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.

The whole point I was trying to make that looking back on sound on Linux in the days before ALSA and PA shouldn't be done with rose tinted glasses. Claiming that, like the OP does, that everything went backwards with the invention of ALSA and later PA is just absurd. Those where the bad days regarding sound on Linux. There is nothing to miss from those days, including ISA sound cards.

With ALSA and later PA there were actually people working on the Linux soundstack and developers that could coordinate bug fixing. And PA was a huge help for DE developers that where so tired of trying to maintain their own sound servers and dealing with really low level kernel stuff like drivers, when all they wanted to do was to develop for the desktop.

Practically nobody was using Upstart on Debian at that time according to popcon. That the Upstart maintainer voted for his own project was natural, but among the rank and file DD's the support for systemd was strong, while the fact that there was a Upstart CLA made it unacceptable for many others. I think it was only Debian's affinity with Canonical that even made it an alternative at all.

I think Ian simply cooked off in some major rage fit. He wasn't entirely rational about this issue after that.

Really, please show me a non-systemd Linux distro that doesn't use scripts for setting up daemons and boot, thereby mixing code and config statements in one unstructured code lump that are hard to parse for both humans and machines. And does it provides high level API abstractions for cgroups and kernel capabilities so SA's can use them for all daemons just by adding a simple key/value line in a text config file?

I am well aware that SysVinit and endless variations like it such as OpenRC exist. But they don't provide any meaningful competition to the many features that systemd provides. You may be happy with SysVinit and its many limitations, but I and so many others aren't.

If you don't recognize how superior systemd is to existing alternatives, you also say that no new development is necessary for the non-systemd distros in order to stay competitive. I would like to see some real competition to systemd, but it doesn't happen, seemingly because the systemd-opponents have dug into their own grave claiming that everything existing is good enough and systemd is just bad. Shrug.

You really are uniformed about systemd's journal; its structure and layout and API have been fully documented and is stable. That means you can read any journal with any systemd version. At worst you may miss out certain extra meta-information fields that have been added later, but nothing essential will be missed (and it will be information that any text based syslog implementation won't have anyway).

The systemd journal is designed to be read on other machines, and it does it exceedingly well, like reading from nspawn OS containers, etc.

Plain text log files have been a problem for Linux for decades, and many projects, including Rsyslog was started exactly to overcome the many limitations with both the syslog interface and the plain text log files.
The current journal file format, which is basically an appended text file with index, is a great compromise between having unstructured, unindexed text logs with no meta-data, and running a full sql-server.

If the non-systemd distros have a better idea, then great, let them implement it, but I fear the usual answer will be that text logs are the final word in logging, and that no new development is needed.

You are interpreting this much too hard. Every time a new important kernel features come you have these kind of statements. The point being that some reviewers set the standard to "perfect" to begin with. That way nothing will be merged, so from now on people have to battle out the details until Linus is satisfied. Eg. Linus has personally stated that some of the criticism that Biederman repeats are wrong (about caps metadata in an exchange with Lutomirski).

All in all this is business as usual, and the kdbus developers have been very very quick to change anything specific that has been pointed out as problematic. That they are eager to get things merged is just how such things work, same with reviewers that says "hold your horses".

There are pretty good odds on that kdbus will be merged into mainline in not so far a future when things have been trashed out on lkml a while.

Please note that PA is for consumer audio, that means general purpose desktop and sound server use. It works great for that and doesn't drain batteries and so on. For specialized use or Pro audio where latency is king ALSA directly or jackd. No PA expert but if the driver/hardware doesn't support sampling above 96 kHz you should expect problems. +100kHz really is an unusual user case.