17 ms·

Oasis: a small statically-linked Linux system

252 points by varbhat 6y ago

haolez 6y ago
Is "velox" (mentioned in the article) a display server or a window manager?
- fbn79 6y ago
  Window manager I think. Is based on https://github.com/michaelforney/swc https://github.com/michaelforney/swc that is a Wayland compositor
  - deleted 6y ago
    [deleted]
- herodoturtle 6y ago
  A wayland window manager.
- chousuke 6y ago
  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.
Hello71 6y ago
it's advertised as "small". how small is that? an Alpine minirootfs is ~2.5 MB tar.gz and ~6.0 MB on ext4 (4k overhead).
- yuribro 6y ago
  This looks like a desktop system, with a browser and window manager. So comparing it to the alpine minirootfs is apples to oranges
waynecochran 6y ago
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.
- warpech 6y ago
  Except that the README of this project answers all your questions. A list of distinctive features and a list of project's principles make up half of the README.
  - waynecochran 6y ago
    I read it. It does not say "why" anywhere.
    - grafelic 6y ago
      Why care about "why" when there is "why not".
      - DoofusOfDeath 6y ago
        > 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.
        yjftsjthsd-h 6y ago
        Okay, how about this: Why are you on Hacker News? It clearly doesn't align well with your self-professed interests.
        deleted 6y ago
        [deleted]
- mforney 6y ago
HALtheWise 6y ago
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?
- Subsentient 6y ago
  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 spewing to stderr.
  - nybble41 6y ago
    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 this regard. Applying LTO to the resulting code for inter-application optimization would be an interesting twist.
    - Subsentient 6y ago
      It could be done if you heavily patched everything you linked in, or developed an entirely new compiler, or both, but as-is, no.
      - nybble41 6y ago
        Apart from the global initializers, everything necessary could be accomplished with a reasonable-length shell script applying "objcopy --redefine-syms" to the object files between the compilation and linking steps to add application-specific prefixes to all external symbols defined in any of the application's object files, without any changes to the source code or the compiler. I'm not saying it would be trivial, but it wouldn't require writing an entirely new compiler. Source: I've implemented programs similar to busybox before by merging programs originally intended to be compiled separately, albeit on a smaller scale than an entire Linux distribution.
mittermayr 6y ago
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 more such things, but felt a bit left out as I couldn't figure out why exactly it exists.
- gameswithgo 6y ago
  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 love an ecosystem where things tend to be statically linked unless there is a good reason not to.
  - Wowfunhappy 6y ago
    > 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.
    - an_opabinia 6y ago
      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.
      - 6y ago
dry_soup 6y ago
I'll never use this but it's cool that it exists.
Subsentient 6y ago
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.
- AnIdiotOnTheNet 6y ago
  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.
  - Wowfunhappy 6y ago
    > 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?
    - AnIdiotOnTheNet 6y ago
      Oasis is just the opposite extreme of how most Linux distros work. That's interesting because no one else does it. I did not say it was the ideal.
  - deleted 6y ago
    [deleted]
  - 6y ago
deleted 6y ago
[deleted]
0xbadcafebee 6y ago
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 compile-in all the dependencies, you've only shifted the complexity from the filesystem to the build system, and you still have applications with incompatible features and interfaces across versions.
- AnIdiotOnTheNet 6y ago
  > 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.
  - 0xbadcafebee 6y ago
    > "we added a bunch of complexity on top of the problem without actually solving it" It solved it as much as is possible within the current state of software design. > Package managers are supposed to prevent conflicts and manage giant dependency graphs Actually, they can't do that. They can look for the conflicts they're programmed to look for by packages, and they can walk dependency graphs that are generated by the packages in the repos maintained by a person. The root of the problem is that modern software architecture (even for trendy languages) cannot express the dependencies in the first place. I wrote you an explanation, but it ran to 1,355 words, so I Gist'd it here https://gist.github.com/peterwwillis/e96854532f471c739983c0bba7608834 https://gist.github.com/peterwwillis/e96854532f471c739983c0b...
  - smilliken 6y ago
    Nix[1] is a package manager for linux and macos that solves this problem beautifully. You can have any variation (version, build options, dependencies, etc) of a package installed natively without conflicting with eachother because the filesystem path includes a hash of the build instructions. It works really, really well for reproducibility and eliminating the "works on my machine" problem. I've been using it exckusively for dev machines and servers for years. [1] https://github.com/NixOS/nixpkgs https://github.com/NixOS/nixpkgs
