On Sat, Jun 11, 2011 at 10:41:56AM +0200, Guido Berhoerster wrote:

* Frederic Crozat [2011-06-10 19:04]:

...

systemd is coming for next openSUSE (12.1) scheduled next fall.

As far as I'm aware there was only one recent discussion on this this list about it [1] which started with the premise that systemd will be the default for 12.1. I'd like to know who has decided when and for what reasons that systemd will be the default for 12.1? More specifically, what alternatives were considered and why and how is systemd serving the openSUSE project better in the long term?

There is only one alternative, and that package is no longer being maintained or developed, so there really isn't anything else to choose from. As for why to switch, you did read the long series of posts about systemd for admins, right? All of those things are stuff that users want, and care about, why would we not provide them?

I admit that I disapprove of its approach to cram everything but the kitchen sink into an init daemon (including stuff completely unrelated to init such as (auto)mounting, handling LUKS volumes, controlling the system locale, time, and hostname, replacing ConsoleKit, or the planned per-user session-startup functionality) rather thank keeping it simple and doing one thing well (a design philosophy which has served Un*x systems rather well in terms of functionality, security, and sustainability of codebases). So far it's not even clear where this will end.

It does one thing well, the rest is supported by helper scripts and plugins. Do you have an alternative that you think should be used instead? And note, we aren't talking about taking away the choice to use systemv from what I can tell, you can always go back to that if you want to for some reason. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Sat, Jun 11, 2011 at 08:28:39PM +0200, Guido Berhoerster wrote:

* Greg KH [2011-06-11 18:39]:

...

On Sat, Jun 11, 2011 at 10:41:56AM +0200, Guido Berhoerster wrote:

...

* Frederic Crozat [2011-06-10 19:04]:

...

systemd is coming for next openSUSE (12.1) scheduled next fall.

As far as I'm aware there was only one recent discussion on this this list about it [1] which started with the premise that systemd will be the default for 12.1. I'd like to know who has decided when and for what reasons that systemd will be the default for 12.1? More specifically, what alternatives were considered and why and how is systemd serving the openSUSE project better in the long term?

There is only one alternative, and that package is no longer being maintained or developed, so there really isn't anything else to choose from.

As for why to switch, you did read the long series of posts about systemd for admins, right? All of those things are stuff that users want, and care about, why would we not provide them?

This was not about offering systemd as an option, but part of the proposal ("phase 3") was to replace SysV init files with native systemd files. And an init daemon is not any arbitrary package, fully comitting to an implementation has long-term consequences. Hence, I would expect some kind of decision-making based on some real considerations rather than just following the latest buzz and the quite vocal promotion of its author.

And how do you know that was not done already? And also, please always remember, that changes happen here by people doing the work, not by people sitting around and discussing things, or dissing things. Do you not trust the developers involved to get this working correctly? If so, offer to help out. If not, well, that's a different problem...

...

...

I admit that I disapprove of its approach to cram everything but the kitchen sink into an init daemon (including stuff completely unrelated to init such as (auto)mounting, handling LUKS volumes, controlling the system locale, time, and hostname, replacing ConsoleKit, or the planned per-user session-startup functionality) rather thank keeping it simple and doing one thing well (a design philosophy which has served Un*x systems rather well in terms of functionality, security, and sustainability of codebases). So far it's not even clear where this will end.

It does one thing well, the rest is supported by helper scripts and plugins.

Do you have an alternative that you think should be used instead?

I'd really like to have an answer to my initial questions (including why we have to switch the default init system at all right now).

Because what we have right now sucks. Seriously, it does, it was great for the 70's and 80's when things were static, but now, it makes absolutly no sense whatsoever. Linux has been evolving to support this type of dynamic, use only what you need when you need it, type of a system for a very long time now, and this is just one piece of that progression that has been needing to change for a very long time.

But the alternatives I am aware of are sysvinit which we are using right now and upstart, given the (im)maturity of systemd, the lack of clarity where the scope of systemd will eventually end, and my aforementioned concerns I'd consider both of these the lesser evil.

So what would make systemd somehow "mature" in your eyes? A major distro shipping it as their default init system? The developers working on it paid to do nothing else but support it and guarantee that it works properly for everyone? Or something else? Oh, and upstart is a dead-end project, so that's not even an option, sorry. greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Sun, Jun 12, 2011 at 09:52:45AM +0200, Guido Berhoerster wrote:

Yeah it sucks, and it has for a long time compared to its alternatives and I'm also familiar with SMF on Solaris, rc on FeeBSD and its modernization efforts[1], as well as upstart on Ubuntu. I'd still be interested in the reasoning why we have to switch right now and why it has to be systemd.

Why now? Upstream claimed it is enough stable and feature complete, it has been already released in Fedora 15, so will be here any better time in future? And of course, having it enabled by default earlier in Factory would help with bugfixing a lot. From administrator point of view is the most important it provides the simple access to majority Linux features - cpu schedulers, io scheduling, cgroups, pam, process namespaces and so and so [1] With systemd you can disable, change or override the vendor suppliend service. Nothing will prevents you to create your own sshd.service, which will be never replaced on package upgrade like /etc/init.d/sshd. Having the same way how the service is started independently on the way how the start is triggered is unique - now you have to maintain init script and (x)inetd configuration file separate. With systemd whatever-activation will turn on the same .service file. Usage of cgroups makes the system much robust and prevents you from mistakes like killall in one init script will kill all instances of daemon. And with the easy of creating your own variants of init scripts, you can very easy maintain more instances of one service. And yes, when the whole logic of service run/start/restart is now a part of systemd, so no need to reimplement it again and again. There are of course more features, like socket-based activation, paralel start, no need of fork, clean execution environment, having a great cross-distro consolidation [2] (because it contains tools like) and so, but I hope this is enough for you. [1] http://0pointer.de/public/systemd-man/systemd.exec.html [2] http://0pointer.de/blog/projects/the-new-configuration-files.html Regards Michal Vyskocil

On Mon, 2011-06-13 at 16:23 +0200, jdd wrote:

Le 13/06/2011 14:24, Michal Vyskocil a écrit :

...

And yes, when the whole logic of service run/start/restart is now a part of systemd, so no need to reimplement it again and again.

in early SuSE times, the manual had a *very good* initscript description.

We probably need the same thing for systemd. May be it's already done (where?)

a question directly on subject: the init scripts are treated differently from distro to distro (debian init 3, 5... are not the openSUSE ones). Is it the same for systemd or is the interface unified? this would be a great enhancement for people having to manage different distros.

There are no native run-levels in systemd. It can have any number of 'sets of services', whicyh are called targets and have textual names. The default systemd targets are the same on all distros. Native service files have no notion of a SYSV runlevels, they hook only into systemd targets. The runlevel mapping in systemd only affect SYSV compatibiliy which will go away over time. Some of the smaller, embedded-focused, or newer distros already switched to systemd and dropped (compile switch) SYSV support entirely. The concept of runlevels will fade out over time. Kay -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

* Michal Vyskocil [2011-06-13 14:25]:

On Sun, Jun 12, 2011 at 09:52:45AM +0200, Guido Berhoerster wrote:

...

Yeah it sucks, and it has for a long time compared to its alternatives and I'm also familiar with SMF on Solaris, rc on FeeBSD and its modernization efforts[1], as well as upstart on Ubuntu. I'd still be interested in the reasoning why we have to switch right now and why it has to be systemd.

Why now? Upstream claimed it is enough stable and feature complete, it has been already released in Fedora 15, so will be here any better time in future? And of course, having it enabled by default earlier in Factory would help with bugfixing a lot.

From administrator point of view is the most important it provides the simple access to majority Linux features - cpu schedulers, io scheduling, cgroups, pam, process namespaces and so and so [1]

With systemd you can disable, change or override the vendor suppliend service. Nothing will prevents you to create your own sshd.service, which will be never replaced on package upgrade like /etc/init.d/sshd.

