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

231–240 of 288 posts

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

#231

Post by raverbashing »

skywal_l wrote: post #59
digikata wrote: post #16

Earlier quoted context omitted.

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.

Linus Torvald agrees with you: https://youtu.be/Pzl1B7nB9Kc?feature=shared&t=261

As much as I think about Linux compared to the competition in desktop the more I realize this is right

"If it's a bug people rely on it's not a bug, it's a feature" Let me guess, he was thinking of the memcpy issue that broke flash. Or maybe something else. And I agree, nobody cares

The spec says that because it was the 70s and nobody had thought better of that or how things would work 30 yrs on, and going with it does not make sense.

And I feel the pain of this hardheadedness when any library deprecates an API when they didn't need. "Oh but it's cleaner now" Again, nobody cares

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

#232

Post by raverbashing »

NewJazz wrote: post #71
ghotli wrote: post #19

Earlier quoted context omitted.

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.

Yeah, and with glibc you can even LDLIBRARY an alternative glibc, not so much with musl (unless it changed recently)

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

#233

Post by palata »

avgcorrection wrote: post #230
palata wrote: post #78

Earlier quoted context omitted.

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

It seems impossible to solve this by just everyone adopting a manifesto that one GitHub guy wrote many years ago and which has been adopted in some communities but not in many others. And besides there is plenty of (1) human judgement about what is breaking and not (which goes against machine-readability), and (2) worrying about the minutiae of what is a “patch” and a “feature”, and (3) weird implicit social taboos a…

Good points.

> It seems impossible to solve this by just everyone adopting a manifesto that one GitHub guy wrote many years ago

Well by "semver" I mostly mean "change the major number to indicate a change of ABI", I don't mind so much about the other numbers in this case. But that's a good question: I don't know when it started being a thing. I would guess much, much earlier than GitHub, though.

> human judgement about what is breaking and not

Hmmm... ABI compatibility for the public interface is not really subjective, or is it?

> weird implicit social taboos about doing major releases “too often”

Yes I don't get that one and I fight hard against it.

> But also doing static linking a bit more seems like it would help a lot with the same problem.

Well I am not fundamentally against static linking; to me it makes sense to do a mix, with the caveat that if you link something statically, then you are the maintainer of that code. Whereas if you link a system library dynamically, you merely depend on it.

My problem is about moving to "static linking only" (or "by default", but I don't even know if Rust allows dynamic linking at all?).

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

#234

Post by arghwhat »

marwis wrote: post #209
arghwhat wrote: post #203

Earlier quoted context omitted.

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…

> The case for the shared library having better caching implies multiple processes that are distinct executables But this is the most common case for desktops/multipurpose systems. On my desktop there are tens or hundreds distinct processes sharing most of their code.

No it is not.

Depending on your CPU, you might have, say, 32KB of 8-way associative instruction cache per core. Just being shared does not make it fit in the cache.

A shared library would only be there across processes of different executable images if its users primarily, continuously execute the same paths in shared libs rather than anything unique in their own executable image - e.g., they'd more or less need to be stuck in the same processing-intensive shared routine in the lib. There would also have to be no other processing done in between by other processes that would have trashed the cache.

On the other hand, the severe cache penalty of longer code paths for each executable and the larger PLT call overhead will universally lead to a loss in performance for all library usage.

The scenarios you may hit where different processes are actually executing the same shared code paths to the point of benefiting from shared cache utilization would be cases where they share executable image as well. E.g., browser processes, threads, compilers. Electron too if using system-packaged electron binaries.

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

#235

Post by YoshiRulz »

charcircuit wrote: post #150
kentonv wrote: post #103

Earlier quoted context omitted.

Everything you describe already exists. Executables do list their dependencies, and we have well-defined conventions for indicating ABI breaks. It is entirely normal to have multiple major versions of a library installed for ABI compatibility reasons, and it is also entirely normal to expect that you can upgrade the dependencies out from under a binary as long as the library hasn't had an ABI break. The bigger depend…

>Executables do list their dependencies They list paths to libraries, but not the exact version that the executable depends on. It is a common occurrence for executables to load versions of libraries they were not designed to be used with.

If you're talking about ELF for desktop Linux, they for the most part don't contain file paths, and may specify the version but usually just have the major version (to allow for security updates). You can use ldd to read the list of deps and also do a dry run of fulfilling them from the search path, for example:

  $> ldd $(command -v ls)
    linux-vdso.so.1 (0x00007ffd5b3a0000)
    libcap.so.2 => /usr/lib/libcap.so.2 (0x00007f6bd398c000)
    libc.so.6 => /usr/lib/libc.so.6 (0x00007f6bd3780000)
    /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f6bd39e5000)

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

