Guest post by AquilaOS is a UNIX-like Operating System that started in 2016. Based on another OS I developed and many trials and failures since 2012, it finally came to light.
The goal behind AquilaOS is to make a UNIX-like OS adhering to a quote by K. Thompson in UNIX Implementation.
The kernel is the only UNIX code that cannot be substituted by a user to his own liking. For this reason, the kernel should make as few real decisions as possible. This does not mean to allow the user a million options to do the same thing. Rather, it means to allow only one way to do one thing, but have that way be the least-common divisor of all the options that might have been provided.
From the start, AquilaOS focused on being as transparent and architecture-agnostic as possible. To even raise the challenge, strict compliance with C standard (C99) is a must which allows compiling with “-O3” (strict optimization in GCC) and “-Wall -Wextra -Werror”. Currently AquilaOS v0.0.1a is released and awaiting testers and contributors.
Features
AquilaOS is mostly written in C with a few assembly parts when absolutely needed. It consists of a monolithic kernel and a set of user utilities.
Kernel Features:
- Monolithic kernel
- Supports x86 archticture (all arch dependent code is seperate from the kernel)
- Multitasking and Multithreading using POSIX threads
- Supports ELF format
- Signals
- Blocking and Non-blocking I/O
- Sessions, process groups and job control
- Virtual file system (VFS) with support for initramfs, tmpfs, devfs, devpts, procfs and ext2
- Devices subsystem using devices files with major/minor numbers
- Supported devices include: PS/2 Keyboard, IDE/ATA Harddisk, Framebuffer device (fbdev, Linux API) with VESA 3.0, 8250 UART
- Memory management subsystem (with demand paging and copy-on-write)
System Utilities:
- aqbox: several UNIX/POSIX utilities in one binary (similar to BusyBox)
- fbterm: Framebuffer based terminal (with wallpaper) with VT100 emulation using libvterm
- lua: Lightweight, multi-paradigm programming language
- kilo: Simple text editor for ANSI/VT100 terminal
- tcc: Tiny C Compiler by Fabrice Bellard (Who made Qemu and FFmpeg)
- nuklear: Immediate mode graphics library – experimental
The source code is released under GPLv3 licence and hosted on Github, https://github.com/mohamed-anwar/Aquila. Make sure to check it out and follow up with suggestions, or better yet, contributions.
Kudos to the author. Hope it will get a cool feature in the future.
Aspiring OS dev’ers always face this dilemma: to posix, or not to posix. On the one hand, posix gives your new OS creation access to a wide variety of posix compliant software, most of which you’d never realistically get the authors to port to your tiny OS. On the other hand though, posix is a messy legacy standard and operating systems based on it have been done so many times already that I’d kind of like to see new generations focus on building something new and creative instead.
This is meant to be a not a criticism of the author, who is talented, but criticism of an industry that only rewards incumbents over and over again. It’s like in hollywood, several billions go to reboots and big name actors while being unknown & small is a struggle despite putting in just as much effort and creativity. Some might retort “who cares”, but IMHO an industry with diminishing capacity for new ideas looses the sense of awe and wonder that it used to have; things get stale and repetitive.
Anyways, congrats on the OS. I respect the dedication and skill that go along with os-dev’ing. You got further than my OS years ago. There’s no better way to learn low level programming than to program your own OS
Having apps or not might be the other question.
Easy access to thousands of programs is of course tempting.
I am in favor of non-posix, but we have seen many of them already and they all have the big problem, that nobody uses it, because xy is missing …
And because nobody uses it, no one is gong to port xy to the new platform…
You only have a chance when you have the influence like Google, e.g. to push Fuchsia … but even there they are going to use the same old ARP runtime to ease the transition.
As an OS developer, I’ve gone fully the non-POSIX path because POSIX is clumsy, it had its reasons in the past, but adapted painfully to modern age. I sure provide macros that can somehow emulate POSIX apis by converting them to native ones, but the whole original POSIX stuff looks so much like unengineered stuff. I mean, you have memory functions in ‘string.h’ ? Things might have been a little better sorted out in the first place.
While it is still coded in C (easier to control memory footprint than C++, RTTI and exception handling) I’ve followed a complete multitasking approach that really, really looks like Erlang process scheduling and message passing, providing a clean and futureproof api, while ensuring a kind of legacy support. Things evolved since POSIX appeared, I mean by a lot, hence this experience should be seen integrated into an OS, not just with incremental api updates that renders things even more painful than they already were.
Pthread, semaphores, mutexes, signals, … It’s like lighting a fire with a flint in the 3rd millennium. It’s not like scholars and researchers haven’t found a better way since then, but because of the “backward compatibility” motto, to help coders “copy’n paste” old code and get the job done with as little modification as possible, we should bear old practices for ages ? Err, I beg to differ, gimme modern tools, we’re not coding in notepad and debugging with printf anymore. Do we ? Do we ?
That sounds very interesting.
Where can I find more about your OS?
IoT oriented OS I designed for the company I work for, will be released as SDK in a few months.
looking forward to it! Thanks!
string.h memory functions make a lot more sense when you realize that CPU machine instructions that deal with long “strings” of bytes are called string instructions.
That’s a CISC thing. But the PDP-11 that C was developed for was a CISC machine.
It really does make sense.
Pthread, semaphores, mutexes, signals
Out of curiosity, with which concepts do you replaced them?
process-task, message-event. That’s all.
What about best of both scenarios? I’ve acknowledged this issue early in the design and tried to overcome it by abstracting as much as possible. You’ll see, for example, that the syscalls are fully contained in one source file, that can be altered to support different/multiple interfaces easily (not just POSIX). You’ll see too that in the VFS the POSIX interface is not hard coded in any file system handler (there are POSIX bindings if an implementation wishes to confirm to POSIX). This strategy is applied throughout the entire design.
manwar,
It’s true you can add posix support, and maybe this is the best we can do from a pragmatic POV. However my own feelings towards this is that alternative methods will become overshadowed by posix. When you bring over tons of posix software, it comes with the caveat that posix becomes the primary methodology on your OS even if you have others that are better.
Software has evolved the way it has because posix became the least common denominator. You could have an innovative feature that can genuinely make software better, but because posix did not have it, software won’t have evolved to use it.
Another issue is that the goal of supporting posix software can rope you into supporting legacy baggage for things that don’t otherwise have a 1:1 mapping to anything in your ideal model. For example, termios can be quite messy, and posix file permission bits are rooted in legacy designs. In my linux distro, I wanted to use modern ACLs exclusively and simplify the FS layout, but then I discovered just how much software depends on those legacy bits. Software like openssh makes faulty security assumptions when you switch to ACLs (I don’t know if this has been fixed since then). In hindsight I can see that my idealism to make a clean break had me going against the tides of pre-existing software.
I admit, I don’t have the answers. A few years ago I had another friend on here named Neolander who was working on an OS. I asked him what his goals were, he wanted to innovate GUI paradigms for mobile devices. I suggested it would probably be easier to use an existing OS, despite their faults. Yet I think people like us still do it to scratch an itch. At least for me, it was to push myself to develop skills that I would not otherwise get to work on.
Your page doesn’t mention goals, what are your goals?
Edited 2018-05-15 14:51 UTC
Honestly, my goal was just to run Lua (I love that language), but that was done a long while ago, ever since I’m taking the free soul approach to it.
I clearly prefer non-POSIX OSes, or to stay with your example, the Sundance Film Festival of operating systems.
Xerox PARC ideas would never have taken off in a world that only rewards POSIX clones.
Sure they would, they’d just be implemented on top of POSIX
More seriously, POSIX is such a low level API spec that it is more a building block, rather than a full user API. Sure, you can code applications using just C and POSIX APIs, but there are so much more richer APIs built on top that you otherwise just end up re-implementing, that it really isn’t worth it.
For me and my toy OS, I’m aiming for a POSIX API purely because it provides all that an OS needs to provide, then anything else can be built on top, either through none-C language wrappers, or other intermediate libraries.
My personal opinion is that it is the standard C library that is the main weakness of UNIX/POSIX/C API. Memory management is error prone, string handling is primitive and also error prone, there are no built in collection primitives other than C arrays.
If I ever get my toy OS to user space with a libc, my first port of call will be busybox or similar, as that is the minimum you’d want to have a functional user system. I don’t want to have to code an entire user space as well as kernel, it’s just less practical.
christian,
I highly recommend busybox. While it has some quirks, you can realistically get it up and running with the linux kernel in a day if you know what you are doing. A GNU userspace is so much more work (if you are building it yourself from scratch).
POSIX is more the base fundamentals upon which other things can be built.
I’m not really knowledgeable on CICS idioms and how they impact application development, but I am quite familiar with Java EE (full boat Java EE), and it’s all about transaction management. Despite all of the other stuff, the singular gift of the Java EE platform that distinguishes it from most anything else mainstream is its first class support of transactions, distributed transactions at that.
Notably, for example, the DEC OSes had first class ideas of file structure etc. POSIX doesn’t. Just streams of bytes. DBM layers structure on top of POSIX files. Oracle layers structure on top of files, etc.
POSIX dictates a simple model of memory, processes and IPC. It has a minimal rights model (which seems to be what most folks grouse about today in OSes anyway, through either granularity, or attribute based rights management, etc.).
We know that putting, say, a Garbage Collector in the kernel doesn’t make much sense today. Most of the specialized OSes have fallen by the wayside of the “generic OS” that is POSIX. It’s not even clear that were they to start from scratch, would IBM build up what they have today if there was no momentum of an existing legacy to maintain?
There’s no denying that compatibility with existing software is an extremely compelling reason to use POSIX. However if the goal is innovation, then I think there are compelling reasons to avoid it. POSIX is not the end all be all of operating system foundations.
Take a look at newlib. I’ve been able to get it to work well enough with my personal OS (toss CP/M and RT-11 in a blender; pretty much as non-posix as you can get) to be able to compile things such as the vi clone built into busybox and Lua.
Android might be using the Linux kernel, but it definitely ignores POSIX, it isn’t even part of the allowed set of NDK APIs.
Oberon, Symbian, BeOS, Singularity, Midori, Redox, Mbed, Android Things, Unikernels are the OSes that make me loose a weekend hacking around or tracking down papers and blog reports on the Internet.
That is your work anyway, so just do whatever makes you happy.
Symbian is dead, right / are you one of the few who dare go through its code dump on Sourceforge?
As ex-Symbian developer I have have the SDKs, books, the devices and source code from the short open-source attempt from Nokia.
But that is not the point, the point is what kind of OS architectures have been done in the past, that aren’t plain UNIX clones.
Hm, but wasn’t it also you sometimes posting that Symbian is a quite horrible dev experience?
…so why would you willingly keep all those resources now, when the practical reasons dissapeared? 
Anyway, now mobile OS landscape is dominatd by UNIX clones …maybe there is something to it.
We can all agree that when money gets involved in any way things get restricted. Let’s talk … Linux. Linux does not entirely confirm to POSIX and not always because it’s most innovative, Linux simply has the influence to convey its APIs on developers (LinuxThreads?). We could engineer a new perfect API, and build POSIX compatibility into it, but still only a few will use it (Even I had struggles when binutils switched from BFD to GOLD and ended up using BFD anyway) so we can broaden the question to how to convince developers to use new APIs?
manwar,
Yeah, this is all true. It’s one of the things I realize up front in almost every discussion we have, I have no expectation for things to change. It doesn’t matter how convincing the arguments are if we don’t carry weight in influential circles. I still enjoy discussions though.
If you do make any newsworthy changes to the os please submit them to osnews and I hope Thom publishes them. It’s really cool to speak to the person making the news, which is you