Well, yes and no. journald was meant as a total overhaul of _local_ Linux logging. It provides "metal-to-metal" logging by being able to operate in initramsfs before rootfs is mounted, and pivot back to initramfs (Dracut) after rootfs has been unmounted. It collates all logs into a single view, instead of the myriad of scattered legacy log files (including binary logs like utmp etc).
It also vastly improve the way programmers can use logging, since syslog(3) etc. have so many limitations regarding speed, messages per seconds etc.
It also provide structured logs with plenty of metadata like monotonic timestamps that are troublesome in syslog text logs.

Rsyslog and similar syslog implementation works both as a _local_ logging system _and_ as a remote log sink.

journald doesn't work as a general log sink for remote logging, nor does it provide DB interfaces and various other similar plug-ins. So for general log-sinks, Rsyslog was always meant to be choice.

journald was also designed to be 100% compatible with syslog since it was obvious that legacy requirements would make that a necessity. So again, for legacy setups, syslog was always the designed choice to run on top of journald.

The glaring problems with flat file, unstructured text logs have been discussed for decades now. Plain text log files, like the original syslog(3) interface was simply bad ideas that Linux inherited. The main commercial selling point with any syslog implementation today is exactly that you can avoid several of these problems by using a DB.

An overhaul of the creaking legacy Linux logging system have been needed for a decade at least. Remember, the Rsyslog project was started exactly to fix such problems. They failed partly because distros and developers don't care about working together for a common goal and because there was no other central developer hub who would take the initiative.

systemd have finally fixed so many of the classic syslog problems. I don't care if you think syslog is perfect and never can be improved, and Rsyslog should be avoided for providing binary DB storing option, but please don't think that other people agree to this postulate.

And systemd's journald is designed to be 100% backwards compatible with syslog, so if your setup have legacy need, it is trivial to get a systemd distro to use legacy syslog text logs.

I doubt that you can provide a link for that. Perhaps you are hinting to the RFE about "pruning" journal logs containing "corrupted" field values?

