Recent Features
| |||||||||||||
Shuttleworth: Quality has a new nameShuttleworth: Quality has a new namePosted Apr 25, 2012 4:00 UTC (Wed) by Cyberax (✭ supporter ✭, #52523)In reply to: Shuttleworth: Quality has a new name by paravoid Parent article: Shuttleworth: Quality has a new name
Well, Ubuntu, SUSE, RedHat (CentOS, Fedora) and Debian are the main distributions. Everything else is negligible.
Out of these three, only Ubuntu is not committed to systemd.
You might also note, that Debian isn't really committed to upstart also. They support the bad old SysV scripts as well.
(Log in to post comments)
Shuttleworth: Quality has a new name Posted Apr 25, 2012 8:24 UTC (Wed) by paravoid (subscriber, #32869) [Link]
Wow, that's an interesting way of counting...
For the sake of simplifying your argument, let's keep your definition of a major distribution (fwiw, I wouldn't count openSUSE).
So, out of "Ubuntu, SUSE, RedHat (CentOS, Fedora) and Debian", the set of distros that have chosen systemd as their new generation init system is "SUSE and RedHat (CentOS, Fedora)".
That's a fact. How can this be interpreted as "almost all major Linux distributions"? If it can, then by the same definition can also be interpreted as "almost none of the major Linux distributions" :)
init in Debian Posted Apr 25, 2012 12:58 UTC (Wed) by rleigh (subscriber, #14622) [Link]
> You might also note, that Debian isn't really committed to upstart also.
> They support the bad old SysV scripts as well.
Work is going on to enable sysvinit to run upstart jobs, which will enable packages to start providing upstart jobs in place of/in addition to init scripts. I'm not sure it's the best plan, but I'll accept it rather than stand in the way of preventing the adoption of better init systems. It's already in sysvinit git; it's not enabled yet due to requiring some additional changes.
However, it turns out that systemd does a much better job of sysvinit compatibility than upstart, which will make it much easier for Debian to transition to systemd rather than upstart. There's no need to replace the sysvinit scripts.
I've been doing a lot of work on sysvinit/initscripts to make it much easier to transition between sysvinit and systemd, as well as to support some of the features offered by systemd. While Debian will be using sysvinit for wheezy, switching is certainly something that could be considered for the following stable release.
A big black mark against systemd is the upstream attitude to non-Linux ports. If it wasn't so awful, we might have been in a position to push for its adoption in wheezy. As it is, that was untenable. While systemd uses Linux-specific features heavily, just having it /work/ on non-Linux, albeit without all the features being available, would be desirable. The attitude of not even being willing to consider patches for non-Linux platforms is a non-starter. Support for non-Linux platforms is also useful for portability to other versions of Linux which don't have all the specific features systemd requires--there's no need to paint ourselves into a corner of incompatibility through mandatory use of Linux-specific features.
Regards,
init in Debian Posted Apr 25, 2012 13:02 UTC (Wed) by mjg59 (subscriber, #23239) [Link]
Openssh is OpenBSD specific, with a separate team responsible for producing a portable fork. It seems a little odd to criticise systemd for doing much the same thing.
init in Debian Posted Apr 25, 2012 13:22 UTC (Wed) by rleigh (subscriber, #14622) [Link]
Why? They are both exceptions to the rule, and both are deserving of criticism here. Not actively working on portability is one thing, but being unwilling to consider patches from others to make it portable is quite another.
init in Debian Posted Apr 25, 2012 13:27 UTC (Wed) by mjg59 (subscriber, #23239) [Link]
Portability comes at a cost, and it's a completely rational choice for the people who maintain a project to be unwilling to accept that cost. Maintaining a separate portable branch seems to be a perfectly reasonable compromise.
init in Debian Posted Apr 25, 2012 13:46 UTC (Wed) by rleigh (subscriber, #14622) [Link]
While portability certainly does have a cost, it is a cost most projects are willing to pay. It's not usually that great--we're not talking about anything other than POSIX portability, after all. From what I can tell, this mainly centres around making cgroups optional. That's useful to have even on Linux. Being unwilling to accept patches from other people who are willing to do the porting work is entirely counter-productive.
There's also a significant cost placed on porters by being forced to work out of the main tree. This also needs consideration.
init in Debian Posted Apr 25, 2012 13:54 UTC (Wed) by mjg59 (subscriber, #23239) [Link]
The work the porters have to do is work that the maintainers would have to do otherwise. Requiring that the trees be separate is merely a way of ensuring that the work is done by the people who benefit, not the people who don't care.
init in Debian Posted Apr 25, 2012 14:37 UTC (Wed) by mezcalero (subscriber, #45103) [Link]
I said this before, and I am saying this again. That we as upstream don't care about portability patches to other kernels is a fake problem for you. Porting systemd is not really feasible, because we want our stuff simple, and clean, and small and hence use the Linux APIs directly instead of creating a huge abstraction for them. And that's your actual problem! You can't even get to the point where you could submit a portability patch, that we then could refuse to merge!
And even if you could write a portability patch, then in times of git it would be really easy to maintain it even out-of-tree.
Anyway, summary is: your problem is the technical unfeasibility of a port to freebsd, it's not our political dislike for such a patch and the maintainance burden.
If debian one day would like to go for systemd but at the same time still wants to go on with kfreebsd, then it has to pay the price for it, and just ship both init scripts and unit files in the packages. In fact we made this nice and easy by transparently overriding sysv scripts with native files if both exist.
Lennart
init in Debian Posted Apr 25, 2012 15:30 UTC (Wed) by Zack (guest, #37335) [Link] > because we want our stuff simple, and clean, and small and hence use the Linux APIs directly
$apt-get moo
(__)
(oo)
/------\/
/ | ||
* /\---/\
~~ ~~
Please note how the above cow is distinctly *not* spherical.
init in Debian Posted Apr 25, 2012 15:43 UTC (Wed) by dgm (subscriber, #49227) [Link]
If Systemd is not really portable, have you considered making it as easy as possible to create compatible work-alikes?. It's perfectly possible that the BSDs will eventually try to do something similar. Being completely compatible would be a huge boon for both (and would remove a big hurdle in the path to Debian).
init in Debian Posted Apr 25, 2012 15:54 UTC (Wed) by dgm (subscriber, #49227) [Link]
I know, I'm retarded, because they already thought of that and It didn't cross my mind to check it beforehand: http://www.freedesktop.org/wiki/Software/systemd/Interfac...
Sorry for the noise.
init in Debian Posted Apr 25, 2012 15:58 UTC (Wed) by mpr22 (subscriber, #60784) [Link] Well, there is the interface stability promise, which seems at least somewhat helpful in this regard.
init in Debian Posted Apr 25, 2012 21:20 UTC (Wed) by slashdot (guest, #22014) [Link]
Stop saying this, it's just totally stupid, and hurts systemd adoption for no reason.
It's pretty obvious that it is possible to create a systemd compatible init for any OS, whether by porting the existing systemd or writing a new implementation, since nothing important is fundamentally tied to Linux.
There's also no point in rejecting a well-written non-intrusive portability patch (where "non-intrusive" means that it mostly consists of new files implementing Linux APIs for $OS, with minimal changes to systemd only where absolutely necessary).
Instead, please try to push it in Debian at all costs (possibly including doing a FreeBSD port yourself), since once Debian adopts it, the morons at Ubuntu will be forced to adopt it too, and sysvinit and upstart will finally die forever.
init in Debian Posted Apr 25, 2012 22:05 UTC (Wed) by mpr22 (subscriber, #60784) [Link] The inescapable process grouping is important (it seems to me the second most attractive feature after the whole "simple cases are much simpler" effect from the declarative config). Does any kernel other than Linux provide a comparable feature with close-enough semantics? Are the maintainers of any kernel other than Linux contemplating providing such a feature?
init in Debian Posted Apr 25, 2012 23:07 UTC (Wed) by mathstuf (subscriber, #69389) [Link]
<idea category="crazy">
On FreeBSD, the system could just set up a jail for each service. Mount filesystems as nullfs (for bonus points, be smart about ro and rw directory mounting[1]). It would need some changes so that the jail has the same IP and network view as the main system, but that might be minor compared to what a full cgroups implementation would be like.
[1]The .service file could even have this information and then systemd could set up top-level filters for open; FreeBSD would get it for "free" under the jails with selective mounts while Linux would need syscall filtering or automatic LXC creation.
init in Debian Posted Apr 25, 2012 23:32 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
Uhm. You might check the recent systemd.
It does filesystem confinement just fine (using cgroups), along with secure per-app /tmp.
init in Debian Posted Apr 26, 2012 2:48 UTC (Thu) by mathstuf (subscriber, #69389) [Link]
Ah, didn't know that.
|
|||||||||||||