| |||||||||||||
Some changes needed...Some changes needed...Posted Nov 27, 2012 19:26 UTC (Tue) by mathstuf (subscriber, #69389)In reply to: Some changes needed... by Zack Parent article: Langasek: Upstart in Debian
> In my opinion the only way to ever reach such ubiquity is if one particular distribution gets Apple or MS size marketing behind it, and as such it would dwarf all the others into relative obscurity anyway, making any sort of incompatibilities moot, since whatever is in that distribution is what the proprietary ISPs will package for.
And since only Google (and possibly Canonical, but their success isn't as apparent to most) is doing this so far and their direction doesn't really include my general computer use cases (AFAIK), we may as well work on things we can change (which tend to be the technical side of things).
> Technical excellence will only get an OS so far, and any tweaking in the margins -- by shaving yet another few seconds off booting or having a standardised init system -- isn't going to make a platform more popular.
Agreed. However, there's always the chicken-and-egg problem. Without a standard and reliable init system, we might not get the attention of third parties. Without the third parties, we lose potential users. *Something* needs to give somewhere for things to change. The faster boot is a nice side effect, but it certainly isn't the end goal.
> if a main author of a project basically concedes there's no point in sending in patches concerning portability because the software is too specific
As with anything, lines need to be drawn somewhere. Are you going to support Linux 2.4? FreeBSD 7? VAX? Windows? 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? Drop it and systemd isn't really portable anyways since it wouldn't be able to give the same guarantees about stopping services on BSD as it could on Linux. All that does is push the portability burden onto the services which expect it to exist. At this point, it might be easier to provide the cgroups API on BSD or to get something done which does things equivalently with an interface acceptable for BSD and then offer that on Linux as well.
(Log in to post comments)
Some changes needed... Posted Nov 27, 2012 22:34 UTC (Tue) by Zack (guest, #37335) [Link]
>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.
>As an example, some of the features systemd provides expect something like the cgroups API to exist.
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.
Some changes needed... 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.
Picked a story for you: http://0pointer.de/blog/projects/cgroups-vs-cgroups.html
(Hint: if you don't know how "systemd" and "cgroups" relate, googling for both terms might help.)
Some changes needed... Posted Nov 28, 2012 16:50 UTC (Wed) by nye (guest, #51576) [Link]
>Picked a story for you: http://0pointer.de/blog/projects/cgroups-vs-cgroups.html
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.
|
|||||||||||||