This whole debate saddens me

Posted Dec 1, 2014 23:23 UTC (Mon) by dlang (guest, #313)
In reply to: This whole debate saddens me by hunger
Parent article: The "Devuan" Debian fork

the claims that those things could do the job aren't coming from the people trying to replace the existing stuff, they are coming from the people who are pretty happy with what they already have and who don't like the downsides of the replacements.

They may very well be wrong in listing other possible ways to do what systemd is trying to do, but the bottom line is that those people don't really care about what systemd is trying to do because what it's offering isn't compelling enough to them to be worth the overhead of doing the transition. And yes, that does include having to learn all about the new system. There are always new things to learn, I don't know any good admins who have nothing they are working to learn so they have spare time to pick up systemd config. Instead they (we) all have a long list of things we want to learn, and systemd is being forced up near the top of the list ahead of things that we care a lot more about.

This whole debate saddens me

Posted Dec 2, 2014 1:12 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (10 responses)

Early in 2000-s we tried to do multiseat desktops for schools in order to save money on hardware. We were able to do it, but it required layers upon layers of hacks.

For example, it was simply not possible to partition a Linux machine in such way that stray nohuped processes from one user session could not end up hogging the whole system. We solved that with a special script that killed all but several root-owned processes every several hours. Except that we had no way to check if a user session is active and sometimes ended up kicking out still logged on users.

This whole debate saddens me

Posted Dec 2, 2014 1:30 UTC (Tue) by dlang (guest, #313) [Link] (9 responses)

that sounds like a perfect use case for cgroups, but I don't see how it's related to what I posted.

This whole debate saddens me

Posted Dec 2, 2014 1:33 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (8 responses)

Yes, and the first software combination that bothered to support it was logind+systemd. That's a clear example of a thing that was practically impossible to do correctly with the old infrastructure - and not for the lack of trying.

This whole debate saddens me

Posted Dec 2, 2014 1:38 UTC (Tue) by dlang (guest, #313) [Link] (7 responses)

So that means that there is a good reason for that combination to exist.

But that's a strawman because nobody is saying that systemd in all it's glory (with everything integrated and enabled) has no right to exist.

People just disagree on it being the default, or worse, having things start to require it that don't absolutely need it to function (and if something does, should that something be default on a distro?)

This whole debate saddens me

Posted Dec 2, 2014 5:53 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

> People just disagree on it being the default, or worse, having things start to require it that don't absolutely need it to function (and if something does, should that something be default on a distro?)
That's entirely different discussion. I would even support an effort to make sure that systemd does not regress on supporting alternatives to its components.

And so far only journald is required to use systemd, everything else is optional.

This whole debate saddens me

Posted Dec 3, 2014 17:38 UTC (Wed) by jb.1234abcd (guest, #95827) [Link] (3 responses)

> That's entirely different discussion. I would even support an effort to make sure that systemd does not regress on supporting alternatives to its components."

Good to hear.
How about an alternative to what systemd proposed for managaement of cgroups (that is, a systemd, pid=1 dependent solution).
How about systemd learning to live and cooperate in an ecosystem that is based on UNIX philosophy ?

And let's stop useless discussions about SysV vice systemd becuase they
lead nowhere. Let's look into the immediate future, but not only according to systemd zealots.

This is systemd's view of cgroups management:
http://lwn.net/Articles/575793/

This is an alternative view:
A control group manager (CGManager)
http://lwn.net/Articles/618411/
Its heritage is known to be management of "task containers", extended to
resources, and renamed to control groups.

Here are some excerpts from discussion on osnews.com, in context of Devuan fork of Debian and its pending choice of a default, progressive init sys like perhaps OpenRC or uselessd (when ready) as coexisting alternatives to systemd:

by Alfman on Fri 28th Nov 2014 16:30 UTC in reply to "RE: Interesting"
"Systemd fixed real limitations of sysv init scripts, which I think is great. However it introduced excessive coupling between unrelated services, which is both unnecessary and harmful to alternatives. When programming, unnecessary coupling is often a sign of a bad design. With Lennart P, I don't suspect incompetence, therefor I worry that it's being done deliberately as part of a strategy to exclude alternatives."

Alfman on Fri 28th Nov 2014 22:52 UTC in reply to "RE[3]: Interesting"
"I disagree with this [edit: systemd's view http://lwn.net/Articles/575793/], the easiest way to do this hasn't changed with systemd. The monitoring process need only handle the SIGCLD signal. Not only is this very easy to do, but it doesn't need any special permissions or non-standard configurations either.

The link points out some functional overlap between a "cgroup manager" and a service manager. However I think that maybe cgroup management might be better left to something more powerful & flexible like linux containers. We can deploy a service inside a linux container and then allow the init system to monitor the container.
[edit: my emphasis]
This method of managing cgroups should work with any service BTW, not just ones that are designed for systemd. It should also work with any init system. This is where the power of *nix comes from in the hands of power users, not monolithic solutions."
[edit: my emphasis][end]

by Alfman on Sat 29th Nov 2014 08:36 UTC in reply to "RE[6]: Interesting"
"If we can leave cgroups to a better tool like LXC, that might be preferable for me but I'm not altogether opposed to them. My interest is having something that is both reliable and unintrusive. Maybe uselessd or openrc like you suggest can fit the criteria."

The emphasis on neutrality of proposed solution w/r to type of sys init
or service should not be overlooked !
Why is it then that this solution is not being implemented by the major distros with the same zeal (but without false pretenses) as in case of systemd ?

This whole debate saddens me

Posted Dec 3, 2014 18:03 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

> How about an alternative to what systemd proposed for managaement of cgroups (that is, a systemd, pid=1 dependent solution). How about systemd learning to live and cooperate in an ecosystem that is based on UNIX philosophy ?
I'm extremely worried about cgroups interoperability. There was a plan for systemd to own ALL of the cgroups and even forbid their modifications by other processes on the kernel level.

However, it seems that somebody had repeatedly beaten kernel cgroups maintainers with a cluebat. So it'll be possible to carve out a subtree out of the cgroups tree and manage it with any tool you want. Even perhaps namespace it for a custom container.

> The monitoring process need only handle the SIGCLD signal. Not only is this very easy to do, but it doesn't need any special permissions or non-standard configurations either.
No, it's not. SIGCHLD is woefully inadequate for process confinement. Only the _parent_ receives it.

For example, suppose that BIND11 launches a helper program 'zone_from_mongodb'. This program (in error!) launches a mongodb instance in the background. Mongodb does the regular daemon song-and-dance and reparents itself to the PID1.

But here's the catch - PID1 has no way to know that this mongodb process actually belongs to BIND11! So there'll be no way to terminate BIND11 cleanly - we'll leave a mongodb instance running in background.

So no, SIGCHLD is not nearly enough.

This whole debate saddens me

Posted Dec 3, 2014 18:13 UTC (Wed) by anselm (subscriber, #2796) [Link]

The emphasis on neutrality of proposed solution w/r to type of sys init or service should not be overlooked ! Why is it then that this solution is not being implemented by the major distros with the same zeal (but without false pretenses) as in case of systemd ?

Perhaps because doing it as part of PID 1 actually makes technical sense? It simplifies the implementation considerably, and a simpler implementation is usually a more robust implementation. Having a separate cgroup management process would lead to all sorts of nasty chicken-and-egg problems and/or duplication of functionality.

In addition, “the major distros” seem to be happy with systemd, which provides cgroups management for free, so there is little incentive to implement something else which is technically inferior, simply for the sake of “neutrality”. No major distribution is “neutral” with respect to things like the C runtime library or operating system kernel, but nobody seems to be bothered by that.

Finally, we're all looking forward to evaluating the alternative implementation of cgroups management that Devuan will hopefully provide in due course. If it is actually superior in practice to systemd's approach, then so much the better for all of us – but the Devuan people will need to build, test, integrate, and document it first. Words are cheap.

This whole debate saddens me

Posted Dec 3, 2014 20:43 UTC (Wed) by ms_43 (subscriber, #99293) [Link]

There was a comment in this very discussion by somebody who actually has relevant experience that explains why separating service management (and croup management is a core part of service management nowadays if you want to keep up with the competition in terms of provided reliability) into a process different from init has negligible practical benefit:

https://lwn.net/Articles/623527/

And the first comment you linked to provides a very good rationale for why service management and cgroup management should not be separated into different processes.

Why then would one want to run CGManager on top of systemd? It appears to be designed to run on systems that don't have systemd.

Btw if these cgroup namespace patches are going to be merged, that would simplify container delegation and i wonder if CGManager would become mostly obsolete.
https://lkml.org/lkml/2014/10/13/464

This whole debate saddens me

Posted Dec 2, 2014 10:21 UTC (Tue) by hunger (subscriber, #36242) [Link]

I do agree that tools should not needlessly depend on other things.

But surely the people that according to you should not need to bother about the problems that those tools solve are not in a position to decide which of those dependencies are needless and which are not.

This whole debate saddens me

Posted Dec 2, 2014 10:27 UTC (Tue) by niner (subscriber, #26151) [Link]

So you bitch and moan around, just because the defaults try to solve other people's problems instead of yours. Well, tough luck. Happens to people all the time. So why should your problems be so much more important than those other people's?

And why do you spend so much time arguing about this, instead of trying to add fixes for your problems to the new default? It is free software, you know?

This whole debate saddens me

Posted Dec 2, 2014 10:14 UTC (Tue) by hunger (subscriber, #36242) [Link]

I am not talking about random users here, not even about admins. This is a community that sets out to replace an existing piece of technology with people actually claiming to write code to help with the removal. I did expect whoever sets out to write code to replace other, existing code to actually take the time to find out which problems that original code is actually trying to solve.

You are telling me that I am wrong to have that expectation, because people are happy with what they have. I can accept that part.

But how can people that do not even bother to understand the problems of the system they are currently using make an informed decision on the downside of the replacements that set out to solve those issues?

If your argument is true, then this whole systemd debate is not a technical discussion, but boils down to a trust issue: Do I trust the maintainers of my distribution to make the right choices for me or do I prefer to listen to random people shouting on the internet? That would paint a rather bleak picture of the Debian community, which is the only one that had this escalate so much.

I have to admit that this discussion does get under my skin, simply because following this debate has eroded my confidence in being part of a community of intelligent and rational people, which I rather enjoyed to have for the last 20 or so years. For the record: People of both sides of the fence contributed to that erosion.

This whole debate saddens me

Posted Dec 2, 2014 12:26 UTC (Tue) by anselm (subscriber, #2796) [Link] (1 responses)

Instead they (we) all have a long list of things we want to learn, and systemd is being forced up near the top of the list ahead of things that we care a lot more about.

One of the nice things about systemd is that it is actually a lot easier to learn than the current hodgepodge of nearly-unrelated tools. For example, there is one basic configuration file format that applies to all parts of systemd, whereas in the traditional setup no two configuration files seem to have the same basic format (let alone semantics). Also, you no longer need to be a shell programmer of some experience merely to understand the way background services are started, stopped, and monitored.

This isn't immediately beneficial to experienced system administrators who have spent the last 30 years getting used to the idiosyncrasies of the traditional setup, but will be a great boon in the future to new people coming in, especially as systemd settles down and better documentation, training manuals, books, etc. are written. As a Linux instructor and author I'm looking forward to my job becoming that much easier as the traditional setup is being phased out and a lot of the stuff that currently makes new Linux administrators tear their hair out simply goes away.

(Cynical minds will of course view the vocal resistance against systemd among some “veteran Unix admins” as fueled at least in part by the old guard running scared of no longer being the undisputed demigods of arcane Unix knowledge, as embodied in the traditional init setup. If my job security depended on my being the only person who understands the company's 20-year buildup of tweaked init scripts, service monitors downloaded from somewhere on the net, and hand-coded hacks that are needed to work around the default system's deficiencies, I too would probably be very afraid of something that threatens to make all of that obsolete.)

This whole debate saddens me

Posted Dec 2, 2014 18:05 UTC (Tue) by dlang (guest, #313) [Link]

You don't have to be "running scared" to be annoyed at being forced to take time away from things you want and need to learn to deal with a change like systemd

Given that (almost) everyone who's learned *nix for decades, and all the training material and examples from that time cover boot scripts, this is hardly a matter of job security because you are the only one who knows this stuff.

Or if you are a person who feels and acts that way, systemd is hardly going to change things, there are still going to be lots of room for config settings that nobody else knows why they are there, not to mention all the application and monitoring configs (and if you think that systemd will eliminate the need for other monitoring tools, you just don't understand the scope of the task)