Short Bytes: We’re a little late on reporting the Minoca OS announcement, but only because we’re bringing some exclusive content to our article, so be sure to read on for some new insight into Minoca OS. It’s a general purpose operating system written from the ground up with an intention to conserve power, storage and memory.
Everyone benefits in some way when a new operating system comes out, especially when that operating system is open source. Minoca OS is a case of just that, and what’s more is that it has been written entirely from the ground up, further contributing to the software landscape.
Evan Green is the CEO of Minoca Corp, the organization currently maintaining Minoca OS, as well as a co-founder and engineer of Minoca OS. Evan has was kind enough to answer some questions about Minoca OS for us.
What inspired the name for Minoca OS?
It was actually the name of the street I grew up on. We just liked the sound of it. It reminds me of oak trees.
What separates Minoca OS from other operating systems?
The combination of supporting (but not requiring) POSIX as an application interface, plus the kernel/driver model supporting the backend are unique.
We think the optional POSIX interface is a good balance between compatibility and footprint, as it makes porting existing applications easy, but also makes it possible to shear off the excess weight of the C library if needed in tighter scenarios.
The design of the kernel-driver interface opens up interesting possibilities in areas like system-wide power management, servicing, and resource isolation. Device manufacturers want longer battery life, smaller BOM costs, and don’t want to spend significant resources on maintaining software patches for older devices. We think our design can help with these issues.
Were there any difficulties in particular when developing Minoca OS?
Writing device drivers and bringing up a new System-on-Chip are always challenging, even in the cases where you’re working with good documentation (which unfortunately is not always). I remember banging my head against a wall for over a week trying to bring video up on a particular device. The screen would come up, and I could draw on it just fine, but there were vertical black bars across the screen. Everything looked like it was in jail. Sometimes I could tweak the code to change where the bars started or the width between them, but could not get rid of them. In the end, I think I turned the right knob by accident, which clued me into the problem. A PLL clock frequency was set too slow, which caused the DMA engine to regularly underflow. The change was simple but nowhere near any video-related code.
To what degree is Minoca OS UNIX-like and how well is the POSIX standard supported?
To applications, Minoca OS looks a lot like other *nix OSes. I would self-rate our POSIX support as “pretty good”. Our goal is not necessarily to be 100% super-eagle-scout POSIX compliant, but to be POSIX compliant enough that the vast majority of open source applications and libraries “just work”. We’ll also draw outside the lines a little, adding extensions that aren’t in POSIX but that most applications expect to be there, like the getopt_long variants.
Underneath the POSIX C library is the native API, which is the real interface to the kernel. It supports the functionality required to present a POSIX C library, but the interface itself is not POSIX. Native APIs may expose more features or different parameters than the traditional POSIX functions, or may at other times expose more of a bare interface to the kernel.
At the bottom layer, the kernel itself is not Unix-like. In fact, to get to a Unix-looking directory structure with bin, lib, etc, the initial environment has to be “chroot”ed. We wanted to be able to support POSIX-like applications, but not necessarily be tied to the Unix paradigm as we look towards the future.
Is there any plan for X/Wayland support?
It’s definitely something that’s rolling around in our minds. We’ve also had some community requests for it. The challenge is that accelerated graphics drivers really do have a lot of secret sauce in them; to do it right we may end up needing support from one of the major vendors.
It’s obviously a very large task to develop drivers, and it’s a large expectation for vendors to develop drivers for yet another operating system. How does Minoca OS plan to approach drivers? Will there be some type of Linux driver compatibility, or will the onus be left entirely with the vendors?
It’s probably a bit too soon for us to answer that question with any real confidence. We think the driver API is an important design area for Minoca OS. I suspect that while writing a Linux or Windows translation layer might provide for some quick solutions now, it may hurt the potential of the OS long term. Additionally, we’re still very young, so some of the driver interface, especially some of the more class-specific areas, is still fairly molten.
The issue of how to make it easy for vendors to port drivers over definitely needs some additional thought, so we’re in no rush to issue any decrees in stone. In the meantime, we’re the driver writers.
What is the general roadmap for Minoca OS? Is there a target audience for which you wish you cater Minoca OS for, or will it be driven by the needs of those that contribute, much like the evolutionary nature of Linux?
So far our roadmap has been shaped around running well on devices that want full OS functionality, but may be resource constrained in terms of power, memory, or storage footprint. Single Board Computers like the Raspberry Pi or BeagleBone Black are good examples of machines we run very comfortably on. We think our small code base and event-driven design is well suited for advanced embedded devices.
I think Linux has shown that the needs of individual hackers and hobbyists don’t necessarily conflict with the needs of larger companies and device manufacturers. We’d like Minoca OS to evolve as a combination of community and commercial interests, and we believe that will benefit everyone. We’re committed to making open source work as a business, and we’re committed to keeping things open for our community.
The Minoca Corp website indicates that there are both proprietary and open sources, would you be able to elaborate on the differences between them and what necessitates the distinction?
Commercially we offer the same source as what’s available publicly under alternate licensing arrangements to companies for whom a copyleft style license isn’t suitable. We also offer support and engineering services for companies that want more direct engagement and faster turnaround.
What were you and your team’s hopes, inspirations, and motivations for developing a new operating system?
The original motivation for Minoca OS was actually simple curiosity. I had spent the last year managing a team of iOS and web developers in Silicon Valley and was starting to miss the smell of C and being close to the hardware. There was also this question that had been rolling around in my head: is it possible for someone to build a new OS anymore, given all the historical context, secret sauce, and errata that go into modern hardware? I sat down at a blank editor and banged out the Master Boot Record in an afternoon. The next day I started working on the debugger, then the memory manager, and basically just never stopped.
As more subsystems came up and things were actually coming together, it started to become clear that what we had here was fairly unique. It was, of course, small and lacked features for almost everything, but the choices we had made in terms of being POSIX-compliant towards applications but having a well-defined driver model on day one was a combination that we hadn’t seen anywhere else.
We’re excited to see where a new OS, given a chance to rethink historical design decisions, might go. We’re trying to build a system that’s clean, approachable, and easy to develop for. Our biggest hope is that it gets used.
The effect a new operating system has on the software ecosystem can often go unnoticed because it’s primarily indirect, but the fresh approaches brought towards operating system design can rub off on others and inspire new approaches to the development of systems of all kinds. And for that, I think we should thank Evan and his team for their efforts, and be sure to check out Minoca OS for yourself with the QEMU emulator package on the Minoca Corp website. Let us know that you think in the comments below.
Also Read: Microsoft Joins Linux Foundation As Platinum Member
