23 Jun
2019
23 Jun
'19
10:38 a.m.
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
23 Jun
23 Jun
11:15 a.m.
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
2:52 p.m.
On 6/22/19, Larry McVoy <lm(a)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
7:39 p.m.
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
7:59 p.m.
Jon Forrest <nobozo(a)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
8:03 p.m.
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(a)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
2:04 p.m.
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&on…
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(a)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
8:54 p.m.
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(a)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&on…
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(a)eschatologist.net>
*Sent: *Sunday, June 23, 2019 12:46 PM
*To: *tuhs(a)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
24 Jun
24 Jun
3:52 a.m.
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.
25 Jun
25 Jun
6:06 a.m.
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
6:31 a.m.
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
6:45 a.m.
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:
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.
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.
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.
6:55 a.m.
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
10:18 a.m.
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:
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.
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. 
27 Jun
27 Jun
5:19 a.m.
New subject: Craft vs Research (Re: CMU Mach sources?
On Mon, 24 Jun 2019 21:18:06 -0700 Larry McVoy <lm(a)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.
6:16 a.m.
New subject: Craft vs Research (Re: CMU Mach sources?
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
11:06 p.m.
New subject: Craft vs Research (Re: CMU Mach sources?
On Wed, Jun 26, 2019 at 9:12 PM <tuhs(a)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
25 Jun
25 Jun
7 a.m.
Is this really the kind of commentary appropriate for this list? I mean I'm
new here, but...
2 p.m.
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(a)gmail.com> wrote:
Is this really the kind of commentary appropriate for this list? I mean I'm new
here, but...
6:11 p.m.
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(a)gmail.com> wrote:
> Is this really the kind of commentary appropriate for this list? I mean I'm new
here, but...
26 Jun
26 Jun
8:45 a.m.
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
8:56 a.m.
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:
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.
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...
9:11 p.m.
On Tue, Jun 25, 2019 at 07:56:46PM -0700, Larry McVoy wrote:
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
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.
11:44 p.m.
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.
27 Jun
27 Jun
12:01 a.m.
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
12:18 a.m.
On Wed, Jun 26, 2019 at 12:01 PM <arnold(a)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
1:22 a.m.
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
1:30 a.m.
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
1:32 a.m.
On Jun 26, 2019, at 3:22 PM, Chris Hanson
<cmhanson(a)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
2:21 a.m.
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.
6:22 a.m.
On Jun 26, 2019, at 1:21 PM, Larry McVoy <lm(a)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
7:02 a.m.
On Wed, Jun 26, 2019 at 05:22:05PM -0700, Chris Hanson wrote:
On Jun 26, 2019, at 1:21 PM, Larry McVoy
<lm(a)mcvoy.com> wrote:
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.
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.
7:26 a.m.
On Jun 26, 2019, at 6:02 PM, Larry McVoy <lm(a)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
10:01 a.m.
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
4:34 p.m.
On Jun 27, 2019, at 12:01 AM, Lyndon Nerenberg
<lyndon(a)orthanc.ca> wrote:
Larry McVoy writes:
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.
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
4:59 p.m.
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(a)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(a)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
5:13 p.m.
On Jun 27, 2019, at 6:59 AM, arnold(a)skeeve.com wrote:
Larry McVoy writes:
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
>> 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(a)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(a)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
8:58 p.m.
On Thu, Jun 27, 2019 at 5:13 AM Ben Greenfield via TUHS <
tuhs(a)minnie.tuhs.org> wrote:
wrote:
interface.
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
On Jun 27, 2019, at 6:59 AM, arnold(a)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(a)orthanc.ca> >
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(a)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
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.
11:25 p.m.
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.
1:25 a.m.
"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(a)mit.edu> wrote:
On Tue, Jun 25, 2019 at 07:56:46PM -0700, Larry McVoy
wrote:
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
> 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.
23 Jun
23 Jun
2:27 p.m.
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_instal…
Regards,
Kevin
On Sat, Jun 22, 2019 at 9:45 PM Chris Hanson <cmhanson(a)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
25 Jun
25 Jun
9:07 a.m.
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(a)gmail.com
"This signature fought the Time Wars, time and again."
On Sun, Jun 23, 2019 at 12:45 AM Chris Hanson
<cmhanson(a)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
2:15 p.m.
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(a)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(a)gmail.com
"This signature fought the Time Wars, time and again."
On Sun, Jun 23, 2019 at 12:45 AM Chris Hanson
<cmhanson(a)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
26 Jun
26 Jun
12:18 a.m.
On Jun 24, 2019, at 8:07 PM, Gregg Levine <gregg.drwho8(a)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
2:23 a.m.
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(a)gmail.com
"This signature fought the Time Wars, time and again."
On Tue, Jun 25, 2019 at 2:18 PM Chris Hanson <cmhanson(a)eschatologist.net> wrote:
On Jun 24, 2019, at 8:07 PM, Gregg Levine <gregg.drwho8(a)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
7:04 a.m.
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(a)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(a)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
6:53 a.m.
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(a)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
25 Jun
25 Jun
1:49 p.m.
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(a)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
1:59 p.m.
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(a)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
------------------------------------------------------------------------------
2004
days inactive
2008
days old
50 comments
22 participants
participants (22)
-
Adam Thornton -
Andreas Grapentin -
Andrew Warkentin -
arnold＠skeeve.com -
Arthur Krewat -
Bakul Shah -
Ben Greenfield -
Chris Hanson -
Clem Cole -
Dennis Boone -
Gregg Levine -
Henry Bent -
Jason Stevens -
Jon Forrest -
Kevin Bowling -
Kurt H Maier -
Larry McVoy -
Lyndon Nerenberg -
Richard Salz -
Theodore Ts'o -
tuhs＠eric.allman.name -
Warner Losh