Alpine Linux is reducing dependencies on Busybox • Hacker News Board

Re: Alpine Linux is reducing dependencies on Busybox

#31

Post by LAC-Tech » Wed, Aug 03, 2022, 11:42 PM UTC

ryan-duve wrote: post #24

LAC-Tech wrote: post #12

I really like alpine linux. I used it as my WSL2 env for years. I run Void Linux on actual hardware these days (better to use photon for games than WSL2 for work), but would probably switch back to alpine if it had more packages and rolling release, as it had the best package manager I had ever used.

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.

Re: Alpine Linux is reducing dependencies on Busybox

#32

Post by stock_toaster » Wed, Aug 03, 2022, 11:46 PM UTC

jart wrote: post #10

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

They're really still going through with that? I didn't expect I'd have to find another distro so soon.

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

Re: Alpine Linux is reducing dependencies on Busybox

#33

Post by jack_pp » Thu, Aug 04, 2022, 1:15 AM UTC

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.

I've been running debian for 8 or 9 years now, on hardware not WSL2 and have no issues with apt. I use debian on my own machine because we use debian on all our cloud VMs and I don't want to learn more than one distro so idk if your WSL2 problems are a great reason to swear debian off

Re: Alpine Linux is reducing dependencies on Busybox

#34

Post by R0b0t1 » Thu, Aug 04, 2022, 1:53 AM UTC

notacoward wrote: post #8

pmarreck wrote: post #6

Earlier quoted context omitted.

> and there's even mention of regression tests I've been doing (mostly) full-coverage unit and integration testing since, oh... 2005? At least in the Ruby on Rails and now Elixir/Phoenix development spaces, it's absolutely de rigeur, and has probably saved me countless hours of debugging and simply not breaking stuff that already worked, or validating that things worked the way I expected them to. The fact that in 20…

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.

It is possible to make useless tests.

Re: Alpine Linux is reducing dependencies on Busybox

#35

Post by notacoward » Thu, Aug 04, 2022, 2:15 AM UTC

R0b0t1 wrote: post #34

notacoward wrote: post #8

Earlier quoted context omitted.

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.

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, by leaving log messages to mark where the bug would have occurred. I know that's not the same as regression tests, but if anything it's even more of a long shot, more of a hard sell to my fellow developers, and even in that case the value was strongly positive. About a half million 2005 dollars in that case, for less than a fifth of that in license costs and my own time. The ROI for regression tests is likely to be in the same ballpark.

The fact that something can be done poorly by lazy people is in no way an argument against trying to do it well, or even semi-competently, by people who take their profession seriously.

Re: Alpine Linux is reducing dependencies on Busybox

#36

Post by wpietri » Thu, Aug 04, 2022, 2:26 AM UTC

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."

Re: Alpine Linux is reducing dependencies on Busybox

#37

Post by wpietri » Thu, Aug 04, 2022, 2:29 AM UTC

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.

Re: Alpine Linux is reducing dependencies on Busybox

#38

Post by cortesoft » Thu, Aug 04, 2022, 2:32 AM UTC

yjftsjthsd-h wrote: post #19

pmarreck wrote: post #6

Earlier quoted context omitted.

> and there's even mention of regression tests I've been doing (mostly) full-coverage unit and integration testing since, oh... 2005? At least in the Ruby on Rails and now Elixir/Phoenix development spaces, it's absolutely de rigeur, and has probably saved me countless hours of debugging and simply not breaking stuff that already worked, or validating that things worked the way I expected them to. The fact that in 20…

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.

Yeah, the scope of things that an operating system needs to be able to do is basically, “all things that can be done on a computer”, so if you are trying to write full regression tests you are never going to hit all the possible combinations.

Re: Alpine Linux is reducing dependencies on Busybox

#39

Post by yjftsjthsd-h » Thu, Aug 04, 2022, 3:01 AM UTC

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.

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.

Re: Alpine Linux is reducing dependencies on Busybox

#40

Post by bruce_one » Thu, Aug 04, 2022, 3:56 AM UTC

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.

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 :-)