Having the same way how the service is started independently on the way how the start is triggered is unique - now you have to maintain init script and (x)inetd configuration file separate. With systemd whatever-activation will turn on the same .service file.

Usage of cgroups makes the system much robust and prevents you from mistakes like killall in one init script will kill all instances of daemon. And with the easy of creating your own variants of init scripts, you can very easy maintain more instances of one service.

And yes, when the whole logic of service run/start/restart is now a part of systemd, so no need to reimplement it again and again.

There are of course more features, like socket-based activation, paralel start, no need of fork, clean execution environment, having a great cross-distro consolidation [2] (because it contains tools like) and so, but I hope this is enough for you.

I know the features systemd provides, some seem genuinely useful while for others I'd dispute whether they are actually features (e.g. making scripting harder) or even belong into an init system and whether a significant amount of functionality not related to init should be centralized this way, even if not all of it is performed by pid 1 (see my other mail). In terms of functionality it goes far beyond that and even its main developer acknowledges that and so far it is not yet in sight where the scope of systemd will eventually end, e.g. AFAICS replacing ConsoleKit and providing some user session management functionality a la launchd seem to be next on the agenda. As far as cross-distro consolidation goes I'm sceptical as well, it does not seem like Debian or Ubuntu will use it as the default init system any time soon. Anyway, since such a decision has implications for the whole distribution and its direction due to the associated costs of switchting to it and possibly away from it in the future I would expect some deliberation based on technical grounds in public _before_ making that decision including an evaluation of the alternatives, reasoning why it is desirable to fully commit to it right now (as opposed to providing optional support), associated costs, reasoning why it is in the interest of openSUSE etc. So far I haven't been able to find any such deliberation or even a simple discussion about making a decision in whichever form, there are just several statements by SUSE employees which take it for granted that systemd will be the default in 12.1, this was my main point and is what irks me the most in this case. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Mon, Jun 13, 2011 at 06:45:33PM +0200, Guido Berhoerster wrote:

Anyway, since such a decision has implications for the whole distribution and its direction due to the associated costs of switchting to it and possibly away from it in the future I would expect some deliberation based on technical grounds in public _before_ making that decision including an evaluation of the alternatives, reasoning why it is desirable to fully commit to it right now (as opposed to providing optional support), associated costs, reasoning why it is in the interest of openSUSE etc. So far I haven't been able to find any such deliberation or even a simple discussion about making a decision in whichever form, there are just several statements by SUSE employees which take it for granted that systemd will be the default in 12.1, this was my main point and is what irks me the most in this case.

Hi Guido, first of all - I wrote only about fact it's good to have systemd in **Factory** enabled by default earlier than later. This will give us more time for testing and on the end we will have the hard facts to decide if it will make a sense enable it by default on 11.2 or not. This is similar to Linus's talk is cheap approach. Of course all people involved in systemd hopes it will be default in 11.2 - it does not make a sense to work on a project, when you don't trust it will be succesfull, right? For the rest, you wrote "there are just several statements by SUSE employees". Please be aware of that despite the part behind @ in our email, we are just the part of community like any other. At least me is telling only my POW here, but I'm sure that the rest of colleagues are doing the same. And my POW is simple - I am convinced systemd is a) better than any of sysvinit alternatives like upstart, runit, init-ng or whatever else I checked and read some documentation, b) is the future of Linux world. I don't care about costs (if you mean the mapower as a cost), because it will take a little time from me to support that. So I'm open to support it. But if you see a need for such decission making process before, then it's up to you as a part of community, because I (and probably others) see no need for it. IOW if you want such process, then you have make it. I would say you should ask openSUSE Board [1] for help. [1] http://en.opensuse.org/openSUSE:Board_2010 Best Regards Michal Vyskocil

On 06/13/2011 07:54 PM, Felix Miata wrote:

On 2011/06/13 14:24 (GMT+0200) Michal Vyskocil composed:

...

Upstream claimed it is enough stable and feature complete, it has been already released in Fedora 15, so will be here any better time in future?

KDE claimed 4.2, 4.3, 4.4 & 4.5 were ready too. Even 4.6 lacks features I depend on in 3.5.x.

Saying something is good enough for Fedora is no recommendation, particularly WRT this particular fundamental base system change. Most traffic on Fedora's devel & test lists since last fall are about systemd or its fallout, particularly for attempts to upgrade from F14.

A better time would be after catching up from the post-11.0 and post-SaX2 Xorg, libata, pulseaudio, KDE4 & KMS foibles, and making sure Gnome 3 is actually good enough for ordinary people using Gnome 2 to upgrade to. There needs to be a release where all the important stuff just works, as in pre-10.1 days, like 10.2 & 11.0 only came close to doing, and others less.

...

And of course, having it enabled by default earlier in Factory would help with bugfixing a lot.

Early enough probably means the day immediately following the day the previous release's GM goes to the duplicators, along with a 15 month devel cycle. Since sysv has yet to be dumped I find it hard to imagine systemd being anywhere near openSUSE release ready by 12.1's scheduled release date.

I have zero faith that release next will be a good release, or one I can replace my already OOS 24/7 use 11.2 with. I'm spending more and more time dreading a search for something to replace openSUSE, zypper and YaST2 with, knowing already Debian, *buntu & Fedora aren't even close to considering. I wish I could take a nap lasting 2 years. Why don't you use SLED? It won't be shipped with systemd in the nearby future, it is supported for a long time, it should be stable and you would still have your familiar environment.

Tim -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Am 11.06.2011 21:53 schrieb Greg KH:

[...] Because what we have right now sucks.

Seriously, it does, it was great for the 70's and 80's when things were static, but now, it makes absolutly no sense whatsoever. Linux has been evolving to support this type of dynamic, use only what you need when you need it, type of a system for a very long time now, and this is just one piece of that progression that has been needing to change for a very long time.

So if I'm installing a web server machine with apache, it will boot quickly, but the first access to the server will take almost forever because nobody connected to port 80 before and thus apache wasn't started? Or does "use only what you need when you need it" not apply here (and if not, why)? Looking at http://0pointer.de/blog/projects/socket-activation.html it seems that systemd socket activation adds an additional overhead of a few context switches for every single connect. How big is the performance degradation for short-lived TCP and UDP connections in that case? Regards, Carl-Daniel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Wed, 2011-06-15 at 09:53 +0200, Frederic Crozat wrote:

Le mercredi 15 juin 2011 à 09:08 +0200, Carl-Daniel Hailfinger a écrit :

...

Am 11.06.2011 21:53 schrieb Greg KH:

...

[...] Because what we have right now sucks.

Seriously, it does, it was great for the 70's and 80's when things were static, but now, it makes absolutly no sense whatsoever. Linux has been evolving to support this type of dynamic, use only what you need when you need it, type of a system for a very long time now, and this is just one piece of that progression that has been needing to change for a very long time.

So if I'm installing a web server machine with apache, it will boot quickly, but the first access to the server will take almost forever because nobody connected to port 80 before and thus apache wasn't started? Or does "use only what you need when you need it" not apply here (and if not, why)?

Socket activation is mainly used to simplify service startup and to avoid to express any dependencies, and not about on-demand start. On a common systemd setup, there are almost zero dependencies to resolve, because all communication channels between services are established before any service is ever started. The kernel will just suspend the requesters until the real service is running. The same logic applies to filesystems access when systemd's automounter is used. Most common services are started just unconditionally, like they have been started since forever, regardless if there are traffic on the socket or not.

...

Looking at http://0pointer.de/blog/projects/socket-activation.html it seems that systemd socket activation adds an additional overhead of a few context switches for every single connect. How big is the performance degradation for short-lived TCP and UDP connections in that case?

Are you running apache behind xinetd ATM ? I don't think so. So I don't see why you would use socket-activation for apache server.

Right, if you run a real webserver, you don't run it inetd mode. Also, the overhead for native/non-inetd systemd socket activation is zero. Apache listens itself, it only gets the first connection passed, if configured to run with socket activation. SShd is a fine example, and there are not many, to run by default from systemd's inetd mode. On most workstations nobody ever logs-in over ssh, and it can be started on demand just fine. If you run a server, where users log-in over ssh all the time, you wouldn't run sshd in inetd mode there, but just enable the service unconditionally, so it is immediately ready when users connect. Kay -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Kay Sievers wrote:

