On Tue, Jul 24, 2012 at 12:28 PM, Cristian Rodríguez wrote:

...

If you ask me, this is good.

No, it is not, at least not good for packagers and people that in general have to keep up with this always changing ecosystem.

Having two init systems is completely fricking insane, just like it was 6 months ago, no news here, having this topic raised again is just a symptom of it.

Why not? Everything in linux is swappable. Windowing systems are. GUIs are. Why are init systems not swappable? I know a distro picks an init system and sticks to it... but that's only because the tools to make init systems easily swappable are lacking. Mantaining two init systems will just make those tools evolve. Is that not good? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, Jul 24, 2012 at 02:45:34PM -0400, Brian K. White wrote:

On 7/24/2012 11:34 AM, Claudio Freire wrote:

Personally I think systemd could and should coexist with sysvinit the same way xinetd does.

Hallo Brian, Are you really convinced adding a new complex way of controlling your services is a way to go?

With xinetd, you can start a service like ftpd either by having an init script that starts it directly, or by having an xinetd config file. Sysv init either manages ftpd, or manages xinetd and xinetd manages ftpd. You can even have support for both options on the same system at the same time and yast can even keep track of them and prevent both from trying to be active at the same time.

In fact one of the basic concepts of systemd is make it only one part of a system executing and controlling services. That means things done atm by xinetd, cron, icron, dbus, desktop-session, whatever will be handled by systemd (not everything by PID 1, but by the same code) as one central place. I like that very much, because it makes the service configuration independent on a type of activation. And of course, you have the same set of kernel features available everywhere.

So I would be fine with that arrangement, where sysv init is still THE init, and systemd is one of the services sysv init starts and stops. With a little work putting common names on some capabilities, yast et al could pretty easily keep track for example that only one cron-provider is active at a time, whether it's systemd's built-in or a stand-alone, even though they have different package names.

How would poor yast ensure you can't do both sh /etc/inid./vsftpd start and systemctl start vsftpd.service? Regards Michal Vyskocil

On Wed, Jul 25, 2012 at 12:23:18PM +0200, Ruediger Meier wrote:

On Wednesday 25 July 2012, Michal Vyskocil wrote:

...

On Tue, Jul 24, 2012 at 02:45:34PM -0400, Brian K. White wrote:

...

On 7/24/2012 11:34 AM, Claudio Freire wrote:

Personally I think systemd could and should coexist with sysvinit the same way xinetd does.

Hallo Brian,

Are you really convinced adding a new complex way of controlling your services is a way to go?

...

With xinetd, you can start a service like ftpd either by having an init script that starts it directly, or by having an xinetd config file. Sysv init either manages ftpd, or manages xinetd and xinetd manages ftpd. You can even have support for both options on the same system at the same time and yast can even keep track of them and prevent both from trying to be active at the same time.

In fact one of the basic concepts of systemd is make it only one part of a system executing and controlling services. That means things done atm by xinetd, cron, icron, dbus, desktop-session, whatever will be handled by systemd (not everything by PID 1, but by the same code) as one central place.

This concept is exactly why systemd will never co-exist friendly on a unix like system where different tasks are done by small "swappable" tools.

Hallo, Why do you think that? Systemd can coexist with such services - if you want to, you still can run your cron.service, icron.service or xinetd.service if you want to. However the goal is to make those services obsoleted, which is definitelly true for later two. And to provide one central point for controlling of all (OK, things started from user shell session does not count) your processes. On the other hand it is true that coexisting with /sbin/init won't be friendly. But the main reason is the complexity of the resulted system, not the (un)friendliness of any involved tool.

...

I like that very much, because it makes the service configuration independent on a type of activation. And of course, you have the same set of kernel features available everywhere.

Systemd is for linux only. You will find it nowhere else. Moreover it makes you even more unfree about many details how to configure your system as you want.

I do not agree with you - if you maintain more systems, you have to deal with a tons of differences as well. You have iptables, where others have pf/ipwf/whatever system? Without learning all those systems, you weren't be able to even secure your system. Or other nixes have ifconfig, but ip is more suitable tool for Linux. Or they have still inetd, but SUSE have xinetd. Or some systems have a BSD like style with /etc/rc.conf, where SUSE have /etc/sysconfig. Or on some systems you have to deal with /etc/rc*/ symlinks manually, but I don't say that can be recommended for SUSE or other Linux systems. So all systems were, are and will be different even in very core parts and you have to be aware about them. Systemd is not an exception. You will have to learn how to configure it if you will have to maintain systemd-powered server. Regards Michal Vyskocil

On Tue, Jul 24, 2012 at 2:02 PM, Frederic Crozat wrote:

If features are missing for sysadmins, please ask for them (with a rationale, it is even better) on systemd mailing list. If there are bugs remaining, open bug reports.

I did. There were bug reports, I didn't start them. Not gonna dig them up, systemd guys (not sure if they were the authors, the maintainers or what) made it clear they weren't interested in implementing them. Everything's in the archives. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, Jul 24, 2012 at 11:46:37AM -0300, Claudio Freire wrote:

On Tue, Jul 24, 2012 at 5:42 AM, Michal Vyskocil wrote:

...

I do not believe that extending the "transition period" for one, or more openSUSE releases will make anything better.

I hope I'm not feeding the troll, but experience has shown that one release cycle wasn't enough to make systemd server-worthy.

I say server, because most (yet not all) of the bugs reported affected servers. Because systemd seems to have concentrated on desktop functionality, and lacks many features server sysadmins need.

Hallo Claudio, I honestly disagree, as I faced a lot of systemd bugs in a past on my desktop. Anyway the "lacking features part" have to follow the list of things cannot be handled by systemd - I doubt there are any others than this is done differently than before, or this one particular hackish script do not boot (call it suse-network-scripts-syndromme ;-). But I can be wrong, so the best way how to correct me is list of issues, you've reported and I'll shut up immediatelly ;-)

So... IMO, this is wishful thinking, and closing the transition period before systemd is server-worthy is burying one's head in the sand. Killing systemd is unlikely to happen, so we're left with this situation of multiple init systems.

Unfortunatelly current situation is very bad from sysvinit and systemd point of view as we do not have a good support for anyone. I am convinced the transition period did not succeeded, mainly because most of people facing a problem with systemd switched back to sysv - that makes all problems hidden to us. So I vote for making a period over, decide, let people affected by systemd report their bug and in case they all won't be fixed in next openSUSE release, add it to release notes, so people will be informed and can switch this release.

If you ask me, this is good. Packagers are spoiled in thinking there's only one init system, and the machinery that will inevitably grow to handle the two init systems will be a good thing for openSUSE's packaging process in general. It's like, in programming, splitting an ill-conceived monolithic app into well defined modules - a pain at the beginning, but a huge benefit in the end.

Did you say having two init systems is good because it enhance a modularity? Or I'm completelly wrong? Regards Michal Vyskocil