4 ms·

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

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?

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?