Subject: [alpine-devel] Alpine features and the future

From: Cág <[email-masked]>
Date: Thu, 15 Jun 2017 21:01:32 +0100

Apparently there has been some sort of speculation regarding
replacement of some components of the system with others, and
apparently many moons ago last time, at least on this list.
I would like to know Alpine developers' and users' positions on:

1. BusyBox. Does it need a replacement such as sbase/ubase,
The Heirloom Toolchest, ToyBox or maybe even 9base or Coreutils?

2. GNU software. Should it be replaced by analogues? For example,
make with bmake, bc with heirloom bc, bison with byacc, ncurses
with NetBSD curses.

3. gcc/clang

4. OpenRC. Should Alpine switch to an alternative like runit, s6
or svc? Should /sbin/init be sinit?

5. In case of replacing BusyBox with something that lacks an
editor, what would become the default? nvi, vim, neovim, elvis
traditional vi, nano or vis? Or maybe there will be two like
in OpenBSD or a load as in Slackware?

6. What would be the default shell? mksh, pksh or dash? Or maybe
bash?

Thanks

-- 
caóc

---
Unsubscribe:  [email-masked]
Help:         [email-masked]
---

---

From: William Pitcock <[email-masked]>
Date: Thu, 22 Jun 2017 00:17:26 -0500

Hi,

> apparently many moons ago last time, at least on this list.

In general our goal is to make it possible to have more choice, while
retaining sensible lightweight defaults where it makes sense.  It is
not likely that we will change any default components, but instead
make more components swappable (as you can already do with coreutils,
shadow, etc.)

Beyond that in these cases, we try to be transparent and collect as
much comment as possible when making major changes to the
distribution.

> The Heirloom Toolchest, ToyBox or maybe even 9base or Coreutils?

For the foreseeable future, BusyBox will likely remain the primary
cornerstone of our base userland.  There are many Alpine developers
who contribute patches to BusyBox to add new features, and generally
speaking we have an excellent working relationship with the BusyBox
maintainers.  So, at least, right now there is no major reason to us
to make any changes here.  We are quite happy with the way things are
going, and how efficiently we can make changes in BusyBox when
necessary.  The only reason right now why we would move away from
BusyBox is if that relationship with upstream were to change in a
major way, but that seems unlikely.

> make with bmake, bc with heirloom bc, bison with byacc, ncurses

The primary argument for switching from GNU software has to do with
the licensing.  We're not license purists.  As long as the software
meets our redistribution guidelines, the license does not matter so
much.  GPLv3 is obviously compliant with our guidelines.

In cases where the GNU software has a higher quality alternative
(byacc vs bison, GNU vs BSD ncurses), we are tending towards using the
option that we feel has the highest code quality, as higher code
quality usually means less security bugs.

> 3. gcc/clang

We already support both GCC and Clang.  There are plans to make the
default system compiler selectable in Alpine 3.7, and we may switch to
Clang in the future to leverage it's Control Flow Integrity features.
This again comes down to what makes operational sense for the
distribution.

> or svc? Should /sbin/init be sinit?

Most likely we are going to switch to using OpenRC's own init in the
future.  In general, while OpenRC is not perfect, it does fit what we
feel is the proper Alpine workflow, while the DJB style tools do not.
If we were to adopt a DJB-style init system such as runit or s6, we
would provide a compatibility layer on top to make it function
similarly to OpenRC.

> in OpenBSD or a load as in Slackware?

As previously mentioned, we are not likely to switch away from BusyBox
for core userspace.  Any replacement of BusyBox would supply an
editor.

> 6. What would be the default shell? mksh, pksh or dash? Or maybe

As we have no plans to switch away from BusyBox, I can't say I have
given it much thought.  However, BusyBox ash is basically in the same
family of shells as dash, and our shell scripts assume that /bin/sh is
an ash derivative.  So, most likely, we would use dash.

William

---

---

From: Jens Staal <[email-masked]>
Date: Thu, 22 Jun 2017 12:36:41 +0200

> This again comes down to what makes operational sense for the

Personally, I think the most compelling thing with clang as system
compiler is the use of libc++ as standard c++ library rather than the
gcc libstdc++.

---

---

From: "Tmp File" <[email-masked]>
Date: Thu, 22 Jun 2017 13:45:11 +0200

