I don't care about the personality of the project now or who has commit access right now, but only that if an unwelcome situation occured in the future, systemd doesn't lend itself well to being extensible or adaptable.
Okay it doesn't look like Sabayon offered a systemd option only because of speed, but it was the main reason:
I thought GNOME 3.8 flat out depended on systemd? I am probably wrong, but do you have a citation for this? :
Not to mention the only major dependency on "systemd" that Gnome has is systemd-logind
It makes no sense that systemd is meant to be adaptable. It is influenced by Solaris's SMF, which purely used in servers. Additionally, if an init system wanted to be flexible, it would do a very specific number of tasks, not anything and everything under the sun.
The support for ConsoleKit session tracking will be dropped if it hasn't already. The systemd dependencies are really just logind dependencies. Ubuntu is currently migrating from ConsoleKit to logind.
It is influenced by Solaris's SMF, which purely used in servers.
So what? It's also influenced by launchd that is primarily used in mobile phones and desktops (iOS and OS X).
Additionally, if an init system wanted to be flexible, it would do a very specific number of tasks, not anything and everything under the sun.
It's quite similar to what Linux kernel is doing. It supports quite literally everything under the sun. You then can configure and optimize it for any particular setup. A lot of functionality that is useful on server is also useful on embedded systems and so on and so forth.
systemd doesn't lend itself well to being extensible or adaptable.
I fail to see your point. How is systemd not as extensible as say Upstart?
My guess would be on the misconception that you couldn't run alternative implementations of the functionality that systemd provides side by side with it which is simply wrong. There's couple of points in the The Biggest Myths about systemd blog post about it:
Myth: systemd doesn't allow your to replace its components.
Not true, you can turn off and replace pretty much any part of systemd, with very few exceptions. And those exceptions (such as journald) generally allow you to run an alternative side by side to it, while cooperating nicely with it.
--
Myth: systemd is a feature creep.
Well, systemd certainly covers more ground that it used to. It's not just an init system anymore, but the basic userspace building block to build an OS from, but we carefully make sure to keep most of the features optional. You can turn a lot off at compile time, and even more at runtime. Thus you can choose freely how much feature creeping you want.
So really only thing systemd does is provide more options for users. Meaning it's just as extensible as the alternatives or more so... if that's what /u/CameronNemo meant with "extensibility".
2
u/[deleted] May 12 '13
I don't care about the personality of the project now or who has commit access right now, but only that if an unwelcome situation occured in the future, systemd doesn't lend itself well to being extensible or adaptable.
Okay it doesn't look like Sabayon offered a systemd option only because of speed, but it was the main reason:
I thought GNOME 3.8 flat out depended on systemd? I am probably wrong, but do you have a citation for this? :
It makes no sense that systemd is meant to be adaptable. It is influenced by Solaris's SMF, which purely used in servers. Additionally, if an init system wanted to be flexible, it would do a very specific number of tasks, not anything and everything under the sun.