enriquto 6y ago
This makes me so happy! If static linking was ubiquitous, we could have avoided the complex craziness of docker and the like.
- remexre 6y ago
  Well, you'd also need to fix Python (, Go, Ruby, JS, ...) packaging and delivery too...
  - enriquto 6y ago
    so it's a step in the right direction, then; bravo Oasis Linux!
  - anthk 6y ago
    >Go Go is already static.
fmakunbound 6y ago
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??
- qz2 6y ago
  Yep. And also because it's statically linked and optimised, which version of musl that ships in that binary may be obfuscated somewhat. And no, I don't get it either.
- rini17 6y ago
  Not a dumb question just there is always a catch: dynamical link saves you from rebuild only if the fix is carefully backported (by a distributor), which can introduce issues, too. The upstream has usually moved on in the meantime and the library isn't binary compatible.
- mforney 6y ago
  Yes, but with the oasis build system this is just a single command to do an incremental build that relinks your binaries and takes a matter of seconds. The user experience is essentially the same as updating your system on a dynamically-linked system. There is no "partial build" where some binaries get relinked but not others.
- eeZah7Ux 6y ago
  Yes, and this is why Linux distribution exist. Good luck maintaining 100.000 statically linked libraries embedded in 10.000 applications.
  - anthk 6y ago
    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.
siraben 6y ago
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 https://drewdevault.com/dynlib.html
- tetraca 6y ago
  It might have been a concern long ago when space was a premium, but these days in the world of >=1TB drives you could probably build your entire software library in the most horrifying, space inefficient way, and it would still be completely and utterly dwarfed by the user's media library. Excepting games, I would bet most anyone's software library would likely comfortably fit under 128 GB. The photos, games, music, and video would be what necessitates more. And I suspect even then, a lot of people don't bother to store these things locally besides the games and photos.
  - Teknoman117 6y ago
    The majority of a game's data usage comes from assets. The binary is a tiny fraction of the size of the application.
    - tetraca 6y ago
      The game binary is generally completely worthless without its associated assets, though. Nobody would really want to install Skyrim without the master esm since the assets contained therein are essential to the experience. Maybe that's not particularly useful to the discussion, but my point is you could probably fit all your most commonly used programs in a static format + all your average assets like icons or config files, and run and use them in a pretty small amount of space. The games, FLAC music collection, high quality photo library, etc can very easily be much greater a storage requirement than an application library full of static binaries.
- mforney 6y ago
  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.
young_unixer 6y ago
> No package manager. > Instead, you configure a set of specifications of what files from which packages to include on your system Isn't that a just a declarative package manager?
- mforney 6y ago
  I suppose you could argue that, but it is not a package manager in the traditional sense. My main point here is that once you build the system, there is no longer any notion of "package", just files that make up your root filesystem. There is no package database tracking which files came from which packages. Instead, if you want to add/remove/update a package, you rebuild the system with a different specification, and then sync the resulting tree it to /.
marttt 6y ago
I might be mistaken, but is Oasis also somehow related to the suckless [1] community? (Edit: yes, the maintainer seems to be part of it.) Another static distro by the suckless people is stali (static linux) [2]. 1: http://suckless.org http://suckless.org 2: https://sta.li https://sta.li
pelasaco 6y ago
build manifests generated by Lua scripts look so elegant and clean.
pjmlp 6y ago
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.
- whizzter 6y ago
  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.
  - pjmlp 6y ago
    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.
    - whizzter 6y ago
      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.
colonwqbang 6y ago
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.
- mforney 6y ago
  > 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/gensources.awk 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.
- 6y ago
anthk 6y ago
>Velox Arcan would be interesting on this, too.
AndyKelley 6y ago
How does graphics drivers work on this distro?
- mforney 6y ago
  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 https://github.com/michaelforney/wld/blob/master/intel.c and nouveau https://github.com/michaelforney/wld/blob/master/nouveau.c 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 https://git.sr.ht/~mcf/libblit/tree/master/amdgpu
