LOL

Me too fellow 83:er..me too. 🥴

Thanks @dmacnet, always good to hear from people who worked on the project or planning even. Thanks for filling in the blanks on the goals of Hurd, makes sense

I was working on what would become the coreutils, mostly remotely, so I didn't keep up with Hurd development, which was done in the FSF office at the MIT AI Lab where Thomas Bushnell worked. I only visited MIT for about two weeks a year. There were definitely some lively discussions about the direction to go. Everyone wanted a technically clean and innovative (ambitious) design, and empowering users was a motivation for that approach of moving as much as possible into userspace. Mach ended up being the pragmatic compromise choice, for better or worse.

I was put Apple's AUX on a 68020 processor, the performance wasnt stellar, might have been better to use yours :). Thanks @jecelassumpcaojr890 great story

Exactly. Feels just likes DJ is out Tech grandpa and we kids sit down around him and listen to the stories about yesteryear 💪

DJ's memories are right up there with any of the CHM interviews of folks in Silicon Valley. And this one on GNU Hurd is especially good, because it reinforces those discoveries that writing micro-kernels or nano-kernels is hard. Hybrid kernels work. You just have to optimize for the compromises to get the performance. So no surprise things go dormant when they hit stumbling blocks. I'm glad there are people who can devote their time doing the research, bench-marking and publishing paper.s

and I still owe you a video on Minux will have to do that in the next couple of weeks

Minix 3 hasn’t been updated in a few years though. At least Redox and Hubri are a thing now?

@@chrystals.4376 Barrelfish hasn't been updated in a few years either, but I suspect that like Minix-3, it'll continue to influence the thinking of newer OSs to come.

At that time multi-process was much more a thing than multi-threading, in addition to distributed computing on multiple machines due to single-core processors. Now multi-core/multi-thread processors are the norm, and cache coherence is built-in on hardware level between kernels. Thus the multi-threaded monolithic approach is much more appealing from performance and ease of implementation standpoint. Less so academic purity, but in real life who cares when the stuff just works.

Yet it's Linux that dominates on the Top100 HPC computers. The kernel itself is highly multi-threaded and also can have user space network devices and file systems. Linux as a microkernel simply wouldn't have performed, a fairly simple good enough working system is what attracts development effort rather than an ivory tower theoretical approach.

Oh wow you want me lynched :). Yeah I could do that, can't wait to see the comments on it hahaha

Love to listen and understand the knowledge which he share.

LOL

Tbh, the Windows NT kernel was inspired by the design of Mach, not based on it. Dave Cutler has stated in multiple interviews they looked at the design of Mach but didn’t base their code on it at all, and that the design for Windows NT was done in-house at Microsoft. NeXT/Apple based their XNU kernel on Mach though, and turned it into a hybrid kernel.

@@tomhekker Yes, “inspired by” is a much more precise description. 👍

OMG LOL

You might want to check out Plan9 too.

LOL, sad isn't it

Gosh, and go though multiple context switches for any and everything? using Gigabytes of shared memory, and adminstering locking and administration through distributed processes? Sounds like a recipe for a not so performant non-enterprise/big data platform. But costs a lot more to develop, and a lot more single points of failure, and overhead during development.

@@kaihorstmann2783 Well, I suppose you could be right .... OTOH, as I understand it, "Big Data" already requires distributed applications with the attendant locking, gobs of memory (whether shared or not), and enough computing power to choke a moose (or rather lots of herds of mooses). All of the other stuff you wave your arms at seem to me to be the price you pay for "Big Data" ... regardless of whether or not we're talking about micro-kernel or monolithic kernel.

@@lewiscole5193 You are right in regards "Big data" being large distributed systems. But as I understand these read access by far exceeds write access, thus coordinating write access is less critical, or new data worm their way graually through the systems (I think of Google and the likes) My previous point rather concerns online transaction systems where change throughput is equally important.

