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...
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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!
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.
EDIT: Appears to be a component of a larger "Prismriver" project, but still completely tentative.