Title is quite self-explanatory, reason I wonder is because every now and then I think to myself “maybe distro X is good, maybe I should try it at some point”, but then I think a bit more and realise it kind of doesn’t make a difference - the only thing I feel kinda matters is rolling vs non-rolling release patterns.
My guiding principles when choosing distro are that I run arch on my desktop because it’s what I’m used to (and AUR is nice to have), and Debian on servers because some people said it’s good and I the non-rolling release gives me peace of mind that I don’t have to update very often. But I could switch both of these out and I really don’t think it would make a difference at all.
I have been using Linux since early March 2020. I chose Debian/Ubuntu-based distributions for two main reasons: stability and my strong familiarity with the APT package manager. The APT man page is deeply ingrained in my memory.
Today I run Debian Stable/Testing and also Unstable, on all my computers 4/4 on Debian!
Arch has a combination of great documentation and great packaging. I use Debian on a server but for daily use, everything I need is on Arch.
I jumped from Ubuntu over to Arch because I was getting fed up with all the things I wanted to do being unavailable in Ubuntu, but all in the Arch repo or AUR.
I’ve been using Debian-based distros for like 25 years, so it was definitely a bit of a change, but it didn’t take long to adjust. I’m glad I made the change.
Debian stable:
- Works on all of my devices, none of which are newer than 2019
- Compatibility with all of the software that I use day to day
- I like my system set up in a very particular way and the stability makes upkeep simple
- I was a holdout on older Windows versions before I moved to Linux, so getting new features at all is already exciting
I’m relatively new to Linux, so I’m testing a few distros via VMs right now. My main desktop runs OpenSUSE Leap with KDE Plasma and I love it so far. I’m also trying Fedora 42 with GNOME, but I’m realizing I don’t like GNOME. I’m running Linux Mint Cinnamon on a 2016 MacBook Pro, which is pretty nice too. I also ran Debian stable for a bit. OpenSUSE is my favorite of the ones I’ve tried.
I was given a CD set for SUSE 8.2, then bought the 9.0 book set from a book store because I liked it but wanted the hard copy to reference when I was messing things up. I’ve tried a ton of other distros, but keep going back to Suse because I’m used to it.
A bunch of nerds on lemmy suggested it and I haven’t found any problems with it that make me want to go for another. I use Fedora KDE
Mint CE for my desktop (might distro hop soon for multiple curiosity based reasons, all my data is on non-os drives anyway) - easiest to just get working when fast-swapping, IMO
Debian for my server - it’s the flavor of Linux I’m most familiar with over the years & for my server I dont need any of the shit Ubuntu does
STEAM OS for my Steam Deck (I use it as a TV PC so desktop mode is common with it), because it’s really good for that purpose
I’m an IT professional, I use what I support. RHEL based OS’s, Rocky for servers, Fedora for workstations. That said I still love Debian and use them most often for container images when I dont have a reason to use something else.
Finally time to bust this out again.
Debian for everything since it’s one of the few distros that has always been there. It’s one of the second distros to come after after SLS. Distros come and go, but Debian marches on.
Most big distros are old enough to drink though. Ubuntu is 20yo, Fedora 21yo, openSUSE 18yo, Arch 23yo, Gentoo 23yo. (I got curious and a bit carried away…)
But sure, Debian does have them beat by roughly 10 years (31yo).
Yepp. Started using Debian around the Ham/Slink releases, haven’t found any reason to change yet.
Oh wow yeah I started around the same time. 1998 was a magical time. I stated with a boxed copy of OG Suse but switched to Debian like 6 months later then never switched again. I learned a lot from the thick manual that came with Suse but once I tried Debian everything just clicked. It’s like you learn the Debian rules and philosophy and any package you work with makes sense.
Arch. Purely because of the Arch Wiki. I honestly think it’s the easiest OS to troubleshoot as long as you are willing and able to read every now and again.
Agree.
Years ago, I was troubleshooting something (can’t remember what) on Ubuntu and realised the package had fixed the bug, but it wasn’t in the repos yet… like months behind.
Looked at Arch with it’s up to date repos, moved over and never looked back.
I’ve reported bugs since, watched the package get updated and seen the improvement on my system… now that’s what it should be like.
Bazzite because I get an immutable install that won’t let me accidentally fuck it up. It just works. All necessary drivers for my dock and peripherals are already installed and configured. It’s the very first time in my decades long Linux excursion that I have a user experience that is similar to windows in that sense, but without the enshittifcation of windows.
I genuinely enjoy video editing, gaming, and surfing the web on my laptop when it’s running Bazzite.
I haven’t tried Bazzite yet, but I feel the same about the other ublue flavours.
I’m the most productive I’ve ever been. Tweaking everything was fun for a few years, but now I just need a distro I can trust, that comes with the tools to do anything.
I see rebases to Bazzite DX are available now. I might give that a go today.
I’m loving bluefin and I really want to go all in on the immutable stuff, but I’m having a hard time being productive on it. The devcontainers experience has been miserable (probably because I refuse to use VSCode and every other editor having poor or no support for it); I also had SElinux fuck me up when trying to build some complex dockerfile from a project at work (something that was supposed to just work took me two whole days of debugging - and I even managed to break bluefin’s boot process when I tried to mess with the SElinux configuration. This one was mostly due to my own inexperience with SElinux, combined with there being a lot less content on the internet about fixing stuff on immutable distros compared to traditional ones).
Yep, I’m with you. Project Bluefin is exactly what I want from an OS. My previous Linux experiences had all been awful UX, having to diagnose obscure issues and copy pasting decipherable terminal commands. Until Bluefin, nothing ever worked straight out of the box.
Bluefin’s main issue right now is a lack of good documentation. Like you, I’ve tried to get devcontainers working and they just don’t.
Honestly, even with VSCode, devcontainers are kind of just ok, at best.
They are very fiddly. The containers keep running when you close VSCode (which makes sense, and sure the resource usage is minimal, but it’s damned annoying) and you have to stop them manually. Meanwhile the commands in VSCode to work with/activate the containers are not super clear in terms of what they actually do.
Oh, what’s that? Need a shell inside the container you’re working in for testing things out, installing dependencies, etc.? Well, I hope you pick the right one of VSCode’s crappy built in terminals! Because if you want to use a real terminal, you are stuck with the crappy devcontainer CLI to exec into the container. A CLI that is NOT up to date with, or even includes, all the commands for devcontainers in the editor (which is what makes working with them in other IDE/editors such a pain in the butt…).
And this gets me…. What? A container I can share with other developers, sure, but it’s very likely NOT the container we are actually going to deploy in. So…
Yeah, I’ve also had a lot of frustrations with devcontainers in Bluefin. I really like what the Bluefin project is doing. The reasoning behind it makes a lot of sense to me. But devcontainers are kind of pushed as the way you “should” be writing code on Bluefin and it’s…. not great.
They do have Homebrew and Distrobox though, which helps a lot. I have ended up doing most of my development work on Bluefin on the host system with tools installed via brew, which is kept separate enough from the rest of the file system to still keep things tidy.
Overall, I think Bluefin is great and it, or something like it, may very well be the future of Linux… but the future isn’t here just yet and there are some growing pains, for sure.
But devcontainers are kind of pushed as the way you “should” be writing code on Bluefin and it’s…. not great.
Both podman and docker are on the image, you could just use containers normally without using devcontainers if you want.
Yes! This what I usually do. I will develop on the host using tools installed via Homebrew, then package/build/test via docker.
And to be clear, I really love the ideas behind Bluefin and use it every day. I’ve just kind of given up on devcontainers, specifically.
Not exactly a product from ublue but something in the same line:
Secureblue because of the reasons aforementioned for the ublue images where things are really darn rock solid out of the box AND because Linux is fundamentally behind in security and this project is trying to mitigate some of the big flaws.
I’m asking this because I haven’t tried secureblue: in what ways is Linux behind in security, and what does secureblue do to mitigate that?
And do any of those mitigations negatively impact usability?
Some answers to your first question you can find here: https://madaidans-insecurities.github.io/guides/linux-hardening.html
For the second question about in what ways Secureblue do mitigate that you can find more here: https://secureblue.dev/features
The last question about usability, is very usable. If you use Bazzite you may have a similar experience. It is not like QubesOS that isolate all processes making it even not able to use a GPU.
Thanks! That first link is an excellent resource for a security tool I’m working on. Specifically, gVisor, which I hadn’t heard of, but looks like an excellent way to harden containers.
I may rebase to secureblue from Bluefin at some point to give it a try.
Bazite and bluefin for me, too. been daily driving Linux since the mid-90s and this little cluster of distros is the best experience I’ve had. really feels like everything finally came together.
I use NixOS, it appealed to me because i got to a point where i liked minimal distros like arch and void and i could build them up exactly the way i like them to be, however i didn’t like how i would have to go through that whole process again if i wanted to do a reinstall. With NixOS i can still craft my OS the way i like it, with the benefit of it being saved as a config, and easy to restore. I did make my own post-install script for void but NixOS is a more solid solution compared to my own janky script. I’m hoping to finally settle down on this distro. I guess the upside to the huge learning curve with nix is that it’s a good motivator to not abandon it because it would feel like my efforts to learn it would go to waste lol.
Everything-in-my-life-as-code FTW
Besides everything else you said, I especially love how you can store entire bash scripts in the nix configs, and even populate pieces of said scripts with variables if you so desire.
Also, if you run
nixops, it’s much easier to work with if your dev system is also running NixOS.Yeah, i’m realizing more and more how convenient those variables are. I recently started using gtklock for example, a screenlocker that also has separate modules for extra functionality, which are also in nixpkgs, but the problem is that you have to explicitly specify the path to those modules in the config. So i wrote the config inside of home manager, and pointed to the modules path with the pkgs.foo variables. Worked like a charm.
What do you use nixops for?
It’s for deployments and managing many environments/machines from a single CLI interface. You can do all sorts of things like push configs based on labels/groups, gather real-time data/logs, scale up/down. It’s great when you have a lot of VPS/VDS/VMs to manage and you’re not using a platform’s specific management tools.
I mainly use NixOS as a barebones backend, keep it as minimal and hardened as I can, then most of the projects/apps that run are done through something like Docker or k8s. So for me, it’s all about managing the underlying servers that provide the tools needed for a project to operate.
The tool itself is undergoing a pretty big redesign at the moment, but you can get the gist of it from the overview in the manual of the commands.
https://hydra.nixos.org/build/115931128/download/1/manual/manual.html#chap-overview
That’s fair enough, I also host some applications on a k8s cluster, but for the underlying OS I picked talos instead.
I use NixOS and Home Manager to keep my configuration as code and shared between my PC and laptop.
The only VM I have running NixOS isn’t actually doing all that much, and I don’t mind ssh-ing into it to apply new configs from time to time.
NixOS. My primary reason for switching was wanting a single list of programs that I had installed. After using ubuntu for 5 years I just lost track of all the tools and versions of software that I had installed…and that didnt even count my laptop. Now all my machines have a single list of applications, and they are all in sync.
This is a big reason for me. Also because if anything breaks - even if my system becomes unbootable - I can select the previous generation from the boot menu, and everything is back to working.
It’s very empowering, the combination of knowing that I won’t irrevocably break things, and that I won’t build up cruft from old packages and hand-edited config files. It’s given me confidence to tinker more than I did in other distros.
What does that mean? Like there is one calendar app?
NixOS configuration is done entirely through code, so all of your packages are in a list (although that list can be spread across multiple files; it’s a bit to explain)
I’ve found it can be easier to manage what you have installed, since you can just look at that list and go “oh, why do I still have xyz installed, idek what that does anymore”
I appreciate the way things are configured a lot, but I would not recommend it unless you really like coding and you have time to tinker. It’s not too hard to get simple config setup, but I spiraled down a deep rabbit hole really quickly.
EDIT: If my comment for some reason persuaded you to use NixOS, I recommend you get a basic config setup before installing it. I’d also recommend you look at how annoying it can be to run dynamically-linked applications (i.e. you download a random executable off the Internet and try to run it, or you try to run something you downloaded with npm)
I’ve found it can be easier to manage what you have installed, since you can just look at that list and go “oh, why do I still have xyz installed, idek what that does anymore”
While it sounds sexy and attractive… Not sure the amount of time needed to configure your NixOS is worthwhile. (Except if you have time to spare and want that learning experience !)
Just put everyhting In your personal notes and you have a similar “feature”?
The configuration of nix is not the time consuming part, most of the time it’s faster than other distro if you are a developer. The time consuming part is having an issue with a niche package, the only doc you have is the code and random github issue from 3 years ago that don’t mirror your config, and the nix evaluation doesn’t tell you which part of the config is the problem.
Perhaps, but when I accidentally nuked my system by dd’ing to one of the hard drives, being able to install the exact same system back onto it by pointing the installer to my git repository was an excellent experience.
Is the restoration method mentioned here really only achievable via nixos? How can you be so confident that you are truly reobtaining an “exact same system”?
Nixos consistently intrigues me because of what it seems to be accomplishing but I can never dive in because there seems to also be many warnings about the investment required and the potential for other more complicated and really nuanced drawbacks to arise.
Give it to me straight–is it offering a new approach of stability with the emphasis on reproducibility? If I’m a gentoo enjoyer hardset in my ways, what could I stand to gain in the nixos/guix realm?
Your personal files e.g. ~/Documents are not recreated, you’ll still need backups of those.
caveats are you’ve got to use:
- home-manager to generate your dotfiles.
- something akin to sops to generate and securely store your private keys and secrets.
But all this can be written in the one flake, so yes
nixos-install --flake <GIT URL>#<HOSTNAME>Is sufficient for me to rebuild my desktop, laptop or server from the same repository.I’ve never used Gentoo, and I’m sure there are other methods of achieving the same level of reproducibility but I don’t know what they are.
Nixos can be as modifiable as Gentoo with the caveat being it’s a massive pain in the ass to do some things. I have a flake for making aarch64-musl systems which has been an endeavour, and… It works? I have a running system that works on 2 different SoCs. I do have to compile everything quite often though.
There are efforts to recreate Nixos without systemd, but that’s a huge effort; because it’s very “infrastructure as code”, you have to change a lot of code where editing a build script would’ve sufficed on arch/Gentoo.
As for nix vs guix, guix was described to me as “if you only ever want to write in scheme”, whereas nix feels much more like a means to an end with practical compromises spattered throughout.
Yeah can’t argue against that, never tried NixOS !
NixOS is a declarative distro. Meaning it you can declare pretty much every aspect of it from what software is installed to how the system is configured from a config file.
Using your calandar example, you can list Thunderbird (or whatever) as a package you want in the configuration and it will be installed. You can also use that same configuration on another machine and produce the same environment.
Relevant to the original point, since all your software is listed in a text file, you can easily see exactly what’s installed.
Tinkering, really. I did a bunch of stuff with wine and virtualization and troubleshooted across versions. One time I manually updated the version of sqlite in python’s std lib to be a newer version. I picked a non LTS kernel once. All these things compounded and bloated my system. And when I went to do clean up, I didnt have a record of exactly everything I installed, what I used and what I didnt. It was guesswork to clean up my disk or even remember the tools I used to get a project working.
This is solved with declarative configuration, which is the basis of NixOS. I believe VanillaOS 2 has something similar. Likewise, this is one the great benefits of docker, vagrant, ansible, etc.