harry8 6y ago
oh no, LD_PRELOAD= hax won't work! LGPL is d00med! Beyond that dynamic linking seems like a great solution to a problem posed by hardware constraints from 30 years ago. Like a lot of CS. Eg most uses of linked lists. (Can't wait for the abuse I'll cop for that).
qwerty456127 6y ago
> netsurf instead of chromium or firefox Great for the default but can we have a Firefox/Chromium/derivative as an alternative, for the sites which don't work in NetSurf?
- mforney 6y ago
  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.
  - qwerty456127 6y ago
    Is a self-sufficient static build of Chromium or Firefox an impossible thing?
    - ObscureScience 6y ago
      As of now I think it is, but it should be fixable. Something like Oasis might spur interest (and possibly a framework) for such work.
    - anthk 6y ago
      It's tedious and cumbersome to do so with C++, and with QT is a nightmare.
musicale 6y ago
For my purposes I've often found that static-binary+cgroups+chroot+permissions gives you 90% of the isolation benefit of various container systems (docker) with like 10% of the pain. I'm also not happy with Ubuntu's move towards snaps which also seem to increase complexity and overhead with minimal benefit. An app-as-directory setup, like the one that was used in NeXTSTEP and is still used in macOS, also seems to work OK.
kingdaa 6y ago
good stuff
ObscureScience 6y ago
I think it's awesome. This is likely another of those passion project that, might draw in some overzealous on-watchers, not really become anything usable in the end, but still be incredibly valuable for the greater ecosystem. It points out how some things has gone unconsidered in the "status quo", but rather then just rant about it, shows how it can be different. It might put some lesser known code bases into the public eye. It might iron out compatibility issues with e.g. the linux kernel and "the good parts" of POSIX/unix-philosophy. Which is why I like Alpine and Voidlinux for being such complete systems, without hard dependencies on GNU-components (I think the GNU project, especially many of the individual code bases, are awesome as well). And while there are benefits of both statically linked applications, an dynamic linking, I do find it for the best if that can be a realistic choice of the user, whatever program of library you want to use. And most big applications simplu can't be totally statically linked as of now. It's a form of "greenfield project", but still leveraging existing components.
- ObscureScience 6y ago
  As an addition, I've been trying their qemu image, and similar to an older, similarly radical distro "rsld" (the old release which was graphical), it's usable in qemu, with kvm disabled, to get a snappy graphical environment that can even browse the web (with all the limitation those simple webbrowser have). Browsing HN (using netsurf), while checking memory usage in a st window uses 56MBs of memory. IIRC rsld, which used dillo on tinyxserver, used ~25MB on something like wikipedia. Other notable "radical" linux systems are EasyOS, RancherOS, Bedrock linux, Gobolinux, NixOS and Guix.

252 points by varbhat 6y ago

haolez 6y ago

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

fbn79 6y ago
Window manager I think. Is based on https://github.com/michaelforney/swc https://github.com/michaelforney/swc that is a Wayland compositor
- deleted 6y ago
  [deleted]
herodoturtle 6y ago
A wayland window manager.
chousuke 6y ago
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.

Hello71 6y ago

it's advertised as "small". how small is that? an Alpine minirootfs is ~2.5 MB tar.gz and ~6.0 MB on ext4 (4k overhead).

yuribro 6y ago
This looks like a desktop system, with a browser and window manager. So comparing it to the alpine minirootfs is apples to oranges

waynecochran 6y ago

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.

warpech 6y ago
Except that the README of this project answers all your questions. A list of distinctive features and a list of project's principles make up half of the README.
- waynecochran 6y ago
  I read it. It does not say "why" anywhere.
  - grafelic 6y ago
    Why care about "why" when there is "why not".
    - DoofusOfDeath 6y ago
      > 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.
      - yjftsjthsd-h 6y ago
        Okay, how about this: Why are you on Hacker News? It clearly doesn't align well with your self-professed interests.
      - deleted 6y ago
        [deleted]
mforney 6y ago

HALtheWise 6y ago

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?

Subsentient 6y ago
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 spewing to stderr.
- nybble41 6y ago
  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 this regard. Applying LTO to the resulting code for inter-application optimization would be an interesting twist.
  - Subsentient 6y ago
    It could be done if you heavily patched everything you linked in, or developed an entirely new compiler, or both, but as-is, no.
    - nybble41 6y ago
      Apart from the global initializers, everything necessary could be accomplished with a reasonable-length shell script applying "objcopy --redefine-syms" to the object files between the compilation and linking steps to add application-specific prefixes to all external symbols defined in any of the application's object files, without any changes to the source code or the compiler. I'm not saying it would be trivial, but it wouldn't require writing an entirely new compiler. Source: I've implemented programs similar to busybox before by merging programs originally intended to be compiled separately, albeit on a smaller scale than an entire Linux distribution.

