Live data from Hacker News

Oasis: a small statically-linked Linux system

github.com

21–30 of 169 posts

Re: Oasis: a small statically-linked Linux system

#21

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.

There's no reason that there needs to be such extremes as either all statically linked or all dynamically linked. History has proven that dynamic linking causes a large number of headaches, and static linking has drawbacks as well. 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.

The problem is that Linux userspace has historically payed little attention to backwards compatibility and has no definition of "base system". Consequently, Linux distros tend to be their own little mutually-incompatible worlds where you either play with the package manager/repo combo you have or jump through hoops and dodge conflicts to try to get anything to work.

Oasis is interesting in this way: there are no conflicts, there is no package manager, and the binaries should work anywhere provided the arch is the same.

Re: Oasis: a small statically-linked Linux system

#22

This would be 10x faster and smaller if they just built these components into Busybox. Package management, library management, etc are solved problems when it comes to Linux distros. The only practical improvement you can make is containers (or similar). Static binaries cannot deal with external dependencies, and many applications require external dependencies that cannot be compiled in . But even by trying to compil…

> Package management, library management, etc are solved problems when it comes to Linux distros. The only practical improvement you can make is containers (or similar).

To me this basically reads as "we added a bunch of complexity on top of the problem without actually solving it". Package managers are supposed to prevent conflicts and manage giant dependency graphs, but they're so shit at doing that while actually allowing people to use whatever software they want that we've invented containers to keep everything separate again.

Re: Oasis: a small statically-linked Linux system

#23

Earlier quoted context omitted.

I read it. It does not say "why" anywhere.

Why care about "why" when there is "why not".

> Why care about "why" when there is "why not".

Life is short. As I've gotten older, I've seen the importance on focusing my time and attention on what matters.

So, personally, I'd want to know "why" so I could decide where the project ranks in my priorities.

Re: Oasis: a small statically-linked Linux system

#24

This seems to "statically link" binaries in the sense that each program it ships with is a standalone binary. Does anyone know whether it's possible to truly statically link an entire Linux install, in the sense that the whole system is a single statically linked file including the kernel, display manager, web browser, etc so that link-time optimization can deduplicate code across the entire system?

I am not sure what you mean. The Linux kernel has dynamically loaded modules but you can build modules as statically part of the kernel. 'Y' instead of 'M' in the config. It doesn't make sense to "statically link" a kernel to a program, or multiple programs together, which I read your comment to suggest. That would be a different thing than the term "statically link" refers to.

> It doesn't make sense to "statically link" a kernel to a program

That's kinda what a Unikernel is.

Re: Oasis: a small statically-linked Linux system

#25
post #2

Is "velox" (mentioned in the article) a display server or a window manager?

As far as I understand it, that distinction doesn't really make sense with Wayland. The display server / compositor is also the "window manager".

Client applications have their own buffer they draw on, and they negotiate the details of its handling with the compositor which manages the composition of all client buffers (and other data, such as input events) to form the final result.

I suppose it's technically possible to write a protocol that involves a third client process (a "window manager") to draw something around another client's buffer and tell the compositor how to position things, but that sounds like a nightmare to synchronize.

Re: Oasis: a small statically-linked Linux system

#26

This seems to "statically link" binaries in the sense that each program it ships with is a standalone binary. Does anyone know whether it's possible to truly statically link an entire Linux install, in the sense that the whole system is a single statically linked file including the kernel, display manager, web browser, etc so that link-time optimization can deduplicate code across the entire system?

I am not sure what you mean. The Linux kernel has dynamically loaded modules but you can build modules as statically part of the kernel. 'Y' instead of 'M' in the config. It doesn't make sense to "statically link" a kernel to a program, or multiple programs together, which I read your comment to suggest. That would be a different thing than the term "statically link" refers to.

I think they might be referring to a unikernel.

https://en.m.wikipedia.org/wiki/Unikernel

In userspace, you can do what busybox does and link a bunch of programs together with a single main function that decides which program to actually run.

Re: Oasis: a small statically-linked Linux system

#27

Would be cool to get a bit of a "why this matters" intro on repos like this. I clicked through the details, but left wondering if I have any potential use for this. Can I compile this onto a USB stick and use it as a throw-away boot Linux for maintenance tasks? Can I cross-compile this for embedded devices? What is the statically-linked advantage here? Not trying to minimize the effort, I would actually love to see m…

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.

Me too, but I'm not sure this project brings us closer to that goal.

I don't need the base OS to be statically linked—in fact, that's where static vs dynamic linking matters least, because it all comes preinstalled. What I want is for everything else which I may want to install on top to be available as statically-linked binaries.

Re: Oasis: a small statically-linked Linux system

#28

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.

> I prefer to have things clearly separated in functionality and easily upgradeable.

What is your thinking here? Are you talking about a use case where you have an application that uses a library and a bug fix is issued for that library, so you want to just get the new .so for the library and have the application use it? That feels like a niche use case to me. Maybe there is another benefit, or this use case is more common than I realize. I'd be interested in further opinions/info.

Re: Oasis: a small statically-linked Linux system

#29

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.

There's no reason that there needs to be such extremes as either all statically linked or all dynamically linked. History has proven that dynamic linking causes a large number of headaches, and static linking has drawbacks as well. 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 b…

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

But isn't this the exact opposite of what Oasis provides?

Re: Oasis: a small statically-linked Linux system

#30

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. Me too, but I'm not sure this project brings us closer to that goal. I don't need the base OS to be statically linked—in fact, that's where static vs dynamic linking matters least , because it all comes preinstalled. What I want is for everything else which I may want to install on top to be available as statica…

Since most common applications have moved to the web, and the biggest Linux end user deployment by far, Android, was created from fresh beginnings, the idea of the user being concerned with minutia of binaries is already far along a long road to the grave.
Post reply on HN