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

161–169 of 169 posts

Re: Oasis: a small statically-linked Linux system

#161

Post by SQLite »

smilliken wrote: post #158
0xbadcafebee wrote: post #155

Earlier quoted context omitted.

I worked for a company that built the same thing in the mid-2000s, and it did not solve all dependency issues, because there's multiple kinds of issues. They're actually kind of unsolveable. I list some of the reasons here https://gist.github.com/peterwwillis/e96854532f471c739983c0b...

Thanks for sharing. Agreed that runtime dependency conflicts are unavoidable for most programming languages. Your example of sqlite database format conflicts is also a good one. I definitely won't claim that nix has solved runtime dependency conflicts, but it does decisively solve build-time conflicts. Similar to containers like you describe, but reproducible and don't require storing and shipping opaque binary image…

All versions of SQLite from 3.0.0 (2004-06-18) through 3.34.0 (the latest) use the same database file format. So if two applications use different versions of SQLite, it shouldn't matter. The database file will be the same.

Now, if one application uses a more recent version of SQLite and also makes use of some new feature (say, for example, generated columns which were added in release 3.31.0) then that might result in a database file that is unreadable by older versions since the older version won't be able to interpret the generated column syntax. But if you assume that all different versions of SQLite that you use have support for all of the features used in the database file (a reasonable assumption in most cases) then the database files are completely portable across versions. Different versions of SQLite can read/write the same database file concurrently. And newer versions of SQLite are always able to read/write databases created by older versions of SQLite, without exception or precondition.

So perhaps the "sqlite format conflict" example was not the best, in as much as it will always work as long as the package manager installs the most recent version of SQLite.

All of the above is also true for the API.

Re: Oasis: a small statically-linked Linux system

#162

Post by kaba0 »

colonwqbang wrote: post #86

I find the build system more interesting than the "statically linked" part. Incremental compilation across your whole system is something we should have nailed by now, I think. The best I've seen is something like openembedded, where you get per-package (but not per-file) dependency tracking across the whole system. I was ever so slightly disappointed to see how manual the packaging is, with every .c file listed in e…

Honestly, DLL hell is currently only a solved problem by nix and guix and at this point onwards, I don’t see much point in not porting everything over to the nix way of maintaining packages.

Re: Oasis: a small statically-linked Linux system

#163

Post by jcelerier »

thekyle wrote: post #157
jcelerier wrote: post #149

Earlier quoted context omitted.

there are plenty of installers of archlinux - I use https://anarchyinstaller.org/ for instance

But do any of those come with the ISO available at https://www.archlinux.org/download/ ? I don't see how you can say something "just works" if you have to go out of your way to choose an installer for it.

ArchLinux is not defined by the ArchLinux ISO ? it will be arch as long as it installs packages from the arch repos, which is what those installer do. So you just burn this iso to an usb and be happy: https://gitlab.com/anarchyinstaller/installer/-/releases

Re: Oasis: a small statically-linked Linux system

#164

Post by anthk »

eeZah7Ux wrote: post #131
fmakunbound wrote: post #35

Ok maybe this is dumb question and is addressed somewhere: If a security problem is found, e.g. in muscl (the C lib), then is the user supposed to rebuild everything that statically linked it??

Yes, and this is why Linux distribution exist. Good luck maintaining 100.000 statically linked libraries embedded in 10.000 applications.

That's the point, you need less than 100.

A browser, cloc, sbase, ubase, X/Arcan, mpv, youtube-dl, ffmpeg, mocp, lynx/link, bitlbee, irssi and not much more.

On games, mednafen can emulate well a huge stack of systems, slashem/nethack is highly replayable and chocolate-doom has tons of PWADs (maps, levels and total conversions). Not the most modern gaming, but these are options to almost never be bored.

For everything else you can spawn an x86 vm with tinyemu and forget maintenance.

Re: Oasis: a small statically-linked Linux system

#165

Post by anthk »

mleonhard wrote: post #135
bityard wrote: post #50

Earlier quoted context omitted.

> That feels like a niche use case to me. I wouldn't call it a niche use case at all, it's exactly how the software for all major Linux and BSD operating systems are packaged and built. For example, when (not if) a vulnerability is found in OpenSSL, package maintainers just commit an update to the openssl package and users only have to download and install one package to patch their system against the vulnerability.…

