Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why pro-systemd and anti-systemd people will never get along

uselessd.darknedgy.net

Post reply on HN
Print view View original

101–110 of 113 posts

Re: Why pro-systemd and anti-systemd people will never get along

#101

Post by api »

e7620 wrote: post #62
api wrote: post #14

Earlier quoted context omitted.

I agree. So far I've seen it as a classic conservatives vs. liberals debate. The conservatives have no interest at all in changing the Unix paradigm under Linux. It works perfectly well, thank you. The liberals see it as archaic and unsuited to a wide variety of new use cases including rapid-deployment VMs, containers, mobile and laptop computers, and the desktop in general. I side with the liberals here, but with a…

Not really, I use a dozen init systems, each for a different situation, and I'm interested in keeping it that way. The problem is that systemd is that is being forcefully pushed to all distros. For instance, by merging udev with systemd. Maybe those forks don't add nothing for you, but for me they're beneficial, because I think Darwinian evolution also applies to software.

> I use a dozen init systems, each for a different situation, and I'm interested in keeping it that way.

You might like that, but it makes life hell for developers who write and package any kind of daemon/service.

Re: Why pro-systemd and anti-systemd people will never get along

#102

Post by wahern »

bkor wrote: post #44
ck2 wrote: post #17

Earlier quoted context omitted.

One person decided the way microsoft windows handles services was awesome and it would be a good idea to make the linux service manager work like that with complex binaries and binary logs instead of editable, standardized bash scripts and text logs. No vote, only veto. Very anti-linux.

According to the blogs it is based upon what Mac OS does as well as Solaris. So it is very UNIX in mind.

Both launchd and SMF suck. Have you tried learning either?

SMF utilizes XML all over the place. launchd uses .plist trees all over the place. They're both a gigantic pain to learn, with obtuse configuration syntax, and in fact very few people actually learn them. They're both environments that breed epic cargo cults because they're overly complex, yet provide so little benefit that there's little motivation to bother to learn them properly. All you normally care about is getting your little script to run on boot or login, so the rest is just food for bugs.

SMF and launchd also organically grew to take over most of the management of /etc. Now neither is hardly any better than the Windows Registry.

systemd is not only moving in the same direction, they're going to leap-frog them. Why have a separate ntpd or dhcpd when you can just build it into the init framework. Why listen for SIGHUP or SIGTERM when "good" services (in as much as service can be good which isn't shipped with systemd) just use the systemd C API to listen for DBUS events.

That's the problem with systemd, SMF, and launchd. Like SMF and launchd, I have no doubt whatsoever that systemd will rocket past the boundary where the complexity exceeds the benefit.

Re: Why pro-systemd and anti-systemd people will never get along

#103

Post by anko »

agrover wrote: post #90
exelius wrote: post #38

Earlier quoted context omitted.

I'm not on either side myself, either. But "this is the way we've always done things" is a terrible reason to keep doing them that way. Systems change, requirements change, and so implementations and methods must change as well. I'm not saying this is warranted or not in the case of systemd (I don't know enough of the details to opine either way) but it has been a cultural problem in the Linux community for a number…

I think the fallacy is looking at the composability of tools on the command line and thinking you want/need the same composability in how the system runs. You don't. The Unix Way is actually TWO things: one is shellscripting and the composability of the command line, and the other is C and libraries. "Whipupitude vs manipulexity", to quote Larry Wall. Systemd is the result of determining that running system services…

Thank you, this is the most insightful comment I've read.

People like the whipupitude, because they know it. But nearly every init.d script I've read has bugs. There isn't a testing framework to ensure correctness and even if there were it would be needlessly complex because you'd spend a bunch of time mocking out the filesystem / the process table / whatever else init scripts do.

We know what initialising a process should look like and we should be stabilising this API so that we limit mistakes/bugs.

Re: Why pro-systemd and anti-systemd people will never get along

#104

Post by hk__2 »

deelowe wrote: post #16
hk__2 wrote: post #2

Could someone ELI5 this pro-systemd/anti-systemd thing?

Linux/unix has a bit of an issue with it's init aging systems. One simple example is that they are serial, meaning that services start one by one with little to no concurrency. This causes several issues. Also, the most popular variant, system V is difficult to maintain having multiple directories for various run levels and other cumbersome features. I won't go into details here, just know that the popular init syste…

Thanks!

Re: Why pro-systemd and anti-systemd people will never get along

#105

Post by e7620 »

api wrote: post #101
e7620 wrote: post #62

Earlier quoted context omitted.

Not really, I use a dozen init systems, each for a different situation, and I'm interested in keeping it that way. The problem is that systemd is that is being forcefully pushed to all distros. For instance, by merging udev with systemd. Maybe those forks don't add nothing for you, but for me they're beneficial, because I think Darwinian evolution also applies to software.

> I use a dozen init systems, each for a different situation, and I'm interested in keeping it that way. You might like that, but it makes life hell for developers who write and package any kind of daemon/service.

Absolutely not, only if they depend on systemd. If they follow UNIX conventions, they don't need to edit a single file. Writing a daemon init script was a solved problem decades ago, and that script will serve for every init system.

Re: Why pro-systemd and anti-systemd people will never get along

#106

Post by e7620 »

stock_toaster wrote: post #99
e7620 wrote: post #87

Earlier quoted context omitted.

