Live data from Hacker News

So what is the deal with A/UX anyways?

virtuallyfun.com

51–60 of 166 posts

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

#51
post #39
post #34

Earlier quoted context omitted.

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…

Tangential to AU/X and licensing costs, I think this is why OS X was something like a "from scratch" recreation of NeXTSTEP instead of being a straight port. They replaced the AT&T licensed UNIX core with a new open source one derived from the 386BSD forks (and DEC's OSF/1 mach fork), and replaced the display postscript WindowServer with Quartz, both for licensing cost and performance reasons. At least, that's my imp…

You forgot there was still OpenSTEP and the collaboration with Sun, which ended up having an influence on a language being designed at the time called Oak.

Early versions of OS X were still based on OpenSTEP, thus able to run on top of Windows as well.

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

#52

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?!"

My understanding is the "Mac" side of A/UX still had no memory protection. It still had all the stability problems plaguing System 7, unlike modern macOS / OS/X

This is true and was not easily fixable with existing applications. They added a kernel supporting memory protection in the move to PowerPC but it wasn't until Carbon that apps really benefited from that. Carbon was a transitional API between classic MacOS and OS X that made it feasible to port apps to run on both, but conceivably they could have done something similar without the switch to Darwin.

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

#53
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.

16MB in 1987, good lord. I didn't even know that was possible on x86 at the time.

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

#54
post #19

Earlier quoted context omitted.

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…

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…

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.

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

#55
post #39
post #34

Earlier quoted context omitted.

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…

Tangential to AU/X and licensing costs, I think this is why OS X was something like a "from scratch" recreation of NeXTSTEP instead of being a straight port. They replaced the AT&T licensed UNIX core with a new open source one derived from the 386BSD forks (and DEC's OSF/1 mach fork), and replaced the display postscript WindowServer with Quartz, both for licensing cost and performance reasons. At least, that's my imp…

I had thought NeXTStep was always BSD based?

Still might have paid the unix license; this was pre AT&T vs USL, but, thought nextstep was basically CMU mach (which itself was BSD+Mach) + the NextStep frameworks/ui

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

#56
post #51
post #39

Earlier quoted context omitted.

Tangential to AU/X and licensing costs, I think this is why OS X was something like a "from scratch" recreation of NeXTSTEP instead of being a straight port. They replaced the AT&T licensed UNIX core with a new open source one derived from the 386BSD forks (and DEC's OSF/1 mach fork), and replaced the display postscript WindowServer with Quartz, both for licensing cost and performance reasons. At least, that's my imp…

You forgot there was still OpenSTEP and the collaboration with Sun, which ended up having an influence on a language being designed at the time called Oak. Early versions of OS X were still based on OpenSTEP, thus able to run on top of Windows as well.

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 impedance. I'm fairly certain Rhapsody is the same, using the OSFMK kernel and 4.4BSD "lite".

At least, I don't think OS X Server 1.0 software would have worked on the OpenSTEP for Enterprise stuff?

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

#57
post #45

As the author mentions, Apple's internal work with A/UX and the associated Mac toolbox led to a product known as the Macintosh Application Environment, MAE. I used it on a PA-RISC HPUX workstation in the 90s. Actually worked really well. We were using CAD tools on HPUX workstations but it didn't have much in the way of productivity apps. Running the MAE layer allowed one to fill that gap. It was a surprisingly lightw…

> As the author mentions, Apple's internal work with A/UX and the associated Mac toolbox led to a product known as the Macintosh Application Environment, MAE I can't find any solid info on it but have to imagine their experience reimplementing Toolbox was tied into "Star Trek" somehow as well: https://en.wikipedia.org/wiki/Star_Trek_project

https://web.archive.org/web/19980613012744/http://www.mae.ap...

MAE is 68k macintosh emulator with some OS/toolbox parts handled with native code.

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

#58
post #55
post #39

Earlier quoted context omitted.

Tangential to AU/X and licensing costs, I think this is why OS X was something like a "from scratch" recreation of NeXTSTEP instead of being a straight port. They replaced the AT&T licensed UNIX core with a new open source one derived from the 386BSD forks (and DEC's OSF/1 mach fork), and replaced the display postscript WindowServer with Quartz, both for licensing cost and performance reasons. At least, that's my imp…

I had thought NeXTStep was always BSD based? Still might have paid the unix license; this was pre AT&T vs USL, but, thought nextstep was basically CMU mach (which itself was BSD+Mach) + the NextStep frameworks/ui

Yes the apis eg cocoa are the openstep apis and the terminal tools under openstep were BSD

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

#59

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?!"

After studying the history a bit it seems to me the reasons were organizational more than technical. Jobs brought his team back with him and they built on what they were familiar with. With better management the existing nanokernel-based MacOS could probably have been evolved similar to what MS did with NT.

Nt is not a evolution of dos.

A similar issue you need a new kernel for protected memory etc.

Apple did make attempts see Taligent

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

#60
post #55
post #39

Earlier quoted context omitted.

Tangential to AU/X and licensing costs, I think this is why OS X was something like a "from scratch" recreation of NeXTSTEP instead of being a straight port. They replaced the AT&T licensed UNIX core with a new open source one derived from the 386BSD forks (and DEC's OSF/1 mach fork), and replaced the display postscript WindowServer with Quartz, both for licensing cost and performance reasons. At least, that's my imp…

I had thought NeXTStep was always BSD based? Still might have paid the unix license; this was pre AT&T vs USL, but, thought nextstep was basically CMU mach (which itself was BSD+Mach) + the NextStep frameworks/ui

NeXTSTEP/OpenSTEP were based on 4.3BSD/4.4BSD(not-lite) and required a license from AT&T to distribute. I assume that, to be legally safe, they would have scrapped that code entirely and replaced it with 4.4BSD lite, pulling in code from 4.4BSD lite forks like FreeBSD and NetBSD.
Post reply on HN