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
.
RE[4]: Innovation versus posix
By whartung on 2018-05-15 20:25:05
>
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.


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?
Permalink - Score: 3
.
RE[5]: Innovation versus posix
By Alfman on 2018-05-15 23:28:42
> 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.

Ok, manwar also brought up the idea of building abstractions on top of posix, so it's worth having this discussion. Clearly we build abstractions on top of a posix kernel, but what are the pros/cons of doing so?

Let's start with some pros:
- POSIX primitives keep the OS simple (we have to ignore the legacy baggage that comes along for the ride, but at least in principal it does.)
- different abstractions can co-exist on top of posix.
- posix helps keep software portable

But there are cons too, posix has a lot of legacy quirks and arbitrary limitations. Using your choice of java as an example, it has a nice abstraction of tcp sockets with a "flush" method, but since posix failed to standardize such a method, java code that correctly calls flush becomes a "no-op" and is forced to wait for the nagle algorithm to timeout before sending the packet. It's a small timeout that maybe we don't care about, but it results in tcp packets being sent a tad slower on posix platforms and is an example posix shortcomings impeding higher level functionality.

Another example is that a programmer may wish to know the source of a tcp connection BEFORE accepting a connection. However the posix standard returns this information AFTER the connection is accepted. This is an example of how software becomes shaped by the limitations of posix.

int accept(int
sockfd, struct sockaddr *addr, socklen_t *addrlen);



You could say I'm nitpicking, but try to remember my point that "Fundamental building blocks have consequences to the software designs using them".



> 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.
Permalink - Score: 4
.
RE: Innovation versus application
By Kochise on 2018-05-16 01:57:15
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 ?
Permalink - Score: 3
.
Industry vs Innovation
By manwar on 2018-05-16 02:49:42
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?
Permalink - Score: 2
.
RE: Industry vs Innovation
By Alfman on 2018-05-16 13:18:52
manwar,

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

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 :)
Permalink - Score: 3
.
RE[2]: Innovation versus application
By cybergorf on 2018-05-16 18:10:05
That sounds very interesting.
Where can I find more about your OS?
Permalink - Score: 2
.
RE[3]: Innovation versus application
By Kochise on 2018-05-16 19:11:33
IoT oriented OS I designed for the company I work for, will be released as SDK in a few months.
Permalink - Score: 2
.
RE[2]: Innovation versus application
By zlynx on 2018-05-16 19:26:36
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.
Permalink - Score: 3
.
RE[4]: Innovation versus application
By cybergorf on 2018-05-16 19:31:26
looking forward to it! Thanks!
Permalink - Score: 2
.
RE[2]: Innovation versus application
By narke on 2018-05-16 21:20:14
Pthread, semaphores, mutexes, signals
Out of curiosity, with which concepts do you replaced them?
Permalink - Score: 2

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?