[gumby]

The irony for me is that Unix was the (unhappy) inspiration for the famous “worse is better” memo. The Unix workstation vendors made high end hardware with (semi-) commodity software, and had their lunch eaten by generic hardware coupled with software that gave more people a better experience.

(Though personally not at all a fan of most of the Unix paradigm, for me it’s a vastly superior experience to Windows. But I can’t deny that that is not the case for most people)

[mistrial9]

I was there at that time, there are manuals in white binders down the hall from me now. The Mac was made to never, ever, use the command line. That is what I chose to develop for at that time, including exposure to "high end" machines at University.

fun fact - there were no undergraduate courses in computer science at that time; master's level and up .. you have to be trained to use those workstations, even for five minutes, AND the oversight of an admin with security.

Mac? get one, fire it up, make Mac Paint pictures. The network IS NOT the computer, thankyouverymuch

[Taniwha]

I actually wrote a large chunk of the A/UX unix port (late 80s) - a decade before (mid 70s) I'd obtained an undergraduate degree in Comp Sci (in New Zealand) - undergraduate Comp Sci was very much a thing at the time

[scruffyherder]

Have you ever played with this:

https://macintoshgarden.org/apps/aux-apple-unix-68k-version-...

I found it interesting that it mentions both ‘Milwaukee‘, and Cayman "brac" ... Here on the Jasmine 80.

Seems like lots of weird codenames.

It looks like UniSoft had done a lot of work on the code (you?) to make it super portable. Although everything not directly related to the Milwaukee was cut. It'd be interesting to see if the kernel could be built without MMU support.. I tried to remove PAGING but that didn't work. Oh yeah the kernel source is on that image and other than one damaged file, it not only builds, but works on a special Shoebill.

cd /sys/psn

rm *.o

cd io

mv screen-data.c screen_data.c

cd ..

make unix

Pretty neat, none the less!

[Taniwha]

(here's probably too much information)

yup I wrote a lot of that, I did all the console stuff (font renderer, vt100, mouse, keyboard, fdb/adb, ui event queue etc).

Missing is all the auto config support (ability to add 3rd party drivers to the kernel in the field, something that at the time you usually couldn't do without source), fixes for large screen support, all my appletalk code is missing too. However I can see the latish floppy bug fix (there was a hardware bug found in the FDB/ADB chip where if we accessed the floppy on only some systems the keyboard froze, turned out we were spinning reading the timer while reading the disk, doing it so fast the clock to the FDB chip sped up) and the older pre-fix code in "sony.c.~8A" - that sort of places the release in time.

Given all that I'd guess that this is one of the early releases we gave to Apple that has somehow escaped - we used to fly to Oregon and copy disks to do releases to avoid California's sales taxes - UniSoft actually had an online modem based system where customers could log in and download the latest software - at the time CA tax law didn't explicitly cover electronic delivery of software, we were sued by the state and they lost setting a precedent

It's been a long time but "psn" probably stands for "Pigs in Space" - our internal code name for the project (Apple's code name "Eagle" leaked, but ours never did).

The "Cayman/brac" looks like what someone named their box, "Jasmine" was a type of hard drive, I've no idea about Milwaukee - I think Cayman used to be a company that made mac ethernet hardware, my guess would be that someone at Apple slipped them this pre-release, and then an update with some bug fixes, along with source (very naughty! AT&T would likely have sued us, ie UniSoft if they found out)

The assembly font renderer uses the 68020 only bfins bit field insert instructions, it can under certain circumstances generate a 24-bit bus write, nubus doesn't support such a thing, we got half of the first big run of mac 2 boards, they came with a schematic and PAL equations, I got to send fixed PAL equations back to Ron at Apple to make it work.

As far as "making it portable" a large part of that is just system 5 (SVR2 in this case) not so much us, though porting this code was our bread and butter - we supported a number of MMUs - 2 paging MMUs for 68020s, and a whole lot of swapping MMUs for 68010/68000s (plus 29k 88k etc) - it was never really designed to work without some form of MMU

[scruffyherder]

Cayman must be Cayman Systems (Cambridge, MA).

I'd seen this zip file floating around for well over a decade, maybe quite a bit longer. It was amazing to see someone write enough glue for an emulator to actually boot it. It's even more crazy to get 3.0.1 to mount it under Qemu and do a full build in 17 seconds... I can't even imagine how long it took to build this back in the day!

Apparently above Milwaukee has something to do with Gasse and the BigMac Jr.

I wonder what ever happened to Unisoft's unix business. I've always wanted a SYSV but they seem impossible to buy. Best I have is a non commercial SYSIII from SCO before they 'gave 32v' and lower away but it's all so murkey if they could give anything away but I think they could sublicense for a fee (best $100 ever!)

[Taniwha]

After I left the Unix biz changed, we'd made money doing lots of ports for small companies, as Sun/SGI/etc got successful there were fewer of them, then we did the 88k and 29k ports but those guys didn't really take off. Doing A/UX also kind of screwed the company, I think it made us ignore our smaller customers, we expanded a bit too much, moved into a nicer building. We also didn't do an x86 port, which was a mistake - we actually helped SCO with the MMU portion of the SysV 286 port, there was some deal where we were supposed to get a copy but somehow that didn't happen (no love lost there).

UniSoft still exists, these days they sell digital video stuff (which was very weird when I became a cable/sat protocol engineer for a while a decade or so ago).

Reading what other people have been saying "Milwaukee" might have been a Mac2 code name.

[mistrial9]

not at Berkeley ! but proper respect to you Taniwha, many paths

[Taniwha]

Well I did the A/UX port IN Berkeley (the city, not the university).

The thing is that as a discipline Comp Sci is a late comer, university Comp Sci departments came from lots of places, some grew out of Engineering depts, others from Maths, Physics, Chemistry, Commerce, others from the computing infrastructure groups withing universities - they ended up being called all sorts of things - early on places offered Comp Sci by a whole lot of names

[cjsplat]

Yes, Berkeley had undergrad CS degrees in the 80's (and late 70's). One in the College of Engineering and one in the College of Letters and Science. Also, an undergrad EECS in Engineering.

