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.
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...
How much longer can non-systemd hold out (with gnome/kde swallowing it ...)? how long until it is wrapped in that behemoth that is PID1.
It isn't the UNIX way... its the windows way with svchost.exe & binary logs... and we all know how well that works.
Not only that but Systemd has shown to be hostile to that which it has assimilated...
https://lkml.org/lkml/2015/4/15/104
> To make this clear, we expect that systemd and kernels are updated in
> lockstep. We explicitly do not support really old kernels with really
> (which means 3.4 right now), but even that should be taken with a grain
> of salt, as we already made clear that soon after kdbus is merged into
> the kernel we'll probably make a hard requirement on it from the systemd
> side.
Thats plenty clear, isnt it? As soond as kdbus is merged into kernel,
systemd will depend on it, and then if I need to go back to older kernel,
I have to downgrade systemd as well?
http://utcc.utoronto.ca/~cks/space/blog/linux/SystemdAndSyslog
Anyone who works with systemd soon comes to realize that systemd just doesn't like syslog very much. In fact systemd is so unhappy with syslog that it invented its own logging mechanism (in the form of journald). This is not news. What people who don't have to look deeply into the situation often don't realize is that systemd's dislike is sufficiently deep that systemd just doesn't interact very well with syslog.
I won't say that bugs and glitches 'abound', because I've only run into two issues so far (although both issues are relatively severe). One was that systemd mis-filed kernel messages under the syslog 'user' facility instead of the 'kernel' one; this bug made it past testing and into RHEL 7 / CentOS 7. The other is that sometimes on boot, randomly, systemd will barf up a significant chunk of old journal messages (sometimes very old) and re-send them to syslog. If you don't scroll back far enough while watching syslog logs, this can lead you to believe that something really bad and weird has happened.
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.
What bugs me about systemd is not the idea behind systemd. It's the implementation. Using cgroups and other kernel-provided features, it's able to provide functionality that we don't have elsewhere. But rather than break-down that functionality and make each part replaceable, and use "old" methods to do some things while they are replaced with "new" methods.
It's the all-or-nothing nature of systemd that I hate. There's no reason it can't be done in some other way. There's no reason that, even at a base level, you can't write scripts that do the same as it does - for all functions, but also for parts of the functions. As such, it's not modular, not changeable, it's just a lump of code that you accept having complete control of your machine or not. And I don't.
Honestly, I'm waiting for the crash-and-burn moment at which someone steps up, gives us the same features, using predictable, modular code or even scripts, and we can put in the bits we like and leave out the bits we don't like and replace any bit and NOBODY will know or care that we've done that.
I know, it's almost like you'd want a distro to have different versions to suit server vs desktop usage.
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.
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.
Since you resorted to an ad hominem argument, I'll follow this up. The initiator of systemd is Lennart Poettering, who was also responsible for the pulseaudio and avahi projects. I discovered pulseaudio when Ubuntu implemented it ~7 years ago, and my audio randomly started breaking. A release or two later (6+ months) it was fixed, and audio worked the same as it had before, except that I've noticed pulseaudio occasionally using a few percent of my CPU. Avahi is apparently a service that allows me to make printers connected to my computer available to other computers on the network, which I've never used - but I've still noticed it occasionally at the top of "top" in CPU usage. I'm using a laptop: when a process advertising non-existent printers is sometimes the number one drain on my battery, that's a problem.
So the head programmer of systemd has previously been responsible for projects that did nothing of any benefit to me, caused occasional instability and breakage, and consumed resources unnecessarily. That doesn't tell me that he's a "top notch, seasoned Linux programmer". It tells me that he's a poor architect, probably an indifferent programmer - but very, very good at politicking to get projects incorporated into distros when they shouldn't be. Why should I think that systemd is any different?
"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."
Yes, and most of that existing industry will have to rewrite everything from scratch without file format compatibility.
Also, systemd doesn't magically structure log files. It only structures the least interesting parts. What most syslog processing do is parse the log data itself, which is highly application specific, and which is completely opaque to systemd just as it is to syslog.
"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."
Really? Here's the microsecond monotonic timestamp on my current box: 242841.31760194. That's 15 bytes. A 64-bit binary timestamp is 16 bytes. The text version is shorter! And given that the vast majority of usages do not require microsecond resolution (which isn't even really accurate, anyhow), the text approach would lead to substantially _smaller_ files.
I'm neither pro- or anti-systemd. On the one hand, I've actually looked at the systemd code. It's actually very well-written AFAICT. I'm not saying I agree with the way it's structured or how they keep re-writing subsystems (e.g. event loop library, ntp service, etc), but all things considered it's an overall improvement in code quality for the myriad things it replaces. OTOH, systemd doesn't provide anything that I've ever cared about. Process and log management is the least of my concerns. Plus, I have to worry about portability, so the marginal conveniences systemd provides are of little benefit to me.
But from what I can tell, most pro-systemd proponents aren't actually developers of system-level components. They tend to work on high-level applications--e.g. web applications. These people have an exaggerated perspective of the apparent benefit of systemd. The exception to this observation are desktop component integrators and developers. Systemd's process management is much more important in those cases.
By comparison, the anti-systemd people do have much more legitimate complaints about increases in complexity for their scenarios. Particularly wrt journald. But I tend to think these issues are also slightly exaggerated. And, anyhow, at the end of the day open source has one abiding rule--he who writes the code writes the rules. The systemd people have written a better system. It's not as useful as people make it out to be, but it is more useful as a general matter. So stop complaining and get to writing the alternative if it really matters that much to you.
BTW, Linux will soon get process descriptor support. From my perspective of implementing low-level network daemons and services this is far and away the more elegant building block for re-imagining process management in Unix compared to cgroups.