@@kaihorstmann2783 > You are right in regards "Big data" being large > distributed systems. Okay. So we agree on one thing. > But as I understand these read access by far > exceeds write access, thus coordinating write > access is less critical, or new data worm their > way graually through the systems (I think of > Google and the likes) I'm not at all sure that I understand what you mean when you talk about read accesses exceeding write accesses thereby making write accesses less "critical". My understanding is that the explosion of non-SQL databases is at least in part driven by the fact that they really aren't able to deal with writes with the same ease/speed as reads, hence the use of LSM trees in the non-SQL alternatives. Since I'm not particularly familiar enough with "Big Data", I don't feel warm and fuzzy about accepting your statements without further elaboration as they sound a bit like overly broad generalizations at this point. > My previous point rather concerns online > transaction systems where change throughput > is equally important. Since I haven't tried to keep up-to-date on the latest goings on in computing, the transaction systems that I'm aware of basically airline reservation systems. They work very, very well and they run on monolithic kernels, not because they have to, but because that's what was available in the Good Old Days. However, while everyone is familiar with SABRE, not everyone seems to be familiar with the history before such a system as cooked up ... lots of failures, lots of money pissed away ... the sort of thing you seem to be attributing to micro-kernels as being unavoidable. From my experience, it's been obvious for a long, long time that you want to run something as fast as possible, you want to stay out of the kernel because once you entered, it was anyone's guess when you come out. My understanding is that part of the reason LMAX Disruptor was so fast was because its developers recognized this fact. And if you stay out of the kernel, I don't see why I should much care if we're talking about a monolithic kernel or a micro-kernel.

Except: 1:31 that’s not richard stallman, that’s the silly impersonator from the O’Rieleys book about him.

Also, archhurd has been dormant for more than a year and only has a couple hundred packages. It’s also unofficial.

Thank you fred most kind of you!

Will take a look at it and see if I can get it installed

@@CyberGizmo Hubri also looks interesting but IIRC it’s mostly for Servers.

Yeah I think so, I was on the opposite side of that split, but I think I can cover it might have some bias in it though :)

Im trying to remember what DEC called their Mach based OS, oh well might have to go look it up, ok I looked it up, duh, DEC OSF/1

Well, if you want to talk about DEC OSs, what about SPIN? Aside from whatever extensibility it might have had, the really good thing about it from my perspective is that it wasn't Unix.

Maybe they'll bring life to it and take over.

Thanks Richard

Thanks William, I doubt they would be interested in the musings of some old timer systems engineer :)

It's a little know fact that the Smithsonian archives include the Library of Congress and also the Library of Congress contains the Smithsonian archives. There's got to be a copy of Hurd in there somewhere.

Should have scrolled down 11 minutes ago! wow

added to the list for @PavelSayekat thanks @emik365

