Alpine Linux is reducing dependencies on Busybox (opens in new tab)

It's one of the many system factoring challenges. It's difficult to define a hard and fast rule as to which is better. Often some combination of the two is ideal, particularly as the system grows.

Is this so that you don’t end up creating the wrong abstraction when inevitably over time the meaning changes and you end up special casing the implementation?

Debatable. I view it as a restatement of the goal to package scripts by service, instead of having a grab bag package for scripts, and one tied to a specific impl at that.

> More generally, and this is more a matter of opinion and totally debatable, I would like functionality to be progressively stripped from busybox-initscripts, which is a package that gathers a bunch of miscellaneous policy scripts that are only related by the fact that their mechanism is provided by busybox. I don't think this package makes sense from a semantics point of view; it is more logical to provide the policy scripts classified by service, no matter whether or not the implementation of the service is done by busybox. To me, ideally, busybox-initscripts would be empty, and we'd have virtual packages for every service that is currently defined in it, so support for alternative implementations can be added over time.

Used s6-overlay[1] to start a lot daemons in a docker-image for demo purposes - postgres, tomcat, mysql, php-fpm, apache (don't ask why ;) - s6 worked really well and was reliable and stable - I enjoyed it very much. It was also possible to reliable pass SIGTERM to the daemons in the image for clean shutdown and it was easily possible to configure logging to stdout with a prefix. Modelling dependencies (waiting on database before starting app etc.pp) is possible via shell-scripts. It's super flexible but out of the box it's more like a collection of powerful tools not a complete package - but that's good. It's in the tradition of djb daemontools and is very unix - as in doesn't talk a lot and you better know how each part works but - and that's really cool - it's modular and simple and once you get a grip on it you can easily reason about it. systemd takes a completely different approach and also solves a kind of differnt problem - this is like small pieces of lego that compose well instead of one big chunk of glib/dbus/glibc only c-code.

1: https://github.com/just-containers/s6-overlay

We do - and have found it very reliable and I really like it :-)

One of the members of our team finds it more complex when it comes to diagnosing why things aren't running/starting as expected, but that's also down to the complexity we have around s6 with other setup scripts (we use it to manage the full suite of processes in our product).

Hence, they're not the biggest fan of it (and would talk negatively about it), but I _think_ s6 isn't really the culprit and instead the other complexity is.

Although, when things go wrong it can be a little bit harder to chase down than it was with our former manual "start this process" type scripts... But, you can just `./run` the run script which may tell you enough :-)

linuxserver.io uses s6-overlay for all their images, which are very popular in the self-hosting community.

Based on my reading of [1] and [2] it sounds a bit more nuanced than "just incorporate s6 into alpine".

[1]: https://ariadne.space/2021/03/25/lets-build-a-new-service-ma...

[2]: https://skarnet.com/projects/service-manager.html

Can you elaborate on why this is relationship-ending for you? https://skarnet.org/software/s6/why.html makes it seem like a reasonable direction.

It will only be an option, you can keep sysvinit + openrc if you prefer it this way.

what's the objection?

Why would Alpine need systemd? Why would you need it in a container?

It saddens me too, but it still seems necessary. In my (quite long and varied) experience, most developers do not appreciate the value of regression tests. Therefore, reminders and positive reinforcement are still beneficial.

While I agree that it should be a standard feature, it is worth pointing out that operating systems tend to be more difficult and more expensive to run full tests for.

Heh. I'm writing a custom tool for a security product that pulls configs down and looks for deviations from expected config values.

Instead of running the script against the client config and validating it works correctly, I thought to myself "Hey, what if I made a sample configuration with known good and bad values, and have a known result output to quickly validate the script's function?"

I just invented testing. No, large scale programming and devops is not my primary job. Yes, I have built validation before, but it isn't habit and this is a bespoke project so I didn't think about it at first.

You can already install coreutils and udev over busybox, without busybox being removed.

The simplicity of Alpine and the lack of systemd is what drew me to it. I have converted all my routers, firewalls, VM's and home appliances to Alpine. I do not have a single regret.

Sure, I like having a distro that defaults to not using GNU (if nothing else, to flavor the GNU/Linux naming debate), but there's nothing wrong with allowing GNU or others to be used. Further, Alpine already packages GNU tools, so I prefer the most elegant implementation possible.

If that's indeed the case, I think it might be because of the fear of license trouble ie the whole business of Docker images referencing/installing a Debian base as the first thing always had the smell of a GPL circumvention device to me, in part at least. But it seems license holders don't really bother, or we've heard about it by now. And in that context, Alpine already got rid of the OS and glib, leaving only the rest of the userland GPLish. OTOH busybox is GPL, too, and actually known for going after violators, so what do I know.

The packaging format and system is very different to yum and deb, despite the similarities in cli interface for local maintenance. It's quite similar to PKGBUILD in Arch, except with more streamlined tooling.

intuitive CLI, things are packaged a bit better, easy configuration.

I swore off of apt based distros after I accidentally installed some graphical things on my WSL and multiple debian wizards couldn't figure out how to remove them, even when I installed stuff like dpigs and aptitude.