Slashdot Mirror
Linux 4.1 Bringing Many Changes, But No KDBUS
An anonymous reader writes: The first release candidate of Linux 4.1 is now available. Linus noted, "The merge window is pretty normal in terms of what got merged too. Just eyeballing the size, it looks like this is going to fit right in — while 4.0 was a bit smaller than usual, 4.1 seems to be smack dab in the middle of the normal range for the last couple of years." There are numerous new features in Linux 4.1, like Xbox One controller force feedback support, better Wacom tablet support, Intel Atom SoC performance improvements, Radeon DisplayPort MST support, EXT4 file-system encryption, ChromeOS Lightbar support, and ACPI for 64-bit ARM, among other additions. However, KDBUS wasn't accepted for Linux 4.1.
The article doesn't state why KDBUS was rejected. Like everyone else, I consider systemd to be vile, but what techical reservations does Lignus have?
systemd is great stuff, only a tiny but vocal minority disagree with this. Keep your SysVinit for the next 30 years if you please, the rest of us wants systemd.
Linus Torvalds have long signalled that he wants kdbus in the kernel. What he is waiting for is the usual kernel process to work. At the moment the technical debate is about allowing certain kinds of meta-data to be transported around. The broader problem is that most kernel developers have very little experience with user space system glue like dbus, and you have to understand dbus in order to understand kdbus, so the review process will take some time. Nothing really unusual about this however, sometimes it takes a long time before features are accepted into the kernel.
Having used Linux audio from before ALSA came into existence, and having used PA from the beginning, I can assure that PA was a major step backwards in fixing Linux audio
Oh so you miss the days of manually setting sound card jumpers to set DMA and IRQ with certain software only accepting a subset of these, and you miss how each and every program fought over access to the sound card, and how there was no system sound daemon that worked across the different DE's so each DE had its own shitty sound daemon, and in those days where you really had to know what chipset your sound card used because so many chipsets was unsupported or had quite broken drivers. And don't get me started on that shitty company behind OSS that started to close source their stuff in order to extort money from Linux users and distros.
PA is great stuff that solved many real world problems with sound on Linux.
When I tried to configure PA to use a sample rate over 100KHz last year, it consistently brought down the entire system. This was on a very capable machine, and high sample rates should be a basic use case for PA. I didn't dig into the cause, but it was PA itself that thrashed the CPU, so it seems unlikely that particular defect was caused by the layers underneath.
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.
I'm not even going to get into a pro/anti systemd argument becauser that's actually not relevant here, but this is why people get annoyed with the systemd folks, because of the mindless zealotry/ignorance. No offence, but solutions to this have existed for YEARS and have been implemeted in plenty of other systems.
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 have a text based log file, which just works with everything. You also have a separate binary index which indexes the textual log file. You get the benefit of fast lookup if you use the index and it will just work no another machine if the original tanks and you don't have the right version of systemd on the new machine.
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.
Did you actually read my post which was about a very specific point about binary versus text versus INDEXED text log files
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.
Well if so, that's new. It never used to be the case that the binary format was stable. So, I'm going to ask you to provide a link to the description of the binary structure.
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.
Jesus fucking H. Christ on a stick what is wrong with you? I specifically went into detail about how noisy the pro-systemd people like you insist on a dichotomy between unstructured text files and binary file formats. There is no fucking dichotomy you moron. If you actually read my sodding post instead of going off on a rant then you would actually become marginally more informed and stop spouting the same old shit repeatedly.
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.