;)
I don't think what the iphone supports will matter much in the long run, it's what devices like these nokias that will have the biggest impact on the future of mobile http://www.nokia.com/A4405104
———
No one is going to stop developing in Flash or Java just because it doesn't work on iPhone. Those who wanna cater to the iPhone market will make a "watered down version" of the app. Just the way an m site is developed for mobile browser.Thats it.
——
If another device maker come up with a cheaper phone with a more powerful browser, with support for Java and Flash, things will change. Always, the fittest will survive. Flash and java are necessary evils(if you think they are evil).
——
So it will take 1 (one) must-have application written in Flash or Java to make iPhone buyers look like fools? Sounds okay to me.
——
The computer based market will remain vastly larger than the phone based market. I don't have real numbers off hand, but lets assume 5% of web views are via cellphones
I did re-read that section again 25 years later...
I mean, here's a piece of mine from 25 years ago.
https://archive.org/details/PersonalComputerWorldMagazine/PC...
I stand by that.
But I wrote things for the Register when I started there full-time 3.3 years ago that now I look at with some regret. I'm learning. I'm changing.
We all learn and we all change. That is good. When you stop changing, you are dead.
Don't be worried about changing your mind. Be worried about if you stop doing so.
Imagine if you don't learn anything new in the next 25 years, and all your opinions stay completely stagnant. What a waste of 25 years that will be.
I remember when the first iPhone was released in Jan 2007 that Jobs said all the non-Apple apps would be HTML based.
I thought it was dumb. Release a development environment and there will be thousands of apps that do stuff they couldn't even think of.
The App Store was started in July 2008.
The husk of slashdot is still around.
While I could go into a long story here about the relative merits of the
two designs, suffice it to say that among the people who actually design
operating systems, the debate is essentially over. Microkernels have won.
While the original post was written well before NeXTSTEP, the Mach 3.0 kernel was converted into a monolithic kernel in NeXTSTEP, which later became MacOS. The reality is that Mach 3.0 was just still slow performance wise, much like how NT would have been had they had made it into an actual micro-kernel.
In the present day, the only place where microkernels are common are embedded applications, but embedded systems often don't even have operating systems and more traditional operating systems are present there too (e.g. NuttX).
The original Tanenbaum post is dated Jan 29, 1992.
NeXTSTEP 0.8 was released in Oct 1988.
https://en.wikipedia.org/wiki/NeXTSTEP#Release_history
3.0 was not the conversion into a monolithic kernel. That was the version when it was finally a microkernel. Until that point the BSD Unix part ran in kernel space.
https://en.wikipedia.org/wiki/Mach_(kernel)
NeXTSTEP was based on this pre-Mach 3.0 architecture so it would have never met Tanenbaum's definition of a true microkernel.
> Mach received a major boost in visibility when the Open Software Foundation (OSF) announced they would be hosting future versions of OSF/1 on Mach 2.5, and were investigating Mach 3 as well. Mach 2.5 was also selected for the NeXTSTEP system and a number of commercial multiprocessor vendors.
OSF/1 was used by DEC and they rebranded it Digital Unix and then Tru64 Unix.
After NeXT was acquired by Apple they updated a lot of the OS.
https://en.wikipedia.org/wiki/XNU#Mach
> The basis of the XNU kernel is a heavily modified (hybrid) Open Software Foundation Mach kernel (OSFMK) 7.3.[3] OSFMK 7.3 is a microkernel[6] that includes applicable code from the University of Utah Mach 4 kernel and from the many Mach 3.0 variants forked from the original Carnegie Mellon University Mach 3.0 microkernel.
> The BSD code present in XNU has been most recently synchronised with that from the FreeBSD kernel. Although much of it has been significantly modified, code sharing still occurs between Apple and the FreeBSD Project as of 2009
Back in the late 2000's Apple hired some FreeBSD people to work on OS X.
Before Apple bought NeXT they were working with OSF on MkLinux which ported Linux to run on top of the Mach 3.0 microkernel.
https://en.wikipedia.org/wiki/MkLinux
> MkLinux is the first official attempt by Apple to support a free and open-source software project.[2] The work done with the Mach 3.0 kernel in MkLinux is said to have been extremely helpful in the initial porting of NeXTSTEP to the Macintosh hardware platform, which would later become macOS.
> OS X is based on the Mach 3.0 microkernel, designed by Carnegie Mellon University, and later adapted to the Power Macintosh by Apple and the Open Software Foundation Research Institute (now part of Silicomp). This was known as osfmk, and was part of MkLinux (http://www.mklinux.org). Later, this and code from OSF’s commercial development efforts were incorporated into Darwin’s kernel. Throughout this evolutionary process, the Mach APIs used in OS X diverged in many ways from the original CMU Mach 3 APIs. You may find older versions of the Mach source code interesting, both to satisfy historical curiosity and to avoid remaking mistakes made in earlier implementations.
So modern OS X is a mix of various code from multiple versions of Mach and BSD running as a hybrid kernel because as you said Mach 3.0 in true microkernel mode is slow.
One of the reasons for the Windows 11 hardware requirements, is that nowadays Windows always runs as a guest OS.
I still hand this out to younger software engineers to understand the true principle of architecture. I have a print off of it next to my book on how this great new operating system and SDK from Taligent was meant to be coded.
Same question for the iphone. There are some link from HN where people saying iphone is dead bcs it does not support flash. But it didnt. Why it didnt?
İs performance really the only key factor when it comes to software design ?
BSD was mired in legal issues, the commercial Unix vendors were by and large determined to stay proprietary (only Solaris made a go of this and by that time it was years too late), and things like Hurd were bogged down in second-system perfectionism.
Had Linux started, maybe, 9 months later BSD may have won instead. Had Larry McVoy's "sourceware" proposal for SunOS been adopted by Sun, perhaps it would have won out. Of course, all of this is impossible to predict. But, by the time BSD (for example) was out of the lawsuit woods, Linux had gained a foothold and the adoption gap was impossible to overcome.
At the end of the day, I think technical details had very little to do with it.
I started running Linux in October 1994.
One of the main reasons I chose Linux over Free/NetBSD was the hardware support. Linux supported tons of cheap PC hardware and had bug workarounds very quickly.
I had this IDE chip and Linux got a workaround quickly. The FreeBSD people told me to stop using cheap hardware and buy a SCSI card, SCSI hard drive, and SCSI CD-ROM. That would have been another $800 and I was a broke college student.
https://en.wikipedia.org/wiki/CMD640
Linux even supported the $10 software based "WinModem" I got for free.
But why linux won? We know now it won, but what is the reason. Tanenbaum was theoraticaly correct. İf HN exist back then, I would argue most devs here would say Minix will last longer, monolithics is indeed an old idea that had been tried and tested etc.
İs performance really the only key factor when it comes to software design ?
It seems to me that the microkernel idea came from observing that virtual memory protection made life easier and then saying “what would life be like if we applied virtual memory protection to as much of the kernel as we can”. Interestingly, the original email thread shows that they even tried doing microkernels without virtual memory protection in the name of portability, even though there was no real benefit to the idea without virtual memory protection, as you end up with everything being able to write to each other’s memory anyway such that there is no point,
Same question for the iphone. There are some link from HN where people saying iphone is dead bcs it does not support flash. But it didnt. Why it didnt?
This doesn't just apply to kernels. It applies to anything in software; writing a huge monolith of intertwined code is always going to be faster than writing separate components with clear API boundaries and responsibilities.
Of course, monolithic software ends up being less safe, less reliable, and often messier to maintain. But decoupled design (or micro-kernels) can take SO MUCH longer to develop and implement, that by the time it's close to being ready, the monolithic implementation has become ubiquitous.
He was only correct in a world where programmer and cpu time is free and infinite.
> As a result of my occupation, I think I know a bit about where operating are going in the next decade or so.
The gap between industry and academia must have been less well recognized at this stage. I think of PL researchers today, most of whom would not confidently assert they know the way programming languages will go—they'd instead confine themselves to asserting that they know where PLs ought to go, while acknowledging that the industry doesn't tend to care at all what PL researchers think a PL should look like.
One thing I'm curious about is why the industry-academia gap is so large? Is this true in other disciplines? I'd expect some baseline level of ivory-tower effect in any industry, but I'd also expect there to be a significant number of people who actually do cross the gap and make an effort to study the way things actually work rather than just the way they theoretically ought to work.
Where are the OS researchers who research why Linux won? Where are the PL researchers who study what makes a great industry language?
But well, that's just some of the gap. The truth is that most of what the industry does is chosen by really stupid reasons (or some times raw corruption), where the people making the choice has no power to fix any problem, and the problems are kept there by people not interested on improving anything.
If you want to research why the industry does what it does, you should study political science, not anything related to IT.
The tech lead on my team was a college professor for a while before joining us, and he occasionally got in spats with one of the other more senior folks on our team, which could be oversimplified to "correct vs pragmatic".
However, they also respected each other and always resolved it amicably in the end.
A couple of times I thanked them both for working through it and pointed out that I think we end up with significantly better software as a result, even if getting there was difficult.
I learned a lot from both of them.
Perhaps it's possible to close this gap, and make an OS or PL that combines new actually-good ideas with great execution, but there may just not be enough of a push by any party to do so. Or perhaps there's just too much disdain in both directions. (Those dumb enterprise programmers, toiling with Java and Windows because they can't be bothered to learn anything better! / Those dumb researchers, getting grant money to come up with abstract nonsense that no one asked for and no one else will seriously use!)
Also, especially in PL research, a lot of the language useful for expressing novel ideas is very different from the kinds of documentation used in practical applications. Research-oriented people will swear that it's great because of how precise it is (e.g., https://news.ycombinator.com/item?id=42918840, on the WASM Core Specification), but it's hardly like precision must be at odds with accessibility to a wider audience.
As you said, he may have been right about where things “ought” to go. In that way, it is the same as an engineer telling you that they know where their field will go in 10 years. They are often wrong when they forget that technology is not the only force at work.
Why Linux won is good history to know but few of the reasons will advance OS research.
He was probably not wrong that microkernels as the future in that most new OS projects will use that design at some point. Just like most dev will be in memory safe languages at some point. Look at Redox, using both a microkernel and Rust.
The trick is that recognizing that “at some point” may not be now even if you are right. As Keynes said about investing (also future prediction), “the market can stay irrational longer than you can stay solvent”.
Also note that the design of Linux itself changed after this debate as well. The system of pluggable modules is not a microkernel but it is not exactly a true monolithic kernel either. We do mot “compile in” all our device drivers. Also, the FUSE user mode filesystem looks pretty microkernel-like to me.
Microkernels have a lot of advantages. Enough that Andrew T thought they were the obvious choice. So did HURD. They are also harder to implement. In this era for easy virtual machines, containers, and the cloud, I think it is a lot easier. It was a lot harder when Linux was being written in-place of 386 PC hardware. More importantly, microkernels are a bit less efficient. Again, that does not matter quite as much today in many cases. The kernel itself is only using a tiny fraction of your memory and CPU capacity. In the era of 386 hardware with while digit megabytes of RAM, it still mattered a lot.
Remember that MINIX, the microkernel being defended, got installed in very Intel CPU for years. There may have been more instances of Minix than there was of Linux.
Also, I do not think that Linux “won” because of technology. BSD already existed when Linux was born and for years BSD was clearly technically superior. Linux got the momentum and the mindshare. Why? I think the AT&T lawsuit was the primary factor. A lot of other proper credit the GPL. Few would argue it was because Linux was better back then.
Why Linux won is not going to advance OS research. Companies kirk Microsoft and IBM have big “research” arms that produce “working” tech all the time that showcase ideas that are “the future”. It is not like these companies frequently throw-out their successful products every time this happens. But ideas do trickle in. And as I said above, even Linux has borrowed from the “losing” ideas showcased in “Linux is obsolete”.
In the 1990's the XFree86 X11 server ran as root as a userspace process. I remember people wanting to move graphics into the kernel and Linus said something like "You all think microkernels are better with userspace device drivers, well XFree86 is a user space device driver."
We used to have 10 different X servers for each graphics chip and a symlink from X to the one for the card you have installed.
Since then we got DRI in the kernel for graphics but it was a debate for a while.
GGI was another effort to put graphics into the kernel. There are some quotes from Linus in this article.
Tanenbaum: Microkernels are superior to monolithic kernels.
Torvalds: I agree— so go ahead and write a Production microkernel…
14 years ago (2011) this thread happened on reddit:
https://www.reddit.com/r/linux/comments/edl9t/so_whats_the_d...
Meanwhile in 1994 I knew people with working linux systems.
According to some people I've met who claimed to witness things (old AI Lab peeps) the failure started with initial project management and when Linux offered alternative GPLed kernel to use, that was enough to bring the effort even more to halt.
He has though. Tanenbaum's created the most popular production OS in the world, and it's microkernel based: https://www.networkworld.com/article/964650/minix-the-most-p...
Last post is from 2016. Any news on MINIX front?
Tannenbaum must be threatened by the growing linux community to start throwing flamebaits like this.
The best performance for IPC is achieved indeed as you say, using shared memory between the communicating parties.
But once you have shared memory, you can implement in it any kind of concurrent queue you want, without any kind of overhead in comparison with in-process communication between threads.
While other kinds of IPC, which need context switches between kernel and user processes, are slow, IPC through shared memory has exactly the same performance as inter-thread communication inside a process.
Inter-thread communication may need to use event-waiting syscalls, which cause context switches, but these are always needed when long waiting times are possible, regardless if the communication is inter-process or inside a process.
Mach and other early attempts at implementing micro-kernels have made the big mistake of trying to do IPC mediated by the kernel, which unavoidably has a low performance.
The right way to do a micro-kernel is for it to not handle any IPC, but only scheduling, event handling and resource allocation, including the allocation of the shared memory that enables direct communication between processes.
Got to put all that monolithic kernel performance to good use. /s
I haven't read this specific link, but I remember few chosen quotes about how Minix had no "multithreaded VFS" while Linux's monolithic approach meant one was available for free (minus locking).
To make it more accessible (because when I first read that comparison I didn't grok it either), the issue is that Minix filesystem server was single threaded and handled one operation, one by one. Linux VFS mechanism (and all "basic" operations triggered by syscalls) run in the thread of the user process that calls them. This means that I/O on minix was starved on single queue of a separate process with effectively no preemption, while on linux at worst you'd run out of scheduler quanta and be descheduled when the VFS op finished instead of getting immediate answer.
This is also why BeOS/Android Binder and Solaris (and Spring) Doors system provide multiple threads to handle incoming requests, with Solaris/Spring also "patching over" one's context to minimize amount of work involved in switching them.
The other part is the UNIX server manufacturers falling behind on performance versus Intel and their fab prowess and AMD with their x86-64 architecture. Sun Microsystems went from being the second highest market cap in tech in 2000 to being bought by Oracle in 2009.
What's the point of an OS if it doesn't have drivers for your hardware?
what a way to argue...
In the grand scheme of things, the whole thread is still pretty tame for a usenet argument and largely amounts to two intelligent people talking past each other with some riffing and dunking on each other mixed in.
Makes me come back and appreciate the discussion guidelines we have on this site.
You need to understand the theory and the design if you want to design something that will last for generations without becoming a massive pain to maintain.
Linux now is a massive pain to maintain, but loads of multi-billion-dollar companies are propping it up.
If something only keeps working because thousands of people are paid to labour night and day to keep it working via hundreds of MB of patches a day, that is not a demo of good design.
Not only does microservices and Kubernetes all over the place kind of diminishes whatever gains Linux could offer as monolithic kernels, the current trend of cloud based programing language runtimes being OS agnostic in serverless (hate the naming) deployment, also makes irrelevant what is between the type-2 hypervisor and language runtimes.
So while Linux based distributions might have taken over the server room as UNIX replacements, it only matters for those still doing full VM deployments in the style of AWS EC2 instances.
Also one of the few times I agree with Rob Pike,
> 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.
> At the risk of contradicting my last answer a little, let me ask you back: Does the kernel matter any more? I don't think it does. They're all the same at some level. I don't care nearly as much as I used to about the what the kernel does; it's so easy to emulate your way back to a familiar state.
-- 2004 interview on Slashdot, https://m.slashdot.org/story/50858
Explicit enough?
Such is the irony of using a monolithic kernel for nothing.
As for Windows, not only has kept its hybrid approach throughout the years, Windows 10 (optionally) and Windows 11 (enforced), runs as a guest on Hyper-V, with multiple subsystems sandboxed, DriverGuard, Virtualization-Based Security, Secure Kernel, UMDF.
So glad we’ve moved past being blinded by computing fads the way Tanenbaun was.
> MINIX was initially proprietary source-available, but was relicensed under the BSD 3-Clause to become free and open-source in 2000.
That is a full eight years after this post.
Also from Wikipedia on Linux becoming FOSS [1]:
> He [Linus Torvalds] first announced this decision in the release notes of version 0.12. In the middle of December 1992 he published version 0.99 using the GNU GPL.
So this post was essentially right at the cross roads of Linux going from some custom license to FOSS while MINIX would remain proprietary for another eight years, presumably long after it had lost to Linux.
I do wonder how much of an effect, subtle or otherwise, the licensing helped or hindered adoption of either.
I didn't heard about Minix until mid 2000's maybe, and it was like an old legend of an allegedly better-than-linux OS that failed because people are dumb.
The folklore around the Linux/Minix debate, for me, was that "working code wins" and either microkernel wasn't as beneficial as was claimed or through grit and elbow grease, Linux pushed through to viability. But now I wonder how true that narrative is.
Could it have been that FOSS provided the boost in network effects for Linux that compounded its popularity and helped it soar past Minix? Was Minix hampered by Tanenbaum gatekeeping the software and refusal to cede copyright control?
To me, the licensing seems pretty important as, even if the boost to adoption was small, it could have compounding network effects that helped with popularity. I just never heard this argument before so I wonder how true it is, if at all.
The first Linux license was that you could not charge for Linux. As it grew in popularity, people wanted to be able to charge for media (to cover their costs). So, Linus switched to the GPL which kept the code free but allowed charging for distribution.
> How I hated UNIX back in the seventies - that devilish accumulator of data trash, obscurer of function, enemy of the user! If anyone had told me back then that getting back to embarrassingly primitive UNIX would be the great hope and investment obsession of the year 2000, merely because it's name was changed to LINUX and its source code was opened up again, I never would have had the stomach or the heart to continue in computer science.
> Why can’t anyone younger dump our old ideas for something original? I long to be shocked and made obsolete by new generations of digital culture, but instead I am being tortured by repetition and boredom. For example: the pinnacle of achievement of the open software movement has been the creation of Linux, a derivative of UNIX, an old operating system from the 1970s. It’s still strange that generations of young, energetic, idealistic people would perceive such intense value in creating them. Let’s suppose that back in the 1980s I had said, “In a quarter century, when the digital revolution has made great progress and computer chips are millions of times faster than they are now, humanity will finally win the prize of being able to write a new version of UNIX!” It would have sounded utterly pathetic.
- Jaron Lanier
Where are our lisp machines? Our plan9? Our microkernels? The first (mainstream) half-interesting OS we've seen in decades is NixOS and that's still got linux under the hood as a compromise [2]. At least this space is lively right now, and maybe something like nix will let us use some of the good software on whatever interesting project comes next.
[1] https://www.edge.org/conversation/jaron_lanier-one-half-a-ma...
[2] linux under NixOS isn't actually a hard requirement. There's no reason a brand new kernel can't be used. There are currently a few small projects that use rust-based non unix microkernels and other interesting experiments.
Intel likely "only" has hundreds of millions of CPUs deployed out there.
Ok, I take it back. Linux is the undisputed champion of the world.
Also there's https://groups.google.com/g/comp.os.minix/c/wlhw16QWltI/m/tH.... It was, unfortunately, not this young lad's last flamefest. See second sentence of last paragraph.
Goodness, the internet really was a nicer place back then. Nowadays, you quote forum etiquette on someone and you get called an idiot for it. I'm touching grass today and I'm gonna be grateful for it.
Sometimes the only good way was to test all possible names with speaker-test or the like.
Took me a month to port an existing driver to me cheaper unknown brand sound card, in 1995.
Got the CD from an OS book. Kernel internals maybe? Doesn't matter, the book was enough to understand enough of the kernel to, by trial and error, stumble upon the correct way to talk to the sound card.
https://www.eternal-september.org/
I did and checked some tech newsgroups I used to read 25 years ago. It was 99% political spam. Basically unusable.
Toasters are also obsolete, academically. You couldn't publish a paper about toasters, yet millions of people put bread into toasters every morning. Toasters are not obsolete commercially, economically or socially. The average kid born today will know what a toaster is by the time they are two, even if they don't have one at home.
His view is that it was moronic because communicating vessels had already been known for centuries.
I tried arguing that maybe they didn't have the materials (pipes), or maybe dealing with obstructions would have been difficult, etc. After all, this was a remote location at that time.
I think that the person who built it probably didn't know about communicating vessels but that it is also true that the aqueduct was the best solution for the time and place.
Anyway, debating academics about practical considerations is hard.
https://dreamsongs.com/RiseOfWorseIsBetter.html
Gabriel was right in 1989, and he's right today, though sometimes the deciding factor is performance (e.g. vs security) rather than implementation simplicity.
Windows in comparison has none of that. The design is complex from the start, is poorly understood because most knowledge is from the NT 4.0 era (when MS cared about communicating about their cool new kernel), and the community of people who could explain it to you is a lot smaller.
It's impressive what the NT Kernel can do. But most of that is unused because it was either basically abandoned, meant for very specific enterprise use cases, or is poorly understood by developers. And a feature only gives you an advantage if it's actually used
The Tanenbaum-Torvalds Debate - https://news.ycombinator.com/item?id=39338103 - Feb 2024 (1 comment)
Linux Is Obsolete (1992) - https://news.ycombinator.com/item?id=38419400 - Nov 2023 (2 comments)
Linux Is Obsolete (1992) - https://news.ycombinator.com/item?id=31369053 - May 2022 (2 comments)
The Tanenbaum – Torvalds Debate - https://news.ycombinator.com/item?id=27652985 - June 2021 (7 comments)
The Tanenbaum-Torvalds Debate (1992) - https://news.ycombinator.com/item?id=25823232 - Jan 2021 (2 comments)
Tanenbaum–Torvalds_debate (Microkernel vs. Monolithic Kernel) - https://news.ycombinator.com/item?id=20292838 - June 2019 (1 comment)
Linux is Obsolete (1992) - https://news.ycombinator.com/item?id=17294907 - June 2018 (168 comments)
The Tanenbaum-Torvalds Debate (1992) - https://news.ycombinator.com/item?id=10047573 - Aug 2015 (1 comment)
Linux is obsolete – A debate between Andrew S. Tanenbaum and Linus Torvalds - https://news.ycombinator.com/item?id=9739016 - June 2015 (5 comments)
LINUX is obsolete (1992) - https://news.ycombinator.com/item?id=8942175 - Jan 2015 (74 comments)
The Tanenbaum-Torvalds Debate (1992) - https://news.ycombinator.com/item?id=8151147 - Aug 2014 (47 comments)
Linux is obsolete (1992) - https://news.ycombinator.com/item?id=7223306 - Feb 2014 (5 comments)
Tanenbaum-Linus Torvalds Debate: Part II - https://news.ycombinator.com/item?id=4853655 - Nov 2012 (2 comments)
"LINUX is obsolete" - Andy Tanenbaum, 1992 - https://news.ycombinator.com/item?id=3785363 - April 2012 (14 comments)
Why was Tanenbaum wrong in the Tanenbaum-Torvalds debates? - https://news.ycombinator.com/item?id=3744138 - March 2012 (54 comments)
Why was Tanenbaum wrong in the Tanenbaum-Torvalds debates? - https://news.ycombinator.com/item?id=3739240 - March 2012 (1 comment)
Linux is Obsolete [1992] - https://news.ycombinator.com/item?id=545213 - April 2009 (46 comments)
If only he knew...
https://www.ibiblio.org/pub/historic-linux/ftp-archives/suns...
Further proof that computer "science" is a nonsense discipline. ;-)
The World Wide Web was invented at CERN, a particle physics laboratory, by someone with BA in physics. Who later got the Turing award, which computer scientists claim is somehow equivalent to a nobel prize.
Prof. Tanenbaum (whose degrees are also in physics) wasn't entirely off base though - Linux repeated Unix's mistakes and compromises (many of which were no longer necessary in 1992, let alone 2001 when macOS recycled NeXT's version of Unix) and we are still suffering from them some decades later.
But either way these both boil down to bytes loaded in memory, being executed by the cpu. The significant thing about a microkernel is that the operating system is organized into functional parts that are separate and only talk to each other via specific, well defined channels/interfaces.
Microkernel uses processes and messages for this, but that’s hardly the only way to do it, and can certainly be done in a bunch of units that happen to be packaged into the same file and process. C header files to define interface, C ABI to structure the channels, .c files for the separate pieces.
Of course you could do that wrong, but you could also do it right (and, of course, the same is true of processes and messages).
A process, btw, is an abstraction implemented by the os, so microkernel or not, the os is setting the rules it plays by (subject to what the CPU provides/allows).
I’m not sure one necessarily qualifies you to know the other… there always seems to be a lot of arrogance in these circles.
> There are really no other alternatives other than Linux for people like me who want a "free" OS.
What a minute. What about FreeBSD?
[Update: Never mind. I realized later this thread was written about a year before FreeBSD was first released.]
Linux is still obsolete.
Today seL4 carries the flag.
" Things like paradigmatic ways of doing open source software development took 20 years to dominate because the longevity and applicability of the more abstract solutions is on the same time frame as their implementations. But within that exists lower-level Maslovian motivations.
And keeping things there makes them more actionable. Let’s say your network card isn’t sending out packets. We can say this bug is known, agreed upon, and demonstrable. So although it may not be easy, the labor path is traversable.
A new network card comes out, you need it to work on Linux. That’s a need. You can demonstrate and come to an agreement on what that would look like.
Pretend you want that network card to do something it wasn’t designed to do. That’s harder to demonstrate and agree upon.
To get that actionable you need to pull the desire into the lower curve so that a development cycle can encompass it.
VVV here's where it comes in VVV
It’s worth noting the Tannenbaum-Torvalds debate from 1992 to illustrate this. Tannenbaum chastised Torvalds approach because it wasn’t a microkernel and Linux was exclusive to the 386. Really Linus was in these lower curves and Tannenbaum was trying to pull it up to the higher curves where things move far slower. That’s where the hot research always is - people trying to make these higher level concepts more real.
GNU/Hurd is a microkernel approach. Stallman claimed in the early 2000s that’s why it was taking so long and wasn’t very stable.
The higher level curves are unlikely to succeed except as superstructures of the lower level functions in the same way that our asymmetric approach to platonic ideals happens on the back of incrementally more appropriate implementations which is why you can snake a line from 1950s IBM SHARE to GitHub.
Through that process of clarifying the aspirations, they get moved to the concrete as they become material needs and bug problems.
The clarity of the present stands on both the triumph and wreckage of the past. For example, the Mach 3 micro-kernel led to Pink, NextStep, Workplace OS, Taligent, and eventually XNU which is part monolithic and is now the basis for macOS. To get there that curve burned over a decade through multiple companies and billions of dollars. Also the OSF group I mentioned before had a Mach-BSD hybrid named OSF/1. Apple was going to use it in an alliance with IBM but that got canceled. It went on to become Tru64 whose last major release was in 2000, 24 years ago, to add IPv6 support.
How’s that transition going?"