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

161–170 of 288 posts

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

#161

Post by IshKebab »

i-use-nixos-btw wrote: post #153
dijit wrote: post #115

Earlier quoted context omitted.

I didnt need to use bazel, I like bazel and want to learn more about it. I also have a small, but burning, passion for reproducible builds, distributed compilation and distributed caching. Being able to build an entire OS and essentially anything I want on top in a reproducible and relatively organic way (with incremental compilation) is pretty dope.

You sound like the perfect Nix cult memb… erm, user. It’s everything you describe and more (plus the language is incredibly powerful compared with starlark). But you speak from sufficient experience that I presume Nix is a “been there, done that” thing for you. What gives?

Nix isn't as fine-grained as Bazel as I understand it? I don't think it's incremental within a package, which is presumably what dijit achieved.

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

#162

Post by nequo »

jvanderbot wrote: post #51
jezze wrote: 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…

> Dynamic linking served us when OS upgrades came infrequently, user software was almost never upgraded

Even today, dynamic linking is not only a security feature but also serves convenience. A security fix in OpenSSL or libwebp can be applied to everything that uses them by just updating those libraries instead of having to rebuild userland, with Firefox, Emacs, and so on.

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

#163

Post by IshKebab »

nerpderp82 wrote: post #79
Gazoche wrote: post #72

Earlier quoted context omitted.

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/

Exactly this. Windows apps aren't distributed as Docker images. Guess why...

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

#164

Post by chaxor »

jvanderbot wrote: post #51
jezze wrote: 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…

I'm not versed in this, so apologies for the stupid question, but wouldn't statically linking be more secure, if anything? Or at least have potentially better security?

I always thought the better security practice is statically linked Go binary in a docker container for namespace isolation.

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

#165

Post by schemescape »

o11c wrote: post #109
schemescape wrote: post #104

Earlier quoted context omitted.

What are the quirks of static linking you need to work around (in general, not for glibc)?

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

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

#166

Post by palata »

StillBored wrote: post #151
bscphil wrote: post #99

Earlier quoted context omitted.

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

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 yes, you have to understand that you are now the maintainer of that library. Link it dynamically or statically, whichever you want, but you are responsible for its updates in any case.

The fashion that goes towards statically linking everything shows, to me, that people generally don't know how to handle dependencies. "It's simpler" to copy-paste the library code in your project, build it as part of it, and call that "statically linking". And then probably never update it, or try to update it and give up after 10min the first time the update fails ("well, the old version works for now, I don't have time for an update").

I am fine with people who know how to do both and choose to statically link. I don't like the arguments coming from those who statically link because they don't know better, but still try to justify themselves.

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

#167

Post by tyingq »

chaxor wrote: post #164
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…

I'm not versed in this, so apologies for the stupid question, but wouldn't statically linking be more secure, if anything? Or at least have potentially better security? I always thought the better security practice is statically linked Go binary in a docker container for namespace isolation.

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.

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

#168

Post by palata »

moffkalast wrote: post #124
bscphil wrote: post #99

Earlier quoted context omitted.

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

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

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

#169

Post by ratrocket »

lubutu wrote: post #132
ratrocket wrote: post #64

Earlier quoted context omitted.

A comment up-thread (currently) says/implies Oasis is a successor to sta.li by the same person. https://news.ycombinator.com/item?id=39143029 I also thought sta.li when I saw this was about a statically linked linux system...

It's not by the same person — sta.li was by Anselm R Garbe. It's more like a spiritual successor.

Ah, thank you for the clarification. I read the linked to (by me) comment too quickly and/or without thinking enough! Cheers!

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

#170

Post by soulofmischief »

palata wrote: post #154
nerpderp82 wrote: post #79

Earlier quoted context omitted.

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/

To be fair, QubesOS does not really solve the problem of bad libraries creating dependency hell. If you need to ship every app with its own rootfs because you can't handle dependencies, then you will have to do that on QubesOS as well (you don't want one VM per app). Also the biggest problem I had with QubesOS is that it doesn't support GPU (for security reasons). It feels like that was a big cause for the reduced pe…

Same, I love Qubes' philosophy and UX, but GPU passthrough support was a dealbreaker in the end and I switched to a KVM system.
Post reply on HN