3 ms·

OS X is not Darwin. All the interesting parts are on the layers built on top of it. What was remarkable was being able to run a graphic accelerated version of

OS X is not Darwin. All the interesting parts are on the layers built on top of it. What was remarkable was being able to run a graphic accelerated version of AppKit built for touch screens (UIKit) and have RAM to spare to run a non trivial app, like, you know, a full blown web browser, all in 128MB. So yeah, Darwin + window server + springboard + Safari + webpage > 128MB is pretty impressive indeed.

heavyset_go 5y ago
> OS X is not Darwin. iOS is not OS X. > So yeah, Darwin + window server + springboard + Safari + webpage > 128MB is pretty impressive indeed. Maemo did all all of this years before, and in 64MB of RAM.
- tambourine_man 5y ago
  I don’t think Debian wasn’t doing double buffering GPU compositing of the UI. Nor was it running WebKit. Show me a video of a smooth pinch to zoom on a webpage with MicroB
  - heavyset_go 5y ago
    Konqueror has modular backend support, and it shipped with WebKit support as backend before the iPhone was released. Rekonq also used it and not KHTML. Epiphany used WebKit since mid-2007, it's now Gnome Web. All were available on Debian and Debian-based distributions. Phone-wise, Symbian used WebKit in 2005.
wvenable 5y ago
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.
Jyaif 5y ago
My iMac from 2000 had 128MB and ran OS X.
- tambourine_man 5y ago
  And it was terribly slow. The iPhone was responsive like no other computer at its time, let alone phone. It prioritizes user input above all else, which is the right choice.
  - Jyaif 5y ago
    > And it was terribly slow. https://youtu.be/YW7z0uMOYrw?t=364 https://youtu.be/YW7z0uMOYrw?t=364 Does that look terribly slow to you?
    - tambourine_man 5y ago
      That's a 600Mhz G3 with 256MB of RAM. Probably 3X faster CPU and twice the RAM. I was a user at the time. Had many iMac G3s. But even on this machine, try navigating through nested menus, dragging windows around. Now boot from Mac OS 9 and do the same. It's night and day.

heavyset_go 5y ago

> OS X is not Darwin. iOS is not OS X. > So yeah, Darwin + window server + springboard + Safari + webpage > 128MB is pretty impressive indeed. Maemo did all all of this years before, and in 64MB of RAM.

tambourine_man 5y ago
I don’t think Debian wasn’t doing double buffering GPU compositing of the UI. Nor was it running WebKit. Show me a video of a smooth pinch to zoom on a webpage with MicroB
- heavyset_go 5y ago
  Konqueror has modular backend support, and it shipped with WebKit support as backend before the iPhone was released. Rekonq also used it and not KHTML. Epiphany used WebKit since mid-2007, it's now Gnome Web. All were available on Debian and Debian-based distributions. Phone-wise, Symbian used WebKit in 2005.

wvenable 5y ago

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.

Jyaif 5y ago

My iMac from 2000 had 128MB and ran OS X.

tambourine_man 5y ago
And it was terribly slow. The iPhone was responsive like no other computer at its time, let alone phone. It prioritizes user input above all else, which is the right choice.
- Jyaif 5y ago
  > And it was terribly slow. https://youtu.be/YW7z0uMOYrw?t=364 https://youtu.be/YW7z0uMOYrw?t=364 Does that look terribly slow to you?
  - tambourine_man 5y ago
    That's a 600Mhz G3 with 256MB of RAM. Probably 3X faster CPU and twice the RAM. I was a user at the time. Had many iMac G3s. But even on this machine, try navigating through nested menus, dragging windows around. Now boot from Mac OS 9 and do the same. It's night and day.