The type of kernel is orthogonal to this particular design flaw from what I know. It's about how page tables are set up for user mode processes. I may be wrong but pretty much every Unix or Unix-like kernel (including Plan 9) follows the page table model Windows and Linux use: the ring 0 PTEs are present in the page table, even in user mode, and we count on the architecture to prevent ring 3 access to ring 0 memory. This is certainly the case on all the ones I've worked on. I don't think a microkernel would save you. This is not a much ado about nothing case: it's early days and people can make it work: https://twitter.com/brainsmoke/status/948561799875502080

On Wed, Jan 3, 2018 at 12:28 PM, Bakul Shah <bakul(a)bitblocks.com> wrote: ​I agree. We came to the same conclusion in the early/mid 1990's with Mach and Chorus. In fact, the UI 'requirements for modern OS' document (which is part of why AT&T got behind Chorus for the never completed SVR5/R6 stuff - I'll see if I can find a copy) was based on that work. The OS weenies at the time felt that the cost was low enough and hardware cheap enough that of course kernels would be the way to go. AT&T Research has switched to Plan9 and the like, again going 'small and light' as opposed to monolithic and bigger (BSD, Tru64, Solaris, etc). Similarly, Microsoft since Windows (not OS/2) was the UI for NT in the end; Microsoft had to put hacks into the make user code word and NT became a hybrid (like Mach 2.x) and never pushed the pure kernel that Mica (NT's origin had been). To do so would have broken code which at the time was something they were loath to do. Similarly with Apple, when they switched to Next and the Mach family they could have become more 'pure.' Quickly it became a game of 'speed' and the Mach 3.0/4.0 was never fast (or small enough). To their credit, with OSF/RI trying to make a true uK, UI tried to counter with Chorus, but by this time, Solaris was the 'UNIX of Choice' for the AT&T world - which was being driven on high-end/high margin systems. Plus Mach 3.0 was never 'micro.' None of the production Mach folks ever switched to it, because they did not want to pay the performance penalty and we are users never pushed them. Plus, by that time the 386 had become the driver to the community as a whole (certainly the low end/entry systems) and then AT&T suite blew up UNIX in general with the law suite; and Linux came on the scene as the savior. Linus's ​distain for microkernels was understood, but frankly I think has hurt as if a uKernel based FOSS UNIX had been the leader; I wonder if we would still be in the mess we are in. I have personally hoped that something like L4/seL4 with a clean UNIX/Plan9-ish style upper layer might some day be the thing that really wins. Maybe be written in something else - Rust/Go/Kotlin whatever ... But I suspect that will happen long after I'm gone. We keep reinventing the great work Ken, Dennis and Team did years ago and sadly not really doing a good job of learning from our mistakes. Linux (nor Windows) is/are hardly a small, simple system these days. The fact that AMD, Intel *et. al.* optimize the hardware is clearly traditional sustaining engineering right out Christensen's book. The hope is a new disruptive market -- as you say. Maybe Arm/Cell phones will be that. I would not bet against them, but then again. IBM/Intel *et al *have a history of recovering. It is going to be interesting to both watch and play the game for the next few years -- UNIX is hardly dead nor traditional complex systems that run on them, nor the HW that delivers it :-) All that said - the idea is that this HW error we could limit the damage a bit but removing some of the complexity. Their still an open question, if the VM was in a server process, would we completely be free of the error. As I understand it, not completely; but I think the damage/risk/fix would be smaller and easier - which is my primary point. Clem ᐧ

it's implementation dependent, not architecture dependent. RISC-V implementations I've seen don't do the kind of speculation that brought intel to grief. On Wed, Jan 3, 2018 at 10:39 AM Forrest, Jon <nobozo(a)gmail.com> wrote:

On Jan 3, 2018, at 10:27 AM, Clem Cole <clemc(a)ccc.com> wrote: It may be sooner than you think. Now it is much harder to produce faster processors than to produce processors with larger and larger number of cores. For most tasks not *all* of these cores have to work in tandem -- more likely you will run a set of loosely coupled diverse tasks on such a machine. In this scenario it is not clear to me that centralized OSes like like unix/windows can use these cores efficiently. Not even plan9 will do well. In the "cloud" we have already given up on such centralization (though present solutions seem clunky and inefficient). IMHO what we need a much more composable architecture. In Barrelfish, a research OS based on L4, each core has its own ukernel that can be independently brought up. This may be a direction worth exploring[1]. If done right + an orchestration protocol can provide the basis for clean, secure, scalable and resilient distributed systems. a) Actually we don't reinvent their work -- we just keep fiddling at the edges! b) IMHO their work is better thought of as a compositional architecture or service protocol. That is, in a ukernel arch., different user processes can implement different Unix "system call" protocols. There is no reason to stuff all that in a single "kernel". This model actually fits in with what you said (L4/seL4 with a clean UNIX/Plan9-ish style upper layer). [1] My real bias is that even ukernels shouldn't exist! That is, the very core OS function of thread and protection switch should be done in h/w via a few instructions. The *policy* of this is implemented in s/w. Then an OS is just a (set of) shared libraries and a set of initial services. Thinking this way, it is clear that a ukernel is merely implementing this model in s/w and it makes perfect sense for each core to have its own emulation layer! None of above has anything to do with the "intel design flow".

