InitWare VS libnklabs

Fear not. They get to be part of the future too.

> Yes indeed, I should've expanded to requiring user namespaces and other kernel magic I can't expect from any random box i wanna work on.

That's fair, do have to make sure to avoid to modules that do user systemd services.

Longer term, though, I am hoping https://github.com/InitWare/InitWare will help with the userland part. And I hope to personally help with things like

https://lists.freebsd.org/archives/freebsd-arch/2022-January...

https://lore.kernel.org/lkml/f8457e20-c3cc-6e56-96a4-3090d7d...

to get us more sane cross-platform system calls.

I know, but support is still in FreeBSD. My big long term plan is:

1. Work on FreeBSD cross in Nixpkgs, because I need a way to pin forks and run nice tests without going insane. (We already have NetBSD cross.)

2. Rig up a booting image that uses https://github.com/InitWare/InitWare, the fork of systemd.

3. Add support to CloudABI in initware.

4. Bang on drum for other OSes and upstream systemd to implement this stuff we can can good portable abstractions -- I think this is our best shot to get "portable containers".

I haven't bothered to have a beef with systemd, but some of us have discussed https://github.com/InitWare/InitWare to support non-Linux kernels. That would be really fun.

I'm the first to admit that I'm ignorant of the facts here, but seeing that a systemd fork ran on OpenBSD for the first time two months ago does not give me confidence that it's "an option" in the sense that you can trust it to work well.

And to be pedantic (this is an OpenBSD thread, after all), it's not "systemd", it's a fork of systemd called "InitWare", and the GitHub repo describes it as "alpha software".

Someone also pointed out in the discussion you linked that it doesn't seem to include journald. Here's a relevant PR: https://github.com/InitWare/InitWare/pull/27

The project GitHub is found at https://github.com/InitWare/InitWare

You may have heard of InitWare https://github.com/InitWare/InitWare. Discussions, note that one of the titles is misleading:

Two issues with readline: it's GPL and it's big. For embedded systems intended to become products you really need something else. My tiny variant is this, but for sure there are many others:

https://github.com/nklabs/libnklabs

("nkreadline" has editing, tab-completion (for embedded "nkcli" commands) and history)

I used RTEMS on Movius Myriad vision CPU (running on LEON- a SPARC clone).

I remember the RTEMS event concept was not very good- the events are globally shared. You are better off using semaphores.

>I have realized that for a majority of the embedded software using an RTOS is an overkill

I agree with this. Instead of an OS, we like to use a small framework that provides a CLI, database and UART communications (YMODEM protocol). It's a single stack system that provides a simple work-queue for scheduling future tasks / callbacks, and for interrupt code to schedule non-interrupt code. It works for almost everything as long as you are comfortable programming in an event-driven style.

https://github.com/nklabs/libnklabs

(recently added support for AVR 8-bit processors).

I've extracted the Chromium-EC encryption functions, they are convenient for signing / verifying firmware on other platforms. Chromium-ec is nice for example code like this:

https://github.com/jhallen/rsa-verify

On the other hand, if you are looking for some generic embedded system code all in C, here is our library:

https://github.com/nklabs/libnklabs

I think it's most unique feature is the embedded schema-based database- so you can save things like calibration and configuration information in local flash memory. Recently I've been adding device drivers for all common devices I can find on break-out boards for the Arduino and Raspberry-PI communities.