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

141–150 of 288 posts

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

#141

Post by sylware »

stefan_ wrote: post #130
sylware wrote: post #122

For a real statically-linked linux system, the main issue is GPU support: you must relink all apps _really using_ a GPU, that to include the required GPU drivers. With sound, alsa, it is fine since there is IPC/shared-memory based mixing that whatever the playback/capture devices [dmix/dsnoop]. Static linking is reasonable. (pulseaudio[012] IPC interfaces are bloaty kludges, hardly stable in time, 0..1..2.., not to b…

To be fair ELF is complex mostly because of relocations, which are not purely to support shared libraries but also the nowadays ubiquitous PIE. But GPU drivers is a good point; I don't believe you can even statically link them today, you would only be statically linking a shim that tries to find the real driver at runtime.

I am exploring an executable file format of my own (excrutiatingly simple, basically userland syscalls) which is only PIE, and until now, the main real "issue" (not really) is actually the lack of support from compilers for static relative global data init (handled by ELF... which is not there anymore).

About the shared libs, well, they are the utility shared libs, and the system interface shared libs. With a mostly statically linked elf/linux distro, all the utility libs would be statically linked, and the system interface shared libs would be statically linked if they have an IPC/shared-mem interface. In the end, only the GPU driver is an issue, namely would stay a shared libs.

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

#142

Post by xiconfjs »

jackothy wrote: post #131
schemescape wrote: post #55

Does anyone know how big the base installation is? I couldn't find an answer anywhere, and the link to the QEMU image appears to be broken, currently. I'm curious how it compares to, say, Alpine with a similar set of packages.

I have an old (2020) .qcow2 lying around that's about 360MB

could you please upload it?

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

#143

Post by kentonv »

rwmj wrote: post #106
kentonv wrote: post #103

Earlier quoted context omitted.

Everything you describe already exists. Executables do list their dependencies, and we have well-defined conventions for indicating ABI breaks. It is entirely normal to have multiple major versions of a library installed for ABI compatibility reasons, and it is also entirely normal to expect that you can upgrade the dependencies out from under a binary as long as the library hasn't had an ABI break. The bigger depend…

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.

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

#144

Post by rwmj »

kentonv wrote: post #143
rwmj wrote: post #106

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

This isn't really true, Fedora, Debian and Arch have huge numbers of packages, many very niche. You might well need to make the distro aware that the new program exists, but there are established routes for doing that.

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

#145

Post by willy_k »

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.

Tangential, but the trailing “/“ in the URL you gave seems to include the “);” in the hyperlink, giving a “Not Found” error.

Working link: https://www.netsurf-browser.org

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

#147

Post by javierhonduco »

kentonv wrote: post #20

Doesn't linking everything statically imply that the base image -- and memory, at runtime -- will be bloated by many copies of libc and other common libraries? I do like the simplicity of static linking but it sort of seems to go against the idea of avoiding "bloat".

Once it’s loaded in memory, if Kernel Samepage Merging is enabled it might not be as bad, but would love to hear of somebody has any thoughts https://docs.kernel.org/admin-guide/mm/ksm.html

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

#149

Post by LegionMammal978 »

javierhonduco wrote: post #147
kentonv wrote: post #20

Doesn't linking everything statically imply that the base image -- and memory, at runtime -- will be bloated by many copies of libc and other common libraries? I do like the simplicity of static linking but it sort of seems to go against the idea of avoiding "bloat".

Once it’s loaded in memory, if Kernel Samepage Merging is enabled it might not be as bad, but would love to hear of somebody has any thoughts https://docs.kernel.org/admin-guide/mm/ksm.html

From the link:

> KSM only merges anonymous (private) pages, never pagecache (file) pages.

So it wouldn't be able to help with static libraries loaded from different executables. (At any rate, they'd have to be at the same alignment within the page, which is unlikely without some special linker configuration.)

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

#150

Post by charcircuit »

kentonv wrote: post #103
gnramires wrote: post #94

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

Everything you describe already exists. Executables do list their dependencies, and we have well-defined conventions for indicating ABI breaks. It is entirely normal to have multiple major versions of a library installed for ABI compatibility reasons, and it is also entirely normal to expect that you can upgrade the dependencies out from under a binary as long as the library hasn't had an ABI break. The bigger depend…

>Executables do list their dependencies

They list paths to libraries, but not the exact version that the executable depends on. It is a common occurrence for executables to load versions of libraries they were not designed to be used with.

Post reply on HN