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.
- 0 Posts
- 39 Comments
Joined 10 months ago
Cake day: March 1st, 2024
You are not logged in. If you use a Fediverse account that is able to follow users, you can follow this user.
3·6 months agoI 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://docs.flatpak.org/en/latest/hosting-a-repository.html
Edit: Some did get a flathub mirror working. The issue is that a. Fastly works good enough and b. There is no concept of “packages” on the server side. It’s just one big addressed content store because of ostree, and syncing is apparently difficult? Idk, not being able to sync the state of content is like the entire point of ostree…
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.
Why are you being inflammatory for no reason? I’m just saying I don’t think it’d be correct for an OS 3 years in the past to be neck and neck with modern stuff. Log off the computer and go outside lmao
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.
I’m not sure how much I’d buy into phoronix benchmarks in this case. CentOS Strea, 9 was performing as good, if not better than, the recently released Ubuntu 24.04 and 2 week old FreeBSD 14.1 despite having a 3 year old kernel and being compiled with an equally old version of GCC. Linux is currently suffering from a pstate bug with AMD, too.
There’s a reason the BSDs are hardly used in HPC.
351·6 months agoCan’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.
Same as any FF or chromium fork. The further away from the original you are, the longer security and performance updates will take to trickle down.
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.
No. They likely don’t have the manpower to update it. It is run by students, after all.
Floorp is great. It has so many features that make it better than stock FF.
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.
Another thing not mentioned yet is maintenance overhead. These distros operate around the clock, all over the world, with talent from the likes of RH and co. There are far fewer people (who run your mirrors) who know how to maintain a torrent tracker (or similar), and on top of that, I haven’t really seen any good BitTorrent caching methods. Support would need to be added to your package manager of choice.
It also comes down to most client having asymmetric bandwidth, and that most users do not have every package installed and therefore can only distribute a very small amount of the total distro. Those users probably don’t want to be constantly uploading, either. I also can’t imagine torrents are too fun to work with when it comes to distributing constantly changing package manager metadata, too.
Oh it’s definitely over-complicated, and contrary to what others say here, Silverblue can definitely have some very difficult to troubleshoot problems (especially when using things outside the direct Fedora ecosystem), which are greatly worsened by rpm-ostree taking 15 years to do anything despite sharing code with the supposedly lighting-quick dnf5. For servers, rpm-ostree is great (it’s in all of RH k8s offerings, see RHCOS), but on desktops, there’s definitely a good reason why RH has to apparent offering and Fedora calls theirs “emerging”. Still miles better than having an unbootable system after updating.
But how does this solve the problem of the config files of the various DEs (GTK rc files or other theme stuff) messing with each other in the home directory?
It does not. Your dotfiles will be a bit wrecked when you rebase. See: https://universal-blue.discourse.group/t/why-is-rebasing-between-desktop-environments-bad/690/4 It’ll also cause random issues like: https://discussion.fedoraproject.org/t/flatpak-apps-crashing-after-rebasing-from-silverblue-to-kinoite/83623/2
It’s mostly plasma fighting gnome, though. I haven’t seen any conflicts with say, sway.
If the kernel is available in a COPR or another third party repo, you can just do a little swapping with rpm-ostree: https://github.com/openshift/os/blob/master/docs/faq.md#q-how-do-i-replace-the-current-kernel-with-kernel-rt-or-a-new-kernel-version-in-rhcos
Edit: Just in case this is the project you’re using, here’s specific install instructions for Fedora Silverblue: https://github.com/linux-surface/linux-surface/wiki/Installation-and-Setup#fedora-silverblue
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.
Tbf you did start your post with
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.