Hacker News Reader

Comment by _yy | Hacker News Reader

Nice project! Even if you believe that systemd is too complicated, it's a great example on how to build an asynchronous, modern init system. Upstart uses some highly questionable tricks (ptrace!) to track processes across forks whereas systemd uses cgroups.

View on HN

Not only that, it is a nice example of using Go in a role that many would use C for, so it might convince a few to try their hands to safer programming languages.

Next step, bare metal runtime! :)

Is there even any concurrency in this case? Wouldn't e.g. OCaml be a better choice?

What benefit would adding the overhead of learning OCaml be to this project? It's not like a functional or immutable language would add any value here, would it?!

Even at this 3-line stage, the stateful log.SetOutput construct is ugly and error-prone. So I'd say a functional/immutable language would already be adding value, and that would only increase as the amount of code grows. At a minimum an init is going to involve parsing config and something similar to a state machine, both good use cases for functional languages.

Init's job is to start the init scripts and then hang around to foster orphan processes. Ideally, it should not be parsing configs, but should spawn another process to do that sort of work. A good PID 1 is very, very minimal.

This project isn't just a PID1 though, it's a full system. (Well at the moment it's a hello world, but that's the intent)

When C is taken as the baseline, there's a very long list of languages that look better for this sort of program. I don't see a huge reason that init has to be C, or even particularly benefits from it. (Specific init implementations may have the advantage of being battle-tested, but that's a characteristic of the program and time, not implementation language per se.)

Using high-level languages for init systems is a great idea. In fact, we do this for the Guix System Distribution. Our init system is called GNU Shepherd, and it's written in Guile Scheme. It's great because you write services as Scheme code. For example, I have a number of Ruby web servers that I run for development at work that are nearly identical. Since services are first-class Scheme objects, I wrote a simple function that returns a service object for running a Ruby web server, specialized for a given application. For this workflow, I run Shepherd as an unprivileged user and additionally manage all of my user services like gpg-agent, emacs daemon, offlineimap, etc. No crappy external domain specific language to learn; data is code. Highly recommended.

http://www.gnu.org/software/shepherd/

Personally I would use OCaml over Go, as I prefer expressive languages.

However given Oberon's influence on Go, I find positive other devs that like Go, do use it for such purposes.

OCaml already has MirageOS advertising it for system level coding. :)

Edit: Regarding concurrency, even systems programming languages older than C have built in support for concurrency. C and C++ are probably the outsiders in terms of built-in support for concurrency, language or std libs.

If you want to build a system that can survive out-of-memory conditions, you need to implement init so that it doesn't allocate memory at semi-random moments. Both Go and OCaml will fight you on that requirement. (IIRC, Go is designed to allocate memory the moment your stack grows too deep - which is usually a good idea, but not here.)

Of course, very few Unices actually survive out-of-memory - Linux runs an OOM killer by default, OpenBSD tends to crash the kernel, etc. Apparently Solaris does have a good story here. (Of course, you'd have to ensure that the system doesn't spend all its time swapping, regardless.)

Erlang would look be a very interesting choice here, seeing how any Erlang system is basically a miniature OS. It even has an init already.

cgroups are overkill for process tracking, per se. The Linux kernel has the Netlink proc connector for that purpose. Subscribing to cgroupfs entails a much higher cognitive and resource load in having to deal with a hierarchical resource management subsystem altogether.

Upstart is much more readable even though it has various idiosyncrasies.

I get the impression that the primary reason for systemd using cgroups was "security". This in that it provided the means of namespace isolating daemons.

This in turn because if you follow Poetterings project history it starts with him creating Pulseaudio to handle moving between sound devices while in use, then crated Avahi to provide a means of Pulseaudio equipped computers to find each other on a network, and then came Systemd based on what he learned about daemon security while writing Avahi.

Sadly i can't shake the feeling that the security in systemd is all too often leaning towards "security theater".

Reply on news.ycombinator.com