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

101–110 of 169 posts

Re: Oasis: a small statically-linked Linux system

#101

Post by mforney »

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…

> 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 worried about this, too, but it turns out most of the cost in just the initial packaging. Packages do not tend to change their build system very much in between releases, so updating is usually just `git diff` between the version tags, sometimes adding/removing a couple source files to `gen.lua`, and regenerating `config.h`.

I'm just one person, but I've been able to keep these 100 or so packages up-to-date fairly easily, while still spending most of my time developing my own projects.

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

This would be amazing, but I think it is too difficult a problem to solve, especially with the huge variety of build systems (which are sometimes used pretty creatively). For some packages I get part of the way there with scripts or command snippets to extract source lists from the upstream build system. Here's an example: https://github.com/oasislinux/oasis/blob/master/pkg/mpv/gens...

One of the main motivations for the oasis build system is that it is often very difficult to get the upstream build system to do what you want. It is very common for projects to ignore your CFLAGS or LDFLAGS, ignore special include/lib directories for dependencies, or have automagic dependencies (to borrow a term from gentoo) that can't be enabled/disabled explicitly with a configure switch. Also, most build systems don't work very well for building things statically. libtool will intercept your -static flag, hiding it from the compiler, and libraries which are dependencies of other libraries get left out from the linking command.

Re: Oasis: a small statically-linked Linux system

#102

Post by waynecochran »

mforney wrote: post #81
waynecochran wrote: post #6

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…

I definitely do not want to disregard. It think its cool. I just wanted to know what the target was and I think its helpful for README's to include their purpose.

Re: Oasis: a small statically-linked Linux system

#103

Post by robocat »

retrac wrote: post #46
arendtio wrote: post #39

Earlier quoted context omitted.

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

> every time there is a bug fix in one of your dependencies you/your distribution would have to recompile everything that depends on it Back in the dark ages, some mainframe operating systems like MVS normally stored executables as object files, and would link the program every time you executed it. Has the on-disk space savings and updateable libraries of dynamic linking, without most of the complexity. I believe th…

It was for personal operating systems (and ancient mainframes) that had a multitasking OS but without any MMU support in the hardware. Relocatable executables were required so that you could load multiple executables at different addresses within the single address space of the memory. This is now called Position Independent Code[1].

Modern MMUs meant that the OS would define specific addresses for use by a program, so for example all ELF programs in a distribution would have the same starting address in memory hard coded into the executable (one virtual address within a process is mapped to a different physical memory address for each process by the MMU).

[1] https://en.wikipedia.org/wiki/Position-independent_code

Re: Oasis: a small statically-linked Linux system

#104

Post by mrtweetyhack »

zamadatix wrote: post #92
mittermayr wrote: post #8

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…

It seems like your definition of "why this matters" is "how can this pick me up as a user" but for some projects "why this matters" is "to see if this works as well as we think it could" or similar more abstract goals. If the goal of the project is to try to be as small and simple of a Linux distro as possible by trying a different take and seeing how it pans out (which it seems like this is) then it's accomplishing…

So this doesn't matter

Re: Oasis: a small statically-linked Linux system

#105

Post by tonyedgecombe »

gameswithgo wrote: post #15
mittermayr wrote: post #8

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…

Actually that's one problem I've never had with Linux. Even using stuff that isn't in the default package manager seems to just work.

Re: Oasis: a small statically-linked Linux system

#106

Post by tonyedgecombe »

jcelerier wrote: post #68
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.…

> 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. even though I'm typing this on a linux desktop, this is a niche use case. In Windows, macOS, iOS and Android, so 99.9% of all user-facing computing, all the libraries except the OS API are duplicated for each app.

I think the license for the Microsoft C runtime dll's precludes bundling although it does allow static linking. It used to cause me no end of problems because the silent install would often fail.

Re: Oasis: a small statically-linked Linux system

#107

Post by ChiefOBrien »

gameswithgo wrote: post #15
mittermayr wrote: post #8

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…

Hot take: A great tragedy of the GNU/Linux ecosystem is the fact that ABI+API is still not figured out, and the most common interface between programs is the C ABI, which is embarassingly primitive even by 80's/90's standards. Some people in the FOSS community just want to leave things as-is to hinder propiertary software, and it's the same story with device drivers. You can debate the merits rightfully so, but then there's still companies pushing out binary blobs which break every few kernel updates. As a FOSS developer it's an eternal fight between good and evil with no winner in sight, as a propiertary developer it's pain in the ass to maintain old and new software between all the permutation of Linux distros, and as a user I get to cry because of the lack of popular software and backwards compatibility. Snaps and flatpaks are an ugly hack, literal ductape around this very fundamental problem, and clearly not the solution. GNU/Linux should have adopted COM and/or an adequete proglang with stable ABI a long time ago, and should have tried to control wasted effort put into duplicate software ecosystems (KDE and Gnome).

Re: Oasis: a small statically-linked Linux system

#108

Post by breakfastduck »

zamadatix wrote: post #92
mittermayr wrote: post #8

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…

It seems like your definition of "why this matters" is "how can this pick me up as a user" but for some projects "why this matters" is "to see if this works as well as we think it could" or similar more abstract goals. If the goal of the project is to try to be as small and simple of a Linux distro as possible by trying a different take and seeing how it pans out (which it seems like this is) then it's accomplishing…

I don't think you're disagreeing with each other - a bit of intro text especially helps if the project is abstract.

Re: Oasis: a small statically-linked Linux system

#110

Post by mforney »

AndyKelley wrote: post #109

How does graphics drivers work on this distro?

There is rudimentary hardware acceleration for certain older GPUs that I own in wld (intel at https://github.com/michaelforney/wld/blob/master/intel.c and nouveau https://github.com/michaelforney/wld/blob/master/nouveau.c).

But, for everything else there is only software rendering via pixman. I started working on a new library called libblit that will support amdgpu, and I managed to draw some rectangles and textures, but there is still a ways to go on that: https://git.sr.ht/~mcf/libblit/tree/master/amdgpu

Post reply on HN