Whether or not something is "suitable" for "mission critical situations" depends on what the mission or missions happen to be and what sorts of requirements and constraints are "acceptable" with regard to that mission. Since you haven't stated what mission(s) you have in mind or what requirements or constraints you're willing to tolerate, your question about suitability is basically meaningless (at least to me). For example, Once Upon a Time, the OS I took part in the care and feeding of what modified by one customer to NEVER take a system stop (i.e. all the system stops were removed from the code). Why? Because the mission had to do with monitoring/controlling missiles and so the priority was to keep on running, even if poorly, no matter what. Data integrity was a distant second. Meanwhile, in "normal" use, the OS was also used in banking and airlines environments. While they were willing to take stops, if they had to, their approach to what happened when a stop occurred was different. In the case of a stop in a banking environment, the customer wanted all the information that could be collected to resolve/prevent the cause of the stop from ever happening again, even if that meant that the system stayed down for awhile. Data integrity was everything and so leaving things frozen as they were at the time of the stop was acceptable. In the case of a stop in an airline environment, however, the customer wanted their system back up RIGHT NOW. They could reconstruct their data later, and since having to deal with seats that were overbooked was something they naturally had to deal with, they could live with data being lost. And there were penalties in some of the contracts IIRC for the system not getting back up within a certain amount of time. Not that it matters in the slightest, but here's something from a 2020 Unisys Web-inar which included a mention about "vulnerabilities" of various OSs based on data taken from NIST's National Vulnerability Database for that year: Operating System / Number / Date of Last Vulnerability / Compromised User Data Unisys OS2200........... 0 ........... ---------- ........... No Unisys MCP.............. 3 ........... 02/26/2018 ........... No IBM System z (zSeries).. 25 ........... 11/14/2019 ........... Yes IBM System i (iSeries).. 28 ........... 11/08/2019 ........... Yes OpenVMS................. 39 ........... 01/28/2020 ........... Yes HP-UX................... 370 ........... 01/28/2020 ........... Yes IBM AIX................. 398 ........... 01/28/2020 ........... Yes Unix.................... 890 ........... 01/29/2020 ........... Yes Solaris................. 1,118 ........... 02/04/2020 ........... Yes Linux................... 7,819 ........... 02/07/2020 ........... Yes Windows................. 7,977 ........... 02/06/2020 ........... Yes So do these numbers make it look like Linux is ready for prime time (i.e. "mission critical" work) to you? If so, are you willing to accept the same sort of thing for the other OSs you mentioned?

>What are the overlapping and unique functionalities? Hurd/Plan9 allows you to parse anything with a program and provide that parsed output as a tree of files to other programs. You can kind of think of Hurd as Plan9 with a global namespace instead of per-process namespaces (and of course the ability to run GNU programs). >Are these systems suitable (or what will it take to mature) for mission critical situations? In a vacuum, microkernels are more suited to mission-critical applications as they are more fault-tolerant. And Hurd is theoretically more secure as its permissions are more fine-grained than a normal Unix kernel. Though I wouldn't use Hurd for anything like that unless it had way more developers looking over it for bugs.

> QNX supports both ARM and x86 (and x86-64) CPUs, > and the last time I looked, it supported something > like 32 CPUs per OS instance. The number of supported CPUs says nothing about how well it scales up, but just for the record, Linux supports at least 2048 CPUs. > And since the QNX message handler could pass messages to other > QNX instances over a network Similarly, you can build a Linux cluster, and such Linux clusters are widely used. However, let's not forget multiple instances are only possible for tasks that are relatively easy to parallelize, i.e. they can have large computational chunks that can be executed independently. > The only time that a fine grain lock has an advantage is > if there is low contention on the shared object. Fine grained locking can reduce contention. Let's take the filesystem as an example. If you have just one filesystem lock, then you have a lot of contention on that lock, because virtually every process needs to read or write something. You may say let's use message passing instead, and it can be slightly faster than having just one highly contended lock, but it is not going to scale well anyway. A better approach is to add an RW lock per each inode, so most common operations require only to take inode locks, which have little contention. You still need the filesystem lock for cross-directory rename, and it can be tricky to do cross-directory rename properly, but if you did that correctly, it scales up well. In most cases, if you have a highly contended lock, you do not use fine grained locking or you have not designed them properly. Admittedly message passing or coarse locking is much easier to implement correctly, so if performance is good enough then development time is usually the primary concern, especially if we speak about specialized commercial software. > Crossing sockets is a killer. Sure, but if you do that a lot, you probably do not care about performance. Linux avoids that by using per-CPU data structure.

@@tripplefives1402 what is a "fad" language? Yes, I like it, based on what I have code in Rust so far. However Rust has a learning curve. Swift/Kotlin/C# have concerning ties with Apple/Google/Microsoft.

Linux isn't truly monolithic anymore and hasn't been for quite some time. From what I understand AT&T Unix was modular. In other words drivers were loaded and unload as modules. Linux added modular support early on and became a monolithic modular hybrid kernel.

