Live data from Hacker News

So what is the deal with A/UX anyways?

virtuallyfun.com

131–140 of 166 posts

Re: So what is the deal with A/UX anyways?

#131
post #106

Earlier quoted context omitted.

* "Milwaukee" wasn't Big Mac, even though (if Levy is correct) it was also sometimes referred to as "Little Big Mac". As Aventure-Apple states (and Levy confirms), it was a rival (or at least completely indepdendent) effort. Insanely Great says that it was a grassroots initiative by engineer Mike Dhuey focussed on creating a version-2 Macintosh with internal expansion slots. (And it wasn't even the only other project…

Milwaukee is mentioned in the A/UX 0.7 build, so I was wondering if it was more 'BigMac' or something else entirely. It's a shame more of this is buried in legend.

My guess would be that "Milwaukee virtual Unix" https://github.com/BobMorlock/AUX/blob/ac3d03a2a0c0924866ce2... refers to the fact that A/UX was designed to run on Macintosh II (ie. Milwaukee) hardware.

I remember (I think) John Siracusa expressing frustration that Isaacson delivered a personality-focussed and patchily-researched bio instead of taking the unique opportunity to grill Jobs with a long list of detailed and specific questions about the remaining mysteries of his stints at Apple. But of course that's probably part of the reason why Jobs chose Isaacson and not Siracusa or someone like him. And conversely, not all of this stuff actually required access to Jobs: there is, for instance, a lot of mystery about the Big Mac that Levy could probably have cleared up. However Levy was really quite specific (and hopefully correct!) about the 'Milwaukee' name: he said that Gassée coined the name after seeing a photo of Milwaukee on the wall of Dhuey's cubicle.

Re: So what is the deal with A/UX anyways?

#132
post #28
post #7

Earlier quoted context omitted.

Interesting that the article calls out the price point as one of the reasons it didn't succeed. Although a lot of that was the OS only having drivers for expensive hardware and being unusable on the lower end Macs. That said, high price killed off most of the legacy Unix vendors/products. The world was changing around them and they weren't ready or able to give up the profit margins they had enjoyed for so long. Pers…

It was expensive. In 1987 I built a 386-25 with 16MB RAM and SCSI HD that ran Interactive Systems UNIX for a lot less than it would have cost to get a Mac II with A/UX.

Interactive still did beat SCO/Xenix on price in 1992 for running Oracle (on 386 hardware that costed as little as a single 857 MB hard disk on RS/6000 with AIX). And Novell 2 or 3 sure did beat A/UX as AppleTalk file server.

Re: So what is the deal with A/UX anyways?

#133
post #76

Earlier quoted context omitted.

which to me was surprising about A/UX, you got both C89 and F77!

I think GCC was available back then. Not sure about F77. What C compiler did BSD use?

Out of the box running strings on stuff shows the 1984-1985 AT&T-IS 1985-1987 UniSoft Corporation strings.

So it's got to be PCC.

The F77 credits Apple, Adobe, AT&T-IS, Motorola, SUN, CSRG, and Unisoft.

In the A/UX 0.7 build there is a 'greenhills' marker in crt0.o and libc so it looks like they used greenhills before switching (self hosting?) to pcc?

Re: So what is the deal with A/UX anyways?

#134
post #124
post #56

Earlier quoted context omitted.

OpenStep was still based on Mach 2 and (encumbered) 4.3BSD. OS X Server 1.0 was very OpenStep like yes, it used the old Display Postscript server and was more compatible with next/openstep (I think the display servers were similar enough you could forward OpenSTEP software to a OS X Server 1.0 windowserver), but I believe it was based on the un-encumbered XNU, and couldn't directly run OpenSTEP programs due to this i…

Rhapsody was still pre-Mk but had 4.4BSD userland. It could run OPENSTEP binaries if you copied the shared libraries over, from memory one of the ex-NeXT engineers did this for fun.

Cool :) this is all before my time but I've got a few Sun boxes running various old BSDs and Nextstep 3.3.

I've always been kind of curious how hard it'd be to get NetBSD's COMPAT_DARWIN and COMPAT_MACH to run the next/openstep userland...

Re: So what is the deal with A/UX anyways?

#135
post #34

I don't know the technical details of why it wasn't viable, and wouldn't understand them if I did, but every time I see something about A/UX, I say "Apple, you spent a decade trying to come up with a modern successor to System 6/7, and nearly died doing so, and all along you had this in the labs—and shipping?!"

I think it was the price more than anything. Both of the software license (not cheap!) and also the hardware requirements. It's something that doesn't come up much anymore but RAM used to be one of the main limits of a personal computer. A/UX required a high-end Mac at the time. And Macs were already high-end PCs. And UNIX wanted a lot of RAM. 16 MB was barely comfortable in the early 90s. This was a time when when t…

I ran A/UX comfortably in 8MB, on an SE/30.

8MB was a lot of RAM. Most people were running windos in 2MB or less, at the time.

Re: So what is the deal with A/UX anyways?

#137

What is A/UX? I’m not seeing a definition.

Apple bough a port of UniSoft SYSVr2 to the Apple platoform and dubbed it A/UX. Version 2 onward were technically significant as ToolBox and Finder had been ported to Unix and allowed MacOS apps to run on top of Unix. They didn't offer process virtualization so they could all crash eachother out.

Still, since you didn't need to run MacOS apps much, it wasn't really a problem. MacOS couldn't crash the Unix or X subsystems, or anything (else) on them, and nothing else could crash MacOS.

Re: So what is the deal with A/UX anyways?

#138
post #115

Earlier quoted context omitted.

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: cas…

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-m…

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.

Re: So what is the deal with A/UX anyways?

#139
post #80
post #47

Earlier quoted context omitted.

> 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…

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.

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.

Re: So what is the deal with A/UX anyways?

#140
post #86

Earlier quoted context omitted.

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.

evidence welcome - I do not recall that as the case

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.

Post reply on HN