>As with anything, lines need to be drawn somewhere. Are you going to support Linux 2.4? FreeBSD 7? VAX? Windows?
True, but "nothing but (current) linux, and all linux platforms should use this" is just drawing that line in a circle around yourself.
By my standards that's acceptable for a quickly thrown together proof-of-concept mailclient, but not really for the init system we're all to use.
>As an example, some of the features systemd provides expect something like the cgroups API to exist.
>What (existing) interface would you propose is used on BSD instead?
That would be up to the BSD developers, once they inescapably see the light. But up until that point it would be good form to just have systemd default to a bog standard portable init wherever its highly specialised features are not available so hackers everywhere can at least attempt to bring such glory to their system and meantime be able to boot.
>we may as well work on things we can change (which tend to be the technical side of things).
I guess that's as true as anything written in this thread. "Be the change you want to see in the world", or something like that.
Posted Nov 27, 2012 23:54 UTC (Tue) by Eckhart (guest, #74500)
[Link]
> But up until that point it would be good form to just have systemd default to a bog standard portable init wherever its highly specialised features are not available so hackers everywhere can at least attempt to bring such glory to their system and meantime be able to boot.
Why is this so hard to understand? systemd fundamentally depends on concepts like cgroups, they are not just an afterthought. Just have a look at the code.
Or, as an analogy: a team of engineers are building a maglev train. You are telling them to add wheels and a diesel engine, so it can also run on conventional tracks. Sure, it might be possible to add this stuff: by increasing costs per unit, ruining the design and reducing the maximum speed the train is able to travel because of the weight of the diesel engine.
Some changes needed...
Posted Nov 28, 2012 0:02 UTC (Wed) by dlang (✭ supporter ✭, #313)
[Link]
> systemd fundamentally depends on concepts like cgroups
however when people complain about how systemd should not be considered to be the standard init because it requires cgroups, which impose a significant performance hit on current systems, the answer that we get is that cgroups are an optional feature, systemd will work without cgroups, just not as well.
you can't have it both ways, pick a story and stick with it.
Some changes needed...
Posted Nov 28, 2012 0:43 UTC (Wed) by mathstuf (subscriber, #69389)
[Link]
I think the specifics are that cgroups have to be available, but not fully enabled. From the README:
> with cgroups (but it's OK to disable all controllers)
I would assume that cgroups still offers the process grouping functionality, it just can't do per-group rlimits.
Some changes needed...
Posted Nov 28, 2012 2:02 UTC (Wed) by Eckhart (guest, #74500)
[Link]
> however when people complain about how systemd should not be considered to be the standard init because it requires cgroups, which impose a significant performance hit on current systems, the answer that we get is that cgroups are an optional feature, systemd will work without cgroups, just not as well.
> you can't have it both ways, pick a story and stick with it.
That document says "if you...disable the grouping feature entirely (A) then systemd will loudly complain at boot and proceed only reluctantly with a big warning and in a limited functionality mode". That sounds a lot like "a bog standard portable init wherever its highly specialised features are not available", which you claimed was impossible.
Some changes needed...
Posted Nov 28, 2012 19:15 UTC (Wed) by Eckhart (guest, #74500)
[Link]
> That document says "if you...disable the grouping feature entirely (A) then systemd will loudly complain at boot and proceed only reluctantly with a big warning and in a limited functionality mode". That sounds a lot like "a bog standard portable init wherever its highly specialised features are not available", which you claimed was impossible.
According to systemd developers "limited functionality mode" means "expect breakage" and "might allow you to compile a kernel with cgroups if you are lucky".
Some changes needed...
Posted Nov 28, 2012 14:31 UTC (Wed) by HelloWorld (guest, #56129)
[Link]
> True, but "nothing but (current) linux, and all linux platforms should use this" is just drawing that line in a circle around yourself.
I don't see a reason to make init portable. sysvinit is portable, but who actually uses it on anything but Linux? Nobody, because pretty much every other Unix out there has its own init, and they're certainly not all portable (cf. SMF on Solaris). And the BSD people won't adopt systemd anyway due to the license.
Also note that while systemd's implementation isn't portable, its interfaces are, so nothing stops a vendor from implementing a systemd clone for their OS.