Live data from Hacker News

Oasis – a small, statically-linked Linux system

github.com

11–20 of 288 posts

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

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

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

#13

Can someone explain a couple use cases for something like this?

I routinely get embedded linux devices at $dayjob that need my time and attention and they basically never have the tooling I need to get my job done. I'm a pro at looking at how Alpine builds a tool and then just making my own statically linked / minimal size tool to drop in place on the device. The allure of something like this is that I can just potentially grab a drop-in binary and get on with my day. I simply don't attempt to link to libraries already on the device since they're all built in wildly different ways, old tools, old compilers.

Hopefully that's helpful context. Overall since I did linux from scratch half a lifetime ago I've always wondered why something like Oasis hasn't gotten more traction. It's got some ambitious ideas in the README so maybe others have other nice use-cases atop all that. I just see small, statically linked and think 'oh boy if i never have to build my own tools again for some weird board'. If so, I'm here for it.

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

#14
post #7
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.

Have you shared your BUILD files upstream?

No, they were quite happy with Samurai

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

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

> 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 version is 0.6. It is now considered beta-quality software" (from https://bearssl.org/).

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

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

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

#17
post #15
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.

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

[deleted]

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

#18
post #13

Can someone explain a couple use cases for something like this?

I routinely get embedded linux devices at $dayjob that need my time and attention and they basically never have the tooling I need to get my job done. I'm a pro at looking at how Alpine builds a tool and then just making my own statically linked / minimal size tool to drop in place on the device. The allure of something like this is that I can just potentially grab a drop-in binary and get on with my day. I simply do…

> grab a drop-in binary

This is a cool approach on Docker as well.

    FROM some:thing AS bins
    FROM debian:latest
    COPY --from=bins /bin/foo /bin/

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

#19
post #15
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.

> 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 have been addressed. Avoiding musl to me seems like an outdated trope, but there was a time wherein that take was valid indeed.

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

#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".
Post reply on HN