On Wed, 2011-06-15 at 11:48 +0200, Kay Sievers wrote:

...

...

Le mercredi 15 juin 2011 à 09:08 +0200, Carl-Daniel Hailfinger a écrit :

...

...

...

So if I'm installing a web server machine with apache, it will boot quickly, but the first access to the server will take almost forever because nobody connected to port 80 before and thus apache wasn't started? Or does "use only what you need when you need it" not apply here (and if not, why)?

Socket activation is mainly used to simplify service startup and to avoid to express any dependencies, and not about on-demand start.

The other example of socket activation is package upgrades. When pid 1 keeps the socket established, you can replace packages without ever losing any new connection.

You don't need systemd for that though. Keeping sockets open across exec is an operating system feature. The hard part is restoring the application's state and that's nothing systemd can help with. From the top of my head I only remember irssi which can re-exec itself since ages without losing connections or state. It's embarassing that e.g. dbus updates require a system reboot but that's nothing systemd can magically solve.

With systemd you can even replace services like syslogd with a different implementation without ever losing a single message.

Well, I doubt that's relevant in practice and would only work for the local socket anyways. Kind of funny that you take syslog as example though since you only care about rsyslogd.

Services are also automatically restarted if a service crashes, without losing any new message submitted during the time the service was not available. Clients will never see connection refused.

These are mostly features enterprise users asked for, and what no other init can really provide or work around.

The plain old inetd could already do local socket activation¹. Maybe the name prevented people from using it for that purpose. Unfortunately xinetd lost the ability to use local sockets. Implementing it wouldn't be rocket science though. cu Ludwig [1] http://www.freebsd.org/cgi/man.cgi?query=inetd&sektion=8 -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Kay Sievers wrote:

On Thu, 2011-06-16 at 13:18 +0200, Ludwig Nussel wrote:

...

Kay Sievers wrote:

...

The other example of socket activation is package upgrades. When pid 1 keeps the socket established, you can replace packages without ever losing any new connection.

You don't need systemd for that though. Keeping sockets open across exec is an operating system feature. The hard part is restoring the application's state and that's nothing systemd can help with. From the top of my head I only remember irssi which can re-exec itself since ages without losing connections or state. It's embarassing that e.g. dbus updates require a system reboot but that's nothing systemd can magically solve.

We don't want any service besides pid 1 to re-ecec itself. It's just to fragile to get right. [...] You can upgrade/restart many services without interruption.

Maybe you didn't run "systemctl restart dbus.service" today to watch your login session collapse :-) No doubt that systemd taking care of listening sockets is useful for simple, more or less stateless services. Starting udevd that way isn't too impressive though. As soon as you have more connections and state information associated with the connections the application needs to do the hard work though, no matter whether started via systemd or not. Next dbus security update is already in the queue btw. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Thu, 2011-06-16 at 14:23 +0200, Anders Johansson wrote:

On Thursday 16 June 2011 14:04:47 Will Stephenson wrote:

...

3) What are the big gaps that it doesn't currently do, compared to sysvinit? I hear of things like encrypted LVM volumes not working being dismissed as unimportant. I'll start you off with "password agents to do interactive things during service startup, eg openvpn passwords" (bnc675406): http://www.freedesktop.org/wiki/Software/systemd/PasswordAgents

read-only /usr mounts I believe were dismissed as unimportant as well

They can't work reliably, and never worked reliably for any non-trivial setup. They did not in the recent past, and never will in the future. Anybody who still claims that hasn't look into any of the non-interesting details of the current reality. We just require that /usr is mounted from initramfs, when systemd is started, nobody cares where /usr comes from or if its writable. The time where we boot up with only 30% of the system available, start stuff referencing /usr and silently fail, but pretending stuff will still work, is now over. The real fix is to extend initramfs to provide that feature, and not to mindlessly move just another tool to the rootfs, and hope it will fix something. Today, people should see the initramfs is the 'rootfs', not some misguided idea about the split between /usr/bin and /bin and /usr/lib and /lib, ... It is planned, that in the future we will move the entire rootfs to /usr. The entire system will be contained in that (similar to what Android and MacOS have as /system) and the entire /usr can then be shared read-only. Kay -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Thu, 2011-06-16 at 15:01 +0200, Anders Johansson wrote:

On Thursday 16 June 2011 14:46:47 Kay Sievers wrote:

...

On Thu, 2011-06-16 at 14:23 +0200, Anders Johansson wrote:

...

On Thursday 16 June 2011 14:04:47 Will Stephenson wrote:

...

3) What are the big gaps that it doesn't currently do, compared to sysvinit? I hear of things like encrypted LVM volumes not working being dismissed as unimportant. I'll start you off with "password agents to do interactive things during service startup, eg openvpn passwords" (bnc675406): http://www.freedesktop.org/wiki/Software/systemd/PasswordAgents

read-only /usr mounts I believe were dismissed as unimportant as well

They can't work reliably, and never worked reliably for any non-trivial setup. They did not in the recent past, and never will in the future. Anybody who still claims that hasn't look into any of the non-interesting details of the current reality.

What fails? Can you give some relevant examples?

Everything that uses the udev database which was populated with /usr around but needed tools from there to do so. Network setups are known to fail. 3G modems get the wrong drivers attached. Sound does not work. All the stuff that has deeper dependencies on hardware/device setups. Simple web/file servers are usually not a problem, but it's really hard to debug what went wrong if things go wrong, and the dependency on proper early boot get larger and larger. Everything that uses D-Bus, it's entire config is in /usr. Systemd, and a growing number of tools, wants D-Bus properly started up very early.

As far as I'm aware, anything that runs before boot.localfs should only use things in /bin /sbin or /lib and anything that runs that early that references /usr is just broken

Can you point to any bug reports of things breaking when /usr is mounted read- only?

No, we just tell everybody running into it not to do that fiddling with /usr. And most of the people who already do that don't need any advanced feature today.

...

We just require that /usr is mounted from initramfs, when systemd is started, nobody cares where /usr comes from or if its writable.

initramfs? Are you suggesting sticking that thing into the initrd?

What do you mean by 'that thing'? I suggest to mount /usr from inside the initramfs, just like we mount / from there, before init/udev/D-Bus or anything which might need /usr is started, yes. Kay -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Thu, 2011-06-16 at 15:35 +0200, Anders Johansson wrote:

On Thursday 16 June 2011 15:21:29 Kay Sievers wrote:

...

...

What fails? Can you give some relevant examples?

Everything that uses the udev database which was populated with /usr around but needed tools from there to do so.

Ah yes. udev is also one of your projects. Also pushed into the initrd for absolutely no reason whatever, and the cause of so many problems because of it that it's not even funny

Thanks for the absolutely-no-reason-whatever expert opinion.

...

Network setups are known to fail. 3G modems get the wrong drivers attached. Sound does not work. All the stuff that has deeper dependencies on hardware/device setups.

huh? Network setups fail when /usr is readonly? What are you talking about?

With /usr not mounted. Read-only should work just fine.

Nothing complex should start before boot.localfs. It should be one of the absolute first things to run. After that, you have a /usr and anything that expects to be able to write to it should be fixed because it is fundamentally broken

That's just not reality today. People work hard to get us out of the UNIX stone age, with its mindless idea to move all random stuff from /usr to / and do symlink games. / is the initramfs today, /usr is everything else. The split will very likely be history in the near future for many very good reasons.

...

What do you mean by 'that thing'? I suggest to mount /usr from inside the initramfs, just like we mount / from there, before init/udev/D-Bus or anything which might need /usr is started, yes.

Then you have completely misunderstood the purpose of /usr

Sure, sorry, there are many things I don't understand. :)

I propose that we not allow systemd to completely rewrite the entire userspace setup of linux.

