Precedence: list
MIME-Version: 1.0
In-Reply-To: <B94B29B1-CA84-4E47-9F36-E6C8AF4E11F4@shiz.me>
References: <20170615200132.GA24181@alpine> <B94B29B1-CA84-4E47-9F36-E6C8AF4E11F4@shiz.me>
From: Alan Pillay <alanppillay4@gmail.com>
Date: Thu, 15 Jun 2017 21:57:46 -0300
Message-ID: <CAO6-m01mzcjXvNR277Lekke0AweGNifnsCFKHLZKse5uHfZ3+g@mail.gmail.com>
Subject: Re: [alpine-devel] Alpine features and the future
To: AlpineLinux ML <alpine-devel@lists.alpinelinux.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

In light of this discussion I remember all participants about the last
thread about (e)udev/mdev replacement.

https://lists.alpinelinux.org/alpine-devel/4955.html
https://lists.alpinelinux.org/alpine-devel/4959.html
https://lists.alpinelinux.org/alpine-devel/4958.html
https://lists.alpinelinux.org/alpine-devel/4957.html




On Thu, Jun 15, 2017 at 8:46 PM, Shiz <hi@shiz.me> wrote:
>
>> On 15 Jun 2017, at 22:01, 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.
>> I would like to know Alpine developers' and users' positions on:
>
> While I may be an Alpine developer by some measures, I=E2=80=99d like to
> emphasise that the following opinions are mine alone and don=E2=80=99t
> 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=E2=80=99t
> 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=E2=80=99t perceive e.g. GNU make to be, at least
> immediately.
>
>> 3. gcc/clang
>
> This is a more interesting question to me as I=E2=80=99ve 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=E2=80=99m 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=E2=80=99t see either me or ou=
r
> 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=E2=80=99t see an immediate need to replace busybo=
x
> 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=E2=80=99d prefer a light POSIX-compatible shell (as is in t=
he
> 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=E2=80=99d probably pick mksh, =
or
> maybe even posh.
>
>>
>> Thanks
>>
>> --
>> ca=C3=B3c
>
> - Shiz
>


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---