This page contains both non-technical and technical FAQs.

Why is a new operating system necessary?

Most of the popular operating systems today were originally built in the late 1980s or early 1990s at best. The landscape of hardware and devices back in the '80s was vastly different than today's device, especially in the mobile and embedded spaces. The design requirements of today's devices have drastically evolved in areas of power management, security, serviceability, and virtualization. Existing OSes have had work done to "bolt on" or patch up equivalent functionality, but the resulting architecture is at times awkward and bloated. By starting from a clean slate, Minoca OS is able to incorporate those core tenets into the very fabric of the operating system. The goal is to do a better job of capturing these tenets, and to do so in both a clean and lean manner.

How is Minoca OS different from other operating systems?

Though Minoca OS may appear at an application level only slightly different from Unix-based operating systems, the design and implementation serving these familiar interfaces couldn't be more different. The industry has learned a great deal over the years about what has worked and what hasn't, and we benefit from both hindsight and the ability to cherry-pick design elements. One of the most noticeable differences at the kernel level is the uniform driver model, which provides a maintainable interface between the kernel core and device drivers. This enables new scenarios in component updating and servicing that would previously require a complete recompile of the kernel environment. It also enables exciting possibilities in the realm of global system power management. Another very noticeable difference is our strong emphasis on the kernel development environment. Being able to step through code in the kernel, boot environment, and even firmware was something we felt was critical to quickly developing and maintaining kernel-quality code. The differences in design and implementation permeate throughout the code, and are far too numerous to answer in an FAQ.

How big is the OS?

Given the level of customization possible in the OS, that's a difficult question to answer. As of this writing (April 2014), the x86 kernel is about 750 kilobytes. This does not include any drivers, some of which are basically essential for booting certain platforms. A freshly booted system sitting at a command prompt with USB, Networking, and a 1024x768 video frame buffer enabled uses somewhere between 5-7MB of RAM.

Is it real-time?

The term "real-time" is often misused or misunderstood. We'll define it as "a provable guarantee of meeting an execution deadline when scheduling a task". In this sense, no, it is not a real-time system. If you have hard deadlines like controlling the robotic arm in an assembly line, this is not the OS for you. On the other hand, if by real time you mean "snappy performance", that we've got in spades. Our interrupt overhead is next to nothing, and there is so little background activity going on that our response time might often rival that of a real-time system.

What are the system CPU requirements?

On x86 architectures, we require an APIC, which is basically anything from 2002 or later. On ARM, we do turn on virtual memory support, so we currently only support ARMv6k and up. If you've got a slightly older ARMv6 device that supports VMSA, contact us, and we'll see what we can do.

What are the system memory requirements?

Probably in the range of 5-10 MB. Depending on your requirements we may be able to squeeze into less.

I'm a developer and am interested in getting involved. Do you need help with anything?

Goodness yes. We've only had time to build a limited number of third party packages so far, but we expect to be able to support a great deal more. If you'd like to volunteer to be a "package ambassador", we'll work with you to get up and running, and potentially integrate your package into our distributed builds. Similarly, if you're interested in writing a device driver, we'll help there too. Finally, if you're interested in core OS (kernel) development, see the next question.

Are you hiring?

Yep. We're currently hiring software developers who aren't afraid to go elbow deep in kernel mode code. Inquire at info@minocacorp.com or check out our careers page.

Where are you based?

Menlo Park, California.

What processor architectures do you support?

x86, ARMv6, and ARMv7. The kernel itself is quite portable, so x86-64 and ARMv8 are both on our to-do list. If you're interested, let us know.

Who wrote your networking stack?

We did. It's built in house like the rest of the system.

What compilers do you support?

We build the OS on GCC (as of April 2016 it's GCC 4.9.2). We do try to minimize our reliance on compiler-specific features, but so far haven't tried anything other than GCC.

Do you support copy-on-write, demand paging, and swapping to disk?

Yep, all those fancy memory manager optimizations are there.

What file systems do you support?

As of our most recent release (April 2016), we support FAT (FAT12, FAT16, and FAT32). FAT was an obvious choice for an initial file system as it is the only file system supported ubiquitously. Ext2 is probably next on our list to support.

Do you support multi-core (SMP)?

Yep, on both x86 and ARM. The kernel will automatically balance out processes and threads across logical processors. The kernel was designed to be able to scale to many-core machines with minimal overhead.

Is there a maximum limit on memory?

From a design perspective, no. We have a bit of work to do as far as making our drivers >4GB aware, and implementing PAE page tables, so for now physical memory above the 4GB line is not accessible. If this is a necessity for your project, let us know, and we can expedite it.

Is the debugger extensible?

Absolutely. You can write debugger extensions that help you dump and manipulate your own data structures.

What can the debugger connect over?

On a PC, the debugger will natively find and use the first serial port if there is one. If there is not, the debugger will search for a USB EHCI controller on the PCI bus whose BARs have been set up by the BIOS. It will then look for an FTDI USB Serial port matching VID 0x0403 and PID 0x6001. Support for other USB devices can be added, but so far we haven't published the debugger USB device interface.

What debug symbol formats does the debugger understand?

DWARF. Compile with -g or -gdwarf to get DWARF symbols.

Why am I not seeing proper call stacks when I try to debug a program I built?

The compiler may be omitting the frame pointer, which the debugger uses to reconstruct the stack. Compile again adding "-fno-omit-frame-pointer" to your CFLAGS.

How do I enable paging?

To enable paging, create a file called pagefile.sys at the root of the system drive (the drive that contains the apps and minoca directories). You'll need to reboot after this file is written out.

Why is boot slow?

In the debug builds available for download, there is an articifial 2 second delay at boot. This is to allow the Minoca Debugger host to connect to the Minoca OS target.