Alpine Linux is reducing dependencies on Busybox(gitlab.alpinelinux.org) |
Alpine Linux is reducing dependencies on Busybox(gitlab.alpinelinux.org) |
> 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.
> 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.
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.
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.
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.
Because yeah, trying to change Alpine's init system, mdev, or other coreutils is indeed not easy/feasible at the moment.
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.
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.
https://twitter.com/ariadneconill/status/1554846536521207808
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 :-)
[1]: https://ariadne.space/2021/03/25/lets-build-a-new-service-ma...
"Avoiding spinning up new processes" is incorrect characterization of s6. Processes are not a scarce resource; spawning a process is not a costly operation in the context of process supervision, even on embedded systems. s6 focuses on optimizing some metrics that are indeed important to embedded systems, like RAM use and code path length, but "spinning up new processes" isn't one of these metrics.
It is not, and has never been, necessary to learn execline, the scripting language you're speaking of, in order to use s6. execline is used _internally_, and you can also use it in your own scripts if you so choose, but it is not a requirement.
"Sending a polite shutdown signal, waiting for some time, and sending a harsher shutdown signal" is a matter of exactly one command: s6-svc -d. That is precisely one of the benefits of s6 over other daemontools-style supervisors: it handles this sequence natively.
I welcome fact-based criticism of s6. I do not welcome FUD-based criticism.
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.
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.
If you reproduce the error, congrats, now you get to figure out where to file the bug report with reproduction steps.
Though a friend of mine once discovered that it's a bad idea to force remove glibc (on a non BusyBox distro, of course).
Is it worth your time, though?
Which, if you're writing unit tests at the same time as the unit under test, leads naturally to pro-isolation, pro-modular designs, which are both easier to test, more reliable and generally have a more concise purpose.
I've never tried Windows but I've heard it's a faff to do this. Good to hear it's catching up, though!
Use it baremetal for your servers and desktops, then use Debian/CentOS containers on top when something is missing.
There's plenty of good reasons for one to want to do so.
If you're actually doing those things inside one, you're literally doing it wrong
Yes you might have some special cases where some of this is needed but I'd use anything besides systemd
See for more details: https://github.com/krallin/tini/issues/8#issuecomment-146135...
b) systemd is the only thing that can start services cleanly and correctly. Every other solution is in various states of brokenness.
I still think that orchestration should live outside containers, whether within one box or several. BTW systemd has some vestiges of container orchestration built in.
OTOH there are other approaches; say, LXD directly assumes an ecosystem of processes within a container, more akin to a VM than to a single chroot-ed / jailed service process.
Those are what I had in mind. Basically cheaper VPS like service but built on Linux container tech instead of full virtualization. Maybe they are less of a rage these days, when fully virtualized KVM/Vmware VPS are so cheap. But about 5 years ago I did run my email server, webserver and database on such a container for $1-1.5$/mo. When I was able to switch to full virtualization at similar price point, I did. But there's nothing weird about runing multiple different processes in a "container" :)