
Minoca OS: A new open source operating system - EvanGr
https://blog.minocacorp.com/minoca-os-a-new-open-source-operating-system-4bb7998df3a7
======
jprzybyl
I'm very excited about this! Minoca is an interesting system, and I applaud
any attempt to make driver-writing less inherently horrible.

Minoca OS has been around for a while, but the news is that they're GPLv3. I
think that's a great thing! The MIT license is good for software that wants to
permeate through _everything_ , but for building a community, the GPL is a
good idea.

It seems that for any operating system to be successful, it has to carry
around POSIX compatibility like an extremely expensive entry pass. I wonder
when we will leave that behind? Or if we ever will? I'm glad POSIX is just a
layer in Minoca, and not the base of the system, because these days it really
should just be treated like a big wad of glue.

PS: I love the object manager. I don't see any particularly ground-breaking
networking stack, though. A plan9-inspired networked file system approach
would have been amazing, but it seems this project is content with today's
more typical approach. Perhaps it is just trying to be less opinionated about
network structure than plan9 was?

PPS: I'm terrible at organizing a comment. Maybe I need a blog.

~~~
rogerhoward
Seems to me like POSIX compatibility is actually a cheap pass that gives you
access to a huge software environment. Right on the homepage they mention
already having packages for Python, Ruby, Git, Lua, and Node... would that,
and thousands of other packages, be feasible without a workable POSIX layer?

~~~
jprzybyl
> would that, and thousands of other packages, be feasible without a workable
> POSIX layer?

I think my problem is the core concept. POSIX stands for Portable Operating
System Interface (and X stands for Xtreme?). In an age where we spin up entire
operating systems to start a single application, why are we defining
portability at the operating system level when network portability works so
much better?

Keep in mind, this is also an age where systems like Qubes OS can make
separate VMs cooperate with each other.

The only sell for POSIX I can think of is performance, and I don't know if I
buy it anymore. Why do programs have to be cross-compatible when the concept
of an operating system no longer means owning the hardware?

~~~
kevin_thibedeau
> why are we defining portability at the operating system level when network
> portability works so much better

A lightweight POSIX-capable system has real value today. Operating systems
need to be in more places than just the data center. IoT devices don't have
the resources to run a VM or any other fancy containerized environment. POSIX
was designed to be used on systems with comparable resources to what many
embedded processors now have. It makes sense to leverage the existing codebase
where possible.

~~~
jprzybyl
> POSIX was designed to be used on systems with comparable resources to what
> many embedded processors now have.

But not comparable environments. Most IOT environments are very small parts of
very big systems, and POSIX defines a system with a teletype and a line
editor.

I seriously doubt the value of the existing codebase. Saying code made for a
server (like most existing unix code!) is fine for IOT feels wrong, and not
just because IOT devices have kilobytes of memory and servers can have
gigabytes/terabytes.

I don't think that a universal OS can work well when we know that universal
programming languages, data transfer protocols, and _everything else_ didn't.
Imagine if we were still doing everything in PL/I. We recognize now that
different programming tasks need different programming environments, but we
still don't think that different programs need different program environments.
It's just strange to me.

~~~
kevin_thibedeau
> Saying code made for a server (like most existing unix code!) is fine for
> IOT feels wrong,

There was a time when people ran Linux/SunOS/Ultrix/etc. with tiny amounts of
RAM and swap. It's not unusual for an embedded device to have 8, 16, 32 MiB,
or more RAM available. Many traditional *nix programs can run unchanged on
such hardware.

~~~
cmrdporcupine
I think the parent's comment was more along the lines of: just because an
embedded device _can_ run a Unix doesn't mean it should have to adopt the
semantics and history of the *Unix environment that POSIX mandates. In
particular the model of TTYs, filesystems, Unix-style file/IO, Unix-style
virtual memory / mmap, etc. It's not that this stuff is expensive on modern
embedded systems (which as pointed out often have the hardware capacity of
high end systems from 20 years ago), it's that these capabilities are either
not needed, or impose a conceptual model of what a computer and operating
system have to be that don't match up to what the machine is designed for.

