Disentangling the Debian derivatives: Which should you use? There are probably more variants of Debian than any other Linux distro, which can make it confusing. To provide some clarity, The Reg has lined up the main suspects. Toy Story, the movie that saved Pixar (and Steve Jobs' fortune), was released in 1995. Although Debian 0.01 appeared in 1993, you can date Debian from Toy Story, …
I stick with RHEL and derivates (Alma Linux, Rocky Linux) and SUSE/openSUSE on the server and SUSE/openSUSE on the desktop. Mostly because I get longer support cycles, QA seems to be better, there's less breakage between updates and I get packages which, while not necessarily the latest, aren't ancient.
But each to their own I guess
[Different AC]
It depends on what you are using your OS for, of course, but of late, it seems that more and more of the quirky scientific/research software created by quirky academics seems to get packaged for Ubuntu and/or Debian increasingly often, and as for RHEL and friends, very much not so much (and/or then you fall into the horrible morass of compile from source with endless library requirements, many of which are too new to run on RHEL clones anyway).
For that reason, and also the recent implosion and recent not quite cooled fallout of the debris of the RHEL clones, my workplace is currently transitioning to Ubuntu. (There's obviously nothing wrong with RHEL, etc, if they Work For You, but it does seem in some areas that their very long lifespan has now become a little bit of a hindrance.)
I like to play with these things from time to time. Some of them are actually more complicated than Linux itself and have cultures that extend across thousands of people and millions of boffin-hours. I do worry that some of these things may just curl up and die due to a core component being non-upgradeable due to some quirk that current and future generations cant grok. Some of these things are really good but you need two or three years of hand holding as an undergrad to get into them to any degree(sic).
As 10cc used to sing
Art for art's sake
Money for god's sake
While Linux used to be a fun hobby the legacy Unixes which put a roof over my head are deader than a Norwegian Blue and so Linux is having to become a job and there are more people prepared to pay for Dead Rat skills so these days I tend to work mostly on RHEL and it's clones.
I do keep meaning to have a real play with Devuan as it seems to offer the best chance of separating the behaviour of modern Linux kernels from the behaviour of systemd and the sprawling tentacles of its ecosphere or at least systemd-udevd.
How much of the stochastic nature of device initialisation is due to parallelism within the kernel or within systemd's udev?
The systemd dev team seem fixated with Linux on a laptop whereas my paying customers see it as a server operating system and tend to have significantly more NICs and HBAs and so their boxes behave in an altogether different manor.
Went Mint when Unity happened, went back to Ubuntu when Ubuntu MATE happened because Mint kept breaking..
sudo apt-get update
sudo apt-get upgrade
sudo apt-get dist-upgrade
.. to do major version updates.
Currently still using Ubuntu MATE, even if upstream Ubuntu keep doing things to try and reduce the number of pesky desktop users.
I made a joke in another article's comments a few days ago about systemd taking over every aspect of the linux platform, and ended my comment with hyperbole along the lines of "some distant future version will even..." (here, I racked my brains to think of something as far away from init scripts as it was possible to imagine) "...handle DISK PARTITIONING, hahahahaha"
Only for a fellow commentard to point out that yes, systemd now handles disk partitioning too.
Truth, stranger, fiction, etc etc.
One problem is that there are several Debian devs who refuse to let 'their' packages use anything other than systemd, to the point of actively removing support for anything else.
This is clearly against the intentions of the original vote, but It's a bit like the way that Brexiteers decided the referendum was an unarguable mandate for the hardest Brexit we've got.
Not to discredit the work on Devuan (which I have not personally used), I wish people would stop acting like you can't change the init system in Debian. While you do not have the choice during the installer, you most certainly can (even in the latest stable release, Bullseye) change to sysvinit after the install.
Granted, there are some packages that truly just cannot be installed without systemd, but that's largely to blame on the individual package maintainers, not on Debian itself. They've actually done a surprisingly good job with keeping sysvinit compatibility for most things. It's mainly some of the graphical desktop related programs that are more problematic.
But if you change your Debian from systemd after the install, a huge array of stuff breaks and your OS suddenly has a functional app pool the size of a gnat's gnadgers (and full of nasty hidden surprises). The suggestions is just ignorant propaganda.
If you /really/ want to get useful stuff working, you have to do the whole Devuan rebuild thing. Which, ahem, is precisely why Devuan is what it is.
By all means use Devuan. I'm not saying you can't and shouldn't. Just stop selling the lies that you can't use the OS with sysvinit.
I've been running sysvinit versions of Debian on servers since Jessie, and I've been able to get by just fine. Maybe I should clarify that this is largely on the SERVER side (although I've done it on some desktops as well). It is perfectly possible to make it work, so I really don't understand all the down votes, unless it's simple due to people going by what they've heard and not what they've experienced.
This post has been deleted by its author
"I've been running sysvinit versions of Debian ... and I've been able to get by just fine"
There is a big difference between running sysvinit with no systemd installed on the one hand, and installing both, initialising with sysvinit and then unknowingly handing over to systemd for all the other things it does. Most folks mean the former, I have a sneaking suspicion you are doing the latter.
To expand on that: many Debian packages record systemd as a dependency. Therefore, even if you go for sysvinit, your Debian install will almost certainly pull in systemd anyway. The apps that depend on it will then run just fine.
"I have a sneaking suspicion you are doing the latter."
Nope. No systemd init on the system. The OS is installed normally, then systemd is swapped out with sysvinit. When I say sysvinit, of course I'm only referring to the init system; that's all sysvinit is.
apt-get install sysvinit-core
-- reboot
apt-get purge systemd
Then block the systemd-sysv package from getting installed via apt_preferences(5). Keep in mind that the systemd package is different. While I normally don't have that one installed either, it is sometimes possible to install it without worrying about switching your init system. They've broken apart the systemd functionality quite a bit in an attempt to make running sysvinit easier.
Is every single package in Debian still installable? Of course not (unfortunately). That's why I said some onus is on the package maintainers, and some just want to force systemd for no truly valid reason (see Ondřej Surý, the maintainer of the PHP package and bugs like 952895 or 959174). What ends up happening is someone comes along and extracts systemd-specific functionality into its own non-systemd module, like elogind or systemd-standalone-tmpfiles. Other times you have to get creative yourself to get around it. It's definitely not geared toward the novice Linux user.
Is the situation pretty or ideal? Absolutely not (that's why things like Devuan exist). However, it doesn't mean you can't do it in Debian. I was not on board with their decision to switch to systemd, hence the reason I try to stay away from it.
Just stop selling the lies that you can't use the OS with sysvinit.
It's an even bigger lie to suggest that Debian will reasonably do much without systemd - unless, as already pointed out, you do a Devuan on it to fix all the gratuitous dependencies. The reality is that it's not really about init - it's about all the other stuff the systemd folks decided needed "improving" (improving in quotes there as some of the replacements are clearly inferior to what they replace - like using sntp instead of ntp).
You try really excluding systemd from a Debian installation and you'll find ... not a lot of packages that will install.
Now, that could have been sorted - "all" it needs is for package maintainers to support both the systemd and non-systemd ways of doing stuff. But they aren't, and the systemd folk appear to have a policy of making their systemd replacements for previously working stuff incompatible with the other alternatives. SO if you have to do two ways of logging, two ways of another thing, two ways of something else, ... then that's a lot of work and I can understand package maintainers not wanting to do it.
I recall when the completely fudged vote was done, there were claims that "you'll still be able to ..." - but even back then I could see that was never going to last even a short time, and it wasn't long before I could see that that was the case.
TL;DR - it's not really about the init (PID1) although that's a big part of it. It's the attitude of just trampling over everything and fixing stuff that wasn't broken, and gleefully removing choice that really pees a lot of people off.
EX-Debian user.
"You try really excluding systemd from a Debian installation and you'll find ... not a lot of packages that will install."
I guess my definition of "a lot" is very different.
First and foremost, I'm not a systemd fan. That's why I try to get rid of it. I've used it, and when it works properly, it's not that bad. When it doesn't work, that's when it's a royal pain. Things that were once simple to debug become ten times harder because you're not just fighting a simple shell script.
If I am pretty much forced to use systemd (like in Ubuntu Server), I'll disable as many of the "extra" services as possible, like timesyncd or resolved, and use other programs meant for that sort of thing. I still use rsyslog over journald as the primary means of logging.
For my experience with servers, I've been able to run Debian under sysvinit for many years with services like Apache, nginx, Varnish, PHP, Postgres, MariaDB, memcached, node.js, Docker, and all sorts of other very commonly used setups. I'd say those systems are doing "reasonably much".
Is it easier to just run Devuan instead? Probably. I've never tried, so I can't give a first-hand account. I don't know how easy it is to drop in a package built for Debian (most probably work, but I'm sure some don't). If I had to offer up a concern, it would be wondering how long the Devuan guys will continue to make releases. I don't know what sort of financial backing they have to keep them going, so they may fizzle out or they may continue to be a strong systemd-free alternative.
I don't have any money on this fight, but
>> Things that were once simple to debug become ten times harder because you're not just fighting a simple shell script.
Having looked at many of these shell scripts, one thing I would never describe them as is "simple". A systemd unit file, OTOH, is something I worked out how to do simply by looking at one at changing 2 lines.
>> I'll disable as many of the "extra" services as possible, like timesyncd or resolved, and use other programs meant for that sort of thing.
So you're taking a system, trying to remove certain parts of it and replace them with other parts under a different system, and then complaining it's complicated?
As someone who tries not to look at the engine unless it stops working, there's very little difference to me between sysvinit and systemd. I don't honestly care which one I have, I just want a computer.
"Having looked at many of these shell scripts, one thing I would never describe them as is "simple". A systemd unit file, OTOH, is something I worked out how to do simply by looking at one at changing 2 lines."
I've been dealing with programming for over 25 years, so I will give it to you that "simple" is a very subjective term. By simple, I'm referring more to the idea that I can add a few echo statements or run the script in debug mode to trace what's going on. systemd is a black box. It will fail to start processes, yet report that everything is fine. You are then stuck trying to trace what's happening on your own. To use your engine analogy, it can be like trying to diagnose a modern engine that's giving error codes without an OBD reader.
"So you're taking a system, trying to remove certain parts of it and replace them with other parts under a different system, and then complaining it's complicated?"
My big rub with systemd is the NIH syndrome it suffers from. Tools already exist for a lot of functionality that systemd just tries to duplicate. Sometimes it (thinks it) adds a few useful things, but other times there's no reason for it to exist. Many of these tools are supposed to be optional (i.e. "extra"), so removing them should not affect any functionality. That's why I don't equate it to making the system more complicated. However, systemd often blurs the line between modular and dependent components.
"As someone who tries not to look at the engine unless it stops working..."
Based on that, I'm assuming you are more of a desktop user. In general, I wouldn't say Debian is geared toward desktop users, although I used it in a desktop setting. It's shines more n server environments, and people that run servers typically do look a lot more at the engine.
Having looked at many of these shell scripts, one thing I would never describe them as is "simple".
A fair bit of that is not actually to do with init, but with other (related stuff). An init script can be just a couple of lines (I've done that occasionally). but some package maintainers do seem to enjoy making them somewhat more complicated than seems to be needed.
A systemd unit file, OTOH, is something I worked out how to do simply by looking at one at changing 2 lines.
As already pointed out, this is where systemd really screws you over. In effect, it's moved a chunk of those "complicated" scripts into a black box of compiled code that you can't fiddle with. I'd go further than suggesting it's like trying to diagnose a modern engine just by the warning light - more like trying to diagnose a modern engine when it craps out but doesn't even put any warning light on.
With a script you can put some judicious echo (and other) statements into the script and (for example) dump to state of the environment into a file together with some "I got here" messages which can allow you to peek inside the system at the time the problem is occurring. OK, that's not "shell scripting lesson one" standard, but it is doable for someone with fairly basic shell skills - and 100% better than a black box that "just doesn't work right".
But this whole unit files vs "complex" shell scripts debate is a bit bogus anyway. There are alternatives to SysVInit, and several are supported (to a greater or lesser degree so far) in Devuan - and from what I recall reading, at least one of those has a config setup similar to systemd unit files. One of the things Devuan offers is not just the ability to stick with SysVInit - but to use your init of choice (apart from SystemD - you have the choice to go back to Debian for that).
Just stop selling the lies that you can't use the OS with sysvinit.
That completely depends on your definition of 'use'.
The result of removing systemd from Debian, results in a for most people unacceptably broken system, where the unfortunate soul spends more time workng around everything that's broken, than acrually using it for any productivity.
It's like saying that you can 'use' a car if you take off 2 of the wgeels and the steering wheel and throw the ignition key in the Thames.
You can sit in the driver's seat and loudly grow 'Vroom' all day, but you're not getting anywhere.
Debian just boots into the installation program – there's no way to "try before you buy"
Typing "debian live image" into DuckDuckGo brings up https://www.debian.org/CD/live/ as the first hit - the way in to official live images and unofficial images with non-free software included. It will take a little more clicking to get to the list of images but there are images for several desktops. Yes, the route to get them could benefit from some tidying up but they're readily available.
At https://www.devuan.org/get-devuan the first option listed is a live image, available in any desktop you want so long as it's Xfce. Again a few additional clicks are needed before you're downloading from a mirror.
One thing I would complain about with Debian - and hence Devuan - is that for a long term support distro there's a strange reluctance to ship an LTS version of KDE.
[Author here]
The thing is that *you need to know that you have to do that.*
The same is true of openSUSE: yes, these things exist, but they are not the default, and for non-experts, they are effectively hidden away.
In both cases, the images that you actually might want to use are hidden, hedged about with spurious warnings (openSUSE: "do not use these live images to install a computer"; Debian: "non-free images are unofficial and unsupported").
They are only findable if you know you want them, in which case, you probably don't need them.
That is not good. That is bad. That is obfuscatory and unhelpful.
But they are old decisions and so are now enshrined received wisdom and the respective teams are very reluctant to change them.
It looks a bit cluttered to me - or do those panel things at top and bottom autohide if you want them to? and then there's the latest idea of cluttering up the title bar with extra controls.
Beauty lies in the eye of the beholder.
I was in "RPM dependency hell" with Red Hat at the time, and when I found out you could just say "ok, grab everything you need to upgrade and install it" with mostly just "apt dist-upgrade" then I switched to Debian Testing (Sarge at the time) and I haven't looked back. I've only had Testing break my system once in all those years.
"By default, it also doesn't include either Snap or Flatpak" is a feature, as far as I'm concerned. Every app does not need another corresponding copy of the OS. I've also migrated to Devuan myself. I tried writing a systemd init script once. Just once. I also tried writing scripts to auto-download pictures from my camera, and that was the motivation to move to Devuan.
I was in "RPM dependency hell..."
Yes, me too, so that when I discovered PCLinuxOS had all the tools from Mandrake and it had the apt system of package management that was it, and I have stuck with PCLOS ever since.
There's something about systemd that puts me off trying the likes of Debian and its derivatives so although there might be features that would appeal to me I have tended to steer clear. Keeping my boxes on the straight and narrow is one thing, wrestling with a vampire squid is another.
'[Brian] brightened up. “Do you know,” he said, “my cousin said that in America there's shops that sell thirtynine different flavors of ice cream?”
This even silenced Adam, briefly.
“There aren't thirtynine flavors of ice cream,” said Pepper. “There aren't thirtynine flavors in the whole world.”
“There could be, if you mixed them up,” said Wensleydale, blinking owlishly. “You know. Strawberry and chocolate. Chocolate and vanilla.” He sought for more English flavors. “Strawberry and vanilla and chocolate,” he added, lamely.'
Stretching your (well, Sir Pterry/Neil Gaiman’s) analogy perhaps too far, I wonder what the Them would make of the Goats’ Cheese, Marionberry & Jalapeño ice-cream I bought from the somewhat hipster-ish Salt & Straw last week?
In 1970 my dad was teaching summer school in Oregon and we went to Portland to a place that served 57 (IIRC) flavours of ice cream. They did a thing called the Pigs Trough which you got for free if you finished it. A couple of my dads grad students managed it - I've seen smaller planters in city centres!
[Author here]
Since I see people are quoting Pratchett and Gaiman, may I quote Monty Python?
"I'm feeling much better!"
It is. I am absolutely not denying that.
I think that the issue is that it got a lot better years after multiple other distros had got underway making Debian easier to install, and they have not gone away. Indeed, they continue to proliferate.
I have never run Gentoo other than in a VM to see how their package manager worked. Gentoo was another independent distro started around the same time as Arch according to the Linux distribution timeline:
https://upload.wikimedia.org/wikipedia/commons/b/b5/Linux_Distribution_Timeline_21_10_2021.svg
Don't keep calling systemd an "init system". If that was all it was, it wouldn't be so controversial. I'd probably still think it was a badly-designed init system though.
I was a Slackware user, but switched to Debian prior to 1.0 and used it for everything for 20 years until migrating to Devuan in 2017 or thenabouts.
I am not talking about the APT toolkit in general here, you understand. I am talking about the `apt` command, an entirely different thing, which is an easy-to-use wrapper around APT and its many subcommands.
This is APT, the Advanced Package Tool:
https://wiki.debian.org/Apt
It is normally manipulated from the command line using command such as `apt-get`, `apt-cache` and so on. For example:
apt-get update && apt-get dist-upgrade -y
That's two separate invocations of the `apt-get` command.
Another common one is:
apt-cache search tilde
Debian offered a wrapper around this called Aptitude:
https://wiki.debian.org/Aptitude
It is invoked similarly:
aptitude update
Since Ubuntu 16.04 apt-get, apt-cache etc. have been supplemented by the `apt` command, which replaces various separate apt-get and apt-cache commands:
apt update && apt full-upgrade -y && apt autoremove -y && apt clean && apt purge
or
apt search tilde
You no longer need to know the difference between apt-get and apt-cache and so on. The `apt` command does them all, just as `aptitude` did before it. It also has nice pseudographical progress bars, which I personally like.
There is a nice summary of the differences here:
https://itsfoss.com/apt-vs-apt-get-difference/
Debian included aptitude by default and it was the recommended tool. AFAIK Ubuntu never installed aptitude by default in any version, and v16.04 introduced the new `apt` command which does much the same thing.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
