Date: Mon, 4 Dec 2017 15:30:39 -0500
From: Drew DeVault <ddevault@vistarmedia.com>
To: =?iso-8859-1?B?Q+Fn?= <ca6c@bitmessage.ch>
Cc: alpine-devel@lists.alpinelinux.org
Subject: Re: [alpine-devel] Alpine features and the future
Message-ID: <20171204203039.GA18601@miku>
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170615200132.GA24181@alpine>
User-Agent: Mutt/1.9.1 (2017-09-22)

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.

>1. BusyBox. Does it need a replacement such as sbase/ubase, 
>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.

>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. 

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.

>4. OpenRC. Should Alpine switch to an alternative like runit, s6 
>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).

>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? 

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 
>bash? 

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


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---