-----BEGIN PGP SIGNED MESSAGE-----
On 15/06/17 15: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.
- 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.
> 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.
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
> 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
> 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?
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.
A. Wilcox (awilfox)
Project Lead, Adélie Linux
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
-----END PGP SIGNATURE-----
Received on Thu Jun 15 2017 - 18:27:35 UTC