A safe, comprehensible and efficient PID 1/init replacement written in OCaml | Hacker News Reader

A safe, comprehensible and efficient PID 1/init replacement written in OCaml

github.com

131 pointspjmlp45 comments

It's just sinit translated to OCaml. Given that it all boils down to POSIX libc, I'm not sure what the advantage of OCaml is here.

EDIT: Appears to be a component of a larger "Prismriver" project, but still completely tentative.

The name Prismriver reminds me too much of https://en.wikipedia.org/wiki/PRISM_(surveillance_program), and the next thing beginning with 'P' that came to mind was Palladium, the codename for Microsoft's Trusted Computing platform. Neither of those seem particularly desirable to associate your project with, although what this does have in common with them is the safety/security aspect...

Apparently they are named after characters from a game series. http://en.touhouwiki.net/wiki/Prismriver_Sisters

So the letter P is out of bounds now?

P is the 15th letter of the alphabet, 15 is 0xf in hexadecimal, the ascii code of f is 102. 1 + 0 + 2 = 3 omg, Half-Life 3 confirmed!

How tested is this in the field? "Safe" for an init replacement is a strong statement. The git repo statistics make this look young but I don't know what Prismriver is.

I'm not saying this to be a jerk, I'm saying this because, well, "safe" is a high bar for an init replacement! And I'm genuinely interested in the answer.

"Safe" here means memory and type safety.

What does type safety has anything to do with runtime or user of an init program? Or is not the memory safety provided by the OS already? Does OCaml bring anything specific to the table, or could this've been written in Go as well?

Operating systems usually only provide memory safety between processes. The operating system doesn't protect a C program from overflowing its own buffers or making incorrect writes to the heap for example. OCaml's memory safety means many of those types of bugs aren't possible.

What is the motivation for this question? If written in Go, do you ask why not OCaml? Or think OCaml somehow especially unsuitable?

Better type safety is correlated with more correct programs. OCaml has a pretty solid type system which helps with that.

It's just 59 lines of code, 20 of which are merely listing names of signals. I won't say it's safe, but it's certainly easier to audit!

Or it might be possible to generate a proof with a solver[1] of some kind.

[1]: http://www.chargueraud.org/softs/cfml/

For a fun init can use Erlang!:

https://github.com/nerves-project/erlinit

Erlang/Elixir is already structured like modern OS (isolated processes, preemptable, built in tracing, debugging, smp support). So if your project is mostly Erlang skip the regular init and use erlinit right away.

Some example and usage from parent site:

http://nerves-project.org/learn.html

erlinit is not an Erlang init, rather a C program for bootstrapping a minimum GNU/Linux userspace over which Erlang/OTP applications can run on.

How practical is it to run a simplified init program like this instead of systemd for a desktop Linux system?

It feels like as a Linux user one has to make the choice between software freedom (and software ethics) and an easily maintained, attractive desktop experience. As a Fedora user, I'm very used to GNOME and all of the comforts that it provides, but I'd consider switching to Gentoo sans systemd for the sake of making a stand against bad practice in the software community.

Probably easier to just use another operating system like FreeBSD if you don't like the direction the Linux ecosystem is heading. There are some great alternatives out there.

How does systemd violate your freedom? It's LGPL 2.1 and, as far as I know, respects the four freedoms: https://en.wikipedia.org/wiki/The_Free_Software_Definition

If Emacs is an example of cathedral-style development, and Linux is an example of bazaar-style development, then Systemd is turnpike-style development, steamrolling ahead against all objections and the better interests of the communities they bulldoze.

That's not a violation of the LGPL, but it is a betrayal of the community it represents.

> How practical is it

Very? Contrary to the popular meme that suggests that systemd is required for features like automounting hotplugged hardware or roaming network configurations were possible a decade before systemd. Several pre-systemd distros even handled a lot of the work for you automagically, though the UI for some tools wasn't the best (or, rarely, was missing).

> I'm very used to GNOME

That's another matter, unfortunately. GNOME is firmly in the systemd-only, "screw portability"/"it's not a regression when we removing working code because it's 'old'" camp.

That said, Gentoo has implemented a workaround[1]. I haven't tried it (I still use enlightenment DR16), so I don't know if the workaround involves any loss of features, but that might be worth investigating. The install process appears to be a typical level of work for Gentoo.

edit: oops - forgot the URL

[1] https://forums.gentoo.org/viewtopic-t-1022050.html

I use Void Linux at work fulltime for 2 months now and it's very lean and stable, using runit as init. xbps had 99% of the packages I needed.

Looks good. The more alternatives to systemd the better.

This.

I really would like to see at least Debian get to a point where init is actually a swappable component in the real world.

Debian already is at that point. You can chose between sysvinit and systemd. You can also install openrc or upstart, but there’s very few packages which are being tested with these init systems, so expect to run into trouble.

