9 ms·

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

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

retrac 5y ago
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 typical entry-level Macs were still selling with 2 - 4 MB sometimes and a full 32 MB upgrade would cost twice as much as the base model. In short, basically the same reasons we didn't all run SCO UNIX or whatever on our IBM PCs. Much the same dynamic for why the Windows NT kernel took so long to come down to home computers (in Windows XP finally). Even OS X's RAM requirements would inhibit its uptake for a few years. "Real" operating systems were too big for the small computers of the 1980s and even early 1990s.
- spijdar 5y ago
  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 impression from comparing NeXTSTEP and early OS X. A lot of the "base layer" was totally replaced, including those troublesome licensed bits.
  - pjmlp 5y ago
    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.
    - spijdar 5y ago
      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?
      - pjmlp 5y ago
        That much I don't recall, maybe, not sure.
      - lukeh 5y ago
        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.
        spijdar 5y ago
        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...
  - cat199 5y ago
    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
    - pasc1878 5y ago
      Yes the apis eg cocoa are the openstep apis and the terminal tools under openstep were BSD
    - spijdar 5y ago
      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.
  - asveikau 5y ago
    It also probably has to do with personalities, and who did what. NeXT was the Jobs thing. So Jobs came back, and they based things on NeXT.
    - pjmlp 5y ago
      While killing almost everything else. The video of the audience heat he is taking for those decisions and how he goes justifying his decisions is worth watching for anyone that needs to go through something similar.
      - perardi 5y ago
        Though he did notably compromise on Carbon. The early plan was Cocoa/App Kit all the way, which meant a fundamental rewrite of all the important applications, namely Adobe and Microsoft stuff. Which would not have flown.
        pjmlp 5y ago
        Sean Parent was key on that whole process, given his role at Adobe and Apple, hear his interviews here, https://adspthepodcast.com/ https://adspthepodcast.com/
      - vintagedave 5y ago
        Do you have a link to that video?
        mrpippy 5y ago
        https://archive.org/details/wwdc-1997-fireside-chat-steve-jobs https://archive.org/details/wwdc-1997-fireside-chat-steve-jo...
- ncmncm 5y ago
  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.
icedchai 5y ago
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
- hedgehog 5y ago
  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.
- classichasclass 5y ago
  This is correct, but as a practical matter, since the Finder was just another process on A/UX everything else (including X clients, if any) could keep running. Unfortunately this would kill all your Mac apps, including your X server if you were running it through MacX.
- wmf 5y ago
  That's no worse than Classic aka the Blue Box. In retrospect it seems like Carbon on A/UX should have been possible.
hedgehog 5y ago
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.
- pasc1878 5y ago
  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
  - hedgehog 5y ago
    Exactly. MS rehosted win16 apps on top of a new kernel, ported the UI, and encouraged developers to migrate code to win32. Apple had pieces of a similar transition with the transition to PPC but failed to execute, maybe because they were betting on different attempts to rewrite everything from scratch.
    - pjmlp 5y ago
      Win16 and NT branch don't share almost anything. Probably the only port was Win32s, which was a subset of Win32 backported to Win16. Win16 stuff runned on a VM like environment, WOW. https://en.m.wikipedia.org/wiki/Windows_on_Windows https://en.m.wikipedia.org/wiki/Windows_on_Windows
      - hedgehog 5y ago
        I'll admit I haven't seen the NT source but from a user perspective NT's UI (widgets, progman, etc) looked and functioned near identically to Windows 3 so I've always thought those bits were ported over. I'm aware most everything under that was replaced. To my eye that was one step in a well-executed evolution up from legacy Windows towards the eventual convergence in XP.
        5y ago

retrac 5y ago

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 typical entry-level Macs were still selling with 2 - 4 MB sometimes and a full 32 MB upgrade would cost twice as much as the base model. In short, basically the same reasons we didn't all run SCO UNIX or whatever on our IBM PCs. Much the same dynamic for why the Windows NT kernel took so long to come down to home computers (in Windows XP finally). Even OS X's RAM requirements would inhibit its uptake for a few years. "Real" operating systems were too big for the small computers of the 1980s and even early 1990s.

spijdar 5y ago
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 impression from comparing NeXTSTEP and early OS X. A lot of the "base layer" was totally replaced, including those troublesome licensed bits.
- pjmlp 5y ago
  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.
  - spijdar 5y ago
    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?
    - pjmlp 5y ago
      That much I don't recall, maybe, not sure.
    - lukeh 5y ago
      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.
      - spijdar 5y ago
        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...
- cat199 5y ago
  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
  - pasc1878 5y ago
    Yes the apis eg cocoa are the openstep apis and the terminal tools under openstep were BSD
  - spijdar 5y ago
    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.
- asveikau 5y ago
  It also probably has to do with personalities, and who did what. NeXT was the Jobs thing. So Jobs came back, and they based things on NeXT.
  - pjmlp 5y ago
    While killing almost everything else. The video of the audience heat he is taking for those decisions and how he goes justifying his decisions is worth watching for anyone that needs to go through something similar.
    - perardi 5y ago
      Though he did notably compromise on Carbon. The early plan was Cocoa/App Kit all the way, which meant a fundamental rewrite of all the important applications, namely Adobe and Microsoft stuff. Which would not have flown.
      - pjmlp 5y ago
        Sean Parent was key on that whole process, given his role at Adobe and Apple, hear his interviews here, https://adspthepodcast.com/ https://adspthepodcast.com/
    - vintagedave 5y ago
      Do you have a link to that video?
      - mrpippy 5y ago
        https://archive.org/details/wwdc-1997-fireside-chat-steve-jobs https://archive.org/details/wwdc-1997-fireside-chat-steve-jo...
ncmncm 5y ago
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.

icedchai 5y ago

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

hedgehog 5y ago
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.
classichasclass 5y ago
This is correct, but as a practical matter, since the Finder was just another process on A/UX everything else (including X clients, if any) could keep running. Unfortunately this would kill all your Mac apps, including your X server if you were running it through MacX.
wmf 5y ago
That's no worse than Classic aka the Blue Box. In retrospect it seems like Carbon on A/UX should have been possible.

hedgehog 5y ago

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.

pasc1878 5y ago
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
- hedgehog 5y ago
  Exactly. MS rehosted win16 apps on top of a new kernel, ported the UI, and encouraged developers to migrate code to win32. Apple had pieces of a similar transition with the transition to PPC but failed to execute, maybe because they were betting on different attempts to rewrite everything from scratch.
  - pjmlp 5y ago
    Win16 and NT branch don't share almost anything. Probably the only port was Win32s, which was a subset of Win32 backported to Win16. Win16 stuff runned on a VM like environment, WOW. https://en.m.wikipedia.org/wiki/Windows_on_Windows https://en.m.wikipedia.org/wiki/Windows_on_Windows
    - hedgehog 5y ago
      I'll admit I haven't seen the NT source but from a user perspective NT's UI (widgets, progman, etc) looked and functioned near identically to Windows 3 so I've always thought those bits were ported over. I'm aware most everything under that was replaced. To my eye that was one step in a well-executed evolution up from legacy Windows towards the eventual convergence in XP.
      - 5y ago