You might think the world of Linux distributions is a rather boring, settled affair, but there’s actually a ton of interesting experimentation going on in the Linux world. From things like NixOS with its unique packaging framework, to the various immutable distributions out there like the Fedora Atomic editions, there’s enough uniqueness to go around to find a lid for every pot. Oasis Linux surely falls into this category. One of its main unique characteristics is that it’s entirely statically linked.
All software in the base system is linked statically, including the display server (velox) and web browser (netsurf). Compared to dynamic linking, this is a simpler mechanism which eliminates problems with upgrading libraries, and results in completely self-contained binaries that can easily be copied to other systems.
↫ Oasis GitHub page
That’s not all it has to offer, though. It also offers fast and 100% reproducible builds, it’s mostly ISO C conformant, and it has minimal bootstrap dependencies – all you need is a “POSIX system with git, lua, curl, a sha256 utility, standard compression utilities, and an x86_64-linux-musl cross compiler”. The ISO C-comformance is a crucial part of one of Oasis’ goals: to be buildable with cproc, a small, very strict C11 compiler. It has no package manager, but any software outside of Oasis itself can be installed and managed with pkgsrc or Nix.
Another important goal of the project is to be extremely easy to understand, and its /etc directory is honestly a sight to behold, and as the project proudly claims, the most complex file in there is rc.init at a mere 16 lines. The configuration files are indeed incredibly easy to understand, which is a breath of fresh air compared to the archaic stuff in commercial UNIX or the complex stuff in modern Linux distributions that I normally deal with.
I’m not sure is Oasis would make for a good, usable day-to-day operating system, but I definitely like what they’re putting down.
There seems to be a few problems on this site. If an article starts with a quoted item, the date, links to comment, etc just don’t show up. Something is very wrong.
Also, unrelated, to login to comment and have to enter username and password and THEN pull an 8 digit code from email seems excessive. It’s easier to login to my bank.
Yes, please look into this Thom! It’s been like this for at least a week and still articles are being posted that are displayed brokenly on the OSNews homepage. At the very least you could edit the articles to not start with quotes – as it is it’s not possible to comment on about half of the front page, because the link to the OSNews post is missing!
As explained a few items below, this has been fixed! You just need to shift+reload in your browser to refresh the cache for OSNews.
Looks like my email has reached you but you don’t bother to reply, yet you fixed the website. Thanks, I guess?
I didn’t get anything from you? In any case, we’ve been working on this issue for over a week, and since we caused it ourselves, we knew of it right away, as it happened.
Looks like my email from GMX dot com went straight to the SPAM folder.
Why not ask first if the recipient has received the message instead of assuming the person just ignored you?
It’s not like the absolute majority of the viewship of this webpage is not tech-savvy enough to know that tech, you know… fails.
Shiunbird,
Yeah, I haven’t experienced this problem in a couple years, but there was a period when google would simply blackhole emails. Whether this was intentional or not is unclear because there were no SMTP errors or bounces. This is one of the worst offenses an email provider can do because it leaves legitimate users in the void about delivery failures. Think of important an application or other important communication being black holed with no delivery feedback. For better or worse, the other party’s usually going to be blamed even when google’s the one at fault
Just to be clear, I don’t blame google for the existence of spam and false positives. However it’s not ok to blackhole emails, the correct way to deal with suspected spam is to explicitly REJECT it and create a record of the delivery failure. Otherwise the service becomes untrustworthy.
That’s true. The failure modes of some of our technologies can be quite frustrating.
Ah, thanks for that! I didn’t even think to refresh the cache – it did indeed work like a charm.
This is something Android got right from the start: No dependencies (which by extension means no dependency trees). You have an immutable base system that provides some functionality, and everything else your application needs, it has to be bundled with the application. Each Android application is a self-contained package, with all dependencies baked in (including AndroidX). The whole idea of dependency trees in Desktop Linux is a relic from another era, back when disk space was expensive and everything had to be shared to an extreme. Also, for Desktop Linux in particular, dependencies allow distros to play fast and loose with what the base system is. Of course, Windows also has some of that same brain damage, with the ability of apps to drop shared DLLs in system32, but at least the base system is a given.
I think it’s the other way around. Unix and BSD, both of which came before Linux distributions, use a standard base system. I believe Linux ended up with this package system because the GNU components are all distributed as separate packages and they don’t form a complete base system. So instead of just having the entire tree, you had to pull in multiple packages from different places. That means you had to configure and build them all separately, as well. Packaging them separately was the logical choice.
I looked into Oasis some years back (I mostly like and agree with the suckless principles), but in the end, it provides a far too basic and still experimental system. For example, you would have to bring in your own packaging tools, like Nix, pkgsrc or other. Also, the build scripts do not include a kennel nor does it include the means to build the kennel, so you have to bring it in from a different distro or build it yourself outside the project.
You are meant to build the core oasis system from source, configuring what you want to include and building the entire distro at once.
As you say, oasis itself is just the core system. Not having a package manager and relying on pkgsrc or nix is an intentional design decision.
Similarly, the kernel is meant to come from kernel.org itself. I am not sure what you mean by saying that it does not “include the means to build the kernel”. Building the kernel is covered in the wiki:
https://github.com/oasislinux/oasis/wiki/Kernel
The QEMU image of oasis includes a pre-built kernel.
Before I say what I’m going to say, let me just be clear: I think Oasis is a novel project and I agree without a lot of the principles they espouse. I’ve been a silent observer of the Suckless community for many years (which is where I originally found out about Oasis).
With that out of the way, lets not kid ourselves… As it stands, Oasis Linux is missing some key pieces of software with no way of getting it within the system. While cproc is a really cool project (I’ve been following it on SourceHut for over a year now), it does not include a preprocessor, and as far as I can tell, Oasis does not provide one either. So while a C compiler is available, with no CPP you’re out of luck for actually compiling anything. Additionally, even if a CPP was provided, you won’t be able to build any project of moderate complexity because cproc is still in it’s early stages. Maybe TCC would’ve been a better option.
Back to my comment about the Linux Kernel… the fact is that it uses a lot of GCC-specific features. Last time I checked, not even TCC was able to build it anymore. Clang can do it because it implements so many those features. The GCC-specific stuff is only the tip of the iceberg, however. Once you have Oasis running, you can’t build GCC or Clang/LLVM going because it does not include a C++ compiler. I guess you could work around that by first build GCC 4, then building the latest GCC from there, or maybe start with GNU Mes. The fact is that Oasis Linux cannot build the Linux kernel out of the box.
Ok, I am afraid I am going to come off as an oasis zealot which is not at all my intention. Let me be clear, it is a totally unfinished and not very polished project. It seems mostly to be a testbed for the author’s other projects like Velox (Wayland desktop using only 30MB of RAM!), samurai (ninja replacement), and cproc (the C compiler you mentioned). I have played with oasis but I do not use it myself.
That said, let’s be accurate. cproc is not the system compiler in oasis. As the Github states, the goal is to get the project to the point where it is “possible” to compile everything with cproc and they detail the impressive progress towards this goal. However, if you download the QEMU image (or read the author’s comments), you will see that GCC is the system compiler. The expectation is that you will use GCC (including it’s pre-processor).
The GCC and binutils that ships with oasis is statically compiled. I have taken advantage of that to move GCC to other systems where I was having trouble building a modern compiler (eg. ancient Red Hat — pre-Fedora ).
You are correct that crpoc does not have a pre-processor of its own. Again though, it is a sister project to oasis and there is no expectation that oasis users are using cproc to build oasis itself. Clearly there is the hope that it will be possible someday. That is not the same thing.
The fact is, you can compile the Linux kernel on oasis (and certainly out-of-the-box on the QEMU image provided) using GCC as the distro author intends you to. There are instructions for how to do it on the oasis github (I linked to those above).
Anyway, to repeat, I do not use oasis and do not care if anybody else does. I just have a personality defect around being accurate.
By “another era” I mean the early days of Desktop Linux (mid-to-late-90s or so), when both hard-drive space and more importantly internet bandwidth were scarce.
Basically. C doesn’t have a package management system, and compiling 3rd party software from source or headers + object files is a Unix tradition.
Linux took this to the extreme. They fixed the C package management problem with package managers and dealt with dependency hell by anointing people as “package maintainers”. This is the value proposition of Linux distros.
Applications bundling their own dependency tree is more the norm then unique. The FOSS *nixs relying on dynamic linking are odd in that regard, and in the case of Android, that’s more a function of how JARs work then anything.
There is no base in Linux. There are SDKs which are called a distros. Debian Linux SDK, Fedora Linux SDK, Gentoo Linux SDK, RHEL SDK…
People can argue that Linux kernel + GNU Libc + GNU binutils + GNU Compiler toolchain is the base, but it’s really only the most prevalent combination of Linux. Alpine is Linux kernel + musl libc + busybox + GNU Compiler Collection (I think, it’s in the build-base package).