Live data from Hacker News

Oasis – a small, statically-linked Linux system

github.com

191–200 of 288 posts

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

#191
post #109

Earlier quoted context omitted.

You have to know the internals of your dependencies so you can link them explicitly, recursively. (admittedly, pkg-config helps a ton, but not all libraries ship (good) .pc files) Global constructors no longer reliably fire unless you are extremely careful with your build system, nor do they run in a predictable order (e.g. you can call a library before it is actually initialized, unlike dynamic linking where only pr…

Thanks! Most of those seem like a fair trade-off for portability… for an app. I’m not sure it’s a great idea for an OS as in the OP, but I do like that they claim accurate incremental rebuilds, to ensure everything get updated. Certainly an interesting experiment! Edit: just to clarify, I meant "app" as in "something that isn't part of the OS/distribution".

The bash-static example alone is proof that the "usefulness" for apps isn't actually there.

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

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

https://www.netsurf-browser.org/documentation/ Every single link on that page is dead. https://www.netsurf-browser.org/about/screenshots/ Judging by the screenshots, it can render BBC, its own website, and Wikipedia. Well, it might be able to render others, we just can't tell from the shots. But we can tell those three websites work with all sorts of different window decorations.

> Every single link on that page is dead

Unfortunately, as it seems. On the start page they say "Last updated 2 January 2007". But version 3.11 was released on 28 Dec 2023.

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

#193
post #166

Earlier quoted context omitted.

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…

> Then one dynamically links the core libraries and statically links everything else. Agreed, and that is already totally possible. - If you split your project in libraries (there are reasons to do that), then by all means link them statically. - If you depend on a third party library that is so unstable that nobody maintains a package for it, then the first question should be: do you really want to depend on it? If…

Statically linking does not imply copying the code into the project

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

#194
post #186
post #167

Earlier quoted context omitted.

If there is a mechanism to monitor the dependency chain. Otherwise, you may be blissfully unaware that some vulnerability in libwhatever is in some binary you're using. Golang tooling provides some reasonable mechanisms to keep dependencies up to date. Any given C program might or might not.

> If there is a mechanism to monitor the dependency chain. So that would not be less secure, but it would also not make it more secure than dynamic linking with a good mechanism, right?

Personally, I think any inherent security advantage (assuming it has great dependency management) would be very small. This "Oasis" project doesn't seem to call it out at all, even though they are making a fair amount of effort to track dependencies per binary.

They cite the main benefits being this: "Compared to dynamic linking, this is a simpler mechanism which eliminates problems with upgrading libraries, and results in completely self-contained binaries that can easily be copied to other systems".

Even that "easily be copied to other systems" sort of cites one of the security downsides. Is the system you're copying it to going to make any effort to keep the transient statically linked stuff in it up to date?

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

#195
post #191

Earlier quoted context omitted.

Thanks! Most of those seem like a fair trade-off for portability… for an app. I’m not sure it’s a great idea for an OS as in the OP, but I do like that they claim accurate incremental rebuilds, to ensure everything get updated. Certainly an interesting experiment! Edit: just to clarify, I meant "app" as in "something that isn't part of the OS/distribution".

The bash-static example alone is proof that the "usefulness" for apps isn't actually there.

[deleted]

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

#196
post #191

Earlier quoted context omitted.

Thanks! Most of those seem like a fair trade-off for portability… for an app. I’m not sure it’s a great idea for an OS as in the OP, but I do like that they claim accurate incremental rebuilds, to ensure everything get updated. Certainly an interesting experiment! Edit: just to clarify, I meant "app" as in "something that isn't part of the OS/distribution".

The bash-static example alone is proof that the "usefulness" for apps isn't actually there.

[deleted]

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

#197
post #188
post #183

Earlier quoted context omitted.

> Yep, the dev(s) of libA should learn good practice. But they didn't and app1 and app2 still have the problem. Sure :-). I just find it sad that app1 and app2 then use the bad libA. Of course that is more productive, but I believe this is exactly the kind of philosophy that makes the software industry produce worse software every year :(.

I used to think the same. But after nearly 30 years of doing this. I no longer think that people will meet the standard you propose. You can either work around it or you can abandon mainstream software entirely and make everything you use bespoke. There are basically no other choices.

Yeah I try really hard to not use "bad" dependencies. When I really can't, well... I can't.

But still I like to make it clear that the software industry goes in that direction because of quality issues, and not because the modern ways are superior (on the contrary, quite often) :-).

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

#198
post #168

Earlier quoted context omitted.

> when you dare to have more than one version of something. Because who would ever need that, right? If done properly, you can have multiple major versions of something and that's fine. If one app depends on libA.so.1.0.3, the other on libA.so.1.1.4, and they can't both live with 1.1.4, it means that `libA` did something wrong. One pretty clear solution to me is that the dev of libA should learn good practice.

Wishing that all people will be smart and always do the correct thing is setting yourself up for madness. The dependency system needs to be robust enough to endure a considerable amount of dumbfuckery. Because there will be a lot of it.

Because I have to live with "malpractice" doesn't mean I should not say it is, IMHO.

I can accept that someone needs to make a hack, but I really want them to realize (and acknowledge) that it is a hack.

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

#199
post #166

Earlier quoted context omitted.

> Then one dynamically links the core libraries and statically links everything else. Agreed, and that is already totally possible. - If you split your project in libraries (there are reasons to do that), then by all means link them statically. - If you depend on a third party library that is so unstable that nobody maintains a package for it, then the first question should be: do you really want to depend on it? If…

Statically linking does not imply copying the code into the project

Of course not. My point was that people who say "static linking is better" because the only thing they know (which is copying the code into their project) results in something that looks like static linking are in the wrong.

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

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

If you don't mind I'm super curious as to what approach you ended up taking. Did you use rules_foreign_cc to build the ninja files they generate? Or generating BUILD files directly? Or something completely different? Sounds like a really cool project!
Post reply on HN