* Kay Sievers <kay.sievers@suse.de> [2011-06-16 15:09]:
We expect 'proper' services to have their own config files, and not let every distro invent their own options on top in some additional file. Most services work that way, and it's just good enough.
In short, 'foo' should have a native /etc/foo/config instead of /etc/sysconfig/foo. That will be the same on any system, any Linux, any distro. Yast should be able to edit this file, if needed, not bring its own files.
Some of the sysconfig options can be imported into the environment with the systemd service file.
Some services which still rely on weird sysconfig options SUSE invented will need to be started by a shell script wrapper.
In the future we want /etc/defaults and /etc/sysconfig, and all the other friends distros invented to die. :)
Different distros have different policies and objectives which is why such efforts have failed before, and with Debian and Ubuntu two major distros have already opted out of that. Information in /etc/sysconfig also does not necessarily only contain configuration information specific to a service but also information on how to manage that service (my own /etc/sysconfig/zfs-fuse comes to mind and there are others). And how is all this supposed to integrate with YaST?
To systemd maintainers: 2) While I agree with systemd's performance goals and recognise the persuasive narrative for the socket activated design in the LP blog series, I hear that it additionally replaces other parts of userland. Massive uncertainty rules in my head about what those are and the wider effects of those changes.
As an example, http://lwn.net/Articles/441328/ mentions that there are plans to remove ConsoleKit and merge its functionality into a systemd helper daemon. What changes of this type to the runtime platform are implied by systemd that would affect eg a KDE session (other than https://bugzilla.novell.com/show_bug.cgi?id=655141) , and who is planning to do the work to adapt to those?
It's all optional for now. The 'systemd --user' part will land in the next weeks. It already kind of works.
The session tracking is also already part of systemd proper and will land in the next weeks. It will include out-of-the box multi-seat setup, where USB graphic+keyboard+mouse+sound adapter plugged in, will create a new seat with a login manager running on it.
Existing users can still pull-in the current ConsoleKit and don't need to switch now. The stuff will just run in parallel.
For GNOME it is planned to switch gnome-session over to systemd bit-by-bit, but it will take its time until 'systemd --user' will be any harder requirement. It might just happen by the fact that people doing the work don't run non-systemd systems anymore.
But stuff that works today should not stop working. It might just be, that in the background systemd is doing some stuff for sessions (like ConsoleKit) that is not used by anything.
One example why committing to systemd is not simply about switching the init daemon. And it seems from the responses on the Fedora and GNOME lists that I'm not the only one getting the impression that systemd employs technology to push personal and political agendas. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org