Noted as *your* opinion. :)

It was supposed to be a replacement for init, not a replacement for *everything*

Did not see you involved what we define as *supposed*. You might get involved if you don't like the current ideas. It's as always, the people who do the work, make the decisions. Kay -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Thu, 2011-06-16 at 15:51 +0200, Anders Johansson wrote:

On Thursday 16 June 2011 15:44:58 Kay Sievers wrote:

...

On Thu, 2011-06-16 at 15:35 +0200, Anders Johansson wrote:

...

On Thursday 16 June 2011 15:21:29 Kay Sievers wrote:

...

...

What fails? Can you give some relevant examples?

Everything that uses the udev database which was populated with /usr around but needed tools from there to do so.

Ah yes. udev is also one of your projects. Also pushed into the initrd for absolutely no reason whatever, and the cause of so many problems because of it that it's not even funny

Thanks for the absolutely-no-reason-whatever expert opinion.

You're welcome. I can show you the pain it has caused me and my colleagues.

Because of udev in the initrd, we now have discovery of every single device so early, we have problems with the interaction between mpio and lvm/md, we have problems with configuration files because every time anything changes that affects those things the initrd has to be rebuilt, we have problems debugging because it's virtually impossible to debug discovery failures in the initrd.

The initrd is supposed to be an extremely small thing that gets the root file system mounted, and everything else is supposed to happen afterwards, once the real root has been mounted. It is not supposed to contain a small operating system

I don't think we share this opinion. The iniramfs is there to mount / (and in the future also everything else that's needed). Statement like 'extremely small' are just misguiding. They need to be as big as they need to be to get their job done. And if setting up / is that expensive, we just need the needed tools there. You might just want to switch the technology below your rootfs to something more abstract, then you might don't need one at all.

And yes, udev in the initrd is the cause of quite a number of totally unnecessary bugs. Especially when it was pushed into the initrd in SLES9 while

I don't know about udev in SLE9's initramfs. I've never seen that.

it was still deemed unfit for the main system, but even today

Thanks again! Kay -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Thursday, June 16, 2011 03:01:28 PM Anders Johansson wrote:

On Thursday 16 June 2011 14:46:47 Kay Sievers wrote:

...

On Thu, 2011-06-16 at 14:23 +0200, Anders Johansson wrote:

...

On Thursday 16 June 2011 14:04:47 Will Stephenson wrote:

...

3) What are the big gaps that it doesn't currently do, compared to sysvinit? I hear of things like encrypted LVM volumes not working being dismissed as unimportant. I'll start you off with "password agents to do interactive things during service startup, eg openvpn passwords" (bnc675406): http://www.freedesktop.org/wiki/Software/systemd/PasswordAgents

read-only /usr mounts I believe were dismissed as unimportant as well

They can't work reliably, and never worked reliably for any non-trivial setup. They did not in the recent past, and never will in the future. Anybody who still claims that hasn't look into any of the non-interesting details of the current reality.

What fails? Can you give some relevant examples?

We've moved a lot of binaries and libs from /usr/ to / to support it - but there are for example udev scripts that access /usr etc.

As far as I'm aware, anything that runs before boot.localfs should only use things in /bin /sbin or /lib and anything that runs that early that references /usr is just broken

that's the policy in SUSE - but nobody upstream takes care of it, so it's an endless figuring out what fails and fixing it.

Can you point to any bug reports of things breaking when /usr is mounted read- only?

It wasn't /usr read-only AFAIK - it's separate /usr.

...

We just require that /usr is mounted from initramfs, when systemd is started, nobody cares where /usr comes from or if its writable.

initramfs? Are you suggesting sticking that thing into the initrd?

He says that /usr needs to be mountable from the initial ram disk - and that's the only requirement we have, Andreas -- Andreas Jaeger, Program Manager openSUSE aj@{novell.com,suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 06/16/2011 02:04 PM, Will Stephenson wrote:

On Friday 10 Jun 2011 19:04:14 Frederic Crozat wrote:

...

For discussing / helping with systemd integration for Factory, please use opensuse-factory mailing list or go to #opensuse-factory IRC channel on Freenode.

We need your help to make sure openSUSE 12.1 will use systemd at 200% ;)

Ok, I took the time to read and re-read all of the systemd blogs, some man pages, and our wiki articles, so here are my 2 cents on the matter:

To systemd maintainers, and maintainers of our init scripts: 1) Our sysvinit scripts are configured by sourcing variables from /etc/sysconfig. This allows us to keep common init scripts over several distribution versions and releases, and allows YaST to modify the way services are run by modifying /etc/sysconfig files only.

systemd service files support environment variable substitution for some keys, eg ExecStart, and the values are obtained from single config files specified by absolute paths in EnvironmentFile keys. Is this sufficient to maintain the same configurability as we use now in init scripts?

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?

To systemd maintainers, and everyone else, since I suspect the systemd guys are not omniscient: 3) What are the big gaps that it doesn't currently do, compared to sysvinit? I hear of things like encrypted LVM volumes not working being dismissed as unimportant.

tested (/boot simple partition) and full rest encrypted volume group with several logical volume. (/ /var swap /home) Works, has to be finished to not fsck each volume at each restart.

I'll start you off with "password agents to do interactive things during service startup, eg openvpn passwords" (bnc675406): http://www.freedesktop.org/wiki/Software/systemd/PasswordAgents

4) Are non-NetworkManager network configurations supported? was working on a 11.4 + systemd + normal network + Gnome3

Will

But yes several systemd native service are not ready/fully apache2 (who try the different worker?) postgresql (which is a complicated one to get it upstream) rpm based have on pg version, debian like have several version supported. Oh Will there's a trend actually to kill a vast majority of the /etc/sysconfig contain :-) -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member & Ambassador GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