The Bay Area school that didn't have an undergrad CS program was Stanfurd.

[gumby]

Back then MIT had one but Harvard did not. I felt sorry for my friends who opted to go there.

H recently started an engineering school. Years ago they tried to buy MIT but were rebuffed.

[mistrial9]

evidence welcome - I do not recall that as the case

[cjsplat]

Surprisingly tricky to prove. It looks like Berkeley overhauled its student body statistics about 15 years ago, and data from before seems to have vanished.

Is it argument from authority if I cite Karp?

https://www2.eecs.berkeley.edu/bears/CS_Anniversary/karp-tal...

The two undergraduate degree programs at Berkeley seem to date from 1968 or so. (Karp is fuzzy about his citations).

It was certainly well established when I went there in the early 80's.

[reaperducer]

fun fact - there were no undergraduate courses in computer science at that time

Perhaps this was regional. I was enrolled in undergraduate Computer Science courses at this time, and it was at a pretty low-end state university.

[msh]

I assume it can't have been that common not to have undergrad courses in cs?

I know my (non US) University have had undergrad courses since 1970.

[rbanffy]

> Unix was the (unhappy) inspiration for the famous “worse is better” memo.

It could be rephrased as “done is better than perfect”. I would love to have a high-end workstation based on exotic hardware with ridiculously fast storage, but an average home PC is probably enough for my development work and, when it’s not, I can acknowledge it is so because the software is much more bloated than it should be.

[aoki]

“Worse” was Bell Labs: portable C/Unix. As opposed to MIT: codesigned Lisp/LispMs. The Unix workstation was the triumph of COTS micros over LSI or custom VLSI hardware.

[gumby]

> The Unix workstation was the triumph of COTS micros over LSI or custom VLSI hardware.

Well the Sun-1 definitely started there, no question (I don’t remember the Daisy or Apollo hardware). HP definitely never did and Sun (and SGI et al) all went down the custom hardware rabbit hole.

By the time they tried to hop onto the PC hardware train it was too late. None of those companies survive in any meaningful way.

BTW if you catch this in time to edit: you might want to put a hyphen between “co” and “design” because you didn’t mean signing code.

[temac]

The customness of the hardware is partly relative. One had to guess the trajectory of the PC to bet on clones and their components. Of course at one point there was no question the non-x86 workstation used "custom" hardware vs. the kind of more open ecosystem of x86 PC components, however even in this situation doing custom is not even an absolute criteria for success or failure or even eventual economy of scale: case in point Apple. Now of course there is in-house design vs. OTS but while it was true that the first PCs used pre-existing chips, quickly some chips started to be developed specifically for PCs or at least with PC as the main target, by far. So it is also kind of "custom", just developed by multiple companies.

