Systemd 255 is here with improved UKI support The 255th version of systemd is here, banishing support for split and unmerged /usr directories but enriching its UKI boot support. Although Systemd 255 mainly consolidates and builds on changes that were announced earlier, it does have some new features. A visible one may prove to be the new BSOD service, which is genuinely …
Recently updated OSs on my local network, after managing to avoid dealing with the shitty "S" for many years, finally had to face up to it to get rid of silly DNS problems, unwanted link-local routes amongst other things, Of course fixing them is one thing, stopping them returning again and again like stupid zombie puppies is another! Resenting the time & effort I was forced to spend learning how to fix this nonsense. I respectfully submit the following commands for your perusal . . .
sudo systemctl mask avahi-daemon
sudo systemctl mask dhcpcd.service
any other things that people like remove to reclaim control over their own computers?
Chief among them being most essential daemons finally being limited to least privilege across the majority of Linux distros. Honestly, Lennart took a critical eye to launchd, upstart, SCM and SMF and created something which made both distributors and sysadmins lives much much easier. Just like PulseAudio, it was buggy garbage in the beginning (using a 32-bit userland with 64-bit kernel? enjoy launchctl doing nothing after a few commands!) but there’s no way I’d ever wish for the clock to be turned back now that it’s mature and stable.
"Chief among them being most essential daemons finally being limited to least privilege across the majority of Linux distros."
I notice you haven't mentioned any issues at all, just said that OP is wrong to think sytemd fixed lots of things and implied that it broke loads more.
Your fact free post got plenty of upvotes though, making this place look like an echo chamber. All you have to do is have the right opinion and you don't need any data at all to back you up.
"essential daemons finally being limited to least privilege"
Seeing as no one else has addressed this claim (possibly because it's so obviously wrong), I will. A well written daemon will do the bare minimum at startup that it needs to do as a privileged user, then switch to an unprivileged user. Standard coding practice for decades, no over engineered, buggy, poorly documented crap like systemd required.
Show us the well-written daemon which does ALL of the following:
Carefully sets up cgroups to help prevent DoS through resource exhaustion
Applies a strict eBPF system call filter to prevent unnecessary system calls being used
Locks itself out of using alternative OS personalities, UNIX sockets, and unnecessary IPC properly
Bans itself from creating namespaces after setting up its own private namespaces
Removes its own ability to communicate over TCP/IP by removing NIC access
Hides all other processes except for itself within its own view of procfs for confidentiality
Checks that it has been confined under the correct SELinux/AppArmor domain
Bans itself from interacting with any/all device nodes, except those it needs
systemd gives you all this for free and much, much more, as it also offers these kinds of lockdowns for scheduled tasks and processes which normally would have needed to run under a superserver like (x)inetd. A well written daemon COULD technically do all of the above but good luck auditing for it and even better luck trying to make it common practice.
Further down the roadmap, systemd will be able to check the execution environment hasn’t been tampered with prior to execution. Checking itself is something no daemon currently does, but with the help of TPM, Secure Boot and Linux IMA, systemd will be able to check the integrity of your daemons and their execution environment for you.
systemd was buggy garbage when it first landed, but I definitely wouldn’t dare go back to what we used before.
Well-written daemons can still end up containing buffer overflow vulnerabilities which lead to execution of code not contained within the daemon itself. That was one of the key drivers behind the chroot jails of old, not just restricting access to things, but making an attackers life so much harder by giving them no access to any local binaries or devices that they could potentially abuse post-compromise. Linux lets us do so much more than what the UNIX systems of old let us do to help mitigate the impact of unknown security vulnerabilities, and we’re not wrong for wanting to do those things in a highly centralised and auditable manner.
What is it with the systemd devs finding obscure ways to provide info? If it's inteligent enough to produce a QR which will point to what might be wrong, then surely it could cope with just printing it on the screen where we can see it without having to resort to jumping though hoops. It's bad enough having to use journalctl to find out what's going on because they decided that wrting to logs was far too obvious.
I came here to say exactly the same thing. It's already bloated enough, but all that code to generate a QR code with, at the very least, a list of codes to generate web links to encode into the QR code, why not just put the goddam error message on the screen in the first place? But, as already mentioned above, look who Poettering works for. He's clearly fitting in very well in a place where dumbing everything down to a sad face for system errors is normal practice.
The future of M$ is the 365 cloud; boxen booting straight into Edge+home page are already in the dev community. QR codes and point-and-click fixes make perfect sense in this world if you have a spare Lumia or Surface handy. I mean, display the error message encoded so you need a smart device and a ridiculous runaround to read it, what could be more Microsoft? A sticky pop-up over the thing you need to click, asking if you want to revisit some random email from two months ago and with no Close widget so you get to chill out for ten seconds, is the real cherry on the cake - for Satan.
While I feel an ideological revulsion towards this, I do have to concede that it's not really obscure as such: it's just symptomatic of having been designed by a member of the "phone first" generation - people to whom the idea of an internet-enabled phone not being available at all times is unthinkable.
Pointing a phone camera at the screen is arguably more convenient than typing some error message or code into google (especially if you only have a crappy on-screen keyboard available because your systemd infested computer won't start).
I agree that it should do both, and the format of the contents QR will probably be where it falls down.
If it is a weblink, who will be hosting it, and what is their plan to prevent link rot. Third party "permalink" services aren't permanent, aren't generally open source, and have down time. Anyone who thinks a fix for that is easy and that someone will host it for them for free forever is bound for disappointment on many levels. Even keeping the the code base and documentation in sync is one of the most notorious problems in computing and about as much progress has been made to "solving" it as a "secure" backdoor to other peoples encrypted communications.
Just suppose... just suppose...
That your system has been hacked in some way. We see those stories here almost every day of the week.
Those hacker could easily hack the QR generator so that the resulting QR code sends you to a Child Pron site or some other NSFW embarrasment?
Are you going to risk going to jail and being on the sex offenders register for life because you followed a QR code?
BTW, the short URL's are just as dangerous.
Pottering can go suck on this--> [see icon]
why not just put the goddam error message on the screen in the first place?
Or why not both?
That your system has been hacked in some way. We see those stories here almost every day of the week.
Those hacker could easily hack the QR generator so that the resulting QR code sends you to a Child Pron site or some other NSFW embarrasment?
Are you going to risk going to jail and being on the sex offenders register for life because you followed a QR code?
I... erm... what?
I'm not sure that's how the law works; you don't accidentally follow a link and go straight to paedo jail?
In the unlikely event the above situation ever happens to you, close the browser, then take a picture of the screen as evidence. (Quickly mind, the rozzers are probably already on their way...)
But that's pretty batshit. I accept the tiny paranoid window where you pop a zero day on the persons phone when you dump the crash screen on their workstation, but literally just making it easier for the user to save them typing something in. Which is to say the risk already exists if the user tries to look up the error code. They are more likely to end up on a shady site from google/bing/etc now than a deep link.
Though it does raise the prospect of the really easy gag of firing a full screen modal graphic from a web page that LOOKS like a terminal crash.
Of course your mark probably wouldn't go to it _voluntarily_, or click past the warning windows from the browser going full screen, but so many things can happen when you leave your screen unlocked.
> Are you going to risk going to jail and being on the sex offenders register for life because you followed a QR code?
Do you block inline loading in your web-browser? Do you browse the internet with no images, or CSS?
Please, tell me how you block a page from doing:
<img src="https://some.dodgy.site/" height=0 width=0>
No response to say I'm wrong, no comeback at all, just downvotes.
Like MAGA, some of you extreme showflakes get offended simply by facts being repeated, just because you don't like them.
I suppose you also get annoyed at the weatherman when he says it's going to rain, because you don't like rain. Or, of course, if anyone dares to mention when Musks or Trumps company shares go down in value.. HOW DARE anyone point out a negative about His Muskiness, or King Trumper.
For there to be a crime, one has to prove the suspect has actually viewed illegal images. As these arguments demonstrate, the mere existence of said images in a browser cache is not a guarantee they have actually been viewed by the person using it. Since criminal law is based upon the standard of “beyond a reasonable doubt” and the height=8 width=8 (let’s assume 0x0 and 1x1 is blocked) obvious example casts huge amounts of doubt upon browser cache evidence as being anything more than circumstantial at best, there would have to be further evidence that implicates the suspect. Even if the only images to be cached by a browser were those which had actually been seen by someone, that still does not prove it was the suspect who viewed said images, it would only prove someone who was using their computer at the time viewed them, which is also circumstantial at best.
When it comes to the whole QR code generator side of things, they’re safe because funny enough, the apps which interpret them show the user the URL and offer them a chance to back out before loading it to defend against trickery. In the case of systemd, however, the situation is even safer because it does not actually generate a URL in the first place, but instead text which can be copied/pasted into a search engine, and a trained sysadmin debugging issues on behalf of an untrained end user is going to know that. But let’s assume they didn’t, what’s to stop someone who has so thoroughly rooted the system from doing whatever they want anyway, and just adding the functionality you’re complaining about, tricking the user that way instead?
I can see the reason behind systemd to streamline boot up. But I have to remember the original mantra of "do one thing and do it well". Systemd seems to have become a tentacular monster and a poorly documented, non-deterministic one as well. At least with System V initscripts I can follow what happens and when without having to reference a gazzillion man pages for each type of /*/systemd/system/* file.
Which came first: the RAM or the code?
Systemd belongs to a generation who see lots of RAM (and memory in general) as space to be filled—however pointlessly.
Why write ten lines of code when there's room for a thousand, and the pay to go with it?
Then, of course, there's that priestly caste to protect that special voodoo needed to keep the whole shambling monster upright and moving. Mind you, the 'priestly caste' schtick is as old as coding.
What's worse is shutdown. By default (and it takes a deal of messing about to stop it) systemd stops things that take longer than 10 seconds to exit on a power-off. You have to enable a longer global time-out limit, as well as set the time-out for the particular service to force systemd to let a slow-to-exit service complete correctly.
Lost too much data to that one.
"with System V initscripts I can follow what happens"
You can even run them on the terminal to debug them with single stepping. Or you can insert some logging commands to see what's happening when run for real.
I spent a very long time trying to debug video on a MythTV box running Upstart because I couldn't work out how to monitor what was happening. It turned out that the TV was lying about its video resolution reporting itself as having the screen of a PDA. Then along came systemd like Upstart on steroids.
[Author here]
> the single user/multi user booting distinctions will be going away.
Hoenstly, this is one thing I'm in favour of.
The Unix filesystem hierarchy wasn't designed: it just happened as it grew. `/usr/` means "users" and home directories lived there 'til they ran out of disk space.
Taking the pruning shears to it is a great idea and long overdue.
We do not need those historical splits any more.
Separate /home and swap have strong justifications and have saved my bacon. The rest can go.
Bear in mind that a vast number of Unix deployments today have a lifetime in seconds to minutes before erasure, that the primary enterprise distro didn't support major version to version upgrades *at all* until recently, and that most user-facing stuff with a UI is on battery-powered pocket devices.
It's not like the old days any more.
It was the "let's move everything into /usr" instead of "let's use the opportunity to clear out all the crap that shouldn't even ended up there in the first place and only ever did because there was nowhere else to put it", forcing actual users to go to /mnt, /home or various others depending on the era, the alignment of the planets and the sticky buns in the cafeteria and so on. My reaction to it has always been "yeah, I appreciate maybe it is a good time to tidy things up" but this was basically the opposite of what I'd hoped for and seems an ugly kludge. I have / and /usr on the same dataset anyway and /local (actually mounted on /usr/local) for all the 3rd-party stuff, though others prefer /opt for stuff like that. And apart from /work, everything else goes under /rec(reation) which I couldn't think of a better name for: music, videos, games modding, photos etc. Actually video gets its own pool because it's so lardy-arsed.
And swap gets its own GPT partitions. Well actually a pair of mirrors, similarly EFI is mirrored across all the drives. I've always felt a bit "hmm" about using different partitions like that and just kinda hoped the GPart suite can figure it out having heard various probably long-fixed problems with having swap on a ZFS file or dataset, but it seems to work pretty well.
Anyway, I've digressed because I'm outrageously tired; the idea of putting everything from e.g. /bin into /usr/bin and then symbolically linking them just seems so arse about tit to me. I can only assume Poettering's hand in that too as most of his decisions seem to be based on annoying as many people as possible.
It all started going downhill when people changed /u back to /usr ... Us lazy bastards at Berkeley had changed AT&T's /usr to /u in the name of typing brevity, but apparently it made things hard to understand for newbies (I personally never met a newbie who made that claim. I suspect it was actually a professor outside the computer group who had "issues" ... ).
/u (or /usr) always had non-home directories, user supplied packages, common stuff we were working on & other stuff in it ... Source code, documentation, the man pages, user installed binaries available to everybody, and other useful tat like vi, EMACS, UUCP and later the BSD games pack.
It was both useful and logical to split it into /usr and /user when the system grew large enough, and had many users. Then some bright spark decided that /usr and /user was too complicated due to their similarity, and thus /user became /home ... except in the appleverse, where they "simplified" it to /Users (Caps in a system directory name? WTF‽‽‽).
/Users came to Apple from NeXT. The distinction mattered there, but is moot on Macs because Apple’s filesystems are case-preserving, but case insensitive. This is because they treat the directory entries as text (with a filesystem-defined encoding), rather than a sequence of bytes (with encoding left as a matter for client libraries to impose). Actually, Apple goes further (or used to), and decomposes filename text to a canonical form so that you don’t go insane when files are created using inconsistent combinations of pre-composed characters and combining accents, as here:
$ ls
bómánta bómánta bómánta bómánta
(you’ll have to use hexdump to see which of these is which)
"We do not need those historical splits any more."
Unless we want to take advantage of mounting certain parts of the file system read only. Or have to manage mounts from SAN systems, NFS, DBMS partitions or large file partitions in data center operations. I certainly don't need that for my laptop. But that isn't to say that some larger systems don't.
I find it odd that an outfit like RedHat would get behind this, given their user base. Or maybe not. Strip all the flexibility out of the Fedora consumer level distro and upsell the data center people the version which keeps all the options available.
"But that isn't to say that some larger systems don't."
Fortunately, we still have options that don't require the systemd-cancer.
"I find it odd that an outfit like RedHat would get behind this"
Think about it by asking yourself who they are trying to take market-share from, and then compare and contrast that company's way of doing things with RedHat's otherwise non-intuitive changes to the way experts have been using computers for decades. It's not about making things better, rather it's all about locking suckers into their way of doing things.
I've found a separate /var partition to be useful in the past, at least on servers. I like to have noexec on it, though at least in the past some Linux distros fail to install and needs to be added afterwards.
I've also used a separate /usr partition in the past (FeedBSD system IIRC) resulting in a small and almost unchanging / partition.
Having system binaries in /bin and /sbin is useful in this case, just in case the /usr partition is borked.
An init system attempting to dictate the location of system binaries is simple meglomania.
A separate /var is useful, and I set it up to reformat at install time - I've seen an install messed up because there was prior content there. Of course this is a bit of an issue if the distro puts web server data and/or database data there. They should be in /srv and symlinked back to /var in case the system expects them to be there.
> separate /var
Echo this. My "standard" (such as it is) for years has been /, swap, /var/, /tmp/ (either disk or mem filesystem), with /home/ and other large application-y things often on their own device altogether, if not a separate partition.
A basic idea behind it: users and potential user activity (logs and temp files and whatnot) shouldn't affect system diskspace in / (or / & /usr/ if you really prefer).
I grew up with several commercial Unixes in the 80's-90's where / & /usr/ were typically separate, and often the default scheme you got if you didn't re-install or customize. So "The Split" was normal to me for a long time, but part of that was because the aforementioned application-y things often camped in /usr/ and we wanted to avoid the possibility of filling up /.
Our response wasn't to make /usr/ bigger, but instead to move users, DB's, web, etc. to their own storage. So merging The Split was pretty close to a non-event for us, and I've stuck with it ever since.
We have only been working on Linux FHS through versions 1, 2 (2004), and 3 (2015) for the past what? 20 years? and have little to show for it providing a consistent environment for applications to use cross-distro. I don't dislike the /usr merge just as I don't dislike packages and libraries and executables and data spread across /lib, /lib64, /usr/lib, /usr/lib64, /bin, /sbin, /usr/bin, /usr/sbin, etc...
I see benefits, but I think we should be clear-eyed about what is driving the mandate for consistency now being foisted upon the community by systemd. It has nothing to do with FOSS choice or allowing distributions the freedom to do things in their own way, it is more about the desire to have a vanilla-Linux-landscape that guarantees containers will run without a hodge-podge of compose routines. Whether it is Linux FHS or a /usr merge, once the corporate "sponsor"-camel has it's nose under the tent of open-source -- they will want to see a return with fewer resources expended in the long run. That's not all a bad thing.
As far as display changes, I'd rather the the kernel-panic and the register-dump than a BSOD and WTF? a QR Code? that I'll never use. (just trust us, use your phone to scan the square of information you can't understand and we promise we won't grab and store any of your information that gets sent along with the request to turn it into a URL -- we really, really promise this time... trust us). But this is largely a who cares? part of systemd. So long as I can hist ESC and see the reason the boot failed without having to jack with a QR code, it's not worth worrying about. Now if I can't look behind the BSOD and get the same information I could before -- that's a problem, and a bug report will follow...
But, on balance, at least for normal small-server / desktop use, the move to systemd 255 is a big "Meh". Arch moved to it this past week. The update and reboot (due to Linux 6.6.5) was a non-event, no BSOD, just an underwhelming reboot to have 0x11111111 do the same thing it did when it was just 0x11111110...
If there’s one thing that techies love to engage in, it’s holy wars.
“systemd knew its audience. It provided a free and maintained service that was better and more modern than its predecessors. This made it a no-brainer for many Linux distributions to make the switch.”
''remembering the times people told him GUIs were "bloat" in the 1980s.''
Or another attack surface in 2001. It was the web management option of NT servers that allowed the Code Red virus to bring our companies data center operations to its knees. Given the option to manage these servers using the old fashioned command line options or "use our cool new web-based tool", many admins (and I use that term loosely) chose the latter. Not understanding that this would quietly start IIS in the background. Not knowing that this had happened, security updates for the web services were never applied. (It's not a web server. It's a file server/dbms server.) And then the virus hit all those unpatched systems.
I don't know how many layers of extra stuff I need to keep up to date just to keep the junior PFY admins happy with their GUI management tools. But it's not a trivial amount.
"One person's bloat is another person's "easier to use"."
In this particular example, the first person is an experienced systems administrator, while the second is anything but.
"And it was ever thus, he said, remembering the times people told him GUIs were "bloat" in the 1980s."
In the 1980s, when even Mainframes often only had 2 megs of Core (or less!), GUIs WERE bloat.
Even today, the experienced sysadmin armed with a CLI can run rings around someone requiring a GUI to administrate a system.
> ... “systemd knew its audience. It provided a free and maintained service that was better and more modern than its predecessors. This made it a no-brainer for many Linux distributions to make the switch.”
But it isn't maintained, it's forever having cruft added, perhaps becuase that's easier than writing good (or even adequate) documentation. It is more modern, but better? No evidence for that, I think. A no brainer indeed, if we're discussing the author ("designer"? No evidence for that either).
where a phone, camera etc are just not permitted on pain of serious ... ah ... pain.
So popping up a QR image is pretty bloody useless.
I would like to believe such high security environments don't run this shite but I am pretty certain that is just my naivety or wishful thinking.
I can imagine an irate BOFH filling in squares on a sheet of graph paper to copy the QR code in order to take the code to a less secure area to access the URL if they can get it past the gorillas with guns.
Hiding the gory details of the boot process with some pointless eye candy was the slippery slope. Any punter that actually installs a Linux distro is already up for an education so why obscure the boot process? With a bit of skulduggery in Windows you can see the same sort of output during a Windows boot - quite educational.
Honestly, a QR code that simply duplicates the text is a good thing.
The fatal bug reports we get either have no information at all, a hastily written down failure code, or a fuzzy photo of the screen.
The first, we can do nothing if the machine wasn't able to store it.
The second often contains typops.
The fuzzy photo is often unreadable, but a QR code could likely be deciphered.
As long as it simply duplicates the text. If there's anything different then it is indeed worse than useless.
If the QR code simply duplicates the text, Shirley simply putting the text in a consistent, known, local place where any cognizant sysadmin can find and read it would make more sense than intentionally obscuring it, and then hiding it off-campus somewhere?
Call me a rebel, but perhaps a logfile in plain-text in a specific, known local directory would be a better idea all around?
No, a true BOFH would make sure ALL error messages appearing on screens would be QR images and then supply graph paper for people to report errors to him (refusing to accept any other kind - photos of said screen being automatically rejected). But, of course, the QR code on screen would have some subtle code running behind it so that it would flip the occasional square at random intervals making sure that the pattern copied by the user would never match the one on the screen, thus rendering all the error codes invalid due to, ahem, "user copying error".
Whether merging /usr/bin /usr/sbin with their /bin /sbin counterparts is a different discussion.
The linked message showing the historical reasoning is irrelevant - it's whether there's a good use for it *NOW* that matters.
But anyway, different argument.
However, whether you agree with this or not, this is **NOT** something that systemd has any business mandating.
Every release, the roots bury deeper, and the many frogs on the stove with the heat slowly rising don't seem to realise or care.
this is **NOT** something that systemd has any business mandating.
Part of me wonders if there's a Bloody-Stupid-Johnson type thing going on here, where patrons keep funding Poettering out of morbid fascination as to what he'll screw up next.
Systemd 258: now controls mouse cursor management & appearance
Systemd 265: contains the necessary graphics drivers for your desktop. But only for the GPUs that Poettering runs in his personal systems. All others are, by definition, unnecessary. #WONTFIX.
Systemd 280: Now includes the system firmware layer. Will only boot during Poettering's office hours.
Systemd 281: All system directories and files now merged into a single binary blob named PAGEFILE.SYS. "Vastly simplifies my workflow" says Poettering.
I couldn't decide which icon was appropriate - so many to choose from. Fail? Trollface? Facepalm?
Went for Beer in the end because alcohol is an appropriate response to this idiocy. Cheers.
"Part of me wonders if there's a Bloody-Stupid-Johnson type thing going on here, where patrons keep funding Poettering out of morbid fascination as to what he'll screw up next."
Remember who employs him and worry about
Systemd 365: It is a single binary blob. Everything else is eliminated and the entire system is now a thin client to run application in Microsoft's cloud. Google & AWS are complaining to the regulators and working on reverse engineering so they can fork it.
Adopting a BSOD is simply amusing. Dictating filesystem structure of the underlying OS?!? What next? Will we have to look for hosts in some subfolder under Systemd/WINDOWS/SYSTEM32/ since they will no longer be called directories?
What frustrates me the most about systemd is application dependency - real or imagined. You have apps checking for systemd on way or another during install or execution, but not truly needing systemd to execute. Then there are apps which become snap package only. There are people out there spending time on making snap packages work without the snap system and without systemd. Build from source you say? The source build environments have become equally bloated and convoluted. Rube Goldberg would be proud.
I installed Slackware to get away from systemd. Not quite. I looked into Linux from scratch, that project has also been infected. I have even heard of forking systemd to BSD and MAC worlds. Incredible! It is even worse than I thought.
OK, This post is talking generally, I'm not applying each point to EVERY Linux user. etc.
The BSD's won't touch it with a bargepole.
One of the major differences always between the BSD and linux-gnu philosphies, is that with BSD's, the traditional unix way of doing things is preserved, unless there's a good reason not to (BSD developers aren't bloody minded, and are pragmatic)
Linux fans always used to call for programs to be portable, but they are quiet these days now that linuxism-lockin is affecting everything.
Sound driver not working? Write another one! To show how portable we are, we will put "Linux" in the title!
devd ? udev? Whatever is flavour of the month.
The whole linux thing (and I'm talking about userland etc. NOT Linus or the kernel or the other kernel developers) has been about sticking it to microsoft, not how to get a better Unix.
BSD's are maintained by UNIX engineers.
Linux folk have always been simply anti-Microsoft, which is ironic considering who Pottering works for, but no big deal, they are getting distracted by the new shiny shiny way of doing something else, whether its audio, video, or any other random piece of code that someone wants to wriite a new API for for everyone to use, because in their eyes, it's obviously much better than the one before.
Thank heavens it's not like the old days anymore, if it was I'd still be faffing about with Windows. I fail to share this hating on systemd, it just works, and the number of times I've had to fight with a conf file or whatever lately has shrunk to zero. Now if I could just get Bitwig to play nice with Jack and Pulse and Midi...
Whenever systemd is mentioned it seems like only people who passionately dislike it comment on the topic. This is of course, not factual. Most distros use systemd because it is objectively better, and most users like the simplicity and minimalism of its commands. But the people who dislike it always scream so loudly that more rational and moderate voices cannot be heard over the din. (This is much the same as the Haskell community, the X.org apologists, and other fanboi/hype-train/bandwagon groups.)
"Most distros use systemd because it is objectively better, and most users like the simplicity and minimalism of its commands."
Bollocks. "Objective"? Hardly. "Subjective" at best. Citation needed, at minimum. But if it's sweeping generalizations you're after....
Most distros use systemd because Red Had pushed it (pinched it off) into the world. For better or worse, Red Hat largely still determines where most mainstream Linux direction goes. Some of us hope that is becoming less true than it has historically been.
Most users are either unaware of systemD (e.g. they're predominantly GUI users and likely not admins), have gotten used to it (grudgingly or otherwise), or they've never known a world where systemD hadn't already infested the common Linux distros.
Where you got "simplicity" and "minimalism" wrt systemd is beyond me.
"Most distros use systemd because it is objectively better,"
Only two major distros use the systemd-cancer: RedHat and Debian.
Red Hat implemented it to make their Linux Distribution more Windows-like, which should be a red flag to anyone with a clue. Debian followed along for internal political reasons, the tech involved had nothing to do with its implementation in the Debian space. Another red flag. Most of the rest followed on blindly through ignorance and/or apathy, with a pinch of sheer laziness, because, and only because, they use one of those two distro's repositories and so had to (or start to think for themselves, which is unthinkable, of course).
In no example that I can find did a distribution choose the systemd-cancer because it is demonstrably a technologically better system. Not one.
Think about that for a minute, and then ask yourself "Have I been had?".
[Author here]
Turn the paranoia dial down, Jake. You are frothing at the mouth again. Please don't.
> Only two major distros
Not true. In fact many many more distros use systemd than do not use systemd.
About 25 do not:
https://nosystemd.org/
There are 500-600 actively maintained distros:
https://linuxopsys.com/topics/linux-distribution-list
https://en.wikipedia.org/wiki/List_of_Linux_distributions
From this we can conclude that somewhere around 475 distros do use it.
In other words about 19 times as many use it as don't. Or, alternatively, some 95% of distros use it.
> the systemd-cancer
Drop the Ballmer bollocks, will you?
> Red Hat implemented it to make their Linux Distribution more Windows-like
{{citation needed}}
If you mean "to make their distro into an enterprise tool worth tens of billions" then yes, but is that a bad thing?
> Most of the rest followed on blindly
{{citation needed}}
Remember Hanlon's Razor.
> demonstrably a technologically better system
Please provide a universally-acceptable, uncontroversial definition of "better".
If you can't, then stop posting FUD.
Hint: you can't.
Look, I don't particularly like it. I don't really want it. I like the faster boot times, but I hate the fragility. I don't give a monkey's about writing startup units because I don't do that.
But it mostly works, and it seems to make sysadmins' lives easier.
Meanwhile, I tried Debian head-to-head with Devuan and Debian is good and getting better while Devuan gets worse and more complicated with each release.
Once Debian went it was always going to be followed by most of the distros that are based on it (except for a few deliberate standouts such as Devuan). Chief among the distros that follow it directly is Ubuntu and that then dragged in all those that follow Ubuntu such as Mint.
I'm not sure why you would find Devuan more difficult than Debian. IME it Just Works as you'd expect Debian to do (if we draw a veil over linux-image-6.1.014 and Debian 12.3).
"Turn the paranoia dial down, Jake. You are frothing at the mouth again. Please don't."
It's paranoid to discuss what I've seen with my own eyes? OK. I guess ... Note that I'm not frothing, at all. In fact, I'm not even remotely emotional about all this, just voicing an opinion based on long experience.
My round, I think. Have a beer.
"Not true. In fact many many more distros use systemd than do not use systemd."
Did you see where I said "major"? Most of the other distros are just repackaged versions of the two I mentioned. (Frankly, I'm surprised nobody called me on not including SUSE with the other two ... I guess I'm not the only one who doesn't consider it a major player anymore. Sad, that.)
"Drop the Ballmer bollocks, will you?"
How is the systemd-cancer not a cancer? It takes root in its host, eats massive quantities of resources as it grows, spreads unchecked into areas unrelated to the initial infection, and refuses to die unless physically removed from the system, all the while doing absolutely nothing of benefit to the host.
"then yes, but is that a bad thing?"
It is if you see the mess that it is emulating for what it is ... a mess that has set back computing about 30 years. Maybe 40. Consider that these days, the Mythical Corporate Computer Operating System is supposed to contain shoddy code, it's supposed to not be secure, it's supposed to break at the least convenient time, it will crash at random, updates will make things worse, over time it gets bigger and worse, if you turn it off and back on again it might fix it (maybe; try it again), and retraining people in it's use is an ongoing expense ... these are all enshrined in the corporate mindset thanks to Microsoft. This is NOT a good project to emulate. And yet here we are.
"Remember Hanlon's Razor."
As I said "Most of the rest followed on blindly through ignorance and/or apathy, with a pinch of sheer laziness, because, and only because, they use one of those two distro's repositories and so had to (or start to think for themselves, which is unthinkable, of course)."
"Please provide a universally-acceptable, uncontroversial definition of "better"."
I pulled that word specifically from Dostoevsky's post, above. During the meanwhile, I'm pretty certain that everybody reading this thread understands exactly what I meant, in the context of the thread. Or are we switching to debating the meaning of meaning?
"Hint: you can't."
Rather, I don't see a need to do so. What I wrote was clear enough for my intended readers.
"But it mostly works, and it seems to make sysadmins' lives easier."
This particular init's definition of "mostly" isn't good enough for me, nor any other veteran sysadmin I've ever talked to face to face in the wild. (Note that I'm resisting asking you to define "seems" and "easier". It's not germane to the conversation.)
"Meanwhile, I tried Debian head-to-head with Devuan and Debian is good and getting better while Devuan gets worse and more complicated with each release."
Use whatever suits you (or your boss). No skin off my teeth. I use neither. Slackware on the desktops, and BSD on the servers & most Internet-facing kit have been working for me in almost all situations for over 25 years.
More!= Better
McDonalds has more restaurants than my local Thai. But I know which one I'd prefer.
Toyota sells more cars than Rolls-Royce, but I know which one I'd like as my daily commute.
Of course, "Better" is always relative. Is Maccas faster to serve its slop - sure. Can I purchase a Toyota at a reasonable price ... sure.
If systemD could address
1 - Legitimate use cases with are simply ignored with #WONTFIX
2 - Unable to pick and choose some tools that might offer superior functionality
3 - Binary logging
4 - Non-determinism
we might have a starter.
Slackware and Duvian for me.
There are still people who refer to systemd as an "init system". Why should an init system give a flying fig about the directory structure its OS is using? Actually, why should anything care about the underlying directory structure? A distro which perversely renamed or restructured the entire heirarchy would still be Linux.
(I have no strong opinions on /bin vs /usr/bin etc. My latest fresh Devuan install left them separate.)
In a tech interview I did once, I was asked the question “What is systemd?”
It turned out later that the question was irrelevant for the work - I can’t even remember if we had a systemd-equipped distro on the hardware. What really mattered was the candidate’s reaction to being asked. Anyone taking a very strong position on the matter was immediately docked points. Once employed, I later interviewed one candidate who very much nailed their coffin shut with a long rant in response to this very question, so it definitely had value as an interviewing tool. That person was already an unlikely due to other weaknesses on the simple programming element, but this sealed the deal.
I think the thing that riles me the most about this debacle is that it denies a majority of newcomers to Linux the simplicity and flexibility that impressed me so much when I myself made the switch. Coming from a lifetime of Windows* the underlying design principles of UNIX (and by extension, Linux) made a great impression on me. I know I don't need to repeat them here, but SystemD somehow manages to ignore and/or violate every single one. Binary log files. The endless feature creep. Locked in dependencies. Inscrutability. Unpredictability. Elimination of choice. That's far from all its issues, but we haven't got all day.
I readily agree that most newcomers will happily use whatever they've been given, whether it's from RedHat or Canonical (or one of their many flavours), and under typical use may never need to look under the hood very deeply - but if they do they won't find the same simplicity and flexibilty that so impressed me, just the big convoluted mess of wires that is SystemD. And they will never know that things could have been different. It's hyperbole, I'm sure some would say, but I honestly feel that SystemD has done more to damage Linux than all Redmond's underhand efforts of doing so put together. And short of some major player (RPi Foundation?) realising just how corrosive SystemD is I have little hope that anything will change. Many of us greybeards will continue to choose differently of course, but we won't be around forever. I for one will continue to speak up against SystemD until I draw my last breath - because I find it unacceptable and abhorrent. Brrrr. Thank you.
*) ok, so my first computer was a Sinclair, and then I had an Atari, an Amiga, and a DOS only 286 - and I've also mucked around with 68k Macs - so I do have experience of other systems. But yeah, all serious work I had done before moving to Linux was under Windows; 3, 3.1, 3.11, NT, 95, 98, 2000, XP, 7, 8 - and there they lost me.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
