> 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".
> 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."
> 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.
The underlying goal (in the long follow up message) seems to be the desire to move from mdev (in busybox) to mdevd (not in busybox) so the title is to some degree justified. Although the situation is a complicated and subtle one, as per usual with Linux distributions.
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.
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.
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.
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.
> 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.
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.
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?
At most, this MR is reducing dependencies on busybox's init scripts.
A far more accurate title would be the title of the MR itself: "main/mdevd: make it a fully supported alternative to mdev". The MR is mainly about mdev.
As Ariadne was talking yesterday about mid-long term removing busybox, there was a big hype around it and maybe we/some others made more from this MR than it was.
g051051|3 years ago
> 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".
wpietri|3 years ago
> 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."
tremon|3 years ago
> 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.
rkangel|3 years ago
hinkley|3 years ago
[deleted]
rahen|3 years ago
https://skarnet.org/software/s6/
https://skarnet.com/projects/service-manager.html
1vuio0pswjnm7|3 years ago
wpietri|3 years ago
jart|3 years ago
silon42|3 years ago
notacoward|3 years ago
pmarreck|3 years ago
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.
yjftsjthsd-h|3 years ago
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|3 years ago
Because yeah, trying to change Alpine's init system, mdev, or other coreutils is indeed not easy/feasible at the moment.
nibbleshifter|3 years ago
LAC-Tech|3 years ago
rurban|3 years ago
yjftsjthsd-h|3 years ago
blueflow|3 years ago
ryan-duve|3 years ago
octoberfranklin|3 years ago
At most, this MR is reducing dependencies on busybox's init scripts.
A far more accurate title would be the title of the MR itself: "main/mdevd: make it a fully supported alternative to mdev". The MR is mainly about mdev.
tecleandor|3 years ago
https://twitter.com/ariadneconill/status/1554846536521207808
unknown|3 years ago
[deleted]
freemint|3 years ago
gtirloni|3 years ago