* Kay Sievers [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

On Thu, Jun 16, 2011 at 04:20:09PM +0200, Kay Sievers wrote:

On Thu, 2011-06-16 at 15:56 +0200, Guido Berhoerster wrote:

...

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.

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.

From the side of the enterprise people: /usr mountable ro. Please note that we have customers which are using exactly this feature.

Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Fri, Jun 17, 2011 at 12:13:45PM +0200, Kay Sievers wrote:

Sure, they will just need an initramfs that can do that, if they want it to work in the future.

Actually, the long-term goal is to merge the useless split of / and /usr back to /usr and be able to mount /usr ro on every system. It's the same model as Android is doing with /system.

/usr will contain the entire system, and only /etc and /var will be host-specific. /usr can be ro and be shared between many machines of the same architecture. But all logic to set it up before init starts will be in in the initramfs. People are actually already working on it.

It has to possible to boot the system into single user mode maintenance without mounted partitions. I've no problem if this is done in initramfs just as a rescue mode even before mounting the root file system but for /usr this is a hard requirement for every big data server. Be aware that a s390x / and most ppc64 are not a smart phones nor net books. Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Fri, Jun 17, 2011 at 12:36:20PM +0200, Kay Sievers wrote:

We really need to get closer to how they work, and the mindless split between / and /usr is the first step to clean up the mess we inherited.

For a DB the split between / and /usr is not mindless ... at least this is on our remit for the minimal specification of the most big DB server. I also prefer / and /usr on on partition but my personal opinion, but this is clearly not all that. -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Friday 17 June 2011 13:01:47 Stephan Kulow wrote:

Am Freitag, 17. Juni 2011 schrieb Dr. Werner Fink:

...

On Fri, Jun 17, 2011 at 12:36:20PM +0200, Kay Sievers wrote:

...

We really need to get closer to how they work, and the mindless split between / and /usr is the first step to clean up the mess we inherited.

For a DB the split between / and /usr is not mindless ... at least this is on our remit for the minimal specification of the most big DB server. I also prefer / and /usr on on partition but my personal opinion, but this is clearly not all that.

Can we please leave these technical discussions on opensuse-factory instead of crossposting? This one should be suitable the get the non-technical discussion going: http://bit.ly/mcmjGP -- Mit freundlichen Grüßen, Sascha Peilicke http://saschpe.wordpress.com

* Kay Sievers [2011-06-17 12:13]:

...

From the side of the enterprise people: /usr mountable ro. Please note that we have customers which are using exactly this feature.

Sure, they will just need an initramfs that can do that, if they want it to work in the future.

Actually, the long-term goal is to merge the useless split of / and /usr back to /usr and be able to mount /usr ro on every system. It's the same model as Android is doing with /system.

On servers I always have /, /usr, (/usr)/home, /var, and /tmp on separate filesystems in order to prevent accidentally filling up /. I know others are doing the same and I think that is a perfectly legitimate use case. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Fri, Jun 17, 2011 at 05:09:17PM +0200, Kay Sievers wrote:

On Fri, 2011-06-17 at 16:37 +0200, Guido Berhoerster wrote:

...

* Kay Sievers [2011-06-17 12:13]:

...

...

From the side of the enterprise people: /usr mountable ro. Please note that we have customers which are using exactly this feature.

Sure, they will just need an initramfs that can do that, if they want it to work in the future.

Actually, the long-term goal is to merge the useless split of / and /usr back to /usr and be able to mount /usr ro on every system. It's the same model as Android is doing with /system.

On servers I always have /, /usr, (/usr)/home, /var, and /tmp on separate filesystems in order to prevent accidentally filling up /. I know others are doing the same and I think that is a perfectly legitimate use case.

Sure, you only need to be able to mount /usr from initramfs. Init will not care where it came from. But it will no longer be supported to start init with an empty /usr.

Actually, /bin, /sbin, /lib, /lib64, ... should just be symliks to /usr, which will be mounted by initramfs, and likely be read-only by default in the future.

This is a bug of systemd and a violation of the FSH standard. For server systems a nogo. Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 06/17/2011 01:11 PM, Kay Sievers wrote:

On Fri, 2011-06-17 at 18:54 +0200, Dr. Werner Fink wrote:

...

On Fri, Jun 17, 2011 at 05:09:17PM +0200, Kay Sievers wrote:

...

On Fri, 2011-06-17 at 16:37 +0200, Guido Berhoerster wrote:

...

* Kay Sievers [2011-06-17 12:13]:

...

...

From the side of the enterprise people: /usr mountable ro. Please note that we have customers which are using exactly this feature.

Sure, they will just need an initramfs that can do that, if they want it to work in the future.

Actually, the long-term goal is to merge the useless split of / and /usr back to /usr and be able to mount /usr ro on every system. It's the same model as Android is doing with /system.

On servers I always have /, /usr, (/usr)/home, /var, and /tmp on separate filesystems in order to prevent accidentally filling up /. I know others are doing the same and I think that is a perfectly legitimate use case.

Sure, you only need to be able to mount /usr from initramfs. Init will not care where it came from. But it will no longer be supported to start init with an empty /usr.

Actually, /bin, /sbin, /lib, /lib64, ... should just be symliks to /usr, which will be mounted by initramfs, and likely be read-only by default in the future.

This is a bug of systemd and a violation of the FSH standard. For server systems a nogo.

Yeah, it's a violation of the rules of the stone age. Many of them just don't make sense anymore. We need to pick the nice parts of UNIX, and leave the silly things behind us to be able to survive. And the split of / and /usr very high on the list of things we like to get rid of.

Anyway, FHS documents current behavior, it can not be violated. If the current behavior changes, FHS needs to change, and people actually working on that.

Just double checked on that. There is no awareness at the FHS level that systemd implementation is pushing for the removal of /bin, /sbin, /lib, /lib64 and having everything pushed into /usr. Better speak up soon at fhs-discuss@lists.linux-foundation.org as the next release of FHS is in the works right now. Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead rschweikert@novell.com rschweikert@ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Friday 17 June 2011 19:32:09 Kay Sievers wrote:

Remember, FHS documents behavior, does not set rules to follow.

Where did you hear this? The FHS - and the LSB in general - was invented to give us a set of standards that third-party developers to rely on to always work, so they didn't have to live in constant fear of people upending everything to break their software. This was once considered important in linux. I personally believe it was what made us number 1 on server systems. The next move of the LSB and FHS was meant to be a standardisation of the desktop, so we could move ahead there and eventually become number 1 there as well. I think this was partly the idea of freedesktop.org and the work around standards such as XDG But I guess that is all stone age. Anders -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 06/17/2011 03:47 PM, Graham Anderson wrote:

On Friday 17 Jun 2011 19:42:31 Anders Johansson wrote:

...

On Friday 17 June 2011 19:32:09 Kay Sievers wrote:

...

Remember, FHS documents behavior, does not set rules to follow.

Where did you hear this? The FHS - and the LSB in general - was invented to give us a set of standards that third-party developers to rely on to always work, so they didn't have to live in constant fear of people upending everything to break their software.

This was once considered important in linux. I personally believe it was what made us number 1 on server systems.

The next move of the LSB and FHS was meant to be a standardisation of the desktop, so we could move ahead there and eventually become number 1 there as well. I think this was partly the idea of freedesktop.org and the work around standards such as XDG

As a wise penguin once said "I see standards bodies as documentation and really nothing more". And this is prbably close to the reality of the matter. It can be argued that the LSB is lagging behind the pace of development and change, especially on the desktop, and that would pretty much make it documentation in my eyes. And out of date documentation at that.

The LSB lags behind on purpose in an effort to resemble currently released enterprise distribution. The LSB is setup to be a trailing standard, while the FHS is not. For LSB 5.0 the LSB will be a bit more aggressive, however, it will never be targeted at the community distributions as community distributions clearly move too fast. BTW, community distros also move too fast for most ISV and Enterprises, which is the target of the LSB. Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead rschweikert@novell.com rschweikert@ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 06/17/2011 01:32 PM, Kay Sievers wrote:

On Fri, 2011-06-17 at 13:26 -0400, Robert Schweikert wrote:

...

On 06/17/2011 01:11 PM, Kay Sievers wrote:

...

On Fri, 2011-06-17 at 18:54 +0200, Dr. Werner Fink wrote:

...

On Fri, Jun 17, 2011 at 05:09:17PM +0200, Kay Sievers wrote:

...

On Fri, 2011-06-17 at 16:37 +0200, Guido Berhoerster wrote:

...

* Kay Sievers [2011-06-17 12:13]: >> From the side of the enterprise people: /usr mountable ro. >> Please note that we have customers which are using exactly >> this feature. > > Sure, they will just need an initramfs that can do that, if they want it > to work in the future. > > Actually, the long-term goal is to merge the useless split of / and /usr > back to /usr and be able to mount /usr ro on every system. It's the same > model as Android is doing with /system.

On servers I always have /, /usr, (/usr)/home, /var, and /tmp on separate filesystems in order to prevent accidentally filling up /. I know others are doing the same and I think that is a perfectly legitimate use case.

Sure, you only need to be able to mount /usr from initramfs. Init will not care where it came from. But it will no longer be supported to start init with an empty /usr.

Actually, /bin, /sbin, /lib, /lib64, ... should just be symliks to /usr, which will be mounted by initramfs, and likely be read-only by default in the future.

This is a bug of systemd and a violation of the FSH standard. For server systems a nogo.

Yeah, it's a violation of the rules of the stone age. Many of them just don't make sense anymore. We need to pick the nice parts of UNIX, and leave the silly things behind us to be able to survive. And the split of / and /usr very high on the list of things we like to get rid of.

Anyway, FHS documents current behavior, it can not be violated. If the current behavior changes, FHS needs to change, and people actually working on that.

Just double checked on that. There is no awareness at the FHS level that systemd implementation is pushing for the removal of /bin, /sbin, /lib, /lib64 and having everything pushed into /usr.

Better speak up soon at fhs-discuss@lists.linux-foundation.org as the next release of FHS is in the works right now.

We submitted only /run so far.

The rest is all work-in-progress, and nothing ready for any slow-moving official FHS, or bike-shedding discussions. Stuff needs to work in reality before it can be formalized. Distros will experiment with it first. We are currently working on the initramfs code to make all that possible.

Will be a while before anything gets officially submitted. Remember, FHS documents behavior, does not set rules to follow.

Well, I'd say there will be a bunch of people that disagree with that statement. Since the "survive in the future" card has been played a couple of times in this thread, here are my $0.02. If systemd breaks the FHS there will be a lot of ticked of ISVs when they have to change their build system and/or application to accommodate whatever may break. Annoying app vendors is not the best way to achieve success or "survive in the future". Not that a transition cannot be completed, but when presented in the steamroller fashion as things are presented here the reaction on the other side is probably not very positive. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead rschweikert@novell.com rschweikert@ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Fri, 2011-06-17 at 20:16 +0200, Kay Sievers wrote:

On Fri, 2011-06-17 at 14:07 -0400, Robert Schweikert wrote:

...

Since the "survive in the future" card has been played a couple of times in this thread, here are my $0.02.

If systemd breaks the FHS there will be a lot of ticked of ISVs when they have to change their build system and/or application to accommodate whatever may break. Annoying app vendors is not the best way to achieve success or "survive in the future". Not that a transition cannot be completed, but when presented in the steamroller fashion as things are presented here the reaction on the other side is probably not very positive.

Nobody talks about renaming things, stuff will still be there.

This is only about early boot and how things are brought up at bootup time, mainly the task of moving / into /usr. And having a single directory containing the _entire_ system, which can be shared read-only across many instances.

And apps should not care what is mounted which way, as long as it's there -- just like they don't care about the underlying storage, be it nfs, or a disk, or iscsi.

We will have something working, to show, and to talk about after the summer I guess: http://www.linuxplumbersconf.org/2011/ocw/proposals/579 Kay -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Fri, 2011-06-17 at 20:34 +0200, Anders Johansson wrote:

On Friday 17 June 2011 20:25:55 Kay Sievers wrote:

...

We will have something working, to show, and to talk about after the summer I guess: http://www.linuxplumbersconf.org/2011/ocw/proposals/579

"Lessons learned from Android, MacOS"

Right. Android has a read-only /system by default, strict separation between: system, host, user, 3rd party app and runtime data. There is actually a lot to learn from. Unlike people like the state: usual Linux distros are many years behind that, they are less secure, less flexible and much more complicated. Android did many things very right, and they use the same tools we all have available. We just need to think out of the box, and can improve what we have, without really breaking anything after bootup. Kay -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Fri, 2011-06-17 at 19:39 +0200, Dr. Werner Fink wrote:

On Fri, Jun 17, 2011 at 07:11:50PM +0200, Kay Sievers wrote:

...

...

This is a bug of systemd and a violation of the FSH standard. For server systems a nogo.

Yeah, it's a violation of the rules of the stone age. Many of them just don't make sense anymore. We need to pick the nice parts of UNIX, and leave the silly things behind us to be able to survive. And the split of / and /usr very high on the list of things we like to get rid of.

Anyway, FHS documents current behavior, it can not be violated. If the current behavior changes, FHS needs to change, and people actually working on that.

FHS is very useful to argument against something, we all use it that way from time to time, and if it is in our way we just ignore it, just like we did with /run. It's very convenient, everybody wins. :)

I'd like to know what the big vendors are thinking about this. Introducing risks due lazy/snooty systemd developers can not be a reason to ignore well-founded and common rules how to handle big severs.

Most of the 'lazy/snooty systemd developers' work for the biggest vendors. :) And actually most of the requests what systemd should do come from these vendors and their customers. We declined more requests form them than we have implemented so far. Kay -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Monday 20 June 2011 10:40:26 Dr. Werner Fink wrote:

