Oasis Linux
63 points by kneeawn
63 points by kneeawn
Completely statically linked.
Don't link bash in anger ♪
They seem to be linking in a project called oksh instead of bash.
Oh wow ! I remember poking around this project around 2020 when Wayland was barely a thing, and this guy was creating an entire statically linked distro out of its own display server, and that was really impressive back then. Seeing that this project is still alive today is even cooler !
A screenshot: https://github.com/oasislinux/oasis/wiki (please put these on your README)
heh, they did, 2 hours after your comment: https://git.sr.ht/~mcf/oasis/commit/63b3b083cf41cf5314c56b6c03f0df53ad21386f
Completely statically linked.
I find that very impressive. My projects are almost completely statically linked, with classic exceptions like the X server and graphics stuff (OpenGL or Vulkan.)
Oasis' list of simpler library / software alternatives is worth a quick look.
I downloaded the qemu image + run script and tried it out. It worked (which can not be said for all projects out there) and it was fun to give it a quick spin.
They're actually skipping the upstream build systems which is certainly a decision. It will be definitely faster and nicer for small things like curl, but likely a serious pain to maintain long term for huge packages like libreoffice or chromium. And can result in weird differences from skipping some upstream defines... It's an interesting experiment though and saves so much time not dealing with autoconf.
Indeed. It actually sets a nice criteria for whether a package should be included in oasis or not. If it's a pain to package and maintain, it's probably out of scope. libreoffice and chromium definitely are. These days, I usually use chromium in a flatpak (as much as I like netsurf, it just can't handle most websites, and I've spent too much of my life trying to compile modern web browsers on weird systems).
There are a few packages that test the line a little bit, such as binutils, but it turns out most packages don't restructure their build systems all that often. I often add comments indicating where the upstream build system listed its sources, so updating just involves re-running configure and skimming through git diff looking for changes to the Makefile source lists.
Note also that while this approach is uncommon on Linux, it's actually done often on BSD. For instance, OpenBSD's clang has a complete replacement of the upstream build system using BSD make.
And can result in weird differences from skipping some upstream defines
I try to be pretty attentive to this and check the compile command lines the upstream build system used.
I learnt so much about Linux when I set up Oasis on my laptop. But it's not for the faint of heart, especially when setting up pkgsrc to get access to sway and other wayland desktops. The suckless version of coreutils is also incompatible with a lot of software, so expect it to cause issues. Maybe it's also because I am a little bit ignorant on the subject, but I find it slightly scary that bearssl is used instead of openssl, given bearssl was last updated 9 years age. Bearssl also explicitly says (edit: this is outdated)
BearSSL is for now considered alpha-level software. This means that it probably still has some bugs, possibly very serious ones (e.g. buffer overflows -- one of the perks of using C as programming language). It still lacks some functionalities. The API will probably change and may break both source and binary compatibility. In other words, you would be quite mad to use it for any production purpose. Right now, this is for learning, testing and possibly contributing.
What I did particularly like about the system was that it was very easy to debug and understand the entire userspace, minimal /etc, rc-shell for shell-scripting, git for version management. As an approach to reproducible systems it feels a lot less magic than say nix.
Glad to hear it was a good learning experience!
While BearSSL it hasn't had a release in a long time, it does still see commits occasionally (a few in the last month). Unfortunately, it was removed from curl last year in 8.15 since it doesn't yet support TLS 1.3 (though 1.2 is still considered secure). There was also some concern from curl that if there are few recent commits and bug fixes then it can't have happy users, to which Thomas responded
Sorry if I don't make enough bugs in my code! I'll try to be sloppier next time.
You are quoting an old version of the README. In 0.6 it says
BearSSL is considered beta-level software. Most planned functionalities are implemented; new evolution may still break both source and binary compatibility.
Using BearSSL for production purposes would be a relatively bold but not utterly crazy move. BearSSL is free, open-source software, provided without any guarantee of fitness or reliability. That being said, it appears to behave properly, and only minor issues have been found (and fixed) so far. You are encourage to inspect its API and code for learning, testing and possibly contributing.
In my opinion, Thomas Pornin's definition of "beta-quality software" is a higher bar than most people's idea of production-ready software.
While BearSSL it hasn't had a release in a long time, it does still see commits occasionally (a few in the last month). Unfortunately, it was removed from curl last year in 8.15 since it doesn't yet support TLS 1.3 (though 1.2 is still considered secure). There was also some concern from curl that if there are few recent commits and bug fixes then it can't have happy users, to which Thomas responded...
Daniel has been a little... aggressive with removing TLS libraries. I know for a platform I use, he unilaterally removed support for the only TLS library supported on it (in spite of people saying they were using and willing to help maintain it), then later asked if anyone was building curl without TLS support...
Argh, I was looking at the wrong version all this time. Thanks for the correction, BearSSL makes more sense then.
I agree that more commits does not necessarily correlate with better software; some of the most stable software I've used hasn't been updated in years. The curl team's concern is a bit frustrating in that regard. That said, it's quite rare you encounter C code so solid that it barely needs updating. :)