* [TUHS] CMU Mach sources? @ 2019-06-23 4:38 Chris Hanson 2019-06-23 5:15 ` Larry McVoy ` (4 more replies) 0 siblings, 5 replies; 55+ messages in thread From: Chris Hanson @ 2019-06-23 4:38 UTC (permalink / raw) To: tuhs Does anyone know whether CMU’s local Mach sources have been preserved? I’m not just talking about MK84.default.tar.Z and so on, I’m talking about all the bits of Mach that were used on cluster systems on campus, prior to the switch to vendor UNIX. I know at least one person who had complete MacMach sources for the last version, but threw out the backup discs with the sources in the process of moving. So I know they exist. If nothing else, CMU did provide other sites their UX source package (eg UX42), which was the BSD single server environment. So I know that has to be out there, somewhere. — Chris Sent from my iPhone ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [TUHS] CMU Mach sources? 2019-06-23 4:38 [TUHS] CMU Mach sources? Chris Hanson @ 2019-06-23 5:15 ` Larry McVoy 2019-06-23 8:52 ` Andrew Warkentin 2019-06-23 13:39 ` Jon Forrest 2019-06-23 8:04 ` Jason Stevens ` (3 subsequent siblings) 4 siblings, 2 replies; 55+ messages in thread From: Larry McVoy @ 2019-06-23 5:15 UTC (permalink / raw) To: Chris Hanson; +Cc: tuhs I've read the Mach source. Not a fan. If you look around you can find SunOS 4.x sources, not legal but it is out there. If you read the SunOS vm code enough, it will come into focus for you. The code matches what you think a VM system should be. If you read the Mach code, nope, it's a tangled mess, there is no clear picture there. I read the papers and wanted to believe it was good, it is not. On Sat, Jun 22, 2019 at 09:38:26PM -0700, Chris Hanson wrote: > Does anyone know whether CMU???s local Mach sources have been preserved? > > I???m not just talking about MK84.default.tar.Z and so on, I???m talking about all the bits of Mach that were used on cluster systems on campus, prior to the switch to vendor UNIX. > > I know at least one person who had complete MacMach sources for the last version, but threw out the backup discs with the sources in the process of moving. So I know they exist. > > If nothing else, CMU did provide other sites their UX source package (eg UX42), which was the BSD single server environment. So I know that has to be out there, somewhere. > > ??? Chris > > Sent from my iPhone -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [TUHS] CMU Mach sources? 2019-06-23 5:15 ` Larry McVoy @ 2019-06-23 8:52 ` Andrew Warkentin 2019-06-23 13:39 ` Jon Forrest 1 sibling, 0 replies; 55+ messages in thread From: Andrew Warkentin @ 2019-06-23 8:52 UTC (permalink / raw) To: tuhs On 6/22/19, Larry McVoy <lm@mcvoy.com> wrote: > I've read the Mach source. Not a fan. If you look around you can find > SunOS 4.x sources, not legal but it is out there. > > If you read the SunOS vm code enough, it will come into focus for you. > The code matches what you think a VM system should be. > > If you read the Mach code, nope, it's a tangled mess, there is no > clear picture there. > > I read the papers and wanted to believe it was good, it is not. > I've never actually read Mach's sources, but it doesn't surprise me that Mach's implementation is every bit as much of a train wreck as its design. Mach and the other kernels influenced by it basically destroyed the reputation of microkernels, even though there were microkernels that performed comparably to or better than monolithic kernels that actually predated Mach et al. There was one paper from 1992 [1] in which an early version of QNX 4 significantly outperformed System V in just about every category benchmarked (one of these days I should try to benchmark a newer version of QNX against Linux and see if the results still hold up). I wonder, had QNX or something like it had been the "next big thing" in the late 80s and early 90s rather than Mach, if microkernels wouldn't have become the dominant OS architecture, or at least a credible alternative. I also wonder if a modern highly optimized microkernel OS could still outperform monolithic kernels. Current open-source microkernel OSes seem to focus on academic purism rather than real-world performance (one of the biggest issues is that they tend to split subsystems up vertically with little benefit to security or stability, and probably adding significant overhead to system calls; e.g. on noux under Genode, a simple read() of a disk file, which is a single kernel call on a monolithic kernel and usually two context switches on QNX, takes at least 8 context switches - client->VFS->disk FS->partition driver->disk driver and back again). I may find out once I get UX/RT [2] (the QNX/Plan 9-like seL4-based OS I'm writing) working, since it will focus on real-world performance over academic purism (I'm an architectural purist in many ways, but I think purism must further performance and usability, not hinder them), although I don't necessarily expect early versions to have the best performance because the implementation will probably be suboptimal in places. I'm still a ways from getting it working though. [1] https://cseweb.ucsd.edu/~voelker/cse221/papers/qnx-paper92.pdf [2] https://gitlab.com/uxrt ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [TUHS] CMU Mach sources? 2019-06-23 5:15 ` Larry McVoy 2019-06-23 8:52 ` Andrew Warkentin @ 2019-06-23 13:39 ` Jon Forrest 2019-06-23 13:59 ` arnold 2019-06-23 14:03 ` Jason Stevens 1 sibling, 2 replies; 55+ messages in thread From: Jon Forrest @ 2019-06-23 13:39 UTC (permalink / raw) To: tuhs On 6/22/2019 10:15 PM, Larry McVoy wrote: > I've read the Mach source. Not a fan. If you look around you can find > SunOS 4.x sources, not legal but it is out there. > If you read the Mach code, nope, it's a tangled mess, there is no > clear picture there. > > I read the papers and wanted to believe it was good, it is not. There's one thing to keep in mind about some software produced in an academic environment. Sometimes it's a collection of proofs of concept of clever ideas that various grad student have hacked together for their MS or PhD work. It's not intended to be production quality. I don't know anything about Mach, but this was certainly the state of Postgres when I worked in the Postgres group in 1991-1995. We tried to use it as the basis for a big research project (e.g. Sequoia 2000) but spent (wasted?) lots of time fighting Postgres issues. Eventually, long after I left the group, and after Mike Stonebraker left Berkeley, a group of people who weren't associated with UC Berkeley did a truly heroic job and "fixed" Postgres. The production quality Postgres you see now is the result. The BSD project was different, for all kinds of reasons. I wonder if Mach was a Postgres or BSD style project. Cordially, Jon Forrest ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [TUHS] CMU Mach sources? 2019-06-23 13:39 ` Jon Forrest @ 2019-06-23 13:59 ` arnold 2019-06-23 14:03 ` Jason Stevens 1 sibling, 0 replies; 55+ messages in thread From: arnold @ 2019-06-23 13:59 UTC (permalink / raw) To: tuhs, nobozo Jon Forrest <nobozo@gmail.com> wrote: > I wonder if Mach was a Postgres or BSD style project. More the former than the latter. Mach entered the commercial world by way of NeXT, and there were a few other more or less production versions, such as the mt. Xinu one and MachTen (IIRC), but Mach never really caught on big. (There was even a port of Linux on top of Mach at some point.) Mach survives today in the kernel of Mac OS X (Darwin), but I think that's about it. Rick Rashid, who was the guiding professor for Mach, went to Microsoft Research, and as far as I can tell, fell off the radar screen for OS development work. (Anyone who knows different feel free to correct me.) Arnold ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [TUHS] CMU Mach sources? 2019-06-23 13:39 ` Jon Forrest 2019-06-23 13:59 ` arnold @ 2019-06-23 14:03 ` Jason Stevens 1 sibling, 0 replies; 55+ messages in thread From: Jason Stevens @ 2019-06-23 14:03 UTC (permalink / raw) To: tuhs, Jon Forrest [-- Attachment #1: Type: text/plain, Size: 1734 bytes --] I guess XNU is the 'fixed' version of Mach. At least it powers all those iPhones and iPads. And I do have the buildable source of Darwin 0.1/0.3 which is the equivalent of OS X Server 1.0 It's a.. Fusion of Mach 2.5 and 4.4BSD. I've heard that NeXTSTEP is more 4.3BSD Get Outlook for Android On Sun, Jun 23, 2019 at 9:40 PM +0800, "Jon Forrest" <nobozo@gmail.com> wrote: On 6/22/2019 10:15 PM, Larry McVoy wrote: > I've read the Mach source. Not a fan. If you look around you can find > SunOS 4.x sources, not legal but it is out there. > If you read the Mach code, nope, it's a tangled mess, there is no > clear picture there. > > I read the papers and wanted to believe it was good, it is not. There's one thing to keep in mind about some software produced in an academic environment. Sometimes it's a collection of proofs of concept of clever ideas that various grad student have hacked together for their MS or PhD work. It's not intended to be production quality. I don't know anything about Mach, but this was certainly the state of Postgres when I worked in the Postgres group in 1991-1995. We tried to use it as the basis for a big research project (e.g. Sequoia 2000) but spent (wasted?) lots of time fighting Postgres issues. Eventually, long after I left the group, and after Mike Stonebraker left Berkeley, a group of people who weren't associated with UC Berkeley did a truly heroic job and "fixed" Postgres. The production quality Postgres you see now is the result. The BSD project was different, for all kinds of reasons. I wonder if Mach was a Postgres or BSD style project. Cordially, Jon Forrest [-- Attachment #2: Type: text/html, Size: 2737 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [TUHS] CMU Mach sources? 2019-06-23 4:38 [TUHS] CMU Mach sources? Chris Hanson 2019-06-23 5:15 ` Larry McVoy @ 2019-06-23 8:04 ` Jason Stevens 2019-06-23 14:54 ` Henry Bent 2019-06-23 8:27 ` Kevin Bowling ` (2 subsequent siblings) 4 siblings, 1 reply; 55+ messages in thread From: Jason Stevens @ 2019-06-23 8:04 UTC (permalink / raw) To: tuhs [-- Attachment #1: Type: text/plain, Size: 1797 bytes --] The fractions I've found of the 2.5 is on the CSRG #4 cd https://vpsland.superglobalmegacorp.com/install/Mach/MACH_CSRG_CD.7z You have to read the 404 to get the password. It changes frequently. I've been slowly trying to get 2.5 to build under Mt Xinu BSD/Mach. I've managed only the tools and bootloader so far. I've just been busy moving offices the last week. Anyway in that directory is a bunch of other Mach stuff I've found. I also started trying to map the Mach 3.0 stuff https://unix.superglobalmegacorp.com/cgi-bin/cvsweb.cgi/?sortby=file&only_with_tag=MAIN&hideattic=1&hidenonreadable=1&f=u&logsort=date&cvsroot=Mach3&path= Including BSDSS a unknown to me port of BSD to Mach 3. It seems plenty of the Mach 1/2 stuff is hidden on CMU's servers in wait of the ATT v CSRG lawsuit. And that everyone who worked on it left so it's locked away hidden. There is a vmdk of the mt Xinu installed that will run on qemu and most likely others as well. So you can take it out for a test drive From: Chris Hanson Sent: Sunday, June 23, 2019 12:46 PM To: tuhs@minnie.tuhs.org Subject: [TUHS] CMU Mach sources? Does anyone know whether CMU’s local Mach sources have been preserved? I’m not just talking about MK84.default.tar.Z and so on, I’m talking about all the bits of Mach that were used on cluster systems on campus, prior to the switch to vendor UNIX. I know at least one person who had complete MacMach sources for the last version, but threw out the backup discs with the sources in the process of moving. So I know they exist. If nothing else, CMU did provide other sites their UX source package (eg UX42), which was the BSD single server environment. So I know that has to be out there, somewhere. — Chris Sent from my iPhone [-- Attachment #2: Type: text/html, Size: 5200 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [TUHS] CMU Mach sources? 2019-06-23 8:04 ` Jason Stevens @ 2019-06-23 14:54 ` Henry Bent 2019-06-23 21:52 ` Clem Cole 0 siblings, 1 reply; 55+ messages in thread From: Henry Bent @ 2019-06-23 14:54 UTC (permalink / raw) To: Jason Stevens; +Cc: tuhs [-- Attachment #1: Type: text/plain, Size: 2442 bytes --] I know that it's not exactly what was asked for, but DEC's OSF/1 V1.0 source is floating around out there in the ether, which is a fusion of Mach 2.5 and Ultrix 4.2. It's the original release, for MIPS-based DECstations, of what eventually became Digital UNIX / Tru64. -Henry On Sun, 23 Jun 2019 at 04:05, Jason Stevens <jsteve@superglobalmegacorp.com> wrote: > The fractions I've found of the 2.5 is on the CSRG #4 cd > > https://vpsland.superglobalmegacorp.com/install/Mach/MACH_CSRG_CD.7z > <https://vpsland.superglobalmegacorp.com/old/install/Mach/MACH_CSRG_CD.7z> > > You have to read the 404 to get the password. It changes frequently. > > I've been slowly trying to get 2.5 to build under Mt Xinu BSD/Mach. > > I've managed only the tools and bootloader so far. I've just been busy > moving offices the last week. > > Anyway in that directory is a bunch of other Mach stuff I've found. > > I also started trying to map the Mach 3.0 stuff > > > https://unix.superglobalmegacorp.com/cgi-bin/cvsweb.cgi/?sortby=file&only_with_tag=MAIN&hideattic=1&hidenonreadable=1&f=u&logsort=date&cvsroot=Mach3&path= > > Including BSDSS a unknown to me port of BSD to Mach 3. > > It seems plenty of the Mach 1/2 stuff is hidden on CMU's servers in wait > of the ATT v CSRG lawsuit. And that everyone who worked on it left so it's > locked away hidden. > > There is a vmdk of the mt Xinu installed that will run on qemu and most > likely others as well. So you can take it out for a test drive > > > > > > *From: *Chris Hanson <cmhanson@eschatologist.net> > *Sent: *Sunday, June 23, 2019 12:46 PM > *To: *tuhs@minnie.tuhs.org > *Subject: *[TUHS] CMU Mach sources? > > > > Does anyone know whether CMU’s local Mach sources have been preserved? > > > > I’m not just talking about MK84.default.tar.Z and so on, I’m talking > about all the bits of Mach that were used on cluster systems on campus, > prior to the switch to vendor UNIX. > > > > I know at least one person who had complete MacMach sources for the last > version, but threw out the backup discs with the sources in the process of > moving. So I know they exist. > > > > If nothing else, CMU did provide other sites their UX source package (eg > UX42), which was the BSD single server environment. So I know that has to > be out there, somewhere. > > > > — Chris > > > > Sent from my iPhone > > > [-- Attachment #2: Type: text/html, Size: 5320 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [TUHS] CMU Mach sources? 2019-06-23 14:54 ` Henry Bent @ 2019-06-23 21:52 ` Clem Cole 2019-06-25 0:06 ` Larry McVoy 0 siblings, 1 reply; 55+ messages in thread From: Clem Cole @ 2019-06-23 21:52 UTC (permalink / raw) To: Henry Bent, Jason Stevens, Larry McVoy; +Cc: tuhs [-- Attachment #1: Type: text/plain, Size: 5519 bytes --] A couple of thoughts... 1.) Mach2.5 and 3.0 was part of an *extremely successful research project* but also did suffer from issues associated with being so. CSRG BTW *was not a research project*, contrary to its name, it was a support contract for DARPA since BTL would not support UNIX the way DEC, IBM, *et al*, did with their products. The reality is that Mach more than Thoth**), V Kernel, QNX, Sol, Chrous, Minux or any other uK of the day, changed the way people started to think about building an OS. Give Rashid and team credit - it showed some extremely interesting and aggressive ideas could be made to work. 2.) Comparing Mach with BSD or SunOS 4.3 is not really a valid comparison. They had different goals and targets. Comparing Ultrix, Tru64, or Mac OSx with SunOS (or Solaris for that matter) is fair. They all were products. They needed to be clean, maintainable and extensible [as Larry likes to point out, Sun traded a great deal of that away for political reasons with Solaris]. But the bottom line, you are comparing a test vehicle to a production one. And I while I agree with Larry on the internals and a lot of the actual code in Mach, I was always pretty damned impressed with what they crammed into a 5 lbs bag in a very short time. 3.) Mach2.5/386/Vax/etc.. << OSF/1 386 the later is similar what MtUnix shipped. Both are 'hybrid' kernels. But while MtUnix created a product with it, they were too small to do what DEC would later do. But the investment was greater than I think they could really afford. 4.) Mach 3.0 was from CMU, Mach 4.0 (which is still sort of available) was from the OSF/1 [this is a pure uK]. 3.) DEC OSF/1 (for MIPS) << Tru64 (for Alpha) - *a.k.a.* Digital UNIX - yes both started with a Mach 2.5 hybrid kernel and the later was mostly the same as OSF/1386, and both supported the Mach2.5 kernel message system - but DEC's team rewrote darned near everything in the kernel -- which in fact was both a bless and a curse [more in a minute]. Ok, so why have I bothered with all this mess. The fact is Mach was able to be turned into a product, both Apple and DEC did it. Apple had the advantage of starting with NextOS which (along with machTen) was the first short at making a 'product' out of it. But they invested a lot over the years and incrementally changed it. Enough to create XNU. DEC was a different story (which I lived a bit of personally). The DEC PMAX (mips) and the Intel 386 were the first references from OSF. OSF had an issue. IBM was supposed to deliver an OS, but for a number of reasons was not ready when OSF needed something. CMU had something that was 'good enough.' This is probably where Larry and I differ a little on shipping code. I'm a great believer figure out one solid goal and nailing it, and the rest is 'good enough' - i.e. fix in version 2. I think OSF/1 as a reference system nailed it. Their job was get something out as a starting base that ran on at least 2 workstations (and one server - which IIRC was an HP, maybe an Encore box) but able to be shipped on an AT&T V.3 unlimited license [which IBM had brought to the table]. The fact that they did not spend a lot of time cleaning up about CMU at this stage was not their job. The kernel had to be good enough - and it was (Larry might argue Mach2.5 vs SunOS 4.3 it was not as good technically - and he might be right - but that was not their job). So DEC gets a new code based. They have Ultrix (a product) for the PMAX. OSF has released the reference port. From a kernel code quality standpoint, OSF1 1.0/PMAX < Ultrix/RISC 4.5. They also are moving to a new 64-bit processor that is not going to run either VAX or PMAX binaries ( *i.e.* you will have to recompile). Two technical decisions and one marketing one were made at the management level that would later doom Tru64. First, it was agreed that Tru64 was going to be 'pure 64-bit' and it turned out >>none of the ISVs had clean code. Moreover, there were no tools to help find 64-bit issues. This single choice cost DEC 3 years in the ability to ship Tru64/Alpha. The second choice was DEC's team decided to re-write OSF/1 subsystem by subsystem. The argument would be: the XXX system sucks. It will never scale on a 64-bit system and it will not work for clusters. XXX was at least Memory Management, Terminal Handler, Basic I/O, SCSI, File System. The >>truth<< is each of these was actually right in the small, they did suck. But the fact is, they all were good enough to get the system out the door and get customers and ISV's starting the process of using the system. Yes, Megasafe is an excellent FS, but UFS was good enough to start. The marketing decision BTW, that not to ship Tru64/PMAX. Truth is it was running internally. But Marketing held that Tru64 was the sexy cool thing and did not want to make it available. The argument was they would have to support it. But the truth is that asking ISV's and customers to switch Architecture and OS in one jump, opened the door to consider Sun or HP (and with Tru64/Alpha's ecosystem taking 3 more years, people left DEC). ** Mike Malcolm was the primary author of Thoth as his PhD from Waterloo. HIs officemate, Kelly Booth (of the 'Graphics Killer-Bs) had a tee-shirt made that exhaled: 'Thoth Thucks' and gave them to the lot of the Waterloo folks. BTW, Mike and Cheridon would later go to Stanford and create V. Two of their students would create QNX with still lives. > [-- Attachment #2: Type: text/html, Size: 7987 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [TUHS] CMU Mach sources? 2019-06-23 21:52 ` Clem Cole @ 2019-06-25 0:06 ` Larry McVoy 2019-06-25 0:31 ` Theodore Ts'o 0 siblings, 1 reply; 55+ messages in thread From: Larry McVoy @ 2019-06-25 0:06 UTC (permalink / raw) To: Clem Cole; +Cc: tuhs All interesting points but messy code is messy code. I had a bunch of the FreeBSD folks over here for a BBQ a couple days ago (they want you at the next one Clem). We got to talking about Mach and someone told me that in the FreeBSD tree the Mach code was gone through and 60% of was deleted and it still worked. It just seems like the Mach folks wanted to try this, and that, and then next thing and never went back to clean up the mess. Even after that FreeBSD cleanup the code looks like crap to me. Let me define "crap" by defining good code. Good code is very stylized, you learn part of the system and you get the style and you can predict what the next part of the system looks like and when you get there, yeah, the prediction and the code matches. That's what SunOS 4.x was like when I sort of "got it". I just guessed what I'd see and that was what I saw. The Mach code, IMHO, completely fails that test. You can't predict anything, there are layers of code that don't seem to do anything, you have to tag through them to get to the code that does something. There are all sorts of helper functions (after the cleanup!) that don't seem to be used. I get that it was a big effort and I get that it was research code, but Clem, I can point you to code that I wrote as a grad student and it is SunOS like. You can predict what stuff looks like. That's just clean code. Mach was never like that, I'm sorry, but it wasn't. Was it/is it useful? Yeah. Would I like to work in that code if I had the juice? No, hard pass. And I was in it recently enough to submit a patch to the FreeBSD tree, trivial patch but you have to read a bunch of code to get to that trivial patch. It wasn't fun reading that code. Maybe I'm just old and washed up but maybe I know clean code when I see it. On Sun, Jun 23, 2019 at 09:52:33PM +0000, Clem Cole wrote: > A couple of thoughts... > > 1.) Mach2.5 and 3.0 was part of an *extremely successful research project* > but also did suffer from issues associated with being so. CSRG BTW *was > not a research project*, contrary to its name, it was a support contract > for DARPA since BTL would not support UNIX the way DEC, IBM, *et al*, did > with their products. The reality is that Mach more than Thoth**), V > Kernel, QNX, Sol, Chrous, Minux or any other uK of the day, changed the way > people started to think about building an OS. Give Rashid and team > credit - it showed some extremely interesting and aggressive ideas could be > made to work. > > 2.) Comparing Mach with BSD or SunOS 4.3 is not really a valid comparison. > They had different goals and targets. Comparing Ultrix, Tru64, or Mac > OSx with SunOS (or Solaris for that matter) is fair. They all were > products. They needed to be clean, maintainable and extensible [as Larry > likes to point out, Sun traded a great deal of that away for political > reasons with Solaris]. But the bottom line, you are comparing a test > vehicle to a production one. And I while I agree with Larry on the > internals and a lot of the actual code in Mach, I was always pretty damned > impressed with what they crammed into a 5 lbs bag in a very short time. > > 3.) Mach2.5/386/Vax/etc.. << OSF/1 386 the later is similar what MtUnix > shipped. Both are 'hybrid' kernels. But while MtUnix created a product > with it, they were too small to do what DEC would later do. But the > investment was greater than I think they could really afford. > > 4.) Mach 3.0 was from CMU, Mach 4.0 (which is still sort of available) was > from the OSF/1 [this is a pure uK]. > > 3.) DEC OSF/1 (for MIPS) << Tru64 (for Alpha) - *a.k.a.* Digital UNIX - yes > both started with a Mach 2.5 hybrid kernel and the later was mostly the > same as OSF/1386, and both supported the Mach2.5 kernel message system - > but DEC's team rewrote darned near everything in the kernel -- which in > fact was both a bless and a curse [more in a minute]. > > Ok, so why have I bothered with all this mess. The fact is Mach was able > to be turned into a product, both Apple and DEC did it. Apple had the > advantage of starting with NextOS which (along with machTen) was the first > short at making a 'product' out of it. But they invested a lot over the > years and incrementally changed it. Enough to create XNU. DEC was a > different story (which I lived a bit of personally). > > The DEC PMAX (mips) and the Intel 386 were the first references from OSF. > OSF had an issue. IBM was supposed to deliver an OS, but for a number of > reasons was not ready when OSF needed something. CMU had something that > was 'good enough.' > > This is probably where Larry and I differ a little on shipping code. I'm a > great believer figure out one solid goal and nailing it, and the rest is > 'good enough' - i.e. fix in version 2. I think OSF/1 as a reference > system nailed it. Their job was get something out as a starting base that > ran on at least 2 workstations (and one server - which IIRC was an HP, > maybe an Encore box) but able to be shipped on an AT&T V.3 unlimited > license [which IBM had brought to the table]. The fact that they did not > spend a lot of time cleaning up about CMU at this stage was not their job. > The kernel had to be good enough - and it was (Larry might argue Mach2.5 > vs SunOS 4.3 it was not as good technically - and he might be right - but > that was not their job). > > So DEC gets a new code based. They have Ultrix (a product) for the PMAX. > OSF has released the reference port. From a kernel code quality > standpoint, OSF1 1.0/PMAX < Ultrix/RISC 4.5. They also are moving to a > new 64-bit processor that is not going to run either VAX or PMAX binaries ( > *i.e.* you will have to recompile). Two technical decisions and one > marketing one were made at the management level that would later doom > Tru64. First, it was agreed that Tru64 was going to be 'pure 64-bit' and > it turned out >>none of the ISVs had clean code. Moreover, there were no > tools to help find 64-bit issues. This single choice cost DEC 3 years in > the ability to ship Tru64/Alpha. The second choice was DEC's team decided > to re-write OSF/1 subsystem by subsystem. The argument would be: the XXX > system sucks. It will never scale on a 64-bit system and it will not work > for clusters. XXX was at least Memory Management, Terminal Handler, Basic > I/O, SCSI, File System. The >>truth<< is each of these was actually right > in the small, they did suck. But the fact is, they all were good enough > to get the system out the door and get customers and ISV's starting the > process of using the system. Yes, Megasafe is an excellent FS, but UFS > was good enough to start. The marketing decision BTW, that not to ship > Tru64/PMAX. Truth is it was running internally. But Marketing held that > Tru64 was the sexy cool thing and did not want to make it available. The > argument was they would have to support it. But the truth is that asking > ISV's and customers to switch Architecture and OS in one jump, opened the > door to consider Sun or HP (and with Tru64/Alpha's ecosystem taking 3 more > years, people left DEC). > > > > > > ** Mike Malcolm was the primary author of Thoth as his PhD from Waterloo. > HIs officemate, Kelly Booth (of the 'Graphics Killer-Bs) had a tee-shirt > made that exhaled: 'Thoth Thucks' and gave them to the lot of the Waterloo > folks. BTW, Mike and Cheridon would later go to Stanford and create V. > Two of their students would create QNX with still lives. > > > -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [TUHS] CMU Mach sources? 2019-06-25 0:06 ` Larry McVoy @ 2019-06-25 0:31 ` Theodore Ts'o 2019-06-25 0:45 ` Larry McVoy 0 siblings, 1 reply; 55+ messages in thread From: Theodore Ts'o @ 2019-06-25 0:31 UTC (permalink / raw) To: Larry McVoy; +Cc: tuhs On Mon, Jun 24, 2019 at 05:06:30PM -0700, Larry McVoy wrote: > All interesting points but messy code is messy code. I had a bunch of the > FreeBSD folks over here for a BBQ a couple days ago (they want you at the > next one Clem). We got to talking about Mach and someone told me that in > the FreeBSD tree the Mach code was gone through and 60% of was deleted and > it still worked. It just seems like the Mach folks wanted to try this, > and that, and then next thing and never went back to clean up the mess. Welcome to academic/research code. :-) I'm reminded of a description of the Coda File System by Peter Braam; he said that it was irretrivably tainted by a dozen Ph.D. students working on their thesis. Naturally, once they had done the necessary work for them to get their doctorate, any interest in doing the necessary code cleanup for their various experimental efforts evaporated. He tried cleaning it up, and eventually gave up and decided to the only solution was a rewrite and redesign from scratch.... I used to be annoyed when professors and their graduate students would do their work based on same ancient version of Linux. (In general, the last version of Linux dating from the professor had time to hack on code.) I later decided that was a feature, not a bug, because it meant no one would be tempted to take academic code and try to put it into the mainline kernel... - Ted ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [TUHS] CMU Mach sources? 2019-06-25 0:31 ` Theodore Ts'o @ 2019-06-25 0:45 ` Larry McVoy 2019-06-25 0:55 ` Kurt H Maier 2019-06-25 1:00 ` [TUHS] " Richard Salz 0 siblings, 2 replies; 55+ messages in thread From: Larry McVoy @ 2019-06-25 0:45 UTC (permalink / raw) To: Theodore Ts'o; +Cc: tuhs On Mon, Jun 24, 2019 at 08:31:21PM -0400, Theodore Ts'o wrote: > On Mon, Jun 24, 2019 at 05:06:30PM -0700, Larry McVoy wrote: > > All interesting points but messy code is messy code. I had a bunch of the > > FreeBSD folks over here for a BBQ a couple days ago (they want you at the > > next one Clem). We got to talking about Mach and someone told me that in > > the FreeBSD tree the Mach code was gone through and 60% of was deleted and > > it still worked. It just seems like the Mach folks wanted to try this, > > and that, and then next thing and never went back to clean up the mess. > > Welcome to academic/research code. :-) Like I said, I can point anyone at code I wrote as a grad student that while I'm not proud of the style, it has style and it is clean. Just because you are a grad student that doesn't excuse messy code. If you write messy code then you're a bad hire. > I'm reminded of a description of the Coda File System by Peter Braam; > he said that it was irretrivably tainted by a dozen Ph.D. students > working on their thesis. Naturally, once they had done the necessary > work for them to get their doctorate, any interest in doing the > necessary code cleanup for their various experimental efforts > evaporated. Yeah, like I said, bad hires. People who are good coders take pride in their work. They put in the extra time to clean it up. That's why SunOS 4.x was a nice code base, everyone pulled their weight to make it be so. I get that that is unusual but it is super nice when it happens. And I wasn't trying to belittle the Mach effort, I'm impressed with what it does. I am most definitely belittling the people who did it. Not because of what they accomplished, that's cool, but they didn't care enough to clean it up. That sucks. And that means they suck as professional programmers. I'm a canoe guy and any canoe guy knows that the ultimate insult is "I wouldn't want him in my boat." Well, I wouldn't want the Mach people, for all their talent and accomplishments, on my team. I like people who get the job done, all the way done. Code is clean, the docs cover the code, the test cases are there. Done done. I just don't buy that academic/research code needs to be bad. If the people doing it are people you'd want to hire, they get it done done. I get that I'm describing a unicorn but I was one, and I'm not that great. Doesn't seem so much to ask that people give a shit and do it right. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [TUHS] CMU Mach sources? 2019-06-25 0:45 ` Larry McVoy @ 2019-06-25 0:55 ` Kurt H Maier 2019-06-25 4:18 ` Larry McVoy 2019-06-25 1:00 ` [TUHS] " Richard Salz 1 sibling, 1 reply; 55+ messages in thread From: Kurt H Maier @ 2019-06-25 0:55 UTC (permalink / raw) To: Larry McVoy; +Cc: tuhs On Mon, Jun 24, 2019 at 05:45:23PM -0700, Larry McVoy wrote: > > Like I said, I can point anyone at code I wrote as a grad student that > while I'm not proud of the style, it has style and it is clean. Just > because you are a grad student that doesn't excuse messy code. If you > write messy code then you're a bad hire. > This is akin to complaining about laborers not polishing railroad spikes before hammering them into the sleepers. It's hard enough to find people willing to touch computers at all for grad-student "wages," much less ones both capable & willing to be held to production-code standards on budgets that barely put food on the table, one fiscal year at a time. The systems engineer side of me really wants to agree with you, but the state of academic computing has not been amenable to this standard for some years -- ever, in terms of my career. We're lucky to get working code, full stop. There is no funding for *nice* code. Funding directed toward nice code will be cut next quarter. People advocating for funding for nice code will find their annual performance review is suddenly a multi-player game. Some institutions are better than others. The place I work now has explicit policies regarding "sustainable" software development, and it's an absolute delight ... which does not exist in many (most?) places. khm ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [TUHS] CMU Mach sources? 2019-06-25 0:55 ` Kurt H Maier @ 2019-06-25 4:18 ` Larry McVoy 2019-06-26 23:19 ` [TUHS] Craft vs Research (Re: " Bakul Shah 0 siblings, 1 reply; 55+ messages in thread From: Larry McVoy @ 2019-06-25 4:18 UTC (permalink / raw) To: Larry McVoy, Theodore Ts'o, tuhs On Mon, Jun 24, 2019 at 05:55:28PM -0700, Kurt H Maier wrote: > On Mon, Jun 24, 2019 at 05:45:23PM -0700, Larry McVoy wrote: > > > > Like I said, I can point anyone at code I wrote as a grad student that > > while I'm not proud of the style, it has style and it is clean. Just > > because you are a grad student that doesn't excuse messy code. If you > > write messy code then you're a bad hire. > > > > This is akin to complaining about laborers not polishing railroad spikes > before hammering them into the sleepers. It's hard enough to find > people willing to touch computers at all for grad-student "wages," much > less ones both capable & willing to be held to production-code standards > on budgets that barely put food on the table, one fiscal year at a time. It is not about wages, when I was a grad student I got $16K and had to pay tuition and rent and everything else out of that. It's not about money. It's about caring about your craft. I cared, the people I have worked with in industry cared, if they didn't I left. The point I was trying to make was that you can be a student and still be a pro. Or not. The pros care about their craft. The Mach people, in my you-get-what-you-paid-for opinion, were not pros. They got a lot done in a sloppy way and they left a mess. I don't know how to say it more clearly, there are plenty examples of students that wrote clean code. Mach was cool, clean code it was not. ^ permalink raw reply [flat|nested] 55+ messages in thread
* [TUHS] Craft vs Research (Re: CMU Mach sources? 2019-06-25 4:18 ` Larry McVoy @ 2019-06-26 23:19 ` Bakul Shah 2019-06-27 0:16 ` tuhs 0 siblings, 1 reply; 55+ messages in thread From: Bakul Shah @ 2019-06-26 23:19 UTC (permalink / raw) To: Larry McVoy; +Cc: tuhs On Mon, 24 Jun 2019 21:18:06 -0700 Larry McVoy <lm@mcvoy.com> wrote: > > It's not about money. It's about caring about your craft. I cared, > the people I have worked with in industry cared, if they didn't I > left. > > The point I was trying to make was that you can be a student and still > be a pro. Or not. The pros care about their craft. The Mach people, > in my you-get-what-you-paid-for opinion, were not pros. They got a > lot done in a sloppy way and they left a mess. > > I don't know how to say it more clearly, there are plenty examples of > students that wrote clean code. Mach was cool, clean code it was not. I beg to differ with Larry. Research is basically directed exploration. You may have a vague idea about what you're seeking or you may decide to pursue something you stumbled upon. But you are mainly hacking a path through the jungle as it were. In my view it is much too early to build permanent roads (i.e. write "production quality code") during exploration. And if you spend time building roads, you are likely going to slow down or are already stuck and simply using road building to procrastinate! Craft certainly counts but it is not all important. You should just build *what you absolutely need* and do so as simply as possible and keep moving. In fact, the more permanent structures you build, the more afraid you will be to throw away bad bits and pieces if you have to change direction! It doesn't make sense to expect such exploratory code to work well in production. It is not going to be rock solid, it won't take care of corner cases, it will have lousy error recovery, if any, it may not have some necessary features and it may not scale well. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [TUHS] Craft vs Research (Re: CMU Mach sources? 2019-06-26 23:19 ` [TUHS] Craft vs Research (Re: " Bakul Shah @ 2019-06-27 0:16 ` tuhs 2019-06-27 17:06 ` Clem Cole 0 siblings, 1 reply; 55+ messages in thread From: tuhs @ 2019-06-27 0:16 UTC (permalink / raw) To: tuhs I think Larry is right, but also wrong. I think I can speak from experience. The goal of research is not to produce consumer-ready code, but to explore ideas. Nasty things sometimes happen in that environment. But that doesn't mean that code doesn't have to work. My introduction to coding on a research project was INGRES, at the time the competitor to System R (now DB/2, better known as "anything SQL") from IBM Research. By the very nature of the problem, the main complaint was that "Relational Databases Cannot Work" --- so proving that they could was a major part of the research agenda. At one point (pre-commercial) INGRES stored the telecom wiring diagram of New York City. It wasn't always a pleasant experience, but we learned a lot, mostly happy, most of the time. A lot of our motivation was because real people were using our code to do real work. Had we hung them out in the wind to dry, we wouldn't have gotten that feedback, and frankly I think RDBMS wouldn't have progressed so far and so fast. But when I left INGRES I talked with Mike Stonebraker, who asked me where I thought the project should be going. At that point I thought it was clear that the research objectives had been satisfied, and there was the beginnings of a commercial company to move it forward, so I advised that the old code base (which at that point I had written or substantially modified well over 50%) should be abandoned. Do a new system from scratch, in any language, (and I quote) "even in LISP if that's the right decision." Unfortunately the first version of Postgres was written in LISP --- my breed of humor was apparently unappreciated at that time. But from a research perspective the goal was no longer to produce something that actually worked in the real world, but to explore new ideas, including bad ones. I wasn't involved with Postgres personally, but I think Larry's analysis was essentially correct as I know it. I was extraordinarily lucky to have ended up at Berkeley in the mid-70s when UNIX was just becoming a "thing", and I can assure you that while there were a lot of people who just wanted to get their degrees, there was also a large cadre wanting to produce good stuff that could make peoples' lives better. eric ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [TUHS] Craft vs Research (Re: CMU Mach sources? 2019-06-27 0:16 ` tuhs @ 2019-06-27 17:06 ` Clem Cole 0 siblings, 0 replies; 55+ messages in thread From: Clem Cole @ 2019-06-27 17:06 UTC (permalink / raw) To: tuhs; +Cc: tuhs [-- Attachment #1: Type: text/plain, Size: 2561 bytes --] On Wed, Jun 26, 2019 at 9:12 PM <tuhs@eric.allman.name> wrote: > I think Larry is right, but also wrong. I think I can speak from > experience. > +1 > > The goal of research is not to produce consumer-ready code, but to > explore ideas. Nasty things sometimes happen in that environment. > > But that doesn't mean that code doesn't have to work. And BTW, Mach is an example of something that did work. And it worked "good enough" -- I think Ted's comments follow exactly these ideas. > My introduction to coding on a research project was INGRES, at the time > the competitor to System R (now DB/2, better known as "anything SQL") > from IBM Research. By the very nature of the problem, the main complaint > was that "Relational Databases Cannot Work" --- so proving that they could was > a major part of the research agenda. > > At one point (pre-commercial) INGRES stored the telecom wiring diagram of > New York City. It wasn't always a pleasant experience, but we learned a > lot, mostly happy, most of the time. A lot of our motivationwas because > real people were using our code to do real work. Had we hung them out in > the wind to dry, we wouldn't have gotten that feedback, and frankly I > think RDBMS wouldn't have progressed so far and so fast. > > But when I left INGRES I talked with Mike Stonebraker, who asked me > where I thought the project should be going. At that point I thought it > was clear that the research objectives had been satisfied, and there was the > beginnings of a commercial company to move it forward, so I advised that > the old code base (which at that point I had written or > substantially modified well over 50%) should be abandoned. Do a new system > from scratch, in any language, (and I quote) "even in LISP if that's the > right decision." Unfortunately the first version of Postgres > was written in LISP --- my breed of humor was apparently unappreciated at > that time. But from a research perspective the goal was no longer to produce > something that actually worked in the real world, but to explore new > ideas, including bad ones. I wasn't involved with Postgres personally, > but I think Larry's analysis was essentially correct as I know it. > > I was extraordinarily lucky to have ended up at Berkeley in the mid-70s when > UNIX was just becoming a "thing", and I can assure you that while there > were a lot of people who just wanted to get their degrees, there was also > a large cadre wanting to produce good stuff that could make peoples' > lives better. > Well said thanks, Clem [-- Attachment #2: Type: text/html, Size: 5622 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [TUHS] CMU Mach sources? 2019-06-25 0:45 ` Larry McVoy 2019-06-25 0:55 ` Kurt H Maier @ 2019-06-25 1:00 ` Richard Salz 2019-06-25 8:00 ` Kevin Bowling 2019-06-26 2:45 ` Kurt H Maier 1 sibling, 2 replies; 55+ messages in thread From: Richard Salz @ 2019-06-25 1:00 UTC (permalink / raw) To: Larry McVoy; +Cc: tuhs [-- Attachment #1: Type: text/plain, Size: 93 bytes --] Is this really the kind of commentary appropriate for this list? I mean I'm new here, but... [-- Attachment #2: Type: text/html, Size: 119 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [TUHS] CMU Mach sources? 2019-06-25 1:00 ` [TUHS] " Richard Salz @ 2019-06-25 8:00 ` Kevin Bowling 2019-06-25 12:11 ` Arthur Krewat 2019-06-26 2:45 ` Kurt H Maier 1 sibling, 1 reply; 55+ messages in thread From: Kevin Bowling @ 2019-06-25 8:00 UTC (permalink / raw) To: Richard Salz; +Cc: TUHS main list Why not? The utility of history isn't just recording or paying reverence for the past, we can also draw conclusions in the current or insights into the future -- "the old new thing" That's certainly why I'm here and invest in computer history. Of course it can be lossy, and victors get more air time. But there's nothing inherently wrong with strong opinions or criticism of the past. Regards, Kevin On Mon, Jun 24, 2019 at 6:01 PM Richard Salz <rich.salz@gmail.com> wrote: > > Is this really the kind of commentary appropriate for this list? I mean I'm new here, but... ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [TUHS] CMU Mach sources? 2019-06-25 8:00 ` Kevin Bowling @ 2019-06-25 12:11 ` Arthur Krewat 2019-06-25 12:17 ` Arthur Krewat 0 siblings, 1 reply; 55+ messages in thread From: Arthur Krewat @ 2019-06-25 12:11 UTC (permalink / raw) To: tuhs There's nothing like sitting in a room listening to your elders argue over minutiae. Or huge issues such as code cleanliness ;) I didn't even graduate high school, but one of the first things my mentor/boss did before I started working for him as a consultant was to comment, and write clean code. And that was on TOPS-10, using MACRO-10. I've recently been exposed to a grad student's C++ code, and between no error checking and outright lack of formatting or any other care in the world for "clean" code, his stuff is atrocious. His casts from one type to another to another to another through nested function calls makes my skin crawl. ak On 6/25/2019 4:00 AM, Kevin Bowling wrote: > Why not? The utility of history isn't just recording or paying > reverence for the past, we can also draw conclusions in the current or > insights into the future -- "the old new thing" > > That's certainly why I'm here and invest in computer history. Of > course it can be lossy, and victors get more air time. But there's > nothing inherently wrong with strong opinions or criticism of the > past. > > Regards, > Kevin > > On Mon, Jun 24, 2019 at 6:01 PM Richard Salz <rich.salz@gmail.com> wrote: >> Is this really the kind of commentary appropriate for this list? I mean I'm new here, but... ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [TUHS] CMU Mach sources? 2019-06-25 12:11 ` Arthur Krewat @ 2019-06-25 12:17 ` Arthur Krewat 0 siblings, 0 replies; 55+ messages in thread From: Arthur Krewat @ 2019-06-25 12:17 UTC (permalink / raw) To: tuhs That should have read *teach me to comment, and write clean code. On 6/25/2019 8:11 AM, Arthur Krewat wrote: > was to comment, and write clean code. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [TUHS] CMU Mach sources? 2019-06-25 1:00 ` [TUHS] " Richard Salz 2019-06-25 8:00 ` Kevin Bowling @ 2019-06-26 2:45 ` Kurt H Maier 2019-06-26 2:56 ` Larry McVoy 1 sibling, 1 reply; 55+ messages in thread From: Kurt H Maier @ 2019-06-26 2:45 UTC (permalink / raw) To: Richard Salz; +Cc: tuhs On Mon, Jun 24, 2019 at 09:00:28PM -0400, Richard Salz wrote: > Is this really the kind of commentary appropriate for this list? I mean I'm > new here, but... It might not be, but it is definitely relevant to Unix. Arguably the drivers of Unix's development movement away from R&D-focused places and toward product-oriented entities had at least a little to do with Larry's topic of complaint. Product managers gained the ammunition to demand sustainable development practices, while R&D got a little leaner, a little more focused on demonstrating the thesis, a little less focused on who might need to run this code five years on... I'd say there's a thesis to be written about the economics of support contracts vs the economics of proving concepts, but since I'm not volunteering to write it, I'll shut up about it on TUHS. Suffice to say the sociology surrounding the evolution of Unix is a topic I find fascinating, even if it's not strictly technical. khm ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [TUHS] CMU Mach sources? 2019-06-26 2:45 ` Kurt H Maier @ 2019-06-26 2:56 ` Larry McVoy 2019-06-26 15:11 ` Theodore Ts'o 0 siblings, 1 reply; 55+ messages in thread From: Larry McVoy @ 2019-06-26 2:56 UTC (permalink / raw) To: Richard Salz, Larry McVoy, tuhs On Tue, Jun 25, 2019 at 07:45:03PM -0700, Kurt H Maier wrote: > On Mon, Jun 24, 2019 at 09:00:28PM -0400, Richard Salz wrote: > > Is this really the kind of commentary appropriate for this list? I mean I'm > > new here, but... > > It might not be, but it is definitely relevant to Unix. Arguably the > drivers of Unix's development movement away from R&D-focused places and > toward product-oriented entities had at least a little to do with > Larry's topic of complaint. Product managers gained the ammunition to > demand sustainable development practices, while R&D got a little leaner, > a little more focused on demonstrating the thesis, a little less focused > on who might need to run this code five years on... In the good old days at Sun, we were very focussed on who would run this code for decades to come. I think the engineers at Sun were very focussed on helping people, the reason we were there was because the work we did helped people. The leverage was how much work we could do versus how much that helped people. That is product oriented. I think the reason that any engineer works is because they feel like their work helps someone. As an engineer, I wanted to go to the place and do the work that had the best chance of helping someone. All of Sun, when I was there, was like that. We were there to help. Yeah, of course, we wanted to make money, but all of us wanted to help. It's the dream, you do work, your work helps. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [TUHS] CMU Mach sources? 2019-06-26 2:56 ` Larry McVoy @ 2019-06-26 15:11 ` Theodore Ts'o 2019-06-26 17:44 ` Larry McVoy 2019-06-26 19:25 ` Adam Thornton 0 siblings, 2 replies; 55+ messages in thread From: Theodore Ts'o @ 2019-06-26 15:11 UTC (permalink / raw) To: Larry McVoy; +Cc: tuhs On Tue, Jun 25, 2019 at 07:56:46PM -0700, Larry McVoy wrote: > > It might not be, but it is definitely relevant to Unix. Arguably the > > drivers of Unix's development movement away from R&D-focused places and > > toward product-oriented entities had at least a little to do with > > Larry's topic of complaint. Product managers gained the ammunition to > > demand sustainable development practices, while R&D got a little leaner, > > a little more focused on demonstrating the thesis, a little less focused > > on who might need to run this code five years on... > > In the good old days at Sun, we were very focussed on who would run > this code for decades to come. I think the engineers at Sun were very > focussed on helping people, the reason we were there was because the > work we did helped people. The leverage was how much work we could > do versus how much that helped people. That is product oriented. > > I think the reason that any engineer works is because they feel like > their work helps someone. As an engineer, I wanted to go to the place > and do the work that had the best chance of helping someone. All of > Sun, when I was there, was like that. We were there to help. Yeah, > of course, we wanted to make money, but all of us wanted to help. > It's the dream, you do work, your work helps. Motivations and incentives are a very big and important aspect which is often overlooked in large scale projects. For example, one of the really big problems with device drivers in the embedded space is that the team that works on SOC version X gets disbanded, and immediately reassigned to SOC verison X+1, sometimes before product has even shipped. Having one device driver that works for SOC versions N, N+1, N+2, ... N+5, is really important from a maintainability and being able to send out bug fixes for security flaws. However, it means that whenever you make changes, you need to test on N different older versions. And between the need to release product quickly, and the fact that engineers are !@#@! expensive, and the teams constantly getting formed and reformed, it's much easier to do code reuse by copying, and so you have N different versions of a device driver in a Board Support Package version of the Linux kernel shipping by a SOC vendor. Unfortunately, I have to disagree with Larry, there are many, many engineers who works because they get a paycheck, and so they go home at 5pm. Some people might be free to improve their code on their own time, or late at night, but corporation also preach "work/life balance" --- and then don't fund time for making code long-term maintainable or reducing tech debt. Open source helps because embarassment can be a great motivator, but more important are the fact that there are people who are empowered to say "no" who don't work for the corporation who is trying to cut corners, and who have a higher allegiance to the codebase than their employer. There is a similar related issue around publishing papers to document great ideas. This takes time away from product development, and it used to be that Sun was really prolific at documenting their technical innovations at conferences like Usenix. Over time, the academic traditions started dying off, and managers who came from that tradition moved on, retired, or got promoted beyond the point where they could encourage engineers to do that work. And it wasn't just at Sun; I was working at IBM when IBM decided to take away the (de minimus) bonus for publishing papers at conferences. But at the Usenix board, I remember looking at a chart of the declining number of ATC papers coming from industry over time. And it was very depressing... And the key for all of this is motivation and incentives, as any good historian will tell you. This is true whether probing the start of wars, or the decline of a technical community or tradition. - Ted ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [TUHS] CMU Mach sources? 2019-06-26 15:11 ` Theodore Ts'o @ 2019-06-26 17:44 ` Larry McVoy 2019-06-26 18:01 ` arnold ` (2 more replies) 2019-06-26 19:25 ` Adam Thornton 1 sibling, 3 replies; 55+ messages in thread From: Larry McVoy @ 2019-06-26 17:44 UTC (permalink / raw) To: Theodore Ts'o; +Cc: tuhs On Wed, Jun 26, 2019 at 11:11:43AM -0400, Theodore Ts'o wrote: > Unfortunately, I have to disagree with Larry, there are many, many > engineers who works because they get a paycheck, and so they go home > at 5pm. Some people might be free to improve their code on their own > time, or late at night, but corporation also preach "work/life > balance" --- and then don't fund time for making code long-term > maintainable or reducing tech debt. Yeah, I was talking about 25-30 years ago. And even then there were people who were there for the paycheck. But the people I considered my peers were people who cared deeply about doing work well. The motivation was that we were at Sun, everyone wanted a Sun workstation, which made it all the more important that we did stuff right. If you need any proof, look no further than me. I was the guy who was so happy to be at Sun, I walked around for 3 years saying "I'd do this job for free if I had enough money" :) I think that feeling still exists but it is much harder to find these days, systems work seems to have dried up, kids think a server is a VM, it's a strange world. > There is a similar related issue around publishing papers to document > great ideas. This takes time away from product development, and it > used to be that Sun was really prolific at documenting their technical > innovations at conferences like Usenix. Over time, the academic > traditions started dying off, and managers who came from that > tradition moved on, retired, or got promoted beyond the point where > they could encourage engineers to do that work. And it wasn't just at > Sun; I was working at IBM when IBM decided to take away the (de > minimus) bonus for publishing papers at conferences. Huh, I didn't know IBM gave bonuses for papers, Sun never did. I don't remember, but they may have paid for us to go to a conference. > But at the > Usenix board, I remember looking at a chart of the declining number of > ATC papers coming from industry over time. And it was very depressing... Tell me about it. Systems work just isn't what it once was. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [TUHS] CMU Mach sources? 2019-06-26 17:44 ` Larry McVoy @ 2019-06-26 18:01 ` arnold 2019-06-26 18:18 ` Warner Losh 2019-06-26 19:22 ` Chris Hanson 2019-06-26 19:30 ` Dennis Boone 2 siblings, 1 reply; 55+ messages in thread From: arnold @ 2019-06-26 18:01 UTC (permalink / raw) To: tytso, lm; +Cc: tuhs This is getting a little off topic ... There are still lots of motivated people. I found for myself that working on security products is very motivating; you're developing something that people really NEED, that protects them and their assets, and it's IMPORTANT, not just adding another shiny gadget onto Word or whatever. So, do I care about code quality? Very much. My workplace does too. That said, work/life balance is a real issue. I work to feed my family and keep a roof over their heads. Of course I want to enjoy my work and feel value from it, but out of necessity I've spent a lot of time where it wasn't so good. I'm fortunate that today it's good on both ends. :-) Arnold ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [TUHS] CMU Mach sources? 2019-06-26 18:01 ` arnold @ 2019-06-26 18:18 ` Warner Losh 0 siblings, 0 replies; 55+ messages in thread From: Warner Losh @ 2019-06-26 18:18 UTC (permalink / raw) To: arnold; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 863 bytes --] On Wed, Jun 26, 2019 at 12:01 PM <arnold@skeeve.com> wrote: > This is getting a little off topic ... > > There are still lots of motivated people. I found for myself that > working on security products is very motivating; you're developing > something > that people really NEED, that protects them and their assets, and > it's IMPORTANT, not just adding another shiny gadget onto Word or > whatever. > > So, do I care about code quality? Very much. My workplace does too. > > That said, work/life balance is a real issue. I work to feed my family > and keep a roof over their heads. Of course I want to enjoy my work > and feel value from it, but out of necessity I've spent a lot of time > where it wasn't so good. I'm fortunate that today it's good on both > ends. :-) > For me, work life balance dictates WHEN I do the work, not the work that I do. Warner [-- Attachment #2: Type: text/html, Size: 1284 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [TUHS] CMU Mach sources? 2019-06-26 17:44 ` Larry McVoy 2019-06-26 18:01 ` arnold @ 2019-06-26 19:22 ` Chris Hanson 2019-06-26 19:32 ` Ben Greenfield via TUHS 2019-06-26 19:30 ` Dennis Boone 2 siblings, 1 reply; 55+ messages in thread From: Chris Hanson @ 2019-06-26 19:22 UTC (permalink / raw) To: Tuhs One thing to remember about Mach is that it really was a *research* project. Some of the things that have been complained about, e.g. “pointless” or “needless” abstraction and layering, were done specifically to examine the effects of having those layers of abstraction. Does their presence enable different approaches to problems? Do they enable new features altogether? What’s given up by having them? And so on. Just as an example, a lot of the complexity in the Mach VM system comes from the idea that it could provide a substrate for all sorts of different types of systems, and it could have all sorts of different mechanisms underneath supporting it. This means that Mach’s creators got to do things like try dedicated network virtual memory, purpose-specific pagers, compressing pagers, etc. You may not need as much flexibility in a non-research system. For another example, Mach did a lot of extra work around things like processor sets that wouldn’t be needed on (say) a dual-CPU shared-cache uniform-memory systems, but turns out to be important when dealing with things like systems with a hierarchy of CPUs, caches, and memories. Did they know about all the possible needs for that before they started? Having met some of them, the people who created and worked on Mach were passionate about exploring the space of operating system architecture and worked to create a system that would be a good vehicle for that. That wasn’t their only goal—they were also part of the group creating what was at the time CMU’s next-generation academic computing environment—but the sum of their goals generally led to a very pragmatic approach to making things possible to try while also shipping. -- Chris ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [TUHS] CMU Mach sources? 2019-06-26 19:22 ` Chris Hanson @ 2019-06-26 19:32 ` Ben Greenfield via TUHS 2019-06-26 20:21 ` Larry McVoy 0 siblings, 1 reply; 55+ messages in thread From: Ben Greenfield via TUHS @ 2019-06-26 19:32 UTC (permalink / raw) To: Tuhs > On Jun 26, 2019, at 3:22 PM, Chris Hanson <cmhanson@eschatologist.net> wrote: > > One thing to remember about Mach is that it really was a *research* project. Some of the things that have been complained about, e.g. “pointless” or “needless” abstraction and layering, were done specifically to examine the effects of having those layers of abstraction. Does their presence enable different approaches to problems? I’m surprised the study of Mach needs any justification. Mach certainly happened and is certainly enjoys a large and growing installed base. I’m bothered that some feel the need to belittle the interests of others. I would be more impressed if those criticizing weren’t so hand-wavy and had more specific points…. > Do they enable new features altogether? What’s given up by having them? And so on. > > Just as an example, a lot of the complexity in the Mach VM system comes from the idea that it could provide a substrate for all sorts of different types of systems, and it could have all sorts of different mechanisms underneath supporting it. This means that Mach’s creators got to do things like try dedicated network virtual memory, purpose-specific pagers, compressing pagers, etc. You may not need as much flexibility in a non-research system. > > For another example, Mach did a lot of extra work around things like processor sets that wouldn’t be needed on (say) a dual-CPU shared-cache uniform-memory systems, but turns out to be important when dealing with things like systems with a hierarchy of CPUs, caches, and memories. Did they know about all the possible needs for that before they started? > > Having met some of them, the people who created and worked on Mach were passionate about exploring the space of operating system architecture and worked to create a system that would be a good vehicle for that. That wasn’t their only goal—they were also part of the group creating what was at the time CMU’s next-generation academic computing environment—but the sum of their goals generally led to a very pragmatic approach to making things possible to try while also shipping. > > -- Chris > ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [TUHS] CMU Mach sources? 2019-06-26 19:32 ` Ben Greenfield via TUHS @ 2019-06-26 20:21 ` Larry McVoy 2019-06-27 0:22 ` Chris Hanson 2019-06-27 4:01 ` Lyndon Nerenberg 0 siblings, 2 replies; 55+ messages in thread From: Larry McVoy @ 2019-06-26 20:21 UTC (permalink / raw) To: Ben Greenfield; +Cc: Tuhs On Wed, Jun 26, 2019 at 03:32:32PM -0400, Ben Greenfield via TUHS wrote: > I would be more impressed if those criticizing weren???t so hand-wavy and had more specific points???. OK, I'll bite. Go read the source in the FreeBSD tree, which has been reduced in size by 60% according to someone on the team. Then come back and draw me a picture of what it does. I get that what I'm asking is non-trivial, I've tried to do it and failed. As a pretty green guy it took me months to do that for SunOS but I could feel myself getting closer. I never got that feeling in the Mach code, I kept getting lost in code that made me say "why is this here?" What I've been trying to say all along is getting something to work is different from making something that both works and is clean. When something is clean it is like a well written paper, it is actively trying to help you understand the information. I value clean code, and I'm not a fan of people excusing messy code because researchers did it. As someone said to me in private, those same researchers are expected to write clear and understandable papers, why is code any different? I also agree with whoever said the Mach guys were trying out all sorts of different ideas, that's cool. What's not cool is that when those ideas didn't pan out they left in all the substrate that had proven to be not needed. And I'll freely admit Mach left a sour taste in my mouth. I read all the papers and those lead me to believe that the code would be on par with the SunOS code. When I finally got to read it I felt like a kid who was promised nice things only to have them taken away. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [TUHS] CMU Mach sources? 2019-06-26 20:21 ` Larry McVoy @ 2019-06-27 0:22 ` Chris Hanson 2019-06-27 1:02 ` Larry McVoy 2019-06-27 4:01 ` Lyndon Nerenberg 1 sibling, 1 reply; 55+ messages in thread From: Chris Hanson @ 2019-06-27 0:22 UTC (permalink / raw) To: Larry McVoy; +Cc: Tuhs On Jun 26, 2019, at 1:21 PM, Larry McVoy <lm@mcvoy.com> wrote: > > I also agree with whoever said the Mach guys were trying out all sorts > of different ideas, that's cool. What's not cool is that when those > ideas didn't pan out they left in all the substrate that had proven to > be not needed. It seems like you’re still missing the point. All the different ideas weren’t implemented by “the Mach [people] trying all sorts of different ideas” in-tree, they were implemented by a variety of researchers *atop* the large set of abstractions and layers Mach provided. All the substrate *wasn’t* proven to be not needed, if anything it was proven to be very useful in performing OS research experiments without having to do a lot of work on the substrate itself. I also read a lot of the Mach code very early in my career and found it pretty comprehensible. -- Chris ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [TUHS] CMU Mach sources? 2019-06-27 0:22 ` Chris Hanson @ 2019-06-27 1:02 ` Larry McVoy 2019-06-27 1:26 ` Chris Hanson 0 siblings, 1 reply; 55+ messages in thread From: Larry McVoy @ 2019-06-27 1:02 UTC (permalink / raw) To: Chris Hanson; +Cc: Tuhs On Wed, Jun 26, 2019 at 05:22:05PM -0700, Chris Hanson wrote: > On Jun 26, 2019, at 1:21 PM, Larry McVoy <lm@mcvoy.com> wrote: > > > > I also agree with whoever said the Mach guys were trying out all sorts > > of different ideas, that's cool. What's not cool is that when those > > ideas didn't pan out they left in all the substrate that had proven to > > be not needed. > > It seems like you???re still missing the point. I'm not missing anything. Go read this: https://www.cs.ubc.ca/~norm/508/2009W1/mach_usenix86.pdf It talks about how simple Mach is, how it is going to be what Unix wanted to be but Unix got too complicated. Etc. It sounds fantastic, too good to be true and that's exactly what the code is. You can go on all you want about all the cool research it enabled, which I've not disputed other than to say I didn't see much work out. But OK, cool research vehicle, got it. What it is not is the simple awesome system that the papers described. I was super stoked when I read that initial Mach paper, it seemed like they wanted to clean up Unix and they had a plan. I was very hopeful that they were doing that, I agreed with their statements in section 2. Anyone who has read the code would have a hard time reconciling their code with the picture they painted in their papers. And indeed, the Mach supporters have said nothing about the code, other than to say it is a research system and you can't expect clean code. If it had been advertised as that you wouldn't hear a peep out of me. But it was advertised as a clean up of poor choices in Unix, it was advertised as simple and clean. It is anything but that. I've got no problem with prototypes so long as it is clear that's what it is. My disappointment with Mach is I thought they were cleaning things up, that's what they said, that's not what they delivered. My beef is with their false advertising. If they had advertised that this was a research system for exploring OS research, not a production ready system, I'd have been fine. That's not how I read the Mach papers. They made promises that they didn't deliver. With that, I'm done on this topic. I'm not going to convince some people of what I think, and they are not going to convince me of what I think. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [TUHS] CMU Mach sources? 2019-06-27 1:02 ` Larry McVoy @ 2019-06-27 1:26 ` Chris Hanson 0 siblings, 0 replies; 55+ messages in thread From: Chris Hanson @ 2019-06-27 1:26 UTC (permalink / raw) To: Tuhs On Jun 26, 2019, at 6:02 PM, Larry McVoy <lm@mcvoy.com> wrote: > Anyone who has read the code would have a hard time reconciling their > code with the picture they painted in their papers. And indeed, the > Mach supporters have said nothing about the code, other than to say it > is a research system and you can't expect clean code. Then I’ll say it: I did find the Mach code plenty clean *for what it was trying to accomplish* — providing the layering and abstractions necessary to make extensible what had traditionally been kernel code, including allowing it to be developed out-of-tree. -- Chris ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [TUHS] CMU Mach sources? 2019-06-26 20:21 ` Larry McVoy 2019-06-27 0:22 ` Chris Hanson @ 2019-06-27 4:01 ` Lyndon Nerenberg 2019-06-27 10:34 ` Ben Greenfield via TUHS 1 sibling, 1 reply; 55+ messages in thread From: Lyndon Nerenberg @ 2019-06-27 4:01 UTC (permalink / raw) To: Larry McVoy; +Cc: Tuhs Larry McVoy writes: > OK, I'll bite. Go read the source in the FreeBSD tree, which has been > reduced in size by 60% according to someone on the team. Then come > back and draw me a picture of what it does. Larry, it seems to me your argument is the Mach code should never have been incorporated into BSD in the first place. That's fine, but it's not the Mach developers fault that happened, so maybe you should lay off them for not writing their research software to a production shop standard they were never a part of? --lyndon ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [TUHS] CMU Mach sources? 2019-06-27 4:01 ` Lyndon Nerenberg @ 2019-06-27 10:34 ` Ben Greenfield via TUHS 2019-06-27 10:59 ` arnold 0 siblings, 1 reply; 55+ messages in thread From: Ben Greenfield via TUHS @ 2019-06-27 10:34 UTC (permalink / raw) To: Lyndon Nerenberg, Tuhs > On Jun 27, 2019, at 12:01 AM, Lyndon Nerenberg <lyndon@orthanc.ca> wrote: > > Larry McVoy writes: > >> OK, I'll bite. Go read the source in the FreeBSD tree, which has been >> reduced in size by 60% according to someone on the team. Then come >> back and draw me a picture of what it does. > > Larry, it seems to me your argument is the Mach code should never > have been incorporated into BSD in the first place. That's fine, > but it's not the Mach developers fault that happened, so maybe you > should lay off them for not writing their research software to a > production shop standard they were never a part of? My understanding is that the BSD layer was a requirement from DARPA. DARPA wanted a “normal” interface to the kernel and BSD was that interface. > > --lyndon ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [TUHS] CMU Mach sources? 2019-06-27 10:34 ` Ben Greenfield via TUHS @ 2019-06-27 10:59 ` arnold 2019-06-27 11:13 ` Ben Greenfield via TUHS 0 siblings, 1 reply; 55+ messages in thread From: arnold @ 2019-06-27 10:59 UTC (permalink / raw) To: tuhs, lyndon, ben Larry McVoy writes: > >> OK, I'll bite. Go read the source in the FreeBSD tree, which has been > >> reduced in size by 60% according to someone on the team. Then come > >> back and draw me a picture of what it does. On Jun 27, 2019, at 12:01 AM, Lyndon Nerenberg <lyndon@orthanc.ca> wrote: > > Larry, it seems to me your argument is the Mach code should never > > have been incorporated into BSD in the first place. That's fine, > > but it's not the Mach developers fault that happened, so maybe you > > should lay off them for not writing their research software to a > > production shop standard they were never a part of? Ben Greenfield via TUHS <tuhs@minnie.tuhs.org> wrote: > My understanding is that the BSD layer was a requirement from DARPA. > DARPA wanted a “normal” interface to the kernel and BSD was that interface. Yes, Mach had to provide a BSD layer on top, but that's not the source of Larry's gripes. It's the other way around. 4.4 BSD pulled the VM code out of Mach and into BSD to provide mmap and some level of portability off the Vax. From there the Mach code got into FreeBSD. That's what Larry is complaining about and what Lyndon is saying isn't fair to the Mach guys. Thanks, Arnold ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [TUHS] CMU Mach sources? 2019-06-27 10:59 ` arnold @ 2019-06-27 11:13 ` Ben Greenfield via TUHS 2019-06-27 11:39 ` arnold 2019-06-27 14:58 ` Warner Losh 0 siblings, 2 replies; 55+ messages in thread From: Ben Greenfield via TUHS @ 2019-06-27 11:13 UTC (permalink / raw) To: arnold, Tuhs > On Jun 27, 2019, at 6:59 AM, arnold@skeeve.com wrote: > > Larry McVoy writes: >>>> OK, I'll bite. Go read the source in the FreeBSD tree, which has been >>>> reduced in size by 60% according to someone on the team. Then come >>>> back and draw me a picture of what it does. > > On Jun 27, 2019, at 12:01 AM, Lyndon Nerenberg <lyndon@orthanc.ca> wrote: >>> Larry, it seems to me your argument is the Mach code should never >>> have been incorporated into BSD in the first place. That's fine, >>> but it's not the Mach developers fault that happened, so maybe you >>> should lay off them for not writing their research software to a >>> production shop standard they were never a part of? > > Ben Greenfield via TUHS <tuhs@minnie.tuhs.org> wrote: >> My understanding is that the BSD layer was a requirement from DARPA. >> DARPA wanted a “normal” interface to the kernel and BSD was that interface. > > Yes, Mach had to provide a BSD layer on top, but that's not the source > of Larry's gripes. > > It's the other way around. 4.4 BSD pulled the VM code out of Mach and > into BSD to provide mmap and some level of portability off the Vax. From > there the Mach code got into FreeBSD. That's what Larry is complaining > about and what Lyndon is saying isn't fair to the Mach guys. Thank you for this clarification, so this conversation has been going on since the 80’s and gets ignited from time to time. Thank you, Ben > > Thanks, > > Arnold ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [TUHS] CMU Mach sources? 2019-06-27 11:13 ` Ben Greenfield via TUHS @ 2019-06-27 11:39 ` arnold 2019-06-27 14:58 ` Warner Losh 1 sibling, 0 replies; 55+ messages in thread From: arnold @ 2019-06-27 11:39 UTC (permalink / raw) To: tuhs, ben, arnold Ben Greenfield <ben@cogs.com> wrote: > Thank you for this clarification, so this conversation has been going > on since the 80’s and gets ignited from time to time. 4.4 was very early 90s, IIRC, but basically, yes. Arnold ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [TUHS] CMU Mach sources? 2019-06-27 11:13 ` Ben Greenfield via TUHS 2019-06-27 11:39 ` arnold @ 2019-06-27 14:58 ` Warner Losh 2019-06-27 17:25 ` Larry McVoy 1 sibling, 1 reply; 55+ messages in thread From: Warner Losh @ 2019-06-27 14:58 UTC (permalink / raw) To: Ben Greenfield; +Cc: Tuhs [-- Attachment #1: Type: text/plain, Size: 3453 bytes --] On Thu, Jun 27, 2019 at 5:13 AM Ben Greenfield via TUHS < tuhs@minnie.tuhs.org> wrote: > > > > On Jun 27, 2019, at 6:59 AM, arnold@skeeve.com wrote: > > > > Larry McVoy writes: > >>>> OK, I'll bite. Go read the source in the FreeBSD tree, which has > been > >>>> reduced in size by 60% according to someone on the team. Then come > >>>> back and draw me a picture of what it does. > > > > On Jun 27, 2019, at 12:01 AM, Lyndon Nerenberg <lyndon@orthanc.ca> > wrote: > >>> Larry, it seems to me your argument is the Mach code should never > >>> have been incorporated into BSD in the first place. That's fine, > >>> but it's not the Mach developers fault that happened, so maybe you > >>> should lay off them for not writing their research software to a > >>> production shop standard they were never a part of? > > > > Ben Greenfield via TUHS <tuhs@minnie.tuhs.org> wrote: > >> My understanding is that the BSD layer was a requirement from DARPA. > >> DARPA wanted a “normal” interface to the kernel and BSD was that > interface. > > > > Yes, Mach had to provide a BSD layer on top, but that's not the source > > of Larry's gripes. > > > > It's the other way around. 4.4 BSD pulled the VM code out of Mach and > > into BSD to provide mmap and some level of portability off the Vax. From > > there the Mach code got into FreeBSD. That's what Larry is complaining > > about and what Lyndon is saying isn't fair to the Mach guys. > > Thank you for this clarification, so this conversation has been going on > since the 80’s and gets ignited from time to time. > Yea, there's been three or four rounds of rototilling in the FreeBSD vm. While it shares some structures with its Mach ancestors, complaining about it to paint Mach as this or that is unfair. FreeBSD's sys/vm has had a crapton of changes to make to scale in an MP system, to adopt non-uniform page sizes, etc. Some of these changes have been done with skill and subtly. Some have been done by a ham-fisted goober. It would overstate things to say the most recognizable part of Mach is the copyright headers :), but those bits are arguable the most unchanged. What's resulted lacks architectural purity because it wasn't designed from scratch to be pure. It's grown organically over the last 30-odd years as different groups, companies and organizations have found it necessary to fund development. The SunOS 4.x code, which was almost donated to the BSD project only to be scuttled at the last minute, has the twin advantages of being purpose built for only two architectures and didn't need to scale to thousands of CPUs, and stopped evolving in the 90s. As such, it can maintain its architectural purity since it's not needed to grow and adapt since then. All that "growth" happened in Solaris. So it's also a bit unfair to compare that code which was developed over a decade to FreeBSD's. But yea, DARPA was about networking in the Unix world. BSD was Unix at the time since AT&T didn't have the business structure to do the contracts, and BSD's 2BSD or 3BSD was little more than a slightly more evolved V7 research edition with some really cool user land features and a few more drivers for hardware BSD users had. The Mach VM came late to the game and was never the focus of the DARPA contracts. For another view on how well CSRG integrated Mach into BSD, see NetBSD's uvm, a complete rewrite. Warner [-- Attachment #2: Type: text/html, Size: 4333 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [TUHS] CMU Mach sources? 2019-06-27 14:58 ` Warner Losh @ 2019-06-27 17:25 ` Larry McVoy 0 siblings, 0 replies; 55+ messages in thread From: Larry McVoy @ 2019-06-27 17:25 UTC (permalink / raw) To: Warner Losh; +Cc: Tuhs On Thu, Jun 27, 2019 at 08:58:22AM -0600, Warner Losh wrote: > The SunOS 4.x code, which was almost donated to the BSD project only to be > scuttled at the last minute, has the twin advantages of being purpose built > for only two architectures and didn't need to scale to thousands of CPUs, > and stopped evolving in the 90s. As such, it can maintain its architectural > purity since it's not needed to grow and adapt since then. All that > "growth" happened in Solaris. So it's also a bit unfair to compare that > code which was developed over a decade to FreeBSD's. Yeah, I actually agree with this. The SunOS I love so much didn't scale at all. Which means it was inherently more simple and easier to understand. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [TUHS] CMU Mach sources? 2019-06-26 17:44 ` Larry McVoy 2019-06-26 18:01 ` arnold 2019-06-26 19:22 ` Chris Hanson @ 2019-06-26 19:30 ` Dennis Boone 2 siblings, 0 replies; 55+ messages in thread From: Dennis Boone @ 2019-06-26 19:30 UTC (permalink / raw) To: tuhs > For another example, Mach did a lot of extra work around things like > processor sets that wouldn’t be needed on (say) a dual-CPU > shared-cache uniform-memory systems, but turns out to be important > when dealing with things like systems with a hierarchy of CPUs, > caches, and memories. Did they know about all the possible needs for > that before they started? For example, our campus had one of these, with 96 processors if I recall correctly. Mach-based OS. https://en.wikipedia.org/wiki/BBN_Butterfly De ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [TUHS] CMU Mach sources? 2019-06-26 15:11 ` Theodore Ts'o 2019-06-26 17:44 ` Larry McVoy @ 2019-06-26 19:25 ` Adam Thornton 1 sibling, 0 replies; 55+ messages in thread From: Adam Thornton @ 2019-06-26 19:25 UTC (permalink / raw) To: Theodore Ts'o, tuhs [-- Attachment #1: Type: text/plain, Size: 5400 bytes --] "And the key for all of this is motivation and incentives, as any good historian will tell you. This is true whether probing the start of wars, or the decline of a technical community or tradition." This. I work for the Large Synoptic Survey Telescope. I'm in the Data Management group, and specifically in the Science Quality and Reliability Engineering team. The 50,000 foot view of what we do is try to bring software engineering to astronomical software. In general, the thing about scientific software is that, to put it crudely, no one gets a Nobel Prize for software. There's a very strong incentive to write a thing that will solve whatever particular problem you need solved for your paper, and no more. There's also the (highly correlated) problem that, to an established researcher, graduate student labor is free, and your graduate students want to finish their thesis, not engineer quality software. Whereas what I'd like to do is factor the common infrastructure--of which there is a lot--out of the various teetering stacks of special-purpose software and create some sane and maintainable infrastructure that individual researchers can easily and relatively gracefully extend to answer their specific questions. Adam On Wed, Jun 26, 2019 at 8:12 AM Theodore Ts'o <tytso@mit.edu> wrote: > On Tue, Jun 25, 2019 at 07:56:46PM -0700, Larry McVoy wrote: > > > It might not be, but it is definitely relevant to Unix. Arguably the > > > drivers of Unix's development movement away from R&D-focused places and > > > toward product-oriented entities had at least a little to do with > > > Larry's topic of complaint. Product managers gained the ammunition to > > > demand sustainable development practices, while R&D got a little > leaner, > > > a little more focused on demonstrating the thesis, a little less > focused > > > on who might need to run this code five years on... > > > > In the good old days at Sun, we were very focussed on who would run > > this code for decades to come. I think the engineers at Sun were very > > focussed on helping people, the reason we were there was because the > > work we did helped people. The leverage was how much work we could > > do versus how much that helped people. That is product oriented. > > > > I think the reason that any engineer works is because they feel like > > their work helps someone. As an engineer, I wanted to go to the place > > and do the work that had the best chance of helping someone. All of > > Sun, when I was there, was like that. We were there to help. Yeah, > > of course, we wanted to make money, but all of us wanted to help. > > It's the dream, you do work, your work helps. > > Motivations and incentives are a very big and important aspect which > is often overlooked in large scale projects. > > For example, one of the really big problems with device drivers in the > embedded space is that the team that works on SOC version X gets > disbanded, and immediately reassigned to SOC verison X+1, sometimes > before product has even shipped. Having one device driver that works > for SOC versions N, N+1, N+2, ... N+5, is really important from a > maintainability and being able to send out bug fixes for security > flaws. However, it means that whenever you make changes, you need to > test on N different older versions. And between the need to release > product quickly, and the fact that engineers are !@#@! expensive, and > the teams constantly getting formed and reformed, it's much easier to > do code reuse by copying, and so you have N different versions of a > device driver in a Board Support Package version of the Linux kernel > shipping by a SOC vendor. > > Unfortunately, I have to disagree with Larry, there are many, many > engineers who works because they get a paycheck, and so they go home > at 5pm. Some people might be free to improve their code on their own > time, or late at night, but corporation also preach "work/life > balance" --- and then don't fund time for making code long-term > maintainable or reducing tech debt. > > Open source helps because embarassment can be a great motivator, but > more important are the fact that there are people who are empowered to > say "no" who don't work for the corporation who is trying to cut > corners, and who have a higher allegiance to the codebase than their > employer. > > There is a similar related issue around publishing papers to document > great ideas. This takes time away from product development, and it > used to be that Sun was really prolific at documenting their technical > innovations at conferences like Usenix. Over time, the academic > traditions started dying off, and managers who came from that > tradition moved on, retired, or got promoted beyond the point where > they could encourage engineers to do that work. And it wasn't just at > Sun; I was working at IBM when IBM decided to take away the (de > minimus) bonus for publishing papers at conferences. But at the > Usenix board, I remember looking at a chart of the declining number of > ATC papers coming from industry over time. And it was very depressing... > > And the key for all of this is motivation and incentives, as any good > historian will tell you. This is true whether probing the start of > wars, or the decline of a technical community or tradition. > > - Ted > [-- Attachment #2: Type: text/html, Size: 6208 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [TUHS] CMU Mach sources? 2019-06-23 4:38 [TUHS] CMU Mach sources? Chris Hanson 2019-06-23 5:15 ` Larry McVoy 2019-06-23 8:04 ` Jason Stevens @ 2019-06-23 8:27 ` Kevin Bowling 2019-06-25 3:07 ` Gregg Levine 2019-06-25 7:49 ` Jason Stevens 4 siblings, 0 replies; 55+ messages in thread From: Kevin Bowling @ 2019-06-23 8:27 UTC (permalink / raw) To: Chris Hanson; +Cc: TUHS main list If you find this stash I am looking for the rs6000 port that lived in the "unpublished" directory of ftp://ftp.cs.cmu.edu/afs/cs/project/mach/public/doc/unpublished/rs6k_install.ps Regards, Kevin On Sat, Jun 22, 2019 at 9:45 PM Chris Hanson <cmhanson@eschatologist.net> wrote: > > Does anyone know whether CMU’s local Mach sources have been preserved? > > I’m not just talking about MK84.default.tar.Z and so on, I’m talking about all the bits of Mach that were used on cluster systems on campus, prior to the switch to vendor UNIX. > > I know at least one person who had complete MacMach sources for the last version, but threw out the backup discs with the sources in the process of moving. So I know they exist. > > If nothing else, CMU did provide other sites their UX source package (eg UX42), which was the BSD single server environment. So I know that has to be out there, somewhere. > > — Chris > > Sent from my iPhone ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [TUHS] CMU Mach sources? 2019-06-23 4:38 [TUHS] CMU Mach sources? Chris Hanson ` (2 preceding siblings ...) 2019-06-23 8:27 ` Kevin Bowling @ 2019-06-25 3:07 ` Gregg Levine 2019-06-25 8:15 ` Kevin Bowling 2019-06-25 18:18 ` Chris Hanson 2019-06-25 7:49 ` Jason Stevens 4 siblings, 2 replies; 55+ messages in thread From: Gregg Levine @ 2019-06-25 3:07 UTC (permalink / raw) To: Tuhs Hello! Actually Chris, I found a complete collection of both CMU Mach and the Flux Group Mach, and even MkMach at the FTP2 site for the French OpenBSD location, ftp://ftp2.fr.openbsd.org under the pub and the mach directories. In all actuality I first discovered the Mach code base and the binary at the Flux Group offices of the Utah Computer Sciences site. They shut that down around the turn of the century. And once at the Arizona site for their computer sciences site. I believe it is gone as is the CMU one. And Jason I found your Gunkies Wiki with a link to your incredible storage site. ----- Gregg C Levine gregg.drwho8@gmail.com "This signature fought the Time Wars, time and again." On Sun, Jun 23, 2019 at 12:45 AM Chris Hanson <cmhanson@eschatologist.net> wrote: > > Does anyone know whether CMU’s local Mach sources have been preserved? > > I’m not just talking about MK84.default.tar.Z and so on, I’m talking about all the bits of Mach that were used on cluster systems on campus, prior to the switch to vendor UNIX. > > I know at least one person who had complete MacMach sources for the last version, but threw out the backup discs with the sources in the process of moving. So I know they exist. > > If nothing else, CMU did provide other sites their UX source package (eg UX42), which was the BSD single server environment. So I know that has to be out there, somewhere. > > — Chris > > Sent from my iPhone ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [TUHS] CMU Mach sources? 2019-06-25 3:07 ` Gregg Levine @ 2019-06-25 8:15 ` Kevin Bowling 2019-06-25 18:18 ` Chris Hanson 1 sibling, 0 replies; 55+ messages in thread From: Kevin Bowling @ 2019-06-25 8:15 UTC (permalink / raw) To: Gregg Levine; +Cc: Tuhs Thanks for the link. This is overall a great find, and you almost totally made my night, but the doc/unpublished directory seems to be pruned versus what other docs in here state :(. In particular I'm looking for the stuff mentioned in ftp://ftp2.fr.openbsd.org/pub/mach/cmu/FAQ/rs6k_announce On Mon, Jun 24, 2019 at 8:08 PM Gregg Levine <gregg.drwho8@gmail.com> wrote: > > Hello! > Actually Chris, I found a complete collection of both CMU Mach and the > Flux Group Mach, and even MkMach at the FTP2 site for the French > OpenBSD location, ftp://ftp2.fr.openbsd.org under the pub and the mach > directories. > > In all actuality I first discovered the Mach code base and the binary > at the Flux Group offices of the Utah Computer Sciences site. They > shut that down around the turn of the century. And once at the Arizona > site for their computer sciences site. I believe it is gone as is the > CMU one. > > And Jason I found your Gunkies Wiki with a link to your incredible > storage site. > ----- > Gregg C Levine gregg.drwho8@gmail.com > "This signature fought the Time Wars, time and again." > > On Sun, Jun 23, 2019 at 12:45 AM Chris Hanson > <cmhanson@eschatologist.net> wrote: > > > > Does anyone know whether CMU’s local Mach sources have been preserved? > > > > I’m not just talking about MK84.default.tar.Z and so on, I’m talking about all the bits of Mach that were used on cluster systems on campus, prior to the switch to vendor UNIX. > > > > I know at least one person who had complete MacMach sources for the last version, but threw out the backup discs with the sources in the process of moving. So I know they exist. > > > > If nothing else, CMU did provide other sites their UX source package (eg UX42), which was the BSD single server environment. So I know that has to be out there, somewhere. > > > > — Chris > > > > Sent from my iPhone ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [TUHS] CMU Mach sources? 2019-06-25 3:07 ` Gregg Levine 2019-06-25 8:15 ` Kevin Bowling @ 2019-06-25 18:18 ` Chris Hanson 2019-06-25 20:23 ` Gregg Levine 2019-06-26 0:53 ` Jason Stevens 1 sibling, 2 replies; 55+ messages in thread From: Chris Hanson @ 2019-06-25 18:18 UTC (permalink / raw) To: Gregg Levine; +Cc: Tuhs On Jun 24, 2019, at 8:07 PM, Gregg Levine <gregg.drwho8@gmail.com> wrote: > > Actually Chris, I found a complete collection of both CMU Mach and the > Flux Group Mach, and even MkMach at the FTP2 site for the French > OpenBSD location, ftp://ftp2.fr.openbsd.org under the pub and the mach > directories. Thanks for this, but it’s just the stuff that was made publicly available by these groups. It’s useful, especially to have via FTP (easier to sync), but it doesn’t cover things like UX42 (the BSD atop Mach that CMU deployed to cluster workstations). -- Chris ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [TUHS] CMU Mach sources? 2019-06-25 18:18 ` Chris Hanson @ 2019-06-25 20:23 ` Gregg Levine 2019-06-26 1:04 ` Jason Stevens 2019-06-26 0:53 ` Jason Stevens 1 sibling, 1 reply; 55+ messages in thread From: Gregg Levine @ 2019-06-25 20:23 UTC (permalink / raw) To: Chris Hanson; +Cc: Tuhs Hello! And oddly enough the Finnish site ftp://nic.funet.fi maintains a collection of Mach related items at ftp://nic.funet.fi/pub/doc/OS/Mach/ and and at ftp://nic.funet.fi/pub/mach/ and a place named LYX contains Mach at ftp://ftp.lyx.org/pub/mach/ Ideally it is just a duplicate of the first one from earlier. And then Google gets lost. It also includes several hits to Jason's work, but after that Google gets lost. ----- Gregg C Levine gregg.drwho8@gmail.com "This signature fought the Time Wars, time and again." On Tue, Jun 25, 2019 at 2:18 PM Chris Hanson <cmhanson@eschatologist.net> wrote: > > On Jun 24, 2019, at 8:07 PM, Gregg Levine <gregg.drwho8@gmail.com> wrote: > > > > Actually Chris, I found a complete collection of both CMU Mach and the > > Flux Group Mach, and even MkMach at the FTP2 site for the French > > OpenBSD location, ftp://ftp2.fr.openbsd.org under the pub and the mach > > directories. > > Thanks for this, but it’s just the stuff that was made publicly available by these groups. It’s useful, especially to have via FTP (easier to sync), but it doesn’t cover things like UX42 (the BSD atop Mach that CMU deployed to cluster workstations). > > -- Chris > > ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [TUHS] CMU Mach sources? 2019-06-25 20:23 ` Gregg Levine @ 2019-06-26 1:04 ` Jason Stevens 0 siblings, 0 replies; 55+ messages in thread From: Jason Stevens @ 2019-06-26 1:04 UTC (permalink / raw) To: Chris Hanson, Gregg Levine; +Cc: Tuhs [-- Attachment #1: Type: text/plain, Size: 2269 bytes --] After I got lites + 3.0 on netbsd running on qemu with networking to show how painfully slow it was, it felt like I was the last person on earth to care about this stuff. I think the gnumach folks had some interesting trip on rehosting Mach on oskit to get all those Linux 2.0 drivers but they never could get the push to x86_64. I guess it's hard to compete in the Hurd cathedral vs the Linux bazaar... So to speak. Probably the more important stuff to archive and find is mailing lists although I don't know of anything surviving anywhere. I guess it was deep underground as the internet lawyers were in fear about emailing patches and having AT&T show up at their door demanding new borns. Oh well such is life when you are chasing evelotionary dead ends. It's not like a 4.3BSD os is going to set the world on fire, but then again I did save Quasijarious from the digital dumpster as well. Get Outlook for Android On Wed, Jun 26, 2019 at 4:24 AM +0800, "Gregg Levine" <gregg.drwho8@gmail.com> wrote: Hello! And oddly enough the Finnish site ftp://nic.funet.fi maintains a collection of Mach related items at ftp://nic.funet.fi/pub/doc/OS/Mach/ and and at ftp://nic.funet.fi/pub/mach/ and a place named LYX contains Mach at ftp://ftp.lyx.org/pub/mach/ Ideally it is just a duplicate of the first one from earlier. And then Google gets lost. It also includes several hits to Jason's work, but after that Google gets lost. ----- Gregg C Levine gregg.drwho8@gmail.com "This signature fought the Time Wars, time and again." On Tue, Jun 25, 2019 at 2:18 PM Chris Hanson wrote: > > On Jun 24, 2019, at 8:07 PM, Gregg Levine wrote: > > > > Actually Chris, I found a complete collection of both CMU Mach and the > > Flux Group Mach, and even MkMach at the FTP2 site for the French > > OpenBSD location, ftp://ftp2.fr.openbsd.org under the pub and the mach > > directories. > > Thanks for this, but it’s just the stuff that was made publicly available by these groups. It’s useful, especially to have via FTP (easier to sync), but it doesn’t cover things like UX42 (the BSD atop Mach that CMU deployed to cluster workstations). > > -- Chris > > [-- Attachment #2: Type: text/html, Size: 3620 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [TUHS] CMU Mach sources? 2019-06-25 18:18 ` Chris Hanson 2019-06-25 20:23 ` Gregg Levine @ 2019-06-26 0:53 ` Jason Stevens 1 sibling, 0 replies; 55+ messages in thread From: Jason Stevens @ 2019-06-26 0:53 UTC (permalink / raw) To: Gregg Levine, Chris Hanson; +Cc: Tuhs [-- Attachment #1: Type: text/plain, Size: 2793 bytes --] The only UX42 like thing I've found is a binary image on the Mach 3.0 disk set of the mt xinu disks. In one of the Amiga directories of Mach stuff and the NS512 there is the BSDSS version 4 dump. I haven't tried to build it yet. Apparently CMU had up to version 8 of it, until the AT&T lawsuit where CMU apparently got cold feet and locked everything up. If google works right it seems that you'll just find me interested in the old stuff, the world has mostly passed this stuff on. I have been looking for RS/6000 Mach the better part of forever. Absolutely zero luck. It's funny about MachTEN, I asked them about buying the source, and/or redistribution but all they have is apparently a mountain of version 4 CD-ROMs. The only exciting thing is getting the mt xinu binaries and being able to compile the CSRG dump of 2.5. I found on bochs that it's doing something weird at the 3gb boundary which resulted in a triple fault and reboot. Everything is about doing elf debug, a.out is so out of vogue it's not even funny. I'd always assumed that Mach 2.5 on i386 actually works. Although the 3.0 stuff, at least on the Mt Xinu disks does. Time to walk through start and locore... Definitely way above my pay grade. Although it does look like there is some sequent machine with multiple 386 processors implying that it's SMP capable. Which probably doesn't work, otherwise why would NeXT have been lacking in SMP for so long? It'd have been awesome on the SUN hardware, and of course on i386. Instead it didn't come until what? OS X 10.3? Im always saddened on how the most prolific platform was ignored back in the day it seems. Sure the 80386 isnt sexy but they didn't have to cost as much as a luxury car. Have you tried emailing professors at mit, Utah or CMU? Maybe they might take you up on it. I had zero luck, but I don't have any 'in'. I'm just some dropout that barely made it through high school, not exactly university material. Get Outlook for Android On Wed, Jun 26, 2019 at 2:26 AM +0800, "Chris Hanson" <cmhanson@eschatologist.net> wrote: On Jun 24, 2019, at 8:07 PM, Gregg Levine wrote: > > Actually Chris, I found a complete collection of both CMU Mach and the > Flux Group Mach, and even MkMach at the FTP2 site for the French > OpenBSD location, ftp://ftp2.fr.openbsd.org under the pub and the mach > directories. Thanks for this, but it’s just the stuff that was made publicly available by these groups. It’s useful, especially to have via FTP (easier to sync), but it doesn’t cover things like UX42 (the BSD atop Mach that CMU deployed to cluster workstations). -- Chris [-- Attachment #2: Type: text/html, Size: 4884 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [TUHS] CMU Mach sources? 2019-06-23 4:38 [TUHS] CMU Mach sources? Chris Hanson ` (3 preceding siblings ...) 2019-06-25 3:07 ` Gregg Levine @ 2019-06-25 7:49 ` Jason Stevens 2019-06-25 7:59 ` Andreas Grapentin 4 siblings, 1 reply; 55+ messages in thread From: Jason Stevens @ 2019-06-25 7:49 UTC (permalink / raw) To: Chris Hanson, tuhs [-- Attachment #1: Type: text/plain, Size: 3535 bytes --] Well hot on the heels of the SUN-3 version of Mach25 I managed to figure out enough of the wedge issues for the 386 directory on the CSRG CD set and got it to compile! I put up a non HTTPS server on port 8080 for people with http only access to this stuff.. http://vpsland.superglobalmegacorp.com:8080/install/Mach/mach25-i386.tar.gz I apologize for the 404 & password craziness but the whole story is in the 404 page. It’s so annoying, but here we are in the world of anonymous virus scans and skittish data centres. I’m using the aforementioned MtXinu (http://vpsland.superglobalmegacorp.com:8080/install/Mach/MtXinu/) Mach386 to build this stuff. I haven’t looked at cross compiling from anything yet at the moment. Gzip -dc & tar -xvf this somewhere with space (/usr/src?) The Makefile bombs while running config on the source, I don’t immediately see where it fails, but it’s easy enough to just CD into the directory run config , cd out & re-run make… cd mach25-i386 bash# sh build.sh and it'll do the build dance.... cc -c -O -MD -DCMU -DINET -DMACH -DAT386 -DCMUCS -DKERNEL -fno-function-cse ../../i386at/pic_isa.c; ; ; cc -c -O -MD -DCMU -DINET -DMACH -DAT386 -DCMUCS -DKERNEL -fno-function-cse ../../i386at/rtc.c; ; ; cc -c -O -MD -DCMU -DINET -DMACH -DAT386 -DCMUCS -DKERNEL -fno-function-cse ../../i386at/wt.c; ; ; grep -v '^#' ../../machine/symbols.raw | sed 's/^ //' | sort -u > symbols.tmp mv -f symbols.tmp symbols.sort cc -c -O -MD -DCMU -DINET -DMACH -DAT386 -DCMUCS -DKERNEL -fno-function-cse ../../machine/swapgeneric.c (null command) (null command) (null command) vers.config: No such file or directory loading vmunix.sys rearranging symbols text data bss dec hex 442336 46776 115216 604328 938a8 ln vmunix.sys vmunix; ln vmunix vmunix.I386x. md -f -d `ls *.d` So yeah, turns out both trees are buildable! who knew?! It's certainly not easy to figure out or anything close to self explanatory. I had to copy some files from the 'other' SUN-3 complete Mach. -- cp /usr/src/mach25/sys/Makeconf . cp /usr/src/mach25/sys/Makefile . cp /usr/src/mach25/sys/conf/newvers.sh conf To get anywhere with this. So weird that they were missing. I'm working on the boot sector stuff, looks like the stuff I build is too big, and I’m trying to work with the pre-built stuff. mkfs /dev/rfloppy 2880 18 2 4096 512 32 1 dd if=boot.hd of=/dev/rfd0c fsck /dev/rfd0a mount /dev/floppy /mnt I'd like to think I'm getting close. close to something. ... lol I’m not sure if this is so off topic, or noise? Anyways I’ll keep updating unless told otherwise. From: Chris Hanson Sent: Sunday, June 23, 2019 12:46 PM To: tuhs@minnie.tuhs.org Subject: [TUHS] CMU Mach sources? Does anyone know whether CMU’s local Mach sources have been preserved? I’m not just talking about MK84.default.tar.Z and so on, I’m talking about all the bits of Mach that were used on cluster systems on campus, prior to the switch to vendor UNIX. I know at least one person who had complete MacMach sources for the last version, but threw out the backup discs with the sources in the process of moving. So I know they exist. If nothing else, CMU did provide other sites their UX source package (eg UX42), which was the BSD single server environment. So I know that has to be out there, somewhere. — Chris Sent from my iPhone [-- Attachment #2: Type: text/html, Size: 9882 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [TUHS] CMU Mach sources? 2019-06-25 7:49 ` Jason Stevens @ 2019-06-25 7:59 ` Andreas Grapentin 0 siblings, 0 replies; 55+ messages in thread From: Andreas Grapentin @ 2019-06-25 7:59 UTC (permalink / raw) To: tuhs, Jason Stevens [-- Attachment #1: Type: text/plain, Size: 4298 bytes --] Amazing, thanks for sharing! Best, Andreas On Tue, Jun 25, 2019 at 03:49:57PM +0800, Jason Stevens wrote: > Well hot on the heels of the SUN-3 version of Mach25 I managed to figure out enough of the wedge issues for the 386 directory on the CSRG CD set and got it to compile! > > I put up a non HTTPS server on port 8080 for people with http only access to this stuff.. > > http://vpsland.superglobalmegacorp.com:8080/install/Mach/mach25-i386.tar.gz > > I apologize for the 404 & password craziness but the whole story is in the 404 page. It’s so annoying, but here we are in the world of anonymous virus scans and skittish data centres. > > I’m using the aforementioned MtXinu (http://vpsland.superglobalmegacorp.com:8080/install/Mach/MtXinu/) Mach386 to build this stuff. I haven’t looked at cross compiling from anything yet at the moment. > > Gzip -dc & tar -xvf this somewhere with space (/usr/src?) > > The Makefile bombs while running config on the source, I don’t immediately see where it fails, but it’s easy enough to just CD into the directory run config , cd out & re-run make… > > cd mach25-i386 > bash# sh build.sh > > and it'll do the build dance.... > > cc -c -O -MD -DCMU -DINET -DMACH -DAT386 -DCMUCS -DKERNEL -fno-function-cse ../../i386at/pic_isa.c; ; ; > cc -c -O -MD -DCMU -DINET -DMACH -DAT386 -DCMUCS -DKERNEL -fno-function-cse ../../i386at/rtc.c; ; ; > cc -c -O -MD -DCMU -DINET -DMACH -DAT386 -DCMUCS -DKERNEL -fno-function-cse ../../i386at/wt.c; ; ; > grep -v '^#' ../../machine/symbols.raw | sed 's/^ //' | sort -u > symbols.tmp > mv -f symbols.tmp symbols.sort > cc -c -O -MD -DCMU -DINET -DMACH -DAT386 -DCMUCS -DKERNEL -fno-function-cse ../../machine/swapgeneric.c > (null command) > (null command) > (null command) > vers.config: No such file or directory > loading vmunix.sys > rearranging symbols > text data bss dec hex > 442336 46776 115216 604328 938a8 > ln vmunix.sys vmunix; ln vmunix vmunix.I386x. > md -f -d `ls *.d` > > > > So yeah, turns out both trees are buildable! who knew?! It's certainly not easy to figure out or anything close to self explanatory. > > I had to copy some files from the 'other' SUN-3 complete Mach. > > -- > cp /usr/src/mach25/sys/Makeconf . > cp /usr/src/mach25/sys/Makefile . > cp /usr/src/mach25/sys/conf/newvers.sh conf > > > To get anywhere with this. So weird that they were missing. > > I'm working on the boot sector stuff, looks like the stuff I build is too big, and I’m trying to work with the pre-built stuff. > > > mkfs /dev/rfloppy 2880 18 2 4096 512 32 1 > dd if=boot.hd of=/dev/rfd0c > fsck /dev/rfd0a > mount /dev/floppy /mnt > > I'd like to think I'm getting close. close to something. ... lol > > I’m not sure if this is so off topic, or noise? Anyways I’ll keep updating unless told otherwise. > > From: Chris Hanson > Sent: Sunday, June 23, 2019 12:46 PM > To: tuhs@minnie.tuhs.org > Subject: [TUHS] CMU Mach sources? > > Does anyone know whether CMU’s local Mach sources have been preserved? > > I’m not just talking about MK84.default.tar.Z and so on, I’m talking about all the bits of Mach that were used on cluster systems on campus, prior to the switch to vendor UNIX. > > I know at least one person who had complete MacMach sources for the last version, but threw out the backup discs with the sources in the process of moving. So I know they exist. > > If nothing else, CMU did provide other sites their UX source package (eg UX42), which was the BSD single server environment. So I know that has to be out there, somewhere. > > — Chris > > Sent from my iPhone > -- ------------------------------------------------------------------------------ Andreas Grapentin, M.Sc. Research Assistant @ Hasso-Plattner-Institut Operating Systems and Middleware Group www.dcl.hpi.uni-potsdam.de Phone: +49 (0) 331 55 09-238 Fax: +49 (0) 331 55 09-229 my GPG Public Key: https://files.grapentin.org/.gpg/public.key ------------------------------------------------------------------------------ [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [TUHS] CMU Mach sources? @ 2019-06-23 22:08 Noel Chiappa 2019-06-23 23:54 ` Theodore Ts'o 0 siblings, 1 reply; 55+ messages in thread From: Noel Chiappa @ 2019-06-23 22:08 UTC (permalink / raw) To: tuhs; +Cc: jnc > From: Andrew Warkentin > Mach and the other kernels influenced by it basically destroyed the > reputation of microkernels ... a simple read() of a disk file, which is > a single kernel call on a monolithic kernel and usually two context > switches on QNX, takes at least 8 context switches - client->VFS->disk > FS->partition driver->disk driver and back again). Hammer-nail syndrome. When the only tool you have for creating separate subsystems is processes, you wind up with a lot of processes. Who'd a thunk it. A system with a segmented memory which allows subroutine calls from one subsystem to another will have a lot less overhead. It does take hardware support to be really efficient, though. The x86 processors had that support, until Intel dropped it from the latest ones because nobody used it. Excuse me while I go bang my head on a very hard wall until the pain stops. Noel ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [TUHS] CMU Mach sources? 2019-06-23 22:08 Noel Chiappa @ 2019-06-23 23:54 ` Theodore Ts'o 2019-06-24 17:04 ` Jason Stevens 0 siblings, 1 reply; 55+ messages in thread From: Theodore Ts'o @ 2019-06-23 23:54 UTC (permalink / raw) To: Noel Chiappa; +Cc: tuhs On Sun, Jun 23, 2019 at 06:08:56PM -0400, Noel Chiappa wrote: > > Hammer-nail syndrome. > > When the only tool you have for creating separate subsystems is processes, you > wind up with a lot of processes. Who'd a thunk it. > > A system with a segmented memory which allows subroutine calls from one subsystem > to another will have a lot less overhead. It does take hardware support to be > really efficient, though. The x86 processors had that support, until Intel dropped > it from the latest ones because nobody used it. One of the real problems with how x86 implemented segments was that the segments were layered on top of the 32-bit virtual address space implemented by the page tables. So if you wanted to use a pure segmented architecture, ala Multics, you run into the same problem as 32-bit IP addresses. If you need to allow for segments to grow, you very quickly fragment the 32-bit address space. If I recall correctly, this wasn't an issue with Multics because the DPS-8 had page tables for each segment. Maybe if Intel/AMD had kept segmentation support when x86_64 was developed, trying to do something more novel with segments could have worked when we went to 64-bits (or maybe, like IPv6, what's really needed is 128-bits of address space :-P). But, Itanic was supposed to be the dominant 64-bit architecture that was going to take over the whole world, and when that turned out not to be the case, AMD threw together x86_64 as the "just good enough" architectural extension. - Ted ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [TUHS] CMU Mach sources? 2019-06-23 23:54 ` Theodore Ts'o @ 2019-06-24 17:04 ` Jason Stevens 0 siblings, 0 replies; 55+ messages in thread From: Jason Stevens @ 2019-06-24 17:04 UTC (permalink / raw) To: tuhs [-- Attachment #1: Type: text/plain, Size: 2645 bytes --] So with that Mt Xinu Mach/386 thing I thought I’d take another stab at building the source from the CSRG CD-ROM set. The makefiles from the i386 version are so cut up it’s a seemingly hopeless mess. I took the mach.kernel.mk directory and tried to build of 4.3BSD UWisc, but that went nowhere quick as the tool chain just isn’t right and there is a bunch of VAX stuff missing. It looks more complete for the SUN-3. So in a fit of rage, I copied the bare needed i386 files into the SUN-3 tree and it actually compiles. ROUGH notes…. Mach25 is where I put the 386 directory & running from inside the mach.kernel.mk directory. mv ../mach25/sys/i386 . mv ../mach25/sys/i386at . mv ../mach25/sys/mach/i386 mach mv ../mach25/sys/sysV . cp ../mach25/sys/conf/*i386* conf ln -s i386 machine ln -s mach/i386 mach/machine cp Makeconf Makeconf-orig vi Makeconf ------ bash$ diff Makeconf-orig Makeconf 85c85,86 < CONFIG = ${${TARGET_MACHINE}_CONFIG?${${TARGET_MACHINE}_CONFIG}:STD+ANY+EXP} --- > #CONFIG = ${${TARGET_MACHINE}_CONFIG?${${TARGET_MACHINE}_CONFIG}:STD+ANY+EXP} > CONFIG = STD+WS-afs-nfs 89a91 > #SOURCEDIR = /usr/src/mach.kernel.mk 91c93,95 < OBJECTDIR = ../../../obj/@sys/kernel/${KERNEL_SERIES} --- > #OBJECTDIR = ../../../obj/@sys/kernel/${KERNEL_SERIES} > #OBJECTDIR = /usr/src/mach.kernel.mk/obj > OBJECTDIR = ./obj ------ vi Makefile include ../../${MAKETOP}Makefile-common to include ${MAKETOP}Makefile-common vi src/config/Makefile include ../../${MAKETOP}Makefile-common to include ${MAKETOP}Makefile-common mkdir obj make And it actually compiled… cc -c -O -MD -I. -I../../sys -DCMU -DINET -DMACH -DAT386 -DCMUCS -DKERNEL -fno-function-cse ../../i386at/pic_isa.c; ; ; cc -c -O -MD -I. -I../../sys -DCMU -DINET -DMACH -DAT386 -DCMUCS -DKERNEL -fno-function-cse ../../i386at/rtc.c; ; ; cc -c -O -MD -I. -I../../sys -DCMU -DINET -DMACH -DAT386 -DCMUCS -DKERNEL -fno-function-cse ../../i386at/wt.c; ; ; cc -c -O -MD -I. -I../../sys -DCMU -DINET -DMACH -DAT386 -DCMUCS -DKERNEL -fno-function-cse ../../machine/swapgeneric.c (null command) (null command) (null command) loading vmunix.sys rearranging symbols text data bss dec hex 479200 47980 125520 652700 9f59c ln vmunix.sys vmunix md -f -d `ls *.d` ln -s STD+WS-afs-nfs/vmunix KERNEL.STD+WS-afs-nfs Naturally the Mt Xinu bootloader won’t run it. 479200+47980+125520[+40968+42516] That’s all I get out of it. I’ll have to mess with it later on as it’s getting late, but I thought it was worth sharing. [-- Attachment #2: Type: text/html, Size: 5922 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* [TUHS] CMU Mach sources? @ 2019-07-01 13:20 Jason Stevens 0 siblings, 0 replies; 55+ messages in thread From: Jason Stevens @ 2019-07-01 13:20 UTC (permalink / raw) To: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 566 bytes --] I finally got a chance to talk to someone who knows a hell of a lot about the i386 than I could ever hope to know. I gave him all the materials and I think he spent more time replying to my email than doing the debugging. Basically the registers for entering protected mode with paging are backwards. This is kind of funny as the port was done by Intel of all people. Anyway I reversed them and I now have the Mach kernel from 1988 booted under VMware. I have to say that it's super cool to finally have chased this one down. [-- Attachment #2: Type: text/html, Size: 1116 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
end of thread, other threads:[~2019-07-01 13:20 UTC | newest] Thread overview: 55+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-06-23 4:38 [TUHS] CMU Mach sources? Chris Hanson 2019-06-23 5:15 ` Larry McVoy 2019-06-23 8:52 ` Andrew Warkentin 2019-06-23 13:39 ` Jon Forrest 2019-06-23 13:59 ` arnold 2019-06-23 14:03 ` Jason Stevens 2019-06-23 8:04 ` Jason Stevens 2019-06-23 14:54 ` Henry Bent 2019-06-23 21:52 ` Clem Cole 2019-06-25 0:06 ` Larry McVoy 2019-06-25 0:31 ` Theodore Ts'o 2019-06-25 0:45 ` Larry McVoy 2019-06-25 0:55 ` Kurt H Maier 2019-06-25 4:18 ` Larry McVoy 2019-06-26 23:19 ` [TUHS] Craft vs Research (Re: " Bakul Shah 2019-06-27 0:16 ` tuhs 2019-06-27 17:06 ` Clem Cole 2019-06-25 1:00 ` [TUHS] " Richard Salz 2019-06-25 8:00 ` Kevin Bowling 2019-06-25 12:11 ` Arthur Krewat 2019-06-25 12:17 ` Arthur Krewat 2019-06-26 2:45 ` Kurt H Maier 2019-06-26 2:56 ` Larry McVoy 2019-06-26 15:11 ` Theodore Ts'o 2019-06-26 17:44 ` Larry McVoy 2019-06-26 18:01 ` arnold 2019-06-26 18:18 ` Warner Losh 2019-06-26 19:22 ` Chris Hanson 2019-06-26 19:32 ` Ben Greenfield via TUHS 2019-06-26 20:21 ` Larry McVoy 2019-06-27 0:22 ` Chris Hanson 2019-06-27 1:02 ` Larry McVoy 2019-06-27 1:26 ` Chris Hanson 2019-06-27 4:01 ` Lyndon Nerenberg 2019-06-27 10:34 ` Ben Greenfield via TUHS 2019-06-27 10:59 ` arnold 2019-06-27 11:13 ` Ben Greenfield via TUHS 2019-06-27 11:39 ` arnold 2019-06-27 14:58 ` Warner Losh 2019-06-27 17:25 ` Larry McVoy 2019-06-26 19:30 ` Dennis Boone 2019-06-26 19:25 ` Adam Thornton 2019-06-23 8:27 ` Kevin Bowling 2019-06-25 3:07 ` Gregg Levine 2019-06-25 8:15 ` Kevin Bowling 2019-06-25 18:18 ` Chris Hanson 2019-06-25 20:23 ` Gregg Levine 2019-06-26 1:04 ` Jason Stevens 2019-06-26 0:53 ` Jason Stevens 2019-06-25 7:49 ` Jason Stevens 2019-06-25 7:59 ` Andreas Grapentin 2019-06-23 22:08 Noel Chiappa 2019-06-23 23:54 ` Theodore Ts'o 2019-06-24 17:04 ` Jason Stevens 2019-07-01 13:20 Jason Stevens
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).