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. The whole deep integration approach and lack of inter-module boundaries doesn't allow one to write replaceable blocks without crazy hacking. 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 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. 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. 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. > > 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. All that reasons are just an excuse. 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. 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. 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. Best regards, Andrew Savchenko
pgpNXWRgUgRgH.pgp
Description: PGP signature
