Re: [alpine-devel] Alpine features and the future
In light of this discussion I remember all participants about the last
thread about (e)udev/mdev replacement.
On Thu, Jun 15, 2017 at 8:46 PM, Shiz <hi_at_shiz.me> wrote:
>> On 15 Jun 2017, at 22:01, Cág <ca6c_at_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.
>> 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
> 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
Received on Thu Jun 15 2017 - 21:57:46 GMT