●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
wnewsdaystalestupid
sightfulinterestingmaybe
cflamebaittrollredundantoverrated
vefunnyunderrated
podupeerror
×
180717384
comment
bydrinkypoo
2026 @05:59PM
(#65963136)
Attached to: Author of Systemd Quits Microsoft To Prove Linux Can Be Trusted
try and keep the niche role by having scripts than no-one else knows about
This is nonsense. Nobody with any sense is developing their own solutions for everything, because someone else has already done it — unless it's so simple that someone else competent could just write essentially the same script. I write tons of short scripts, but I don't think any of them are magic, they're just time savers because I will do the same things again later. Then maybe they become the basis of some automation later.
It's also nonsense because one of the defining characteristics of shell scripts is that they are self-documenting. If you understand what the commands do, you know what the script does when you read it. If not, you can look the commands up in the manual. None of it is secret if someone else walks in to your job after you get hit by a bus.
180716534
comment
bydrinkypoo
2026 @02:30PM
(#65962816)
Attached to: Author of Systemd Quits Microsoft To Prove Linux Can Be Trusted
We no longer need it. We have pipewire and wireplumber. They do that job and some other jobs too. The combo replaces both pulseaudio and JACK, and also connects ALSA clients so they get their own volume controls as well.
180716502
comment
bydrinkypoo
2026 @02:18PM
(#65962798)
Attached to: China Executes 11 Members of Myanmar Scam Mafia
The western world didn't outsource squat. These drug cartels in these countries are local
Which countries consume the largest amounts of these drugs?
180715128
comment
bydrinkypoo
2026 @09:32AM
(#65962374)
Attached to: Author of Systemd Quits Microsoft To Prove Linux Can Be Trusted
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 don't work — even things which have explicitly provided non-systemd support upstream. That was an openly anti-user move.
180714846
comment
bydrinkypoo
2026 @08:40AM
(#65962326)
Attached to: Author of Systemd Quits Microsoft To Prove Linux Can Be Trusted
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 scripting.
Also, init scripts work fine on Debian even without any of that. If you take an init script written in bourne shell from a classic SysV system and slap it onto Debian it will work with zero changes, but you may have to give additional arguments to update-rc.d if you don't add the runlevel and dependency info to the top of the script depending on what your service requires or is required by.
It wasn't about you, it never was.
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. If there's a bit less software in the core distribution because some of the would-be maintainers are confused by a core Unix feature, okey dokey. People who need an outdated version of it provided to them by their distribution can run a derivative. A ton of Debian software is woefully outdated and you have to go looking for a newer version if you want to run modern software anyway, so it's not like they are keeping up in general despite the handholding.
180714796
comment
bydrinkypoo
2026 @08:30AM
(#65962316)
Attached to: Author of Systemd Quits Microsoft To Prove Linux Can Be Trusted
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 the one of the two processes that absolutely must not have a problem which has always been very simple is very arguably not the best idea.
With all of that said, none of what you said addressed the question. What's so bad about init scripts? Allow me to pose my version here: Given that most users will never need to write an init script or unit file, for the same reasons, what is the problem with init scripts supposed to be? I can take an ancient init script and slap it into place on a modern system and it will likely still work, and if I want boot order dependency to work I will only need to slap some structured comments into the top of it.
My recollection of the Debian argument for systemd looks like this: "GNOME is going to it and some maintainers are confused by writing init scripts." But understanding Debian packaging (bop it! twist it! pull it!) is like ten times harder than that, so I just don't get this argument at all. I do comprehend the GNOME argument, I just don't find it compelling because GNOME was enshittifying at the time, so it wasn't worth enshittifying Debian with systemd.
180714736
comment
bydrinkypoo
2026 @08:11AM
(#65962304)
Attached to: Author of Systemd Quits Microsoft To Prove Linux Can Be Trusted
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.
180714712
comment
bydrinkypoo
2026 @08:06AM
(#65962300)
Attached to: Author of Systemd Quits Microsoft To Prove Linux Can Be Trusted
I think you got modded down for begging the question.
What I mean here is, do people outside of the Linux world actually even hear about any of that stuff, let alone get scared off by it? What little I see about Linux from the mainstream tech press is generally cautiously optimistic and points users towards specific low-friction distributions where they won't be making a lot of choices. KDE vs GNOME is completely irrelevant to your average user, who wouldn't use advanced features if they had them. They don't do anything complicated enough to benefit from them. In that regard GNOME is correct, it's too bad they just torpedoed all the advanced functionality the nerds were using. That's why KDE has a much better clue, if you don't care you can just leave settings along and it just works, but it also has much more configurability. They should really adopt a simple/advanced settings system though, the problem with actually having all the settings in one place is that there's a lot of them.
And there I go off into the weeds again, as the average person won't even ever open settings. They just want to launch a couple of things, and everything will autoconfigure for them.
People have been having technical arguments about platforms as long as there's been platforms to argue about. Linux's arguments are out in the open because of the nature of the thing, so if people are seeing how sausages are made that could be a putoff. I just don't think they are in fact seeing those things unless they are the kind of people who are interested in such things to begin with. You have to go out of your way to encounter these kinds of discussions, and most people aren't swimming in the nerd end of the pool.
180714682
comment
bydrinkypoo
2026 @07:57AM
(#65962286)
Attached to: Author of Systemd Quits Microsoft To Prove Linux Can Be Trusted
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
180714672
comment
bydrinkypoo
2026 @07:55AM
(#65962284)
Attached to: Author of Systemd Quits Microsoft To Prove Linux Can Be Trusted
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.
180711368
comment
bydrinkypoo
1, 2026 @07:02PM
(#65961752)
Attached to: Author of Systemd Quits Microsoft To Prove Linux Can Be Trusted
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 available in a standard Devuan install right now. And they were available in a standard Debian install before they adopted systemd, too.
180711352
comment
bydrinkypoo
1, 2026 @06:56PM
(#65961750)
Attached to: Author of Systemd Quits Microsoft To Prove Linux Can Be Trusted
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 same thing as the BSD way — after all, it's only shell scripts being run in a predetermined order.
180709100
comment
bydrinkypoo
1, 2026 @10:15AM
(#65960846)
Attached to: Author of Systemd Quits Microsoft To Prove Linux Can Be Trusted
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 to impossible to switch out portions of it, and much of which doesn't work very well. systemd is arguably better at typical run time logging but is worse at early boot logging, which is what got me to drop it. I was having problems with root on zfs on Debian, which had been working, and I couldn't tell what had happened without a debugger. So I switched to Devuan.
In fact I just did a fresh install of Devuan excalibur (Debian trixie) with root on zfs from the trixie instructions on the openzfs site, where I had a dumb problem with grub which I solved in a hacky way by dropping a script into grub.d (the script which creates the root= part of the cmdline doesn't detect the pool the root volume is on correctly) and also had to do an init script in place of their .service file. It took me about 45 seconds to whack a related init script into what I needed and add it to the boot sequence.
When Debian switched to systemd, I adapted. I switched to Devuan.
180708706
comment
bydrinkypoo
1, 2026 @07:31AM
(#65960698)
Attached to: Author of Systemd Quits Microsoft To Prove Linux Can Be Trusted
Poettering will also continue to remain deeply involved in the systemd ecosystem.
I therefore trust that it will continue to be shit.
180708696
comment
bydrinkypoo
1, 2026 @07:26AM
(#65960692)
Attached to: UK's First Rapid-Charging Battery Train Ready For Boarding
Not needing a pantograph but needing isolators between rail segments is just trading one problem for another. Pantographs aren't cheap, but they are simple in principle and highly reliable.
« Newer
Older »
Slashdot Top Deals
●(email not shown publicly)
http://flagburningworld.com/
●
Days Read in a Row
●
Got a Score:5 Comment
●
Spent All My Mod Points
●
Not even pennies
●
Re:For the sake of the Olympics...
(Score:4, Insightful)
●
Re:1984
●
Re:I call rule 34 on section 34
(Score:2)
●
Not 140 bytes
(Score:3, Insightful)
●
Wonko the Sane
●
webmistressrachel
●
bmo
●
Mr. McGibby
●
tomhudson
●
lube (stories)
●
!story (stories)
●
!money (stories)
●
spam (stories)
●
like (stories)
Slashdot
●
Submit Story
It is much harder to find a job than to keep one.
●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...