Now in retrospect some workstation vendors could maybe have survived a little more by switching to x86 PC like hardware except the window for doing the switch was astonishingly small and they would have transformed to either a random OS vendor, or a random PC hardware vendor, or even both (even if requiring their own hardware, their competition would have quickly been way more directly e.g. Linux or BSD on generic PCs, and eventually with e.g. CAD vendors switching to Windows it would not have helped either)

Or as a random hardware PC vendor, what is even the point compared to their initial positioning and what was a "workstation". This market is now taken mostly by chip vendors with more or less artificial market segmentation -- and then computer vendors using such chips but they do not define the platforms anymore and add far less value. It's kind or logical; well at least in retrospect, here too. A very few number of platforms had to remain because of both the network effect and the practicality of using and developing for them. And consumer hardware was bound to eventually get state of the art designs (mostly scaled with parallelism for pro hw + a few artificial market seg)

You can take the internal dev route (again: Apple) but you had to target the general public first to do that (so not appropriate for a WS vendor)

Ironically, we could argue that to survive "in a meaningful way", if I read that in yielding a legacy today that could influence the ws workload by providing them at least a part of the platform, the old-school Workstation vendors would have needed to pivot to more pure component makers (for PCs).

[twoodfin]

Now in retrospect some workstation vendors could maybe have survived a little more by switching to x86 PC like hardware except the window for doing the switch was astonishingly small and they would have transformed to either a random OS vendor, or a random PC hardware vendor, or even both

I think this window was non-existent: Moore’s Law at the time was turning white boxes into workstations faster than any time-and-money consuming custom engineering could pay back the investment.

[smackeyacky]

I'm not sure about that, even today. The typical white box PC motherboard then (and now) doesn't support 128gb of memory for example, you have to buy a HP Z400 or a Mac Pro (or an old server). Plus they aren't really designed to be maintained, or have space for dual processors. The Sun/HP/DEC/IBM workstations were not purely bought because they were fast, there was often specific software in mind that the end user wanted.

I have two primary machines I do development on, an Acer gaming laptop (a few years old, intel i7 8750h, 32gb of memory) and a truly ancient HP Proliant server with dual Xeons (x5650 and 96Gb of memory). The Proliant is still consistently faster at compiling an Android app than the laptop, despite the laptop having SSDs and the Proliant being 7 years older. There is a lot more to making a workstation than just raw CPU speed which is as true now as it was in the early 1990s when a Sparcstation was the go-to performance machine to have on your desk.

[rbanffy]

Same here. The 5yo Lenovo trounces the 2yo top of the line x86 MacBook Pro on pretty much everything. When it was young it easily humiliated every computer in the house.

[rbanffy]

My impression is that they all built desktop minicomputers possible thanks to CPUs like the 68K but moved on to RISC designs when the 68K started showing its age. I would not say the PA-RISC was open, but SPARC had multiple sources and MIPS showed up everywhere. At that period, the x86 was not an option - Sun tried.

[ncmncm]

Apollo was building bit-slice 68000 emulations (to have an MMU) into the mid '80s, and ran Aegis, their homegrown fully-networked GUI OS, coded in their home-grown Pascal, with their home-grown touchpad pointer and home-grown token-ring network, on those and on actual 68K into the late '80s.

Aegis was inspired by MULTICS, not Unix, and was definitely a better system. They were demand-paging across the network in the early '80s.

One feature I recall stood out: they expanded environment variables in symbolic link text, like /usr/bin -> /usr/$SYSTEM/bin to get a SYSV or BSD Unix flavor, later on. The only Unix that does something similar I know of is Dragonfly.

[rbanffy]

> Aegis was inspired by MULTICS, not Unix, and was definitely a better system. They were demand-paging across the network in the early '80s.

I’d love to see one of those operating. We have lost so many great ideas we seem to never revisit…

[ncmncm]

Another was a read() system call that would copy into a caller-supplied buffer if it had to, but would normally just return a pointer into its buffer cache.

[ncmncm]

I know somebody who has some. You sort of need more than one so the token has somewhere to go.

[scruffyherder]

the SUN-1 was based on the SUN (Stanford University Network) board, but I can't find anything concrete on the SUN board (Also by Andy) other than it existing, and apparently 'cheap/free' to license?

Apparently it formed the foundations of cisco/SGi & SUN.

[gumby]

Indeed, I remember those days well.