Honestly, I'm team dynamic linking. I prefer to have things clearly separated in functionality and easily upgradeable.
Statically linking all the OS utilities to their dependency libraries, over and over again? Dear god that sounds awful.
Statically linking all the OS utilities to their dependency libraries, over and over again? Dear god that sounds awful.
The problem is that Linux userspace has historically payed little attention to backwards compatibility and has no definition of "base system". Consequently, Linux distros tend to be their own little mutually-incompatible worlds where you either play with the package manager/repo combo you have or jump through hoops and dodge conflicts to try to get anything to work.
Oasis is interesting in this way: there are no conflicts, there is no package manager, and the binaries should work anywhere provided the arch is the same.
I disagree, I tend to want the opposite. I want big, bloated libraries like Qt or Gtk or Boost to be dynamically linked, and OS facilities like libc to be statically linked.
These fall under "GUI" in the "base system" category in my opinion.
> and OS facilities like libc to be statically linked.
If you're not being sarcastic right now, I'm really curious as to your reasoning.
Whether this is a benefit when you're duplicating bits of libc across every executable in your entire system is unclear to me though.
But isn't this the exact opposite of what Oasis provides?
What is your thinking here? Are you talking about a use case where you have an application that uses a library and a bug fix is issued for that library, so you want to just get the new .so for the library and have the application use it? That feels like a niche use case to me. Maybe there is another benefit, or this use case is more common than I realize. I'd be interested in further opinions/info.
I wouldn't call it a niche use case at all, it's exactly how the software for all major Linux and BSD operating systems are packaged and built.
For example, when (not if) a vulnerability is found in OpenSSL, package maintainers just commit an update to the openssl package and users only have to download and install one package to patch their system against the vulnerability.
Contrast with a fully-static OS and applications: the maintainers would have to update the openssl package, rebuild it, and then also rebuild _every single other program_ that relies on it as well. On my system, that's 123 packages. I don't have all of those installed, but as a user, it means I would have to download new full copies of around a dozen packages to patch one flaw in one package.
And of course, the packages themselves are much _much_ larger too. Most software that I can install as a flatpack or appimage are at least an order of magnitude larger than the deb version, take longer to start, and also take up more valuable RAM when running.
Proponents of static linking have generally experienced the pain of dynamically-linked software either through container deployment or by accidentally messing up their system with third-party packages and repos and the like. I get it, I have been there too. But even through managing a dynamically linked system is certainly more complex, it brings a lot of benefits to the table.
even though I'm typing this on a linux desktop, this is a niche use case. In Windows, macOS, iOS and Android, so 99.9% of all user-facing computing, all the libraries except the OS API are duplicated for each app.
DLL loading is full of security risks. Static binaries are free of them.
DLLs are compiled separately from the binaries that load them. Compilers cannot optimize code that calls into a DLL. Compiler optimizers are amazing these days. Compared to a separately optimized binary + DLL, a completely optimized binary will consume less CPU, use less memory, and cause less heap pressure and fragmentation.
DLL's original purpose is reducing memory and disk usage. Since we have different needs now, DLLs are just technical debt.
Also, on services you got a performance boost.
Just curious, why does that sound awful to you? Are you worried that it will take a long time to relink the binaries? The oasis build system is incremental, so updates to a library only involve relinking dependent binaries, which is quite fast. Even a full rebuild from scratch only takes a few minutes (assuming you have the sources downloaded already).
If it's just the idea of relinking all the dependencies over and over again, note that with dynamic linking you do this at runtime every time you execute a binary.
This is awesome as long as no app you need requires an otherwise-useless yet big thing (with its own requirements) or insists on an obsolete version of a library you prefer to have a newer version of.
For a base image for VMs or containers I'm going to build automatically and throw away on demand anyway, a slightly longer build time to statically link things won't hurt. The memory utilization penalty should also be small, because those should only be running one application or a couple at most.