On Fri, Jun 17, 2011 at 07:43:12PM +0200, Kay Sievers wrote:

...

...

I'd like to know what the big vendors are thinking about this. Introducing risks due lazy/snooty systemd developers can not be a reason to ignore well-founded and common rules how to handle big severs.

Most of the 'lazy/snooty systemd developers' work for the biggest vendors. :)

Does this mean that IBM will enforce that /usr and other useful partitions will be only avaiable by using initramfs?

Since when does IBM ship openSUSE?

...

And actually most of the requests what systemd should do come from these vendors and their customers. We declined more requests form them than we have implemented so far.

Defer would be OK, but declined is not that what will help to become systemd accepted as replacement on top of most big servers.

openSUSE doesn't run on big servers so what is the issue? It might be an issue for SLES but that's not expected for another two years and I'm sure SUSE can solve that issue if they want to. Please keep the openSUSE and SUSE discussions separate.

Werner

Am 20.06.2011 11:17, schrieb Jos Poortvliet:

On Monday 20 June 2011 10:40:26 Dr. Werner Fink wrote:

...

On Fri, Jun 17, 2011 at 07:43:12PM +0200, Kay Sievers wrote:

...

...

I'd like to know what the big vendors are thinking about this. Introducing risks due lazy/snooty systemd developers can not be a reason to ignore well-founded and common rules how to handle big severs.

Most of the 'lazy/snooty systemd developers' work for the biggest vendors. :)

Does this mean that IBM will enforce that /usr and other useful partitions will be only avaiable by using initramfs?

Since when does IBM ship openSUSE?

...

...

And actually most of the requests what systemd should do come from these vendors and their customers. We declined more requests form them than we have implemented so far.

Defer would be OK, but declined is not that what will help to become systemd accepted as replacement on top of most big servers.

openSUSE doesn't run on big servers so what is the issue? It might be an issue for SLES but that's not expected for another two years and I'm sure SUSE can solve that issue if they want to.

Please keep the openSUSE and SUSE discussions separate.

Not exactly sure what you mean by big servers but openSUSE is definitely running on my servers. And I at least cannot remember that we decided in the openSUSE project to dump the usage of openSUSE for servers. Without having very much experience (I have to admit) with systemd it sounds like it is very much designed for the desktop. As I said several times now it might be possible that systemd serves us well. But I don't like how this "discussion" goes. Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Monday 20 June 2011 11:37:54 Stephan Kulow wrote:

Am Montag, 20. Juni 2011 schrieb Jos Poortvliet:

...

On Monday 20 June 2011 10:40:26 Dr. Werner Fink wrote:

...

On Fri, Jun 17, 2011 at 07:43:12PM +0200, Kay Sievers wrote:

...

...

I'd like to know what the big vendors are thinking about this. Introducing risks due lazy/snooty systemd developers can not be a reason to ignore well-founded and common rules how to handle big severs.

Most of the 'lazy/snooty systemd developers' work for the biggest vendors. :)

Does this mean that IBM will enforce that /usr and other useful partitions will be only avaiable by using initramfs?

Since when does IBM ship openSUSE?

How does this matter? systemd wants to be one for all linux and this is about openSUSE wanting systemd. So in this context, we need to look at other uses of linux in general and openSUSE based distributions specifically.

...

...

...

And actually most of the requests what systemd should do come from these vendors and their customers. We declined more requests form them than we have implemented so far.

Defer would be OK, but declined is not that what will help to become systemd accepted as replacement on top of most big servers.

openSUSE doesn't run on big servers so what is the issue? It might be an

How do you know?

...

issue for SLES but that's not expected for another two years and I'm sure SUSE can solve that issue if they want to.

While this is politically correct, SUSE engineers are a huge part of openSUSE, so their concerns are pratically openSUSE concerns too.

...

Please keep the openSUSE and SUSE discussions separate.

You want SUSE engineers to shutup in openSUSE? You can't be serious.

No, I want to have product management in SUSE care about SLES. If they need features for corporate customers, fine, but openSUSE doesn't have to wait for that if we don't want to. and OK, I admit I was being a tad too black and white, surely SUSE concerns should be part of the discussion here... But in this case, as the discussion is complicated enough as it is, it'd be nice if SUSE could figure out what they want before pulling in two directions at once... There shuldn't be a secret, internal cabal saying we go for systemd and screw the community but we could de-clutter the discussion a bit here. If SUSE wants certain features, it either should commit to implementing them, or keep sysv maintained next to systemd or whatever...

