On Mon, Apr 06, 2015 at 09:38:06AM +0100, KatolaZ wrote: > What really puzzles me is why if you love systemd that much you just > continue arguing about systemd on the ML of a Debian fork specifically > born to throw systemd away. Do you think you might be able to convince > us that systemd is *good* and *beautiful* and *necessary*? I don't > want to be saved, thanks ;)
All I see T.J. saying is that systemd (1) implements some good ideas and (2) has done so in a way that is flawed in *certain* aspects, but (3) not in *other* aspects. And I suppose I agree with that. An init system that can collect *all* the descendents of a service is a nice concept. So is having a dependency-based boot that can respond to events, without treating "this dependency became available" as an event in its own right. And I suppose that knowing when service x becomes available, and when it goes away, can be nice...as is knowing that service x will keep running until the sysadmin stops it. But does that entail a release schedule such that the version number has increased by nearly 200 in 5 years, or a library to interface with that same package? Does it call for writing a new service to handle fdisk, another one to handle networking, another to handle the boot splash, and so on? Why should an init system implement an SNTP daemon, or its own DNS server, and what excuse is there for reinventing cache poisoning? I've heard comments about systemd being spaghetti-code. No, it's not: it's spaghetti-architecture, but the bits and pieces looked fairly clear. I *wish* busybox were that well-written. It's what they require and how they're combined that's problematic. I use musl libc on many of my installs, because I like having a libc that's simple to read, to enhance, to fix, to build, and to install, and that respects the bounds of its scope and keeps code and binary size down. systemd doesn't complement that, because it's an *boot* system that takes half a million lines of code to cover "booting the system". Note that I didn't call it an *init* system, because that is obviously not the scope that they accept. It doesn't work with musl, in small part because they decided to require secure_getenv() which is synonymous with if (issetugid()) getenv(var); but also because of extensive reliance on "how glibc does it"-- which may actually be undefined or nonstandard behavior that could change (for examples, note the flash breakage thanks to the memcpy() rewrite, and check the history of glibc getenv()). When people have enquired about making it work with uclibc, the developers responded with something that sounded a lot like "maybe, *if* it's not much different and you do the work". It requires util-linux and its libraries, and libkmod, and its own device manager, and libraries for crypto and compression, and it tries to provide a boot manager that's worthless for me (I use BIOS-based systems). Here, I use toybox/busybox because it covers all the functionality needed to boot and use a command-line Linux system; xz rather than lzma is my preferred compression tool; and I use grub4dos, currently the chenall fork, as a bootloader because I understand grub1, it can boot from NTFS, it can easily be set up from Windows, and it can boot FreeDOS. So my objection to systemd mostly comes down to this question: why should I have *any* interest in a project that averages ~3 releases a month to add features I don't want, that depends on packages I don't use, and would expect *me* to support *their* design? I have things I'd rather be working on than understanding half a million lines of boot system, and I can build one that I understand and that meets my own needs in under a thousand. Thanks, Isaac Dunham _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
