4 ms·

Honestly, I'm team dynamic linking. I prefer to have things clearly separated in functionality and easily upgradeable. Statically linking all the OS utilities

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.

AnIdiotOnTheNet 6y ago
There's no reason that there needs to be such extremes as either all statically linked or all dynamically linked. History has proven that dynamic linking causes a large number of headaches, and static linking has drawbacks as well. There is a reasonable middle ground: base system functionality that is utilized by most software (stdlib, cryptography, networking, gui, etc) should be dynamic and everything else should be static. 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.
- Wowfunhappy 6y ago
  > There is a reasonable middle ground: base system functionality that is utilized by most software (stdlib, cryptography, networking, gui, etc) should be dynamic and everything else should be static. But isn't this the exact opposite of what Oasis provides?
  - AnIdiotOnTheNet 6y ago
    Oasis is just the opposite extreme of how most Linux distros work. That's interesting because no one else does it. I did not say it was the ideal.
- deleted 6y ago
  [deleted]
- Subsentient 6y ago
  >>There is a reasonable middle ground: base system functionality that is utilized by most software (stdlib, cryptography, networking, gui, etc) should be dynamic and everything else should be static 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.
  - AnIdiotOnTheNet 6y ago
    > I want big, bloated libraries like Qt or Gtk or Boost to be dynamically 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.
    - zik 6y ago
      I'm not OP but statically linking a compact libc like musl gets you just the parts of libc that you need and nothing more. This can be a lot more efficient than a dynamically linked program which has to bring in the entire bloated mess of glibc. Whether this is a benefit when you're duplicating bits of libc across every executable in your entire system is unclear to me though.
    - Subsentient 6y ago
      libc is much smaller than other libraries, and as another has pointed out, compiling it statically will get you only the symbols you actually use, so it doesn't even equal the total size of libc. Which makes more sense? Bloating your executable with ~100+MiB of Qt crap, or bloating it with 100KiB of libc symbols?
- nycticorax 6y ago
  This 'middle ground' you describe is essentially how macOS and Windows work, isn't it?
abainbridge 6y ago
> I prefer to have things clearly separated in functionality and easily upgradeable. 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.
- cestith 6y ago
  That is not at al a niche use case, at least on a general-purpose system. Shared libraries on Linux, like most modern OSes, are also shared in resident memory among programs using them. For very common libraries like TLS, readline, or GTK that can be a big savings.
- bityard 6y ago
  > That feels like a niche use case to me. 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.
cestith 6y ago
For a system I'm going to keep and use in multiple ways, dynamic linking is wonderful. Save time building and upgrading, and save memory using the various apps. 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.
mforney 6y ago
> Statically linking all the OS utilities to their dependency libraries, over and over again? Dear god that sounds awful. 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.
qwerty456127 6y ago
> Honestly, I'm team dynamic linking. I prefer to have things clearly separated in functionality and easily upgradeable. 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.

AnIdiotOnTheNet 6y ago

There's no reason that there needs to be such extremes as either all statically linked or all dynamically linked. History has proven that dynamic linking causes a large number of headaches, and static linking has drawbacks as well. There is a reasonable middle ground: base system functionality that is utilized by most software (stdlib, cryptography, networking, gui, etc) should be dynamic and everything else should be static. 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.

Wowfunhappy 6y ago
> There is a reasonable middle ground: base system functionality that is utilized by most software (stdlib, cryptography, networking, gui, etc) should be dynamic and everything else should be static. But isn't this the exact opposite of what Oasis provides?
- AnIdiotOnTheNet 6y ago
  Oasis is just the opposite extreme of how most Linux distros work. That's interesting because no one else does it. I did not say it was the ideal.
deleted 6y ago
[deleted]
Subsentient 6y ago
>>There is a reasonable middle ground: base system functionality that is utilized by most software (stdlib, cryptography, networking, gui, etc) should be dynamic and everything else should be static 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.
- AnIdiotOnTheNet 6y ago
  > I want big, bloated libraries like Qt or Gtk or Boost to be dynamically 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.
  - zik 6y ago
    I'm not OP but statically linking a compact libc like musl gets you just the parts of libc that you need and nothing more. This can be a lot more efficient than a dynamically linked program which has to bring in the entire bloated mess of glibc. Whether this is a benefit when you're duplicating bits of libc across every executable in your entire system is unclear to me though.
  - Subsentient 6y ago
    libc is much smaller than other libraries, and as another has pointed out, compiling it statically will get you only the symbols you actually use, so it doesn't even equal the total size of libc. Which makes more sense? Bloating your executable with ~100+MiB of Qt crap, or bloating it with 100KiB of libc symbols?
nycticorax 6y ago
This 'middle ground' you describe is essentially how macOS and Windows work, isn't it?

abainbridge 6y ago

> I prefer to have things clearly separated in functionality and easily upgradeable. 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.

cestith 6y ago
That is not at al a niche use case, at least on a general-purpose system. Shared libraries on Linux, like most modern OSes, are also shared in resident memory among programs using them. For very common libraries like TLS, readline, or GTK that can be a big savings.
bityard 6y ago
> That feels like a niche use case to me. 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.

cestith 6y ago

For a system I'm going to keep and use in multiple ways, dynamic linking is wonderful. Save time building and upgrading, and save memory using the various apps. 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.

mforney 6y ago

> Statically linking all the OS utilities to their dependency libraries, over and over again? Dear god that sounds awful. 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.

qwerty456127 6y ago

> Honestly, I'm team dynamic linking. I prefer to have things clearly separated in functionality and easily upgradeable. 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.