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

181–190 of 288 posts

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

#181

Post by i-use-nixos-btw »

chaxor wrote: post #160
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 has decentralized caching and memorizing?

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.

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

#182

Post by zaphar »

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…

If Linux dependency management works well in theory but not in practice then it doesn't work. It works in nix because it can literally use multiple minor versions of a library when it needs to with no problem. Most distro's can't or won't do that.

You can call it malpractice but it's not going to stop so in practice you need a way to deal with it.

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

#183

Post by palata »

zaphar wrote: post #179
palata wrote: post #168

Earlier quoted context omitted.

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

> Yep, the dev(s) of libA should learn good practice. But they didn't and app1 and app2 still have the problem.

Sure :-). I just find it sad that app1 and app2 then use the bad libA. Of course that is more productive, but I believe this is exactly the kind of philosophy that makes the software industry produce worse software every year :(.

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

#184

Post by mike_hock »

Rochus wrote: post #12

Interesting, but what is the use case? What is the advantage of using the croc C compiler instead of e.g. TCC? I wasn't aware of Netsurf ( https://www.netsurf-browser.org/); this is really amazing. But it seems to use Duktape as the JS engine, so performance might be an issue.

https://www.netsurf-browser.org/documentation/

Every single link on that page is dead.

https://www.netsurf-browser.org/about/screenshots/

Judging by the screenshots, it can render BBC, its own website, and Wikipedia. Well, it might be able to render others, we just can't tell from the shots. But we can tell those three websites work with all sorts of different window decorations.

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

#186

Post by palata »

tyingq wrote: post #167
chaxor wrote: post #164

Earlier quoted context omitted.

I'm not versed in this, so apologies for the stupid question, but wouldn't statically linking be more secure, if anything? Or at least have potentially better security? I always thought the better security practice is statically linked Go binary in a docker container for namespace isolation.

If there is a mechanism to monitor the dependency chain. Otherwise, you may be blissfully unaware that some vulnerability in libwhatever is in some binary you're using. Golang tooling provides some reasonable mechanisms to keep dependencies up to date. Any given C program might or might not.

> If there is a mechanism to monitor the dependency chain.

So that would not be less secure, but it would also not make it more secure than dynamic linking with a good mechanism, right?

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

#187

Post by palata »

zaphar wrote: post #182
palata wrote: post #175

Earlier quoted context omitted.

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

If Linux dependency management works well in theory but not in practice then it doesn't work. It works in nix because it can literally use multiple minor versions of a library when it needs to with no problem. Most distro's can't or won't do that. You can call it malpractice but it's not going to stop so in practice you need a way to deal with it.

Well, by calling it "malpractice", I say that it works for "true professionals". Then we could say that "it doesn't work in practice if people who don't know what they are doing cannot use it", of course.

The question then is where we want to put the bar. I feel like it is too low, and most software is too bad. And I don't want to participate in making tooling that helps lowering the bar even more.

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

#188

Post by zaphar »

palata wrote: post #183
zaphar wrote: post #179

Earlier quoted context omitted.

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…

> Yep, the dev(s) of libA should learn good practice. But they didn't and app1 and app2 still have the problem. Sure :-). I just find it sad that app1 and app2 then use the bad libA. Of course that is more productive, but I believe this is exactly the kind of philosophy that makes the software industry produce worse software every year :(.

I used to think the same. But after nearly 30 years of doing this. I no longer think that people will meet the standard you propose. You can either work around it or you can abandon mainstream software entirely and make everything you use bespoke. There are basically no other choices.

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

#189

Post by moffkalast »

palata wrote: post #168
moffkalast wrote: post #124

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

Wishing that all people will be smart and always do the correct thing is setting yourself up for madness. The dependency system needs to be robust enough to endure a considerable amount of dumbfuckery. Because there will be a lot of it.

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

#190

Post by chaxor »

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

Earlier quoted context omitted.

Nix has decentralized caching and memorizing?

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 using the software (who downloaded the ETL database).

That way you save compute and time.

Post reply on HN