I wonder if this will impact Debian's current debate [1] on init systems. A minimal systemd-compatible init system seems like a real contender here, and this project shows that there're both interest and capability for developing one.
From the README: "For now that is just out of interest how far I could come with this and what would be needed to get a somewhat working system. It is very much a proof of concept."
It's also only two months old. So I would say this a toy project. Of course, that it is a toy project right now does not preclude it becoming a real, robust init system in the future (just look at where the Linux kernel started, after all) but I do not think it is currently relevant to the Debian debate.
Tangential question: is rust usable for core parts of distributions like Debian that can run on a million architectures and even on different kernels? I hope to see more C code replaced by rust, but that seems difficult if portability to extremely niche systems is a requirement.
The main issue with systemd is UX. The config files needs too many knobs for simple run-forever-in-background use cases and half of the time you get weird permission issues related to sudo. Documentation feels half baked and requires digging through manpages. A pm2-style init in Rust would be a lot better.
If main.py crashes ~5 times within ~10 seconds, then it'll get put in a failed state until you manually recover it with `reset-failed`. systemd will be happy to restart it often enough that it hits that threshold, because you told it to. So just `Restart=always` isn't enough; you need to set `StartLimitBurst` too (and `StartLimitIntervalSec` if you want to fine-tune it).
I always thought systemd would be a messy pioneering attempt that would be redesigned later on. Because dependency based parallel boot is a good thing.
* The entire line is more a riff on "It's the Journey That Counts"[1].
* The name systemd is recast as an eponym for all init processes. This is only poetically significant, but essential to interpret the remainder correctly.
* The reference to "real" is obliquely evoking real mode as a proxy term for all boot-time activity (to this day, all x86 CPUs start in real mode, notwithstanding that by the time init is spawned we are most definitely not supposed to be in real mode anymore, Toto)
* Outwith the kernel there remains no more quintessentially Unix process than PID 1. You can take my shell, my text utilities, even make, uucp, and cpio, but you'll pry the general concept of an init from my cold dead fingers
* The traditional language of Unix systems programming is C.
* Rust certainly is one of the few potential successors to C as a systems programming language.
* The ordinal successor to C is D; deliberately playing on the d in systemd as though it stood for something more than the mundane "daemon", because it does: the name is itself a punning reference to a French term, "Système D", meaning, roughly, "one's ability and need to be resourceful in an adverse situation".
* Ergo, both mechanically and allegorically: to truly prove its worth, there must exist a generally usable init written in Rust.
* The hidden reference to real mode now evokes an even loftier goal, viz. writing the entire kernel, bootloader, and BIOS in Rust
* A common form of the meme was/is: "The real treasure is the friends we made along the way". The implication by distinction being most certainly that systemd is a false treasure, and that the systemd project is not a friendly one (a sentiment some may find controversial, but hardly without evidence).
So the statement
The real systemd is the programming language we made along the way
is therefore a meditation on the past and present of Unix boot-time initialisation, but particularly embedding the suggestions that the greatest long-term value of systemd (both as a program and a project) is ultimately as a stepping stone, a collection of teachable moments regarding both implementation and community engagement, and that if Rust wants to be taken seriously as a systems programming language then a viable init process written in Rust certainly seems like a good idea.
Accusations that this is all tantamount to intentional RESF upvote sniping are perfectly cromulent.
What features would a "slimmed down version of systemd" provide that isn't available in various independent tools we used to use (and still use today).
* Running/waking a program from network activity? inetd (xinetd) has been doing that since the '70s.
* journald? Logging tools - including multiple types of syslog daemons - are numerous; use whatever you want. Choice is good. Even journald could be an option some people might prefer If it wasn't monolithically tied to systemd and could be used as a stand-alone daemon.
* cgroups? Other managers exist.
* timedated? Managing the clock was never difficult. The standard solution is to delegate most/all clock management to ntpd. If you had especially unusual needs, you probably had to set it up manually anyway (probably with a tiny amount of sh script).
* udevd? Other hardware managers exist. Some of us prefer the peace-of-mind of a simple static configuration instead of a manager, but you should be able to use udevd if you prefer it; udevd used to work stand-alone, but Lennart added it to the systemd monolith[1] when they were trying to push kdbus into the kernel. -sigh-
* daemon/process management? daemontools, runnit, s6, etc.
* logind? This attempts to create the concept of a "session" as a privilege boundary that is orthogonal to the actual privilege boundary in UNIX: the UID. The entire concept is a terrible security problem waiting to happen. The entire concept of a session is especially stupid considering most people don't actually use the traditional multiuser features of UNIX or this new "session" concept. In the rare situation where someone actually is running an actual multiseat setup, an extra step to install an optional package with these features wouldn't be a burden. The rest of just need a simple login/password prompt that can launch gnome/kde/.xinitrc/whatever at login time, which already existed as {x,g,sd,lx}dm.
If there are features that were only provided by systemd, is a monolithic[1] daemon really the best solution? Or could those feature simply be encapsulated into a small stand-alone package that could work wherever it is needed?
edit:
[1] Any objections trying to claim systemd isn't a tightly coupled, monolithic design will be ignored. If you think the number of binary program files is in any way useful as an objection, see: https://news.ycombinator.com/item?id=19024256
Systemd's real value proposition is its tight coupling. As you pointed out, there were several logging systems, several daemon programs, several hardware managers, a combinatorial smorgasbord of options available.
This means you can't assume almost anything about the distro or setup you're targeting as an application developer. Should I log to /var/log or use journald? Can I bundle a .service file or should I have shell scripts? Can I rely on udev rules or do I need to touch /dev? You can't assume unless you're only targeting Ubuntu.
Systemd is so integrated that programs require minimal porting. The alternative is either supporting everything, which leads to massive bloat, or forcing downstream patches to make the damn thing compile and run. Having a non-modular set of services you can rely on means even small alternative distros like NixOS can support many packages, because those packages require minimal changes.
Consistency across environments is critical. it's why docker is so big - all the wiring lives in one place, and what's inside runs everywhere.
But reducing choices to get consistency and consensus strips away the freedom that Linux offered - you can't uproot and replace components as easily. You can have that freedom or you can have a hassle-free package ecosystem; it's an inherent trade-off.
For resource quotas? Cgroups is a kernel interface. What kind of manager do you have in mind?
> daemon/process management? daemontools, runnit, s6, etc.
None of them can deal with runaway daemons. Some of them can deal with ordering and pre/post conditions and instancing, but not as extensively. Each provides a different subset of systemd's init features.
> Running/waking a program from network activity? inetd (xinetd) has been doing that since the '70s.
Inetd works in entirely different way. Those approaches are not comparable at all. (Systemd can hand off the whole listening socket)
All of the tools you mentioned have different syntaxes. With sd I onlt have to keep a single syntax - ini files - which is incredibly more efficient than ten years ago when I had to memorize a dozen different things to make my system run. I'd rather slit my wrists than write another init script in bash / dash, even for the simplest service.
Mo, they don't. They are merely a prerequisite. It must be reasonably possible to reimplement the module in question and it must be possible to instantiate that alternative implementation instead of the original one.
A counter-example is to have all lodules linked into a single static binary. You may have a beautiful separation berween modules in there, but the static linking makes them an immutable bundle.
Cool project, congrats to the author for getting a system tool so far in Rust. Just a couple of years ago that seemed questionably difficult but here we are.
I do have to ask though, does this serve any improvement over or fix any of the shortcomings of systemd aside from being written in Rust?
The title here is a little questionable: this project is not an attempt to be a full replacement for systemd, but more a minimalist init system compatible with systemd.
I much more like the title chosen by the author when he posted it on reddit earlier: “Rustysd: A systemd-compatible service manager written in rust”.[1]
It's fascinating how much the rust community dedicate work to reinvent the wheel.
Don't get me wrong, it's not always a bad thing, but I believe there are still a load of interesting types of software that almost doesn't exist, and such efforts would have better ROI on those new kinds of software e.g an hypergraph database or an NLP library that allows for any inflected word to get another inflection (e.g I give in parameters input="be", kind=verb, time=present, person= 3rd plural) and it output "are".
The ROI on improving widely used tools is quite large
Yes indeed.
You probably wanted to say:
The ROI on reinventing widely used tools is quite large"
There are some extremely used binaries that have a stagnant development and have not adapted to modern ergonomics.
I beautiful example of that subset of widely used tools is cat.
Cat is extremely used and yet, the rust rewrite bat is far superior, because among other things, it has color and code higlithing :0
For a rust rewrite to be successful you need the following conditions:
You have ideas of improvments not present in the current tool.
Your ideas are not on their roadmap.
The current tool has not had too much of man/hours, which you can interpret heuristically as: the current tool has less than a few thousands of commits.
Here we're talking about systemd which has 42,600 commits.
By the time rustysd will have as much features as current* systemd, the original developer will be dead.
As an end user I have almost zero benefits in this kind of rewrites, as I'm aware it's a far poorer software by design.
If it was 1) a new kind of software or 2) a reimplementation of a tool that they can realistically manage to outcompete or 3) the development that will in the very longterm replace an old complex tool that has stopped development, then I would have been interested.
Anyway if it's for fun/learning purpose, they do what they want, but utilitaristically there would be better choices.
> For a rust rewrite to be successful you need the following conditions: You have ideas of improvments not present in the current tool. Your ideas are not on their roadmap. The current tool has not had too much of man/hours, which you can interpret heuristically as: the current tool has less than a few thousands of commits.
I think you are missing the point completely. We are talking about rust, memory safe performant language, and systemd, core system in many Linux distributions, written in C++. I would love to be able to replace systemd (and kernel and core libraries too) with something that was safer at least in this aspect (memory safety).
Big kudos to Mozilla for identifying the cause of many security bugs and for finding a way to solve it while keeping performance intact.
Many will hate me for that, but preferring old-C over C++ for a system software after 2011 is a non-sense. Even the maintainers of GCC understood that.
Memory bugs are only one kind of bugs.
Even if stability where our only metric, systemd had more testing and bugfixing than a rust alternative would ever have.
Thus even if the rust one would be free of most memory bugs, the testing made on systemd would outweigh by far this advantage.
And Rust is only setting out to do a subset of what C++ can do. Did you have a point?
In particular, C++ has been engineered from the beginning to create expressive, powerful libraries, much moreso than Rust. The gap today is bigger than it was five years ago. This matters because every use of an idiomatic, powerful, mature library replaces code not using it that would have had bugs. Yes, Rust programs do have bugs.
Powerful is important in libraries because it translates to actually usable where you need it, without compromise. Any library you can't or don't use does you and your users no good.
Code that uses a good library will have none of the problematic, buggy constructs that Rust is supposed to protect you from.
> In particular, C++ has been engineered from the beginning to create expressive, powerful libraries, much moreso than Rust.
I really can't fault Rust developers for choosing to put aside the whole C++ ABI mess by refraining from developing their own "Stable ABI" and sticking to the lowest common denominator of C FFI for the time being. And perceived ABI issues are the only thing that might stop you from building "expressive, powerful libraries" in the language. (Const generics and specialization are often-requested features that do impact this area, but they're in the pipeline already, and coming soon.)
> "perceived ABI issues are the only thing that might stop you from building 'expressive, powerful libraries' in the language."
This statement makes no sense. What stops you from building expressive, powerful libraries in Rust is the absolute lack of the corresponding features in the language that are necessary to the task.
The edit window expired, but if you want us to edit your comment for you, you'd be welcome to email the text you want to hn@ycombinator.com.
If you say that you mean it sincerely as a question and not as a swipe, I believe you. The problem is that lines like that are routinely used to take cheap shots at others, imply that they don't have a point, and so on. If that wasn't your intention, the burden is on you to disambiguate that by making clear that you're asking sincerely and making your question more specific.
By "aggressive", you mean explaining the point in detail?
Rust and C++ have different emphases. C++ has a huge head start, but also massive backward-compatibility anchors. It is certain that, over time, Rust will get better at expressing powerful libraries, but C++ is not sitting still.
It is very far from clear whether Rust will be important, ten years from now. It is far from clear that it is more beneficial to put resources into rewriting C things from scratch in Rust than to transition existing development from C to C++, and start replacing subsystems in-place.
What is clear is that the difference in benefit to starting any new project in Rust or in C++ is absolutely overwhelmed by the absolute benefit of starting in one of those, and not C.
> By "aggressive", you mean explaining the point in detail?
No, I mean the stuff dang has already commented on.
You also did not explain the point in detail, you responded to what I said with a whole bunch of off-topic things, and then insinuated that I did not have the point.
The parent said that C++ would have "memory safety mechanisms similar to Rust," and my point was that while they are similar in some ways, they are not as comprehensive. That's an important distinction!
All of this other stuff you're talking about has nothing to do with that.
What I see is special pleading. C++ inherits flaws from C, Rust has flaws from its late start and weaker emphasis on expressibility, both sets of flaws interfere with reliable use.
The launching order of the internal daemons is not explicit on the services graph. For a long while I had a computer that mounted the disks on a non-predictable time and most attempts to fsck the root partition would fail.
For a while it would ignore the system DNS settings, so it didn't only require it to be configured twice, but the systemd settings had an habit of changing in format every so often.
Udev failed a bit at the time it was being included on the package.
Oh, there was the time when the simple service launcher didn't conform to the documentation so a lot of daemons could fail to launch in unpredictable ways.
But the first I started using it was at the Debian migration. So the earlier bugs were all solved already.
I get your sentiment, but creating a minimalist, but compatible alternative to systemd in a safe language is anything but reinventing the wheel. There's a real concern with systemd's feature creep, it's defaults, security and a development culture. rustysd may be a proof of concept, but it addresses real issues.
> For now that is just out of interest how far I could come with this and what would be needed to get a somewhat working system. It is very much a proof of concept.
It sounds to me like this was more of a project that was just for fun and not really meant to be a genuine attempt at producing an alternative to systemd.
Yes, but you need to be an expert in NLP to write that NLP library. People in their free time write software that sits at the intersection of interesting and able.
On the one hand yes there's tons to explore, so many promising futures.
But I would like to keep an open mind about works like this one. This is work that could beget all kinds of neat things! Systemd targets Linux, where as this is a bit higher level & might be portable to other environments. It allows other people to not have to create their own process management systems, not have to create their own init system. The recreation brings the availability of the giant's shoulder to many many more places, distributes it's promise to really new & interesting targets.
It's pretty likely that the people writing an init system in Rust are not just gonna casually decide to write an advanced NLP library instead, since it requires a fairly distinct set of interests and skills.
Technology advances by the continued reinvention of the wheel. As much as I dislike Rust the language, these activities of the Rust community are spot on.
I like Rust as much as the next guy, but currently Rust (and Go for that matter) binaries are comparatively enormous (compared to C or C++, i.e. compared to systemd).
For comparison: ripgrep (Rust) is >2 MB stripped, GNU grep is <200k stripped.
I have not looked at systemd in a while, but I'd be surprised it systemd in total is not smaller than the Rust runtime, which would leave your minimal subset larger than the original.
So maybe you meant something other than code size here, but using words like "minimal" and "subset" feel a bit (unintentionally, probably) misleading to me.
I'm sure the Rust people will at some point find a way to reduce the footprint of the runtime. Currently they have other, more pressing goals.
Personally, I wrote my own init system. The PID 1 process is a 10k statically linked binary. Resident memory size is 24k on one of my AMD64 Linux production servers. That is what I think could rightfully be called a minimal subset.
> I like Rust as much as the next guy, but currently Rust (and Go for that matter) binaries are comparatively enormous (compared to C or C++, i.e. compared to systemd).
> I have not looked at systemd in a while, but I'd be surprised it systemd in total is not smaller than the Rust runtime, which would leave your minimal subset larger than the original.
Isn't this simply a result of the C runtime not being bundled with the executable? How does the comparison look when accounting for that difference?
Depends obviously but in general small, busybox is statically linked that uses a relatively large swath of libc and you can compare different libc versions somewhat by looking at the tags here: https://hub.docker.com/_/busybox?tab=tags. If parent was correct you could link all of musl libc and have 1.3MB or so left over for an actual application.
It also depends on the how the code is structured, musl for example is structured not to pull in unneeded objects while the size of the glibc docker container speaks for itself.
C does type erasure, doesn't do runtime checking and maps most everything to assembly. I haven't checked recently but last time I did Rust's bare metal binaries were larger than C ones. Might be better now.
That said you can beat C's code size with hand assembly and p-code interpreters.
So maybe you meant something other than code size here, but using words like "minimal" and "subset" feel a bit (unintentionally, probably) misleading to me.
I understood it as as a subset of features. It doesn't seem to me that the author is trying to play code golf with their codebase, or optimize for binary size (and why would you in 2019, storage is cheap)
[1] https://www.debian.org/vote/2019/vote_002#textf