Live data from Hacker News

Oasis: a small statically-linked Linux system

github.com

81–90 of 169 posts

Re: Oasis: a small statically-linked Linux system

#81

All README's should begin with some sort of mission statement. What is the goal or reason for the existence of this? I can imagine some, but I am not sure where this is heading.

It exists because I wanted a complete system where I could easily experiment with various minimal/alternative software. I wanted this so that I could easily understand and hack on any component without spending weeks/months familiarizing with massive code-bases and waiting for things to compile.

I made it for myself, and honestly that's all there is to it. I tried to describe the things that make oasis unique in the README, and I think some of those are pretty cool, but I'm not trying to market this to anyone. If it doesn't sound interesting to you, then feel free to disregard the project.

Re: Oasis: a small statically-linked Linux system

#82
post #75

Earlier quoted context omitted.

If you know of such a utility I'd like to see it, because I've looked and never found it. The closest I've seen are things like AppImage.

Shell scripting and ld tools should allow you to make that yourself. EDIT: people are apparently entitled to solutions for their problems... > Care to elaborate? > Show us a script then! Your internet fame awaits. I'm not interested in fame, or in reinventing the wheel. Apparently, you are unfamiliar with this process, so TLDR: there are basically 2 approaches, in order of complexity: 1. working with ldtools or 2. ru…

Show us a script then! Your internet fame awaits.

Re: Oasis: a small statically-linked Linux system

#83
post #55

Does statically linking everything not lead to much higher disk usage, espcially when you have thousands of binaries? Drew Devault has an analysis[0] that appears to claim otherwise. [0] https://drewdevault.com/dynlib.html

The idea with oasis is to choose smaller software with fewer dependencies that offsets the slightly higher disk usage, as well as to deliberately not have thousands of binaries.

Re: Oasis: a small statically-linked Linux system

#84

Earlier quoted context omitted.

As someone who uses linux casually, I often experience pain when I download a program, try to run it, and it fails because some dependency is not installed or is not the right version. So you try to figure out how to install it and it in turn needs a couple of things. All of this works fine if whatever package manager your distro uses has the program you want, but the package managers don't have evertying! So I'd lov…

> So I'd love an ecosystem where things tend to be statically linked unless there is a good reason not to. Well, every time there is a bug fix in one of your dependencies you/your distribution would have to recompile everything that depends on it. Which will use quite some resources. So to actually use this you would have to reinstall (nearly) all programs once a week or so (no matter if source or binary distribution…

You won't have to recompile everything if you cache your build artifacts (e.g., object files); you'll only have to relink which is quite a lot better.

Re: Oasis: a small statically-linked Linux system

#85
post #49

Earlier quoted context omitted.

I would be surprised if there was not a way to take a dynamic executable, "add in" all the required libraries, and return a fat static executable

If you know of such a utility I'd like to see it, because I've looked and never found it. The closest I've seen are things like AppImage.

It exists. I came across at least one such project last year, but I don't recall the name. :(

Re: Oasis: a small statically-linked Linux system

#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 each lua script. It looks quite maintenance-intensive. I was almost hoping for some kind of meta-build system which could parse automake etc. files and hoist the dependency graph into the main system build.

Re: Oasis: a small statically-linked Linux system

#87
post #80

Having grown up on a static linked world, where dynamic linking was a thing of big iron computers that we dreamt about being able to do in home computers this trend of static linked compiled stuff feels somehow a tragedy of some sort. How bad have we gone, that is now trendy to return to the days of static compiled binaries and process IPC to achieve any sort of dynamism.

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 do understand some people who really loves their package managers and knowing that their updated system will be secure, but many people are even more into shiny new things than me and if anything has held back Linux adoption on the desktop I'd probably point to this second to drivers and configuration troubles historically.

Am I alone in this? I doubt it if we consider the existence of Docker, Snap packages and similar things.

Re: Oasis: a small statically-linked Linux system

#88

Earlier quoted context omitted.

Yes, I know that it's NOT possible. Anything that uses the same libraries, e.g. GTK+, will end up calling gtk_init() multiple times. Callback functions with the same names will collide at link-time. Despite the madness of the code that would be generated if the compiler allowed it, since it doesn't, you can expect a list of linker errors so long, that you can go to bed and wake up in the morning and it's still spewin…

It could be done. Obviously you would only run one of the main functions (via a wrapper) per process invocation and you would need to rename conflicting global symbols at some point before the link step, but this is basically how tools like busybox work. If the application uses global constructors or init functions then those would require special handling since they bypass main—C tends to work better than C++ in thi…

It could be done if you heavily patched everything you linked in, or developed an entirely new compiler, or both, but as-is, no.

Re: Oasis: a small statically-linked Linux system

#89

Honestly, I'm team dynamic linking. I prefer to have things clearly separated in functionality and easily upgradeable. Statically linking all the OS utilities to their dependency libraries, over and over again? Dear god that sounds awful.

> Statically linking all the OS utilities to their dependency libraries, over and over again? Dear god that sounds awful.

Just curious, why does that sound awful to you? Are you worried that it will take a long time to relink the binaries? The oasis build system is incremental, so updates to a library only involve relinking dependent binaries, which is quite fast. Even a full rebuild from scratch only takes a few minutes (assuming you have the sources downloaded already).

If it's just the idea of relinking all the dependencies over and over again, note that with dynamic linking you do this at runtime every time you execute a binary.

Re: Oasis: a small statically-linked Linux system

#90
post #80

Having grown up on a static linked world, where dynamic linking was a thing of big iron computers that we dreamt about being able to do in home computers this trend of static linked compiled stuff feels somehow a tragedy of some sort. How bad have we gone, that is now trendy to return to the days of static compiled binaries and process IPC to achieve any sort of dynamism.

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 not everyone is speaking the same version.

Post reply on HN