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

221–230 of 288 posts

Re: Oasis – a small, statically-linked Linux system

#221

Post by manmal »

jvanderbot wrote: post #51
jezze wrote: post #48

Earlier quoted context omitted.

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…

Dynamic linking served us when OS upgrades came infrequently, user software was almost never upgraded short of mailing out new disks, and vendors had long lead times to incorporate security fixes. In the days of fast networks, embedded OSs, emphemeral containers, and big hard drives, a portable static binary is way less complex and only somewhat less secure (unless you're regularly rebuilding your containers/execs in…

Apple has been pushing dynamic libraries for a while, but now realized that they really like static linking better. The result is they found a way to convert dynamic libraries into static ones for release builds, while keeping them dynamic for debug builds: https://developer.apple.com/documentation/xcode/configuring-...

Re: Oasis – a small, statically-linked Linux system

#222

Post by IshKebab »

palata wrote: post #180
IshKebab wrote: post #172

Earlier quoted context omitted.

There are various kinds of "dependency hell". To be honest I can't think of any that are due to not doing semver properly. Usually it's: 1. Software depending on versions of libraries that are newer than the latest version available on the distro you have to use ( cough RHEL 8 ). E.g. this very day I ran into a bug where some Asciidoctor plugin craps out with an error because my version of Ruby isn't new enough. Ruby…

> Software depending on versions of libraries that are newer than the latest version available on the distro you have to use (cough RHEL 8). That is a fair point, but it raises a question: if you absolutely need to use software that is not packaged by your distro of choice and that you cannot package yourself (are you sure you can't maintain a "community" package yourself with RHEL?), maybe you don't want that distro…

> maybe you don't want that distro

Well I definitely don't want RHEL 8 but unfortunately I have to use it because some software I use requires it (RHEL 9 doesn't have old enough versions of some libraries) or is only certified on it (this is for work).

But even if I was using a more modern distro, none of them have all software packaged. And no I obviously don't want want to become a packager. Some of the software I use is closed source so that's not even an option.

The only real option is Docker (or Apptainer/Distrobox etc), which sucks.

The fundamental model of "we'll just ship all software that exists; all software is open source" that most distros try to use is just fundamentally wrong.

Snap and Flatpak are trying to fix that but in my experience they aren't remotely ready yet.

Re: Oasis – a small, statically-linked Linux system

#223

Post by IshKebab »

palata wrote: post #177
IshKebab wrote: post #163

Earlier quoted context omitted.

Exactly this. Windows apps aren't distributed as Docker images. Guess why...

Well nothing prevents you from dynamically linking only glibc and statically linking everything else, without Docker at all . The fact that people distribute their app with a full rootfs in a Docker containers says more about the fact that they don't know how to link stuff properly, IMHO.

It's not about static vs dynamic linking at all. It's about bundling dependencies or not.

And yes, you totally can do it. Most Linux software just doesn't bother because - while you can do it, in a lot of languages (C, Python, etc.) it's quite a pain to do. Especially if you have lots of dependencies.

It's much easier to bundle dependencies in languages that statically link by default (Go, Rust) because of course statically linking implicitly bundles them.

Re: Oasis – a small, statically-linked Linux system

#224

Post by gnramires »

arghwhat wrote: post #204
gnramires wrote: post #94

Earlier quoted context omitted.

As far as I can see, it would be unwise to roll back 30 years of (Linux) systems building with dynamic linking in favor of static linking. It mostly works very well and does save some memory, disk, and has nice security properties. Both have significant pros and cons. I've been thinking (not a Linux expert by any means) the ideal solution would be to have better dependency management: I think a solution could be if s…

Linus Torvalds disagrees: https://lore.kernel.org/lkml/CAHk-=whs8QZf3YnifdLv57+FhBi5_W...

I should have been more balanced or nuanced a bit: I also don't think static linking is to be forbidden or completely shunned. As Linus himself says, a combination of both may be ideal. For basic system libraries like GUI libraries the current approach works well. But you should be free to static link if you want, and if there are serious issues if you don't. Maybe dynamic linking should be focused on a smaller number of well curated libraries and the rest should be left to static. Library archeology seems like a potential serious problem years from now.

I still think better listing dependencies (perhaps with the option to pin an exact version?) would be helpful, as well as better usage of something like semver. Someone mentioned binaries include paths to dependencies, but as far as I know, there is no tool to automatically try to resolve those dependencies or standard interface, maybe some more tooling in this area would help.

Another nice point about how it current works is that I think it relieves work from programmers. The policy of "Don't worry about distribution (just tell us it exists)" from distros seems like one less headache for the creator (and you can provide static linked binaries too if you want).

As most things in life, the ideal is somewhere in the middle...

Re: Oasis – a small, statically-linked Linux system

#225

Post by formerly_proven »

StillBored wrote: post #151
bscphil wrote: post #99

Earlier quoted context omitted.

> In the days of fast networks, embedded OSs, emphemeral containers, and big hard drives, a portable static binary is way less complex and only somewhat less secure If what you're trying to do is run a single program on a server somewhere, then yes absolutely a static binary is the way to go. There are lots of cases, especially end user desktops, where this doesn't really apply though. In my opinion the debate over s…

understanding that they are different tools for different jobs Right, but this goes against the dogma on both sides and the fact that much of Linux userspace is the wild west. Ideally, there should be a set of core system libraries (ex glibc, openssl, xlib, etc) that have extremely stable API/ABI somatics and are rarely updated. Then one dynamically links the core libraries and statically links everything else. This…

> Right, but this goes against the dogma on both sides and the fact that much of Linux userspace is the wild west. Ideally, there should be a set of core system libraries (ex glibc, openssl, xlib, etc) that have extremely stable API/ABI somatics and are rarely updated.

This is largely true and how most proprietary software is deployed on Linux.

glibc is pretty good about backwards compatibility. It gets shit for not being forwards compatible (i.e. you can't take a binary linked against glibc 2.34 and run it on a glibc 2.17 system). It's not fully bug for bug compatible. Sometimes they'll patch it, sometimes not. On Windows a lot of applications still link and ship their own libc, for example.

xlib et al don't break in practice. Programs bring their own GUI framework linking them and it'll work. Some are adventurous and link against system gtk2 or gtk3. Even that generally works.

OpenSSL does have a few popular SONAMEs around but they have had particularly nastily broken APIs in the past. Many distros offer two or more versions of OpenSSL for this reason. However, most applications ship their own.

If you only need to talk to some servers, you can link against system libcurl though (ABI compatible for like twenty years). This would IMHO be much better than what most applications do today (shipping their own crypto + protocol stack which invariably ends up with holes). While Microsoft ships curl.exe nowadays, they don't include libcurl with their OS. Otherwise that would be pretty close to a universally compatible protocol client API and ABI and you really wouldn't have any good reason any more to patch the same tired X.509 and HTTP parser vulnerabilities in each and every app.

Re: Oasis – a small, statically-linked Linux system

#226

Post by akira2501 »

inkyoto wrote: post #208
jezze wrote: post #48

Earlier quoted context omitted.

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 […] It is exactly the same with the dynamic linking due to the demand paging available in all modern UNIX systems: the dynamic library is not loaded into memory in its entirety, it is mapped into the process's virtual address space. Initially, there is no code from the dynamic library loaded into memory until the process attempts to…

> It is a one-off step, though.

Yes, but often a one off step that sets all your calls to call through a pointer, so each call site in a dynamic executable is slower due to an extra indirection.

> For large, very large and frequently used dynamic libraries, caching can be employed to reduce such overhead.

The cache is not unlimited nor laid out obviously in userspace, and if you have a bunch of calls into a library that end up spread all over the mapped virtual memory space, sparse or not, you may evict cache lines more than you otherwise would if the functions were statically linked and sequential in memory.

> as the 100% code coverage is exceedingly rare.

So you suffer more page faults than you otherwise have to in order to load one function in a page and ignore the rest.

Re: Oasis – a small, statically-linked Linux system

#227

Post by palata »

IshKebab wrote: post #223
palata wrote: post #177

Earlier quoted context omitted.

Well nothing prevents you from dynamically linking only glibc and statically linking everything else, without Docker at all . The fact that people distribute their app with a full rootfs in a Docker containers says more about the fact that they don't know how to link stuff properly, IMHO.

It's not about static vs dynamic linking at all. It's about bundling dependencies or not. And yes, you totally can do it. Most Linux software just doesn't bother because - while you can do it, in a lot of languages (C, Python, etc.) it's quite a pain to do. Especially if you have lots of dependencies. It's much easier to bundle dependencies in languages that statically link by default (Go, Rust) because of course sta…

> Dynamic Library hell is why Docker exists.

> It's much easier to bundle dependencies in languages that statically link by default

> It's not about static vs dynamic linking at all.

Sorry I'm confused :/. What did I say that you disagree with?

Re: Oasis – a small, statically-linked Linux system

#228

Post by palata »

IshKebab wrote: post #222
palata wrote: post #180

Earlier quoted context omitted.

> Software depending on versions of libraries that are newer than the latest version available on the distro you have to use (cough RHEL 8). That is a fair point, but it raises a question: if you absolutely need to use software that is not packaged by your distro of choice and that you cannot package yourself (are you sure you can't maintain a "community" package yourself with RHEL?), maybe you don't want that distro…

> maybe you don't want that distro Well I definitely don't want RHEL 8 but unfortunately I have to use it because some software I use requires it (RHEL 9 doesn't have old enough versions of some libraries) or is only certified on it (this is for work). But even if I was using a more modern distro, none of them have all software packaged. And no I obviously don't want want to become a packager. Some of the software I…

> And no I obviously don't want want to become a packager.

That's where I disagree. It's not that hard, and if more people did it, more software would be packaged. Actually I am yet to find a library that I actually need and that is not already packaged and maintained by someone from the community. Then I could finally maintain one myself.

To me, you're basically saying: "I don't want to learn and commit to maintain a package for my distro, because reason, but I am fine spending time with all that tooling that I say "sucks" (Docker/Apptainer/Distrobox)". That's what I don't really get. There is a solution that works well (for me, at least): package the software that is not already available yourself.

> Some of the software I use is closed source so that's not even an option.

I would not want to maintain a package with proprietary binaries that I don't own, that's for sure. But if you need to, you can. As long as the author distributes binaries for your platform, it's not much harder than making an open source package.

Re: Oasis – a small, statically-linked Linux system

#229

Post by palata »

palata wrote: post #187
zaphar wrote: post #182

Earlier quoted context omitted.

If Linux dependency management works well in theory but not in practice then it doesn't work. It works in nix because it can literally use multiple minor versions of a library when it needs to with no problem. Most distro's can't or won't do that. You can call it malpractice but it's not going to stop so in practice you need a way to deal with it.

Well, by calling it "malpractice", I say that it works for "true professionals". Then we could say that "it doesn't work in practice if people who don't know what they are doing cannot use it", of course. The question then is where we want to put the bar. I feel like it is too low, and most software is too bad. And I don't want to participate in making tooling that helps lowering the bar even more.

And by the way it does work really well for good software. Actually most Linux distros use a system package manager and have been doing it for decades.

So I think it would be more accurate to say that "it doesn't work for lower quality software". And I agree with that.

Re: Oasis – a small, statically-linked Linux system

#230

Post by avgcorrection »

palata wrote: post #78
Gazoche wrote: post #72

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

It seems impossible to solve this by just everyone adopting a manifesto that one GitHub guy wrote many years ago and which has been adopted in some communities but not in many others. And besides there is plenty of (1) human judgement about what is breaking and not (which goes against machine-readability), and (2) worrying about the minutiae of what is a “patch” and a “feature”, and (3) weird implicit social taboos about doing major releases “too often” (?).[1][2]

Most things might be solved by everyone doing SemVer. And for all I know some communities might be running like greased pigs in a chute exactly because they use SemVer (I don’t tend to hear about the everyday everything-is-working stories on HN). But also doing static linking a bit more seems like it would help a lot with the same problem.

[1] All based on discussions I’ve seen. Not really personal experience.

[2] Again, making a spec/manifesto which is both about machine-readability and about shaming people for vague things is very muddled. Although I don’t know how much the latter is about the culture around it rather than the spec itself.

Post reply on HN