[HN Gopher] Alpine Linux is reducing dependencies on Busybox
___________________________________________________________________
Alpine Linux is reducing dependencies on Busybox
Author : senzilla
Score : 82 points
Date : 2022-08-03 20:11 UTC (2 hours ago)
(HTM) web link (gitlab.alpinelinux.org)
(TXT) w3m dump (gitlab.alpinelinux.org)
| g051051 wrote:
| 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 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. This would also ease the
| path to getting out of busybox, or at least providing alternative
| coreutils/low-level utilities implementations, is there is ever a
| will from Alpine to do so.
|
| So it sounds like they just want to change how the scripts are
| packaged. The only mention of getting away from busybox is at the
| end, which is qualified with "[if] there is ever a will from
| Alpine to do so".
| tremon wrote:
| From Ariadne's update:
|
| > The TSC [..] has concluded that there is a general need to
| begin decoupling hardcoded preferences for BusyBox from the
| distribution.
|
| That's a bit stronger than just "we want to reorganize our
| script packaging". It still isn't explicitly "reducing
| dependencies on Busybox", but removing hardcoded dependencies
| is a prerequiste for the former.
| hinkley wrote:
| > This would also ease the path to getting out of busybox,
|
| Prepare ship for Ludicrous Speed.
|
| Fasten all seatbelts.
|
| Seal all entrances and exits.
|
| Close all shops in the mall.
|
| Cancel the three ring circus.
|
| Secure all animals in the zoo.
| LAC-Tech wrote:
| 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.
| ryan-duve wrote:
| 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?
| yjftsjthsd-h wrote:
| You could always just use edge if you want a rolling release.
| freemint wrote:
| Good.
| rahen wrote:
| 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
| 1vuio0pswjnm7 wrote:
| Further trivia: Going one level up from busybox, the maintainer
| of dash is the creator of runit. Both runit and s6 are
| "inspired by" djb's daemontools. In truth, neither [wc]ould
| have been created if not for daemontools.
| jart wrote:
| They're really still going through with that? I didn't expect
| I'd have to find another distro so soon.
| CharlesW wrote:
| 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.
| rahen wrote:
| It will only be an option, you can keep sysvinit + openrc if
| you prefer it this way.
| dannyobrien wrote:
| what's the objection?
| [deleted]
| gtirloni wrote:
| Do not editorialize submissions.
| yjftsjthsd-h wrote:
| > 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 strikes me as a
| little inelegant in comparison.
| senzilla wrote:
| As far as I understand, this initiative is primarily about
| reducing hardcoded dependencies on Busybox. As such, this is
| indeed what would enable alternative implementations to exist
| cleanly alongside whatever is the default.
|
| Because yeah, trying to change Alpine's init system, mdev, or
| other coreutils is indeed not easy/feasible at the moment.
| 0xbadcafebee wrote:
| Sounds fine to me? The exception being if they try to get _all_
| hardcoded Busybox references out before the next release, just
| because they don 't want to extend it into the next one. It
| doesn't sound like there is any burning need to get it done, it's
| just tech investment.
|
| My issues with Alpine are a lot more UX-focused. Like other
| distros, I have ended up with a hosed Alpine system twice from
| installing something (I have no idea what) only to find later
| that half my networking tools were uninstalled (and no packages
| cached on disk) so I had to find an Ethernet cable, try to figure
| out what was missing, reinstall. I prefer Slackware's model: it's
| too stupid to remove things just because you installed something
| else. And diffing/saving system configs and packages in Alpine is
| pretty unintuitive.
| notacoward wrote:
| This really looks like an example of open source done right.
| Obviously there are some strong opinions, but the person
| suggesting the change was pretty gracious about the pushback they
| got. Since then, stakeholders have had a chance to discuss and
| agree on a way forward. Nobody is trying to sweep all the "nasty
| bits" under the rug, like most developers tend to, and there's
| even mention of regression tests. I've seen few other projects
| (including but not limited to those where I was a maintainer)
| handle possibly-disruptive change so well. Kudos.
| pmarreck wrote:
| > 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 2022 someone even has to qualify regression
| testing with an "even" (as in "EVEN mention of regression
| testing!") saddens me. Tests reduce developer pain and increase
| developer productivity, full stop. If you get hit by a bus,
| someone else who is working on your code will know they didn't
| break anything thanks to your test suite. Get with the program,
| folks, it's been decades now since this was known.
| notacoward wrote:
| 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.
| yjftsjthsd-h wrote:
| 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.
| unethical_ban wrote:
| 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.
___________________________________________________________________
(page generated 2022-08-03 23:00 UTC)