●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
Please create an account to participate in the Slashdot moderation system
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.
byVlijmen Fileer ( 120268 ) writes:
Well, Linux can already hardly be trusted, but CIA spy Poettering certainly never can.
Let's hope systemd will die soon!
Reply to This
twitter
facebook
Flag as Inappropriate
bysinkskinkshrieks ( 6952954 ) writes:
Poll: runit, s6, or OpenRC?
byunixisc ( 2429386 ) writes:
Let's go w/ BSD then? Or HURD, if one needs GPL?
bypele ( 151312 ) writes:
Remind me again what was wrong with sysinit scripts?
bydskoll ( 99328 ) writes:
A few things that are hard to do with sysvinit scripts: Parallel startup, dependency management, and management of running services. Also, every service has to duplicate the bits of code needed to properly daemonize a service under UNIX, instead of having the service manager do it for them. Glibc does have a daemon library function, but it is non-standard.
There are hacky or ad-hoc solutions for all of these things, but they no longer really resemble the "simple" sysvinit scripts of the past.
byBig Hairy Gorilla ( 9839972 ) writes:
I've heard all the arguments for Systemd. The argument that multi-homed systems somehow won't work properly is false. I currently use Devuan with sysvinit for most of my servers and desktops, for me and all my customers, several small offices. I've often setup servers with up to 5 networks converging, I load the network interfaces with a custom script @reboot, not complex. I've never seen a valid use case for systemd. Parallel startup? Who cares with the hardware speeds we have today.
I'll grant you that my
bydskoll ( 99328 ) writes:
Parallel startup? Who cares with the hardware speeds we have today.
I care a lot about this on my laptop. It makes a significant difference.
I argue that anything that systemd does, you can write an init script that does the same job with around 1 million less lines of code, less bugs, less attack surface, and 50-75% less processes running in RAM.
And I'd argue that you're wrong. Does the average sysadmin write init scripts with the same care that software developers (are supposed to) take when they
byphantomfive ( 622387 ) writes:
Here's an example of a traditional init script [slashdot.org]. I don't know why Debian wrote such long init scripts but they did. And systemd made the Debian maintainer's job easier. That's why the Debian maintainers switched to systemd.
It wasn't about you, it never was.
bydrinkypoo ( 153816 ) writes:
I don't know why Debian wrote such long init scripts but they did.
It is not a problem if an init script is long. It is only a problem when it is hard to understand. Debian's lsb-inherited functions library for init scripts and the specific structure used is what makes them easy to write. Shell scripting is a fundamental Unix feature, people should understand it well enough to copy an init script and make a few changes. There is a skeleton script to start with so you don't have to actually even understand what you're doing, you only have to (slightly) understand shell scri
byphantomfive ( 622387 ) writes:
That's why it's wrong. The GPL is about the user. Debian is in very large part about the GPL. Debian should be about the user.
You misunderstood: what I mean is that systemd was never about you. It was about making something that Debian maintainers would want to put into their system, and Poettering put a lot of effort into communicating with them and understanding what they wanted, something he doesn't do for other classes of users.
bydrinkypoo ( 153816 ) writes:
You see how that's not better though, right? Debian put all that stuff in their init scripts, if it was too complicated, they have themselves to blame. Since a unit script is just a pile of unique key value pairs separated by equals signs, you could have an init script which parsed them and you wouldn't need systemd but they chose to adopt systemd anyway. And not as an option which would have been ok, but as the only supported option, because yes you could and can change init systems but then tons of things
byphantomfive ( 622387 ) writes:
I didn't say it was better or worse, I said that if you don't like systemd, it's not about you and that's why you don't like it.
As for the Debian team, looking at their prior init scripts shows they wouldn't recognize good code if they saw it.
●rrent threshold.
byfahrbot-bot ( 874524 ) writes:
Remind me again what was wrong with sysinit scripts?
I think the idea of systemd, like most of the runtime systems, is fine, but I take issue with the expanse of systemd and it directly incorporating things, like date/time and resolver, it doesn't need to simply manage a system and its startup. The developers seem to have a not invented here attitude about things. Also, would it kill them to have it run as PID 2 instead of 1?
bythogard ( 43403 ) writes:
Remind me again what was wrong with sysinit scripts?
The sysv init was never finished. If you notice there are some similarities of inittab and a makefile.
The idea was the runlevel and action fields could be used for dependency and concurrency. The run levels A,B & C are hints of that as is the current total lack of use of the id field. There are hints in the 5ess software as well. Init's early features were limited because it could never be paged out and multi-cpus weren't an option on the newer 3b line
bydrinkypoo ( 153816 ) writes:
The sysv init was never finished.
Okay.
If you notice there are some similarities of inittab and a makefile.
What?
The idea was the runlevel and action fields could be used for dependency and concurrency.
But both of those things are actually used. So are the IDs, they actually have meaning. And the runlevels are part of dependency. You pass through runlevels on your way to other runlevels.
The run levels A,B & C are hints of that as is the current total lack of use of the id field.
Almost total. It's relevant to ttys :)
Init's early features were limited because it could never be paged out
init being limited is good. We want it to be simple. It doesn't often have to do anything but you want it to respond right away when it does. Today we can afford to burn more memory so we can afford a more complicated init from that perspective, but having more complexity in
bythogard ( 43403 ) writes:
If you notice there are some similarities of inittab and a makefile.
What?
Look at the names and descriptions in the fields and the pre-tab makefile format for far more similarity.
But both of those things are actually used. So are the IDs, they actually have meaning. And the runlevels are part of dependency. You pass through runlevels on your way to other runlevels.
The ID's aren't used for dependency. The id in sun sysv is a hack based on things like telnetd and rlogin. Part of the plan was to have the action field reference the ids and a state which was not done. The idea was to have a make like dependency check based on the current state of what was running.
Had inittab been expanded slight
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...