I don’t know why, somehow it just feels different to me. Or maybe it’s just the state of the world that tries to dehumanize everything with “AI” that depress me.

Just the thought of sex robots depressed me even more than the state of the world already had.

It’s like regular Fedora KDE, except that it avoids this problem of traces of past experiments everywhere.

Kinoite is much more than that: it is an atomic and immutable spin of Fedora KDE. This has big implications but the gist of it is that:

1. You can roll back to any previous version if anything breaks

2. The base system cannot be modified

3. If you need to install RPM packages, you do that by adding “layers” on top of the base system, and these can be removed if needed to go back to a clean base system

4. You can switch from one spin to another by “rebasing”, but it is recommended that you remove any additional layer first and that you stick to the same desktop environment

My experience on other distros was that upgrading in place a system that deviated too much from “stock” would wreck the install. I would personally play it safe and backup my home folder and do a fresh install.

Just don’t forget to test your backup before formatting your drive!

Android has always been developed in a closed-source manner by Google engineers, the recent changes only reduces the visibility of ongoing changes and the ability for developers outside of OEMs to contribute to Android (such contributions were already rare).

This is explained further in this article:

While some OS components, such as Android’s Bluetooth stack, are developed publicly in the AOSP branch, most components, including the core Android OS framework, are developed privately within Google’s internal branch. Google confirmed to Android Authority that it will soon shift all Android OS development to its internal branch, a change intended to streamline its development process.

Do it! Do it! Do it!

It’s for far more than just deploying VMs: you can create pretty much anything you can on a cloud provider, such as databases, network rules, access tokens, object storage, etc.

Terraform is part of a movement called “Infrastructure as Code” (IaC) which allows engineers to define their cloud infrastructure using code.

This is extremely useful as it allows you to:

• version infrastructure changes

• automate resource and configuration creation and management

• have reproducible environments (think production and staging envs, or deploying a new production env to another datacenter)

Terraform (and OpenTofu) is different to most IaC project as it is agnostic of cloud providers: you can use it to deploy infrastructure to multiple providers, where their competitors are limited to their own platform (I think of AWS’s Cloud Development Kit)

I might be lucky, my Gen 1 Pebble still works (though I have not tested how long the battery lasts in use, I only know it stayed on for under a week idle).

Only restic snapshots are backed-up to B2. ZFS snapshots are for undoing mistakes, though I enabled them recently and I have yet to use them.

My work flow is pretty similar to yours:

For my desktop and laptops: systemd timer and service that backups every 15 minutes using restic to my NAS.

For my NAS : daily backup using restic + ZFS snapshots.

All restic backups are then uploaded daily to Backblaze B2.

Which language are they going to use? Because for some languages (thinking of Java or Node) they definitely would want more than 4GB of RAM. And I’m not even speaking of IDEs that tend to store data in RAM for their suggestion features.

On that note, if the RAM isn’t soldered to the motherboard, I would strongly advice to upgrade the capacity.

I believe Linux Server builds images every day for most of their containers, even though there has been no code changes.

Have you read the article? The fourth paragraph lists improvements systemd timers bring over cron:

Cron is easy, very simple and robust mechanism to execute periodic tasks on a *nix server, and is available by default on all popular Linux distributions. However, cron suffers from some issues:

• If the system is down when the cron needs to run, the cron will be missed

• There is no built-in status monitoring

• There are no built-in logs

• If you want to execute pre/post commands (for example by pinging an external service for success/failure) you have to do it inside the script itself

All of these issues are addressed with systemd services and timers, as the authors explains in details.

The author fails to mention you can also use timers to do schedules like “every 15 minutes, 5 minutes after the systemd started”. Very useful for scheduling automatic updates or backups.

The first one also has better code coverage and way more pulls on Docker Hub.

Jitsi Meet?

This is common in rolling releases

Happened to me on Ubuntu with minor kernel updates including regressions lol

Meh, I don’t think that would fit the community.

I thought for a minute this was a /c/FuckCars meme. I’m disappointed.