#236

Post by YoshiRulz »

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?

Does this happen on Windows too? The reason it happens on Linux is because every game ran via Proton/WINE gets its own virtual C: drive.

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

#237

Post by xorcist »

kentonv wrote: post #143
rwmj wrote: post #106

Earlier quoted context omitted.

That's why distros ask you to provide just the sources and we'll do the packaging work for you. The upstream developers shouldn't need to provide packages for every distro. (Of course you can help us downstream packagers by not having insane build requirements, using semantic versioning, not breaking stuff randomly etc).

This is only realistic for established applications with large userbases. For new or very niche apps, distros are understandably not going to be very interested in doing this work. In that case the developer needs to find a way to distribute the app that they can reasonably maintain directly, and that's where containers or statically-linked binaries are really convenient.

This is not grounded in reality. Look at popcon or something like it. It is a nearly perfect "long tail" distribution. Most software is niche, and it's packaged anyway. It's helped by the fact that the vast majority of software follows a model where it is really easy to build. There are a lot more decisions to take with something like Chromium, which perhaps ironically is also the type of software which tends to package its own dependencies.

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

#238

Post by YoshiRulz »

lloeki wrote: post #43
ghotli wrote: post #22

Earlier quoted context omitted.

Agreed, if the binary is statically linked. If you run `file` on the output from that and it shows 'dynamically linked' then you're playing games with porting over libraries, changing the library loading path, or just going full chroot like linux from scratch does with the bootstrapping part of the install. I find static binaries simplest to work with in that context but agreed I use that pattern too with docker and…

In a way, that's what Nix sets out to do, isolating even dynamically linked libraries: if two derivations depend on the same shared lib derivation then it's reused, if not then they don't conflict. Each leaf derivation can be handled completely independently of the others, and independently of the original system†. And then when Nix† is not an option at runtime, dockerTools†† can build a Docker image to do the minimi…

You've missed nix-bundle and pkgsStatic, which are much closer to the above idea re: copying to another machine.

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

#239

Post by xorcist »

IshKebab wrote: post #222
palata wrote: post #180

Earlier quoted context omitted.

> Software depending on versions of libraries that are newer than the latest version available on the distro you have to use (cough RHEL 8). That is a fair point, but it raises a question: if you absolutely need to use software that is not packaged by your distro of choice and that you cannot package yourself (are you sure you can't maintain a "community" package yourself with RHEL?), maybe you don't want that distro…

> maybe you don't want that distro Well I definitely don't want RHEL 8 but unfortunately I have to use it because some software I use requires it (RHEL 9 doesn't have old enough versions of some libraries) or is only certified on it (this is for work). But even if I was using a more modern distro, none of them have all software packaged. And no I obviously don't want want to become a packager. Some of the software I…

With traditional Linux distributions like Red Hat, you can sometimes take a package from a newer release (or something like Fedora) in source form and rebuild it for your release. When it works, it's literally just one command, which does everything to give you a binary package. If there is some problematic patch, you can often take it out, but also put in patches from the old version. It's usually documented enough to make it obvious.

It's usually straightforward with end user applications, such as bash or git or ruby. Things more likely to be tied to the rest of the operating system, such as SELinux or PAM, are less likely to work. If there are dependencies to things that is release dependent, it's not worth the bother.

Maybe you can argue you don't want to "become a packager", but someone has already done the work for you and you don't need more than superficial knowledge about the system to do it. In most distributions, source packages aren't harder to install than binary packages.

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

#240

Post by YoshiRulz »

dayjaby wrote: post #129
azornathogron wrote: post #89

Earlier quoted context omitted.

I'm no expert, but as an interested amateur I thought the Linux kernel could already be built reproducibly? There is some documentation at least... and I know several Linux distributions have been working on reproducible builds for a long time now - I'd be surprised if there hasn't been good progress on this. https://www.kernel.org/doc/html/latest/kbuild/reproducible-b...

In container context I've heard a definition of "100% reproducible" that means even file timestamps are 100% the same. Like your entire build is bit-by-bit precisely the same if you didn't modify any source. Not sure if that's what they mean here.

This is https://reproducible-builds.org/docs/source-date-epoch/
Post reply on HN