Mailinglist Archive: opensuse-factory (710 mails)

< Previous Next >
Re: [opensuse-factory] The road to systemd for openSUSE 12.1
  • From: Guido Berhoerster <gber@xxxxxxxxxxxx>
  • Date: Thu, 16 Jun 2011 15:56:07 +0200
  • Message-id: <20110616135607.GC2596@wopr.local.invalid>
* Kay Sievers <kay.sievers@xxxxxxx> [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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-factory+help@xxxxxxxxxxxx

< Previous Next >
This Thread
Follow Ups