www. O S N E W S .com
News Features Interviews
BlogContact Editorials
.
AquilaOS: yet another hobbyist operating system
By special contributor manwar on 2018-05-14 21:03:44

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.

 Email a friend - Printer friendly - Related stories
.
Read Comments: 1-10 -- 11-20 -- 21-25
.
Kudos!
By narke on 2018-05-14 22:27:49
Kudos to the author. Hope it will get a cool feature in the future.
Permalink - Score: 2
.
Innovation versus posix
By Alfman on 2018-05-15 02:07:09
> What is cool about it anyway?

All interfaces implemented so far are POSIX compliant.
It compiles with -O3.
Lua 5 is ported to it without changing a single line of code.
It should be simple for anyone to read and understand the code.


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 :)
Permalink - Score: 5
.
Innovation versus application
By cybergorf on 2018-05-15 03:46:08
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.
Permalink - Score: 4
.
RE: Innovation versus posix
By manwar on 2018-05-15 05:03:31
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.
Permalink - Score: 6
.
RE: Innovation versus posix
By moondevil on 2018-05-15 12:21:52
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.
Permalink - Score: 5
.
RE[2]: Innovation versus posix
By Alfman on 2018-05-15 14:46:41
manwar,

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

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
Permalink - Score: 3
.
RE[2]: Innovation versus posix
By christian on 2018-05-15 16:42:52
> 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.
Permalink - Score: 0
.
RE[3]: Innovation versus posix
By Alfman on 2018-05-15 18:18:27
christian,

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

Well posix is widely used and is "good enough", but I disagree that it should be the exclusive building block on top of which everything else should be built. Fundamental building blocks have consequences to the software designs using them. If people like posix, that's fine but I still think it's important for us to at least recognize that there are different models with different pros and cons. Take the CICS model used by IBM mainframes, the design of a unix application is completely different than a CICS one. CICS is more transactional, which drastically simplifies state persistence and concurrency.

Now I'm not suggesting we should all be using legacy mainframes, but I am suggesting that we should look at the different ways that software can be built and consider the roles of fundamental building blocks in software formation. The assumptions behind posix are by no means the only viable ones.

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

Yeah, C's influence is everywhere and will outlast all of us, haha.


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

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).
Permalink - Score: 3
.
RE[3]: Innovation versus posix
By manwar on 2018-05-15 19:17:01
> 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.
Well, I can't disagree with that. Even in hardware, backward compatibility with a machine that practically no longer exists is a painful process, but you'd have to do it, because ... reasons.

> 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.
That is true, however, I think it's not just POSIX, the world has really hard time changing something it's used to. That is convenient for such a huge industry.


> Your page doesn't mention goals, what are your goals?
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.
Permalink - Score: 3
.
RE[3]: Innovation versus posix
By Anachronda on 2018-05-15 19:24:29
> If I ever get my toy OS to user space with a libc...

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.
Permalink - Score: 3

Read Comments 1-10 -- 11-20 -- 21-25

No new comments are allowed for stories older than 10 days.
This story is now archived.

.
News Features Interviews
BlogContact Editorials
.
WAP site - RSS feed
© OSNews LLC 1997-2007. All Rights Reserved.
The readers' comments are owned and a responsibility of whoever posted them.
Prefer the desktop version of OSNews?