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.
Rather typical LKML discussion in my opinion, but blown out in all proportions by the systemd-haters because they wrongly think that Linus don't like systemd nor its programmers because of this.
No it wasn't. Linus made his views on when this stuff will get merged, if ever, abundantly clear. It's not blown out of all proportion. That's what was written.
You don't seem to have experienced many LKML flame fests before, so I think you will be sadly disappointed when Linus merges kdbus.
Linus Torvalds have long signalled that he wants kdbus in the kernel.
No he hasn't you liar. I'm afraid this propaganda ain't going to have any effect whatsoever on his views.
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.
You know what's different about consumer and pro audio? Nothing. As it turns out, consumers also want high-fidelity audio, and they want to be able to mix multiple streams. The only difference lies in what the industry is willing to sell us.
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.
Actually, pulseaudio has notably drained batteries in the past, because shitcode.
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.
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.
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:
Here is the file format;
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.
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.
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.
A previous poster linked to a post by Eric Biederman that should be required reading for this Slashdot thread. I'm not sure which part to quote, because the whole thing is pretty damning: Kdbus needs meaningful review
On one hand, the post (and lack of kdbus in kernel 4.1) seem to indicate that you are correct, and the process is working. OTOH, Eric argues that:
- Kdbus code is nowhere near ready for a merge, it hasn't been reviewed, and in fact may need major reworking before it can be used or reviewed.
- Kdbus authors are pushing the merge very aggressively, and have made a habit of ignoring criticism and refusing to take steps necessary to even make the code reviewable.
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.
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.
Security I don't see how, moving it in the kernel is an improvement. You add all the risks associated with being able to step all over systemically important data structures to a "process" that by definition has to communicate with a largish number of less trusted processes. If you limit who/what is allowed to talk to dbus with a firewall like solution you make dbus less useful as an IPC channel.
Kdbus will really will provide several layers of extra security since LSM's like SELinux can hook into the system from the kernel and not in the much less secure userspace. You also gain kernel guarantee for the message marshalling.
The performance considerations might be a justification but I have never really seen DBUS as a high performance IPC channel anyway.
That is exactly because dbus is extremely slow when it comes to data transport.
Maybe I am just badly misinformed on its planned usecases. I thought it was for deriving simple short messages like "A new input device is a available" not shoveling megabytes of data between processes. We have fifo pipes and UNIX sockets for that, and if latency is an issue there is always shared memory.
The point is that many developers, especially embedded and IVI (and DE's like Gnome and KDE) are interested in using the same framework for both control and data. Having side channels to dbus in order to gain speed for data means maintaining proprietary frameworks that has to duplicate much of what dbus does anyway.
This will also be a great help regarding sandboxing of applications.
See more here:
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.
Many systemd proponents harbour fantasies of it being the one true way of doing......anything and want to wave away the problems.
This is not about "one true way", but I genuinely don't see no interesting alternative to systemd. After having tried the benefits of systemd-journald with collated, structured and indexed log files, there is no way I ever will go back to using unstructured, un-indexed text log files scattered all over the system.
And since the systemd-opponents party line is is that binary log files are always bad, they won't make such an alternative.
This, by the way, is Linus's take on kdbus and why it won't be seen in the kernel for some time to come, if ever:
No it is not, I actually read the LKML at the moment, and I can assure that Linus is positive regarding Kdbus and its design goal and that it will be merged once he is confident that potential security problems have been fixed.
Hopefully the open source community will review kdbus code very carefully and perform security testing before adopting this.
They will. Sure there will be lots of sparing and harsh word duels, and not everybody will be happy, but that is how the process works for any major kernel feature. In the end the process tend to produce good enough results.
Pulseaudio-style bugs and instability could be very bad in the kernel.
Having used Linux audio from before PA came into existence, and having used PA from the beginning, I can assure that PA was a major step forward in fixing Linux audio. With PA sound on Linux actually began to work. Sure it exposed a lot of kernel bugs (drivers) and ALSA bugs in the beginning, and some distros and software got the implementation wrong, but it lead to the first coordinated bug fixing effort between drivers, ALSA and user space. PA was always rock solid for me, and while it had some bugs, but far the most serious and numerous was in the drivers and in ALSA layer.
Even those who smugly announce they don't use PA benefit from all the work the PA, ALSA and kernel developers did together.