skarnet

7 ms·

1.
by skarnet 3y ago
Except it's... not quite correct. getent performs NSS resolution, not DNS resolution, so its output depends on the value of the hosts field in your /etc/nsswitch.conf, which could be set to something fun like LDAP or some
2.
by skarnet 4y ago
Not at all. I'm referring to the structure of the Alpine packaging, especially around boot scripts, that hardcodes busybox in a number of places and makes it difficult to package an alternative without workarounds - which accumulates t
3.
by skarnet 4y ago
And if you look under the hood, you will see that it's only possible because of a bunch of ad-hoc hacks, which is exactly what my proposal was about: level the playing field and make it possible to have alternatives _without_ the ad-ho
4.
by skarnet 4y ago
Your information is incorrect. "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
5.
by skarnet 9y ago
There is no good solution for servers that, mistakenly, background themselves; the practice of backgrounding itself comes from a time where supervision was not as widely known as it is today, and nowadays there is no excuse for a daemon t
6.
by skarnet 9y ago
You need to read the archives of the supervision mailing-list at list.skarnet.org, as well as http://skarnet.org/software/s6/overview.html - there is a lot of value in process supervision, it's just that most
7.
by skarnet 9y ago
I agree with Jonathan on everything here, with the additional caveat that the Go runtime is particularly heavy, and thus not really suitable for low-level system software (which should use resources sparingly, leaving them for production ap
8.
by skarnet 10y ago
Still in active development too. :) And no, Jonathan, I haven't heard anything from TrueOS people. Which is a shame, because if a distribution is being built today, with no existing legacy service script base to cater to (or if it has
9.
by skarnet 11y ago
I see nothing there that can't be achieved by a simple supervision suite. s6, nosh, even runit provide those features; the extra complexity of systemd isn't needed at all. If even embedded developers are getting pulled in by the
10.
by skarnet 11y ago
Honestly, the people who use Busybox are probably aware of the problems - political as well as technical - with systemd, and most likely not using systemd in the first place because it's not exactly a good choice for embedded systems.
11.
by skarnet 11y ago
But how would you go with restoring such an image? It won't be instant, there will still be a window where the service manager is continuing its work but the image hasn't been restored yet. One way or the other, you need a synchro
12.
by skarnet 11y ago
You seem to dislike the idea of asking for notification support in the daemons themselves. Granted, it's impractical, but it's the only way to avoid race conditions which are rare for most services, but very real for a few progr
13.
by skarnet 11y ago
It's important to realize that "a replacement for systemd" is neither achievable nor desirable. systemd has grown fast and conquered large market shares because it was backed up by a company, which put a lot of money and manp
14.
by skarnet 11y ago
As Jonathan said: the reason for the compilation phase is efficiency. The information in the compiled database is organized for fast loading and immediate access to the complete dependency tree. And yes, efficiency is important. The point o
15.
by skarnet 11y ago
Yes, that was exactly the idea behind s6-fdholder-daemon: set up a central server to keep fds open when you need to restart a process. The old process stores the fd into the fdholder, then dies; the supervisor starts the new process, that r
16.
by skarnet 12y ago
Note that: - You do not have to follow the slashpackage convention to use or build s6. You can configure it out. - You do not have to write your init scripts in execline. Any scripting language, including the shell, will do; I use execlin