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: https://lkml.org/lkml/2015/3/9...
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.
Seasoned programmers that "know their stuff" that have been told to keep their un-maintained junk out of the kernel before now? And in no polite terms?
Kay Sievers _is_ a seasoned programmer. He maintained udev alone for many, many years. What he and Linus disagreed upon was whether you should fix broken kernel features or not. Kay thought you should, Linus disagreed. 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.
"Worked beautifully" resulting in many unbootable (or, worse, variably bootable) systems over the years.
Pure rubbish. Sure Sysadmins running with broken fstabs was caught by surprise (who really reads the release notes or study a major piece of new software like systemd before upgrading the servers).
That systemd refuses to boot with disk setups that doesn't work, is because it does right thing to avoid raid array wipe-outs and silent data loss, and because it respect how the sysadmin have configured the system. SysVinit just ignored what fstab told it and bumbled along with the boot.
I don't think anyone is opposed to change on the SysVInit side (the very existence of upstart and a variety of other projects), they just don't think this is the right change.
I think the systemd-opponents are deeply split about this; the BSD-Linux users want OpenRC because that is close to BSD and hates systemd because it means work for BSD, the traditionalists want SysVinit forever "because it isn't broken and systemd doesn't provide new features...". Nobody wants Upstart.
Almost nobody is working on an init-system that basically isn't a SysVinit variant. Considering how small a minority the systemd-opponents are, then any sub-set of this group is positively tiny.
It is worth pointing out again, that the negative campaign against systemd, also have stifled any development of any meaningful competition; if systemd is overall bad in every aspect, why even bother developing an alternative? It is so much easier to take refuge in paranoid conspiracy fantasies on how systemd won over every major Linux distro, by dark cabals working behind the scene.
KDBUS is just another IPC mechanism, and while it might need a little more work before going mainline, its not some evil systemd plot to take over the world. I think its time some of you put down the tin foil hat, take a deep breath, calm down and look at it as the IPC interface that it is.
Well, Kdbus is more than just simple IPC, it is also provide a control framework with policies etc. just like dbus does.
What the tin-foil brigade don't understand, that any non-dbus compatible IPC will be a major problem for all non-systemd distros and BSD variants, since it per default will be Linux only, and in reality a systemd-only affair, since only systemd distros will have the developer manpower to implement and support the necessary userspace libraries.
With Kdbus, userland can just continue to use legacy dbus code that works across all Linux and BSD distros. And the non-systemd distros can use kdbus too by only providing a minimal mechanism that initiates Kdbus at boot.
All in all, the non-systemd distros should really cheer for Kdbus in the kernel, since any other alternative will swamp them with work.
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.
Systemd is one of those thing that people know will end in disaster. Sure, it works at the moment. But a personality will jump into it, or a bug will catch up with their design, or something else. And it will all come crashing down.
Sure, many systemd-opponents harbour fantasies like that. Since they claimed that the systemd developers are bad and inexperienced programmers that can't code or design, that the systemd design is bad and that the code is bad, it puzzles them that despite all this, systemd have worked beautifully for so many years.
But the brutal and inescapable fact is that systemd is coded and designed by top notch, seasoned Linux programmers that really knows their stuff well, and that systemd also work really well and solves so many old problems.
It is one of the hilarious facts that the solely negative campaign the systemd-opponents have waged against systemd, belittling it and its developers, that this has also prevented that any competitive alternative could be developed. By being unable to make a cool assessment of systemd, recognizing its many strong points, you can't even begin to formulate an alternative strategy that can convince technical minded people outside the very small circle of systemd-opponents.
Which is good. Systemd has already stated they will hard depend on it and equally a systemd bump will require a bump of the kernel. For those that are on systemd then finding themselves in a situation where an upgrade/downgrade of either the kernel or systemd (oh I don't know... due to a issue) renders the system unbootable is worrying...
A typical misunderstanding by people quoting a systemd-devel mail out of context. They don't intent to keep the kernel and systemd in lock step for every release. They haven't done before so why should they do it in the future. What they do want to do is require kdbus kernels in the future, and that will bumb the minimum kernel version from 3.8 (or whatever) to 4.2 (or whatever).
At the time when such an edition hits stable distros, there will be no problems with downgrading to a previous kdbus enabled kernel.
Also remember that systemd follows the same pattern as the kernel development with bleeding edge releases and long term stable releases. Nobody is forcing anybody to use the newest systemd available, use a long term stable version (208, 215 etc) if you please.
Is that any excuse for just hanging indefinitly (5 minutes my arse - saw one hang overnight) without any output to anywhere to tell you what is going on?
Well, SysVinit systems aren't magic either, if there is a kernel-GPU bug or similar low level error, systems may hang forever without any useful output, and without rootfs there isn't any logging done.
But did you try VT9 etc.? Was crash shell enabled? I find that systemd with initramfs like Dracut is a breeze to debug when it comes to boot problems; stuff like "rd.break=pre-mount" is great if there are serious rootfs problems, or appending "1" or "emergency" to the kernel cmd-line. This is a good start page about debugging systemd machines: http://freedesktop.org/wiki/So...
Playing around with a systemd-nspawn OS container is also a good way of simulating various boot errors and how to recover from them.
All in all, systemd is a great improvement when it comes to boot problems, not at least because there can be full logging from initramfs already.
You mean untested, unaudited code that is forced into production environments?
systemd code is both thoroughly tested and audited. In fact, Red Hat has a professional security audit team that actively audit systemd code, this is more than can be said for OpenRC or SysVinit or any other systemd alternative.
They also have integrated Coverty static code checking and good coding guidelines to ensure maximum security.
systemd have been used by distros since 2011 (It predates the Linux kernel 3.0 series) and some of its code like udev goes back to 2003. It is much better tested than most other Linux software.
It is pretty close to 4 years since the Fedora 15 was released with systemd: LibreOffice was 3.3.2 (4.4 now) Apache was 2.2 (now 2.4) Kernel was 2.6.38 (4.0 now).
It is absurd to suggest that systemd isn't proven and tested in the wild for a long period.
Also note that some systemd code like udev, existed even before the systemd project was announced, so at least part of the systemd code is much older than 5 years (udev was released in 2003).
This won't work at all. One of the most basic requirements of teaching is that your teaching level correspond to those you teach; aim to high and you loose them because they don't understand, aim to low and you loose them because they are bored. Having one "super teacher" yapping one-way lectures from a giant screen without the "teacher" knowing what his pupils can, is simply a lost cause when it comes to engaging and teaching the pupils.
And why the giant screen? Why not having each pupil following an individual course on individual screens instead of forcing everybody to follow the same course. And why the classroom at all if its only function is to supervise discipline among the inmates/pupils.
(Why not just strap the pupils to a chair in their home and force feed them lectures through Occulus rift headsets and noise-cancelling headphones; it is easy to motive the pupils through reinforcement stimuli like tasing them gently if they have wrong answers. This will be very cheap and is guaranteed to produce marvellous results.)
That's because you're ignorant. Try more Linuxes so that you can be exposed to more things.
Well, I know SysVinit (including variations like Slackware uses) and Upstart. Both are pitiful when compared with systemd, especially killing processes and handling PID's. And all the service management tools you can tack on top I know of like Monit and S6 are painfully labour intensive to use and lacks fundamental features. (Monit has pretty graphs though).
Any init-system without integrated resource management like cgroups and easy to use service monitoring and easy to use security frameworks using namespaces and capabilities, are hopelessly nobbled when compared to systemd.
Just the fact that systemd uses structured plain text files for service and daemon configuration is a huge win compared to using script files, that are basically executable config files that mixes code and config options in one unstructured lump that are hard to parse for both humans and machines.
Sadly, that didn't stop them from making their own sophomoric mistakes made by neither, nor useful idiots from defending their incompetence and poor decision-making abilities.
IMHO, most people criticising systemd haven't really bothered up upon its design or why it is designed the way it is, but rely on third party blogs and random forum comments. There really are good technical decisions behinds its design:
Take the logging system; if you want "metal-to-metal" logging, that is from before rootfs is mounted to potentially after it is dismounted, and you want to collate all logging messages, no matter how and when they are generated, you will end up with a design like systemd's "journal".
All other existing Linux logging facilities have logging gaps and are unable to create collated logfiles from the entire boot and shutdown process.
systemd really solves many old Linux problems in one go, not at least the problem with the partially fossilized plumbing system: eg. cron was made with the assumption that computer was always on. This is a problem when most Linux devices these days runs on batteries and frequently are suspended or shut down.
But there is not central cron-developer group, there are only fragmented forks of ancient abandonware versions of eg. Vixie-cron, so cron can't be fixed, nor can there ever be a new cron version that fixes any problems that will make it incompatible with cron. cron is simply doomed to permanent fossilisation.
Getting systemd-timers is so nice in that they not only fixes old cron problems, but also makes it possible to change future implementations of it. It is simply great that there is a central developer hub that can take RFE's and patches for this.
I am really not aware of any "sophomoric mistakes" regarding systemd's design; it is small, modular, lean on resources, fast, stable, have lots of great features that are very easy to use.
IMHO nothing else on Linux even come close to all the features systemd have, which is why all major distros have chosen to use it.
Yes. systemd had the advantage of learning from both systems, using what they did right and discarding what they did wrong (xml etc). The systemd developers really did their homework well in this regard.
I am sure that the FreeBSD developers will study systemd intensely before making their own version too.
Which is not the correct behavior for a headless server. The correct behavior is to start anyway and for any user processes that depend on access to the unavailable filesystem to exit with a -1 status and log whatever perror() spits out to standard error, at which point it is clear to the sysadmin what happened and without having the other stuff on the box held up.
Just bumbling along with boot even if critical disks are missing is just dumb. Allowing raid arrays to come online in degraded mode without any spares just because some disk were late in reporting in is stupid and dangerous. The sysdamin can always mark non-critical disks with "nofail" if he knows the userspace software can handle missing them.
Sure, not everyone agree with JH (yet), and FreeBSD do lack development manpower to make a fast transition away from rc, that is why he described it in a "FreeBSD the next 10 years talk".
My point is that FreeBSD _will_ get a systemd-like init-system, it is only a matter of when. Of course there will be a lot of discussion, and for political reasons it will be dressed up as not being a systemd clone, and people will moan about learning something new, and there will be lots of drama on the mailing lists whipped up by a small vocal minority.
But like in Linux, the vast majority of actual developers and FreeBSD sponsors will quickly realise the many benefits of doing things the systemd way.
systemd isn't a horrible implementation, it is in fact extremely good in many areas and extremely well coded and documented, which is exactly why FreeBSD will clone that instead of SMF/Launchd or try to invent a new solution.
I am just saying FreeBSD is a system made by sysadmin to sysadmins and not overrun by political bastardos. I sincerely doubt they will go the same route.
The co-founder of FreeBSD have already stated that systemd is a good thing and it is exactly what FreeBSD needs for the future: https://www.youtube.com/watch?...
There are already *BSD developers working on this, including a systemd compatibility layer. So yes, FreeBSD will have a systemd clone init system, and binary log files too, it is only a matter of time.
What I am saying is that what systemd calls "log database" is no such thing and massively inferior to the real thing.
Please don't confuse the term database with a RDBMS or similar. A database can be a simple text file with structured data like/etc/passwd. http://en.wikipedia.org/wiki/F... systemd's journal is by any definition a database file and since it contains logging info, I fail to see the problem in calling it a "log database".
I also _know_ that people that put logs into databases uses real databases, you know the ones that come with ACID.
Some use ACID RDBMS, some use non-ACID NoSQL databases, etc. It all depends on needs and to why they collect the logs in the first place.
What you do _not_ do is change the on-machine logs into a wannabe-database. That is about the worst thing you can do.
You are of course wrong about this, Enterprise log analysers like Splunk uses simple files and indexes to store events etc. pretty much the same way that systemd does.
There is considerably overhead when using ACID RDBMS', so when things needs to be really fast you do stuff like systemd and Splunk does. Logstash (probably one of the more popular log-analysers) doesn't use a ACID compliant RDMBS as backend either (though it can if you want to).
The point is that the world of logging and databases have moved on considerably the last decade. The primary reason being more and more data that needs to be analysed (fast) for one reason or another (Business, real-time security etc.).
systemd's journal is a pretty significant upgrade to the otherwise rather fossilised world of Linux logging. Don't get me wrong, I have tremendous respect for the Rsyslog team, but they have been struggling for over a decade to solve just some of the problems systemd's journal now have solved.
And I have have never really seen any good argumentation against using binary, structured and indexed log files:
They can be read by all standard Linux text tools with piping. There exist multiple independent readers for them. The logs can be programmatically accessed through a myriad of languages. They provide functionality that can't be matched with legacy syslog files. There is no non-contrived scenario where they can't be read one way or another. They can be exported in any format and have default export options for all relevant industry standards. Unlike syslog output, they have a stable and documented API.
So there isn't any real downside to using binary journal log files, while there is considerably advantages.
Slashdot Mirror
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:
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:
https://lkml.org/lkml/2015/3/9...
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.
Seasoned programmers that "know their stuff" that have been told to keep their un-maintained junk out of the kernel before now? And in no polite terms?
Kay Sievers _is_ a seasoned programmer. He maintained udev alone for many, many years. What he and Linus disagreed upon was whether you should fix broken kernel features or not. Kay thought you should, Linus disagreed. 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.
"Worked beautifully" resulting in many unbootable (or, worse, variably bootable) systems over the years.
Pure rubbish. Sure Sysadmins running with broken fstabs was caught by surprise (who really reads the release notes or study a major piece of new software like systemd before upgrading the servers).
That systemd refuses to boot with disk setups that doesn't work, is because it does right thing to avoid raid array wipe-outs and silent data loss, and because it respect how the sysadmin have configured the system. SysVinit just ignored what fstab told it and bumbled along with the boot.
I don't think anyone is opposed to change on the SysVInit side (the very existence of upstart and a variety of other projects), they just don't think this is the right change.
I think the systemd-opponents are deeply split about this; the BSD-Linux users want OpenRC because that is close to BSD and hates systemd because it means work for BSD, the traditionalists want SysVinit forever "because it isn't broken and systemd doesn't provide new features...". Nobody wants Upstart.
Almost nobody is working on an init-system that basically isn't a SysVinit variant. Considering how small a minority the systemd-opponents are, then any sub-set of this group is positively tiny.
It is worth pointing out again, that the negative campaign against systemd, also have stifled any development of any meaningful competition; if systemd is overall bad in every aspect, why even bother developing an alternative? It is so much easier to take refuge in paranoid conspiracy fantasies on how systemd won over every major Linux distro, by dark cabals working behind the scene.
KDBUS is just another IPC mechanism, and while it might need a little more work before going mainline, its not some evil systemd plot to take over the world. I think its time some of you put down the tin foil hat, take a deep breath, calm down and look at it as the IPC interface that it is.
Well, Kdbus is more than just simple IPC, it is also provide a control framework with policies etc. just like dbus does.
What the tin-foil brigade don't understand, that any non-dbus compatible IPC will be a major problem for all non-systemd distros and BSD variants, since it per default will be Linux only, and in reality a systemd-only affair, since only systemd distros will have the developer manpower to implement and support the necessary userspace libraries.
With Kdbus, userland can just continue to use legacy dbus code that works across all Linux and BSD distros. And the non-systemd distros can use kdbus too by only providing a minimal mechanism that initiates Kdbus at boot.
All in all, the non-systemd distros should really cheer for Kdbus in the kernel, since any other alternative will swamp them with work.
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.
Systemd is one of those thing that people know will end in disaster. Sure, it works at the moment. But a personality will jump into it, or a bug will catch up with their design, or something else. And it will all come crashing down.
Sure, many systemd-opponents harbour fantasies like that. Since they claimed that the systemd developers are bad and inexperienced programmers that can't code or design, that the systemd design is bad and that the code is bad, it puzzles them that despite all this, systemd have worked beautifully for so many years.
But the brutal and inescapable fact is that systemd is coded and designed by top notch, seasoned Linux programmers that really knows their stuff well, and that systemd also work really well and solves so many old problems.
It is one of the hilarious facts that the solely negative campaign the systemd-opponents have waged against systemd, belittling it and its developers, that this has also prevented that any competitive alternative could be developed. By being unable to make a cool assessment of systemd, recognizing its many strong points, you can't even begin to formulate an alternative strategy that can convince technical minded people outside the very small circle of systemd-opponents.
Which is good. Systemd has already stated they will hard depend on it and equally a systemd bump will require a bump of the kernel.
For those that are on systemd then finding themselves in a situation where an upgrade/downgrade of either the kernel or systemd (oh I don't know... due to a issue) renders the system unbootable is worrying...
A typical misunderstanding by people quoting a systemd-devel mail out of context. They don't intent to keep the kernel and systemd in lock step for every release. They haven't done before so why should they do it in the future. What they do want to do is require kdbus kernels in the future, and that will bumb the minimum kernel version from 3.8 (or whatever) to 4.2 (or whatever).
At the time when such an edition hits stable distros, there will be no problems with downgrading to a previous kdbus enabled kernel.
Also remember that systemd follows the same pattern as the kernel development with bleeding edge releases and long term stable releases. Nobody is forcing anybody to use the newest systemd available, use a long term stable version (208, 215 etc) if you please.
Is that any excuse for just hanging indefinitly (5 minutes my arse - saw one hang overnight) without any output to anywhere to tell you what is going on?
Well, SysVinit systems aren't magic either, if there is a kernel-GPU bug or similar low level error, systems may hang forever without any useful output, and without rootfs there isn't any logging done.
But did you try VT9 etc.? Was crash shell enabled? I find that systemd with initramfs like Dracut is a breeze to debug when it comes to boot problems; stuff like "rd.break=pre-mount" is great if there are serious rootfs problems, or appending "1" or "emergency" to the kernel cmd-line. This is a good start page about debugging systemd machines:
http://freedesktop.org/wiki/So...
Playing around with a systemd-nspawn OS container is also a good way of simulating various boot errors and how to recover from them.
All in all, systemd is a great improvement when it comes to boot problems, not at least because there can be full logging from initramfs already.
You mean untested, unaudited code that is forced into production environments?
systemd code is both thoroughly tested and audited. In fact, Red Hat has a professional security audit team that actively audit systemd code, this is more than can be said for OpenRC or SysVinit or any other systemd alternative.
They also have integrated Coverty static code checking and good coding guidelines to ensure maximum security.
systemd have been used by distros since 2011 (It predates the Linux kernel 3.0 series) and some of its code like udev goes back to 2003. It is much better tested than most other Linux software.
It is pretty close to 4 years since the Fedora 15 was released with systemd:
LibreOffice was 3.3.2 (4.4 now)
Apache was 2.2 (now 2.4)
Kernel was 2.6.38 (4.0 now).
It is absurd to suggest that systemd isn't proven and tested in the wild for a long period.
Also note that some systemd code like udev, existed even before the systemd project was announced, so at least part of the systemd code is much older than 5 years (udev was released in 2003).
This won't work at all. One of the most basic requirements of teaching is that your teaching level correspond to those you teach; aim to high and you loose them because they don't understand, aim to low and you loose them because they are bored. Having one "super teacher" yapping one-way lectures from a giant screen without the "teacher" knowing what his pupils can, is simply a lost cause when it comes to engaging and teaching the pupils.
And why the giant screen? Why not having each pupil following an individual course on individual screens instead of forcing everybody to follow the same course. And why the classroom at all if its only function is to supervise discipline among the inmates/pupils.
(Why not just strap the pupils to a chair in their home and force feed them lectures through Occulus rift headsets and noise-cancelling headphones; it is easy to motive the pupils through reinforcement stimuli like tasing them gently if they have wrong answers. This will be very cheap and is guaranteed to produce marvellous results.)
That's because you're ignorant. Try more Linuxes so that you can be exposed to more things.
Well, I know SysVinit (including variations like Slackware uses) and Upstart. Both are pitiful when compared with systemd, especially killing processes and handling PID's. And all the service management tools you can tack on top I know of like Monit and S6 are painfully labour intensive to use and lacks fundamental features. (Monit has pretty graphs though).
Any init-system without integrated resource management like cgroups and easy to use service monitoring and easy to use security frameworks using namespaces and capabilities, are hopelessly nobbled when compared to systemd.
Just the fact that systemd uses structured plain text files for service and daemon configuration is a huge win compared to using script files, that are basically executable config files that mixes code and config options in one unstructured lump that are hard to parse for both humans and machines.
Sadly, that didn't stop them from making their own sophomoric mistakes made by neither, nor useful idiots from defending their incompetence and poor decision-making abilities.
IMHO, most people criticising systemd haven't really bothered up upon its design or why it is designed the way it is, but rely on third party blogs and random forum comments. There really are good technical decisions behinds its design:
Take the logging system; if you want "metal-to-metal" logging, that is from before rootfs is mounted to potentially after it is dismounted, and you want to collate all logging messages, no matter how and when they are generated, you will end up with a design like systemd's "journal".
All other existing Linux logging facilities have logging gaps and are unable to create collated logfiles from the entire boot and shutdown process.
systemd really solves many old Linux problems in one go, not at least the problem with the partially fossilized plumbing system: eg. cron was made with the assumption that computer was always on. This is a problem when most Linux devices these days runs on batteries and frequently are suspended or shut down.
But there is not central cron-developer group, there are only fragmented forks of ancient abandonware versions of eg. Vixie-cron, so cron can't be fixed, nor can there ever be a new cron version that fixes any problems that will make it incompatible with cron. cron is simply doomed to permanent fossilisation.
Getting systemd-timers is so nice in that they not only fixes old cron problems, but also makes it possible to change future implementations of it. It is simply great that there is a central developer hub that can take RFE's and patches for this.
I am really not aware of any "sophomoric mistakes" regarding systemd's design; it is small, modular, lean on resources, fast, stable, have lots of great features that are very easy to use.
IMHO nothing else on Linux even come close to all the features systemd have, which is why all major distros have chosen to use it.
Yes. systemd had the advantage of learning from both systems, using what they did right and discarding what they did wrong (xml etc). The systemd developers really did their homework well in this regard.
I am sure that the FreeBSD developers will study systemd intensely before making their own version too.
Which is not the correct behavior for a headless server. The correct behavior is to start anyway and for any user processes that depend on access to the unavailable filesystem to exit with a -1 status and log whatever perror() spits out to standard error, at which point it is clear to the sysadmin what happened and without having the other stuff on the box held up.
Just bumbling along with boot even if critical disks are missing is just dumb. Allowing raid arrays to come online in degraded mode without any spares just because some disk were late in reporting in is stupid and dangerous.
The sysdamin can always mark non-critical disks with "nofail" if he knows the userspace software can handle missing them.
Sure, not everyone agree with JH (yet), and FreeBSD do lack development manpower to make a fast transition away from rc, that is why he described it in a "FreeBSD the next 10 years talk".
My point is that FreeBSD _will_ get a systemd-like init-system, it is only a matter of when.
Of course there will be a lot of discussion, and for political reasons it will be dressed up as not being a systemd clone, and people will moan about learning something new, and there will be lots of drama on the mailing lists whipped up by a small vocal minority.
But like in Linux, the vast majority of actual developers and FreeBSD sponsors will quickly realise the many benefits of doing things the systemd way.
systemd isn't a horrible implementation, it is in fact extremely good in many areas and extremely well coded and documented, which is exactly why FreeBSD will clone that instead of SMF/Launchd or try to invent a new solution.
I am just saying FreeBSD is a system made by sysadmin to sysadmins and not overrun by political bastardos. I sincerely doubt they will go the same route.
The co-founder of FreeBSD have already stated that systemd is a good thing and it is exactly what FreeBSD needs for the future:
https://www.youtube.com/watch?...
There are already *BSD developers working on this, including a systemd compatibility layer. So yes, FreeBSD will have a systemd clone init system, and binary log files too, it is only a matter of time.
What I am saying is that what systemd calls "log database" is no such thing and massively inferior to the real thing.
Please don't confuse the term database with a RDBMS or similar. A database can be a simple text file with structured data like /etc/passwd.
http://en.wikipedia.org/wiki/F...
systemd's journal is by any definition a database file and since it contains logging info, I fail to see the problem in calling it a "log database".
I also _know_ that people that put logs into databases uses real databases, you know the ones that come with ACID.
Some use ACID RDBMS, some use non-ACID NoSQL databases, etc. It all depends on needs and to why they collect the logs in the first place.
What you do _not_ do is change the on-machine logs into a wannabe-database. That is about the worst thing you can do.
You are of course wrong about this, Enterprise log analysers like Splunk uses simple files and indexes to store events etc. pretty much the same way that systemd does.
There is considerably overhead when using ACID RDBMS', so when things needs to be really fast you do stuff like systemd and Splunk does. Logstash (probably one of the more popular log-analysers) doesn't use a ACID compliant RDMBS as backend either (though it can if you want to).
The point is that the world of logging and databases have moved on considerably the last decade. The primary reason being more and more data that needs to be analysed (fast) for one reason or another (Business, real-time security etc.).
systemd's journal is a pretty significant upgrade to the otherwise rather fossilised world of Linux logging. Don't get me wrong, I have tremendous respect for the Rsyslog team, but they have been struggling for over a decade to solve just some of the problems systemd's journal now have solved.
And I have have never really seen any good argumentation against using binary, structured and indexed log files:
They can be read by all standard Linux text tools with piping.
There exist multiple independent readers for them.
The logs can be programmatically accessed through a myriad of languages.
They provide functionality that can't be matched with legacy syslog files.
There is no non-contrived scenario where they can't be read one way or another.
They can be exported in any format and have default export options for all relevant industry standards.
Unlike syslog output, they have a stable and documented API.
So there isn't any real downside to using binary journal log files, while there is considerably advantages.