On 01/26/2013 04:07 PM, Bruce Dubbs wrote: > Armin K. wrote: >> http://0pointer.de/blog/projects/the-biggest-myths.html >> >> I am just sharing this. Please don't start any arguments why something >> he said is true or not. > > Not an argument, a discussion. > > There are a few things that he left out.
I don't particularly care for systemd, but I've found it to be usable enough to support it if the majority is moving in that general direction. Standardization is a good thing IMO, so it gets my vote (even if Debian and its derivatives can't or are unwilling to adopt it). > > systemd uses binary log files that can't use standard tools like grep. > Myth or fact? Myth. This was covered in the referenced blog post. It brings additional functionality, and yes, the systemd executable itself does log to a binary format via the journal, but does not replace, nor hinder operation of a traditional syslog (and actually adds functionality by way of the early logging). We'd still have to do manual parsing of the binary log to get our boot.log file if it is still warranted, but that's less than what we do in rc today to get it. I find it kind of ironic that we attempted to partially solve our own early logging problem by modifying our init system (and using quite a few more tools, although, in our defense, those tools were already present on the system). :-) > > systemd does not support building udev without the rest of systemd. > Myth or fact? Fact. And that is one very annoying fact given the simplicity of rectifying it, but again, I also _understand_ the developers' take on it as well. It is one configuration that will only be used by a handful of its consumers. To get only the basics, we are talking dbus, glib, and libcap2. > > systemd solves problems encountered by many/most LFS users. Myth or fact? > Fact. LFS already uses part of systemd (udevd), BLFS will require more of it if it intends to continue to provide Gnome and KDE (logind), and security is everyone's continual problem (cgroups, though the security advantage is entirely mute if you happen to be an SE user already). Early logging also just got a little bit better to boot as it covers more than just boot script output when combined with a syslog daemon and one dump at the end of init (if you want/need systemd's logs to go to a standard syslog format). > systemd boots significantly faster than LFS on the same hardware. Myth > or fact? > Unable to answer. The question is too subjective because there are far too many variables. If you want a real answer, please define both 'boot' and 'LFS'. If LFS is inclusive of a complete BLFS system where you are nearing the 100 startup items of a typical distro, then yeah, it should be decidedly faster (especially if you consider 'boot' to end at the instant a login prompt is displayed). A noticeable speed difference could be realized if you happen to be running several instances of say Apache httpd, Tomcat, SQL, or any number of other services that take a considerable amount of time, say 100ms, to pass a return value to the shell that called it. Whether the time savings is significant is entirely subjective (even my suggestion of 100ms being considerable is subjective). I'll accept that it _might_ even be slower in some cases, but I've not looked for evidence one way or the other. But then again, if speed is the only concern, the rc script could be replaced with a single script with 7 cases and each called script followed by a single ampersand character if parallelism is desired. The output wouldn't be pretty with current scripts, but it'd be functional none the less. > systemd has/needs over 100 pages of documentation. Myth or fact? > Fact/Myth You asked two questions and I answered both. Yes it has great documentation! Whether the average user needs all of the API documentation is questionable. I will second Simon's earlier response, however. :-) HTH to maybe paint it in at least a partially more positive light. -- DJ -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