I agree completely, those operating systems are great, as good or better than GNU/Linux. But with that phrase I was thinking people without prior experience, like Windows users, FreeBSD install is fairly involved for them, there's PC-BSD, but it seems to me, distros like Mint are easier for beginners and useful as a stepping stone to those OSs.

I think Linux has an edge in driver support, and corp vendors -- especially for gaming with things like Steam. I really like some of the things the pc-bsd folks are doing though. Lumina seems to be coming along nicely.

> I think Linux has an edge in driver support, and corp vendors -- especially for gaming with things like Steam.

Still, remember when using linux meant compiling the kernel ten times, editing some .c file, changing some obscure flag. And then you needed to open that .doc, .ppt or use msn messenger. You tried dual booting, but windows kept rewriting the bootloader...

Now, with VMs and tech like PCI pass-through this is just SO easy, that issue is less relevant and will result in more popularity for other OSs and a reversing of the consolidation trend.

Re: Why pro-systemd and anti-systemd people will never get along

#107

Post by digi_owl »

bnolsen wrote: post #67
fidotron wrote: post #11

It will be very interesting to see how this all plays out in the long run, though the short term is utterly depressing. My hunch is Lennart will be vindicated, on the basis that systemd as it exists right now is not right, but it can be evolved into something much better, and while that may not have occurred to other projects here the stakes are enormous. There is a definite strand to the resistance that any change t…

If anything the whole systemd mess has put more attention on the init system and dependencies. There's plenty of drama and its a modern vi/emacs kde/gnome fight that people are passionate about. I think what burns a lot of us anti systemd people is the apparently lack of sound engineering principles and overengineering. It's just a damn init system! Other init systems (runit, etc) had already mostly solved many of th…

Or allow for replacement A to be mixed with existing system B, rather than have the whole edifice torn down and rebuilt.

Re: Why pro-systemd and anti-systemd people will never get along

#108

Post by digi_owl »

nova wrote: post #58
api wrote: post #14

Earlier quoted context omitted.

I agree. So far I've seen it as a classic conservatives vs. liberals debate. The conservatives have no interest at all in changing the Unix paradigm under Linux. It works perfectly well, thank you. The liberals see it as archaic and unsuited to a wide variety of new use cases including rapid-deployment VMs, containers, mobile and laptop computers, and the desktop in general. I side with the liberals here, but with a…

“The whole modern world has divided itself into Conservatives and Progressives. The business of Progressives is to go on making mistakes. The business of Conservatives is to prevent mistakes from being corrected. Even when the revolutionist might himself repent of his revolution, the traditionalist is already defending it as part of his tradition. Thus we have two great types -- the advanced person who rushes us into…

How about a third way? If you want to go on making mistakes, do so over there, and only bring it back here when you can prove that it will not blow up in our faces.

Re: Why pro-systemd and anti-systemd people will never get along

#109

Post by hollerith »

uselessdguy wrote: post #15
fidotron wrote: post #11

It will be very interesting to see how this all plays out in the long run, though the short term is utterly depressing. My hunch is Lennart will be vindicated, on the basis that systemd as it exists right now is not right, but it can be evolved into something much better, and while that may not have occurred to other projects here the stakes are enormous. There is a definite strand to the resistance that any change t…

Shell scripting isn't "archaic nonsense" at all, it's just that the warts from how most shells implement their command language (ksh/bash/POSIX sh) are holding us back. If you go look at Plan 9 rc shell scripts, you'll see how much cleaner they are. In addition, the s6 people have done some interesting things with execline (which looks kind of like Tcl), which works as a chain loader instead of holding the shell resi…

>If you go look at Plan 9 rc shell scripts, you'll see how much cleaner they are.

I used rc as my interactive shell and for very light shell scripting for over 10 years, and I consider it only slight better than the other Unix shells. In fact, the fact that rc's rules for escaping (quoting) characters like hash and space are incompatible with Emacs's shell mode's file-name completion was enough to cancel out any benefit I have derived from the relative "cleanness" of rc.

the (minor) advantages of rc for me: not having to remember the more complex quoting rules of bash, etc. unlike with bash, etc, no part of an rc commandline is ever interpreted twice except for when the double-interpretation is caused by an explicit use of the "backquote" (eval and substitute) operator.

I know this is just my subjective opinion, but I find Unix shells, including rc, inferior to almost any other programming language.

I always got a little sad when I needed to write anything requiring an if statement or anything but the simplest loop in rc (or any other Unix shell). I have come to realize that I would much, much rather write such things in Emacs Lisp -- and have transitioned to doing so. (The start-up time of Emacs --batch is fast enough on modern hardware not to be an impediment.)

Re: Why pro-systemd and anti-systemd people will never get along

#110

Post by digi_owl »

api wrote: post #101
e7620 wrote: post #62

Earlier quoted context omitted.

Not really, I use a dozen init systems, each for a different situation, and I'm interested in keeping it that way. The problem is that systemd is that is being forcefully pushed to all distros. For instance, by merging udev with systemd. Maybe those forks don't add nothing for you, but for me they're beneficial, because I think Darwinian evolution also applies to software.

> I use a dozen init systems, each for a different situation, and I'm interested in keeping it that way. You might like that, but it makes life hell for developers who write and package any kind of daemon/service.

I keep seeing this, and i keep wondering why said developers are doing any packaging at all.

A binary and clear instructions on how it is launched from a command line should suffice for any competent admin.

He should then be able to fit it into the boot scheme of whatever system he is maintaining.

Post reply on HN