I personally used ubuntu for a very long time and for some servers too, as compared to debian, debian is very slow in terms of being up-to-date, it takes the safest approach.
One core thing that ubuntu managed to get right (or maybe linux nowadays) is to not break your OS after updates. This is a deal-break for me these days, as not only my device is crucial for my work and downtime of days cannot be afforded, however it might contain security keys that are crucial for access.
As for everything else related to linux distributions, there are only 2 things that are important for me:
The package manager, how up-to-date it is kept and how well it operates;
The desktop environment, especially when it comes to multiple screens and big resolution support.
My focus for this laptop is Nerves development so stability is key for me along with a user-friendly package manager and hopefully security configuration tools. Another laptop will be used for all the other stuff that entails email, spreadsheets, etc. For me, the GUI isn’t a priority… good command line tools is important to me because GUI tools often abstract away stuff that makes it difficult to understand what happened under the hood as they say. Recovering from mistakes is not something I want to depend on a GUI interface to have what I need. It’s old school I know but cutting edge features is definitely not what I’m looking here.
Then you’re probably better off with a rolling release distros like Arch / Manjaro or Void because they religiously keep as much as they can always up to date.
Ubuntu is okay but it grew bloated and they push Snap and its store too much these days and surprise surprise, some of the applications there are not as isolated as claimed and also send telemetry 24/7. Ubuntu became almost as bad as Windows because a simple calculator from the Snap store has been reported to start as slow as 5+ seconds.
I get how people want a stable distro but many of them are lately; this is not 2009 when you’re one small update away from your machine booting into a screen that doesn’t even turn itself on. (Though I hear that it’s still happening to some, sadly.)
Correction on LVM, it does do COW snapshots. However, because they are block based, you can probably only do a few of them before there are performance implications.
Also, I did some more reading on BTRFS and, well, I’m only going to use it for data that I can lose. I was reading some horror stories from HN and one of the pointed to Suse Enterprise Docs, which says using repair could destroy your filesystem.
I mean, you got to be kidding me, right? This is a really elaborate April Fools? Right? Right??
Debian includes the guix package manager by default now. Guix and Nix package managers can be installed on any distro and still work properly, so, like Flatpak, they are an alternate way to keep packages up to date.
I think you will either want Void or Debian+Guix or Debian+Nix. Did you give any of the LiveCD’s a shot yet? As long as the hardware works, you should be good with them.
I’ve been using BTRFS for the last 9 years, never had data loss issues. I’m even running a home NAS with 14 drives in the dreaded RAID6 configuration (write hole if power loss happens just right). I have not lost any data yet. I also back everything up religiously so even if I did have loss, I can recover.
I have a love hate relationship with systemd. I have been thinking about trying out Void, but I don’t want to go back to init scripts again. That was a pain to manage 13 years ago before I switched to systemd.
Same. The startup/shutdown parts of systemd are nice, but there are some other components (network, dns, etc) that are buggy. And whenever I have to lookup the proper flags for journalctl, it makes me wonder why they didn’t just quit while they were ahead. The code is so broad that the opensshd backdoor hooked into systemd which then included xz. I’m sure that it all happened in a completely logical and organic way, but that seems like a sentence that shouldn’t be possible to write.
Anyways…
Void doesn’t use OpenRC or SysvInit. It uses a supervisor daemon called runit which uses scripts like this to run ssh. This sets up an environment and then keeps the final binary in the foreground. If the binary crashes or the script exits, it restarts it.
The methodology is from daemontools from the late 90’s. It’s simple, robust, and for certain use-cases like dependencies or oneshot - just kind of janky. That being said, I don’t particularly care if a service has to restart 3-4 times because it crashed due to not having a dependency. To me - that just means the supervisor is doing its job. For oneshot, they pause the exit, so it doesn’t restart. In either case, it works.
If you fire up a VM and play with it, you can see the structure is pretty straightforward. 95% of the scripts just start up the binary in the foreground for monitoring.
Interestingly, Void was one of the first distributions that started using systemd, but it didn’t meet their portability goals, so they switched over to runit.
Are you certain? Lately I had to slightly tinker with systemd because I wanted a few NFS mounts working on reboot, and I also wanted a bcachefs cluster mounted as well. But it was really quick and painless (and I regret not writing down what did I do exactly). It was literally change the what’s blocked on what on 2-3 places and it was done. Even rebooted 3 times in a row to be sure and it worked every time.
I’ve had issues on my laptop with wlan0 and some DNS issues. There is a race condition with wireless and I don’t know if it was ever resolved, I just resolved it myself by delaying it a little bit. But on desktop with a wired interface, I have no problems.
Ah, you are quite correct there, yeah. I’ve read that wireless interfaces need more time to warm up and this has tripped up systemd indeed. Shame, hope they resolve it at one point because I have zero complaints about it otherwise.
Might be a strange argument to make in a community dedicated to a relatively niche language like Elixir, but with respect to the systemd discussion I would say for someone new to linux starting with a non-systemd distro is likely to be painful. Systemd now dominates the linux ecosystem by a wide margin and so troubleshooting is made easier due to more readily available resources. Also lots of packages out there will have systemd dependencies so a lot more work has to be done to make them work on non-systemd systems.
I have zero idea what the other discussions about writing custom scripts are about, I barely understand how systemd works.
For veterans maybe going under the hood and customizing their things is a plus, however for me I just want it to work and to not break. I don’t want to spend entire days compiling my own drivers to run Arch.
That’s not happening with Arch and its derivatives. Maybe you’re thinking of Gentoo.
You can have a ready desktop environment with Manjaro’s installer in literally 5 minutes. Done it several times. And you’re starting the installation from its live disk/USB so you can even screw around a bit to check if you like what you see before committing to installation.
Back in the 2016-17 I wanted to install Arch on a notebook, just to be informed that I have to compile my own wireless drivers.
Maybe the situation got much better, but I remember having a colleague that literally took almost a month to have a fully functional Arch installation.
Arch is more bare and is the spiritual successor of Slackware, the distro for absolute minimalistic maniacs.
I sympathize with their sentiment but I’ve taken the more sane approach: have a working OS in 5 minutes, install your stuff that you need (should take you one evening for a dev machine), then you can remove packages and customize to your heart’s content. Or don’t – I’m in this camp, I like Manjaro’s out of the box experience and only uninstalled Thunderbird.
Totally understandable. There’s no reason anyone should need to be debugging an init system.
Elixir is super-stable, so a huge community isn’t necessary. That’s why I’m 50/50 on this statement.
On the one hand, everything you’ve said is true.
Systemd is “standard”.
Lots of systemd dependencies into everything now.
On the other hand, I feel this is like Stockholm syndrome.
Why should anyone need to be debugging and troubleshooting this?
On rebooting, there’s a random lottery of of potentially waiting 90 seconds for a service to shutdown.
Updates declare the old way as broken, but ignore edge-cases…which actually break things for complex setups. At some point, Ubuntu changed from /etc/network/interfaces to netplan/systemd-network. I don’t remember the exact combo. What I do remember was that and bunch of networking was no longer possible. Like trying to setup bridged vlans.
Updates just change things and don’t tell you. For instance, I have a router/dhcp running on a Raspberry Pi equivalent. I come back home two weeks ago and I have no internet. OK, the sdcard stopped working after 5 years and I had to re-install. So I downloaded the old Ubuntu 18.04 image, manually set the network ip address on eth0 so that I could ssh and setup dhcp. But I could no longer update to 20.04 or 22.04 because old-releases.ubuntu.com wouldn’t let me dist-upgrade. No problem, I’ll just install 22.04…set the ip…and…I can’t ssh into the machine. Wait, what? Systemd changed eth0 to end0. Like WTF #*#!?#? And with no release notes. So yah, maybe they have some technical reasons for the change, but this cost an idiot like me several hours for a 10 min re-install job.
nohup mysteriously quit working after you log out…changing the original behaviour? you guessed it…systemd change. tmux and distros had to change how they handle it.
And I’m sure I ran into even more things over the past decade.
I think the init part of systemd is ok/good, other than the 30 second reboot lottery, but I really don’t want them touching any other part of the system. It breaks too often. Especially after this openssh backdoor thru systemd thru xz.
For a decade, I’ve been pretty ambivalent about systemd. It improved some things and I liked some things. It was better than the Ubuntu attempt called “upstart”. But after 10 years of hoping stuff will quit breaking, screw it. I’m ok with spending a few hours to set something up once. I’m not ok with playing russian roulette with every upgrade. Until I switched off, I didn’t even realize, I just though, “Well, I guess that’s just the way it is.”
So, in conclusion, I’m perfectly content that Void uses runit.
I think you’re making a technical argument while I’m making a sociological one. My point was simply the state of the Linux ecosystem right now defaults to systemd and therefore a Linux novice will likely find things easier to manage. I understand the arguments against systemd from a technical standpoint. I’m glad there are alternatives. But swimming against the tide is intrinsically more challenging. That’s all I was saying.
I like having a single tool for these problems. We the techies disperse our energy way too much. IMO it’s time we got our sh1t together and started contributing to something and not always going our own way and making the 179th tool.
Having a mono-ecosystem in this case is beneficial because people will focus on fixing the errors you showed (though sometimes the maintainers are difficult; though I have no idea if that applies to systemd, any observations?).
I disagree it breaks too often, though I’ll admit my Linux usage is still not as much as it was some years ago. Still, I have a server for like 3 years now and there was literally only one problem ever, and wasn’t related to systemd. It never did anything bad to me, and this server has seen no less than 11 different hard disks, 3 external keyboards, 2 mice, seen 3 replacements of internal drives (and planning to add a NVMe drive soon as well), and I might forget a few others. Not saying this is a classic usage but you’re kinda exaggerating from where I am standing.
Finally, have you tried reporting those issues?
I fear for the world of free computing after Linus retires or dies, but Linus himself is far from perfect, f.ex. he often said security is not a priority for the kernel. He’s awesome but let’s not idolize him.