Tbf you did start your post with

I’m in the process of starting a proper backup

So you’re going to end up with at least a few people talking about how to onboard your existing backups into a proper backup solution (like borg). Your bullet points can certainly probably be organized into a shell script with sync, but why? A proper backup solution with a full backup history is going to be way more useful than dumping all your files into a directory and renaming in case something clobbers. I don’t see the point in doing anything other than tarring your old backups and using borg import-tar (docs). It feels like you’re trying to go from one half-baked, odd backup solution to another, instead of just going with a full, complete solution.

As said previously, Borg is a full dedplicating incremental archiver complete with compression. You can use relative paths temporarily to build up your backups and a full backup history, then use something like pika to browse the archives to ensure a complete history.

I think it’d also be good to document:

Alpine and NixOS: both 6 months

Minor releases of RHEL: 6 months

Non LTS Ubuntu: 6 months

The question also brings up Fedora rawhide. Fedora rawhide never has releases, though its version is always the current latest branched release (not necessarily stable/beta/alpha) + 1.

Since the pace of development was also brought up:

Fedora Rawhide and ELN (same package set) -> Fedora Stable after ~2-3 months of being “stabilized” (this stabilization period has periodic “freezes” which is why bad versions of XZ never made it into Fedora 40’s beta)

Fedora Rawhide and ELN (same package set) -> CentOS Stream (currently unclear how long it takes to go from branched to full release, though it was branched months ago from ELN) -> RHEL every 6 months

AlmaLinux releases are tagged from CentOS stream every 6 months, and patched with security updates. When a new version releases, the current minor release is immediately EOL’d, unlike RHEL. Rocky is the same. Both have extra support services from third parties. RHEL offers EUS releases for every other minor release (as of RHEL 9).

It’s a common misconception that Fedora stable releases become CentOS Stream releases. This pattern was true pre-CentOS stream, but now, for the most part, CentOS Stream and Fedora stable might share a few patches at most, but their development timelines are different. They branch directly off the rolling Fedora Rawhide/ELN trunk.

Debian unstable -> Debian testing (auto-promoted after 2 weeks iirc) -> Ubuntu stable or Debian stable

To everyone saying you can’t mirror a flatpak repo… you’re absolutely right. There should be a far easier way to set up your own mirror without needing to build everything from scratch. That being said, if you wanted to try to make your own repo with every one of flathub’s apps, here you go: https://github.com/flathub https://docs.flatpak.org/en/latest/hosting-a-repository.html

I hope this makes the US revisit the concept of building something like the SSC. Competition in science is awesome.

Am I wrong in assuming that both OS’s should be sharing the EFI and /boot partitions?

Shared ESP is fine as long as you don’t run out of space. Nothing in /boot should conflict but that’s not guaranteed, although having 2 potential boot partitions means having 2 potential grub configs. I’d make sda3 a ~2GB ext4 boot partition just for Fedora (mounted at /boot), and an sda5 with btrfs with a home subvolume mounted at /home, and a root subvolume mounted at /, then mount sda1 at /boot/efi (this is the default layout iirc, albeit with different partitions, ofc). This might be easier to do in the advanced blivet gui.

And yes, Linux’s boot process is a convoluted, fragile mess and there are currently multiple ongoing discussions on how to improve it.

The guy replying is a total dick, and for people that like to encourage change to create software that evolves with needs, they sure do refuse to change when needs evolve.

This is definitely just a dangerous cause of that one xkcd. At the very least, Debian unstable caught something before it could reach everyone else. That works, at the very least.

I sometimes hear that it is a different story on servers.

Wonder what their usages are, especially in a container-focused context, where most containers simply don’t have an init, and the base system just needs, at most, to have a container runtime (+/- a few other things, see: talos linux and their 130MB bare-metal ISOs).

Mfw CentOS Stream 9, using a kernel, compiler, and glibc version from 3 years ago, still manages to pull ahead of software released a few weeks ago on hardware released years after Stream 9’s original release.

Can’t believe he figured it out. What a shame. Guess we’ll have to go provoke another country to invade our fellow flourishing independent democracies, who play a key role in the world’s trade.

Seriously though, I hope he’s just giving himself an easy out here. There’s always too much war going on.

Also see: systemd-bsod. Generates QR codes, too. I think blue for userspace boot-time errors and black for kernel stuff might be nice.

Go for FreeBSD: this might require a learning curve, because this is an OS I’ve never used. Are commands that different from debian?

Both of them are, at the very least, unix-like, so the core command set is mostly the same, albeit with sometimes large functional differences.

Simply install debian 12.5 again, the easiest choice.

You are familiar with Debian. This is probably the choice I’d go with.

Kernels are also updated more often than with debian as far as I know.

That’s why Debian has backports.

If you’re nervous about rm, there’s many alternatives that work by moving a file to your recycling bin instead of deleting it outright. I think the current fun one is trash-rs, but some distros package trash-cli.

Mmm Russian propagandists going hard today, or rather, as hard as ever, ensuring to amplify the messages of individuals who already have questionable allegiance to the US in the first place. Just keep in mind the Ukrainians still want to fight. It’s not like the US are the ones trying to kill the Ukrainian president to get their way.

The cheapest you’ll find that is still pretty good for HDDs is serverpartdeals. They have recertified Seagate Exos X22 20TB drives with 2 year warranties for $215. They also offer new drives with the full 5 years, ofc. Exos can be a little loud, as with other enterprise drives. You’ll still need a way to read from it in case you don’t have a spare drive bay, too.

“run it as root for maximum functionality.”

Russian-based company

Closed-source

Aims to enhance security

Hmm

It’s funny, because there was research done by UC Riverside which specifically figured out LTS branches receive patches for CVEs significantly later than vendor specific branches. Specifically:

Interestingly, we note that the picked CVE patches appear in distributions 74.2 days earlier than LTS on average;

They also conveniently left out the part of Greg KH’s opinion stating that he recommends the use of vendor kernels over stable/LTS branches, too.

I found this particularly funny:

It all comes down to a delicate balancing act between security and stability. Some top Linux kernel developers and CIQ are coming down on the side of security.

Now I know CIQ is “supposedly” different from rocky, but what is CIQ going to do, break bug-for-bug compat and use stable kernels in their supported version of Rocky? This entire article feels like it doesn’t fundamentally understand that not all bugs (especially ones that lead to potential low-ranking CVEs) aren’t worth patching.

Hah, those are the load times I used to get on my Xbox One with its dinky HDD. At the very least, The Midnight Ride has been updated to post next-gen, and I now get really small loading times (<5 sec) on my SSD. The game feels less rough around the edges, too. Only took 3 hours to set up :,)

The US’s Department of Defense is one of Red Hat’s biggest customers. Other than that, the US government theoretically uses Linux quite extensively, going as far as making significant contributions such as SELinux. It was mentioned already, but academia uses Linux a lot, too. I saw lots of machines at SLAC running CentOS 7.

GNU/Hurd