71–80 of 87 posts
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
Oh, interesting! Anybody used s6? I like the theory, but for me what matters is mainly the practice.
Earlier quoted context omitted.
One of the reasons people use alpine is to get away from GNU cruft.
If that's indeed the case, I think it might be because of the fear of license trouble ie the whole business of Docker images referencing/installing a Debian base as the first thing always had the smell of a GPL circumvention device to me, in part at least. But it seems license holders don't really bother, or we've heard about it by now. And in that context, Alpine already got rid of the OS and glib, leaving only the…
Earlier quoted context omitted.
All of the cheap Linux container hosting services are doing it wrong, I guess.
Many of them offer k8s out of the box. 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" :)
Earlier quoted context omitted.
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.
Yeah, the scope of things that an operating system needs to be able to do is basically, “all things that can be done on a computer”, so if you are trying to write full regression tests you are never going to hit all the possible combinations.
Earlier quoted context omitted.
My golden rule of sys admin is if you can't fix it, you reformat and replace it. If you reproduce the error, congrats, now you get to figure out where to file the bug report with reproduction steps.
My golden rule of sys admin is that anything on a Linux based OS can be fixed. Preferably without a reboot. 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?
Earlier quoted context omitted.
My golden rule of sys admin is that anything on a Linux based OS can be fixed. Preferably without a reboot. Though a friend of mine once discovered that it's a bad idea to force remove glibc (on a non BusyBox distro, of course).
God, yes. If all you know is reboot & reinstall (bad habits probably brought from the windows world where you generally can't do anything else), you'll never get past the basics.
I've never tried Windows but I've heard it's a faff to do this. Good to hear it's catching up, though!
Earlier quoted context omitted.
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.
I'm not the OP, but a past employer used it on some legacy systems. It makes some choices, like avoiding spinning up new processes, that feel like it's been optimized for embedded systems. It uses a new-to-me language, that we never invested time in. So doing things like "send polite shutdown signals, wait 30 seconds, send harsher shutdown signals" became a matter of separate scripts or documentation. In short, you'd…
"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.
Earlier quoted context omitted.
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.
You can already install coreutils and udev over busybox, without busybox being removed.
Earlier quoted context omitted.
Yeah, the scope of things that an operating system needs to be able to do is basically, “all things that can be done on a computer”, so if you are trying to write full regression tests you are never going to hit all the possible combinations.
It's not even just that, but also that a lot of the things OSs do are painful to artificially test because they're on the edge of hardware and software, or involve building the abstractions that let other software run without worrying about those details. How do you make a CI job that tests that mdevd correctly handles enumerating devices and setting their /dev nodes correctly, when the edge cases are finicky hardwar…
Earlier quoted context omitted.
> 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…
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.