mittermayr 6y ago

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 more such things, but felt a bit left out as I couldn't figure out why exactly it exists.

gameswithgo 6y ago
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 love an ecosystem where things tend to be statically linked unless there is a good reason not to.
- Wowfunhappy 6y ago
  > 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.
  - an_opabinia 6y ago
    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.
    - 6y ago

dry_soup 6y ago

I'll never use this but it's cool that it exists.

Subsentient 6y ago

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.

AnIdiotOnTheNet 6y ago
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.
- Wowfunhappy 6y ago
  > 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?
  - AnIdiotOnTheNet 6y ago
    Oasis is just the opposite extreme of how most Linux distros work. That's interesting because no one else does it. I did not say it was the ideal.
- deleted 6y ago
  [deleted]
- 6y ago

deleted 6y ago

[deleted]

0xbadcafebee 6y ago

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 compile-in all the dependencies, you've only shifted the complexity from the filesystem to the build system, and you still have applications with incompatible features and interfaces across versions.

AnIdiotOnTheNet 6y ago
> 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.
- 0xbadcafebee 6y ago
  > "we added a bunch of complexity on top of the problem without actually solving it" It solved it as much as is possible within the current state of software design. > Package managers are supposed to prevent conflicts and manage giant dependency graphs Actually, they can't do that. They can look for the conflicts they're programmed to look for by packages, and they can walk dependency graphs that are generated by the packages in the repos maintained by a person. The root of the problem is that modern software architecture (even for trendy languages) cannot express the dependencies in the first place. I wrote you an explanation, but it ran to 1,355 words, so I Gist'd it here https://gist.github.com/peterwwillis/e96854532f471c739983c0bba7608834 https://gist.github.com/peterwwillis/e96854532f471c739983c0b...
- smilliken 6y ago
  Nix[1] is a package manager for linux and macos that solves this problem beautifully. You can have any variation (version, build options, dependencies, etc) of a package installed natively without conflicting with eachother because the filesystem path includes a hash of the build instructions. It works really, really well for reproducibility and eliminating the "works on my machine" problem. I've been using it exckusively for dev machines and servers for years. [1] https://github.com/NixOS/nixpkgs https://github.com/NixOS/nixpkgs

enriquto 6y ago

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

remexre 6y ago
Well, you'd also need to fix Python (, Go, Ruby, JS, ...) packaging and delivery too...
- enriquto 6y ago
  so it's a step in the right direction, then; bravo Oasis Linux!
- anthk 6y ago
  >Go Go is already static.

fmakunbound 6y ago

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

qz2 6y ago
Yep. And also because it's statically linked and optimised, which version of musl that ships in that binary may be obfuscated somewhat. And no, I don't get it either.
rini17 6y ago
Not a dumb question just there is always a catch: dynamical link saves you from rebuild only if the fix is carefully backported (by a distributor), which can introduce issues, too. The upstream has usually moved on in the meantime and the library isn't binary compatible.
mforney 6y ago
Yes, but with the oasis build system this is just a single command to do an incremental build that relinks your binaries and takes a matter of seconds. The user experience is essentially the same as updating your system on a dynamically-linked system. There is no "partial build" where some binaries get relinked but not others.
eeZah7Ux 6y ago
Yes, and this is why Linux distribution exist. Good luck maintaining 100.000 statically linked libraries embedded in 10.000 applications.
- anthk 6y ago
  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.

siraben 6y ago

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 https://drewdevault.com/dynlib.html

tetraca 6y ago
It might have been a concern long ago when space was a premium, but these days in the world of >=1TB drives you could probably build your entire software library in the most horrifying, space inefficient way, and it would still be completely and utterly dwarfed by the user's media library. Excepting games, I would bet most anyone's software library would likely comfortably fit under 128 GB. The photos, games, music, and video would be what necessitates more. And I suspect even then, a lot of people don't bother to store these things locally besides the games and photos.
- Teknoman117 6y ago
  The majority of a game's data usage comes from assets. The binary is a tiny fraction of the size of the application.
  - tetraca 6y ago
    The game binary is generally completely worthless without its associated assets, though. Nobody would really want to install Skyrim without the master esm since the assets contained therein are essential to the experience. Maybe that's not particularly useful to the discussion, but my point is you could probably fit all your most commonly used programs in a static format + all your average assets like icons or config files, and run and use them in a pretty small amount of space. The games, FLAC music collection, high quality photo library, etc can very easily be much greater a storage requirement than an application library full of static binaries.
