> Fast builds that are 100% reproducible.
It's unclear to me what "100%" refers to here, but surely it does not include the Linux kernel or drivers? (I've recently read conversations about how difficult this would be.)
Oasis – a small, statically-linked Linux system
81–90 of 288 posts
Re: Oasis – a small, statically-linked Linux system
#82Earlier quoted context omitted.
I know lots of compilers/linkers don't optimize for it but it should be possible to 'tree shake' libraries so only the parts that are used by an application are included. That would shake off a lot of the 'bloat'.
Wait, it's not being done?
It is, major compilers do that by default
Re: Oasis – a small, statically-linked Linux system
#83Earlier quoted context omitted.
In a world where Docker and Kubernetes exist, where whole copies of operating systems are added to each running service... This seems a weird thing to complain about =)
Yeah but there I can still update vulnerable libraries independently, to be a statically linked system just means that if there is a bug in libpng then I have to recompile everything?
> if there is a bug in libpng then I have to recompile everything?
You say that as if it's such a burden. But it's really not.
I'm somewhat sympathetic to the space argument, but a package manager/docker registry means that updating software is very easy. And it happens all the time for other reasons today anyhow.
Re: Oasis – a small, statically-linked Linux system
#84Doesn't linking everything statically imply that the base image -- and memory, at runtime -- will be bloated by many copies of libc and other common libraries? I do like the simplicity of static linking but it sort of seems to go against the idea of avoiding "bloat".
A linker typically only includes the parts of the library it needs for each binary so some parts will definately have many copies of the same code when you statically link but it will not make complete copies. But I wouldnt consider this bloat. To me it is just a better seperation of concerns. To me bloat would be to have a system that has to keep track of all library dependencies instead, both from a packaging persp…
>A linker typically only includes the parts of the library it needs for each binary so some parts will definately have many copies of the same code when you statically link but it will not make complete copies.
Just to add to what you said: in the old days the linker would include only the .o files in the .a library that were referenced. Really common libraries like libc should be made to have only a single function per .o for this reason.
But modern compilers have link time optimization, which changes everything. The compiler will automatically leave out any items not referenced without regard to .o file boundaries. But more importantly, it can perform more optimizations. Perhaps for a given program a libc function is always called with a constant for a certain argument. The compiler could use this fact to simplify the function.
I'm thinking that you might be giving up quite a lot of performance by using shared libraries, unless you are willing to run the compiler during actual loading.
Even without lto, you can have the same results in C++ by having your library in the form of a template- so the library is fully in the /usr/include header file, with nothing in /usr/lib.
Re: Oasis – a small, statically-linked Linux system
#85Earlier quoted context omitted.
Agreed, if the binary is statically linked. If you run `file` on the output from that and it shows 'dynamically linked' then you're playing games with porting over libraries, changing the library loading path, or just going full chroot like linux from scratch does with the bootstrapping part of the install. I find static binaries simplest to work with in that context but agreed I use that pattern too with docker and…
In a way, that's what Nix sets out to do, isolating even dynamically linked libraries: if two derivations depend on the same shared lib derivation then it's reused, if not then they don't conflict. Each leaf derivation can be handled completely independently of the others, and independently of the original system†. And then when Nix† is not an option at runtime, dockerTools†† can build a Docker image to do the minimi…
So Nix keeps track of different versions of shared libraries?
Re: Oasis – a small, statically-linked Linux system
#86[flagged]
Re: Oasis – a small, statically-linked Linux system
#87> Fast builds that are 100% reproducible. It's unclear to me what "100%" refers to here, but surely it does not include the Linux kernel or drivers? (I've recently read conversations about how difficult this would be.)
Got a link? Sounds interesting.
Re: Oasis – a small, statically-linked Linux system
#88Earlier quoted context omitted.
I'll take bloat over dependency hell every day of the week. Feels like every single app is a bundled web browser these days anyways.
> dependency hell Dependency hell comes from bad dependencies that don't do semver properly. Choose your deps carefully, and that's perfectly fine. > Feels like every single app is a bundled web browser these days anyways. Yep, that's apparently the best way to use the bad libraries people want to use and not give a damn about semver.
Semver is nearly impossible to do "properly" because of https://xkcd.com/1172. With a sufficient number of users, all bug fixes are breaking changes. If the behavior can possibly be observed in any way, some user will be depending on it, deliberately or otherwise.
Re: Oasis – a small, statically-linked Linux system
#89> Fast builds that are 100% reproducible. It's unclear to me what "100%" refers to here, but surely it does not include the Linux kernel or drivers? (I've recently read conversations about how difficult this would be.)
I'm no expert, but as an interested amateur I thought the Linux kernel could already be built reproducibly?
There is some documentation at least... and I know several Linux distributions have been working on reproducible builds for a long time now - I'd be surprised if there hasn't been good progress on this.
https://www.kernel.org/doc/html/latest/kbuild/reproducible-b...
Re: Oasis – a small, statically-linked Linux system
#90Can someone explain a couple use cases for something like this?
> Can someone explain a couple use cases for something like this? At this point, it would be more useful if someone explained a couple of use cases for dynamic linking.
Plugins, unless you want to have one process per plugin.
Which in the days of running Kubernetes clusters on laptops maybe isn't a big deal.