There's a (dead) comment lamenting that you can't access Github with javascript turned off. The Oasis repo seems to be mirrored on sourcehut, though, so if that's more acceptable:
Oasis – a small, statically-linked Linux system
171–180 of 288 posts
Re: Oasis – a small, statically-linked Linux system
#172Earlier 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.
> 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.
There are various kinds of "dependency hell". To be honest I can't think of any that are due to not doing semver properly. Usually it's:
1. Software depending on versions of libraries that are newer than the latest version available on the distro you have to use (cough RHEL 8). E.g. this very day I ran into a bug where some Asciidoctor plugin craps out with an error because my version of Ruby isn't new enough. Ruby's advice for how to install Ruby is "use your package manager; you will get an old version btw fuck you".
90% of the time it's bloody glibc. Every Linux user has run into the dreaded glibc version error dozens of times in their career.
2. Software that can't install multiple versions of the same package, leading to diamond dependency issues. Python is very bad for this.
Re: Oasis – a small, statically-linked Linux system
#173Earlier 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.
I agree with everything you said up to this. We're talking about a software library, for which the user is a software developer. IMO a software developer should be able to package a library for their own distro (then they can share that package with their community and become this package's maintainer).
As the developer of an open source library, I don't think that you should distribute it for systems that you don't use; someone else who uses it should maintain the package. It doesn't have to be a "distro maintainer". Anyone can maintain a single package. I am not on a very mainstream distro, and I still haven't found a single package that I use and is not already maintained by someone in the community (though I wish I did, I would like to maintain a package). My point is that it really works well :-).
I disagree with the idea that we should build a lot of tooling to "lower the bar" such that devs who don't know how to handle a library don't have to learn how to do it. They should learn, it's their job.
For proprietary software, it's admittedly a bit harder (I guess? I don't have much experience there).
Re: Oasis – a small, statically-linked Linux system
#174Earlier quoted context omitted.
You can still call dlopen from your static binary, if you really want to.
I tried to do this recently at $DAYJOB, but when you statically link a binary with musl, the dlopen() you get is a no-op: https://github.com/bpowers/musl/blob/master/src/ldso/dlopen.... I tried to hack in a copy of the musl's dynamic loader (and also from old uclibc). But it took a few hours and my only result was segfaults. Do you have any pointers on making this work?
Have you tried it with glibc? It's harder to build static binaries with it, but it's still possible, and it may work.
To debug your problem, do you have a minimal example at your fingertips to try? Just a "hello world" dynlib that is called from a static program that doesn't do anything else.
Re: Oasis – a small, statically-linked Linux system
#175Earlier quoted context omitted.
As far as I can see, it would be unwise to roll back 30 years of (Linux) systems building with dynamic linking in favor of static linking. It mostly works very well and does save some memory, disk, and has nice security properties. Both have significant pros and cons. I've been thinking (not a Linux expert by any means) the ideal solution would be to have better dependency management: I think a solution could be if s…
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 work. The reason it doesn't work is really just malpractice.
Re: Oasis – a small, statically-linked Linux system
#176Earlier 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…
This isn't really an "operating system" problem. Particularly in the open-source world, there are a number of fairly core libraries that refuse to provide any kind of API compatibility. Then, when there are a couple dozen applications/etc that depend on that library, it's almost an impossible problem because each of those applications then needs to be updated in lockstep with the library version. There is nothing "cl…
> away from the distro, which should never really have been packaging applications to begin with.
I disagree here: the whole point of a "software distribution" is to "distribute" software. And it does so by packaging it. There is a ton of benefit in having distro/package maintainers, and we tend to forget it.
Re: Oasis – a small, statically-linked Linux system
#177Earlier 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/
Exactly this. Windows apps aren't distributed as Docker images. Guess why...
Well nothing prevents you from dynamically linking only glibc and statically linking everything else, without Docker at all.
The fact that people distribute their app with a full rootfs in a Docker containers says more about the fact that they don't know how to link stuff properly, IMHO.
Re: Oasis – a small, statically-linked Linux system
#178Earlier 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.
Weirdly enough I came across a blog post last week that talked about exactly this. https://j.phd/nix-needs-a-native-build-system/
Nix can be used as a build system in the same way that bazel can. It already has all of the tooling - a fundamental representation of a hermetic DAG, caching, access to any tool you need, and a vast selection of libraries.
The only catch is that no one has used it to write a build system for it in public yet. I’ve seen it done in a couple of companies, though, as using Nix to only partially manage builds can be awkward due to caching loss (if your unit of source is the entire source tree, a tiny change is an entirely new source).
Re: Oasis – a small, statically-linked Linux system
#179Earlier quoted context omitted.
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.
Yep, the dev(s) of libA should learn good practice. But they didn't and app1 and app2 still have the problem. Static linking solves it for them more reliably than trying to get the dev of libA to "git gud". Much of the desire to statically link binaries comes from this specific scenario playing out over and over and over.
Heck for a long time upgrading glibc by a minor version was almost guaranteed to break your app and that was often intentional.
Re: Oasis – a small, statically-linked Linux system
#180Earlier 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.
There are various kinds of "dependency hell". To be honest I can't think of any that are due to not doing semver properly. Usually it's: 1. Software depending on versions of libraries that are newer than the latest version available on the distro you have to use ( cough RHEL 8 ). E.g. this very day I ran into a bug where some Asciidoctor plugin craps out with an error because my version of Ruby isn't new enough. Ruby…
> 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.
Different distros come with different goals. If you take a "super slow but secure" distro, it will be slow and secure. If you take a rolling distro, you get updates very quickly but it has drawbacks. It depends on the use-case, but going for a "slow and secure" distro and then building tooling to work around that choice ("nevermind, I'll ship new and less mature software anyway, statically linked") seems to defeat the purpose of the distro... right?