When writing a script a few days ago I noticed BusyBox doesn't have 'paste' which is a pretty standard unix command.
I wonder what else I'll find missing in the future...

My suggestions is to create a toybox-complement. It would install only the commands *not* present on busybox.
Zero intersection.

What do you think?

---

---

From: William Pitcock <[email-masked]>
Date: Thu, 22 Jun 2017 14:18:41 -0500

Hello,

> I wonder what else I'll find missing in the future...

If you need something added to BusyBox, just send us a patch for it.
Most likely we will be OK with adding it.

> My suggestions is to create a toybox-complement. It would install only the commands *not* present on busybox.

That's interesting, but is there actually anything in toybox that
busybox does not also have?

William

---

---

From: Cág <[email-masked]>
Date: Thu, 22 Jun 2017 20:17:34 +0100

> make more components swappable (as you can already do with coreutils,

Having options is nice, while now there are 303 packages that depend on
BusyBox. Ideally there would be zero since people who would run
"apk -i del busybox" probably know what they are doing. It also would
be nice to have some kind of warning if they don't.

> We are quite happy with the way things are
 
My problem with BusyBox is UTF-8. Somewhere it works, somewhere it doesn't
and it's hard to keep an eye on all of the components since there is a
load of them. TODO for Unicode hasn't been updated for seven years now...

> much.  GPLv3 is obviously compliant with our guidelines.
 
Some consider GNU software bloat[0] and think that it sucks[1],
it pisses others off ("I'd like to interject for a moment...").

I personally don't care about licences (GPL is bureaucratic though).

[0]: http://agunix.org/fqa
[1]: http://suckless.org/sucks/

-- 
caóc

---

---

From: "A. Wilcox" <[email-masked]>
Date: Thu, 22 Jun 2017 19:34:33 -0500

On 22/06/17 14:17, Cág wrote:
> William Pitcock wrote:
> 
>> In general our goal is to make it possible to have more choice, 
>> while retaining sensible lightweight defaults where it makes 
>> sense.  It is not likely that we will change any default 
>> components, but instead make more components swappable (as you 
>> can already do with coreutils, shadow, etc.)
> 
> Having options is nice, while now there are 303 packages that 
> depend on BusyBox. Ideally there would be zero since people who 
> would run "apk -i del busybox" probably know what they are doing. 
> It also would be nice to have some kind of warning if they don't.

I am working on a way to make /bin/sh changeable between BusyBox,
dash, bash, and possibly others. If I can manage to do this
successfully, then we would probably change Adélie's copy of abuild.
It would require packages containing shell scripts to depend on some
sort of shell provider, instead of just blindly adding BusyBox as a
dependency.

I'm not entirely clear how we are going to do this yet, but if there
is interest in integrating this work in to Alpine, perhaps we can have
a more full discussion here.

Best to all,
- --arw

- -- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org

---

---

From: Drew DeVault <[email-masked]>
Date: Mon, 4 Dec 2017 15:30:39 -0500

Sorry for chiming in late on this thread - I have some thoughts and I'd
like to spin the discussion back up.

For context, I had a project to build a Linux distro called agunix, but
I made some early compromises that spun the project into a distro that
wasn't aligned with my initial goals. I recently spun it down and
decided to contribute to Alpine instead. Alpine is the closest to my
design goals among established distros.

>The Heirloom Toolchest, ToyBox or maybe even 9base or Coreutils? 

In agunix I was shipping busybox+ubase and it worked very well. I think
busybox's mouth is bigger than its stomach; I prefer to use a busybox
where most of the tools are trimmed out and it basically just implements
POSIX utilities. ubase is suckless.org's project (unportable base) to
implement typical Linux userspace tools like mount(8) and login(8) -
basically most of the non-portable tools in man section 8. They're
pretty minimal and the code is quite straightforward.

https://git.suckless.org/ubase/

suckless has also been working on sbase, which implements most of the
utilities specified by POSIX. There's a status page here detailing the
degree of their completion:

https://git.suckless.org/sbase/tree/README

Personally, I would recommend a minimal busybox build plus ubase without
a second thought, and I would recommend cautiously but earnestly
considering sbase+ubase.

I would also recommend just porting shadow over using busybox user
management tooling. I think `useradd` et al has a more Unix design than
`adduser` et al. Thankfully the shadow codebase hasn't yet been
corrupted beyond saving by the broader Linux ecosystem's influence.

>make with bmake, bc with heirloom bc, bison with byacc, ncurses 

I dislike GNU software because the code is complex and full of
unnecessary and fragile features. Most GNU software is rather bloated,
too.

>3. gcc/clang 

I dislike them both but there's no good alternatives.

>or svc? Should /sbin/init be sinit? 

I had experience with runit on agunix, and I really liked it. To me it
seemed really close to the ideal init system design. The main problem
with it was the codebase, which is pretty awful. I would love to see a
new init project with a similar design and better code, maybe with some
more porcelain service management commands too (the agunix port shipped
with a patch to let you do `sv enable nginx` instead of manually adding
symlinks).

>in OpenBSD or a load as in Slackware? 

I'd just do a minimal (static?) vim build and forget about it.

>6. What would be the default shell? mksh, pksh or dash? Or maybe 

dash

I'd like to start sending some patches to realize this. I have a tracker
for things I want to work on for Alpine:

https://todo.sr.ht/~sircmpwn/alpine

I'm going to start with non-controversial changes like adding doas,
ubase, and shadow to aports while we discuess the harder points.

--
Drew DeVault

---

---

From: Shiz <[email-masked]>
Date: Tue, 5 Dec 2017 00:00:09 +0100

> On 4 Dec 2017, at 21:30, Drew DeVault <[email-masked]> wrote:
> 

When I played around with sbase around half a year ago, it seemed rather
immature to be frank. I fear a lot, especially in our old build system,
would break with it.

> corrupted beyond saving by the broader Linux ecosystem's influence.

Definitely agree with this. I am also of the opinion that `useradd` and
friends seem more commonly used, and it’s a shame to have to recommend
using the shadow package for everyone that wants to either use it
themselves or have tooling using it.

> with a patch to let you do `sv enable nginx` instead of manually adding

s6 with a porcelain layer still seems very interesting in that aspect
to me.

> ubase, and shadow to aports while we discuess the harder points.

Any particular reason you prefer dash over ash? I’m curious. :-)

