The shoggoth keep sprouting pseudopods as devs gets bored and think they can reimplement a time tested daemon in a weekend.
"Ph'nglui mglw'nafh Cthulhu Raleigh[1] wgah'nagl fhtagn" ("In his house at Raleigh, dead Cthulhu waits dreaming.")
1. I'm so sorry, but I couldn't keep myself from punning Red-Hat-sponsored systemd with the Cthulu mythos. For the non-Lovecraft fans, the original city is named "R'lyeh"
Specifically, DBus does not use XML for any message passing or data serialization. It uses its custom binary on-wire format.
Also to consume or provide DBus services you do not need to interact with any XML whatsoever (except maybe for Polkit but that’s not DBus).
Except backwards compatibility? Something that any user of a supposedly-universal IPC bus requires out of the gate?
> It uses its custom binary on-wire format.
Even better, as we all know that custom binary on-wire formats have been proven to be more secure than any other option. Especially when written in C and exposed to a processes of all privilege levels.
You can put DBus server behind a proxy that handles that for you. The XML format is very simple and it doesn’t change.
My point was simply that XML use is very limited, not exposed by any high-level APIs and can be easily ignored.
XML is only used for introspection, a debug protocol on top of DBus.
> Even better, as we all know that custom binary on-wire formats have been proven to be more secure than any other option. Especially when written in C and exposed to a processes of all privilege levels.
DBus is a message-passing protocol. You can write it in anything you like.
You could have DBus server that talks Protocol Buffers or JSON if you like, as long as you provide gateway for legacy clients.
Saying "you can change it to whatever you want" is not a helpful thing to say. I understand your point (it's not "baked in" or wahtever) but you're not helping your cause by stating that "oh, we could just change this part of the protocol whenever we want and it would all just work". Because it gives an aura of instability and "we can move fast and break things" in my eyes (even though DBus has been around for a long time).
> DBus is a message-passing protocol. You can write it in anything you like.
The message passing daemon is written in C, and kdbus is a plan to put it inside the kernel (written in C). Just because "you can write it in whatever language you want" doesn't change that it is currently written in C, and I doubt that anyone is going to rewrite it in Rust any time soon.
Again, I understand that DBus is a protocol and an implementation and you can swap out the implementation if you want. But how many implementations currently exist? One. So currently the dangers of having custom binary formats in C is a valid concern even if you might be able to switch to some other implementation in the distant future.
I get your point about the inertia of there being one de facto implementation, but that’s not quite true. For example Glib’s DBus library contains an (almost) fully featured server implementation.
Anyway I’m not all that worried about the parser in particular. For one DBus wire format is well defined and pretty straightforward. This isn’t ASN.1. Actually it’s probably way simpler than modern DNS with EDNS, DNSSEC etc.
You're spot on.
When systemd was started, Rust barely had a working compiler and go had been announced for about one year.
It's not too different from how things are in Common Lisp land, a language (and a land...) that I'm pretty familiar with. It's a great, probably the best language. There are a few success stories, but truth is, in 2017, most large-scale, non-hobby projects are failures.
All have GNU/Linux compilers available.
FreePascal, Oberon, ActiveOberon, are all great (I'm hesitant to say I know Oberon since I haven't written Oberon code in like 15 years), but besides having the same problem as Ada above, the communities maintaining the compilers are small and understandingly fragile. systemd is still going to be here 15 years from now. Oberon -- who knows?
Modula really belongs in a museum :-).
Besides, they'd all need things like D-Bus bindings etc., a working, stable compiler is just the first step.
The fact is that UNIX-like OSes are married with C, unless there is a commercial entity like Apple or Google, pushing out of the way, UNIX FOSS developers will always gravitate around it for system level applications.
It has always been like that, system languages that aren't the platform main language(s), are relegated to 2nd class status and eventually die or strive in a small niche.
Hence why I think UNIX only has a path to safety in the hands of Apple and Google, because I don't see *BSD or Linux developers using anything other than C for system level code.
Like, this stuff was built tens of years ago and that code is crappy too but we have pretty much got rid of the most obvious security issues. Nobody wants to relive history so you can finally implement a broken DNS client.
I believe systemd-resolved, however, is one of those components that is entirely optional, and which nothing explicitly depends on... which makes it weird that Ubuntu chose to use it by default.
we picked "resolved" as that is small and lightweight, already present (part of the systemd package), does not require D-Bus (unlike dnsmasq), supports DNSSEC, provides transparent fallback to contacting the real DNS servers directly (in case anything goes wrong with the local resolver), and avoids the first issue above that /etc/resolv.conf always shows 127.0.0.1.
We don't need DNSSEC because it doesn't solve any existing problems. The validation is done at the application protocol level with TLS, and apps that aren't running TLS need to fix this gap.
So as it turns out DNSCrypt is winning the internet even though the standards bodies blocked it. Additionally, OpenDNS has massive deployment of DNSCrypt users and this is being furthered by Cisco Umbrella. Cisco is adding this capability to iPhones now as announced earlier this week.
tl;dr DNSSEC has always been DOA, but DNSCrypt is just getting started.
The one and only application I knew of that added DNSSEC for DANE removed it because it was worthless (irssi, irc client).
Yet. Wouldn't be the first time some "optional" component became mandatory.
You could use syslog or journald (or both. But journald was optional)
Meanwhile, from the first public document of journald[1], it was always designed as an indispensable component of systemd.
[1] https://docs.google.com/document/pub?id=1IC9yOXj7j6cdLLxWEBA...
Because systemd
A lot of it is legacy, of course. The steering heads of projects have been around for over 30 years in many cases. These are people who dedicate their lives to a cause, and a lot of it is relation to a vision of the perfect OS circa 1990 - albeit, systemd doesn't follow that philosophy, but the participants in the project are cut from the same cloth, with some new blood and ideas mixed in enough to cast aside the unix philosophy but not enough to change course away from C.
And its all free software, after all. The developers of coreutils, Linux, Mesa, GCC, systemd, NetworkManager, Samba, NFS, and so many other services and applications in use by millions all at least started out as a project of passion. They chose C because that is where their passion lay. We are seeing a new age of such passions emerging around Rust, which is great to see. Whether or not Redox or similar projects can develop the momentum to approach the C lineage is something to be seen (and I would add the permissive licensing is not helping their situation) but the spark is definitely there.
Its development tools are spread like wildfire, but in part that is because of their isolation - you only need rustup to bootstrap your own local Rust ecosystem.
Compared to many other recent native languages, the lack of a runtime absolutely helps Rust in adoption.
Back when GNU/Linux was still at 0.x versions, the OS industry was starting to move to C++. Even though Mac OS, OS/2 and Windows APIs and kernel were written in C, everyone was using C++ with PowerPlant, OWL, MFC, CSet++ or languages like Object Pascal.
OS like Symbian and BeOS were even fully written in C++.
But the adoption of GNU/LInux and BSD with the sacred C, meant everyone that wanted to play ball need to use C instead, so the adoption grew and here we are.
* Rewriting a codebase is much harder than it seems
* systemd is pretty big (376,726 LOC according to Open Hub) which makes it even harder to rewrite
* All maintainers and contributors are C programmers
* Distros don't want their codebase to be made up of many different languages* If your project lacks people with the required skill set, then reach out to programmers who got what you need and educate yourself.
* Distro codebases are not just C since forever, they are a mix of all kinds of stuff, in particular but not limited to C, C++, perl, shell, python.
Indeed....I was surprised to discover OCaml used in Citrix XenServer when spelunking the codebase.
> * Rewriting a codebase is much harder than it seems
That ship sailed a long time ago. Distros already contain C/C++/Python/Perl/Shell Script and others. It is meaningless if you added Go/Rust to that mix.
That's about twice as much as the Linux kernel when I started using a Linux distribution, I believe...
However, I noticed Bruce Perens' message on the Devuan list about the idea of providing a libsystemd0 interface that calls non-systemd services to complete the requests that come in to the systemd API:
https://lists.dyne.org/lurker/message/20170618.121634.7c0d5b...
The plumbing for something like that could indeed be written in Rust. :)
edit: typo
The further you go back in time the less relevant the question is. And arguably any projects in the future written in C instead of a safer language really need to justify that choice if they sit on a security boundary.
C will be around for another hundred years or more. But hopefully new software looks beyond C giving that programmers seemingly cannot write and maintain secure software in it.
As Hoare so elegantly described at his Turing award speech, regarding Algol compilers, done in 1981:
"Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."
Algol dialects like ESPOL and its successor NEWP where used for systems programming the Burroughs B5500 in 1961, 10 years before C was born, nowadays still sold by Unisys as ClearPath MCP.
This may or may not apply to things like systemd which live somewhere on the boundary between what would be pure "system" and "application" programs, but it is undeniably true that application program code, such as that of a document editor or a calculator, should be solely concerned with the application side of things, i.e. correctness and efficient implementation of what is otherwise known as "business logic", and security is usually not one of them - contrary to a very common, but mistaken, perception. It is the "system" component of the execution environment that should focus on what it has been designed for in the first place.
Therefore, ideally, it should not matter what programming language is used to write application software - whether it is C, Rust, Prolog, or SQL; it does sound ironic, though, that the most demanding pieces of a system - demanding in terms of reliability and security - are usually written in an "unsafe" language.
Someone would ask this sooner or later, so.. why is this written in C, really?