Re: [dev] oasis: small linux system inspired by stali

From: Michael Forney <mforney_AT_mforney.org>
Date: Tue, 28 Mar 2017 00:00:22 -0700

On Mon, Mar 27, 2017 at 2:44 PM, Marc André Tanner <mat_AT_brain-dump.org> wrote:
> Hi Michael,
>
> Overall I like your package selection, but I also have a few questions:
>
> * Did you consider using netbsd-curses[1] instead of ncurses?
>
> This probably won't work as is, because libtermkey as required by
> vis depends on the ncurses terminfo library. It might be worth
> investigating how much work it would be to either port libtermkey
> or provide the necessary terminfo symbols in netbsd-curses.

I have not. I actually was originally very hesitant to include any
curses library at all, since it seems to me like the wrong layer to
implement a graphical UI (instead going the route of acme + 9term).

If you find a way to use netbsd-curses (or maybe no curses at all; I
saw you added a vt100 UI to vis), I'd be interested.

> * What is the justification for using ninja (I'm not really familiar
> with it). It seems like the only (non-toolchain) package requiring
> C++. Furthermore, you mentioned that you might write a compatible
> C replacement at some point, hence it must obviously be better than
> other existing alternatives.

I am actually quite happy with how the rc/ninja based build system
worked out. In my experience, ninja is quite good as a low level build
tool. The language itself is extremely simple, and the tool handles
projects with several thousand build actions with ease (since it was
designed for chromium). This makes it really easy to hack on some
package a bit, and build incrementally. Since dependencies (including
C header dependencies) are tracked across the entire system, relinking
due to a static library change is easy and automatic, and everything
is always up to date.

I think it might have been possible to use some other build tool to
achieve something similar, but I don't think it would have worked out
as well.

> * Did you try how much of the system can be built using a C only
> toolchain like cparser+libfirm?

I did try cparser/libfirm at one point in the project's infancy and I
was surprised at the amount of stuff that built no problem. I have
since added more packages though, so can't give you a recent answer. I
also spent a week or so a while ago fixing some bugs in scc to try to
get it to build sbase. I think it would be really cool to be able to
build the core system (or more!) with a lighter toolchain.

> * Why did you settle for perp instead of s6[2]? Again I'm not really
> familiar with either of them (besides reading their respective
> websites etc.). Just curious, it would be interesting to get your
> reasoning behind the package selection process.

I tried both a couple of years ago, and liked perp more. It seemed
simpler and smaller in scope than s6. s6 has its own scripting
language and quite a lot of extra tools. Although, I have to admit,
one contributing factor is that the s6 tool names are just a pain to
type.

Though s6 is definitely more actively maintained and more popular, so
I may take another look at some point. I would not object if someone
wanted to package it as an alternative.

> * Will you consider using BearSSL in the future, once it gets a bit
> more mature?

Of course, although there are a number of packages that depend on the
OpenSSL/LibreSSL API (curl, wpa_supplicant, msmtp, netsurf, openssh,
python, transmission), so it might involve a lot of porting effort.

> Thanks for your work!

Thanks for taking a look!
Received on Tue Mar 28 2017 - 09:00:22 CEST