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 288 posts

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

#121

Post by mappu »

enriquto wrote: post #98
pjmlp wrote: post #90

Earlier quoted context omitted.

Plugins, unless you want to have one process per plugin. Which in the days of running Kubernetes clusters on laptops maybe isn't a big deal.

You can still call dlopen from your static binary, if you really want to.

I tried to do this recently at $DAYJOB, but when you statically link a binary with musl, the dlopen() you get is a no-op:

https://github.com/bpowers/musl/blob/master/src/ldso/dlopen....

I tried to hack in a copy of the musl's dynamic loader (and also from old uclibc). But it took a few hours and my only result was segfaults.

Do you have any pointers on making this work?

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

#122

Post by sylware »

For a real statically-linked linux system, the main issue is GPU support: you must relink all apps _really using_ a GPU, that to include the required GPU drivers.

With sound, alsa, it is fine since there is IPC/shared-memory based mixing that whatever the playback/capture devices [dmix/dsnoop]. Static linking is reasonable. (pulseaudio[012] IPC interfaces are bloaty kludges, hardly stable in time, 0..1..2.., not to be trusted compared to the hardcore stability of alsa one able to do a beyond good enough job *and* _real_ in-process low latency hardware access at the same time).

x11 and wayland are IPC based, then no issue here neither.

But for the GPU, we would need a wayland vulkan3D-inspired set of IPC/shared-memory interfaces (with a 3D enabled wayland compositor). For compute, the interfaces would be de-coupled from the wayland compositor (shared dma-buffers).

The good part of this would be to free our system interfaces from the ultra complex ELF (one could choose an excrutiatingly simple executable file format, aka a modern executable file format, but will need compilers/linkers support to help legacy support).

There is a middle ground though: everything statically linked, except the apps requiring the GPU driver (for that ELF is grotesquely overkill), still provided as a shared library.

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

#123

Post by dwattttt »

hn_go_brrrrr wrote: post #88
palata wrote: post #78

Earlier quoted context omitted.

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

Semver is nearly impossible to do "properly" because of https://xkcd.com/1172 . With a sufficient number of users, all bug fixes are breaking changes. If the behavior can possibly be observed in any way, some user will be depending on it, deliberately or otherwise.

Semver doesn't stop people from depending on unstable/implementation-specific behaviour; it needs to be coupled with a strong mechanism for defining what behaviour is defined by an API, and the result is that "the bug" is with all those users who depend on un-guaranteed behaviour.

The breaks happen regardless, but you have a principled way of defining whose fault/problem it is.

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

#124

Post by moffkalast »

bscphil wrote: post #99
jvanderbot wrote: post #51

Earlier quoted context omitted.

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…

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

It applies very much to end user desktops as well, with snap, flatpak, etc. working towards it. Lots of software requires dependencies that aren't compatible with each other and result in absolute dependency hell or even a broken install when you dare to have more than one version of something. Because who would ever need that, right? Especially not in a dev desktop environment...

Windows is basically all self-contained executables and the few times it isn't it's a complete mess with installing VC++ redistributables or the correct Java runtime or whatever that clueless users inevitably mess up.

We have the disk space, we have the memory, we have the broadband to download it all. Even more so on desktop than on some cheap VPS.

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

#125

Post by MuffinFlavored »

dijit wrote: post #4

I cant speak much about the system, it just works, but the community was really nice when I interacted with them over IRC I had the plan to build oasis with bazel for some immutable OS images that could run as kubernetes nodes. I succeeded with a little pointing.

> I cant speak much about the system, it just works,

What systems don't just work by this criteria?

Just because something is statically linked vs dynamically linked, as long as you are within "normal expected operating conditions", does it really make a "just works vs doesn't work" quality difference?

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

#127

Post by Fronzie »

volemo wrote: post #65
bzzzt wrote: post #50

Earlier quoted context omitted.

I know lots of compilers/linkers don't optimize for it but it should be possible to 'tree shake' libraries so only the parts that are used by an application are included. That would shake off a lot of the 'bloat'.

Wait, it's not being done?

As far as I know, even with LTO, it requires -ffunction-sections -fdata-sections in order to strip out unused functions.

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

#128

Post by arghwhat »

kentonv wrote: post #20

Doesn't linking everything statically imply that the base image -- and memory, at runtime -- will be bloated by many copies of libc and other common libraries? I do like the simplicity of static linking but it sort of seems to go against the idea of avoiding "bloat".

Static linked binaries are a generally lot smaller than a dynamically linked library and its dependencies, especially with link-time optimizations and inlining.

You wouldn't want have 100 tools statically link the entirety of chromium, but for normal C library sizes you don't get bloat. The preference for dynamic libraries in Linux distros is just so they can roll out patch updates in one place instead of rebuilding dependents.

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

#129

Post by dayjaby »

azornathogron wrote: post #89
notfed wrote: post #81

> Fast builds that are 100% reproducible. It's unclear to me what "100%" refers to here, but surely it does not include the Linux kernel or drivers? (I've recently read conversations about how difficult this would be.)

I'm no expert, but as an interested amateur I thought the Linux kernel could already be built reproducibly? There is some documentation at least... and I know several Linux distributions have been working on reproducible builds for a long time now - I'd be surprised if there hasn't been good progress on this. https://www.kernel.org/doc/html/latest/kbuild/reproducible-b...

In container context I've heard a definition of "100% reproducible" that means even file timestamps are 100% the same. Like your entire build is bit-by-bit precisely the same if you didn't modify any source.

Not sure if that's what they mean here.

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

#130

Post by stefan_ »

sylware wrote: post #122

For a real statically-linked linux system, the main issue is GPU support: you must relink all apps _really using_ a GPU, that to include the required GPU drivers. With sound, alsa, it is fine since there is IPC/shared-memory based mixing that whatever the playback/capture devices [dmix/dsnoop]. Static linking is reasonable. (pulseaudio[012] IPC interfaces are bloaty kludges, hardly stable in time, 0..1..2.., not to b…

To be fair ELF is complex mostly because of relocations, which are not purely to support shared libraries but also the nowadays ubiquitous PIE. But GPU drivers is a good point; I don't believe you can even statically link them today, you would only be statically linking a shim that tries to find the real driver at runtime.
Post reply on HN