On Fri, Feb 21, 2014 at 1:42 AM, Andrew Savchenko <birc...@gmail.com> wrote: > On Thu, 20 Feb 2014 18:08:43 -0600 Daniel Campbell wrote: >> It's marginally clever, but so clearly obvious at the same time. It's >> sad (to me) that the community didn't see it coming. Those who did have >> been written off as conspiracy theorists or FUDders. Time will reveal all. > > Indeed time reveals everything and part of this foiled plot > revealed itself two days ago. It was said earlier in the list by > systemd supporters, that this project is modular, fine split to > binaries and thus critical issues in the pid 1 are not that likely. > And just look at systemd-209 release notes: > > http://lists.freedesktop.org/archives/systemd-devel/2014-February/017146.html > [quote] We merged libsystemd-journal.so, libsystemd-id128.so, > libsystemd-login and libsystemd-daemon into a a single libsystemd.so > to reduce code duplication and avoid cyclic dependencies (see below). > [/quote] > > So all talks about systemd being modular are nothing more than > nonsense. Guess what will happen on segfault in libsystemd.so? > Segfaults in pid 1 are so nice to bear...
You have no idea what are you talking about, do you? The systemd binary (you know, PID 1) *DOESN'T LINK AGAINST libsystemd.so!* It's for consumers of systemd's APIs. > And Canek please talk no more about how "talented" systemd > programmers are or even about how "professional" they are, because > they're no longer. They failed a trivial textbook example: what should > one do when libraries A and B have some common code and cyclic deps? > Push common code to library C. That's the Unix way and secure way. > Creating single bloated library will help in neither fencing nor > debugging, nor code audit. This actually I'm even willing to discuss. They give the rationale in the notes you linked: "he reason for this is cyclic dependencies, as these libraries tend to use each other's symbols." It's true, they could have splitted even more the libraries, but they instead coalesced them. If the libraries used each other symbols, then they basically are functioning as a single module, and then it can be argued that coalescing them is a good move. I'm not saying I agree; I think I also would have preferred for them to split the cycles into another library. But I give the benefit of the doubt to the maintainers, and certainly would still think they are talented enough. (And again, it's a "normal" library, for third-party consumers, not PID 1). > It looks like to me that ultimate goal of systemd is to consume as > much system and user tools and interfaces as possible. Yeah, that's the idea. They have been pretty clear and honest about it. They want systemd to be the standard basic plumbing of Linux. > Perhaps, in the > ideal systemd world there will be nothing but linux-systemd kernel and > systemd-stuff userspace. I would call it "systemd-aware" userspace, but yeah, again, that's the idea. > Shell communication will extinct, all major > application and daemons will be converted to systemd "modules". Why would you disallow shell communication? It's pretty useful. But it will be complemented with dbus IPC and systemd controlled processes. It works pretty much like this with GNOME right now. If you don't want this, just keep using OpenRC. Nobody is forcing systemd on you. > Of > course this goal will be never achieved as-is, but one may consider > it as an asymptote of their actions. They want systemd to be the basic plumbing of Linux, yes. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
