1. 16

  2. 5

    “In short, it behaves as sinit does.”

    Why not just use sinit(1) then? I respect the notion to rewrite it in OCaml (as a project), but for PID1 you want as little attack surface as possible and make it as “dumb” as possible. Some people rewrite software to license it under the GPL (which is stupid, as you can relicense MIT/ISC under GPL with no problem), however, given Lyrica is licensed under MIT the reasoning here could be different.

    Is the author available here to explain this in a bit more detail why sinit is “lacking” in some respects? Or was it just a rewrite for the rewrite’s sake?

    1. 10

      Thanks for your comment!

      I am the author; In a sense it is “a rewrite for rewrite’s sake” though it’s also part of a much larger project, a collection of init, service manager and device manager. The decision to use sinit as a source of inspiration was due to the notion that obviously, for PID1, simplicity is key.

      Why OCaml? Down the line it’ll really assist with the development of the service manager in particular as the benefits of a functional language for dependency and requirement handling are numerous, and I think it makes sense to keep them all in the same language. I also feel it helps raise some awareness to OCaml’s suitability as a systems programming language.

      I’m not ruling out adding more features to Lyrica in the future, though I’m currently very happy with where it is at the moment. Should I want to do that, or should anyone else for that matter, OCaml’s memory safety is also an attractive aspect compared to a PID1 written in C.

      1. 4

        Thanks for presenting your points!

        Regarding memory safety: It’s all about how you write your code. C may not have measures to “protect” you from misusing memory, but what’s wrong with perfectly fine code? sinit(1) doesn’t even use the heap explicitly anywhere (maybe the standard library in the background), so in a way it’s more robust than OCaml, whose runtime most probably does use the heap to facilitate the “secure” memory environment.

        So I would personally prefer a PID1 written in C, as the side-effects of code are much much easier to comprehend when the code is written simply enough. And this is definitely the case for sinit(1).

        The grouping of your tools into one package is also a strange decision, given the init(1) program only communicates through signals, so it definitely is decoupled from the rest and could be written in any language.

        1. 3

          but what’s wrong with perfectly fine code

          At this point, the sinit code is probably perfectly safe, but not because one can prove it but because enough people have used it. Establishing C code is “perfectly fine” is a difficult task. I’m guessing @rose is building up a bunch of tools that fit together nicely and the extra safety that something like Ocaml can provide is one less thing to think about.

          1. 1

            Your argument could easily be taken one step further: why not have init written in assembly? Who knows what the C compiler is doing under the hood?!

            1. 2

              Just disable optimizations if you are scared. Then there is very little room for magic to happen.

              1. 2

                I didn’t realize I needed to use a sarcasm tag, as my point was purposefully absurdist.

                1. 2

                  Trust me, there can be cases were even the C compiler can’t be trusted, especially if you work closely with memory and the compiler ends up breaking aliasing rules himself.

                  Now, with PID1 you want maximum stability and won’t really care about optimizations. So you can even assume it to be a sane default to just turn optimizations off. Security always beats speed, and to be honest, what do you want to optimize about sinit? The speed in which it reaps children or handles signals? Nah! :P

      2. 1

        Lyrica is an interesting choice for a name. It’s also the brand name for Pfizer’s pregabaline medicine.

        I do like to see init alternatives. Systemd was never it for me, and the more, the merrier, even if it’s just to - I can’t help myself - weaken systemd’s stronghold.