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

251–260 of 288 posts

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

#251

Post by palata »

jcelerier wrote: post #245
palata wrote: 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…

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

> How?

Well you build OpenSSL as a static library, and you use that...

> Take for instance OpenSSL mentioned above.

However for something like OpenSSL on a distro like Debian, I really don't get why one would want it: it is most definitely distributed by Debian in the core repo. But yeah, I do link OpenSSL statically for Android and iOS (where anyway the system does not provide it). That's fairly straightforward, I just need to build OpenSSL myself.

> My requirement is that I do only one build

You want to make only one build that works with both OpenSSL 1 and OpenSSL 3? I am not sure I understand... the whole point of the major update is that they are not compatible. I think there is fundamentally no way (and that's by definition) to support two explicitly incompatible versions in the same build...

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

#252

Post by palata »

TimeBearingDown wrote: post #249
palata wrote: post #228

Earlier quoted context omitted.

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

Yeah I do agree, I find Arch's PKGBUILDs and Alpine's APKBUILDs much easier to write than e.g. a debian package. Not that the debian package is impossible, but it's not as straightforward.

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

#253

Post by palata »

IshKebab wrote: post #243
palata wrote: post #228

Earlier quoted context omitted.

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

It is pretty obvious indeed, coming from what I get is your point of view. You seem to believe that you have to become a package maintainer for all the dependencies of the software you want to run. But I think you have this wrong.

Take it like this: in the current state, I am struggling to find a single interesting library for which I could become a package maintainer for my non-mainstream Linux distro, because there always exists one. Maybe not in the core repo, maybe only in the community repo. But still: I don't maintain a single package today, because I haven't found one that I use and that it not already maintained by somebody else.

Really, if you decide to create packages for all the dependencies of the software you want to run, congratulations: you have just created a new distro from scratch. But even most new distros don't do that :-).

In other words, there are way more developers than libraries that are worth being depended on. So even if we wanted to, not everybody can maintain a single package. There are just not enough packages out there for that, by very, very far.

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

#254

Post by xenophonf »

eek2121 wrote: post #214
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.

As an aside, emoticons work just fine. ;)

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

#255

Post by Qwertious »

Koshkin wrote: post #134
MuffinFlavored wrote: post #125

Earlier quoted context omitted.

> I cant speak much about the system, it just works, What systems don't just work by this criteria? Just because something is statically linked vs dynamically linked, as long as you are within "normal expected operating conditions", does it really make a "just works vs doesn't work" quality difference?

Read after the comma: > it just works, but...

...but the community was really nice.

That still doesn't tell us how low the parent commenter's standards for "just works" are. It's irrelevant.

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

#256

Post by Qwertious »

TimeBearingDown wrote: post #250
TimeBearingDown wrote: post #248

Earlier quoted context omitted.

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

That's the same as the first link in your previous comment. Did you manage to edit it after all?

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

#257

Post by o11c »

yjftsjthsd-h wrote: post #220
o11c wrote: post #53

Earlier quoted context omitted.

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.

The standard is uselessly incomplete and vague.

There are places where MUSL implements a broad set of GLIBC extensions in order to actually be useful. However, it does not indicate that in any way, and sometimes violates the conditions that GLIBC documents. This requires workarounds.

There are places where MUSL implements a standard interface in a particular way. If you're lucky, this "just" means giving up on performance if you don't know you're using MUSL.

Sometimes MUSL implements its own ABI-incompatible extensions. The time64 transition, for example, is a huge mess regardless, but musl provides no blessed way to figure out what's going on. The only reason it's not an even bigger disaster is that almost nobody uses musl.

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

#258

Post by SAI_Peregrinus »

palata wrote: post #175
josephg wrote: post #101

Earlier quoted context omitted.

Yes, if someone actually did dependency management in Linux properly then I agree - dynamic linking would be fine. It works pretty well in Nixos as I understand it. But it’s called dependency hell for a reason. And the reason is almost no operating systems handle C dependencies well. There’s always weird, complex, distribution specific systems involving 18 different versions of every library. Do you want llvm18 or ll…

> If Linux dependency management worked well, there would be no need or appetite for docker. I kindly disagree here. Linux dependency management does work well. The problem is the bad libraries that don't do semver properly, and the users who still decide to use bad libraries. If people stopped using libraries that break ABI compatibility, then the authors of those libraries would have to do it properly, and it would…

Semver only controls API compatibility, not ABI compatibility. You can make an ABI break in a Semver minor (or patch) version update. Semver is nice, but it's not enough for ensuring compatibility when dynamic linking.

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

#259

Post by manmal »

TimeBearingDown wrote: post #247
manmal wrote: post #221

Earlier quoted context omitted.

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.

Yes, announced last June, Xcode 15

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

#260

Post by chaxor »

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

Earlier quoted context omitted.

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

I see. Perhaps the added benefit I am trying to create with this other system is that specifying remote locations isn't necessary, and is just inherited as the distributed network. Anytime anyone runs it, they're added to the network, so it scales with the number of users.
Post reply on HN