If you're right, that's a big sigh of relief from me.
The guy mentions how "Lennart Poettering would love it!" as the h2, and also describes X11 as "legacy".
With these in mind I feared he was serious about the systemd bit.
I'm really sad X11 is legacy software myself, as an aside. It's a disaster, sure, but now we have one more layer of "uhhhh..." for all the UX-types to get scared away by: it used to be "(WinAPI) vs ((Qt)/(GTK+)/(Xlib/XCB))", which was embarrassing enough; now it's "(WinAPI) vs (X11((Qt)/(GTK+)/(Xlib/XCB))/Wayland((Qt)/(GTK+)/(???)))" which is just plain annoying for low-level graphics hacker wannabes - I can make a WinAPI app in C that opens a window in a few KB, where as to do that in Linux now I HAVE to support XCB and also write my own tiny UI for Wayland.
Practically speaking it means that most developers will just pick a side^H^H^H^Htoolkit and go with that. It doesn't help that I've never been able to get past Qt's love of background processes vs. GTK's various displays of autism/spasticness.
sighs...rant over, situation accepted a bit more.
systemd is still a disaster though. I saw a massive 3Wx5H 1080p video wall in a shop window the other day, displaying... systemd emergency mode.
At least I learned that some video stretchers are smart and will drop the panels they're controlling into standby if they display black for too long. (Only the two panels at the top-left displaying the error were on, the others visibly had their backlights off. Neat.)
It hasn't been all roses in the windows world. Aside from qt/gtk being just as desirable there, there was also winforms and WPF in .net that are now left out in the cold and no clear forward direction that would also work on windows 7. They seem to be taking an each way bet on whether Win32 is deprecated or not.
Actually, I think this is the situation that lead to the growth in webapps and probably helped the decline (or failure to rise) of windows phone, no one had a clue where MS was going.
WPF is pretty much alive for desktop applications and its architecture (XAML + Blend tooling) is the foundation of UWP applications.
Windows Forms is officially dead as communicated at Build a few years ago. It is now playing chess with Carbon.
MFC is officially on life support. Way forward for C++ developers is UWP.
Everything from Win32 that isn't required for UWP support is deprecated and Project Centipede is the official way to bring Win32 applications into the new shinning UWP world.
> I'm really sad X11 is legacy software myself, as an aside. It's a disaster, sure, but now we have one more layer of "uhhhh..." for all the UX-types to get scared away by: it used to be "(WinAPI) vs ((Qt)/(GTK+)/(Xlib/XCB))", which was embarrassing enough; now it's "(WinAPI) vs (X11((Qt)/(GTK+)/(Xlib/XCB))/Wayland((Qt)/(GTK+)/(???)))" which is just plain annoying for low-level graphics hacker wannabes - I can make a WinAPI app in C that opens a window in a few KB, where as to do that in Linux now I HAVE to support XCB and also write my own tiny UI for Wayland.
That's worse than this: you will quite possibly need features that are not implemented through Wayland, but through each different Desktop Environment, through different APIs, since Wayland ditched many X11(+standardised extensions) features.
Another commentator noted that X will just become a Wayland client when things even out. I suspect that things won't necessarily work out that cleanly/elegantly, and eventually X11 will installed on fewer and fewer devices.
Whatever we're left with will create quite an interesting ecosystem; here's hoping it's not too much of a political disaster.
For me, that means hoping Qt keeps up at the end of the day; it's been far superior to GTK in every way IMHO for some time.
Bollocks, the equivalent of opening a window using Win32 in Linux world is using X11's xlib (or xcb) API. Equivalent albeit more brain damaged.
Wayland doesn't change this. Once Wayland is adopted the X server will become a Wayland client and X client's will connect to the X server as usual. You don't have to write a native Wayland application if you don't want to.
One could only hope that 10 years from now X has in-fact disappeared. My greater worry is that it's still around and Wayland (with Weston implementation) hasn't yet gained enough traction to become "de-facto" server. To make matters worse there's the Ubuntu's MIR display server, which seems to have gone silent. This could lead to some nasty fragmentation between distros.
I haven't followed this discussion so am unfamiliar with the validity of the details of the comment, so I can't speak to the content. The downvotes may be in part due to the rantish nature of part of it, which you were aware of at the time of posting. Some readers may have thought as you knew its tone was overly heated, you could have taken the time to express it better. However, this is just speculation, based on behavior I've seen on HN.
Ah, I see. Defining one's argument concretely and concisely is the basis of debating effectively, whereas I've just resorted to anecdote and ranting here. Woops.
Thanks very much for that feedback, I'll keep it in mind.
If I had to use one word to describe systemd's integration and adoption into the Linux ecosystem it would have to be "hostile" - the label has unfortunately been applicable in both directions.
Most of the feathers flew around 2012 when the major Linux distributions adopted systemd as their default init system, irreversibly pulling in all of systemd's system management policies as well, many of which were poorly designed.
Several big names in the Linux community (Linus Torvalds and Greg Kroah-Hartman, to name two) have had heated discussions with Lennart Poettering and other people behind systemd about major bugs, design flaws and policy integration issues, with the systemd response consistently being "the way we're doing it is the right way, no patches will be accepted, go away" even when shown multiple times that something contravenes design best practices or tradition (aka principle of least surprise).
For this reason I dislike systemd's highly bureaucratic "manglement" style, and am very sad that all major distributions have adopted it so widely. systemd uses a very dictatorial approach which makes it very very hard to use any other init system without nontrivial and obscure system reconfiguration.
I understand Lennart also built PulseAudio and got it integrated into pretty much all Linux distributions. PA works well now, but if it's having a bad day and I really need sound working in a pinch, I can just kill it and use ALSA/OSS directly.
systemd categorically isn't like that because it's (ostensibly) an init system. However it comes with so many extra "side features" (which an increasing number of things are depending on) that temporarily shoving it out of the way to became impossible very quickly, and before any real documentation was established. I think it's understandable a large amount of the Linux community have growled and snarled when presented with this set of circumstances.
Nowadays, systemd is pretty much part of the woodwork now, but the communication and social issues continue.
I remember the Fedora 7 (?) days when PulseAudio was made default and nothing worked (silence is golden apparently). I routinely removed PulseAudio from my systems and dropped to ALSA.
I observe that systemd has a plethora of other systems that you mention, including a DHCP server. Yes a DHCP server.
I do not understand it.
Edit: Yes I know Fedora 7 was ancient. Just my memories. I think the fact that PA was broken in it got fixed pretty swiftly, from memory. But I was plagued with glitchy audio releases after this - could be my incredibly lame hardware at the time (but worked fine in ALSA).
The problem with systemd's NTP and DHCP and whatnot is that they use their own systemd-specific APIs. Not using the APIs means that you don't talk to those components. And the thing is, if you're on a systemd-based system (which you can generally assume* to be the case now), you can 100% depend on those components absolutely definitely existing, regardless whatever else is(n't) installed.
(* Unless your users are using Slackware (hi there :D), Devuan or something like that.)
So of course things are beginning to depend on those services' APIs.
Which are exposed via D-Bus. ("Desktop"-Bus. On servers. Facepalm, Inc.)
Now, I do understand that when you use systemd-nspawn or LXC or Docker or whatever else you can generally assume that these components will interoperate and that's why they were implemented. That's the theory.
Their DNS "client" implementation was a tour the force of NIH wrongs, including screamers like not implementing security functionality that had been commonplace in other implementations for a decade or more.
Damn it, they have a web server in there for the sole reason of displaying a QR code for the initial log signing key. A signing system that apparently Poettering's brother came up with as a doctorate thesis, with systemd-journald being the only implementation (that i know of).
BTW, these days you find dbus inside the initramfs. Because systemd need it to be present during bootstrap. After systemd-pid1 is up, it will kill the initramfs version and fire up the one from the HDD instead.
There are times i wonder if the Fedora maintainers grit their teeth and play along with Poettering and crew because they have the same paymasters.
> Their DNS "client" implementation was a tour the force of NIH wrongs, including screamers like not implementing security functionality that had been commonplace in other implementations for a decade or more.
:(
> Damn it, they have a web server in there for the sole reason of displaying a QR code for the initial log signing key. A signing system that apparently Poettering's brother came up with as a doctorate thesis, with systemd-journald being the only implementation (that i know of).
Okay, that I didn't know.
Actually let me read that backwards...
> log signing key
What on earth? Is the log encrypted?
> QR code
How are QR codes relevant to encryption?
> web server
Why do I need a WEB SERVER to display a QR code?! Uh... I can get displaying a QR code on the screen, sure. But... I get the impression you mean the QR code is served over a web server?
Oh. For headless boxes. But... why display a QR code, again? Why not just serve the log signing key itself? QR codes aren't encryption (just a good week's worth of reading on error-correction).
> BTW, these days you find dbus inside the initramfs. Because systemd need it to be present during bootstrap. After systemd-pid1 is up, it will kill the initramfs version and fire up the one from the HDD instead.
Mmm. Because all of its APIs are delivered as D-Bus (desktop-bus) services. I totally get that, but... aghhh. Why not even ZeroMQ :(
> There are times i wonder if the Fedora maintainers grit their teeth and play along with Poettering and crew because they have the same paymasters.
Unless things have changed, Linus Torvalds uses Fedora. He's had a lot to say about things.
I would be very very surprised if there wasn't a noteworthy bunch of mental-pitchfork-wielders.
My limited understanding of the whole thing is that journald use a chain of signatures to verify journal integrity.
Meaning that the first key is used to sign a new key that signs the journal entry and the next key that sign yet another key and entry etc etc etc. And that by having the initial key handy one can at any time walk through the journal to verify that it has not been tampered with.
The whole QR thing it there to allow a would be admin to quickly transfer the initial key to their smartphone or similar by scanning the code.
As for Torvalds being a Fedora user, my impression is that his usage needs are fairly modest these days. He spends most days reading emails via gmail, and approve commits to the kernel code housed on the kernel.org servers.
I see, interesting. For what it's worth that's pretty cool. I never even thought of the idea of a verifiable system boot log...
It's almost sad systemd has some good points. Heh.
I vaguely recall a video that noted where Torvalds was at nowadays; he seems to mostly be in administration/management now, as opposed to low-level hacking. Must be an interesting position to be in.
Do you understand why the Linux kernel has a network stack and do encryption algorithms?
Historically, its the difference between Monolithic vs Micro design. The linux kernel is not just a layer between the application and the hardware, it also support a bunch of extra things which the project want to have built in rather than as optional libraries. There is no TCP/IP or AES library, but there is non-supported alternatives to those that are libraries.
If you wonder why systemd has a dhcp implementation, ask why the tcpip stack don't.
That is a very good point, and I'd like to hear the arguments for why such capabilities wouldn't be added into the kernel.
They'd probably go along the lines of saying that there are already millions of lines of code in there and adding these types of features would add to the codebase size and permanent maintenance requirements.
But it would be really cool if all of these kinds of high-level features were available, yeah...
You don't want them in the kernel, that makes them much harder to replace/upgrade/tinker with. If anything you want to go the other way and move the TCP stack out of the kernel and into a normal userspace library.
I read (unfortunately unsure where) that microkernels do have one fundamental issue: having servers do All The Things and then just making a kernel to dispatch calls to those servers horribly falls down if the messaging/dispatch implementation is single-threaded.
And it inevitably always is, since if you're generalizing all system operations onto a single bus, that bus would either need to support some generic form of contextualization hinting or have some kind of theorem-solver-inspired system to determine what requests have no dependencies. I don't suspect Minix incorporates either approach...
The problem I see is the need to put "these are audio frames" in a different queue than "here are filesystem request packets". (Ideally the filesystem queue would itself allow further sharding, since most filesystems are multithreaded now.)
Writing such a generalized queue sounds like a rather fun exercise to me.
That said, if any such implementations are out there or there are any counter-arguments to make to this, I'd love to hear them. I mean, AFAIK Mach is a microkernel, so it's clearly solved some of this.
I think multithreading the messaging/dispatching implementation would add more overhead than it saved. I remember the hurd's core message-passing routine is 26 assembly instructions - there's simply not a lot of computation involved, and in general not enough data for the message-passing to be the bottleneck - when you're transfering bulk data you'd use shared memory or at least DMA or the like (in a sensible microkernel you just do it, in a super-purist microkernel you'd have a server that owned bulk data buffers and your regular processes pass handles around rather than actually owning the data and it's fine too).
If you need a queue with particular properties you write one, as its own userspace process (or system of cooperating processes). The kernel dispatcher isn't assumed to be a fully general messaging system.
> there's simply not a lot of computation involved
Wow, 26 instructions.
Here's my worst-case scenario: you have 8 concurrent threads (a current reality on POWER8), and let's say all of them are engaged in fetching large amounts of data from different servers - let's say disk and TCP I/O are both servers.
I'm genuinely curious how well a 26-instruction-but-singlethreaded message passing system would hold up. (I honestly don't know.)
Worst case scenario, the cache and branch predictor would perpetually resemble tic-tac-toe after an earthquake.
---
I think it would be genuinely interesting to throw some real-world workloads at Minix, Hurd, etc, and see how they hold up.
Now I'm wondering about ways to preprocess gcc's asm output to add runtime high-resolution function timing information that (eg) just writes elapsed clock ticks to a preallocated memory location (within the kernel)... and then a userspace process to periodically read+flush that area...
> Here's my worst-case scenario: you have 8 concurrent threads (a current reality on POWER8), and let's say all of them are engaged in fetching large amounts of data from different servers - let's say disk and TCP I/O are both servers.
Speculating: if you were passing all the data in messages, terribly. But that's not how you'd handle it. You'd use messages as a control channel instead, similar to DMA or SIMD instructions. E.g. if you're downloading a file to disk, the browser asks to write a file, the filesystem server does its thing to arrange to have a file and gets a DMA channel from the disk driver server. The TCP layer likewise does its thing and gets a DMA channel from the network card driver, and either the browser or a dedicated bulk-transfer server connects them up. The bulk data should never even hit the processor, yet alone the message-passing routines.
> I think it would be genuinely interesting to throw some real-world workloads at Minix, Hurd, etc, and see how they hold up.
Do. Also look at QNX which is the big commercial successful microkernel.
> Now I'm wondering about ways to preprocess gcc's asm output to add runtime high-resolution function timing information that (eg) just writes elapsed clock ticks to a preallocated memory location (within the kernel)... and then a userspace process to periodically read+flush that area...
Using messages as a control channel sounds awesome, wow.
One of the targets I've been trying to figure out how to hit is how to make message-passing still work if you're using it in the dumbest way possible, eg using the message transport itself to push eg video frames. I'm slowly reaching the conclusion that while it'll work, it'll just be terrible, like you say.
I mention this because, at the end of the day, most web developers would just blink at you all like "DM-what?" if you suggested this idea to them. These types of techniques are simply not in widespread use sadly.
In my own case, I'm not actually sure myself how you use DMA as a streaming transport. I know that it's a way to write into memory locations, but I don't know how you actually take advantage of it at higher levels - do you use a certain bit as a read-and-flush clock bit? Do you split the DMA banks into chunks and round-robin write into each chunk so that the other side can operate as a "chaser"? I'm not experienced with how this kind of thing is done.
Well, workload-testing microkernel OSes is now on my todo list, buried along with "count to infinity twice" :) (I really will try and get to it one day though, it is genuinely interesting)
> In my own case, I'm not actually sure myself how you use DMA as a streaming transport. I know that it's a way to write into memory locations, but I don't know how you actually take advantage of it at higher levels - do you use a certain bit as a read-and-flush clock bit? Do you split the DMA banks into chunks and round-robin write into each chunk so that the other side can operate as a "chaser"? I'm not experienced with how this kind of thing is done.
I don't know enough to answer this stuff - last message was already second-hand info (or worse). All I can say is, best of luck.
I am of limited knowledge regarding micro-kernels.
As i have come to understand there is one successful such kernel out there, QNX. And that while both the OSX/iOS and Windows NT kernel started out as a micro design, both Apple and Microsoft have been moving things in and out of the kernel proper as they try to balance performance and stability (Most famously with Windows, the graphics sub-system).
QNX is such a mixed story of technical ingenuity and frustration.
The OS was cautiously courting a "shared source" model where you could agree to a fairly permissive (but not categorically pure-open-source) license and get access to quite a few components' source code.
It was anybody's guess what might develop from that, and an intriguing and hopeful time.
And then BlackBerry came along and bought QNX and killed the shared source initiative. Really mad at BB for deciding to do that.
Nowadays QNX is no longer self-hosting - no more of that cool/characteristic Neutrino GUI anymore :(
He's not. Far better to run a tightly configured systemd on an embedded device than thickets of shell scripts. And as he states, it makes modifying device behaviour that much simpler.
