●Stories
●Firehose
●All
●Popular
●Polls
●Software
●Thought Leadership
Submit
●
Login
●or
●
Sign up
●Topics:
●Devices
●Build
●Entertainment
●Technology
●Open Source
●Science
●YRO
●Follow us:
●RSS
●Facebook
●LinkedIn
●Twitter
●
Youtube
●
Mastodon
●Bluesky
Follow Slashdot blog updates by subscribing to our blog RSS feed
Forgot your password?
Close
Post
Load All Comments
Full
Abbreviated
Hidden
/Sea
Score:
5
4
3
2
1
0
-1
More
| Reply
Login
Forgot your password?
Close
Close
Log In/Create an Account
●
All
●
Insightful
●
Informative
●
Interesting
●
Funny
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
bydrinkypoo ( 153816 ) writes:
Poettering will also continue to remain deeply involved in the systemd ecosystem.
I therefore trust that it will continue to be shit.
bytwinirondrives ( 10502753 ) writes:
for people hacking together their own systems I'd admit that systemd does nothing for that. But organizational level mass deployed systems are pretty much barred from linux without something filling that role. then I think systemd was an idea put forward around the same time io_uring was which maybe possibly was the beginning of a compliant solution filling the systemd role. my opinion is io_uring actually increased the attack surface of linux systems. would that have been different if systemd never existe
byShaitan ( 22585 ) writes:
Overrated. Prior to systemd Linux administrators famously admin'd thousands of systems vs tens in the windows world. That text/file/directory-based system combined with all the text-mangling power tools in linux, the shell, and perl... nothing compares.
It actually becomes much easier to work with configuration management tools when they are managing the state of text files as the Linux gods intended.
bydskoll ( 99328 ) writes:
Systemd units are plain text files, you know.
I honestly don't understand the visceral hate for systemd. I've been using UNIX since 1989 and Linux since 1994, so I have plenty of experience with old ways of doing things.
Systemd, at least in my experience, just works and writing systemd unit files is easier than writing sysvinit scripts. So when Debian switched to it, it was fine. I adapted.
Reply to This Parent
twitter
facebook
Flag as Inappropriate
bydrinkypoo ( 153816 ) writes:
I honestly don't understand the visceral hate for systemd.
It is the antithesis of the Unix way. This has been argued back and forth all along, and if you don't agree I won't try to convince you here.
Systemd, at least in my experience, just works and writing systemd unit files is easier than writing sysvinit scripts. So when Debian switched to it, it was fine. I adapted.
The problem with systemd and unit scripts is that they cannot do all the things that a script can do, so you often wind up using a script anyway. In that case you have really not made things any simpler than the usual case. Meanwhile you've added a whole lot of complexity which is largely unnecessary, some of which is utterly dependent on other parts so it is difficult
bydskoll ( 99328 ) writes:
Appealing to "the UNIX way" is just silly. UNIX has been around for over 50 years, and it evolves as people figure out better ways to do things.
The problem with systemd and unit scripts is that they cannot do all the things that a script can do, so you often wind up using a script anyway.
I would say: very rarely, not often. Looking at the units on my machine, none of them uses an auxiliary script to start or stop a service.
byArchieBunker ( 132337 ) writes:
What was the point of the journal log system? We had stable tools for decades for manipulating and managing text logs. So systemd made the logs binary and then re-invented all the same tools but slightly different. Same as with ifconfig. Worked great for decades and now it’s replaced with “ip” and a different syntax. What was gained?
Reply to This Parent
twitter
facebook
Flag as Inappropriate
bydskoll ( 99328 ) writes:
I agree with you about the binary logging. Not everything about systemd is better than what came before, but also, not everything is worse.
You can still have plain-text logging and AFAIK Debian still generates the normal plain-text log files by default.
I also get annoyed with ifconfig and ip, and iwconfig vs iw, etc. but AFAIK those are not Poettering's doing and are not related to systemd.
BTW, I think the reason for ip instead of ifconfig and route was to add support for different routing tables, wh
bytender-matser ( 938909 ) writes:
There are many things that aren't supported by ifconfig/iwconfig besides different routing tables (first which comes to mind is adding multiple addresses to the same interface).
It all comes down to how they communicate with the kernel -- ifconfig is using ioctls on a socket file descriptor, while ip & co are using netlink sockets. The ioctl interface is quite limited, and was not extended as new features were added to the kernel.
They could've adapted the old net-tools to use netlink behind the scenes wh
bydrinkypoo ( 153816 ) writes:
first which comes to mind is adding multiple addresses to the same interface
At the time that was done with interface aliases. ifconfig eth0:1 blah blah blah
bydrinkypoo ( 153816 ) writes:
You can still have plain-text logging
It's a second-class citizen. Those log messages are passed on to the real log daemon by systemd. If it fails to do that properly, which is often true in the early phases of the process, then log messages don't always make it.
The correct way to do what they did there would have been to add logging to an existing syslogd. It would have been a lot less work, too. Instead they felt they had to add their own incompatible solution instead. That's the biggest thing wrong with systemd in a nutshell.
byBig Hairy Gorilla ( 9839972 ) writes:
What is gained, isn't for you silly. It's there to create vendor lock in.
Write all your code to be dependent on Systemd and you'll never go anywhere, because it is too expensive to even considering changing. Could I rent you a few consultants? says IBM.
Redhat, the Microsoft of Linux.
bydskoll ( 99328 ) writes:
When every Linux distro that matters is using systemd, it's not much of a lock-in.
And guess what? I distribute email-filtering software that runs on a wide variety of UNIX systems. I include sysvinit scripts for systems that use that, and systemd units for ones that use systemd. There's no lock-in.
byBig Hairy Gorilla ( 9839972 ) writes:
Thanks for the categorically broad statements of your opinion stated as a fact.
"Every distro that matters?"
Sooo. Ubuntu and Redhat?
Vendor lock in is assured if you put critical systems on them. BECAUSE of proprietary extensions, of which, systemd could be considered one of them.
The old IBM/Microsoft playbook embrace, extend, extinguish.
Jesus, I wrote COBOL programs for the Treasury Board, here in capital city, about 100 years ago with IBM Report Writer. They paid thru the nose for the license, and as a gree
byBlueLightning ( 442320 ) writes:
Vendor lock-in, to just about any vendor you could choose? You don't even need a vendor at all if you don't want one - just use Debian, or Fedora, or...
●our current threshold.
byShaitan ( 22585 ) writes:
"Appealing to "the UNIX way" is just silly"
No, it's the Unix philosophy of small purpose built tools combined rather than large monolithic integrated solutions and that never changes. But you tipped your hand, you began as a proprietary unix guy and they use monolithic systemd-like chunks all over the place.
"it evolves as people figure out better ways"
The philosophy doesn't, the tools do, but systemd doesn't bring better ways to do things just one built with Microsoft's big monolithic one size fits all phil
bydskoll ( 99328 ) writes:
I never began as a "proprietary UNIX guy" for two reasons; one is that I'm not a guy and second is I used SunOS and Solaris mostly as a student and a little bit on the job, and this was back in the day before SMF, etc. when the system was much more BSD-like.
The problem with appealing to "the UNIX way" is that nobody really knows what that is, beyond a few vague generalities. Systemd itself is not one monolithic program, by the way. It consists of 38 small purpose-built executables (on Debian 13, anyway)
byShaitan ( 22585 ) writes:
"I never began as a "proprietary UNIX guy" for two reasons; one is that I'm not a guy"
Everyone is a "guy" dude. You aren't special man.
"The problem with appealing to "the UNIX way" is that nobody really knows what that is, beyond a few vague generalities."
It's a general concept.
"It consists of 38 small purpose-built executables"
All of which are part of ONE monolithic solution to many unrelated problems. Exchange/Outlook/Office consists of many executables and yet is literally the most famous Microsoft monol
bydskoll ( 99328 ) writes:
Everyone is a "guy" dude. You aren't special man.
In case it's not obvious, about 50% of people are not "guys". I guess sysvinit folks are not great at seeing cases outside their own experience. :)
Change just for the sake of change isn't a good thing.
Yes, I agree. However, on balance, I think systemd (or something like it) isa good change for a number of reasons I've outlined in other posts:
1. Easy ability to do dependency management.
2. Ability to start services in parallel (which flows from 1)
bytender-matser ( 938909 ) writes:
Remove the necessity for every service to write its own daemonization code;
That's a total non-issue. The entire "daemonization code" is just 2 syscalls: fork(2) + setsid(2) and using syslog(3) instead of stderr for printing error messages.
Other stuff like redirecting stdin/out/err to /dev/null or chdir / is usually more trouble than it's worth (for instance, I'm always redirecting the std fds from a non-connected socket instead of /dev/null -- in order to have accidental read/write FAIL instead of silently succeeding and hiding real issues with the code).
Adapting to the canned "solutions" offered by systemd / daemontools / whatever is instead much more complicated and more limiting in what you can do. All that without any benefit (besides better fitting into someone else's worldview and OCD fixations).
Reply to This Parent
twitter
facebook
Flag as Inappropriate
bydskoll ( 99328 ) writes:
OK, so you disagree with my point 3. How about the other 5 points?
bydrinkypoo ( 153816 ) writes:
1. Easy ability to do dependency management.
Debian has a script or script library I believe originally from the lsb which does this easily from some boilerplate at the top of the init script. That's how update-rc.d works, but it's also used to make init scripts require that other scripts have started successfully.
2. Ability to start services in parallel (which flows from 1).
startpar
3. Remove the necessity for every service to write its own daemonization code; you can just let systemd do it for you.
daemontools, inetd...
4. Standard way to run services as a non-root user
Funny thing about standards.
5. Standard way to use newer Linux features like cgroups and namespaces.
There already were standard ways to do this in the shell, and therefore in init scripts. They are even already used.
6. Standard commands for monitoring and controlling the status of a service.
That's always been a part of init scripts.
All of those things can be (and probably have been) implemented in sysvinit environments, but usually as hacks.
All of those things are av
byBarsteward ( 969998 ) writes:
You'll never get this anti-systemd mob to change their minds, you can still see after all this time they think all the small purpose optional executables are mandatory and the nonsense of "monolith" (linux itself is a monolith and they don't mind that). It works well for large organisations, i'd guess they just don't want to learn new tricks and think the old way makes them elitist techies and hopefully keeps them in a job.
byShaitan ( 22585 ) writes:
You: "you often wind up using a script anyway. In that case you have really not made things any simpler than the usual case. Meanwhile you've added a whole lot of complexity which is largely unnecessary"
Him: "Systemd, at least in my experience, just works and writing systemd unit files is easier... I would say: very rarely, not often."
If this isn't a constant repeat of Unix philosophy clashes with Microsoft monolithic one-size-fits-all solution then I don't know what is. Yes it is easier to walk up and conf
bydskoll ( 99328 ) writes:
But you are not making sense. (And it's "Her", by the way, not "Him".)
As the person I replied to pointed out, if systemd doesn't quite do what you need, you can always fall back on a script. So the common use cases are easy and the uncommon ones are possible.
Now I personally have not encountered a use case that systemd couldn't handle natively, but I'm willing to admit that such use cases exist, in which case... you use a script that you call from a systemd unit. Problem solved.
bydskoll ( 99328 ) writes:
OMG, lookit the triggered snowflake! LOL. A whole paragraph to whine about a simple two-letter spelling correction.
byBarsteward ( 969998 ) writes:
Misogynist alert !!!
●th your current threshold.
byArrogant-Bastard ( 141720 ) writes:
A friendly amendment, if I might: it's the Unix way yes, but more important than that: it's the Software Tools way.
I capitalized that because it's a book title, and it's absolutely mandatory reading for everyone in this discussion and anyone developing software. It's such an important work that I make a point of re-reading it every year -- and each time, I learn something new.
But if I were to have the temerity to attempt to summarize it in one sentence, it would be this: a software tool should do one thing, and do it well. This approach drove the development of Unix, and Unix in turn was largely responsible for the development of the ARPAnet, CSnet, and Usenet. (Which I know because I was there for all of it.) And obviously Linux would never have existed without Unix.
If you understand this philosophy, then you understand immediately why systemd not only can be, but must be, summarily rejected. It's obvious on inspection. If you don't understand this philosophy, then you need to do the reading -- until you do.
Let me point something else out: do you think we -- the people who've been working in this field for many decades -- didn't consider the idea of something like systemd? In fact; we did. But because we have seasoned judgment and experience -- we're not mere ignorant newbies like Poettering -- and because we have the humility to recognize that Thompson/Ritchie/Kernighan/McIlroy/Bourne/etc. were quite likely smarter than we are -- we're also not egotistical jackasses like Poettering -- we did not rush into this. We considered it carefully, we debated it at length, and we rejected it.
To borrow an applicable -- but possibly apocryphal -- quote from Enrico Fermi: systemd is not even good enough to be wrong.
Reply to This Parent
twitter
facebook
Flag as Inappropriate
bydskoll ( 99328 ) writes:
So when you say "we -- the people who've been working in this field for many decades", note that I have been developing software as a hobby since 1982 and professionally since 1990, and ran a software development company for 18 years. I think I'm likely as "seasoned" as anyone on Slashdot.
Second: If you say: "We considered it carefully, we debated it at length, and we rejected it.", then why is it that most Linux systems use systemd, Solaris uses smf, and Mac OS uses launchd, all of which are systemd-lik
bylinuxrocks123 ( 905424 ) writes:
> I didn't see a whole lot of anger when Linux went with sysvinit scripts instead of the conceptually-simpler BSD rc system.
Linux _didn't_ universally adopt sysvinit over BSD rc. Which one got used depended on the distribution. Slackware, which I like best because it keeps things simple and doesn't change for the sake of change, happens to (still) use BSD rc.
So, calling the debate "SystemD versus sysvinit" is and always was somewhat incorrect, but it's accurate enough since the actual init binary is th
bydrinkypoo ( 153816 ) writes:
Second: If you say: "We considered it carefully, we debated it at length, and we rejected it.", then why is it that most Linux systems use systemd, Solaris uses smf, and Mac OS uses launchd, all of which are systemd-like things?
All of those things are reviled to various degrees.
sysvinit's only crimes were that it was slow and you had to write scripts. startpar solved the slow problem and scripts are an integral and fundamental feature of the OS, and avoiding them is missing the point. Init scripts are made with skeletons and boilerplate and just aren't that complicated anyway.
There have been Linux distributions which used the BSD init script system. It's just inferior to doing it the System V way, which is yet still basically the
byBarsteward ( 969998 ) writes:
There is a lot of jealousy with Poettering's skills and capabilities, example "we're not mere ignorant newbies like Poettering". But on the personal level dealing with developers etc he can be as much as an asshole as Torvalds.
bydrinkypoo ( 153816 ) writes:
There is a lot of jealousy with Poettering's skills and capabilities
It's not clear exactly what you mean here. Do you mean that he's jealous of competent developers? There could actually be jealousy of his influence despite his lack of skill. As a statement which someone would be willing to make openly in public, that would also make sense. Everything he touches turns to poo.
byBig Hairy Gorilla ( 9839972 ) writes:
+100. Thank you very much, my line of reasoning exactly.
Devuan
is free and you no have dependencies on suppliers, less bugs, and less attack surface. Binary compatible with apt repos. Uses less energy because less is running in memory. My wireguard hub runs with 86 processes in ram. One of my recent email servers, with dovecot 2.4 and postfix, has only 121 running processes. My desktop Devuan system I'm currently writing this on has 390 running processes. Compare by running ps aux | wc on your Ubuntu or Red
bydskoll ( 99328 ) writes:
So much wrong.
Devuan is free and you no have dependencies on suppliers
So Devuan ships zero packages from third-party suppliers? That's a hot take.
Uses less energy because less is running in memory
Another hot take. A program sitting in memory uses essentially no energy unless it's scheduled to run.
One of my recent email servers, with dovecot 2.4 and postfix, has only 121 running processes.
My Raspberry Pi server running dovecot and postfix has 247 processes, but it also runs PostgreSQL, Aster
byBig Hairy Gorilla ( 9839972 ) writes:
I'm not hearing any valid use cases.
bydskoll ( 99328 ) writes:
I think we are witnessing the software equivalent of Planck's Principle [wikipedia.org].
●th your current threshold.
● your current threshold.
bykbrannen ( 581293 ) writes:
By this time, there are a lot of replies to you, but I'll try to add a little more context.
I think a lot of the "visceral hate for systemd" comes from not only the "it's not the Unix way" mindset, but that systemd comes across as "change for the sake of change". From my probably limited perspective, I don't feel that it really gives much of value, but it has made my life harder. I have new commands to learn, new text files in strange places to learn/create, and it's honestly hard to debug. A shell init scri
There may be more comments in this discussion. Without JavaScript enabled, you might want to turn on Classic Discussion System in your preferences instead.
Slashdot
●
●
Submit Story
If A = B and B = C, then A = C, except where void or prohibited by law.
-- Roy Santoro
●FAQ
●Story Archive
●Hall of Fame
●Advertising
●Terms
●Privacy Statement
●About
●Feedback
●Mobile View
●Blog
Do Not Sell or Share My Personal Information
Copyright © 2026 Slashdot Media. All Rights Reserved.
×
Close
Working...
Working...