3 ms·

128MB is absolutely massive compared to the hardware that NextSTEP / OS X was designed to run on. https://en.wikipedia.org/wiki/NeXTstation https://en.wikipedi

128MB is absolutely massive compared to the hardware that NextSTEP / OS X was designed to run on. https://en.wikipedia.org/wiki/NeXTstation https://en.wikipedia.org/wiki/NeXTstation

tambourine_man 5y ago
NextSTEP didn’t run Safari, nor Quartz or Aqua. And NextSTEP was slooooowww. One of the reasons some of us rooted for BeOS.
- unfocussed_mike 5y ago
  NextSTEP didn't run Quartz, no. It used Display PostScript -- a comparably impressive achievement at the time. It also wasn't that slow on the Intel machines, e.g. the black NextStep PCs Elonex made in the UK. It was quite nippy on some of the earlier NeXT hardware, too. BeOS was a very different operating system and -- let's be clear -- would have been a terrible, terrible choice. I tell you what was slow: WebObjects on the Mach subsystem layer on top of Windows NT.
  - tambourine_man 5y ago
    Mach was slow, disk access (the spinning beachball Mac OS inherited was supposed to be a CD originally) was very slow. Using a Turing complete language for drawing was scary. > BeOS was a very different operating system and -- let's be clear -- would have been a terrible, terrible choice. Oh, sure. But it sure was snappy. And gorgeous. And that file system was awesome.
    - unfocussed_mike 5y ago
      > Mach was slow, disk access (the spinning beachball Mac OS inherited was supposed to be a CD originally) was very slow. https://pbfcomics.com/comics/beach-closing/ https://pbfcomics.com/comics/beach-closing/ > Using a Turing complete language for drawing was scary. Not particularly sure why. Aren't all apps using Turing complete languages to draw on screen? It's just a question of which layer that happens. Display PostScript did the same, surely?
      - dreamcompiler 5y ago
        The comment is about the display layer. Yes [almost] all computer languages are Turing complete; the distinction is about the level at which they produce drawing instructions. Some simply set particular bits in memory that cause pixels to light up. That's essentially how the original Mac worked. More abstract is producing instructions to "draw a rectangle" or "rotate all future lines by 20 degrees." That's the "display list" approach and it's more flexible than manipulating raw pixels. More flexible still is producing commands that can contain loops like Postscript. Now we're in tricky territory, because it's easy to make a mistake that e.g. produces an infinite loop and the whole display locks up. And it's much harder to reason about such things as the update rate of the drawing process because the drawing commands are themselves Turing complete. This doesn't matter when you're merely printing because there is no refresh. Not so with an interactive display. That's why the "Display" in "Display Postscript" was a big deal.
        tambourine_man 5y ago
        I think PostScript was considered “too powerful” for its own good by the industry, which is why it was mostly replaced by PDF (initially a subset of it). With PostScript, you can have a document that renders differently every time you open it (on purpose). Or a file that will never finish rendering or printing, like the infinite loop you mentioned. PostScript infinite possibilities are cool and cute, but not all that practical for a graphics description language.
        unfocussed_mike 5y ago
        > With PostScript, you can have a document that renders differently every time you open it (on purpose). Or a file that will never finish rendering or printing, like the infinite loop you mentioned. There was a font, wasn't there -- was it Just van Rossum's Beowulf -- that drew itself slightly differently every time? Can't find a reference now. edit: it was! https://www.fontshop.com/families/ff-beowolf https://www.fontshop.com/families/ff-beowolf
        5y ago
- gcanyon 5y ago
  Those awesome BeOS demos! They would open a dozen apps to max out both CPUs (25 or 33 MHz as I recall) and then show that you could grab any window and drag it around, and everything else would slow to a crawl, but that window, the one you were interacting with, was still snappy. Then they would shut off one of the CPUs. Everything was as slow as winter molasses. And they would grab a window, and it was still super snappy, while everything else almost froze solid. I miss being the center of my computer's universe like that.
addaon 5y ago
128 MB is also the base requirement for 10.2, 10.3, and 10.4 (although at least 10.3 will run with much less than that in practice).
- tambourine_man 5y ago
  It will run. It’s just a very bad experience. The original iPhone was a delight to use, responsive like the desktop counterparts weren’t, despite much slower hardware and running on battery.
  - GeekyBear 5y ago
    I think part of that was that the graphics layer on the iPhone was GPU accelerated from the start, and the first few versions of OSX were not. One of the things that Microsoft got right and Google got wrong was that Microsoft copied the concept of using GPU accelerated graphics with Windows Phone and it took Google quite some time to catch up.

