$ docker run -it --rm alpine
/ # apk add cmd:ldd
/ # ldd $(which ash)
/lib/ld-musl-x86_64.so.1 (0x7f4cb4d1d000)
libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x7f4cb4d1d000)
/ # apk add cmd:python3
/ # ldd $(which python3)
/lib/ld-musl-x86_64.so.1 (0x7fd630cab000)
libpython3.12.so.1.0 => /usr/lib/libpython3.12.so.1.0 (0x7fd63069a000)
libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x7fd630cab000)Alpine’s connection to static linking is mainly that it provides a convenient musl build environment. A fully static binary can run in `FROM scratch`.
Not just `FROM scratch` but also in other contexts. For example:
I wrote my own password manager which lives on a USB drive. Since I compiled a static binary, I can execute it on any Linux machine.
Running static binaries in FreeBSD's Linuxulator is easier. The Linuxulator is a separate set of syscalls that get used when you attempt to run a Linux binary, so a static binary will "just work" for the most part (unless the program needs special filesystems like /proc or /sys). A dynamically linked binary means I need to make sure I have any necessary Linux libraries in the proper location and the Linuxulator's `ld` working properly. Updates to these libraries can then make something that used to work, suddenly stop working. Certainly not an insurmountable task, but there's so many fewer places where things can break when you're just running a static binary.
I don't think that's fair. Alpine-derived images are generally smaller, all things held equal. Of course if you do everything else right then it will matter less, but a proper multistage Dockerfile should still be smaller than the same thing built out of another distro (most of the time).
AI can fix a lot of issues that lingered due to lack of time & patience for proper testing and experimentation.
For example, I had VM instances crashing because of a commercial vendor's agents (telemetry, auth etc). AI identified why the crash occurred, and rewrote the buggy vendor agent with a lighter and more resilient agent.
I brought the issue up with the vendor, and they were stuck with their approach for legacy reasons. Fine! we can both operate happily now. I don't have to use their software.
The pragmatic argument for hard no-LLM projects: if models are to be useful, they need good input. Hand-written software that has been carefully audited is free from the kinds of feedback errors that will eventually weaken LLM code generation. Otherwise, a bad pattern gets copied. In the next generation, this bad pattern is seen a bit more often as stochastic models converge on it and more open source code adopts it. This is reinforced in the next generation and it becomes a common pattern. Then, in the next generation, this pattern is seen all over. This could be inert "non-coding DNA" like weird naming conventions or pointless comments. Or, it could be bad edge cases that become commonly exploitable.
This is an argument, anyhow, but it's very far from being the only (pragmatic) one.
>binutils gcc gdb libffi perl xorriso
Good luck replacing those ...
Oh, how the mighty have fallen. Still remember the times when the meme was that the NetBSD was running on absolutely anything.
This suggests the commenter once thought that NetBSD was mighty
Perhaps he never had such thoughts
If so, then this comment is disingenuous
There is an obvious difference between "hardware (feature) support" and "runs NetBSD"
For example I don't need X11, ACPI, audio or WiFi to "run NetSBD". I want a server not a "desktop"
Fucking get over yourself.