Linked by manwar on Mon 14th May 2018 21:03 UTC
OSNews, Generic OSes

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.

Order by: Score:
Kudos!
by narke on Mon 14th May 2018 22:27 UTC
narke
Member since:
2017-04-05

Kudos to the author. Hope it will get a cool feature in the future.

Reply Score: 2

Innovation versus posix
by Alfman on Tue 15th May 2018 02:07 UTC
Alfman
Member since:
2011-01-28

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 ;)

Reply Score: 5

Innovation versus application
by cybergorf on Tue 15th May 2018 03:46 UTC in reply to "Innovation versus posix"
cybergorf Member since:
2008-06-30

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.

Reply Score: 4

RE: Innovation versus application
by Kochise on Wed 16th May 2018 01:57 UTC in reply to "Innovation versus application"
Kochise Member since:
2006-03-03

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 ?

Reply Score: 3

cybergorf Member since:
2008-06-30

That sounds very interesting.
Where can I find more about your OS?

Reply Score: 2

Kochise Member since:
2006-03-03

IoT oriented OS I designed for the company I work for, will be released as SDK in a few months.

Reply Score: 2

cybergorf Member since:
2008-06-30

looking forward to it! Thanks!

Reply Score: 2

zlynx Member since:
2005-07-20

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.

Reply Score: 3

narke Member since:
2017-04-05

Pthread, semaphores, mutexes, signals
Out of curiosity, with which concepts do you replaced them?

Reply Score: 2

Kochise Member since:
2006-03-03

process-task, message-event. That's all.

Reply Score: 2

RE: Innovation versus posix
by manwar on Tue 15th May 2018 05:03 UTC in reply to "Innovation versus posix"
manwar Member since:
2018-05-07

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.

Reply Score: 6

RE[2]: Innovation versus posix
by Alfman on Tue 15th May 2018 14:46 UTC in reply to "RE: Innovation versus posix"
Alfman Member since:
2011-01-28

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

Reply Score: 3

RE[3]: Innovation versus posix
by manwar on Tue 15th May 2018 19:17 UTC in reply to "RE[2]: Innovation versus posix"
manwar Member since:
2018-05-07

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.

Reply Score: 3

RE: Innovation versus posix
by moondevil on Tue 15th May 2018 12:21 UTC in reply to "Innovation versus posix"
moondevil Member since:
2005-07-08

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.

Reply Score: 5

RE[2]: Innovation versus posix
by christian on Tue 15th May 2018 16:42 UTC in reply to "RE: Innovation versus posix"
christian Member since:
2005-07-06

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.

Reply Score: 0

RE[3]: Innovation versus posix
by Alfman on Tue 15th May 2018 18:18 UTC in reply to "RE[2]: Innovation versus posix"
Alfman Member since:
2011-01-28

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

Reply Score: 3

RE[4]: Innovation versus posix
by whartung on Tue 15th May 2018 20:25 UTC in reply to "RE[3]: Innovation versus posix"
whartung Member since:
2005-07-06


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?

Reply Score: 3

RE[5]: Innovation versus posix
by Alfman on Tue 15th May 2018 23:28 UTC in reply to "RE[4]: Innovation versus posix"
Alfman Member since:
2011-01-28

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.

Reply Score: 4

RE[3]: Innovation versus posix
by Anachronda on Tue 15th May 2018 19:24 UTC in reply to "RE[2]: Innovation versus posix"
Anachronda Member since:
2007-04-18

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.

Reply Score: 3

RE[3]: Innovation versus posix
by moondevil on Thu 17th May 2018 08:41 UTC in reply to "RE[2]: Innovation versus posix"
moondevil Member since:
2005-07-08

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.

Reply Score: 3

RE[4]: Innovation versus posix
by zima on Fri 18th May 2018 00:25 UTC in reply to "RE[3]: Innovation versus posix"
zima Member since:
2005-07-06

Symbian is dead, right / are you one of the few who dare go through its code dump on Sourceforge? ;)

Reply Score: 2

RE[5]: Innovation versus posix
by moondevil on Fri 18th May 2018 11:20 UTC in reply to "RE[4]: Innovation versus posix"
moondevil Member since:
2005-07-08

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.

Reply Score: 2

RE[6]: Innovation versus posix
by zima on Fri 18th May 2018 21:51 UTC in reply to "RE[5]: Innovation versus posix"
zima Member since:
2005-07-06

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.

Reply Score: 2

Industry vs Innovation
by manwar on Wed 16th May 2018 02:49 UTC
manwar
Member since:
2018-05-07

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?

Reply Score: 2

RE: Industry vs Innovation
by Alfman on Wed 16th May 2018 13:18 UTC in reply to "Industry vs Innovation"
Alfman Member since:
2011-01-28

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 ;)

Reply Score: 3