Live data from Hacker News

Oasis – a small, statically-linked Linux system

github.com

51–60 of 288 posts

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

#51
post #48
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".

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 which case it's break even security wise or possibly more secure, simply because each exec may not include vulnerable code)

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

#52
post #27

Earlier quoted context omitted.

A small point on that last bit. The bearssl authors are pretty conservative when it comes to development milestones, I'd guess that their 0.6 would be pretty solid :)

> I'd guess that their 0.6 would be pretty solid :) Would you accept that kind of reasoning for software running on your pacemaker, or on your insuline pump? I think we should respect the developers here: they're not claiming production quality level (they're claiming beta-quality level) so it's not correct to use that library in any kind of product and claim any kind of production-level quality.

> Would you accept that kind of reasoning for software running on your pacemaker, or on your insuline pump?

God helps me I wouldn't implant anything so fundamental in my body with hard dependencies on encrypted communication to a remote agent elsewhere, no matter the advantage.

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

#53
post #9

What is the comparison between using musl and traditional glibc? Is there performance differences between the two? I have been seeing musl used more and more in both Rust and Zig ecosystems lately.

The real comparison is: musl does not provide any preprocessor macro to tell you what libc you're using.

And it has so many weird quirks that you need to work around.

***

Static linking makes linking more painful, especially regarding global constructors (which are often needed for correctness or performance). This is not a musl-specific issue, but a lot of people are interested in both.

Just do your builds on the oldest supported system, and dynamic linking works just fine. You can relative-rpath your non-libc dependencies if they would be a pain to install, though think twice about libstdc++.

***

The major advantage of MUSL is that if you're writing a new OS, it's much easier to port.

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

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

Yeah I’d prefer we just use another gigabyte of storage than add so much complexity. Even with what is a modest SSD capacity today I have a hard time imagining how I’d fill my storage. I’m reminded of my old workstation from 8 years ago. It had a 500GB hard drive and a 32GB SSD for caching. I immediately reconfigured to just use the SSD for everything by default. It ended up being plenty.

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

#56
post #15

Earlier quoted context omitted.

> What is the comparison between using musl and traditional glibc? you get weird bugs and failures that don't happen with glibc (like the incomplete dns resolving routines that would fail under some conditions) but you can brag about saving 30-40 mb of disk space. this project seems to be compromising on quality overall, in the name of having smaller size. Even BearSSL, by their own website is beta-quality: "Current…

> incomplete dns resolving routines They eventually did fix this, as of musl 1.2.4.

While not an issue for musl-centric distros if they keep updated, note that e.g. Debian stable doesn't have that version yet, so good luck testing.

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

#57
post #33
post #31

Earlier quoted context omitted.

In a world where Docker and Kubernetes exist, where whole copies of operating systems are added to each running service... This seems a weird thing to complain about =)

I mean, if you ran every single executable on your desktop in a separate container I think you'd see problems. There are a pretty large number of programs running on most desktops, plus all the programs that get called by shell scripts, etc. Running a handful of containers representing major applications is more reasonable and the memory wastage may be worth it to avoid dependency conflicts.

You've just described Qubes OS!

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

#58
post #12

Interesting, but what is the use case? What is the advantage of using the croc C compiler instead of e.g. TCC? I wasn't aware of Netsurf ( https://www.netsurf-browser.org/); this is really amazing. But it seems to use Duktape as the JS engine, so performance might be an issue.

cproc supports C11, tcc only goes up to c99. There is also something to be said for cproc using QBE which is slowly growing backends like risc-v etc which tcc doesnt support afaik.

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

#59
post #9

What is the comparison between using musl and traditional glibc? Is there performance differences between the two? I have been seeing musl used more and more in both Rust and Zig ecosystems lately.

One of the reasons I've switched some builds over to musl over glibc, is that I found that glibc linking is brittle if you're going to run a binary over multiple distros in various container environments. Particularly if you want one binary to work on linux across RH and Debian/Ubuntu derived distros or even different ages of distro.

Linus Torvald agrees with you: https://youtu.be/Pzl1B7nB9Kc?feature=shared&t=261

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

#60
post #31

Earlier quoted context omitted.

In a world where Docker and Kubernetes exist, where whole copies of operating systems are added to each running service... This seems a weird thing to complain about =)

Yeah but there I can still update vulnerable libraries independently, to be a statically linked system just means that if there is a bug in libpng then I have to recompile everything?

In most cases relinking is enough.
Post reply on HN