------
no_protocol
I ran `cloc` on the minoca/os repository, here are the results:

    
    
      github.com/AlDanial/cloc v 1.70  T=22.43 s (84.3 files/s, 63498.9 lines/s)
      -----------------------------------------------------------------------------------
      Language                         files          blank        comment           code
      -----------------------------------------------------------------------------------
      C                                 1023         296251         262652         530443
      C/C++ Header                       438          93833         117592          69529
      Assembly                            95           9588           7773          13383
      make                               270           2236           6402           4784
      Bourne Shell                        38            799           1198           2787
      JSON                                 4              4              0           1367
      Pascal                               4            232             28            718
      Python                               4            194            257            589
      yacc                                 2             99              4            481
      awk                                  3             25             11            263
      Markdown                             3             27              0            172
      Windows Resource File                3             18              0             86
      lex                                  2             44            142             84
      Perl                                 1              7             10             35
      -----------------------------------------------------------------------------------
      SUM:                              1890         403357         396069         624721
      -----------------------------------------------------------------------------------

~~~
johnp_
Shameless plug of `loc`, a rust implementation of `cloc` that is 100+ times
faster:

[https://github.com/cgag/loc](https://github.com/cgag/loc)

~~~
kybernetyk
Has it any remarkable features other than "it's written in Rust"?

~~~
serge2k
> that is 100+ times faster

is that not enough?

~~~
ams6110
Depends on how slow cloc is. 100x faster than "already very fast" is not going
to be a perceptible benefit.

~~~
steveklabnik
The readme talks about dragonfly BSD's codebase; almost two minutes for cloc,
just over one second for loc. That's a noticeable difference.

~~~
kybernetyk
But how often do you cloc the BSD codebase?

I do clocs maybe once a week. So waiting for 2 minutes isn't really a huge
issue here. (Well, it's less than 2 minutes for my code bases).

Smells like premature optimization ;)

~~~
steveklabnik
This is totally true as well.

------
exabrial
I have to say... the code is beautiful: Full English descriptive variable
names and nearly every function is documented. As AngularJS has shown,
cleaner, consistent code and architecture style = more contributors.

Take a look here for example:
[https://github.com/minoca/os/blob/master/kernel/io/iobase.c#...](https://github.com/minoca/os/blob/master/kernel/io/iobase.c#L959)

~~~
pavlov
Why the initial capital on local variable names? I don't think I've ever seen
that in C code. (Usually types and exported functions are capitalized.)

It kind of makes the code look like Pascal. Nothing wrong with that, really.

~~~
cpeterso
This looks like the NT kernel coding style, especially with the pointless
typedefs for things like PVOID and the PascalCased function names with
prefixes like `IopPerformIoOperation`. I looked up the Minoca founders on
Linked In and, behold, they both worked as engineers on the Windows NT team.
:)

~~~
13of40
NT source code typically (and I say typically, because it's a mish-mash of
tens of thousands of people's work over 35 years of development) has local
variable names in first-letter-lower camel case. If these guys worked on
Windows, it's kind of surprising they didn't follow that convention.

~~~
bonzini
Usually it's uppercase with a lowercase "Hungarian notation" prefix. Without
the prefix, it starts with uppercase.

------
CalChris
Oh please. You have to start somewhere and this is where they're starting. By
comparison, Linus' first announcement was:

    
    
      Hello everybody out there using minix -
      I'm doing a (free) operating system (just a hobby,
      won't be big and professional like gnu) for 386(486) AT
      clones.  This has been brewing since april, and is
      starting to get ready.  I'd like any feedback on things
      people like/dislike in minix, as my OS resembles it
      somewhat (same physical layout of the file-system
      (due to practical reasons) among other things).
    
      I've currently ported bash(1.08) and gcc(1.40),
      and things seem to work.  This implies that I'll get
      something practical within a few months, and
    
      I'd like to know what features most people would want.
      Any suggestions are welcome, but I won't promise I'll
      implement them :-)
    
                    Linus (torv...@kruuna.helsinki.fi)
    
      PS.  Yes - it's free of any minix code, and it has a
      multi-threaded fs. It is NOT protable (uses 386 task
      switching etc), and it probably never will support
      anything other than AT-harddisks, as that's all I
      have :-(.
    

Good luck, guys. Post some docs to read.

~~~
mememachine
Ok, but why are they doing this?

~~~
edraferi
They want an OS that's smarter about power management and easier to maintain.
They describe their high-level objectives in their FAQ:

 _Why is a new operating system necessary?_

 _...The design requirements of today 's devices have drastically evolved in
areas of power management, security, serviceability, and virtualization... By
starting from a clean slate, Minoca OS is able to incorporate those core
tenets into the very fabric of the operating system..._

 _How is Minoca OS different from other operating systems?_

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

[http://www.minocacorp.com/support/faq/](http://www.minocacorp.com/support/faq/)

------
qz_
>Under the hood, Minoca contains a powerful driver model between device
drivers and the kernel. The idea is that drivers can be written in a forward
compatible manner, so kernel level components can be upgraded without
requiring a recompilation of all device drivers.

This sounds really smart and it looks great overall <3

~~~
staticfish
So true. it really is my biggest problem with the monolithic Linux kernel.

~~~
drewg123
RHEL/ Centos defines a stable driver ABI, and even has tools that devs can use
to check that their binary drivers don't use any symbols outside the ABI.

~~~
cyphar
SUSE does too. As far as I'm aware, most stable distributions use a kABI
checker. This is the same reason that Android doesn't have many kernel updates
-- because proprietary driver authors don't feel like keeping up to date with
kABI changes.

------
antarrah
That's a fantastic initiative.

> Can we achieve parity with what what operating systems are used for in
> today’s world, but with less code, and with fewer pain points? Can we do
> better? We’d like to try.

I appreciate the uncertainty!

------
bjt2n3904
Any images out there for Beaglebone? Quite interested!

Edit: Haaa, use your eyes and you shall see!

[http://www.minocacorp.com/download/#beaglebone-
black](http://www.minocacorp.com/download/#beaglebone-black)

Edit: Boo :( I haven't gotten it to boot yet. Boot messages are as follows:

    
    
        Minoca Firmware Loader
        Boot Device: 00000008
        Launching bbonefw.bin.
        Jumping to 82000000...
        !

~~~
ccstevens
Chris from Minoca here.

What you're seeing is the serial output. If you plug in an HDMI monitor,
you'll hopefully already be at the shell prompt. Email me
(chris@minocacorp.com) if you run into further issues.

~~~
bjt2n3904
Hey Chris! Very excited about the potential for a lightweight embedded OS.

I think I understand my confusion now, I was hoping for a shell on the serial
port. Most of the work I do with BBB's is headless. Does the exclamation point
mean it's finished booting to userspace? Do you think you could rig up the
serial port with a shell?

How does Minoca handle GPIO's, and other things like RTC's and SPI? I'm sure
you know of device tree and sysfs drivers for GPIO, but I can write you a
quick overview!

------
amelius
Perhaps a stupid question but where is the architecture doc? (I think that
should be the starting point, especially if you want help from a community.)

I'm also interested in what theoretical results from the last 25 years are
being used. Some references to papers would be nice. Since the biggest hurdle
is separation and thus security, I can imagine the OS has an embedded theorem
prover, but I see no mention of it.

~~~
jzymbaluk
This link was posted elsewhere in the thread:

[http://www.minocacorp.com/documentation/developers/knowledge...](http://www.minocacorp.com/documentation/developers/knowledge/kernel/)

------
nwrk
"Minoca OS was written by two developers, Evan and Chris, over the course of a
few years."

Big kudos.

Going to look at it when time allows

------
zeveb
How cool!

I happen to have an interest in OS development myself: it seems that two
things have combined to make bespoke OS development practical again. First,
the world has mostly standardised on amd64, UEFI &c. None of these standards
may be terribly good (e.g. I've always x86 and its descendants tasteless
compared to 68000, MIPS and others), but they're _good enough_ , and now
there's a critical mass of community support out there for them.

Second, readily-available virtual machines have made it easier than it ever
was to rapidly iterate on an OS concept.

My own interest is in non-POSIX, non-Unix-inspired, non-consumption-oriented
systems: I think that there's some huge headway to be made in building
computers meant to augment the human brain, rather than to just reproduce the
past or serve as an entertainment-enabler. But Minoca OS sounds pretty neat in
itself. Kudos to the guys for putting in the work, and kudos for releasing it
as open source. I hope that they're able to make some money from it too — good
work deserves to be rewarded.

------
dewyatt
The code gives me flashbacks to working with the Windows API.

Cool project though and it's nice that they already have a handful of drivers.

EDIT: To clarify, I'm not saying it's bad at all, they're just using a very
verbose naming convention that I don't particularly like working with.

~~~
maaarghk
It looks like they have basically adopted the coding conventions of windows
API code, down to the / _++ --_ / comments, style of declaring functions,
uppercase types etc. Not that it's is a bad thing, just something I noticed.

Also things like KeCrashSystemEx look _very_ much like KeBugCheckEx in
Windows. There certainly is a lot of inspiration.

Edit: I see from Linkedin the OP is actually an ex-MSFTer who worked on
Windows' HAL, so this makes sense. I wonder, tho, if this will present legal
issues? Could someone say that it is an issue that the API is clearly inspired
by the Windows API?

~~~
billytetrud
While there are the usual legal bizzarities (
[http://blog.smartbear.com/apis/api-copyright-and-why-you-
sho...](http://blog.smartbear.com/apis/api-copyright-and-why-you-should-care/)
), there's no reason this should be any different than copyright of code.
Design-inspired is not design infringement.

------
paxcoder
Took a look at the github page. Sounds really impressive, lads. I only wish it
were a microkernel and licensed with an 'or later'. In fact, given how well
copyleft works for system software, I'd consider AGPL. Anyway, it definitely
deserves a closer look.

------
anta40
[http://www.minocacorp.com/community/](http://www.minocacorp.com/community/)

Windows Environment - If you're looking to develop on Windows, you may find
this repository helpful, as it contains a native MinGW compiler, make, and
other tools needed to set up a Minoca OS development environment on Windows.

Nice to see that development on Windows is supported :)

------
teilo
I wish them well, but I'm rather surprised to see no support for 64-bit
architecture. Seems an odd place to start.

~~~
raymond_goo
well, like they wrote, they want to support small, power limited devices as
well.

~~~
nimrody
Today even smartphones are ARM64. They are powerful, yet power limited.

~~~
ZenoArrow
Look at the tag at the end of the article. It's targeting Internet of Things
devices, which will be a lot more power constrained than smartphones.

------
jwatte
I would love to see architecture and comparison to other kernels described!

Also, I wonder if this can be made to run on Cortex M4 with "MPU" but not
"MMU" hardware? Something to run on the Teensy 3.6 would be interesting.

BTW: Binary compatible function driver interfaces are great! They served us
well on BeOS. The Linux "recompile everything under the sun" approach really
gets in the way for many real world situations.

Finally, I'm sick and tired of POSIX I/O. It's a really old model, and a
really bad match to modern hardware and use cases. Someone needs to develop
and popularize the callback/messaging based kernel/application interface of
the future, complete with something other than the main() entry point...

~~~
0xcde4c3db
> Finally, I'm sick and tired of POSIX I/O.

How do you feel about kqueue or I/O completion ports? Are those something like
the "interface of the future", or just greasing the old machinery?

------
MrZipf
NT coding style and some similarities with naming. Very clean looking in what
I've seen so far. Nice work guys.

~~~
dimman
Have to agree about the good work part. Sadly my personal opinion is that I
really, really dislike the NT coding style. Now that makes me wonder how
coding style affects peoples will to contribute. Compare this to the Linux
kernel coding style and they're on different sides of the scale, I wonder how
it will affect contributions.

~~~
mycall
Windows can do this with its subsystems (Win32, POSIX, OS/2, Linux). Perhaps
they will reuse some of that idea so your preference might be swayed.

------
majewsky
Since Minoca seems to be a Corp., does anyone know what their business
strategy will be? I could imagine a) a paid enterprise edition, b) paid
support or c) paid consultancy (as in "contract the actual maintainers to
implement device drivers for your servers").

Whenever a project is corporate-backed, I like to know the business plan
upfront before I consider contributing to it.

~~~
ufo
Right now it seems that the business model is the MySQL one: provide the code
as GPLv3 and sell licenses if someone wants to use it in a proprietary
context.

And correct me if I am wrong but I think the corp is just the 2 developers
right now.

~~~
qznc
They are hiring [0], so they have money from somewhere?

[0] [http://www.minocacorp.com/careers/](http://www.minocacorp.com/careers/)

------
dreamdu5t
The goals for this new OS are quite vague and uninteresting. It seems set to
repeat most of the problems with existing OSes.

Let's take the package manager for example. Wouldn't it be great if instead of
yet another package manager that is a glorified system of install scripts...
we had a declarative functional system ala NixOS? That's just scratching the
surface.

------
c-smile
Question to authors: do you have any graphics layer in-place? Or at least
thoughts about its future architecture?

I am thinking about porting my Sciter [1] HTML/CSS UI Engine to an OS that can
be used on small (IoT) devices. I think that HTML/CSS as a UI
definition/declaration language is quite convenient.

[1] [http://sciter.com](http://sciter.com)

~~~
EvanGr
OP here. Sciter looks cool, nice site too. Currently Minoca has support for a
basic framebuffer, which we use to display our green terminal. Our biggest
obstacle to having a GUI now is the lack of accelerated graphics drivers. We'd
like to add them, but it will be a very large undertaking and probably require
cooperation from one of the major graphics vendors.

~~~
mwcampbell
Once you get at least one accelerated graphics driver implemented, would you
design your own GUI framework/toolkit, or use an existing one like Qt?

------
mwcampbell
How does this compare to Minix 3? THat's a microkernel-based OS, so drivers
are isolated, and it's also pretty small.

------
Klibarchu
Interesting take!

If I were developing a new OS, I certainly wouldn't have a default text
terminal...

That just looks gross.

But my interests differ. I would focus on the graphical user interface as my
number one concern.

It would always run in a OpenGL type graphics mode, where you could spawn any
number of text terminal-style windows, but I would definitely skip a full-
screen text mode. Its just never needed.

Does that make sense?

~~~
arcbyte
Yes and no. There are so many dofferent parts to an operatong system that you
quickly favor the text console because its so easy to do. If you are going to
work on a GUI first thing, you might as well forgo the operating system bit
and just write it as a program in some other OS while you perfect it

~~~
athenot
MacOS Classic was GUI first. There was no terminal; the closest thing that
came to a console was the MacBugs debugging interface to inspect the assembly
instructions.

------
nerdponx
Since it runs well on ARM, you guys might want to consider reaching out to the
Raspberry Pi organization for collaboration.

------
alistoriv
sounds like it could be interesting, looking forward to seeing more is it a
monolithic kernel or a microkernel? hybrid? :P

------
delinka
"...it’s simply not in widespread circulation."

And won't be under GPLv3. If your goals are to prevent others from locking up
your code in proprietary products, and to give your code to the world, then
this license is for you. If your goal is "widespread circulation," this is not
the license you want.

~~~
slgeorge
Is Linux more widely used than any of the BSD's?

Yes.

So license doesn't seem to be a sufficient impediment if the functionality
advantages are sufficient.

This meme "seems" right, but I see less evidence for it in the field.

~~~
delinka
Linux is not GPLv3 for a reason[1]. Not to mention it's only a kernel, not an
entire OS. Basing your OS on a Linux kernel doesn't expose your other code to
the GPL. Writing apps to run on a Linux system doesn't expose your code to the
GPL.

The Minoca OS folks are asking for the community to contribute code to their
OS that's licensed under GPLv3. GPLv3 supporters are necessarily a subset of
open source supporters. I contend that the subset is small enough that a
Minoca OS licensed under GPLv3 will continue to experience a lack of
widespread circulation.

1 -
[https://www.youtube.com/watch?v=PaKIZ7gJlRU](https://www.youtube.com/watch?v=PaKIZ7gJlRU)

------
walrus01
a barebones debian install of debian-testing or debian-unstable, running no
services takes about 68MB of RAM, whether in i386 or amd64 kernel versions,
and with a very recent v4.7 or v4.8 series kernel... how much more lightweight
do you need?

~~~
vardump
On a PC, 68 MB is nothing.

But in embedded space, 68 MB RAM just for the system is pretty big. Many
systems have a fraction of RAM of that. 1 - 256 kB RAM is common. Of course
embedded systems can also have gigabytes of RAM. It's a wide spectrum, so as
small as possible is preferable.

------
owaislone
Exciting times. First [http://github.com/fuchsia-
mirror/](http://github.com/fuchsia-mirror/) and now this

------
wangchow
I would like to see a built-in natural-language interface so I can, for
example, "ps -elf | grep something" with a voice command.

In the future we will need these interfaces so if this is built in to the OS
that would be nice advantage :)

~~~
wolf2600
"need". I don't think you understand what the term really means.

~~~
minikites
Well if you want to play that game, we don't "need" any computers at all.

------
imode
this should be interesting. POSIX support? I'm game.

I hope they don't try to compete with Linux. just do their own thing and see
where it goes. usually the competitive edge kills projects like these.

happy to see new kernels popping up!

------
snvzz
Very little information on their site about the actual architecture of the
system. Very bad flag there.

I'd be interested if it was based on a post-Liedtke microkernel, but I suspect
it's yet another boring monolith.

------
photonios
This is impressive. I'll give this a shot :-)

------
jlebrech
can it run on raspberry pi?

~~~
JL2010
Yes, they have pre-built images for RPi:
[http://www.minocacorp.com/download/](http://www.minocacorp.com/download/)

------
tmescic
Very cool. Is it possible to run it in VirtualBox/VM Ware?

------
ThomPete
You need design help?

------
Zekio
Would be amazing to see DotNet Core run on Minoca

------
tonyg
Is it able to self-host?

------
noja
Why's it written in C? :(

~~~
pix64
What would you rather?

------
fiatjaf
MINHOCA

------
ghostly_s
YAOSWVITEBN

Yet Another OS With the Vague Impossible-To-Evaluate Benefit of 'Newness'

edit: not to suggest I have a problem with people trying new things, but
rather...why not write up a little essay on the architectural decisions you've
made and their impact before releasing it publicly?

~~~
Zikes
Just because you're not the target demographic doesn't mean the demographic
doesn't exist.

~~~
formula1
Their competition is dsl, arch, raspbarrien and other small/IoT OSs. Not to
say their product is worse. But why are they forking instead of supporting
existing technologies?

Not saying their work isnt useful. But theres an argument to be made for
"why"?

~~~
agildehaus
Because they can. There's your why.

Now you get to answer the "why not?".

~~~
Zikes
Also, as they put it themselves:

> We wanted to see if with 25 years of hindsight and a clean slate we could
> create something interesting and unique in the operating systems space.

------
jwatte
Also, GPL3? Not my favorite license. (MIT/BSD are the best IMO)

~~~
cturner
I felt this way as well (since the mid nineties) until a couple of weeks ago
when I read _Social Architecture_ by Pieter Hintjens. It has a strong
idealogical flavour. He stresses that you should focus on building a
community, with the code and platform as happy side-effects of that community.

For that reason, you want GPL because it forces everything back into the
community. He gives examples of a friend of his who slaved on a BSD project
that got forked with the friend having nothing to show for it. And NT adoption
of much of the code from the BSD sockets API.

~~~
SysArchitect
> He stresses that you should focus on building a community, with the code and
> platform as happy side-effects of that community.

Exactly, so license shouldn't matter that much. I'd probably be a lot more
interested in it were it BSD licensed, as it is now I have no real desire to
play with this new OS.

~~~
throwawaysjshs
Can you explain why you prefer BSD as a contributer (I'm assuming you're not
running an OS company) so much that you won't help a GPL project?

------
neonbat
"lean, maintainable, modular, and compatible with existing software." \- i
wonder how long that will last.

