Mailinglist Archive: opensuse-factory (710 mails)

< Previous Next >
Re: [opensuse-project] Re: [opensuse-factory] The road to systemd for openSUSE 12.1
  • From: Guido Berhoerster <gber@xxxxxxxxxxxx>
  • Date: Fri, 17 Jun 2011 19:20:52 +0200
  • Message-id: <20110617172052.GD5937@wopr.local.invalid>
* Kay Sievers <kay.sievers@xxxxxxx> [2011-06-17 17:06]:
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. 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.

Absolute nonsense. You have not even looked how systemd works. There is
nothing to write in C, and scripts work like any other program works on
the system.

I know you can run scripts from unit files, except that all the
functionality which has now been centralized and implemented
within systemd cannot be easily manipulated and scripted as
before. The recent inconsistency is fstab parsing is a symptom
why duplicating functionality is a bad idea.

Bootup is about service dependency, which includes full hotplug support,
mounting of volumes, early host, locale, network setup, and all that.

Right, I was not talking about bootup but the management of
locale, time, and hostname thorugh systemd. Or replacing
ConsolKit, or managing user sessions and other stuff which has
nothing to do with bootup and management of system services.

Current usual systems can not even mount a system disk that is plugged
in after boot. It just didn't work at all before systemd, not a single
working alternative besides partly Upstart was out there that could do
what we need today.

Hm, care to elaborate? Also, I don't think handling that should
be the task of a service manager.

It also forces
one to run DBus which serves no useful purpose on a server but
needlessly adds a new potential attack vector.

That's not true, systemd does not need the D-Bus server. You can even
boot up without D-Bus if you have a systems that does not have D-Bus
users. Systemd itself uses only private sockets and uses the D-Bus wire
protocol, but not D-Bus as a service.

OK, I suppose the dependency on the dbus-1 package is an
openSUSEism then.

--
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