Greetings, Stephan

Le 20/06/2011 16:21, Ken Schneider - openSUSE a écrit :

WHY? You don't need /usr on a separate partition anymore.

having only one install for several computers? jdd -- http://www.dodin.net http://pizzanetti.fr -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 21/06/11 17:40, Stephan Kulow wrote:

Am Montag, 20. Juni 2011 schrieb jdd:

...

Le 20/06/2011 16:21, Ken Schneider - openSUSE a écrit :

...

WHY? You don't need /usr on a separate partition anymore. having only one install for several computers? Are you doing this or are you just telling stories? With just /usr shared, I would like to see your patches to zypp to run updates on such a system.

Greetings, Stephan

Stephan, Forgive me for asking but who do you actually work for now, Novell or SUSE? Your e-mail address is showing "@novell.com" but following the sale SUSE is now a separate entity and unconnected to Novell. I am simply puzzled, nothing more. BC -- The Annual General Meeting of Psychics has been cancelled due to unforseen circumstances. The Organising Committee -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 21/06/11 19:17, Andreas Jaeger wrote:

On Tuesday, June 21, 2011 11:01:27 Basil Chupin wrote:

...

On 21/06/11 17:40, Stephan Kulow wrote:

...

Am Montag, 20. Juni 2011 schrieb jdd:

...

Le 20/06/2011 16:21, Ken Schneider - openSUSE a écrit :

...

WHY? You don't need /usr on a separate partition anymore. having only one install for several computers? Are you doing this or are you just telling stories? With just /usr shared, I would like to see your patches to zypp to run updates on such a system.

Greetings, Stephan Stephan,

Forgive me for asking but who do you actually work for now, Novell or SUSE? Stephan - and myself - always worked for SUSE Linux Products GmbH.

We continue to use our Novell.com email address since that's the one we're subscribed to many mailing lists. But I guess we switch at one point to an suse one...

...

Your e-mail address is showing "@novell.com" but following the sale SUSE is now a separate entity and unconnected to Novell. Both SUSE and Novell are separate business units owned by Attachmate, so we're related ;)

Thanks for the response, Andreas. But what was written here just doesn't quite give this same understanding of the situation: http://www.zdnet.com/blog/open-source/attachmate-reveals-novell-suse-linux-p...

...

I am simply puzzled, nothing more. ;)

Still puzzled :-) .

Andreas

BC -- The Annual General Meeting of Psychics has been cancelled due to unforseen circumstances. The Organising Committee -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 21/06/11 20:39, Andreas Jaeger wrote:

On Tuesday, June 21, 2011 11:51:13 Basil Chupin wrote:

...

On 21/06/11 19:17, Andreas Jaeger wrote:

...

On Tuesday, June 21, 2011 11:01:27 Basil Chupin wrote:

...

On 21/06/11 17:40, Stephan Kulow wrote:

...

Am Montag, 20. Juni 2011 schrieb jdd:

...

Le 20/06/2011 16:21, Ken Schneider - openSUSE a écrit : > WHY? You don't need /usr on a separate partition anymore. having only one install for several computers? Are you doing this or are you just telling stories? With just /usr shared, I would like to see your patches to zypp to run updates on such a system.

Greetings, Stephan Stephan,

Forgive me for asking but who do you actually work for now, Novell or SUSE? Stephan - and myself - always worked for SUSE Linux Products GmbH.

We continue to use our Novell.com email address since that's the one we're subscribed to many mailing lists. But I guess we switch at one point to an suse one...

...

Your e-mail address is showing "@novell.com" but following the sale SUSE is now a separate entity and unconnected to Novell. Both SUSE and Novell are separate business units owned by Attachmate, so we're related ;) Thanks for the response, Andreas.

But what was written here just doesn't quite give this same understanding of the situation: Please ask specific questions.

...

http://www.zdnet.com/blog/open-source/attachmate-reveals-novell-suse-linux- plans/8771 Let's move this discussion elsewhere to the offtopic and not continue in this thread.

...

...

...

I am simply puzzled, nothing more. ;) Still puzzled :-) . If you have detailed question, ask them - but I guess opensuse-project is better. You can also ask me offlist,

Andreas

Thanks, Andreas, you have answered my hunches, and there is no need to take it to "offtopic" or even private mail. But apart from hoping that all is going well with your now extended family :-) , I do feel that altering the e-mail addresses to reflect the new business situation would be a very good and progressive step. BC -- The Annual General Meeting of Psychics has been cancelled due to unforseen circumstances. The Organising Committee -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Sun, Jul 3, 2011 at 17:59, Gerald Pfeifer wrote:

[ opensuse-factory@ -> opensuse-project@ ]

On Tue, 21 Jun 2011, Basil Chupin wrote:

...

But apart from hoping that all is going well with your now extended family :-) , I do feel that altering the e-mail addresses to reflect the new business situation would be a very good and progressive step.

Agreed, and we are working on it.  Everyone at SUSE who used to be reachable via xyz@novell.com should now (also) be reachable at xyz@suse.com.  I personally switched my sending address on Friday.

Please understand changes like this take time, and there are more places to adjust than one would think of at first (address books, Bugzilla database, individual Bugzilla queries, FATE database,...).

The primary reason I am mentioning this here on the list is that over the next days/weeks you'll notice that in some cases, notably Bugzilla, xyz@novell.com will disappear.  When that happens, don't invoke any conspiracy theories -- rather just check out xyz@suse.com. :-)

Gerald -- Dr. Gerald Pfeifer  || SUSE ||  Director Product Management -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

How about bugzilla itself? Is it going to move out of bugzilla.novell.com? -- Med Vennlig Hilsen, A. Helge Joakimsen -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 06/20/2011 10:21 AM, Ken Schneider - openSUSE wrote:

On 06/20/2011 04:40 AM, Dr. Werner Fink pecked at the keyboard and wrote:

...

On Fri, Jun 17, 2011 at 07:43:12PM +0200, Kay Sievers wrote:

...

...

I'd like to know what the big vendors are thinking about this. Introducing risks due lazy/snooty systemd developers can not be a reason to ignore well-founded and common rules how to handle big severs.

Most of the 'lazy/snooty systemd developers' work for the biggest vendors. :)

Does this mean that IBM will enforce that /usr and other useful partitions will be only avaiable by using initramfs?

WHY? You don't need /usr on a separate partition anymore.

I was first exposed to UNIX in 1988. Back then the largest harddrives were not big enough to fit the whole operating system let alone user login info plus any user data. There was no choice but to split some directories off onto a separate drives (partitions).

Let's get our heads out of the sand and our asses and get with modern times.

The only directories I see as being beneficial on a separate partition are the "tmp" directories which can fill a drive rather quickly if not watched.

*********************

Please stop posting by simply doing reply-to-all (most lazy gmail users). I, as well as everyone else on this list, get our copy of the post from the list and do not need multiple copies of the same email.

Finally! Thank you for answering my question...first ;-) Cheers! Roman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 06/20/2011 03:48 PM, Hans Witvliet pecked at the keyboard and wrote:

On Mon, 2011-06-20 at 10:21 -0400, Ken Schneider - openSUSE wrote:

...

WHY? You don't need /usr on a separate partition anymore.

I was first exposed to UNIX in 1988. Back then the largest harddrives were not big enough to fit the whole operating system let alone user login info plus any user data. There was no choice but to split some directories off onto a separate drives (partitions).

Let's get our heads out of the sand and our asses and get with modern times.

The only directories I see as being beneficial on a separate partition are the "tmp" directories which can fill a drive rather quickly if not watched.

Perhaps good enough for you, when playing with a laptop at home

It just shows that you never came across a malfunctioning dhcp, bind, ldap,apache, openvpn, kerberos, or asterisk server.

Did you ever had to do an fsk on a malfunctioning disk, while having a claim of thousands of euro's for every minute down-time?

