Another daemon for managing control groups [LWN.net]

Another daemon for managing control groups

Posted Jan 2, 2014 11:29 UTC (Thu) by Rudd-O (guest, #61155)
In reply to: Another daemon for managing control groups by cas
Parent article: Another daemon for managing control groups

You are talking to Neil Brown. Where is your respect? You look like an idiot accusing him of "not understanding UNIX". Apologize.

to post comments

Another daemon for managing control groups

Posted Jan 3, 2014 23:02 UTC (Fri) by cas (guest, #52554) [Link] (13 responses)

I really don't care who he is. what people say and do is more important than what their name is.

anyone who says that sort, grep, tr, comm etc 'don't combine together well' and '"do one thing and do it well" is good for prototypes, not for final products' does not understand unix. read his post - the entire thing was "waah! unix toosl are too hard and complicated, systemd saves us from that!".

perhaps he was just indulging in some exaggeration - it's a popular systemd pusher's tactic to exaggerate the alleged 'difficulty' or 'inadeqacy'of all previous/competing methods so that systemd's meager benefits seem greater by comparison. in this particular case, he has to grossly exaggerate the difficulty and inadequacy and just plain awfulness of the small-tools approach.

the truth is that systemd just isn't good enough to be worth the price of loss of modularity and replacability (nothing could be good enough to be worth that price), especially when the minor benefits that systemd does provide could easily be provided without a monolithic mono-culture monstrosity absorbing every low-level userland function in sight. init systems really don't have to be that complicated, they don't have to absorb syslog and cron and automount and everything else.

Another daemon for managing control groups

Posted Jan 3, 2014 23:47 UTC (Fri) by dlang (guest, #313) [Link] (3 responses)

ahh, but they aren't trying to just create a new init system. They are defining a new standard linux userspace. That is enough to justify anything.

I just wish they would do this on their own distro.

Another daemon for managing control groups

Posted Jan 4, 2014 2:27 UTC (Sat) by raven667 (guest, #5198) [Link]

Well this helps standardize service startup and login session management, the CLI and GUI shell userspace is not affected in any way

Another daemon for managing control groups

Posted Jan 25, 2014 20:47 UTC (Sat) by Baylink (guest, #755) [Link] (1 responses)

That's the part that I really don't understand.

I can get that Lennart doesn't understand the Unix Philosophy, or why it's more than "just a philosophy"; I can get that he doesn't care about why binary log files are bad, or why not being able to see *which* component of the core system went runaway on ps and kill just it is bad, or why being unable to replace those components with the specific ones you need for your job is bad. Or why optimizing for something that the vast majority of non-developer users of Linux don't care about -- booting at ludicrous speed -- is bad.

Why, in short: *requiring me to UTSL* just to do admin work, is bad.

What I *cannot* understand is how *entire committees* of people who drive the designs of distributions drank the Flavor Aid.

It is effectively impossible now to run sysVinit, because the people who package things for dnew Tweets istributions *no longer include, much less support* the components necessary to do that. And unless you're google-scale (in which case you're probably building your distro from scratch anyway, with a dedicated department of staffers), you can't fix that.

And that's not to mention the *literally decades* of sysadmin reflexes that have been flushed down the drain by this decision on the part of distro managers -- that's the part that really frosts my ass. I have better things to do than to relearn the basics all over again, guys, really.

I got into Unix because I am *lazy*. I want to learn small things once, and leverage them into big things, to make my life easier.

No matter how much better it might be at the actual work, as a sysadmin, systemd continues to make my life harder and more frustrating, at every single turn.

My philosophy of life is that our morale is proportional not to the size of our wins and losses, but to their *number*; that's why I use Linux.

systemd just made it go the other way.

Thanks, guys.

Another daemon for managing control groups

Posted Jan 27, 2014 15:07 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

If you're so lazy, why are you even trying to follow everyone else? Is sticking with Slackware not the laziest thing one can do these days anymore?</snark>

Maybe others aren't so lazy to not see the benefits it brings to the table and that's why it has been adopted? Making my user setup use unit files took maybe a day or two (and that includes a *lot* of unit files; at least 30) and I just got hung up on needing suid to start X. Systems does bring a lot to the table. Have you even tried it or did "service" not working prevent you from digging deeper?

Anyways, an anecdote from dealing with FreeBSD this weekend: I tried getting a taskd server running, but unfortunately I get no indication that it has failed to start, logs as to why it might have happened, or what the init system even attempted to do. And BSD init scripts are easier to deal with than sysvinit. I really would rather have systemd with all the tools it gives me to deal with such problems (so I know whether I should go poke upstream).

Another daemon for managing control groups

Posted Jan 4, 2014 2:12 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

>anyone who says that sort, grep, tr, comm etc 'don't combine together well' and '"do one thing and do it well" is good for prototypes, not for final products' does not understand unix. read his post - the entire thing was "waah! unix toosl are too hard and complicated, systemd saves us from that!".

Frankly, I'm sick of total ignoramuses who repeat this very argument.

Get the freaking systemd and see what it can do. Now try to replicate it with "do no thing well" tools like SysV Init.

Another daemon for managing control groups

Posted Jan 4, 2014 3:19 UTC (Sat) by neilbrown (subscriber, #359) [Link]

> I really don't care who he is. what people say and do is more important than what their name is.

Well said!

As for the rest of your post, I guess we'll have to agree to disagree.

(and no, I didn't mean to exaggerate. I love Unix tools and use them all the time, but I also believe in choosing the right tool for the job)

Another daemon for managing control groups

Posted Jan 4, 2014 14:50 UTC (Sat) by anselm (subscriber, #2796) [Link] (6 responses)

the truth is that systemd just isn't good enough to be worth the price of loss of modularity and replacability (nothing could be good enough to be worth that price)

Any »modularity« in System-V init is there purely by accident. Actual »modularity« would imply a certain amount of unity of design and basic concepts, and communication between the components by means of well-defined and documented interfaces. None of these apply to System-V init and its associated tools such as inetd, cron, etc.

It's not as if System-V init had been consciously designed the way it is. It is a hodgepodge of stuff from different sources that were developed separately from each other, don't interact well (if at all) and are each configured completely differently from the rest. If there is a long-overdue opportunity to replace this utter mess by something that has actually been properly thought out as a complete system, works a lot better in real life, and is easier to understand, develop for, maintain, teach, and learn, then I'm all for it.

Another daemon for managing control groups

Posted Jan 4, 2014 17:56 UTC (Sat) by raven667 (guest, #5198) [Link]

In some ways this is like Plan9 again, a re-thinking of the UNIX concepts with an eye toward completeness and consistency with a lot of operational experience behind it that didn't exist when many of these systems were first developed.

Another daemon for managing control groups

Posted Jan 25, 2014 20:50 UTC (Sat) by Baylink (guest, #755) [Link] (4 responses)

No, the modularity comes from *the pieces not all being one big piece with no visibility or lines of separation*.

Yes, the design of sysVinit is a *bit* rough. But it works, and it's easy to understand if you know basic Unix, and you don't have to read thousands of lines of source to figure out what it's doing.

And if one part of it falls over, ps will tell you, and you can kill just that one part.

And you can grep the damn logs.

Another daemon for managing control groups

Posted Jan 26, 2014 1:20 UTC (Sun) by HelloWorld (guest, #56129) [Link]

> Yes, the design of sysVinit is a *bit* rough. But it works,
It *doesn't work*. Stop denying it, sysvinit can't even stop a service reliably and correctly.

> and you don't have to read thousands of lines of source to figure out what it's doing.
Yeah, you just have to read thousands of lines of shell. With systemd otoh, you read *documentation*. You know, this stuff that is actually meant to be read by humans. Because unlike the sysvinit quagmire, systemd actually *has* documentation that's worth mentioning.

> And if one part of it falls over, ps will tell you, and you can kill just that one part.
Yeah, like systemd somehow magicall broke ps.

> And you can grep the damn logs.
You can do that with journalctl too. But actually most people don't do it, because it *sucks* and just using the domain-specific features of journalctl is easier, faster and more robust.

Another daemon for managing control groups

Posted Jan 27, 2014 19:38 UTC (Mon) by anselm (subscriber, #2796) [Link] (2 responses)

The current init/service activation infrastructure (System V init, inetd, cron, …) does not have anything worth calling »a design«. It is cobbled together out of random pieces from different sources and the amazing thing is that it works at all. The pieces don't talk to one another and are all configured differently. If it had in fact been »designed« you would expect at least a minimum of consistency and cooperation between the pieces.

If somebody proposed this setup today as a new system they would be laughed out of the lecture theatre. The only reason this is still in actual use at all is that for the longest time nobody has dared come up with an alternative. Most of the other Unix-like systems have replaced it long ago.

People always cite »the Unix philosophy« as »do one thing and do it well«, and point to System V init as a prime example of this approach. This disregards the obvious fact that while SysV init is surely doing something, there is no way that one could claim it is doing it well.

Another daemon for managing control groups

Posted Jan 27, 2014 20:45 UTC (Mon) by khim (subscriber, #9252) [Link] (1 responses)

This disregards the obvious fact that while SysV init is surely doing something, there is no way that one could claim it is doing it well.

It does pretty decent work on scaring newbies away from Linux. Perhaps that is the thing is was designed for? Of course it's kinda overenginered for such a use case, you can create a much smaller and simpler mess which will be much scarier.

Another daemon for managing control groups

Posted Jan 27, 2014 22:40 UTC (Mon) by nix (subscriber, #2304) [Link]

Someone needs to implement an init system as an IOCCC entry, clearly.