Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Alpine Linux is reducing dependencies on Busybox

gitlab.alpinelinux.org

Post reply on HN
Print view View original

41–50 of 87 posts

Re: Alpine Linux is reducing dependencies on Busybox

#41

Post by andy_ppp »

wpietri wrote: post #36
g051051 wrote: post #7

That's not what I read in the link: > 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…

I like this part: > 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. That's a lesson I see learned over and over. Something like, "Group by meaning, not mechanism."

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?

Re: Alpine Linux is reducing dependencies on Busybox

#42

Post by jhugo »

notacoward wrote: post #35
R0b0t1 wrote: post #34

Earlier quoted context omitted.

It is possible to make useless tests.

Does that seem like a strong argument to you? Of course it's possible to make useless tests. It's possible to be injured by an airbag. It's possible to overdose on a drug that usually saves lives. That doesn't mean any of these things aren't generally beneficial, or that they should be foregone. As I said recently on Twitter, I've measured the likely cost of production bugs that were fixed early by static analysis, b…

I think it's a big assumption that the ROI of tests in general is in the same ballpark as the ROI of static analysis.

In my experience, many tests written in commercial software engineering have ~zero or even negative ROI. This mostly applies to micro-level testing like unit tests; macro-level testing like integration tests can be fantastically valuable and I've even come to believe that they're the only type of tests most teams should spend time writing.

Re: Alpine Linux is reducing dependencies on Busybox

#43

Post by silon42 »

rahen wrote: post #4

For the trivia, this is pushed by Laurent Bercot (skarnet), creator of s6, execline and many others. He's also working on implementing s6 as Alpine init and rc systems. https://skarnet.org/software/s6/ https://skarnet.com/projects/service-manager.html

How about alpine-systemd?

Re: Alpine Linux is reducing dependencies on Busybox

#44

Post by onefuncman »

LAC-Tech wrote: post #31
ryan-duve wrote: post #24

Earlier quoted context omitted.

I've only had to use `apk` for a Dockerfile layer when we were really trying to minimize the footprint of an image. From what I could tell, there was no discernible difference from `yum` or `apt`. What are the features that make it stand out to you?

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.

My golden rule of sys admin is if you can't fix it, you reformat and replace it.

If you reproduce the error, congrats, now you get to figure out where to file the bug report with reproduction steps.

Re: Alpine Linux is reducing dependencies on Busybox

#45

Post by nine_k »

silon42 wrote: post #43
rahen wrote: post #4

For the trivia, this is pushed by Laurent Bercot (skarnet), creator of s6, execline and many others. He's also working on implementing s6 as Alpine init and rc systems. https://skarnet.org/software/s6/ https://skarnet.com/projects/service-manager.html

How about alpine-systemd?

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

Re: Alpine Linux is reducing dependencies on Busybox

#46

Post by tannhaeuser »

nibbleshifter wrote: post #27
yjftsjthsd-h wrote: post #3

> The TSC has discussed this issue at today's meeting and has concluded that there is a general need to begin decoupling hardcoded preferences for BusyBox from the distribution. Neat. I wonder if the general decoupling will make it eventually easy to drop in ex. toybox or one of the rust/golang coreutils implementations. Or, for that matter, to drop in GNU coreutils, since the current way to add those to Alpine strik…

One of the reasons people use alpine is to get away from GNU cruft.

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.

Re: Alpine Linux is reducing dependencies on Busybox

#47

Post by WatchDog »

wpietri wrote: post #36
g051051 wrote: post #7

That's not what I read in the link: > 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…

I like this part: > 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. That's a lesson I see learned over and over. Something like, "Group by meaning, not mechanism."

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.

Re: Alpine Linux is reducing dependencies on Busybox

#48

Post by nisa »

wpietri wrote: post #37
rahen wrote: post #4

For the trivia, this is pushed by Laurent Bercot (skarnet), creator of s6, execline and many others. He's also working on implementing s6 as Alpine init and rc systems. https://skarnet.org/software/s6/ https://skarnet.com/projects/service-manager.html

Oh, interesting! Anybody used s6? I like the theory, but for me what matters is mainly the practice.

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

Re: Alpine Linux is reducing dependencies on Busybox

#49

Post by josteink »

nine_k wrote: post #45
silon42 wrote: post #43

Earlier quoted context omitted.

How about alpine-systemd?

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

To make sure that once services are up and running, they keep running and are restarted automatically? To have good, centralized logging? To manage in-container services the same way you do on the container host?

There's plenty of good reasons for one to want to do so.

Re: Alpine Linux is reducing dependencies on Busybox

#50

Post by spockz »

josteink wrote: post #49
nine_k wrote: post #45

Earlier quoted context omitted.

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

To make sure that once services are up and running, they keep running and are restarted automatically? To have good, centralized logging? To manage in-container services the same way you do on the container host? There's plenty of good reasons for one to want to do so.

I think it is counter to best practices to run multiple services in a single container. Although maybe you just need to with some proprietary software.
Post reply on HN