On Mon, Feb 17, 2014 at 12:24 PM, Andrew Savchenko <birc...@gmail.com> wrote: > On Mon, 17 Feb 2014 11:13:39 -0600 Canek Peláez Valdés wrote: >> > It simply doesn't matter if systemd boils down to one monolithic binary, or >> > 600, if they are tied together in such a way that they can not >> > *individually* be replaced *easily and simply* (ie, without having to >> > rewrite the whole of systemd). >> >> You are setting a group of conditions that preemptively wants to stop >> adoption of anything that is tightly integrated. That is a losing >> strategy (different projects actually *want* tight integration), and >> besides the burden of work should not fall on the people wanting to >> use a tightly integrated stack. >> >> You want individual modules that are "easily and simply" replaced? >> Then WROTE THEM. Don't expect the systemd authors (or any other) to do >> it for you. > > And here we have a small problem: for modules to be replaceable the > core system should be designed to support replaceable modules, but > systemd is not.
You misunderstood me: I didn't mean to say that someone should write a module to replace one of systemd's modules. I mean that distributions and projects are using systemd's features, and that if you want those features to be "easily and simply" replaceable, then someone needs to write them like that. Systemd developers decided the tightly integrated route; if you don't like that, and that the distributions are using systemd's features, write something similar being "easily and simply" replaceable so the distros don't need to use systemd. > The whole deep integration approach and lack of > inter-module boundaries doesn't allow one to write replaceable blocks > without crazy hacking. Well, then go and show them how it's done. And please don't say that "it's already done", because if that were the case, no distro would have adopted systemd. They adopted it because of the features it offers. > Just imagine that one have PCI-E bus and this bug is being replaced > with some other PC-systemd bus, where one have to interface each > component differently. And if one removes e.g. audio card some other > seemingly independent component e.g. network controller becomes > broken. That is the nature of systemd and that is many people dislike > this technology. That is a broken analogy; if logind has a bug, that doesn't affect timedated, nor udev. >> > That said, it seems to me that, for now at least, it isn't that big a deal >> > to switch back and forth between systemd and, for example, OpenRC. >> >> It depends; right now you can't switch back and forth between OpenRC >> and systemd without reemerging some stuff. Some of those packages >> *could* be made to switch functionality at run time instead of compile >> time, but SOMEONE has to write that support, and it's probably that >> the upstream for the package will not accept those changes, since for >> binary distributions it makes no sense to have the complexity on the >> code of switching behavior at runtime when doing at compile time is >> easier and the distribution generates one binary per architecture for >> all its users. > > The most sane and fair solution was already proposed: create a > systemd profile for those who need it. I personally highly dislike > systemd technology, but I respect the right of other to shoot them in > the leg (or head) as much as they want to. This is Gentoo: a universal > constructor providing people means to build any system in any shape > they need. If someone willing and able provides any choice, that choice will be available. > Unfortunately chances are that in future some software may become > unusable or unsupported outside of systemd profile. But patches may > be created and other profiles will continue to live the same way > hardened exists now and will continue to exist later. Yeah, and that's my whole point: if you want that the world outside of systemd keeps working, you need to step in. Complaining about systemd will get no one nowhere. > BTW it was shown at the recent LVEE Winter 2014 conference that GDM > can be easily freed from systemd and OpenBSD guys have an interesting > idea for faking systemd presence for applications requesting one > mandatory. Though IMO any end-user application strictly dependable on > any init system is broken by design: for a daemon there should be no > difference by which tool it was started. GNOME depends on logind, not systemd. And no one has been willing and able to produce a compatible replacement: logind works with a dbus API, so it's (in theory) *easy* to duplicate its functionality. Ubuntu has been working in a replacement, but (AFAIU) is not finished. >> > In fact, it seems to me that, since (from what I've read) the primary >> > reason >> > that systemd was written in the first place was to provide extremely fast >> > boots *in virtualized environments*, >> >> You are wrong; systemd was created because Upstart had the silly CLA >> from Canonical[1], and because its authors wanted a novel init system >> for Linux (and Linux only) that used all the cool technologies the >> kernel provides, and that it could solve problems like: how to easily >> and consistently start daemons with well defined semantics for its >> dependencies; how to easily and consistently apply resource quotas to >> them; how to deal with modern computers where hardware comes and goes >> (including CPUs) all the time, etc. [2]. > > Excuse me please, but what you wrote above is very naive. So you say. > All that reasons are just an excuse. So you say. > The real reason is money: systemd is a Red > Hat project (despite being formally open for everyone) and is their > tool^Wweapon to fight with Canonical for a sales market. It the last > years RH was pushed near even in a server market and now they are > fighting back. Nice conspiracy theory you have going on. > They were lucky enough to acquire Poettiring guy and > create from a simple and sound sysvinit (which is an important but > not dictating peace of software) a key component where they can > dictate their own line, where they can lead all Linux community in > a way they need. And it gets better. Citation needed? Any hard proof? > That the real reason I despise systemd: in replaces the freedom of > choice by a dictatorship of a small bunch of managers of a single > corporation (yes, managers, not developers). And all this is under the > veil of GPL and technical merits. This is the poison in the well of > FOSS. I don't work for RedHat; I teach in a University. Nobody pays me for using systemd; I just choose to because I think is a technical sound solution for the chaos that was the plumbing layer in Linux. So do people like Greg Kroah-Hartman and Keith Packard, and many more technical knowledgeable people. If you want to believe your little conspiracy theory, that's fine; but you are covering the sun with a finger. The technical merits and advantages of systemd are there in the open for anyone willing to study a little about it. *After* you carefully read the code, the documentation, and test the software in real life, you *may* still think you don't like the software or its design. But you will be with the minority of the people who have done their homework. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
