Live data from Hacker News

How to Crash Systemd in One Command

agwa.name

51–60 of 193 posts

Re: How to Crash Systemd in One Command

#51

Earlier quoted context omitted.

I'm not sure how this comment is helpful to the discussion. As far as I can tell, you'd rather only hear the facts that fit your opinion of systemd as terrible software. I think the obvious right answer is that both sides present only facts and let newcomers decide based on that.

I completely agree with you. That would be nice, if people were presented with facts and a choice. But they weren't, and aren't.

Well, it's never too late to start. :-) As history shows, you can try to suppress truth for a while, but it is usually either unstoppable, or insignificant.

Re: How to Crash Systemd in One Command

#52
post #33

It seems like it is quite fashionable to hate on systemd, and it seems like systemd is kindof a piece of crap - in some ways. However, linux is missing basic functionality other os's offer, and systemd is showing up and trying to fill in those blanks. This is open source, if you don't like systemd, if you think it's crap, if you think there are obviously better ways to do it, well, what are you waiting for then? Syst…

> However, linux is missing basic functionality other os's offer, and systemd is showing up and trying to fill in those blanks. I'm curious what functionality other OSes had that Linux did not before systemd came along. It seems to me that it has been subsuming functions of other systems on Linux that were already present, as opposed to offering anything new. Socket activation? inetd/xinetd. Timed start of programs?…

> I'm curious what functionality other OSes had that Linux did not before systemd came along.

Uniform daemon/service handling. Just look at the scripts in /etc/init.d (or wherever they are located in your particular SysV init setup). It's a total mess.

The rest of what systemd offers I can't comment on because I'm not familiar with it. But it is clear to me that systemd's declarative .service files are a billion times better than shell scripts.

Re: How to Crash Systemd in One Command

#53

Earlier quoted context omitted.

I'm not sure how this comment is helpful to the discussion. As far as I can tell, you'd rather only hear the facts that fit your opinion of systemd as terrible software. I think the obvious right answer is that both sides present only facts and let newcomers decide based on that.

As the other reply said, the problem is that newcomers aren't allowed to hear the anti-systemd facts, as the systemd gods have already decided that all Linux users (or at least all distros) must bow down and accept them, and no dissenting opinion is allowed to stay on the front page of HN for long (this post has already been brigaded off the front page, apparently).

It could be the "controversial topic" penalty, which is extremely heavy-handed. But I also notice that both anti-systemd and pro-other-init-system posts and comments are barraged with downvotes on all kinds of forums, including HN. It is definitely something that certain people don't want out in the world.

Re: How to Crash Systemd in One Command

#54
post #9

It seems like it is quite fashionable to hate on systemd, and it seems like systemd is kindof a piece of crap - in some ways. However, linux is missing basic functionality other os's offer, and systemd is showing up and trying to fill in those blanks. This is open source, if you don't like systemd, if you think it's crap, if you think there are obviously better ways to do it, well, what are you waiting for then? Syst…

Alternatives have been implemented before: http://cr.yp.to/daemontools.html http://smarden.org/runit/ The more you look at any of DJB's software, the more of the future you'll see.

I've switched everything I write to use runit because runit doesn't require any particular init system, you can easily integrate it with sysvinit, freebsd's RC, ubuntu's upstart, systemd, etc. It just runs on top and doesn't need to be the king and it's incredibly simple to write scripts for it. Completely removes the need to worry about this init mess.

Re: How to Crash Systemd in One Command

#55
post #28
post #6

Earlier quoted context omitted.

> "Systemd is winning because they showed up and basically nobody else did" I can't see how you would qualify this statement, which is utterly false. Specifically, systemd adoption was the result of political pressure by LP (the author), who works at Red Hat. There are plenty of other choices out there. The idea that systemd won because of some kind of meritocracy is wrong. It was mostly political with some technical…

systemd is by far the best linux init system. The options are sysvinit, OpenRC, Upstart, and systemd. Of those, the only reasonable choice is systemd. Upstart was almost good, but its really frustrating to use. OpenRC is decent, but confusing. systemd solved problems, not only that it solved them well. The scope creep of systemd is something that is a bit alarming, however even with the creep it's doing a good job. T…

The only thing systemd solves, and I will say this is a big problem, is full process management. It also unifies startup scripts which does make it easier to support multiple distributions with a simpler packaging process. I'll give you that too.

The scope creep is really bad. It's not just bad, it's terrible. I don't want a program that's an init, and replaces xinitd and replaces my logging system and replaces cron. That's all totally beyond unnecessary.

Even with full process management, I'd hardly say it is the best. I have had cases where I stopped a service on a systemd box and it did leave child processes running. It's command line tools are terrible.

In fact it's this creep that keeps people from even being able to make drop in replacements. uselessd was a fork that kept up for a bit, but lost maintainership. With systemd being RedHat funded for full time development, it's very difficult for independent programmers to put in the time to make anything that can get adopted in the way it is.

Re: How to Crash Systemd in One Command

#56