When you rebuild the binaries that depend on the upgraded library, you can also run their tests and run automated analysis tools. This improves reliability. DLL loading is full of security risks. Static binaries are free of them. DLLs are compiled separately from the binaries that load them. Compilers cannot optimize code that calls into a DLL. Compiler optimizers are amazing these days. Compared to a separately opti…

I remember statically linked software on Linux (old one, such as Netscape, Soffice)... much faster on usage than LibreOffice today.

Also, on services you got a performance boost.

Re: Oasis: a small statically-linked Linux system

#166

Post by anthk »

remexre wrote: post #66
enriquto wrote: post #32

This makes me so happy! If static linking was ubiquitous, we could have avoided the complex craziness of docker and the like.

Well, you'd also need to fix Python (, Go, Ruby, JS, ...) packaging and delivery too...

>Go

Go is already static.

Re: Oasis: a small statically-linked Linux system

#167

Post by anthk »

qwerty456127 wrote: post #129
mforney wrote: post #125

Earlier quoted context omitted.

Yep, you can install firefox via pkgsrc or nix. Due to the complexity of the modern web browser and all of its dependencies, it is unlikely to ever be part of oasis itself.

Is a self-sufficient static build of Chromium or Firefox an impossible thing?

It's tedious and cumbersome to do so with C++, and with QT is a nightmare.

Re: Oasis: a small statically-linked Linux system

#168

Post by Subsentient »

AnIdiotOnTheNet wrote: post #78
Subsentient wrote: post #72

Earlier quoted context omitted.

>>There is a reasonable middle ground: base system functionality that is utilized by most software (stdlib, cryptography, networking, gui, etc) should be dynamic and everything else should be static I disagree, I tend to want the opposite. I want big, bloated libraries like Qt or Gtk or Boost to be dynamically linked, and OS facilities like libc to be statically linked.

> I want big, bloated libraries like Qt or Gtk or Boost to be dynamically linked These fall under "GUI" in the "base system" category in my opinion. > and OS facilities like libc to be statically linked. If you're not being sarcastic right now, I'm really curious as to your reasoning.

libc is much smaller than other libraries, and as another has pointed out, compiling it statically will get you only the symbols you actually use, so it doesn't even equal the total size of libc. Which makes more sense? Bloating your executable with ~100+MiB of Qt crap, or bloating it with 100KiB of libc symbols?

Re: Oasis: a small statically-linked Linux system

#169

Post by whizzter »

pjmlp wrote: post #90
whizzter wrote: post #87

Earlier quoted context omitted.

I think dynamic linking one of those ideas that looks neater on paper and therefore feels better but just fails in many ways in the real world (at least for statically compiled languages like C and C++). Personally i think at least half the times i really tried to use Linux i always wanted a new shiny version of some program at some point, this usually devolved into a more or less broken system due to dependencies. I…

Containers fulfil other purpose, and have existence in some form on mainframes and big UNIXes, because just using UNIX permissions is not enough to actually secure a process. They just happen to have been misused to workaround deficiencies on Linux software distributions. The only areas where I see a failure of dynamic linking is security, given the possible exploits of the host process. Even IPC comes to IPC hell if…

Sorry for the late reply but my point was more about user and developer experience (the end result of the system in place) vs the traditional sysadmin/poweruser view of packages among Linux users/distros where the security and interop details of systems matters more but is kind of in conflict (as a loose reference, think of the conflicing requirement origins of why shadow-IT exists).

Like as a user i don't really need to care if my Chrome browser uses a newer version of the V8 JS engine or libpng for security than for example my VS Code IDE (because that IDE instance isn't active on the hostile internet visiting "random" webpages).

Sure the browser will be more secure and if it was dynamically linked I'd get the benefits of having both upgraded at the same time, however it'd also require breaking changes to an cutting-edge program like Chrome/Chromium to bring all dependencies forward, maybe breaking programs like VSCode that aren't updated as frequently but has more or less the same dependencies. (Like in practice it seems like Ubuntu even uses a dummy Chromium package that just forwards the user to a snap package).

The way forward i think would be to bring some variant of sem-ver to the C/C++ world with a unified strategy to package management, but i don't have hopes of that ever happening.

Post reply on HN