Systemd is aimed to be the Core OS: http://hasgeek.tv/fossdotin/2012-2/1...as-the-core-os

Here you go: http://www.phoronix.com/scan.php?pag...18_boots&num=1

(TL;DR summary: mixed results)

The benschmark you linked to compares systemd on Fedora 18 with systemd on Fedora 17, not systemd with other init systems.

I'm watching the video now, but I have to say it's difficult to be entirely free of prejudice when the message originates from someone who actually thinks logs in binary format is a good idea.

<rant>
I mean, seriously, we've been cursing over the uselessness of the Windows Event Logs since NT 3.1, and only recently has Microsoft introduced features (event subscriptions and the ability to attach tasks to events) that makes it possible to collect events from multiple servers and act on information in these logs. Meanwhile we've all been using 3rd party tools to export them to syslog in order to process them with grep, sed, awk and the like. Which is possible because syslogd writes log entries to text files.

Now systemd turns the clock back 20 years and introduces log files in binary format. Why on earth would anyone want that? Surely, in addition to making it harder to read and process logs, it must break every automated log processing system and host-based IDS/IPS currently in existence?
</rant>

OK, back to the video.

5 members found this post helpful.

But that was my point exactly - you did NOT "compare" any numbers.

And in this post I did not say anything "crap" about systemd, only about the utter uselessness of the "number" that you posted without any context, no "proof" if you will.

But meanwhile, the best proof and all reasonable statements contrary to systemd posted to this thread, you seem to ignore, or at least not understand.

I do have an opinion or two about Mr. Poettering, but I did not express them here. To what do you refer? (A rehtorical question, I really don't intend to engage the tar baby).

Like I said... stranger and stranger...

Of course my machine is a desktop machine, so I don't have any kind of server-related installed on it.
I'd like to know what services you have in mind when you say they can't be started at the same time.
There are very few of them but some are very obvious of course.
For instance you cannot start KDM before mounting your root partition.

But no, systemd isn't really about reducing boot time, it's just a side effect of doing things right.
Binary may seem evil at first glance, but they are not. It's actually a lot more powerful then what syslog offer (as far as i know). Here's a quick overview:


journalctl -b => Display the log from last boot only
journalctl -r => Display entries from the log in reverse. So you get at the beginning what happened at the end of the log.
journalctl -u $unitname => Display log entry for this daemon only.
journalctl --since=$date or journalctl --until=$date => Display entries in the log that ar newer or older then the specified date.
journalctl --disk-usage => Shows the current dis usage of all log files.

You can almost combine every option too.
And there is a lot more, this is just a quick overview of the nice thing that journalctl can do for you.
Application can log error in journalctl too, it's nice too have a all logging in the same place (eventually it'll be I hope )

Yes, you are right on this one.
It's just that it is a PITA to do some boot time benchmarking on sysvinit.
There's the fact that I don't have any sysvinit machine in my hand right now too.

Did you ever read the signature of ReaperX7 ?

All of these things can be done with text logs, with standard UNIX tools like grep, sort, awk, and find.

That the developer chose to re-implement existing functionality suggests to me they didn't know it was already there. That doesn't bode well for them.

Yeah, you can implement all this with shell script for sure but:

1) I'm not a C programmer, but isn't shell script slower then C ?

2) It's available natively with systemd which in my opinion is better then hacking a couple of shell script.

Arch users do it really fast.

1 members found this post helpful.

Does this work in a system that I chrooted to or on logs from a not running system that I have mounted from a live-medium?

What do you mean?

journalctl has a --directory and a --root option, so yeah you could use journalctl against logs from a mounted partition somewhere on your hard drive, if your livecd contains systemd of course.

Not sure about the chroot, but I think systemd-nspawn should be able to handle this.

I call Strawman Fallacy. These tools (grep, awk, find, sort) are written in C, and have become extremely well-optimized over the years of their development. I never brought up shell scripts.

To reiterate my point: This utility that ships with systemd only re-implements functionality that is already available for text-based logs, using standard UNIX tools.

1 members found this post helpful.

And amen to that!!
I'm sorry, but the wheel has allready been invented - there is no way 'round' will be that much more 'round' that it is worth the change ...

1 members found this post helpful.