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

211–220 of 288 posts

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

#211

Post by i-use-nixos-btw »

chaxor wrote: post #190
i-use-nixos-btw wrote: post #181

Earlier quoted context omitted.

Decentralised caching, absolutely - unless I’m misunderstanding what you mean there. You can build across many machines, merge stores, host caches online with cachix (or your own approach), etc. I make fairly heavy use of that, otherwise my CI builds would be brutal. Memorizing isn’t a term I’m familiar with in this context.

Sorry - memoizing . I am interested in making a system that can memoize large databases from ETL systems and then serve that on iroh or ipfs/torrent, such that a process that may take a supercomputer a week to process can have the same code run on a laptop and it will notice it's been done my a university supercomputer before already and grab that result automatically from the decentralized network of all people usin…

Oh I see!

Yes, absolutely doable in Nix.

Derivations are just a set of instructions combined with a set of inputs, and a unique hash is made from that.

If you make a derivation whose result is the invocation of another, and you try and grab the outcome from that derivation, here’s what will happen: - it will generate the hash - it will look that hash up in your local /nix/store - if not found it will look that hash up in any remote caches you have configured - if not found it will create it using the inputs and instructions

This is transitive so any missing inputs will also be searched for and built if missing, etc.

So if the outcome from your process is something you want to keep and make accessible to other machines, you can do that.

If the machines differ in architecture, the “inputs” might differ between machines (e.g. clang on Mac silicon is not the same as clang on x86-64) and that would result in a different final hash, thus one computation per unique architecture.

This is ultimately the correct behaviour as guaranteeing identical output on different architectures is somewhat unrealistic.

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

#212

Post by wongarsu »

bscphil wrote: post #99
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…

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

Windows makes up the lion's share of desktop computing, and seems to be doing fine without actually sharing libraries. Lots of dynamic linking going on, but since about the XP days the entire Windows ecosystem has given up on different software linking the same library file, except for OS interfaces and C runtimes. Instead everyone just ships their own version of everything they use, and dynamic linking is mostly used to solve licencing, for developer convenience, or for plugin systems. The end result isn't that different from everything being statically linked

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

#213

Post by inkyoto »

arghwhat wrote: post #203
marwis wrote: post #133

Earlier quoted context omitted.

But dynamically linked library only needs to be loaded to RAM once whereas with static linking you'd be loading the same code many times (unless you compile everything to single binary like BusyBox). This also gets you better cache utilization. Also I think inlining would typically increase the total size of output rather than decrease it.

Static linking gives you better instruction cache utilization as you are executing local code linearly rather than going through indirection with more boilerplate. This indirection costs a few cycles too. Inlining external code reduces the size not only by saving the call, PLT and and stack dance, but also through specialization (removal of unused conditional, pruning of no longer referenced symbols) as the code is l…

> Static linking gives you better instruction cache utilization as you are executing local code linearly rather than going through indirection with more boilerplate.

No, it does not, it worsens it.

For example, «strlen», if it comes from a dynamic library, will be loaded into the physical memory once and only once, and it will be mapped into each process's address space as many times as there are processes. Since «strlen» is a very frequently used function, there is a very high chance that the page will remain resident in memory for a very long time, and since the physical page is resident in memory, there is also a very good chance that the page will remain resident at least in the L2 cache, but – depending on circumstances – in the L1 cache, too. A TLB flush might not even be necessary in specific circumstances, which is a big performance win. It is a 1:N scenario.

With the static linking, on the other hand, if there are 10k processes in the system, there will be 10k distinct pages containing «strlen» loaded into memory at 10k random addresses. It is a M:N scenario. Since the physical memory pages are now distinct, the context switching will nearly always require the TLB to be flushed out which is costly or very costly, and more frequent L1/L2 cache invalidations due to «strlen» now residing at 10k distinct physical memory addresses.

P.S. I am aware that C compilers now inline «strlen» so there is no actual function call, but let's pretend that it is not inlined for the sake of the conversation.

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

#214

Post by eek2121 »

dijit wrote: 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.

"it just works" so you are doing the tech support when it doesn't, right?

EDIT: that was meant to be a joke, I forgo HN doesn't support emojies.

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

#215

Post by plopz »

nequo wrote: post #162
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…

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

Then why does every steam game need to install a different version of visual c++ redistributable?

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

#216

Post by nequo »

plopz wrote: post #215
nequo wrote: post #162

Earlier quoted context omitted.

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

Then why does every steam game need to install a different version of visual c++ redistributable?

Because they are not packaged by the distros so they are not guaranteed to have the libraries present that they were linked against? I am just guessing, I haven’t used Steam.

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

#217

Post by mech422 »

pjmlp wrote: post #113
mech422 wrote: post #110

Earlier quoted context omitted.

Heh...rebuilding gcc on slackware to enable shared libs was an adventure - but that wasn't till the late 90s(??). I think I spent like a week bootstrapping the new gcc, rebuilding glibc and rebuilding all the stuff I used.

UNIX System V 4.0 was the one that kind of uniformized existing parallel solutions from UNIX variants, alongside ELF in the late 1980's.

yeah - I never had access to a 'real' unix. Closest I came was solaris and maybe Irix. Other then that, it's just been Linux. Keep meaning to give *BSD a try...

P.S. - oh! and I had friends that loved HP/UX - another one I never got to try

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

#218

Post by nightowl_games »

ghotli wrote: post #13
nightowl_games wrote: post #8

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…

I still don't understand.

Is oasis the "drop in binary" you would use? Or do you use oasis to build the tool that you would use?

"The allure of something like this is I could potentially grab a drop in binary"

From where?

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

#220

Post by yjftsjthsd-h »

o11c wrote: post #53
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.

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

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

I was under the impression that musl stuck closely to the standard, and glibc frequently did its own thing, so 1. it's not musl that's quirky, 2. if you need to detect something, just detect glibc.

Post reply on HN