Mail archive

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

From: Shiz <>
Date: Fri, 16 Jun 2017 01:46:16 +0200

> On 15 Jun 2017, at 22:01, Cág <> wrote:
> 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:

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. ;-)

> 1. BusyBox. Does it need a replacement such as sbase/ubase,
> 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.

> 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.

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

> 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.

> 4. OpenRC. Should Alpine switch to an alternative like runit, s6
> 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.

> 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?

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
> bash?

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.

> Thanks
> --
> caóc

- Shiz

Received on Fri Jun 16 2017 - 01:46:16 GMT