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

71–80 of 288 posts

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

#71

Post by NewJazz »

ghotli wrote: post #19
znpy wrote: 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…

https://musl.libc.org/releases.html I maintain a large codebase, widely deployed, cross compiled to many cpu architecures that's built atop musl. You're right that historically in the context of people blindly using alpine for their container base that sort of thing might be the case. The newest version of musl solves the thing you're describing and in general most of the complaints about malloc perf or otherwise hav…

malloc performance is still sub-par IMO. It is not nearly as terrible as it was, but scudo, memalloc, and glibc's malloc are better.

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

#72

Post by Gazoche »

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

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.

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

#73

Post by znpy »

electroly wrote: post #62
o11c wrote: post #56

Earlier quoted context omitted.

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.

At least we have light at the end of the tunnel now. This is a tremendous improvement from the previous status quo of the musl maintainers not even agreeing that it's a problem.

This alone “musl maintainers not even agreeing it’s a problem” should be a good reason to avoid musl imho

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

#74

Post by electroly »

znpy wrote: post #73
electroly wrote: post #62

Earlier quoted context omitted.

At least we have light at the end of the tunnel now. This is a tremendous improvement from the previous status quo of the musl maintainers not even agreeing that it's a problem.

This alone “musl maintainers not even agreeing it’s a problem” should be a good reason to avoid musl imho

What's a better option for static linking? glibc is religiously against it; they have far worse dogmatic beliefs than this musl DNS thing. I'd be happy to choose a better alternative if one exists, but if one does not, I have to live with the options at hand. From where I'm standing, musl seems like the only game in town. uClibc doesn't seem like it's appropriate for general purpose Linux applications on desktop computers (maybe I'm wrong?).

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

#75

Post by actionfromafar »

skywal_l wrote: post #28
sluongng wrote: 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.

glibc is LGPL. Static linking your application implies some obligation on your part. Musl being MIT is less restrictive.

Not very tough obligations, but it can be a practical hassle. This answer describes it quite well I think:

https://opensource.stackexchange.com/questions/13588/how-sho...

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

#76

Post by colonwqbang »

lnxg33k1 wrote: post #34
Shorel wrote: 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?

Not recompile I guess, but you need to relink everything.

Oasis seems to have a good way of doing that, with the whole system being built in a single tree by an efficient build tool (my recollection from last time it was posted).

A dynamic executable needs to relink every time it's run, which also takes time.

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

#77

Post by jacquesm »

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

Not necessarily. Bloat is one reason why originally dynamic linking was rolled out but the bigger benefit (to manufacturers) was to be able to update libraries without updating the applications. This has been the source of much trouble (dependency hell) and statically linked binaries suffer none of these issues. It's not like every application uses all of every library and an efficient linker is able to see which parts of the library it needs to link and which parts it can safely leave out.

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

#78

Post by palata »

Gazoche wrote: post #72
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".

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.

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

#79

Post by nerpderp82 »

Gazoche wrote: post #72
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".

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.

Dynamic Library hell is why Docker exists. If operating systems had less global state and less ambient authority, our systems would be vastly more tractable. Instead we still create environments that look like replicas of whole hosts.

Might as well go all in and use something with pervasive virtualization like Qubes.

https://www.qubes-os.org/

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

#80

Post by palata »

Shorel wrote: post #31
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".

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 =)

> This seems a weird thing to complain about =)

On the contrary, I find it relevant: I think that the modern way is wasting way, way too much.

Post reply on HN