Actually I did, and L4 fixed the slow IPC problem it was faster than a syscall

@@CyberGizmo I paid attention to your whole video but heard nothing about how slow or buggy that Hurd is

@@RonJohn63 As Mr. Ware pointed out, L4 isn't particularly slow, thus showing that your original comment was an incorrect over-generalization. Ditto MP on L4. And then there's QNX which is a proprietary micro-kernel that does rather well at real time uses which sort of further demonstrates the incorrectness of your original comment. So it would appear that rather than admit to the incorrectness of your statement(s), you're now trying to change the goal posts be focusing more specific about the performance of Hurd. That's nice, but since YOU made the assertion about Hurd, it's now up to you, not Mr. Ware, to justify your position. I await with bated breath for YOU to make your own damn video so that I and others can poke holes in it.

@@lewiscole5193 Hurd is not L4 or QNX. And you're right that I over-generalized. L4 solved the IPC problem, but Hurd did not.

I'm not sure anyone evaluating HURD in the last 20 years would have said "if only it performed better!". People don't use it because people _really like their hardware to work_. They want working audio and USB. They want their random to be secure (it wasn't for many years). They want programs that require posix shmem to work. They want SMP and 64 bit.

I guess the fact that HURD lies in dormancy is a kind of answer that people don't see a real practical value in it beyond just a proof of concept. Microkernels' general tradeoff is providing more stability and security in exchange of performance. And in most cases this tradeoff is unnecesary.

Yes QNX was one I was thinking of they were the first to be successful using a microkernel, although I always put them in the embedded, Real Time OS class...and believe it or not, I used it, it was the OS installed on the Burroughs (later Unisys) ICON machine, a computer built for education with Canadian origins as I recall...and Im not arm waving...:)

@@CyberGizmo I was wondering if you' knew of/remembered ICON. It seemed like A Good Idea, at least in principle, and so it was a bit disappointing to me to hear that it died.

@@CyberGizmo Yup. I visited them once in Ottawa IIRC. Quark(? Maybe Photon?) was their GUI I think. A full OS/GUI on a single 1.2MB floppy.

I am pretty sure it’s the right guy his obit said he worked on GNU Hurd

wow

As i recall from that time period uploading to an ftp server was the only way to release software :)

Did you see the latest AI video where the interviewer got the AI so made it threatened to kill him?

@@CyberGizmo I'll check it out. There's AI then there is EC, engineered cognition. It is a failure not to make that distinction.

LOL, might throw the AI into a mobius loop :)

Dahlia OS could be something like that. The microkernel is google's Zircon though.

The GNU project doesn't have people they can move to different projects, it has contributors that care about different things and choose how to spend an hour or two on the weekend.

@@capability-snob GNU can stop funding the attention on HURD and archive the project if they want to influence where developers go. Instead they keep it on life support, still hosting the site, hoping that they’ll have one or two people working on it so it’s never declared dead

@@michaelthompson7217 GNU spends no funding on Hurd besides the cost of hosting a handful of low-traffic webpages, which adds up to maybe a bit of pocket change a month.

Thanks grey for filling us all in, appreciate you taking the time to do this! I am forever a CLI junkie its a hard habit to break

Let me see if i can clear this up for you a little bit. In the written form its easy to tell the difference between demon and daemon in print, but what if you were talking to someone about UNIX, if you pronounce both as dee-mon, how would the other person know you were talking about device drivers or system services. The pronunciation difference was to help clear up the ambiguity in spoken language.

Happily infected. And I've got strangest feeling we had this discussion on slashdot twenty years ago...

If not for GNU, Linux would have been released with a non-commercial license. >Of course I know I'm in the minority on this thought. Deservedly.

In the physics world there is no such thing as below absolute zero. The reason why is due to the fact that at absolute zero all molecular motion stops. So there can be no below absolute zero. It really is an absolute temperature.