Precedence: list
MIME-Version: 1.0
In-Reply-To: <20170615200132.GA24181@alpine>
References: <20170615200132.GA24181@alpine>
From: William Pitcock <nenolod@dereferenced.org>
Date: Thu, 22 Jun 2017 00:17:26 -0500
Message-ID: <CA+T2pCE4YNyFbkX9WABXwthwX0wRV_6edF-1S7ON3GT4js=Hww@mail.gmail.com>
Subject: Re: [alpine-devel] Alpine features and the future
To: =?UTF-8?B?Q8OhZw==?= <ca6c@bitmessage.ch>
Cc: alpine-dev <alpine-devel@lists.alpinelinux.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Thu, Jun 15, 2017 at 3:01 PM, C=C3=A1g <ca6c@bitmessage.ch> 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.

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.

> 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?

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.

> 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.

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.

> 4. OpenRC. Should Alpine switch to an alternative like runit, s6
> 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.

> 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 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
> bash?

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


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---