- Shiz

---

From: "A. Wilcox" <[email-masked]>
Date: Mon, 4 Dec 2017 17:45:33 -0600

On 04/12/17 17:00, Shiz wrote:
>> On 4 Dec 2017, at 21:30, Drew DeVault <[email-masked]>
>> wrote: I would also recommend just porting shadow over using
>> busybox user management tooling. I think `useradd` et al has a
>> more Unix design than `adduser` et al. Thankfully the shadow
>> codebase hasn't yet been corrupted beyond saving by the broader
>> Linux ecosystem's influence.
> 
> Definitely agree with this. I am also of the opinion that `useradd`
> and friends seem more commonly used, and it’s a shame to have to
> recommend using the shadow package for everyone that wants to
> either use it themselves or have tooling using it.

The amount of things that are broken by not having `useradd` is
insane.  We ship shadow in base in Adélie anyway, so this isn't too
big of an issue, but what is an issue is that Alpine build scripts
still think `adduser` and `addgroup` are the way to go.  Our builders
don't have busybox so I had to write clumsy shell shims to 'translate'
them.

I can send them to the list if anyone would be interested; normally I
would put a link, but our Git server ENOSPC'd and I'm still trying to
clean up the pieces before bringing the web interface back online.

I could also write wrappers the other way around if Alpine is really
tied to using `adduser` and `addgroup` so that build scripts can use
`useradd` and `groupadd` without a dependency on shadow.

BTW, is there a reason Alpine doesn't ship shadow as a base dep?  Does
Alpine really recommend use of tcb, or is it some other system?  I've
never been able to figure this out and in fact this is why I gave up
trying to deploy Alpine at my last employer.  We used LDAP and I
couldn't for the life of me make Alpine login(1) use it.

> s6 with a porcelain layer still seems very interesting

+1.

Best,
- --arw

- -- 
A. Wilcox (awilfox)

---

---

From: Jakub Jirutka <[email-masked]>
Date: Tue, 05 Dec 2017 03:41:10 +0100

> The amount of things that are broken by not having `useradd` is
insane.

Maybe on Adélie, I've never encountered any issue on Alpine from not having useradd...

> Alpine build scripts
still think `adduser` and `addgroup` are the way to go.

