* Greg KH <gregkh@suse.de> [2011-06-17 17:14]:
On Fri, Jun 17, 2011 at 04:33:58PM +0200, Guido Berhoerster wrote:
* Kay Sievers <kay.sievers@suse.de> [2011-06-16 16:20]:
and with Debian and Ubuntu two major distros have already opted out of that.
'That' means systemd? Debian is very active in systemd development, and Ubuntu hasn't decided anything, besides the fact that the original author from Canonical has left, and is no longer developing Upstart.
AFAIK Debian plans to offer it as an option but as default due to systemd being Linux-only,
Debian offers _everything_ as an option, so that's not an issue here.
from a quick glance at the upstart repo it seems that upstart is actively maintained.
It has minor bug fixes but no new development. It is essentially end-of-life.
Do you have any facts to back that up or is it just wishful thinking?
So the major distributions participating in this "standardiaztion" seem to be Fedora, oS, and possibly Mageia/Mandriva.
You forgot about Gentoo and Arch and a raft of other minor distros that have all contributed to systemd development and integrated it into their systems already.
So please, this isn't an issue at all, the entire rest of the Linux community is moving to systemd, as a chance to standardize a lot of the cross-distro differences, we can not, and should not, ignore that at all.
I have strong doubts given the above and based on how earlier efforts like this went. But right that's not the main issue here.
Sure the agendas of a whole lot of people. Like every actively maintained project.
Systemd tries to solve the system service management, not just to replace init. It was clear from the beginning, and it wasn't started to just replace SYSV. It will be some sort of a base system on its own.
Judging by the current speed of adoption by distros, and the dropping of SYSV support by many of them, and the pressure coming from the enterprise people for advanced features, I don't think there is much to discuss on the general direction in the future, unless someone comes up with something else on top the current stuff.
Anyway, better join the development now, if you don't like the direction and want to influence things.
I guess that would not be very fruitful since I have rather fundamental concerns about the architecture and scope an init-replacement for openSUSE should have. While systemd certainly provides some attractive features over plain sysvinit such as automatic cgroup assignment and process supervision (the latter of which can of course also be provided by runit or deamontools on top of sysvinit or fsc on top of FreeBSD rc), the monolithic design and centralization of functionality to replace all kinds of unrelated things (handling mounting, LUKS encrypted volumes, changing system locale, time, and hostname, ConsoleKit, per-user session-handling etc.) is IMO a bad idea in terms of security, flexibility, and long-term maintainability (and ripping out systemd in order to replace it with the next big thing will not be fun). It is particularly inflexible and intransparent to admins who want to customize or change all the built-in functionality are now forced to read/write C code for that rather than being able to modify a simple shell script.
Care to propose a valid alternative then? Just "not liking it" isn't really an acceptable critique.
I don't see why I have to provide an alternative in order to express some criticism about the architecture and scope of systemd. We currently have a working init system (though it could use considerable improvements), YaST can manage hostname, locale, and time just fine, ConsoleKit and desktop session management also works more or less well. In fact I would be interested in improving the current startup scripts, switch to a faster and smaller shell or incorporating process supervision. And to repeat myself once again we're not talking about replacing our init daemon but rather an invasive piece of software which goes far beyond the scope of just bootup and service management but aims to replace siginificant parts of the system that are currently made up of specialized tools.
In different usage screnarios such as a e.g. web or DB server systemd carries around a complex codebase with a lot of useless functionality and dependencies which cannot be easily stripped off.
Why would you want to strip it off? And it's not more complex than other parts of our startup code at all.
In order to minimize attack vectors, and yes it is considerably more complex because it incorporates lots of functionality which is totally useless in such scenarios (in particular but not only all the stuff not related to bootup and sevice management).
It also forces one to run DBus which serves no useful purpose on a server but needlessly adds a new potential attack vector.
dbus is already running on your server, and will be in your kernel soon, so what's the problem here with it? It's been audited numerous times, and sure, there might be a bug in it or two, but it is one of the most reviewed pieces of code on your system than anything else.
No, DBus is not running on my servers because it does not provide any useful functionality there but would just create additional risk. CVE-2011-2200 is from Monday, software always has bugs. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org