That said, I expect sysvinit to be phased out over time. Debian simply doesn’t have the manpower to find and address bugs with that many combinations.

> Debian already is at that point.

I said "real world", where Debian is clearly not at that point:

> but there’s very few packages which are being tested with these init systems, so expect to run into trouble.

I've not been involved in a while, but I have trouble believing that the limiting factor for adding in testing for a few inits is available work-hours. Maintainers/packagers' time is far more flexible than that.

I would buy that very few enjoy pain, and the discussion of Systemd in Debian was poisonous enough that using one's scarce fungible time revisiting that isn't something many want to do.

also the more basic unix tools written in ocaml the better.

I would very much enjoy seeing a shell written in a safe language. The problem is, just installing such a shell isn't enough - it'd have to be capable of being copied into /bin/sh to actually make a fully safe platform.

Anything named after Touhou is probably better than what Lennart makes.

The doc says it's equivalent to sinit: suckless init. That led to a git site I don't understand cuz I don't know git. I downloaded the zip to see if readme had anything. Here's what it says:

"sinit is a simple init. It was initially based on Rich Felker's minimal init. Why? I wanted to get rid of Busybox init on my toy distro. How? There are 3 signals that sinit will act on.

SIGUSR1: powers off the machine. SIGINT: reboots the machine (or alternatively via ctrl-alt-del). SIGCHLD: reap children"

So, one or more of these could use some better documentation. Or at least more accessible for non-Git users.

EDIT to Add: I like the idea of rewriting key stuff like this in safer, easier-to-maintain languages like Ocaml. Really nice stuff there. Past that, I can't derive the value proposition without a page detailing what it does vs alternatives.

You read the readme, but did you read the code? You may be surprised at just how simple and straightforward it is. I'm not quite sure that this OCaml (or indeed the suckless) init implementation's intrinsic value depends upon the author conducting a survey of existing alternatives.

Read the code.

I knew someone would say that haha. Let's rephrase what you said in a general context to show what the problem is:

"Anytime you're evaluating solutions to a specific problem in your system or code you should look at all the source code people are posting without expecting a description of what it does. Just read all the source code out there, guess if it meets your needs, and then try whichever looks right."

Kind of dumb way to go about finding 3rd party libraries or tools. Similarly foolish to expect it unless one simply doesn't care about adoption at all. The alternative, which my comment promotes, is to have relevant data in a short summary on each projects' page. Google, HN, or whatever finds users/developers a set of pages like this. At a glance, they can tell what's worth further investigation. Then, they look at its code. Much better way to use limited time to find needles in the massive haystack that is the Web.

I wouldn't say you should read all source code out there; but this is just 89 lines of fairly readable C code. Even its man page (the .8 file) is larger!

I noticed that about the man page. That's rare haha.

I get where you're coming from, but the entire tarball contains one source code file and it's a paltry 89 lines in 1317 bytes. Heck, the man page is a whole 70 bytes bigger than the source code. This is very, very different from, say, Django. I'm not advocating for... whatever it is you're claiming w.r.t. needles and haystacks, only a wee bit of situational awareness when you've already gone so far as to download the code.

And Suckless? Yeah, they're basically the definition of "doesn't care about adoption at all".

"Heck, the man page is a whole 70 bytes bigger than the source code. This is very, very different from, say, Django. I'm not advocating for... "

Alright, alright haha. Yeah, I did download the code. It was small and seemed understandable. Seemed as there's no telling what assumptions its built against. I've seen code meant to prevent compiler issues, OS issues, timing channels... all sorts of things you wouldn't know just reading the code itself & might have even scrapped. So, I'm still about code coming with a detailed statement of what it does with what environmental assumptions.

On other hand, this could be so plain that the environment or tools don't matter. Maybe.

"And Suckless? Yeah, they're basically the definition of "doesn't care about adoption at all"."

Their page hints at targeting a demographic of pro's tired of bloated BS. I wasn't sure how much they cared. There's some clarification.

The web interface is cgit; you can see the files by clicking on the "tree" tab.

Ahhhhh. That's very helpful. Will prevent unnecessary downloads. Thank you. :)

There is also a description of what a minimal init should do here: http://ewontfix.com/14/

Thanks. Great start on a requirements document. Also covers many issues.

Forgetting the politics of the site itself, this is a nice list of references to init systems, from simple to complex:

http://without-systemd.org/wiki/index.php/Init

> That led to a git site I don't understand cuz I don't know git

If you're going to be in this industry in 2016, git is one of those things with which it's worth getting at least minimal familiarity.

No doubt. That reminds me: what are the easiest, down-to-earth articles any of you know of on the topic for beginners. Both Git and Github since I clearly will have to learn both.

http://stackoverflow.com/questions/315911/git-for-beginners-...

That looks like a solid start. Thanks.

The Git book is excellent and officially maintained. https://git-scm.com/book/en/v2

It serves as both a great introduction and a reference.

Reply on news.ycombinator.com