Hm, we really should add a declarative way for creating users/groups in abuilds. Not (just) because of Adélie, the current approach has more problems.

> I could also write wrappers the other way around...

I was thinking about this several times, but always something more important appeared. I also don't like some behaviour of adduser.

> BTW, is there a reason Alpine doesn't ship shadow as a base dep?

Alpine's philosophy is small, simple and secure. shadow is not very small and it depends on PAM which is everything but small and simple. Moreover, it's mostly not really needed and useful. I surely don't wanna this in *base* system.

Jakub

(I'm sending this mail from mobile, so please forgive me typos etc.)

On 5 December 2017 00:45:33 CET, "A. Wilcox" <[email-masked]> wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA256
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v2
>
>iQIcBAEBCAAGBQJaJd4ZAAoJEMspy1GSK50Uk9EP/2MJEp2JqObs8oTuI5Ehu6/6
>VN6e62vIVDgm6EM78/4dEOd7PgDygfcVaEa+LflczP6sgU5rZXpX5mDn5wxb2XaB
>iEsJ/esj306UkFIwnph8VU2z8+FdQ8SwcVD3IF++xKAbDHFCayYqt76nt44aNtjt
>9/2FaLha9apU/4Vbl8u5+9l57wvxkyLTNlt2IrPWiB6KOyp2Jl450clE1VYYfjlQ
>YroEab9klPToft4izScqPhlHc+AiqaiOwxNdKF2ekY3+bOVi73nZHejgibYtE0kj
>tJWnb7M1HlSaPOKQ3XIc+cA/QWGNYWkfg8AwtaWnwSz30LpbV8FOKoRf0AoU4FsU
>gTV8GQHKSLKbQgObZGVq9bpgsin8dWRcFbfij5P+sNZLg84nCfsCYH1TBjo+Y37d
>gLGFrfHBCHWH5qs039lHa9x6U5tlMcBndvkAwd0FSlQDZaNLHDG3x3Jyq0o7BbTD
>yGYj1CtW4udF7V9PxnV9r3PIvBu9OmPC/nNXf+3Mf/i4GOCGdS8IqE5FhFbmbtYG
>BOz+g+Z95V3ZWaE4K6B4nqOMLWjM+UyJNJkfKaUz0ppDFKWU+IFDbtwbnYwCCElW
>KRz/CY/MnOKi0CYEML7ouij4+SOMwjwv0qNAAS4/Xbqf1dt4JnAP/8gPUS3xSike
>GfD+idvKvp24NbAzjbmP
>=GK//
>-----END PGP SIGNATURE-----
>
>
>---

---

---

From: Shiz <[email-masked]>
Date: Tue, 5 Dec 2017 04:44:54 +0100

> On 5 Dec 2017, at 03:41, Jakub Jirutka <[email-masked]> wrote:
> 
> Maybe on Adélie, I've never encountered any issue on Alpine from not having useradd…

I see plenty of issues arising every day, just from questions on IRC and elsewhere.
> 
>> Alpine build scripts still think `adduser` and `addgroup` are the way to go.
> 
> Hm, we really should add a declarative way for creating users/groups in abuilds. Not
> (just) because of Adélie, the current approach has more problems.

+1 here.

- Shiz

---

From: "A. Wilcox" <[email-masked]>
Date: Thu, 15 Jun 2017 18:27:35 -0500

> apparently many moons ago last time, at least on this list.

- From IRC lately it seems like not much will change, but the goal is to
give users (and other spins) choice.  As the leader of a spin (Adélie,
a desktop distro based on Alpine), I personally like that goal, but I
may be slightly biased :)

> I would like to know Alpine developers' and users' positions on:

Since you ask for users positions as well I will answer the way I
feel.  I am not an Alpine developer, but I am working on my own spin,
so I am a developer of that spin.

> 1. BusyBox. Does it need a replacement such as sbase/ubase, The
> Heirloom Toolchest, ToyBox or maybe even 9base or Coreutils?

BusyBox is meh.  It's fine for recovery environments, and to have a
static binary to call in if you break /lib or something (which just
recently happened to me - a bad shell backtick caused me to set
permission 644 on /lib/ld-musl-x86_64.so.1).  I don't think it is
appropriate for user interaction.  It is missing a lot of options that
I use regularly (particularly in things like mv and grep).  We ship
coreutils right now in Adélie because that's the most usable of the
lot, but I have contributed some code to toybox.