mforney 6y ago
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.

young_unixer 6y ago

> No package manager. > Instead, you configure a set of specifications of what files from which packages to include on your system Isn't that a just a declarative package manager?

mforney 6y ago
I suppose you could argue that, but it is not a package manager in the traditional sense. My main point here is that once you build the system, there is no longer any notion of "package", just files that make up your root filesystem. There is no package database tracking which files came from which packages. Instead, if you want to add/remove/update a package, you rebuild the system with a different specification, and then sync the resulting tree it to /.

marttt 6y ago

I might be mistaken, but is Oasis also somehow related to the suckless [1] community? (Edit: yes, the maintainer seems to be part of it.) Another static distro by the suckless people is stali (static linux) [2]. 1: http://suckless.org http://suckless.org 2: https://sta.li https://sta.li

pelasaco 6y ago

build manifests generated by Lua scripts look so elegant and clean.

pjmlp 6y ago

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.

whizzter 6y ago
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.
- pjmlp 6y ago
  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.
  - whizzter 6y ago
    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.

colonwqbang 6y ago

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.

mforney 6y ago
> 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/gensources.awk 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.
6y ago

anthk 6y ago

>Velox Arcan would be interesting on this, too.

AndyKelley 6y ago

How does graphics drivers work on this distro?

mforney 6y ago
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 https://github.com/michaelforney/wld/blob/master/intel.c and nouveau https://github.com/michaelforney/wld/blob/master/nouveau.c 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 https://git.sr.ht/~mcf/libblit/tree/master/amdgpu

harry8 6y ago

oh no, LD_PRELOAD= hax won't work! LGPL is d00med! Beyond that dynamic linking seems like a great solution to a problem posed by hardware constraints from 30 years ago. Like a lot of CS. Eg most uses of linked lists. (Can't wait for the abuse I'll cop for that).

qwerty456127 6y ago

> netsurf instead of chromium or firefox Great for the default but can we have a Firefox/Chromium/derivative as an alternative, for the sites which don't work in NetSurf?

mforney 6y ago
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.
- qwerty456127 6y ago
  Is a self-sufficient static build of Chromium or Firefox an impossible thing?
  - ObscureScience 6y ago
    As of now I think it is, but it should be fixable. Something like Oasis might spur interest (and possibly a framework) for such work.
  - anthk 6y ago
    It's tedious and cumbersome to do so with C++, and with QT is a nightmare.

musicale 6y ago

For my purposes I've often found that static-binary+cgroups+chroot+permissions gives you 90% of the isolation benefit of various container systems (docker) with like 10% of the pain. I'm also not happy with Ubuntu's move towards snaps which also seem to increase complexity and overhead with minimal benefit. An app-as-directory setup, like the one that was used in NeXTSTEP and is still used in macOS, also seems to work OK.

kingdaa 6y ago

good stuff

ObscureScience 6y ago

I think it's awesome. This is likely another of those passion project that, might draw in some overzealous on-watchers, not really become anything usable in the end, but still be incredibly valuable for the greater ecosystem. It points out how some things has gone unconsidered in the "status quo", but rather then just rant about it, shows how it can be different. It might put some lesser known code bases into the public eye. It might iron out compatibility issues with e.g. the linux kernel and "the good parts" of POSIX/unix-philosophy. Which is why I like Alpine and Voidlinux for being such complete systems, without hard dependencies on GNU-components (I think the GNU project, especially many of the individual code bases, are awesome as well). And while there are benefits of both statically linked applications, an dynamic linking, I do find it for the best if that can be a realistic choice of the user, whatever program of library you want to use. And most big applications simplu can't be totally statically linked as of now. It's a form of "greenfield project", but still leveraging existing components.

ObscureScience 6y ago
As an addition, I've been trying their qemu image, and similar to an older, similarly radical distro "rsld" (the old release which was graphical), it's usable in qemu, with kvm disabled, to get a snappy graphical environment that can even browse the web (with all the limitation those simple webbrowser have). Browsing HN (using netsurf), while checking memory usage in a st window uses 56MBs of memory. IIRC rsld, which used dillo on tinyxserver, used ~25MB on something like wikipedia. Other notable "radical" linux systems are EasyOS, RancherOS, Bedrock linux, Gobolinux, NixOS and Guix.