On Wed, Jan 03, 2018 at 06:40:25PM -0500, Theodore Ts'o wrote: To add to Ted's points. I was good friends with one of the core guys on the QNX team a long time ago (he died early in 1998 of brain cancer. Yuck). The QNX micro kernel really was micro, the kernel fit entirely in a 4K instruction cache on x86 (thanks CISC). It did very, very little. It took a lot of thinking and discipline to figure out what the kernel should do and what should be delegated. There was constant pressure to put more stuff in the kernel. My buddy told me that there were only 4 people who were allowed to touch the actual kernel code. And they all both backed each other up and second guessed each other in code reviews. They counted instructions and cache misses each time they changed stuff. As a result, the QNX kernel of the late 1980's and 1990's was super super fast. I ran as much as 10 users logged in to a 80286 running QNX doing text editing and compiles and it actually worked. I'd argue that it worked better than Unix would have worked on that miserable processor. QNX made it work. I think they slowed down when they put full posix in but they made it work. The problem is that most people / companies are not that disciplined. Oh, we need this for $CUSTOMER and this for $BENCHMARK and this for $STANDARD and the easiest way to get it is to shove it into the kernel. I'd argue that microkernels are indeed the best answer but only if you have the best programmers. Which nobody does even though everyone claims they do. Monolithic kernels are far more amenable to less than awesome people messing with them. Sad but true, I'd love a microkernel world but I fear we are too stupid to get it. Something, something, something, this is why we can't have nice things. --lm

On Wed, Jan 03, 2018 at 06:13:59PM -0800, Bakul Shah wrote: Yep, great guy. We could argue long and hard but it was always about the tech, never about the person. An engineer's engineer. Um, I've been reading about Mill for at least a decade. It's not real until it ships. It's still vaporware, no? That's been the claim but there is no data to support that claim. In fact the opposite. History has shown that microkernels can work if you are super super careful. Monolithic kernels work in spite of all the idiots checking in stupid stuff. I *love* the idea of a microkernel with a bunch of processes implementing the OS, it's so much a better design. I also have been in the real world long enough to think that I'm not going to see Linux replaced with a microkernel in my lifetime. I wish, but I don't see it happening. --lm

On 1/3/2018 6:40 PM, Theodore Ts'o wrote: Have you actually priced "Enterprise" level SSD's lately that come with a support contract so that when they hit their end of life, the VAR will replace them? Dell 400GB SLC (Hitachi) in a Compellent, $5K, and that's with an educational discount a couple of years ago. Sure, if you're doing an IOPS/$ comparison, they shine. But for the most part, a Compellent with a few SLC SSDs, and a few MLC SSDs, still needs spinning rust to make the bulk of the storage. And this is a tiny 70TB installation mostly for VMware and Oracle DB. ak

On 1/3/2018 10:21 PM, Dan Cross wrote: Quite true, didn't realize that the context was small-form-factor.