Heirloom is a useful project, especially for things like mailx, but
the Toolchest they have is only barely POSIX and tries to make the
compromise between BSD and GNU extensions by implementing neither.
Again, I'm not sure this is appropriate for user interaction.

I haven't tried out sbase yet.  That is on my radar.

> make with bmake, bc with heirloom bc, bison with byacc, ncurses 

GNU make is used by way too many packages to be replaced with bmake.
If you mean the Alpine tools themselves, abuild's Makefile looks to me
like it is POSIX make and should be usable by any make implementation
available (very possibly even nmake, but that would be silly).  No
real opinion on the others, but we at Adélie do ship mawk instead of
gawk since it is much lighter while still having much more
functionality than BusyBox awk.

> 3. gcc/clang

Using Clang as a system compiler was my mission when I worked in the
Gentoo project, and we made some progress there before I left.  I've
continued that project in my spare time on my own computers (my main
desktop is a weird hybrid of gentoo, a gentoo fork, and LFS, with most
packages compiled by Clang).  There are still a few packages that
require GCC, mostly kernel-based packages like Xen and systemtap.  I
think in general Clang would be usable as a system compiler if it
could be overridden in certain packages with GCC.  Note too that
Clang's support for some architectures is not mature (or even extant)
so it can't be used everywhere.  Of course that makes more maintainer
burden since now you need to maintain Clang and GCC.  But LLVM is
already a thing in Alpine so it isn't much more maintainer burden than
already exists.

> 4. OpenRC. Should Alpine switch to an alternative like runit, s6 or
> svc? Should /sbin/init be sinit?

I think it would be good to have choice.  Some people like OpenRC, and
some people like s6.  Why not let user decide what is best for their
use case?

> traditional vi, nano or vis? Or maybe there will be two like in
> OpenBSD or a load as in Slackware?

nvi is probably the lightest one that can still be used.  elvis is
sadly no longer maintained (was my editor of choice for over a
decade), traditional vi is going to confuse people, and neovim seems
to not be stable yet (but I haven't looked in a while, just going by
what I hear).

> 6. What would be the default shell? mksh, pksh or dash? Or maybe 

All the developers I have talked to in Alpine have told me that
BusyBox ash (which is basically dash) is the One True /bin/sh for
Alpine.  I can't imagine that changing.

Best,
- --arw

- -- 
A. Wilcox (awilfox)

---

---

From: Shiz <[email-masked]>
Date: Fri, 16 Jun 2017 01:46:16 +0200

> On 15 Jun 2017, at 22:01, Cág <[email-masked]> wrote:
> 

While I may be an Alpine developer by some measures, I’d like to
emphasise that the following opinions are mine alone and don’t
necessarily represent Alpine as a project. ;-)

> The Heirloom Toolchest, ToyBox or maybe even 9base or Coreutils?

In my view, busybox is mostly fine and I see no immediate reason to
replace it by anything else, especially considering its relative
completeness when compared to e.g. toy box and sbase. I would be
very much against shipping coreutils by default.

> make with bmake, bc with heirloom bc, bison with byacc, ncurses

Similarly, as someone who actually had to package bmake, I don’t
see it replacing GNU make any time soon, especially considering its
own bugs and quirks. I have no immediate qualms about packaging or
shipping by default GNU software in general, just that which is of
low quality, which I don’t perceive e.g. GNU make to be, at least
immediately.

> 3. gcc/clang

This is a more interesting question to me as I’ve been working on this
for a bit. I see avenues for replacing the system compiler and/or
toolchain with LLVM and elftoolchain-based alternatives, especially
considering the development effort big corporations like Google and
Apple are putting into LLVM, also with regards to hardening like
UBsan and CFI. So for me, this is actually an avenue I’m actively
exploring and see potential in, yes.

> or svc? Should /sbin/init be sinit?

Personally, I like OpenRC and see no immediate need to replace
busybox init with another init. Since busybox is already in our
base system, if our case is to keep the base system small, busybox
init should and does suffice generally well.

