Minix 3.3.0
minix3.org
minix3.org
Even so, minix has a spot, and that spot is in education, an OS that can function like a digital version of a petri dish, something that you can quickly morph to test out a new idea without having to drag a huge behemoth of a kernel behind you.
I'm quite sad about this, I think that if minix had been open instead of 'published as a book' that minix would have been what Linux is today only better engineered and that we'd all be better off for that.
Not being GPL'd meant that a whole generation of hackers followed Linus Torvalds rather than buying a bunch of books from Prentice Hall. And so now we have 70's era tech instead of 90's.
I've built enormous systems using microkernels and there was absolutely no way we'd have gotten the same reliability and performance out of the macro-kernels of the day.
I really wonder what the overlap between Minix and Mirage are btw. Could Minix be used like Mirage as a minimal application-specific OS?
Mirage OS (also Haskell's HaLVm) are layers on-top of Xen. It would seem to me that the microkernel and exokernel designs wouldn't really be used the way Mirage is on-top of Xen except that Mirage / HaLVm could replace much of the userland on the microkernel or be its own os library on an exokernel.
The overlap I think you're seeing is that Xen acts a bit like a "microkernel" and Mirage is the userland implementing the lower-level interfaces provided by the kernel. Minix in this sense is a more complete picture but I don't see why Mirage or HaLVm couldn't be "userland libraries" for microkernels and exokernels.
I think it's a great idea actually. Build a small kernel with very few responsibilities so it's easier to prove safety, then construct the whole of userland on-top of a known type-safe language (Haskell or OCaml) and you get a potent platform!
That already exists and was just open sourced! See seL4:
http://en.wikipedia.org/wiki/L4_microkernel_family#High_assu...
While I like constructing a userland using a safe language over a small safe microkernel, I am annoyed by the hype this is getting because it's not new. Thinks like QNX, Symbian, GNU Hurd are based on this very concept. The only difference nowadays is the renewed interest in safer languages, which I suppose is only enabled thanks to Moore's Law giving us the headroom. It's also like everyone forgot the flamewars (Torvalds-Tanenbaum anyone?) about how microkernels were inherently slower. I'm sure that demon is going to reemerge soon enough, and we'll be back mucking around in C/C++ for performance. Just like 20 years ago. Those who don't learn from history...
Having not written a kernel, I can't judge those claims. It would be interesting to know if Minix has any "harder" algorithms than Linux because of this.
I think L4 already existed around that time, and got 10x or 100x improvement in IPC times, showing that microkernels could be fast enough.
But honestly, I'd rather learn to use the force. Better get that midichlorian shot.
I've seen statements to this effect around, and it's kept me puzzled. Why ditch a VM that runs on your main dev computer, and instead opt for a BeageBone, rPI, etc.? With a separate computer (like a BeagleBone), you have to copy over the OS ri it each time after building it, and this takes up a small amount of additional effort and time (that could add up). Aren't VMs are faster for someone who wants to do a lot of tinkering and iterative OS development?
OTOH VMs are of course faster, more practical and even sometomes more reliable. For anything serious I'd be using one (and even am, for work, etc.)
Yet they're pushing for reliable embedded hardware. Not all that bad of an idea. Given the nightmare of android security updates (or complete lack there of) this would make a nice embedded controller.
Need RTOS features. For .edu or .com embedded use.
The microkernel idea is pretty much dead outside the ivory tower, as in practice it didn't work, so I wouldn't be so pessimistic about how things turned out.
The L4 microkernel
> http://en.wikipedia.org/wiki/L4_microkernel_family
is really fast and used quite often. See
> http://en.wikipedia.org/wiki/L4_microkernel_family#Commercia...
for details about its usages.
A huge swath of the real time world (process and industrial control, all kinds of embedded gear) runs on microkernels. They're enormously successful, just not very visible.
For example, look at the recent minix release notes listing the well known theoretical advantages of a micro when a driver fails. Then look at the actual release notes where ARM USB is broken and crashes the entire kernel, in practice.
So with a theoretically superior microkernel design, you could restart a crashed driver in theory, although in practice when drivers crash they take the kernel with them. So you could recover from an error although in practice it doesn't work.
With a theoretically inferior monolithic design, you can't (easily) restart a crashed driver. Monoliths work around that problem by not crashing. See linux USB support on ARM. So you can't recover from errors, that don't happen anyway, so in practice it doesn't matter.
In actual deployment it doesn't matter anyway because software of a low enough quality to suffer severe driver problems most likely won't live long in the marketplace, and most driver software issues are a symptom of the device hardware being damaged, destroyed, or removed. So if your mass spectrometer A/D converter was vaporized by literal lightning, it doesn't really matter if the kernel crashes; besides the lightning probably vaporized the CPU at the same time.
One event like this is an anecdote. A couple is a trend. A couple decades of this in the marketplace, well thats something else.
Device drivers in QnX are completely separate processes that use send/receive/reply to communicate with the kernel, just like every other process. On top of that they have the ability to talk to hardware. If a device driver causes a bus to be locked and never unlocked or if a device driver starts talking to ports that it has no business talking to then that can cause a problem. So as long as hardware is involved device drivers can cause trouble for all the other processes on the system.
But in QnX those are very rare instances, I've never seen one but my QnX days preceded the arrival of USB.
Privately held company, very small, very wealthy.
Curious how this stacks up against the likes of Amazon's or Twitter's stuff. Or do they have Qnx based setups, as well?
Broadcasts of capacity seekers and offerers. Along the lines of 'I have 50 40' containers sitting in Panama, Colón, destination Rotterdam, bids in by 14:00 GMT tomorrow'.
This would then get broadcasted to all parties that were capable of taking on all or part of that load, within a guaranteed delivery time through just about every medium you can think of with the exception of carrier pigeons.
This does not compare at all with Amazon or Twitter, though twitter uses 'Erlang' in their stack somewhere and quite a bit of the philosophy Erlang uses dovetails with the way you build such systems (which is perfectly logical because Erlang came out of Ericsson and they had problems that were mostly synonymous with message switching).
I'm not aware of either using QnX in their setup.
It does make me wonder if the world should have just gotten better at state machine construction. This seems like if you kept it simple, things would have been straight forward to scale. (Not necessarily easy.)
Which is all to say that I do question how QNX really helped here. Seems more a side detail that neither helped nor hurt the effort.
That is, that you had a network transparent message passing system with high reliability is the key. That it was implemented at the OS level seems a side detail.
That is, if you were to want to build something like that today, I would remove "at the OS level" from the primary constraints in building this solution. Granted... depending on the rest of the requirements, it is highly possible one might go sans OS and just have an FPGA solution. Odds are, though, that would be overkill and more restrictive in possible solutions than necessary.
This is precisely my thought on microkernels. At face value, what is there not to like? In practice, the idea seems overly restrictive and makes it very hard to do some things that you sometimes wish to do.
This was not a theoretical exercise, it built a very deep and wide defensible moat, every Monday was a day pushing a record number of messages through the system since its inception, in other words, growth was continuous and downtime unbelievably (by todays standards) low. Which had a lot to do with the intrinsics of the OS.
And you have my word that without QnX as the cornerstone of that development it would have simply never happened. You can believe me, you don't have to but you're asking me for my reasons and then you proceed to dismiss them on the basis of your theories.
Practice > Theory any day.
If that is your argument, then it seems a moot subject. We'll never know. If Twitter had originated on a microkernel based operating system, would it have gotten the traction it did? Beats me. Not even sure how you could approach such a question.
Now, I fully agree with the view that historically a major way to get these was to go with a solution like QNX. My point is merely that the reliability of other solutions is not as far behind as they used to be. To the point that limiting yourself to only run on one of these systems seems overly restrictive. (And again, that is in today's world. Not the one of 20+ years ago. Probably not even the world of 5+ years ago.)
That's ok. I've spent enough cycles trying to get it across I think. Good night!
QNX says, "Hi." Nearly every router with >1GB/s ports run a microkernel.
Blackberry's phones run microkernels.
Yeah its closed source locked down, but its a functioning high performance micro-kernel.
Do you mean home wireless routers, or higher-end routers? I thought most home wireless routers these days, including gigabite-capable ones, were running Linux. Can you give specific examples?
Here's another: http://www.infinera.com/products/dtn.html
Talk about being dead.
And it isn't like most of us do not like some of the ideas behind microkernels and the like. The empiricist in me has grown to doubt that it is as much of a win as the hopefuls keep talking about. That is, even if someday microkernels make a pretty big comeback, I doubt it will be as dramatic of a change as is always heralded.
I doubt it will happen. But if it happens the difference will be so large that you will be wondering why we didn't do that decades earlier. It's a bit like those people that work with emacs and lisp at home that then have to go to work and use Java or PHP.
But, I still can't deny that the modern IDE has gone a long way to advance what can be done outside of emacs. To the point that I just can't bring myself to think the difference between the LISP world and any other is as large as it is often made out to be.
This is pretty much my point. This "embedded systems use microkernels" is easy to paint in such a way that it supports either argument. Comes down almost to the scottsman falacy.
More to the point, if I were to claim that my phone is really running a microkernel, I would be ignoring the majority of the software on my phone. I mean, yes it is true. But it is laughable in that the majority of the programming on the device is not in L4. To a large margin.
Consider, you are at this point merely claiming that a state machine in your device is running in a microkernel. And, to the non-microkernel that runs the majority of the phone, it is but a device. So, we have a non-microkernel running a microkernel as a standard device.
The high end market is android and ios. the middle of the market is android and small amounts of other the low end of the market is android for the most part now as well.
> I would be ignoring the majority of the software on my phone
I'd like to argue that the baseband processor is the biggest part of the phone, save for relaying and converting the microphone input. The rest is just a handheld computer. But that's the True Scottsman you made out. In fact, Android might be a good example, just one that doesn't support your point too well, because the Scottsman Fallacy is working both ways. When we are talking true OS with services and drivers et al, android is relevant, ofc. Still, it might be chosen because of any other reason as well. The reference to Android is akin to an argument of authority.
You can run Linux on L4 as a hypervisor, by the way. I have no clue how that works, but maybe we have a microkernel running the Linux-kernel as a service. :)
I can see the compelling nature of the baseband processor being the largest part of a phone. If only because of the name of the device. The reality, I assert, is that the phone is now just another component inside a pocket computer I happen to carry around. Ironically, it is mainly used from an app called "Phone" on said device.
And, my entire point for this thread is that Android as an example can be used to cut both ways. That was what I meant by saying it could support either argument. (I cede that my opening comment did not make this clear. It was what I meant by saying "this point is easy to mislead.")
I do not see how it is an appeal to authority, though. It is meant to be an appeal to evidence. Just as the claim that "embedded systems use microkernels" is.
That would certainly explain the billions of microkernels running in production as we speak. Better tell amazon to shut down their whole webhosting business since microkernels don't work. I'm sure they'll be dissapointed to learn about this.
You don't seem afraid of angering people with comments like that.
I think you're right. But you also have to consider the fact that linux is the only reliable open source kernel which developers know how to use. The mere fact that's it's both maintained, open source and used by many is a big feature. It doesn't have to at the bleeding edge.
Even if it's 70's era tech, it's still a good enough tech for many things. Its sole aim is not directly compete with proprietary kernels, it's just because it's just cheaper and more free.
I wish minix would get more attention too, but I think kernel choices boils down to what hardware you have.
In my 'day job' (as far as I have one) I get paid to speak my mind and not to weasel around the issue, compared to that speaking my mind without 'fear of angering people' in an online forum comes pretty easy and I don't think anybody that really knows his stuff would be angered by this.
It is much harder to write a report for a VC detailing a potential investment when every word matters. I can agonize over a report for days in order to make it fair and not to leave ambiguity in.
Seems to me, it found its window of opportunity in the form of €2.5 million and took it. I would call Minix a success.
This is why I was surprised to see that the Raspberry Pi, which has a focus on education, was not on the list of supported boards. I would have loved to tinker with Minix on a Raspberry Pi (I have several boards lying around) since I have a latent interest in microkernels. I hope RPi will get supported later.
> http://elinux.org/RPi_Hardware#Schematic_.2F_Layout
> http://www.raspberrypi.org/model-b-revision-2-0-schematics/
Where I live, you can be happy if people knows what Linux is, maybe you find 1 between each 100 computer users.
Teachers here does not know to program a lot. You can be happy if they are able to copy&paste commands, and blindly follow search engine results.
Of course 100 of each 100 computer users know what android is (not what it means for their freedom, surveillance and privacy). And the market is full of java/android programmers making cry to any UNIX-like sysadmin or security expert with their code.
Education here gets ipad and Microsoft stuff. With agreements hard to break.
At much, you see a "fedora" computers room, on public universities, just to run a few mathematical programs on some careers, and nothing else.
Out of certain universities, it's hard to find people doing things (even in the educational land) with minix.
And as a joke of destiny, most of the open source projects with company funding stay away from GPL or offer dual licensing.
> And so now we have 70's era tech instead of 90's.
It worse than that, it is actually late 60's.
If it were 70's at least we could aspire to have the Xerox PARC environments.
They use GPL or something more liberal (BSD), not less. There's no contradiction.
Just that the GPL dream that spread into the mainstream thanks to Linux becoming GNU's kernel, now is less so thanks to more liberal licenses.
If I am just grad student/professor wanting to publish interesting paper, Minix/uKernel is interesting.
If I am software engineer looking for tech for career development for next 5-10 years, it is Linux.
If I am a project manager/Founder/VC looking for the tech foundation/stack for next cool gadgets, server stack and abilities to find season developer, it will be Linux.
With distribution through a book, at the time, it wasn't a terrible idea. The internet was in its infancy, and there were a lot of schools that had real poor connectivity. Unfortunately, the internet grew rapidly, and textbook publishers are conservative, and the rest really is history.
To be honest, I feel there is a near-depressing anti-intellectualism in discussing non-Linux kernels with a number of hackers. They know the devil that is Linux, and fail to see how exploring those other devils and daemons out there could possibly improve their perceptions of what an OS can and should be. Network transparency, non-traditional filesystems, etc, have all been hampered by too stubborn of a refusal to question the assumptions as to what a kernel and OS can and should be.
Things are changing in the Linux world. Just not in a particularly positive direction.
Moral of the story: Linguistic relativity (Sapir-Whorf hypothesis) is real. It doesn't apply just to human languages, but technology as well. People with broken mindsets will carry over their baggage with them and poison even already mediocre environments.
More depressing though, is the anti-BSD sentiment present amongst many Linux users. Mostly because of how ironic it is.
Even languages without a heritage, which are invented within two generations have complex features comparable to established languages. There are many good examples in Steven Pinker's "The Language Instinct."
Similar to the Sapir-Whorf hypothesis I think "broken mindsets," and "poison," are exaggerations with little basis.
tl;dr It's really not that depressing. There are different ways of doing the same thing.
UNIX had a few nice ideas, but so did other OS, there is hardly a reason to have it in a pedestal.
All monocultures are bad.
What happened is that now young developer generations think that UNIX and Windows are the only OS in town and disregard all the other ones out there being used.
As such they only focus their efforts into UNIX way, instead of trying to come up with new ideas.
For example, how to move away from C for systems programming, when C is married with UNIX? This is just one example.
Of all the things about Apple that could be changed, I'd say the underlying technology of their OS is the least interesting.
Database based filesystem.
The way multi-core programming was present across whole OS.
It's everything I could ever dream~ vomits uncontrollably
The other two are more substantial, but still seem pretty unimportant things to ask from Apple in an alternate reality. I'd say the problems with Apple are mostly non-technical.
Which part? IOKit, for writing kernel drivers for Darwin's xnu kernel is C++.
Cocoa is mostly Objective-C and not plain C. What would C++ improve there?
So… which other part would redoing in C++ improve? The kernel filesystem layer? The internal kernel exec implementation?
I'm not seeing what C++ brings to the table in any of these cases.
Maybe the POSIX layer itelf? That could be new and interesting, but the C++ ABI isn't really compatible with much beyond C++ itself. The beauty of the C ABI is that pretty much everything implements it, some languages with direct C FFI APIs.
Now a kernel written Rust… that's something I'd like to see. But then again, what would the userspace interface layer for such a kernel look like? POSIX?
Everything.
> I'm not seeing what C++ brings to the table in any of these cases.
Making C move out of the scene and moving into safer languages for systems programming. Even though C++ also has its issues, but at least it is way safer than C.
There are C++ OS like Symbian, OS/400, Genode and also Windows is moving into that direction.
However having a desktop OS to point out to as example, would be nice to the C++ community.
> The beauty of the C ABI is that pretty much everything implements it, some languages with direct C FFI APIs.
This is a consequence of C ABI being the OS ABI.
Outside the UNIX world there are a few OS were this wasn't true.
> Now a kernel written Rust… that's something I'd like to see. But then again, what would the userspace interface layer for such a kernel look like? POSIX?
Me too. POSIX is tied to C, the API should be something modern.
I guess I don't see as being "way" safer than C. I see it as being marginally safer [1], but with an arbitrary and rigid object model.
> > The beauty of the C ABI is that pretty much everything implements it, some languages with direct C FFI APIs.
> This is a consequence of C ABI being the OS ABI.
Perhaps. But a non-OO interface layer makes a lot of sense anyway (or at least OO agnostic ones).
The problem with making your main OS interface be C++ is that now every other language has to contort its object model to match the C++ one. How do you write Go code that interfaces with the C++ OS objects? C++ and Go are remarkably different. Ruby and C++ are different, as is Perl, Obj-C, Python, and Java. Either you have to use barely anything from C++ (really light inheritance, no STL, no RIAA, etc.) or you have to have extremely severe wrappers for every non-C++ language. The former means you give up on a lot of the safety that C++ gives you and the latter means that every language binding is 100% different. Neither of those is a good option.
An idiomatic C++ OS interface sounds good on the surface, but I think it's really only a good idea if you want all the user code to be written in C++, too.
[1] Everything you can do wrong in C you can also do in C++: Good old "((void(*)())0)();" compiles in both.
Agree. But at least C++, the language, gives you the tools to write safer code, when you stick to what STL offers or similar libraries.
With C, only third party tools that aren't available everywhere.
Not to mention that back in 80's, C already felt primitive and its success is only a consequence of UNIX spreading into the enterprise out of research labs.
The best would be to have both gone. But until that doesn't happen C++ is way better than C.
> Perhaps. But a non-OO interface layer makes a lot of sense anyway (or at least OO agnostic ones).
C++ usage does not imply OO. The language has a lot more to offer.
> The problem with making your main OS interface be C++ is that now every other language has to contort its object model to match the C++ one.
I fail to see how this is different from OS where C isn't the OS ABI, like the mainframes, almost all of the 80-90's home market OS, for example.
Languages have to use the OS ABI. The fact that in most OS C ABI == OS ABI is a side effect of writing the OS in C.
The proof you could have an workstation OS written in a GC enabled systems programming language.
I cherish Microsoft for its work in Windows, it is the only mainstream OS that can save us from UNIX monoculture.
Yes, UNIX has a bunch of nice ideas, but that is all.
lol
Note that the Microsoft way tends to lead to another monoculture and to vendor lock-in. I'd say "of course, the same applies to the products of every other corporation", except that in my experience, everyone is using Windows on the PC.
Probably because I'm not a hacker from the 70s, when I discovered Linux (note a BSD variant would also have worked, had I known about them) it was a breath of fresh air in the ubiquitous monoculture that was Windows.
I run multiple monitors and multiple drives in my desktop, and generally one of those two things will lead me to pain when it comes to installation, or an upgrade cycle with the OS. I really don't like playing with my desktop for a half a day to get it running again when I'm trying to get work done.
Given, it's a lot better today than in years past, I just haven't had it in me to go to Linux for a month, only to have an update break something that will take hours to fix. That just doesn't happen as much in OSX or Windows.
I kind of wish one desktop platform would come to true prominence in Linux, and I care less about which one, as any one... then that one can get a lot better. I don't even mind gnome 3 or unity so much. I just want something that will keep working right through a few upgrade cycles... opposed to where I really consider not running updates on my desktop.
My last attempt at Linux for a primary OS was about a year and a half ago. I tend to get the bug to try it out every couple years. Eventually, I hit a wall a week or few weeks in that I just don't have time/patience to deal with.
PC-BSD was also a really nice option, but the limited VM options and support for current hardware really killed that for me. I think BSD fits my mindset better, but Linux has become more ubiquitous.
Either way, I would love to see a truly great desktop Linux platform for me. A power user and programmer who likes to tinker with stuff, but wants something that has an ok ui, that gets regular updates without issue. Most of the time, when I did update, it was more for something I wanted to play with other than the main OS.
Also PC-BSD is working on a BSD-specific desktop called Lumina. It's at an early stage of development so not yet clear how well it will compete with established DEs.
It will be interesting to see how far Linux goes with Wayland, said to be a replacement for X. If X becomes deprecated on Linux, probably BSDs won't travel that path and stick with X, which means X development will be more or less up to the BSD projects. Just my speculation about these things.
What I'm waiting for most is completion of FreeBSD UEFI support, including Secure Boot. Once that's available it should make dual-booting FreeBSD+Windows much easier--a great option to have.
It will be cool to see what happens in the next couple years though.
As to "a bunch of nice ideas", I'd suggest you take a look at the concepts that Plan 9 from Bell Labs brings to the table. The everything is a file concept there is something I wish would have taken over the more classic approach to devices, networking, etc. Want to open a remote shell on another server? Easy as opening a file handle. Accessing the CPU and running programs? Same story. Now if you call that just a nice idea, I rest my case ;-)
Microsoft even explored some of those concepts in their research OSes like Singularity and Midori. There has to be something about those ideas that they appeal even to MS, that's just my view though.
We really are using a 1970s era operating system well past its sell-by date. We get a lot done, and we have fun, but let's face it, the fundamental design of Unix is older than many of the readers of Slashdot, while lots of different, great ideas about computing and networks have been developed in the last 30 years. Using Unix is the computing equivalent of listening only to music by David Cassidy.
We're still wrapping our heads around decades-old ideas. We can be sure software development is finally a mature field when we're unflinchingly using 100+-year-old constructs because they've withstood the test of time.
One of my favorite fields, DSP, leans on math from around the turn of the 20th century. Far from shameful, I consider that a win for mathematics.
I tend to simplistically reduce this choice between:
- Everything is a file (the unix way); and
- Everything is an object (the windows way)
Both choices have the potential for great results. In practice, however, the documentation and composability in the everything is a file paradigm has shown to produce better results. Unix ecosystems are more alive; it is easier to replace system parts and create operating systems out of your own choice of replaceable layers. The monolithic nature of Windows is a reflection on the failure of the object oriented approach to operating system interfaces.
Mind you, I don't think it is an intrinsic fault. It may be that it's a fault of this implementation of an OO operating system.
This is the main reason I dislike what the Gnome folks are pushing down Linux's throat. The Gnome way is, today, at odds with the Unix way.
- You can do anything you want with anything (objects)
- You have a discrete set of file operations. (files)
Though, I hate the "paradox of choice" and I think I am saying it reduces to that. :(
* data accesses (read),
* data mutations (write, trunc),
* metadata accesses (readdir, closedir, stat, statfs, readlink),
* metadata mutations (creat, mkdir, link (and symlink), unlink, rmdir),
* interaction contexts (open, close, opendir, closedir),
* namespaces (mount, umount).
I would argue that any object (OS-level or otherwise) can be represented as a filesystem. The advantage of doing so is that the client interface stays the same in all cases. I think it's this constraint on the interface that makes file operations and filesystems so appealing in the long run.
Plan9 window manager is not an example of performance.
For data in /scenegraph/, SceneGraph_fs would accept well-formatted writes to a node's files as a means to update the node in the scene--for example, to translate the node, you would write a new matrix to the object's positional matrix file (the write() would return EPERM if the matrix was malformatted). To create or modify an object atomically, you could describe it under /tmp/ in SceneGraph_fs, and rename() it into place. You could manage lights and lighting data in the same way.
Of course, the graphics card interfacing happens in filesystem implementation. But, the application interacts with the scenegraph as a filesystem, not as an object.
Very similar to the REST versus SOAP/whatever paradigm. Neither one should be more capable than the other. In fact, REST should be the more restrictive choice. Right?
Until you start doing IPC between processes, IOCTL, heavy graphics programming and there goes the abstraction.
> It may be that it's a fault of this implementation of an OO operating system.
I'm not convinced it's just this implementation. When everything's an object, there's additional overhead as a programmer trying to use the API.
File based API - Open a file using the same 'open' call you've always used, and then call 'read' or 'write' (or even 'ioctl') on the file descriptor. Call 'close' when done. There may be multiple files you need to access to get the particular behavior you want.
Object based API - Browse around the docs until you find that particular subsystem's API. Read a bunch. Finally instantiate the object you need. Set all of the objects various properties. Call CreateObject(object, options). Wait, go back and create a options object. Set all of the properties on that object as well. Try that until you figure out you needed to call CreateObjectEx instead. Hit your head on the desk for a couple hours until you figure out that you also need to call RunObject, and that one of the parameters on the options object was set wrong.
As a programmer, the file-based API is just a layer of indirection to make things easier, and shouldn't be considered a limiting factor.
Then again, there's this article about Event Tracing on Windows, that makes me think it's just this iteration of OO-based operating system, and a better designed API would do us all a favor.
I wouldn't say there is a "Windows way", considering that current Windows is actually a system composed of several different layered components:
1) The NT kernel (which is pretty nicely designed) its own ideas of what "objects" are and all the ObXXX functions.
2) Win32 which is a horrible mess from the Windows 3.1 days and maybe earlier.
3) COM and flavors, which actually came later with its own brand of objects.
4) The .NET framework.
It doesn't seem to me that "Windows objects" are really unified in spirit and design across all these components (not to mention that Win32 isn't object-oriented at all).
To add on to what a previous commenter said, Plan 9 is proof that Unix's nice ideas are more than a few. In fact, the ultimate irony is that some of the most fascinating OS design has emerged from being more Unix than Unix itself.
Plan 9 has also become pretty much the only breath of fresh air from an architectural standpoint in Linux, what with procfs and all.
I seriously doubt I could use such abstractions for high performance 3D computing.
What is Windows doing differently than UNIX monolithic kernels? Drivers and filesystems run in NT kernel space.
- Exposing an OO ABI (COM, WinRT)
- Moving beyond C for systems programming (C++, .NET Native, Sing#)
- Experimenting with new OS architectures (Singularity, Drawbridge)
- Continue the multimedia OS culture of Atari ST, Amiga systems
Not sure this matters given the extreme low-level nature of kernel and driver coding. Certainly not enough to warrant a rewrite, which I guess is a result of Microsoft more or less dropping support for modern C in their compiler by not even supporting C99 fully.
>Experimenting with new OS architectures
Certainly Singularity was an interesting experiment, sadly and typical of Microsoft mentality, once they ruled it out for production use and passed it off for others to play with, they chose to do so under such a restrictive license (shared source) that no one will do something interesting with it.
As for drawbridge, the same ideas regarding sandboxing are being worked on in the Linux camp, and from what I understand also in solutions like Capsicum on FreeBSD, from the looks of it, *NIX is way ahead of Microsoft in this area.
>Continue the multimedia OS culture of Atari ST, Amiga systems
Not sure what you mean here unless you are talking about coming with a GUI out-of-the-box ?
Your typical current Linux distro is more of a 'multimedia OS' than Atari ST or Amiga ever was (owned them both), which includes BeOS, the one which actually carried that moniker.
ps: from r/hurd
http://www.gnu.org/software/hurd/microkernel/viengoos.html
https://archive.fosdem.org/2014/schedule/event/04_uk_escape/
That being said, I would really like to know if Minix tech is better than Linux.
I have heard the whole microkernel/monolithic kernel debate. But to this day, Linus admits that monolithic is a better design choice. And on the other hand, HURD is a microkernel which suffers from development and I have heard RMS saying somewhere that choosing microkernel was a bad decision.
No, it isn't.
> But to this day, Linus admits that monolithic is a better design choice.
Well, that depends. Linus is somewhat invested in the monolithic side of things. If you see the world through a real-time lens and you think of computers as things that simply never get switched off until they are physically end-of-lifed, if reliability and latency are more important than raw throughput, if you want to be able to upgrade your OS without a reboot and so on then microkernels start to make a lot more sense.
In the traditional sense, minix is more of a 'small unix' than a micro kernel, the kernel supports all kinds of primitives that you'd not see in other micro kernels.
See:
http://wiki.minix3.org/en/DevelopersGuide/KernelApi
(For instance, the 'device io' calls are not what I'd expect in a true micro kernel, messaging primitives are not present).
HURD is committeeware. L4, QnX and a bunch of closed source industrial systems are real, battle tested microkernels that I would put opposite UNIX/Linux/BSD for comparison, not minix, to me that always was a 'toy' operating system, which just like plan9 never really outgrew the lab.
Which is exactly how it is. So the question remains, what's the problem?
L4 is not a kernel, it is a family of kernels. You can't run L4 any more than you can run BSD. You have to pick an actual specific implementation. Some L4 kernels are "battle tested" and some are learning projects made by single individuals and never used for anything else.
I could not bring myself to appreciate Linux as it was, as it could be, back then. But I realized the trend, because I could understand the economics, both financial and cultural.
What I think happened to me, was a kind of disillusionment. I saw the progression as a long reimplementation of then already ageing concepts, because there was a genuine need to prevent too much being stalled by myopic business and pseudo or real monopoly. Once Microsoft had their hands on the VMS code, or at least David Cutler (it's a strange story and a car crash that ended his counteract architect, and look where senior DEC management got their sinecures)i felt that all Microsoft had to do for twenty years, was expose functions form the NT kernel, to stay ahead in terms of features. With the only viable chase being a reconstruction of what was by definition much earlier thinking, that had to become the spirited, almost religious, movement behind Linux, or fail. I think that era is over.
I don't think anyone won. Not exactly, but I am biased because I will happily consider windows a development platform, with exceptions, and vice versa. I hope that era of chasing against a monopoly is closed, but the massive expansion of installed systems has not helped anyone. Minis or Plan 9 are far better ways to explore computing in a fundamental way, and remain in some ways, more advanced, and if there's a toss up, that can be argued by accessibility. You can't play with the Linux kernel, or with NT, without enormous system knowledge, compared with even ten or fifteen years ago. As a result, we have stagnated the progress of the art.
Sometimes I am even more hopeful, for the windows platform, since the win32 system has survived so much, and lived in emulation on its primary system now fifteen years at least. The compartmentalized driver model for NT offers a certain hope, e.g. for storage driver development, because it was well separated by design. POSIX holds everything closer to the system descriptions that were drawn thirty and more years ago. Obviously that is powerful, but it reduces potentially useful abstraction.
What hope now, is the research in distributed systems, that first interested me, thirty years ago, and I was not reading up to date papers, then, finds a home, in the mix of virtual machines, virtual datacenter even, we can put into a box. Things like on the fly code recompilation and all that's been done to accommodate usually legacy systems and VMs, did progress a lot of art, and instruction sets developed to accommodate that. Yet, with some instructions that matter to me, they are norm and likely will not be virtualized.
Forgive me my hand waving approach, please, but what interests me is when user applications are so many layers away from the kernel, especially in windows systems, I think there is room for approaching again what underlies everything. When ZFS was announced, I immediately craved for a PCI card subsystem for every windows workstation we had. This is now more of a economic quandary, nothing serious stops you building the card and exposing higher level APIs that way. We've performance we can deliberately waste. So much so in consumer space, enthusiast home users, there needs to be a application that takes advantage.
My thoughts are that we need better content addressing, than the web has an ability to offer. Content addressing is what the web has enabled, on a massive scale. The network design behind it has caused all manner of diversions for design, just take a look at how a CDN is built, or buffer bloat, or the economic constraints of "real" internet access, which is available in the UK through only maybe two consumer DSL ISPs...
To change from the "white coat", "glass room" datacenter model, which has prevailed so well that the company who so accurately proclaimed "The Network Is The Computer" (to mem memorably, in a billboard right outside my office, no place anyone save me and colleagues would ever see much) is part of a classical "mainframe" model company.
The next applications that matter, will challenge the infrastructure of computing we use. This is why things like Minis and Plan 9 still matter. Both are great educational tools, but in my shop, I try to get everyone who joins us, to spend some time with Plan 9, to rethink how we appreciate data and content at a low level, and I believe that is really important to my company, the way we think, and will become important much more widely.
I got some hints of that feeling while poking around http://undocumented.ntinternals.net/ ... They seem to have still forgotten about ZwCreateProcess (copy-on-write forking).
Copy-on-write fork existed in POSIX subsystem of Windows NT (MS Services for UNIX aka Interix), hence no global mutexes in that subsystem.
There are global mutexes in Win32 subsystem of Windows NT, hence no fork.
And on "true" POSIX systems with pthreads there are mutexes and fork, but mutexes are process-local (kind of Win32 critical sections).
Why? Even then, nobody thought that. Including ast. Minix was a toy OS, it was designed specifically for teaching, not for actual use. Minix3 is not minix. It just shares the name and the designer. It is a completely different kernel that shares no code. It was designed to be used. That's why minix3 is being used and minix was not.
The only niche where I see an OS being relevant is in single-computer safety-critical applications and consumer devices. Minix3 aims for the former and I really hope it carves out its own little niche, but I think Linux is here to stay.
http://herpolhode.com/rob/utah2000.pdf
On one hand you had Windows NT taking over commercial space, on the other you had the Linux juggernaut gathering speed. There was not much left for the niche players.
Glad to see Minix survives still.
But, it seems to me that it's not really usable for most people, since driver support is very poor.
I would really like to know, if anyone knows the answer, how much effort it would take to create some sort of tool that converts a Linux driver to a Minix-compatible driver, or -- if that's not possible -- how many man hours it would take to rewrite ALL Linux drivers to be Minix-compatible. Anyone know?
Discovered it here on Hacker News some time ago [0]. But it did not get much attention. I would love to hear more opinions from HN on this topic.
The current system I use takes about 220MB of RAM and about 15min on an underpowered netbook. (It is not Linux but still has decent hardware support.)
Of course I'm also curious what other folks who compile their own Linux kernels see as their "minimum" requirements.
Yet I'm reading the conversation in full due to the great, knowledgable, and foremost polite discussions. Not having seen this in Hacker News in a long time...
Thank you all
Gonna try it out tonight!
http://wiki.minix3.org/FAQ#What_is_the_performance_of_MINIX_...
They run the backend of much of the airline industry (former delta employee).
Edit:
Links with more information for those not aware of these behemoths:
http://en.wikipedia.org/wiki/NonStop
http://h17007.www1.hp.com/us/en/enterprise/servers/integrity...