On Thu, Jan 4, 2018 at 6:53 AM, Harald Arnesen &lt;harald(a)skogtun.org&gt; wrote: ​You need to add >>and that he knew about and had access<<. The truth is there was and it had networking and X windows already. Bill Jolitz had completed the original 386 BSD port (and actually started to publish about it in DDJ). The 386BSD sources were available to all BSD licensees - as CSRG had put them on the ucbvax ftp server (truth is they were actually available to anyone there knew how to grab it -- the attempt to keep the ftp address 'secret' was pretty shallow - not quite announced on net.noise but it certainly was passed hacker to hacker if you went to a USENIX conference in those days).​ The funny part was that Linus university was a BSD licensee and could have gotten it (although I've personally never seen or heard of evidence that they did). So this was an example of ignorance of something, not true in fact - That said, Linus solved the problem he had. More power to him. Although his original kernel was a far cry from '386BSD' - but that was the point. When the AT&T case came out, hackers like me were worried 386BSD was going to go away and started to help make Linux more complete. I should (as Larry has pointed out) at the time of Linus original work, some institutions were far more liberal about source access than others. So even if Linus has known about Jolitz's work, its not clear he would/could have had access to it. ᐧ

On Thu, Jan 04, 2018 at 09:03:09AM -0500, Clem Cole wrote: How real was it in June 1991, when he demo'ed it in Usenix Anaheim? Was it at the level of a "MIT Media Lab demo", or was it actually something that could be used in anger? The official history states that 386 BSD version 0.0 was released in March 1992, and the "much more usable" 0.1 version was released in July 1992. The biggest problem with Jolitz's work seems to have been more social than anything else. The writeups from that era seem to indicate that the Jolitz's wanted to keep a much tighter control over things, and this discouraged collaboration and contributions, which led to the first of *BSD fragmentation/spin-offs, starting with FreeBSD and NetBSD. Contrast that to Linus, where I started playing with Linux in September 1991 (Linux 0.09), and in three months he accepted fairly major patches from me to implement all of the new syscalls and changes needed to implement POSIX Job Control and POSIX termios (Linux 0.12). The Linux developers were not spending time fighting over who would get commit bits; we were having fun writing code. - Ted

On Thu, Jan 04, 2018 at 11:45:57AM -0500, Theodore Ts'o wrote: I dunno what "used in anger" means but it worked. I used it. I know Joltiz pretty well, he worked for me around this time period. I hired him just to give him some money, he had gotten sort of screwed by the in crowd in the BSD/Usenix world, I didn't see that as reasonable. Yep. Leading to the famous (to me) quote: The BSD guys can't decide who is going to drive the big red fire truck so they each get to drive their very own toy fire truck. (I think Linus said that but not sure).

On Thu, Jan 04, 2018 at 10:29:59AM -0800, Bakul Shah wrote: I'll answer off list, not interested in ruffling feathers.

My fault. I had meant to reply to just Larry but forgot to remove cc: to the list. Apologies.

On Thu, Jan 4, 2018 at 1:56 PM, Theodore Ts'o &lt;tytso(a)mit.edu&gt; wrote: There was a natural bias towards SysV interfaces, which highlighted the differences with BSD interfaces in some areas and may have left that impression... Linus certainly had access to SysV or SysV derived systems, but there wasn't even a whisper at the time he copied code from there. And the few maybe less than completely legit versions of SysV that are now available bear this out: they look nothing at all like the 0.11-linux tree. Thank goodness for the sockets thing... Even though it's a horrible interface, it was less horrible than STREAMS... Warner

On Thu, Jan 4, 2018 at 5:55 PM, Andy Kosela &lt;akosela(a)andykosela.com&gt; wrote: ​Andy - please explain that connection, as it seem a tad tenuous to me. Sorry for my thickness, but I don't see how being based on V7 reflected on being System V based or not. System V was released many years after Seventh edition (1984 vs 1979). BSD had been out for years by the time Linus started his work and most everything from Seventh Edition (ney UNIX/TS) has been taken into PWB 3.0 @ Summit which was renamed System III in 1981/82ish by the North Carolina weenies at AT&T. I'm trying to think of a program I wrote for Seventh Edition that other than compiler and architectural differences, would not run with a "make clean; make" incantation (I can think of a few but not many). I guess the primary differences was init(8) had changed at that point, /etc/rc had been restructured, and the terminal handlers (termio vs {g,s}tty); but from an kernel interface standard point except for the terminal handler, System III was pretty much based on Seventh Edition and System V was a superset of that. If I remember a number of the emails/notes from the time, Linus was using SunOS on Sun3 at school. So he seen all of the BSD extensions to Seventh Edition, and in particular networking and the sockets API. As Ted noted, POSIX had more of an influence since it was at least formally described, while BSD was only defined by 'trusting the source.' POSIX had not yet been able to broach the Networking API at this point, but things like termios had begun to appear. In fact, Bostic was in the process of redoing BSD's terminal handler to add that API IIRC [I can ask him of the actually date]. Clem ᐧ

Theodore Ts'o &lt;tytso(a)mit.edu&gt; writes: Indeed. I've used NetBSD since it was called 386bsd 0.0, and the way I remember it, we grabbed that when Jolitz made it available, and had an Internet community playing with it and improving it. Patches were accumulated, and sent back to Jolitz. Then he released 0.1, with none of the patches from the 'net. Some of the more active people ported our existing patches to that, and we kept on going. Again, patches were sent back. When Jolitz released 0.2, again with no patches from the Internet community included, it was decided to part ways, and start a forked project on the 'net. This became NetBSD. After a short time, it was obvious that there were two camps: one wanted to keep the OS multi-platform, while the other felt it was smarter to ditch that in favor of maximizing performance and utility on the Intel platform. The latter group became the FreeBSD project. And yes, the stupid lawsuit came at just the right time for the world to adopt Linux instead of BSD, but that's the way the cookie crumbles. The BSD community is doing just fine, thank you, and we still have the better product, so there! ;) -tih -- Most people who graduate with CS degrees don't understand the significance of Lisp. Lisp is the most important idea in computer science. --Alan Kay