I did before I retired but in US$ not euro. And yes I had servers for dhcp, ldap, apache, squid ect. ect. But I also ran them on reliable hardware using a reliable filesystem and a reliable UPS.

Obviously not!

Obviously I *did*.

hw

-- Ken Schneider SuSe since Version 5.2, June 1998 starting with Sun OS in 1988 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Monday 20 June 2011 10:35:21 Dr. Werner Fink wrote:

On Fri, Jun 17, 2011 at 07:11:50PM +0200, Kay Sievers wrote:

...

On Fri, 2011-06-17 at 18:54 +0200, Dr. Werner Fink wrote:

...

This is a bug of systemd and a violation of the FSH standard. For server systems a nogo.

Yeah, it's a violation of the rules of the stone age. Many of them just don't make sense anymore. We need to pick the nice parts of UNIX, and leave the silly things behind us to be able to survive. And the split of / and /usr very high on the list of things we like to get rid of.

There is more than / and /usr, also /tmp, /var, and /boot is IMHO a very important point. Why do you think, most seasoned system adminstrators will mostly use different partitions for / and /usr, /tmp, and /var. Particular /tmp and /var will be separate partitions.

...

Anyway, FHS documents current behavior, it can not be violated. If the current behavior changes, FHS needs to change, and people actually working on that.

FHS is very useful to argument against something, we all use it that way from time to time, and if it is in our way we just ignore it, just like we did with /run. It's very convenient, everybody wins. :)

OK let's disregard the most important clientele by ignoring the most useful experience by declaring those experience as stone aged.

My hope was to have with systemd a real replacment for SysV able to serve all needs for all customer out there, that is not only openSUSE users on netbook and other mobile devices but also needs of our business customer on their big irons.

Let SUSE worry about the business customers, please, that doesn't have to influence what openSUSE decides. Moreover, if some requests of customers or users are not a good idea, we don't have to do it. systemd is not unique in telling you you shouldn't want certain things - or offering alternative ways to do it. About your specific argument, it's been said often enough now in this thread that you can have your /usr on a separate partition. Either the stupid way (like with sysv now: just ignore the fact that it doesn't work for lots of things and hope none of those matters to you) which is fully supported by systemd although they tell you it's stupid; or the smart way, by using initramfs. So, can you please let it go now? Repeating an argument doesn't make it any less valid, you know...

Werner

On Monday 20 June 2011 12:23:33 Dr. Werner Fink wrote:

On Mon, Jun 20, 2011 at 11:16:35AM +0200, Jos Poortvliet wrote:

...

Let SUSE worry about the business customers, please, that doesn't have to influence what openSUSE decides.

My answer is simply no. This because I'll take the concerns and requirements of all customers as real, which includes also all openSUSE users. The reason is simply that the openSUSE platform is the base of all business products like SLES is. Beside this IMHO also the other directions holds true ... as I've tried to add any solution found on SLES also to the next openSUSE tree.

Ok, true, I admit this is relevant...

...

Moreover, if some requests of customers or users are not a good idea, we don't have to do it. systemd is not unique in telling you you shouldn't want certain things - or offering alternative ways to do it.

About your specific argument, it's been said often enough now in this thread that you can have your /usr on a separate partition. Either the stupid way (like with sysv now: just ignore the fact that it doesn't work for lots of things and hope none of those matters to you) which is fully supported by systemd although they tell you it's stupid; or the smart way, by using initramfs.

It seems that I've to explain *why* experienced system administrators use separate partitions for e.g. /usr, /var and /tmp. The main reason is simply to *minimize* downtime after a crash due e.g. services like hugh data base servers getting out of control filling up the logging files at /var and/or temporary files e.g. at /tmp. To have a readdonly mounted /usr partition also minimize the check time of e.g the root paritions after e.g. file system crash due such critical incident.

...

So, can you please let it go now? Repeating an argument doesn't make it any less valid, you know...

Sorry but if facts on well known experience will be handled as stone aged it should be noted, shouldn't it. and even if stone aged in someone eyes, the concerns of the paying customers should whould be taken serious.

Werner

* Kay Sievers [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, from a quick glance at the upstart repo it seems that upstart is actively maintained. So the major distributions participating in this "standardiaztion" seem to be Fedora, oS, and possibly Mageia/Mandriva.

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. It also forces one to run DBus which serves no useful purpose on a server but needlessly adds a new potential attack vector. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

* Kay Sievers [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@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

* Kay Sievers [2011-06-17 19:39]:

On Fri, 2011-06-17 at 19:20 +0200, Guido Berhoerster wrote:

...

* Kay Sievers [2011-06-17 17:06]:

...

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.

Which inconsistency?

How did you customize mount -a, which was called unconditionally, before systemd?

If mountpoints were specified with trailing slashes in fstab they had to be passed exactly like this to mount later. Since systemd's own parser apparently strips that off mounting fails. While this is a bug in mount, it also illustrates why having two different implementations for the same job is not a good idea. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/17/2011 11:14 AM, Greg KH wrote:

On Fri, Jun 17, 2011 at 04:33:58PM +0200, Guido Berhoerster wrote:

...

* Kay Sievers [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.

...

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.

My big concern with all of the systemd discussion is how much flexibility that we (and UNIX generally) have classically had and are losing with systemd. It's like the Apple/GNOME-ification of the boot process and that's not necessarily a good thing. How many feature requests have we seen to take functionality away? Many of the things that are just being handwaved away as "no longer necessary" use the extremely simplistic environment of a smartphone or tablet as an example. Real world deployments of a full-fledged Linux distribution tend to be a bit more complex. Then we're met with the "want X functionality? Put it in the initramfs." at the same time that there are *other* people actively trying to *eliminate* the initramfs. I'm not sold on the systemd community speaking for all of Linux-dom. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk37h58ACgkQLPWxlyuTD7KLVACgm3Bdsw7g8NU6Xy31nQ0wU1tI cR0An3xo1EZfUS7N1YWluOxg5e8YRwuV =/bf6 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

* Greg KH [2011-06-17 17:14]:

On Fri, Jun 17, 2011 at 04:33:58PM +0200, Guido Berhoerster wrote:

...

* Kay Sievers [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

On Thu, 2011-06-16 at 22:33 -0400, Robert Xu wrote:

On Thu, Jun 16, 2011 at 09:09, Kay Sievers wrote:

...

In the future we want /etc/defaults and /etc/sysconfig, and all the other friends distros invented to die. :)

I don't like that, actually - I always thought this was a strong point for SuSE. Being able to keep these options in once place.

Yeah, and they will still be in one place in the future, and that place is just /etc. :) Having 2 competing config files for most of the services doesn't sound very convincing. And as we doubt that anybody can convince or patch all the upstream projects to switch to the /etc/sysconfig/ format only, we better step back and use the current native files, to have only one instance that needs to be configured. Kay -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Fri, 2011-06-17 at 12:21 +0200, jdd wrote:

Le 17/06/2011 12:17, Kay Sievers a écrit :

...

And as we doubt that anybody can convince or patch all the upstream projects to switch to the /etc/sysconfig/ format only, we better step back and use the current native files, to have only one instance that needs to be configured.

we have an unique and very usefull "rcservice" list of links, we can as well have symlinks to config files in /etc/sysconfig (the applications are inconsistent on where they set they config file, even how they name it)

Sure, but if you teach system management to edit native file formats (which is what we should do instead of inventing 2nd level on-top files) then you can simply teach it the native location instead of linking things together for no real reason. :) Actually we make many people happy when there is only one file, because they can edit it by hand or with the system management at the same time, and don't need to care what system management will overwrite in the primary files with the out-of-sync stuff from the artificial 2nd level. There is no rush to force or to do anything like that immediately, stuff will just continue to work as long as needed, but the future definitely doesn't look like /etc/sysconfig/ files put on top by the distribution.

by the way what will these start stop service become with systemd?

systemctl start/stop <name>.service You could probably simply extend systemd's bash completion to auto-complete rc with the list of all services. :) Kay -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org