Earlier quoted context omitted.
honestly not that much since adopting a GNU-ism or Glibc-ism will in most case result in errors at compile-time.
Nope. This 'self is the standard' way of GNU software is one reason I'm not a big fan of GNU. https://wiki.musl-libc.org/functional-differences-from-glibc...
Void Linux: Into the Void
101–104 of 104 posts
Re: Void Linux: Into the Void
#102Earlier quoted context omitted.
but you can check if the process is running and automatically restarting supervised services is the norm.
The norm for what exactly? There are very simplistic init systems out there that do not supervise anything, and every daemon must come with its in shell script that checks if it is running. Without looking, I don’t know what Void does and the original comment here didn’t make it clear.
Void Linux uses runit a descedent of djb's daemontools which does automatically restart services and provides a way to check if it's running by starting the daemons themselves and keeping them as direct childs.
Re: Void Linux: Into the Void
#103Earlier quoted context omitted.
Alpine is musl only; Void has both glibc and musl variants. Void seems more desktop-focussed than Alpine, and (at least as of a year ago) I didn't have a lot of luck with ZFS on Alpine.
IIRC you can install glibc into Alpine when an application needs it but the packages are all musl.
Re: Void Linux: Into the Void
#104Earlier quoted context omitted.
IIRC you can install glibc into Alpine when an application needs it but the packages are all musl.
A glibc chroot still seems to be the recommended method: https://wiki.alpinelinux.org/wiki/Running_glibc_programs
I think it's still the recommended way for dependency management reasons and missing glibc-packages. If you can get your program running with the alpine glibc you should probably do that