I've upvoted this because I would like to see minix succeed and for nostalgic reasons but I can't help the feeling that minix has missed its window of opportunity. In practically every arena where minix could have established itself there are now formidable entities entrenched with mindshare, budgets and an installed base that minix can't even begin to touch. I've got similar feelings towards plan 9.
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 wonder if it would have ever reached mass adoption. While stability is important, the performance impact due to context-switches might have been big enough for many use-cases.
That performance impact is a total myth. There are quite a few ways in which you can mitigate a large part of that and in actual use things like latency (which microkernels are very good at), soft-real time performance and context switch speed are far more important than raw throughput.
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'm a firm believer (ok, a wannabe believer) that one day the "whole goddamn corrupt temple" will collapse under the weight of its own complexity; and then we will go back to simpler, cleaner fundamentals. Maybe that will be the time of Minix. But maybe not, maybe it'll be the time of Mirage OS instead.
I really wonder what the overlap between Minix and Mirage are btw. Could Minix be used like Mirage as a minimal application-specific OS?
The accumulated filth of all their drivers and patches will foam up about their waists and all the programmers and sysops will look up and shout "Save us!"... and we'lll look down and whisper "No."
I'm not an OS designer or OS programmer so I'm just arm-chairing here.
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!
> 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!
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...
Torvalds' argument wasn't that microkernels were slower though. It was that distributed algorithms are harder than shared memory algorithms.
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.
While I appreciate the lyricism, I'm not sure this is an apt metaphor. After all, you can deflect laster pistol shots with a lightsaber, but you can't hardly deflect a lightsaber using a laser pistol.
But honestly, I'd rather learn to use the force. Better get that midichlorian shot.
I may have the Plan 9 books on my shelf, but I too think that it is sad that Minix didn't succeed. Nonetheless, the grant from the European Union to fund further development of Minix is something really remarkable. With this Minix got a fair bit of fresh air and much needed work to bring it into this century :)
Personally, I'm excited to try it out on a BeagleBone Black and tinker around a bit with it. It just has been too long since OS-dev was fun!
> try it out on a BeagleBone Black and tinker around a bit with it
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?
It's basically for the fun of it. Trying out exotic hardware and getting out of your comfort-zone. For me it's just exploring things and maybe a reason to dust off those gadgets and play around with them.
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.)
VMs behave very different from real hardware. VMs are convenient have some very nice features, e.g. GDB debugging with QEMU. But if you're doing anything with hardware, you'll have to test on real hardware or everything will break the moment you do.
"minix has a spot, and that spot is in education,"
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 microkernel idea is pretty much dead outside the ivory tower, as in practice it didn't work
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.
I guess what I'm getting at, is in a fair fight, an open source monolithic always works better than an open source microkernel. Behind closed doors decisions always have other concerns... licensing, support contracts, standardized docs, porting assistance, the list goes on and on.
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.
Minix is not at all the best example of a microkernel, which is why I have yet to see it in production. QnX is an example of a best-of-breed microkernel and the thing is for want of a better word indestructible. We ran large clusters (for the day) of these and there has never been a documented case of a crash of a kernel that was not hardware related. Pretty impressive given the number of transactions that we would push through those boxes.
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.
A very large message switch with very harsh penalties in case it was down. At some point in time it brokered a substantial portion of the worlds shipping tonnage.
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).
Cool. Probably compares more favorably with them than you are letting on. The volume you seem to be implying sounds very impressive.
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.
I find that hard to grok following an admission that erlang could be used to architect systems using similar ideas. :(
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.
At that time it was the only way we could have done it that I'm aware of. We're talking 1985-1989 here! Feel free to disagree with decisions made almost 30 years in the past.
I'm not disagreeing with the decision at the time. Merely saying that the key was not that it was at the OS level. The key seems more that the rest of the details were in place. (If that makes sense.)
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.
Well, you're arguing against someone with 30+ years in software development who actually built stuff using microkernels and macrokernels and who wrote an OS on top of that. That's as shallow an appeal to authority as you'll ever get from me but frankly what your thoughts are does not trump my personal experience to me. In practice microkernels are not overly restrictive and they make things about as easy as they could possibly be. Those things that I happened to do at the time. (Such as, but not limited to: routers, device drivers, image recognition, mail, networking, a supervisor system, logging, reliable storage and on and on, basically everything that goes into a cluster based chunk of enterprise level software with a very specific goal).
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.
I don't get your point. You are doing an appeal to authority, yet you seem to be literally arguing with history and entire industries as to what can make a very scalable system. Or, is your argument that Twitter would be more reliable if it were done with QNX? What about Amazon? Google? Any behemoth out there?
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.)
I've sent a bunch of letters to Quantum software when they still owned it about open sourcing QnX but they never bit. In spite of substantial backing and a pretty good plan (a redhat like model) there was absolutely no interest.
> Nearly every router with >1GB/s ports run a microkernel.
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?
This point is easy to mislead, though. Consider, the android kernel is probably rapidly growing in the realm of what would have once been considered for embedded kernels.
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'm given to understand that on many phones Android runs in the application core on top of an L4 kernel, which provides resources to Android but also controls the various DSP and embedded cores.
> 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.
I'm one of those people, actually. To the point that I now just use emacs at work. Have slowly started using it for all things. Email, irc, im, etc. Is very very nice. Always amusing to hear folks talk about how limited it is.
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.
Android is not a good example, for one, the usecase is almost no different to the desktop, except for the issue with power efficiency . secondly, the real time part of the system, ie. the controllers, doesn't run android. It rather runs L4 in the baseband processor - a microkernel.
I think this response actually came later. Apologies for that to the other poster.
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.
Most of the symbian devices are being replaced by android phones not windows phones.
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'm sorry, i love talking semantics and that's what this discussion is, if you question the meaning of embedded. That word is not well defined, afaict, and i was just trying to add some perspective.
> 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.
I belive that AmigaOS was based on microkernel ideas. Not pure, but very near. And it was working very well. My Amiga 1200 boot ups much more faster that Windows or Linux in my moderm quad core machine
>The microkernel idea is pretty much dead outside the ivory tower, as in practice it didn't work,
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.
> And so now we have 70's era tech instead of 90's.
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.
> You don't seem afraid of angering people with comments like that.
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.
> 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.
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.
I expect a port to the Raspberry Pi will happen. The supported boards are all ARM v7, but the Pi is v6 and that is probably the reason it's not supported right out of the gate.
The problem is the copyright:
"Design (c) 2011, 2012 Raspberry Pi Foundation
All Rights Reserved"
As far as I know the schematics are not open-source, i.e. there's no right to use them other than as documentation for the (proprietary) Raspberry Pi-manufactured board. The BeagleBone, on the other hand, has an open-source license for their schematic under Creative Commons Attribution-Share Alike 3.0 Unported License.
If the spot is education, I should say it has failed (maybe not in the US, I don't know there).
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.
I think you misunderstood the use of the word education here. The grand-parent post did not mean the education community as a whole that is using (or even knows) Minix, but just that Minix is used to educate. Specifically educate Computer Science students on how OS's work.
I believe the OS succeeding in enterprise environment largely dependent on company adoptions. The most objective way to evaluate that for me is look at the # jobs post for that particular language/os/framework in various job site.
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.
I'd love to wipe the dust off a bunch of the old research OSes from the 90s. Amoeba, which gave birth to Python, is another OS from Tanenbaum that I feel died much too soon of a death due to the goliath that Linux became. There are so many tantalizing bits and pieces about the network transparency so many of those research OSes offered that have shamefully been left by the wayside.
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.
Not only that, but we're even seeing an opposite trend where people are now actually starting to tear down and attack the principles of Unix that were once so cherished. The only problem is they're doing it in favor of adopting concepts from consumer operating systems, which is even worse than sticking to the aging primitives of the 1970s, as the latter at least provide a coherent model.
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.
The Sapir-Whorf hypothesis is a bit dated. Comparative linguistics has shown very convincingly that pretty much all languages have a similar set of complex features.
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.
I think path dependence and software affordances are sufficient to explain why bad ideas seem to mutate and grow; no need to reach for Sapir-Whorf. It is a lovely metaphor, however.
In your opinion, what would be the advantages of a Mac OS X based on BeOS rather than BSD Unix? Or is your point merely that a Unix monoculture is inherently bad? (I think it's more like a common ancestor than a monoculture, though perhaps the descendants haven't diverged very far.)
Diversity. It would have been BeOS vs UNIX vs Windows, instead of UNIX vs Windows on the desktop.
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.
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?
> Which part? IOKit, for writing kernel drivers for Darwin's xnu kernel is C++.
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.
> 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.
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.
> I guess I don't see as being "way" safer than C.
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.
> I cherish Microsoft for its work in Windows, it is the only mainstream OS that can save us from UNIX monoculture.
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.
Like you, I discovered Linux in 1998 and have personally used it exclusively since. I get as many people off the MS and Apple treadmill and onto Libre/OSS as I can, especially in SOHO settings. I've yet to not be able to do something I needed done in Linux, even if it did take a bit more time or effort initially.
It's funny, I have an easier time getting friends/family on to a usable Linux OS than myself. I tend to use windows on the desktop (more about cost/value) and OSX for my laptops... I run Linux for my HTPC, and on servers.
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.
I don't know when you last looked at FreeBSD/PC-BSD but there's been improvement in graphics performance, and driver coverage in general, though admittedly not as much as Linux, Windows, etc.
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.
Yeah, it's been a while since I've looked... I really need to have a good multi-platfrom VM host in whatever environment I use... usually VMWare, because I do a lot of work that brings me into windows, mac and linux which was the biggest drawback last I looked.
It will be cool to see what happens in the next couple years though.
> Yes, UNIX has a bunch of nice ideas, but that is all.
Ouch, that actually hurts a little.
Yes, the kernel team at Microsoft is the real deal, but I'll not go into that.
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 cherish Microsoft for its work in Windows, it is the only mainstream OS that can save us from UNIX monoculture.
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.
I don't think it's the paradox of choice at work. I think instead that the set of file operations happens to permit arbitrary interaction with an object. Specifically, file operations already represent:
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.
Depending on how it's implemented, there's no real reason why it couldn't be done. For example, I could create SceneGraph_fs, which exposed the scene graph of objects as a directory hierarchy. The filesystem's toplevel directory would be organized with a /scenegraph/ directory for the scenegraph, /lights/ for the light models, and /tmp/ for a scratch space for constructing objects and staging them to be added. Each node in the scene graph would be represented by a directory under /scenegraph/ which contained one file for each distinct chunk of data the graphics engine would need to know (like a position matrix, an orientation matrix, a mesh model, a texture map, etc., depending on whether or not the directory represented a model or a transformation).
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.
Right. My point is that you have to make your operations fit within that language. As opposed to the object metaphor, where you get to define the language however you want.
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?
> 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.
Until you start doing IPC between processes, IOCTL, heavy graphics programming and there goes the abstraction.
That's an over-simplification, as when you get down to it, there are plenty of things that don't use the file API on UNIX, or at least have convenient wrappers so you're not blindly calling 'ioctl' left and right. I'm thinking specifically of the socket API for bind/connect/accept, the inotify interface, with inotify_* functions, the (less commonly used these days) serial port API, with the tc* and cf* functions.
> 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).
Everything is a file on a FS - so-called permanent storage.
Everything is an object - where? in memory. That's the source of all problems, ORMs, ORBs, persistence layers, etc.
You're saying it as if having a bunch of nice ideas that have been practically implemented is a negligible thing.
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.
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.
>> And so now we have 70's era tech instead of 90's.
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.
> That being said, I would really like to know if Minix tech is better than Linux.
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.
(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.
Out of curiosity, why shouldn't some level of device I/O be handled by the kernel? If the alternative is putting all device I/O responsibility in userspace processes, then wouldn't the kernel still need to do basic driver-related tasks like programming the IOMMU and DMA engine? Even if that's outsource-able to userspace, then wouldn't the kernel still need to run some sort of security-preserving outsourcing logic (e.g. only letting a trusted process access a hardware device)?
Sure, minimal amount needed for safety should be in the kernel. That can also be somewhat federated if you like. Much of a kernel is not hardware access though, it is things like filesystems and sockets way on top of hardware.
Again, you are conflating minix and minix3. Minix3 was never in a lab to outgrow it. It is a new system, developed quite quickly and quite recently. And yes, it is significantly better than linux. Why do you think the device IO calls shouldn't be there? Messaging primitives are present, those calls use them. They are just wrapped in a library for you, like it says right on that page. The "kernel interface" is exposing a unix like API. If you want to send arbitrary messages then you use the low level messaging API.
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.
This is fantastic. I started reading Operating Systems Design and Implementation just a couple of days ago. I can see Minix being my secondary OS as I start to tinker with it especially on microprocessors.
I was one of those who bought books, took weekly reverent hauls at the bookstore, from Prentice Hall, until about twenty plus years ago.
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...
In the specific area of filesystem research, what do you think of FUSE? Particularly high level language bindings, eg fuse-python/fusepy which make it almost trivial to write your own filesystem.
> 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.
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 is not compatible with Win32 global (interprocess) mutexes. After fork succeeds in context of process with acquired global mutex, should parent or child automatically release that mutex?
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).
>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
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.
I'm having the impression that OSes don't really matter for the vast majority of applications anymore; the main advantage of Linux is its licence and development model, by which I mean that it's a commodity. We use high-level languages to abstract away from the OS, and if we want reliability we make distributed systems using technologies like Erlang-OTP or Scala-Akka.
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.
No. If they cared above reliability above all else, they'd be more likely to use something like HP's nonstop systems, which are from their Compaq purchase, where were from Tandem. You can hotswap the motherboards of those things with 0 downtime.
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:
The choice to use a NetBSD userland isn't hugely surprising in light of the project's focus on making everything as clean and portable as possible. Packages also make a lot of sense. NetBSD did something hugely ambitious with Pkgsrc--it is like FreeBSD's ports, but was designed to build software in a coherent fashion on lots of different *nix platforms. At one point in time, I was using pkgsrc to build a somewhat complicated custom stack of open source software on AIX, compiling with IBM's XLC compiler. Can't say everything worked perfectly, but there was so much scaffolding already in place with pkgsrc that it simplified my process immeasurably.
Nice to see they have finally gotten to ARM support. I've worked on an MINIX3 ARM port for my thesis. Got really close to a running system but never got to finishing it after I got my degree.
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.
I'm suspicious that some people complain about dated technology and want something fresh not because the dated tech is obsolete or crippled but because they want to be an expert on new tech, starting from a level playing field and not have to catch up with people with a 20+ year head start.
I'm not understanding much from this thread's conversation. I'm not so interested in OS development (anymore).
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...
From a technological point of view, I think Minix looks really interesting. Especially the feature of a driver being able to crash, and not crashing the entire system. Security is also an added bonus.
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?
You can use the NetBSD drivers pretty much anywhere including in another kernel - see http://rumpkernel.org/ - and they are already using NetBSD userspace code in Minix. I was planning to talk to them at eurobsdcon about this, after a few mailing list conversations.
AFAICS, Minix's model will win in the end because security will be the most important OS feature in the future. It's a matter of time before our life savings (crypto-currencies), all personal info, and even our lives (self driving cars, medical equipment) inevitably becomes dependent on the security of our computer(s).
It would b interesting if minix could reuse the work done on mirageos by importing ocaml and build user space drivers in ocaml to be used by other programs.
178 comments
[ 3.6 ms ] story [ 192 ms ] threadEven 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.
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.
http://mollyrocket.com/casey/stream_0029.html
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...
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://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...
Gonna try it out tonight!
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.
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
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.
[0] https://news.ycombinator.com/item?id=8313144
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.