128MB is absolutely massive compared to the hardware that NextSTEP / OS X was designed to run on. https://en.wikipedia.org/wiki/NeXTstation https://en.wikipedia.org/wiki/NeXTstation

tambourine_man 5y ago

NextSTEP didn’t run Safari, nor Quartz or Aqua. And NextSTEP was slooooowww. One of the reasons some of us rooted for BeOS.

unfocussed_mike 5y ago
NextSTEP didn't run Quartz, no. It used Display PostScript -- a comparably impressive achievement at the time. It also wasn't that slow on the Intel machines, e.g. the black NextStep PCs Elonex made in the UK. It was quite nippy on some of the earlier NeXT hardware, too. BeOS was a very different operating system and -- let's be clear -- would have been a terrible, terrible choice. I tell you what was slow: WebObjects on the Mach subsystem layer on top of Windows NT.
- tambourine_man 5y ago
  Mach was slow, disk access (the spinning beachball Mac OS inherited was supposed to be a CD originally) was very slow. Using a Turing complete language for drawing was scary. > BeOS was a very different operating system and -- let's be clear -- would have been a terrible, terrible choice. Oh, sure. But it sure was snappy. And gorgeous. And that file system was awesome.
  - unfocussed_mike 5y ago
    > Mach was slow, disk access (the spinning beachball Mac OS inherited was supposed to be a CD originally) was very slow. https://pbfcomics.com/comics/beach-closing/ https://pbfcomics.com/comics/beach-closing/ > Using a Turing complete language for drawing was scary. Not particularly sure why. Aren't all apps using Turing complete languages to draw on screen? It's just a question of which layer that happens. Display PostScript did the same, surely?
    - dreamcompiler 5y ago
      The comment is about the display layer. Yes [almost] all computer languages are Turing complete; the distinction is about the level at which they produce drawing instructions. Some simply set particular bits in memory that cause pixels to light up. That's essentially how the original Mac worked. More abstract is producing instructions to "draw a rectangle" or "rotate all future lines by 20 degrees." That's the "display list" approach and it's more flexible than manipulating raw pixels. More flexible still is producing commands that can contain loops like Postscript. Now we're in tricky territory, because it's easy to make a mistake that e.g. produces an infinite loop and the whole display locks up. And it's much harder to reason about such things as the update rate of the drawing process because the drawing commands are themselves Turing complete. This doesn't matter when you're merely printing because there is no refresh. Not so with an interactive display. That's why the "Display" in "Display Postscript" was a big deal.
      - tambourine_man 5y ago
        I think PostScript was considered “too powerful” for its own good by the industry, which is why it was mostly replaced by PDF (initially a subset of it). With PostScript, you can have a document that renders differently every time you open it (on purpose). Or a file that will never finish rendering or printing, like the infinite loop you mentioned. PostScript infinite possibilities are cool and cute, but not all that practical for a graphics description language.
        unfocussed_mike 5y ago
        > With PostScript, you can have a document that renders differently every time you open it (on purpose). Or a file that will never finish rendering or printing, like the infinite loop you mentioned. There was a font, wasn't there -- was it Just van Rossum's Beowulf -- that drew itself slightly differently every time? Can't find a reference now. edit: it was! https://www.fontshop.com/families/ff-beowolf https://www.fontshop.com/families/ff-beowolf
        5y ago
gcanyon 5y ago
Those awesome BeOS demos! They would open a dozen apps to max out both CPUs (25 or 33 MHz as I recall) and then show that you could grab any window and drag it around, and everything else would slow to a crawl, but that window, the one you were interacting with, was still snappy. Then they would shut off one of the CPUs. Everything was as slow as winter molasses. And they would grab a window, and it was still super snappy, while everything else almost froze solid. I miss being the center of my computer's universe like that.

addaon 5y ago

128 MB is also the base requirement for 10.2, 10.3, and 10.4 (although at least 10.3 will run with much less than that in practice).

tambourine_man 5y ago
It will run. It’s just a very bad experience. The original iPhone was a delight to use, responsive like the desktop counterparts weren’t, despite much slower hardware and running on battery.
- GeekyBear 5y ago
  I think part of that was that the graphics layer on the iPhone was GPU accelerated from the start, and the first few versions of OSX were not. One of the things that Microsoft got right and Google got wrong was that Microsoft copied the concept of using GPU accelerated graphics with Windows Phone and it took Google quite some time to catch up.