Earlier quoted context omitted.

> However, linux is missing basic functionality other os's offer Could you please elaborate on what some of those are? > systemd is showing up and trying to fill in those blanks I haven't really kept on top of all systemd releases, but all I can see is them replacing things that already exist, just doing them in a different way. I agree the init system replacement was necessary, but I'm struggling to understand why a…

I basically agree with everything you're saying, I just think if the people who think systemd is misguided spend their time writing blog posts about it, nothing will change and the people actually writing the code will have the final say, right or wrong.

Just to play Devil's advocate here, I wouldn't say that nothing will change. Not everybody can code, and not everybody that can code has time to code for a new project. And that's no guarantee that if someone does submit code that it will be accepted.

I get the strong impression that systemd is driven by ego first, and technical innovation second.

But writing blogposts and making non-coders aware of some of the frustrations and dangers system administrators face will help the "business people" understand, and hopefully can put pressure from another angle.

We'll never all agree on one way of doing things, but I think that it's valid to socially encourage coders who have such a large sphere of influence and whose code can potentially be very harmful, to take more care and consider things outside their immediate bubble.

That blogpost alone has driven a lot of good discussions in this very thread, and I think that's as good and as healthy as helping more directly with submitting code.

Re: How to Crash Systemd in One Command

#57

Earlier quoted context omitted.

Yes, a large part of which is the process behind systemd. You're adopting more than just software when you adopt software, and I think investigating what the systemd developers are like is a worthy exercise -- in particular how they approach bugs. I think most people would be surprised to learn what that is like.

Ah, yes: When is a bug not a bug? According to the systemd developers, it's when we don't encounter it on our personal machines.

... And also when they can pass the buck to kernel developers, even when it's not a kernel bug.

Re: How to Crash Systemd in One Command

#58
post #28

Earlier quoted context omitted.

systemd is by far the best linux init system. The options are sysvinit, OpenRC, Upstart, and systemd. Of those, the only reasonable choice is systemd. Upstart was almost good, but its really frustrating to use. OpenRC is decent, but confusing. systemd solved problems, not only that it solved them well. The scope creep of systemd is something that is a bit alarming, however even with the creep it's doing a good job. T…

The one thing that is painfully obvious about the situation with init systems is that people have strong opinions about their preferences. And that makes the systemd situation even more terrible, since it's a choice unwillingly foisted upon a huge number of people. This situation really deserves some choices. For me, that is the number one reason I do not like systemd, even if it's solved some problems.

I agree with your reason, however for me they get outweighed by other factors. If I am a maintainer of a popular distribution, I want my distro to have the best init system, and I want that init system to have the largest user base.

EL6 and its derivatives was upstart, debian and its derivatives was upstart. The vast majority of linux systems were upstart for a long period of time. Other systems did not switch to upstart, because it introduced headache.

Switching init systems requires quite a bit of work. The fact that they all switched to systemd shows that beyond political pressure, they needed a better system.

Re: How to Crash Systemd in One Command

#59
post #28

Earlier quoted context omitted.

systemd is by far the best linux init system. The options are sysvinit, OpenRC, Upstart, and systemd. Of those, the only reasonable choice is systemd. Upstart was almost good, but its really frustrating to use. OpenRC is decent, but confusing. systemd solved problems, not only that it solved them well. The scope creep of systemd is something that is a bit alarming, however even with the creep it's doing a good job. T…

The one thing that is painfully obvious about the situation with init systems is that people have strong opinions about their preferences. And that makes the systemd situation even more terrible, since it's a choice unwillingly foisted upon a huge number of people. This situation really deserves some choices. For me, that is the number one reason I do not like systemd, even if it's solved some problems.

There are exactly two compelling (for me) arguments against systemd, and one that seems to result from it's current focus:

* Binary log files (WHYYYYY; OTOH you could argue that the only proper place to do logging is to a remote database.)

* Monolithic nature - everything gets shoved in to the daemon, making it harder and more unusual to do things without it.

* Servers - systemd seems to be focused on a desktop lifecycle, where users interactively log in, have settings and log out. It is less clear how secure or well this inter-operates with services running as 'users' for privilege separation. I think this may have recently gotten better.

Re: How to Crash Systemd in One Command

#60
post #52
post #33

Earlier quoted context omitted.

> However, linux is missing basic functionality other os's offer, and systemd is showing up and trying to fill in those blanks. I'm curious what functionality other OSes had that Linux did not before systemd came along. It seems to me that it has been subsuming functions of other systems on Linux that were already present, as opposed to offering anything new. Socket activation? inetd/xinetd. Timed start of programs?…

> I'm curious what functionality other OSes had that Linux did not before systemd came along. Uniform daemon/service handling. Just look at the scripts in /etc/init.d (or wherever they are located in your particular SysV init setup). It's a total mess. The rest of what systemd offers I can't comment on because I'm not familiar with it. But it is clear to me that systemd's declarative .service files are a billion time…

Didn't upstart and launchd cover this before systemd?
Post reply on HN