Replacing OpenRC with something more architecturally competent like
s6 would be a nice end-goal yes, but my main current issue with s6
is still its end-user usability. It, like many others in its style,
has a severe issue with djb-isms that I don’t see either me or our
end-users quickly adapting to. As discussed before on FOSDEM, if we
we were to replace our current init system by anything else, at the
very least support or automated conversion for our current init
scripts, as well as an end-user compatible set of command line tools
equivalent to the current rc-service(8)/rc-update(8) would be a
definite requirement.

> in OpenBSD or a load as in Slackware?

As stated before, I don’t see an immediate need to replace busybox
so I have no direct opinion on the matter.

> 6. What would be the default shell? mksh, pksh or dash? Or maybe

Personally, I’d prefer a light POSIX-compatible shell (as is in the
spirit of Alpine) to be the default, meaning bash, zsh and posh as I
understand it are immediately disqualified. As I have no problems
with busybox I see no direct reason to replace its ash implementation
with anything else, but if it were to be I’d probably pick mksh, or
maybe even posh.

- Shiz

---

From: Alan Pillay <[email-masked]>
Date: Thu, 15 Jun 2017 21:57:46 -0300

In light of this discussion I remember all participants about the last
thread about (e)udev/mdev replacement.

https://lists.alpinelinux.org/alpine-devel/4955.html
https://lists.alpinelinux.org/alpine-devel/4959.html
https://lists.alpinelinux.org/alpine-devel/4958.html
https://lists.alpinelinux.org/alpine-devel/4957.html

---

---

From: Natanael Copa <[email-masked]>
Date: Fri, 16 Jun 2017 10:16:43 +0200

On Thu, 15 Jun 2017 21:01:32 +0100

> apparently many moons ago last time, at least on this list.

Replacing core components requires a signinficant amount of work. Its
not like we have overflow of resources and look for things to spend our
time on.

So if we replace core components it needs to justify the time spent on
it and the risk of break things for users.

In other words, we don't replaces components just because we can.

> The Heirloom Toolchest, ToyBox or maybe even 9base or Coreutils?

no.

> make with bmake, bc with heirloom bc, bison with byacc, ncurses

replacing GNU make is not a goal, specially if it require us to
refactor Makefiles of 1000+ packages.

we ship both bison and byacc. You are free to use any.

ncurses thoug, I wouldn't mind replace GNU ncurses as I have had some
issues in the past with it. (Headers got wrong so lots of packages got
miscompiled). Before replacing ncurses I want be relatively sure that
it will not break things.

> 3. gcc/clang

Shiz has been working on it and I would not mind replace gcc with clang
as default compiler.

> or svc? Should /sbin/init be sinit?

openrc sort of does the job, but i'm not 100% happy with it. I like the
ideas behind s6 but find it a bit "weird" (due to djb style) and I find
it bigger than I'd like.

> 6. What would be the default shell? mksh, pksh or dash? Or maybe

i don't see any reason to replace busybox.

-nc

---

---

From: Alba Pompeo <[email-masked]>
Date: Fri, 16 Jun 2017 09:22:16 -0300

Regarding netbsd-curses instead of, sabotage-linux seems to have been
successful with that.
According to them only "a small percentage of apps written for ncurses
poke at internals and need light patching".
And the benefits are huge.
https://github.com/sabotage-linux/netbsd-curses

---

---

From: Jens Staal <[email-masked]>
Date: Fri, 16 Jun 2017 14:49:46 +0200

> > Shiz has been working on it and I would not mind replace gcc with clang

The most interesting thing with the gcc-->clang switch (to me) is the
switch from libstdc++ to libc++.

I made an experimental gentoo stage 4 (including a llvmlinux-patched
kernel) to play around with it, and a gcc-free base system seems to be
completely possible (on x86_64 at least).

---

---

From: Natanael Copa <[email-masked]>
Date: Fri, 16 Jun 2017 16:05:45 +0200

On Fri, 16 Jun 2017 09:22:16 -0300

> https://github.com/sabotage-linux/netbsd-curses

The size benefits are appealing.

-nc

---

---

From: Cág <[email-masked]>
Date: Fri, 16 Jun 2017 20:19:12 +0100

Thanks for the answers.

I'm asking because I have been fine with sbase/ubase, smdev, sdhcp for
quite some time. I like svc; my /bin/sh is a link to /bin/mksh. I've
yet to compile netbsd-curses on Alpine, but I played with it on NetBSD.

I will support any change as long as it fits the scope, or no changes
at all.

Cheers

-- 
caóc

---