That's bizarre. I'm not a sysadmin, I'm only running Linux on my work laptop and my personal desktop. For Fedora 21, if I do "journalctl -r -o verbose" I'm getting plenty of priority 6 and priority 7 messages in the output.

Anybody else have access to Red Hat 7 to check?

AMD graphics, yes. With the open source drivers. I understand the drivers have gotten better over time, but I guess they're not up to Windows or Linux nVidia proprietary driver standards.

Are you trolling? I've never heard that the systemd journal discards startup information. I'm seeing everything on my Fedoral install. dmesg looks normal too.

Besides, you can run rsyslog alongside the systemd journal.

s/we the users/we the people who want open source software to be more popular and are willing to work to that effect/

I didn't mean to imply users are expected or forced to contribute. I meant that fans - and I consider myself a fan - that want this to be more popular should contribute because it will help that goal. Happy now?

Sure it is useful on the server. In no particular order:

1. The journal digitally signs each entry with the entry contents and the hash of the previous entry, so that for an attacker to insert a spoofed entry or remove a valid one they have to alter the signature on every entry after that point or else the signature mismatch will be detected. And you can still also send logs to rsyslog if you want.

2. Faster boot time does matter for a server - when you need to move physical boxes, add hardware that requires a power cycle, and so forth less time to restart is helpful.

3. You don't need to run "piles of things" with systemd. It's modular, so you only need to compile in the services you want. http://freedesktop.org/wiki/So...

4. Systemd lets you set limits on resource usage by each service: memory limits, CPU limits, Block IO limits, etc... which is useful on the server.

5. On-demand socket-driven service start is useful, so ssh is available 100% of the time but sshd isn't actually consuming resources until it receives a connection attempt.

6. Per-service private /tmp directories, configurable read-only access to some directories, so a hacked service can't access information it should not or make invalid writes.

7. Because of the use of cgroups in the Linux kernel, when you halt a service you can be confident there are no uncleaned resources - threads, forked processes, file handles, etc... left in use.

8. systemd is compatible with services written in any programming language you want, including shell scripts, so you don't have to rewrite your custom SysV init service in systemd. Just spent a few hours in the documentation to make the text file you need, and you're set.

I'm running Ubuntu 15.04 alpha and Fedora 21, and /dev/hd?? and /dev/sd?? are still supported. UUIDs are just preferred.

You're one of the people who didn't actually read any of the systemd documentation. Why should I waste my time responding to you? But because I'm stupid, here it goes:

1. FreeBSD, OS X, and Solaris have all moved on from SysV init. Do you think they did that because it was fun? Because they felt like it? Or maybe because there were design flaws and maintenance headaches in SysV init that needed to be addressed?

2. You can run the systemd journal alongside rsyslog. And the journalctl command for getting text output from the systemd journal takes all of twenty minutes to learn.

3. Systemd services are written in C by convention with text configuration files. But you can run any executable you want as a systemd service: shell scripts, C++, Perl, Java, Lisp, Ruby, COBOL.

Come back and raise an objection after you RTFM.

I didn't say 10% were people with legitimate complaints, I said 10% were people who understood the tradeoffs. A tradeoff implies advantages as well as disadvantages. So it's not the end of the world.

Nope, because usually when you add a new drive you reinstall Linux. It's free. Anyone who understands enough to transfer the whole filesystem image from one disk to another disk is going to update /etc/fstab manually.

Of course I understand where you're coming from. I'm practical, too - I run mostly free (as in freedom) software, but I work on proprietary software to pay the mortgage.

But the thing is, by living that way you let Microsoft or Apple control aspects of your digital life that they have no right to touch. Consider that.

You admin Red Hat and Solaris. I'm sure the price premium of proprietary software also isn't a headache for you unless maybe you wanted a private copy of Oracle 11. But for most of the population, $100 for Windows whatever or $400+ for a new machine or $150 for a professional reinstall after they get hit with malware is all a very big deal. I was having budget problems and was making less than half my current income when I got interested in Linux. I could afford to pay the Microsoft or Apple tax now - but thanks to the skills I developed then, I don't need to. I donate some of the difference to Debian and keep the rest.

Every dollar we throw at Microsoft and Apple - and Google, Oracle, etc... - strengthens proprietary software, strengthens the hold of Digital Rights Management, makes it easier for the government to snoop on all of us as a matter of routine, and makes it harder for poor people to get a good computing experience. Every dollar we put into open source strengthens open source software, weakens DRM, weakens privacy invasions, and makes it easier for regular people to have a good technology experience without spending more than they should budget to get it.

I'm not an expert in X, so I'll have to lookup "grab_break" and xkb and screen locking screensavers.

With respect to the systemd binary journal, a design document is here: https://docs.google.com/docume... Each entry is digitally signed with the hash of the previous entry. So any attacker that gets root can rewrite an entry, but in order to make the digital signatures pass verification he's got to rewrite the digital signature on the modified log entry and on every log entry from that point forward in time - feasible, but a lot more work than just modifying a text file and then changing the timestamp in a traditional log. and you can use rsyslog alongside journald.

It was? When? I've been using since 2001.

Thanks for the correction. You're right, and I didn't allow for that possibility.

Well, if you take the first panel of that comic there are two possibilities, right? The first possibility is that one or more of the existing standards has a design adequate to address the technical problem it tries to solve, and the people in the panel should throw their weight behind one of those. In that case, creating a new standard is counter-productive. The second possibility is that all thirteen competing standards are inadequate and a new attempt is required. In that case, creating a new standard is the right thing to do.

I agree on your first point, and would add that if your application runs on the command line then you will increase your chance of popular use and recommendations by a factor of ten by giving useful error messages and ending with "for more information, run 'man foo'" so that a complete newbie gets help.

On your second point, I emphatically disagree. Read Poettering's blog, starting with "Rethinking Pid 1", then "Biggest Systemd Myths". The backlash against systemd is 90% people who don't even understand systemd and have been too lazy to RTFM and 10% people who understand the technical tradeoffs and think differently, all spurred on by Slashdot, Phoronix, and a dozen other sites making a mint off the advertising revenue from people visiting the flame war. And the documentation for systemd, both at the official website and from the man pages, is outstanding.