Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Oasis: a small statically-linked Linux system

github.com

Post reply on HN
Print view View original

121–130 of 169 posts

Re: Oasis: a small statically-linked Linux system

#121

Post by Teknoman117 »

tetraca wrote: post #73
siraben wrote: post #55

Does statically linking everything not lead to much higher disk usage, espcially when you have thousands of binaries? Drew Devault has an analysis[0] that appears to claim otherwise. [0] https://drewdevault.com/dynlib.html

It might have been a concern long ago when space was a premium, but these days in the world of >=1TB drives you could probably build your entire software library in the most horrifying, space inefficient way, and it would still be completely and utterly dwarfed by the user's media library. Excepting games, I would bet most anyone's software library would likely comfortably fit under 128 GB. The photos, games, music,…

The majority of a game's data usage comes from assets. The binary is a tiny fraction of the size of the application.

Re: Oasis: a small statically-linked Linux system

#123

Post by qwerty456127 »

Subsentient wrote: post #13

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.

> 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.

Re: Oasis: a small statically-linked Linux system

#124

Post by tln »

siraben wrote: post #55

Does statically linking everything not lead to much higher disk usage, espcially when you have thousands of binaries? Drew Devault has an analysis[0] that appears to claim otherwise. [0] https://drewdevault.com/dynlib.html

Yes, I would think static linking would lead to higher disk usage for binaries.

That analysis doesn't really answer the question re: disk usage and doesn't really quantify how much sharing there is from shared libraries, just how many shared libraries don't get shared... basically "Do your installed programs share dynamic libraries" is answered as "not really" because there s a long tail of libraries that are not widely shared.

Drew's stats shows 80% of binaries link to libc (1.8MB on my system), which by itself could be "a lot" of extra storage. It wouldn't be 80% * 1.8MB per executable if unused symbols weren't linked, but still

Re: Oasis: a small statically-linked Linux system

#125

Post by mforney »

qwerty456127 wrote: post #122

> netsurf instead of chromium or firefox Great for the default but can we have a Firefox/Chromium/derivative as an alternative, for the sites which don't work in NetSurf?

Yep, you can install firefox via pkgsrc or nix. Due to the complexity of the modern web browser and all of its dependencies, it is unlikely to ever be part of oasis itself.

Re: Oasis: a small statically-linked Linux system

#126

Post by eeZah7Ux »

gameswithgo wrote: post #15
mittermayr wrote: post #8

Would be cool to get a bit of a "why this matters" intro on repos like this. I clicked through the details, but left wondering if I have any potential use for this. Can I compile this onto a USB stick and use it as a throw-away boot Linux for maintenance tasks? Can I cross-compile this for embedded devices? What is the statically-linked advantage here? Not trying to minimize the effort, I would actually love to see m…

As someone who uses linux casually, I often experience pain when I download a program, try to run it, and it fails because some dependency is not installed or is not the right version. So you try to figure out how to install it and it in turn needs a couple of things. All of this works fine if whatever package manager your distro uses has the program you want, but the package managers don't have evertying! So I'd lov…

> So I'd love an ecosystem where things tend to be statically linked unless there is a good reason not to.

Security: a good distro provides security updates for shared libraries. With static linking it becomes too burdensome.

Re: Oasis: a small statically-linked Linux system

#127

Post by wahern »

qppo wrote: post #111
ChiefOBrien wrote: post #107

Earlier quoted context omitted.

Hot take: A great tragedy of the GNU/Linux ecosystem is the fact that ABI+API is still not figured out, and the most common interface between programs is the C ABI, which is embarassingly primitive even by 80's/90's standards. Some people in the FOSS community just want to leave things as-is to hinder propiertary software, and it's the same story with device drivers. You can debate the merits rightfully so, but then…

That's a searing hot take, to be sure. There is no alternative to the C ABI. If you look at stable ABIs in other programming languages, they're either identical to or thin shims around the C ABI! Even COM, with the caveat of calling convention on MSVC. Regardless of ABI stability you also need software to have API stability for stable distribution. The two solutions to this problem are to statically link everything o…

> Then to launch the software you need a shell script that overrides the loader search path and move on with your life.

> The ultimate solution is the .app/.bundle paradigm of MacOS. Everything should copy that.

All ELF systems support the $ORIGIN RPATH macro. It lets you build and package an application exactly like, if not better than, you would a macOS bundle. Specifically, it let's you specify at compile time a library load path relative to the invoked binary. You'd specify it as $ORIGIN/../lib for the canonical bin/, lib/, etc layout.

Re: Oasis: a small statically-linked Linux system

#128

Post by eeZah7Ux »

tln wrote: post #124
siraben wrote: post #55

Does statically linking everything not lead to much higher disk usage, espcially when you have thousands of binaries? Drew Devault has an analysis[0] that appears to claim otherwise. [0] https://drewdevault.com/dynlib.html

Yes, I would think static linking would lead to higher disk usage for binaries. That analysis doesn't really answer the question re: disk usage and doesn't really quantify how much sharing there is from shared libraries, just how many shared libraries don't get shared... basically "Do your installed programs share dynamic libraries" is answered as "not really" because there s a long tail of libraries that are not wid…

The problem is not the size, but for Linux distributions to provide fast security updates for shared libraries instead of having to patch and recompile tons of packages.

Re: Oasis: a small statically-linked Linux system

#129

Post by qwerty456127 »

mforney wrote: post #125
qwerty456127 wrote: post #122

> netsurf instead of chromium or firefox Great for the default but can we have a Firefox/Chromium/derivative as an alternative, for the sites which don't work in NetSurf?

Yep, you can install firefox via pkgsrc or nix. Due to the complexity of the modern web browser and all of its dependencies, it is unlikely to ever be part of oasis itself.

Is a self-sufficient static build of Chromium or Firefox an impossible thing?

Re: Oasis: a small statically-linked Linux system

#130

Post by eeZah7Ux »

jcelerier wrote: post #68
bityard wrote: post #50

Earlier quoted context omitted.

> 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.…

> 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. 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.

Updating OpenSSL or any other shared library is a "niche use case"?
Post reply on HN