I use to be like you. I used Arch for a long time then tried everything else that was similar like tumbleweed etc. Then I used Fedora and forgot about distrohopping entirely. I still use Arch on my pi4 though because it works nicely for use cases like that.
However I will warn you anything can and will be unstable eventually. Its the nature of software, bugs will happen. For instance a package called ostree was pretty much broken on all distros even Fedora which is crazy.
They did mention stable, which is not something Manjaro can claim in my experience. They tend to hold back packages in the name of stability but it causes problems when using the AUR sometimes.
+1 for Tumbleweed, it works so incredibly well. In the very rare case where an update doesn’t work out for you, you can easily roll back to a previous btrfs snapshot.
Fedora is quite nice, too, but I’ve come to prefer rolling distros over a release based one.
Kalpa / Aeon might be interesting, too, if your use case fits an immutable distro.
After many years on Ubuntu I switched to a Tumbleweed and couldn’t be happier. Apparently a rolling distro can be more reliable than a traditional point-release one.
Depending on your definitions of up to date and stable:
Any of the releases every 6 months distros are more stable and reasonably up to date - something like Fedora even keeps the kernel updated during those months
OpenSUSE Tumbleweed is rolling release with something called “openQA” that is run on the distro before releasing the snapshot to help stability. It also uses BTRFS with something called “snapper” by default, so if something breaks, you can pick the previous version from the bootloader
What is your definition of stability? I have used Arch for about ten years without any major breakage, but sometimes you do have to do some manual tinkering if a package stops working. So it’s stable enough for me, but maybe not for others. Since it is a rolling release, packages are generally being updated quite rapidly.
I think that any modern rolling release distro would fit the bill though.
This here! I actually have had really good luck using Arch. I’ve been running it for only a month now and I make certain to patch/update once a week. Thus far it has not left me stranded. I think Arch is underrated as an OS.
I don’t think Arch is anywhere near “underrated”. The “I use Arch, btw” meme didn’t come out of nowhere. A lot of distros are based on Arch too. Even SteamOS (so the Steam Deck is essentially powered by Arch).
In that regard: yes, Arch is awesome. I use it, btw.
You will only notice the downside of a rolling release distribution when using it for years. Large breaking changes might unexpectedly be applied to your system, instead of at fixed points in time like with other distributions.
NixOS would fit the bill if you’re not afraid of something different. With Nix it’s trivial to cherry pick from unstable channel if you still want a stable base.
It gets close, but NixOS doesn’t have LTS releases yet, so you’ll still be updating at least every six months. Combining the Nix package manager with a Debian stable or Ubuntu LTS might be an option, that gives you a stable base and a few up to date packages on top. However integrating the Nix packages with Debian can get tricky when it comes to core packages such as window manager or DE.
The NixOS unstable channel allows you to get the new packages, but what OP wants is also a stable system and NixOS doesn’t really offer. NixOS has new releases every six months and only provides security updates for one month after a new release is out. So you’ll be updating pretty frequently and things do break in those updates pretty frequently.
Ubuntu LTS in contrast promises security updates for up to 10 years and they have LTS releases every 2 years. So you can basically install it once and forget about it. The downside is that Ubuntu has no way to install new software on the old system by itself, which is why a mix of Ubuntu LTS and Nix might be worth a consideration in some situations, that gives you both a stable base and bleeding edge software.
The stable branches promise no breaking changes (in configuration options etc.). Unstable is a rolling release with everything that entails (personally I use it on desktops and stable on servers).
I honestly tought they had abandoned “native” encryption on btrfs itself, after seeing that it works perfectly fine with LUKS and dm-crypt. Glad to see this is actually being developed.
Can’t wait for the day where you can just create a key, use a TPM or U2F to store it and let btrfs handle the rest
Possibilities at the block layer are generally quite limited since it only has limited means to work with. It’s very low-level. For example, it is not possible to do authentication in LUKS. An attacker can’t read the data but they can modify it; undetected.
You need to stack another layer on top and I’m not sure that’s even a thing.
The patch mentions that authenticated hashes aren’t supported yet either but with effectively limitless metadata to work with, it’s at least possible to do.
Per-directory/subvolume encryption is also a useful feature. You could encrypt the root fs which generally does not contain sensitive information using a key in TPM but then require a password to unlock the user’s home. That’s basically how it works in Android and it builds on top of fscrypt.
Note that this is of course a very theoretical attack vector.
Wouldn’t it then decrypt to gibberish data unless they already had the encryption keys?
Depends. I don’t know the situation of LUKS and its commonly used ciphers in particulare but even some commonly used ciphers are vulnerable to things like bitflip attacks.
This is usually “fixed” by authenticating them but that’s not easily possible at the block layer.
If it decrypts incorrectly, shouldn’t BTRFS checksumming then return an I/O error to user space as well?
Note that btrfs usually uses CRCs, not cryptographic checksums. They’re designed to catch “naturally” occuring corruption, not crafted corruption. Naturally, it’d still be extremely hard to break them when working with encrypted data but it’s a “uh, sounds pretty hard” situtation, not a “we can prove you’d need billions of years to do it” one.
You can use cryptographic checksums but note again here that the attacker could be able to modify the checksum aswell.
I don’t know how feasible this really is a but a possible attack could be to tell btrfs that the extent you modified is a nochecksum extent (you can turn off checksums in btrfs) which would make btrfs simply not check the checksum.
Mint is up to date but less buggy than Ubuntu, and it has served me well for years without problems. The UI is very conventional so I don’t spend time thinking about where stuff is. It supports multiple packaging systems now, so it’s easy to find and install software. You don’t have to go to anywhere as dodgy as the Arch User Repository to find what you need. I like Mint because it’s boring and it works and I can just get on with stuff.
I avoided GNOME3 for the longest time, but I decided to try it on a new install of Debian on a whim and actually ended up really liking it. Needed to enable a couple of extensions, but once you get used to it the workflow isn’t at all that bad.
linux
Newest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.