21–30 of 87 posts
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…
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 f…
> 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…
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.
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.
Earlier quoted context omitted.
They're really still going through with that? I didn't expect I'd have to find another distro so soon.
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.
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…
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.
> 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.
> 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…
> 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.
Earlier quoted context omitted.
They're really still going through with that? I didn't expect I'd have to find another distro so soon.
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.
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.