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

241–250 of 288 posts

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

#241

Post by scns »

ComputerGuru wrote: post #42
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.

Speaking from heavy experimentation and experience, [0] glibc has some more optimized routines but musl has significantly less bloat. If you are haphazardly calling libc functions left and right for everything and have a generally unoptimized code base, your code may fare better better with glibc. But musl’s smaller codebase is a win for faster startup and micro optimizations otherwise - and that’s without lto where…

> in addition to its direct usage of AVX2 functions and types, it also made a call to the BZHI and LZCNT intrinsics/asm instructions – which rustc/llvm do not recognize as being supported via the avx2 feature! So although (to the best of this developer’s knowledge) there does not exist a processor on the face of this planet that supports AVX2 but doesn’t support BZHI and LZCNT

Looks like a "bug" or better put needed enhancement to LLVM.

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

#242

Post by YoshiRulz »

notfed wrote: post #81

> Fast builds that are 100% reproducible. It's unclear to me what "100%" refers to here, but surely it does not include the Linux kernel or drivers? (I've recently read conversations about how difficult this would be.)

I expect it refers to the proportion, weighted by filesize, of programs that are byte-for-byte reproducible across machines. (The assumption being that to take the same measurement in a dynamically-linked context would result in a number less than 100% due to machines having different copies of some libs.) In other contexts, it might simply be a proportion of whole packages, for example Arch Linux' core package set is 96.6% reproducible[1] (=256/(256+9)).

The Linux kernel's lack of a stable ABI (specifically [2]; many userspace APIs are stabilised) doesn't mean individual revisions can't be built reproducibly.

[1]: https://reproducible.archlinux.org

[2]: https://en.wikipedia.org/wiki/Linux_kernel#In-kernel_ABI

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

#243

Post by IshKebab »

palata wrote: post #228
IshKebab wrote: post #222

Earlier quoted context omitted.

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

> And no I obviously don't want want to become a packager. That's where I disagree. It's not that hard, and if more people did it, more software would be packaged. Actually I am yet to find a library that I actually need and that is not already packaged and maintained by someone from the community. Then I could finally maintain one myself. To me, you're basically saying: "I don't want to learn and commit to maintain…

> That's where I disagree.

Well we'll have to agree to disagree on that, but I think if you told most people that the normal way to install third party software for Linux was to become a package maintainer they would rightly laugh you straight to the asylum.

> That's what I don't really get.

The reason is that Docker, Apptainer etc are much easier than creating packages for all the dependencies of the software I want to run. Multiplied by the number of distros I need to use. Pretty obvious no?

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

#244

Post by gallexme »

IshKebab wrote: post #161
i-use-nixos-btw wrote: post #153

Earlier quoted context omitted.

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.

Nix can do it incremental U could split it into multiple derivations which get built into one package For rust there ist the excellent https://crane.dev/index.html project

Or you can also go to the extreme and do 1:1 source to derivation mapping So for example if ur project has 100 source files it could be built from 100 derivations, the language/CLI tools are flexible enough for that

https://discourse.nixos.org/t/distributed-nix-build-split-la... https://discourse.nixos.org/t/per-file-derivations-with-c/19...

Don't know tho if there any well working smart nix tools which can make it well working /efficient, in theory it's very possible, just unsure about practicality/overheads

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

#245

Post by jcelerier »

palata wrote: post #166
StillBored wrote: post #151

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…

> Agreed, and that is already totally possible

How? Take for instance OpenSSL mentioned above. I have a software to distribute for multiple Debian versions, starting from Bullseye which uses OpenSSL 1.x and libicu67. Bookworm the more recent has icu72 and OpenSSL 3.x which are binary-incompatible. My requirement is that I do only one build, not one per distro as i do not have the manpower or CI availability for this. What's your recommendation?

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

#246

Post by TimeBearingDown »

rwmj wrote: post #144
kentonv wrote: post #143

Earlier quoted context omitted.

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 isn't really true, Fedora, Debian and Arch have huge numbers of packages, many very niche. You might well need to make the distro aware that the new program exists, but there are established routes for doing that.

Arch particularly has the user repository where anyone can submit a package and vote on the ones they use most often to be adopted into the community repository, yes.

It’s a great way to start contributing to the distribution at large while scratching an itch and providing a service to individual projects.

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

#247

Post by TimeBearingDown »

manmal wrote: post #221
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…

Apple has been pushing dynamic libraries for a while, but now realized that they really like static linking better. The result is they found a way to convert dynamic libraries into static ones for release builds, while keeping them dynamic for debug builds: https://developer.apple.com/documentation/xcode/configuring-...

Very interesting, as of Xcode 15? I wonder if anyone has explored doing this on Linux, and hope this gets a little more attention.

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

#248

Post by TimeBearingDown »

soulofmischief wrote: post #170
palata wrote: post #154

Earlier quoted context omitted.

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.

I’m pretty sure GPU passthrough does work in Qubes HVMs, although I haven’t tried it myself. Here are three quick and recent tutorials I found including one with a newer VirtualGL approach that offloads work instead of passing the entire card.

https://neowutran.ovh/qubes/articles/gaming_windows_hvm.html

https://forum.qubes-os.org/t/nvidia-gpu-passthrough-into-lin...

https://forum.qubes-os.org/t/seamless-gpu-passthrough-on-qub...

Yes, the passthrough is probably a huge avenue for attacks. Possibly VirtualGL too, I know less about that.

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

#249

Post by TimeBearingDown »

palata wrote: post #228
IshKebab wrote: post #222

Earlier quoted context omitted.

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

> And no I obviously don't want want to become a packager. That's where I disagree. It's not that hard, and if more people did it, more software would be packaged. Actually I am yet to find a library that I actually need and that is not already packaged and maintained by someone from the community. Then I could finally maintain one myself. To me, you're basically saying: "I don't want to learn and commit to maintain…

I agree with essentially all of this, and I really think the barrier to entry for packaging should be lower. It was deeply helpful to me while learning Linux to be able to write a Bash PKGBUILD, maybe 20-40 lines, to have that clear structure and ease my own update process, while also making it available to others on the Arch User Repository and learning from comments others left. These days I can whip up a simple PKGBUILD for a simple project I discover in just a minute or three, and it led me to so much experience handling build issues and software dependency structure.

I would leap for joy to see Red Hat or Debian or even Gentoo make inroads here, but I haven’t looked closely enough and recently at Debian, and .ebuild files hurt my brain. I do believe I recall Gentoo requiring more work to get my packages available and listed anywhere.

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

#250

Post by TimeBearingDown »

TimeBearingDown wrote: post #248
soulofmischief wrote: post #170

Earlier quoted context omitted.

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

I’m pretty sure GPU passthrough does work in Qubes HVMs, although I haven’t tried it myself. Here are three quick and recent tutorials I found including one with a newer VirtualGL approach that offloads work instead of passing the entire card. https://neowutran.ovh/qubes/articles/gaming_windows_hvm.html https://forum.qubes-os.org/t/nvidia-gpu-passthrough-into-lin... https://forum.qubes-os.org/t/seamless-gpu-passthrou…

One more, site won’t let me edit.

https://neowutran.ovh/qubes/articles/gaming_windows_hvm.html

Post reply on HN