61–70 of 87 posts
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.
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…
Editorialized title is extremely misleading. 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
Earlier quoted context omitted.
To make sure that once services are up and running, they keep running and are restarted automatically? To have good, centralized logging? To manage in-container services the same way you do on the container host? There's plenty of good reasons for one to want to do so.
None of those things are actually needed in a container. 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
b) systemd is the only thing that can start services cleanly and correctly. Every other solution is in various states of brokenness.
Earlier quoted context omitted.
None of those things are actually needed in a container. 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
All of the cheap Linux container hosting services are doing it wrong, I guess.
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.
Earlier quoted context omitted.
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, b…
I think it's a big assumption that the ROI of tests in general is in the same ballpark as the ROI of static analysis. 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 test…
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.
> 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…
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?
Earlier quoted context omitted.
Why would Alpine need systemd? Why would you need it in a container?
I'm not a fan of using Alpine in containers. Use it baremetal for your servers and desktops, then use Debian/CentOS containers on top when something is missing.