That is part of the Unix philosophy: (Rule of Repair : http://en.wikipedia.org/wiki/U...), or "if you have to fail, fail early and fail noisily". systemd is build around that; so if disks specified in fstab doesn't show up, it won't boot but give a rescue shell instead. This prevents silent data loss; a classic example of "Rule of Repair".

Been using systemd on Fedora for several years now; it has been rock solid. systemd is just so much better than any alternative out there, and for every release it just keeps on getting better. I love its logging system and the easy and natural way it handles OS containers and system service management.

Stateless boot is nothing new in Linux. What the systemd developers want is to make Linux generic enough to make stateless boot work for those who needs it, instead of each and every developer group making their own proprietary tools. Stateless boot are mostly for embedded but also allow for some interesting network booted options.

There is a lot of work to be done before it is possible, but with systemd people are at least working on it.

Regarding the FHS and where to put things like using /run.
systemd is only doing the sensible thing here. The FHS 2.0 is ancient, so the systemd way of doing things is likely to become FHS 3.0, and then it will be a Linux standard.

Of course you can push journald logs over the network in several different ways, and you can also receive them using the journald. But the systemd journald isn't substitute for syslog, but meant to complement it. Just use rsyslog when it is relevant, or just systemd's journald when that suffices.

Here is the document info for "journal export format"
http://www.freedesktop.org/wik...

Here is how to receive or pull systemd journals across the network: It can either pull log requests or passively wait for a connection:
http://www.freedesktop.org/sof...

Here is how to serve journald log entries across the network:
http://www.freedesktop.org/sof...

Yes I do. It is great that you can use exactly the program you need, even if their usage normally are orthogonal. Please note that PA doesn't disable itself, it just automatically suspend until needed again. PA and jackd where made for different reasons and solves different problems.

Well, some people thought they could stop the systemd progress by waging a negative campaign against it and its developers. That of course was a predictable failure.

Personally I don't care whatever init system people run. Even if I find e.g. SysVinit inferior to systemd I have no problem with people using it, and they owe me no explanation for doing so.

Systemd-opponents don't agree upon what they do like, they can only agree on what they don't like. This make their tactics so rabid and aggressive when attacking systemd, its developers, the distros that uses it and even its users. They simply don't have a positive alternative they can agree upon, so they are left with negative attacks.

journald has excellent export capacity, it is trivial to convert everything into JSON or similar industry standards without tedious data massaging. Unlike the many slightly varying syslog implementation with deviating output, journald output is always predictable since has a stable API and is structured around fields. This is a massive win for everybody, especially those who needs to put their logs into full DB's (for legal or whatever reasons).

Adding full microsecond precision and monotonic timestamps and wall time timestamps + all the other interesting meta-data and the log message itself, are making the text log entries extremely long and unfriendly to read for humans. With journald you only see such meta-data info if you ask for it. Much better solution. And if you are concerned about log sizes, journald has transparent compression. With text logs you need to unpack or use specialised tools to manipulate them if compressed.

Plain text logs sucks for so many reasons, their only redeeming feature seems to be you don't need to pipe them through a tool in order to read them.
I have much respect for the Rsyslog developers, and I remember how I hoped they would fix the most of the glaring syslog problems when they started out a decade ago and in their own way tried to solve the problems that journald does. They partially failed, not because they weren't good, but because changing certain stuff in Linux userland is extremely hard.

sysvinit is crude and simple because it pushes all complexity out of init into userspace and because it offers no worthwhile init functionality. That is why Linux endured decades of remote exploits since SysVinit wouldn't take responsibility for dropping daemon privileges or do socket activation like systemd does, so daemons didn't have to use complex and error prone privilege dropping code just to get a port below 1024.

With systemd and new style daemons you can just avoid all that crap in the daemons. Much better to have one central place for security code made by experts than each and every daemon needs to compensate for the abysmal lack of functionality and security features of SysVinit.

I don't care if some people think that SysVinit is the best init system ever made and that it has no errors and can't be improved and Linux should use it forever and ever. We happen to be a lot of people who don't see it that way, which is why we like systemd and chooses distros that support that.

Great that syslog works for your usercase. I doesn't for me and so many others. There is an entire industry build around the need to beat syslog files into some sort of structure and give them an index so you can do number crunching on them.

These days log files grows so fast and is so important for business decisions that only machine parsing can do the job properly. The journal is excellent in that regard too.

Another problem with text log files are their limited ability to incorporate much meta-data, since that makes the log lines unreadably long. So having full microsecond precision and monotonic timestamps is a problem.

Yes, at some point a Mark I eyeball is going to look at a tiny subset of the data, but these isn't a problem either with systemd's journal; all the usual standard Linux text tools work through piping. And there are language bindings up the yazoo so you can manipulate it the journal files directly with Python scripts etc. It is so easy to extract the data that you need.

Personally I find syslog text files pretty hostile to newbies; unless they grep well and know a variation or two of regex, they are bound to just plow through the logs trying to identify some error. Really, many of them even resort to editors for reading log files. And the DE developers can't make a distro agnostic GUI log viewer better than "less" because there is no stable text log API. With systemd's journal they can because it has a stable API and language bindings etc.

With journalctl it is so easy to make even powerful extractions like; just show me logfiles generated the last 5 minutes (journalctl --since -5m) or all errors with syslog level "warning" and above created since this boot (journalctl -b -p warning). There is tab completion of every command option and every journal field and ususally even of the values of those fields. No need to memorise obscure arguments and subsystem names.

Sure it is possible and has been done before. My point is that no distros seem to use such a init-system and that no other init-system have anywhere near all the nice features that systemd has.

You don't seem to have experienced many LKML flame fests before, so I think you will be sadly disappointed when Linus merges kdbus.

Have you even read the lkml? Linus is deep into discussion of the code and even defended kdbus design decisions. He would never do that if he didn't intend to merge it as some point when enough people thought it was good enough.

Also notice how Linus appeared in the first kdbus patch threads. He didn't comment on the code, so the only reason he mailed was to signal to everybody that he followed this, and this was just business as usual.

Sure, the kdbus maintainers will have to do a good enough job in fixing problems before it is merged, but as it looks now, this doesn't seem to be a problem.

kdbus is good stuff that can benefit everybody, and while it isn't a shining-new general purpose IPC that some kernel developers want, it does solve real world problems, and that is exactly what Linus think his kernel is all about.

This not about spending money or HiFi, but on what you use the audio system for. On consumer audio you want low cpu and battery drain and accept the tiny latency associated with this; that a music stream start 20ms second later doesn't matter. It is also important that features such as streaming, bluetooth head sets integration etc. works out of the box etc.

With Pro audio latency is king. cpu and battery drain means nothing.

PA can provide both things, by suspending out if your need shift from consumer audio (PA) to Pro audio using jackd. No need to dedicate your box to either; they can both work for whenever people need different solutions.

A bug from 2007 on Ubuntu that famously fouled up their PA implementation, hardly a serious complaint. This 2012 shows how PA even beat Androids audio stack (Audioflinger) regarding CPU and poweruse.
http://arunraghavan.net/2012/0...

There are several such benchmarks that shows how good PA is in this regard.

Unlike you I have several years of experience with systemd. You just seem to parrot the party line propaganda from the tin-foil hat systemd-haters.

Don't run with the pack. Try to actual examine systemd by reading the documentation and get some experience yourselves. It takes some time to really understand how systemd works.

systemd's journal is a basically a textfile that uses another line delimiter and have an index. Try "strings" on it, or a hex editor.

Here is is the systemd interface and portability chart. Notice sd_journal and the journal file format:
http://www.freedesktop.org/wik...

Here is the file format;
http://www.freedesktop.org/wik...

There are loads of other developer information about accessing the journal with Python language bindings etc.

Well, you are not the first person to think about how to extend text logs with some kind of index, and it would be nice if it could have microprecision timestamps, and monotonic timestamps like the journal does. The problem is that is unworkable.

As I said, several projects have tried to fix this without any luck for the last couple of decades.
Another problem with such a solution is that standard Linux text tools like grep, tee, sort etc. won't work with such a solution where the index isn't part of the text file, and metadata like microsecond time stamps tend to make the log lines unreadable long.

With systemd's journal all standard text tools work with the index and metadata, so you can grep monotonic timestamps by a simple pipe.

If it was possible to have indexed, and structured plain text log files that didn't require a special "translator" in order for the standard Linux text tools to work, it would have been implemented a decade ago.