Hi, > That's precisely the point. If systemd is installed as default on every > jessie system, since it ships its own time syncing client, what's the > point of installing NTP (provided that the machine doesn't have to > provide time services to other hosts) ? That's exactly what a well-known > software company did to push its web browser by taking advantage of its > dominant position on the OS market. And that's what systemd is doing > with every component it intends to "offer" a replacement for.
As I already mentioned, I think the issue is very different with a browser vs. some low-level system component. Or would you say that the fact that we force every user to use GNU libc is comparable? What you say could also be read as a plea against any kind of integration, as this integration naturally provides a "best" combination of tools, and it will be harder to exchange some of them. I would argue that this is a trade-off. Personally, I am happy to know that the combination of tools that make up a part of the low-level system, has been tested and designed in exactly this constellation - as opposed to the giant exploding test matrix that results from supporting several variants of each tool. I appreciate that others have other preferences, and hence I think it is crucial that people can choose. Jessie is the first Debian release that offers a choice of init systems. >>> No, it's not: >> [...] >> >> Well, systemd has bugs, nobody doubts that. FWIW, I never saw this >> happen on my machine. > > If you already ditched syslog, it obviously won't happen... You wouldn't > be of such bad faith, would you ? ;) Just to clarify, as you already suspected, I still have syslog installed. ;-) > Just kidding. More seriously, you avoided to comment on the real issues: > is it a good sign of code quality (for the whole project) if the piece > of code which is supposed to communicate with syslog doesn't even wait > for it to be ready ? And more importantly, is it the quality level that > Debian has accustomed us to ? I didn't read the code. Depending on where and how this happens, I can understand that someone doesn't want to make a call that blocks arbitrary long. So if you get a timeout, what else could you do? I also find it hasty to judge systemd's code quality from a single example. The analysis of Russ and several others suggest that actually, systemd has a fairly high code quality. That's not something I can comment on; but they do seem to be eager to get rid of old cruft (many say, too eager), which certainly helps keeping your code clean. Considering the age and complexity of the software, I am also impressed how well it works. And finally, what I can comment on is the amount of documentation, and that's outstanding. I assume there is some correlation between well-organized, well-documented code and well-written (user-facing) documentation. Kind regards Ralf -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/546765dc.50...@ralfj.de
