4 ms·

What amazes me about NeXTStep is that you could actually run that desktop, running Display PostScript, in grayscale, admittedly, but with the full motion window

What amazes me about NeXTStep is that you could actually run that desktop, running Display PostScript, in grayscale, admittedly, but with the full motion window dragging and everything else, on that display, with 8MB of RAM. Oh, and on a 25MHz '040. Oh, yes, it was tight. But it was eminently usable (including Project and Interface Builder) with 20MB of RAM. Heck, I think XClock is challenged to run in 20MB today.

hinkley 3y ago
'030 even. I thought some of this was wrong but it turns out the BeBox lore is leaking into my NeXT memories. Wikipedia says it was a 60830@25MHz.
- flenserboy 3y ago
  And the '030 varieties performed admirably well, even after the '040 & '040 Turbo varieties appeared. Our school had a bevy of cubes, and those were the primary workstations for three years until they opened a lab full of slabs before our senior year. The best part was having our user directories on a main server, and we could log in to any campus box and have access to our account. 30 years later & I still can't easily do that with the Macs on my home network.
TazeTSchnitzel 3y ago
NeXT and its successor, the modern Apple, have done incredible things with low amounts of resources. It feels nothing short of miraculous that the first few iOS devices could do so much in just 128MiB of RAM. No Android device has ever managed with that little! The power of Objective-C?
- johndoe0815 3y ago
  I thought the HTC Dream/G1 also had 128 MB RAM, but you're correct - it had 192 MB! :)
- deleted 3y ago
  [deleted]
- jaimex2 3y ago
  Yeah but it couldn't multi-task could it?
  - TazeTSchnitzel 3y ago
    I don't think an Android device with that much RAM would manage much multitasking. iPhone OS actually could multitask with jailbreaking, though you quickly discovered the limitations of that amount of RAM.
    - saagarjha 3y ago
      This is less of an issue today (although there aren't very many jailbreaks to take advantage of it) but back then it was pretty clear the device ran with very little RAM to spare. The best tweaks were fairly simple when it came to RAM usage but true multitasking or other things that stayed resident generally had a massive hit on system performance.
  - pjmlp 3y ago
    Windows Phone and Symbian could.
  - deleted 3y ago
    [deleted]
  - mpweiher 3y ago
    Well, NeXTstep could multitask in 8MB of RAM. And do it well in 16MB.
    - saagarjha 3y ago
      I mean the concept of multitasking takes basically no overhead. The question is what resources your "average app" takes. On NeXTSTEP those requirements were quite low.
- pjmlp 3y ago
  Symbian, Windows Phone did just fine with C++, and also .NET. The power of AOT compiled languages instead of plain interpreter. Apparently the original Android as it was bought by Google, was planned to use JavaScript, then they pivoted into Java, and it took decades until they got any kind of good AOT/JIT story (starting with Android 5).
- saagarjha 3y ago
  I would say it's more the power of incentives, really. Android has historically never had the performance investment that Apple has put on their platform. If anything, early Android was much closer to iOS in terms of hardware specs and diverged quickly as they were unable to keep their resource usage down.
  - pjmlp 3y ago
    I wouldn't call the JIT, AOT and PGO efforts nothing, and stuff like project butter. On the other hand going with a basic Assembly interpreter for Dalvik, when Nokia and Sony-Ericson already had JIT compilers for Symbian, while claming Android was better, no comments. Likewise when comparing Symbian Series 60 3rd edition phones with Android.
    - saagarjha 3y ago
      There are plenty of smart people who work on Android system performance, unfortunately the work put into iOS overshadows it.
1over137 3y ago
It's because they weren't running everything on top of Electron. :)
canucker2016 3y ago
I remember people complaining about how slow the magneto-optical drive was. By the time they ditched the MO-drive as the default, NeXT already had a bad taste in people's mouths, esp. at the introductory price of US$6.5K.
badsectoracula 3y ago
> Heck, I think XClock is challenged to run in 20MB today. Assuming you mean the 'xclock' binary you'd find in Xorg installations, it seems to use about 8MB of RES memory. But keep in mind that it drags in a bunch of libraries (objdump shows Xaw, Xmu, Xt, X11, Xrender, Xft, xkbfile and the math and C libraries as direct dependencies) and those drag their own (ldd shows 26 libraries) and all of that stuff add to the memory overhead for their own purposes even if at the end xclock didn't use them. Chances are an xclock reimplementation that talked the X11 protocol directly, used only the minimum functionality needed to display the clock lines and was statically linked to some minimal C library without any external dependencies would use much less memory. Though even that would probably feel as too much memory since a lot of the memory used by a program in a Linux system relies a lot on what is already there - including the hardware and kernel drivers. (which is also why these articles comparing memory usage between various desktops tend to make zero sense as they measure the entire system memory usage, the largest part of which is outside the control of the desktop environment in the first place and in most cases will vary between different computers even with the same distro)
- anthk 3y ago
  Back in the day with i686 Linuxes you ran terms with screen under 8MB of RAM and lots of SVGAlib software.
  - badsectoracula 3y ago
    I had a Pentium 1 laptop with 8MB of RAM in early 2000s (bought it for very cheap, my first laptop) running Slackware with Window Maker and Emacs :-)
    - anthk 3y ago
      Wmaker and Emacs? You did a custom kernel build right? For being something to brag against, you used XEmacs, I guess. Or X-compiled Emacs, in order to be a "big" accomplishment. UXTerm+Emacs under the CLI was "big", but manageable; the X build (even the Athena or Lucid one) wasn't a light thing at all.
johnklos 3y ago
Not quite, but close. 12 megabytes is still much, much more than is easily explainable. Here is xclock on a 36 megabyte m68030, hosted on the same machine (so be patient). On the other hand, modern OSes do a pretty good job of hiding resource abuse with excellent memory management. http://elsie.zia.io/xclock.png http://elsie.zia.io/xclock.png

hinkley 3y ago

'030 even. I thought some of this was wrong but it turns out the BeBox lore is leaking into my NeXT memories. Wikipedia says it was a 60830@25MHz.

flenserboy 3y ago
And the '030 varieties performed admirably well, even after the '040 & '040 Turbo varieties appeared. Our school had a bevy of cubes, and those were the primary workstations for three years until they opened a lab full of slabs before our senior year. The best part was having our user directories on a main server, and we could log in to any campus box and have access to our account. 30 years later & I still can't easily do that with the Macs on my home network.

TazeTSchnitzel 3y ago

NeXT and its successor, the modern Apple, have done incredible things with low amounts of resources. It feels nothing short of miraculous that the first few iOS devices could do so much in just 128MiB of RAM. No Android device has ever managed with that little! The power of Objective-C?

johndoe0815 3y ago
I thought the HTC Dream/G1 also had 128 MB RAM, but you're correct - it had 192 MB! :)
deleted 3y ago
[deleted]
jaimex2 3y ago
Yeah but it couldn't multi-task could it?
- TazeTSchnitzel 3y ago
  I don't think an Android device with that much RAM would manage much multitasking. iPhone OS actually could multitask with jailbreaking, though you quickly discovered the limitations of that amount of RAM.
  - saagarjha 3y ago
    This is less of an issue today (although there aren't very many jailbreaks to take advantage of it) but back then it was pretty clear the device ran with very little RAM to spare. The best tweaks were fairly simple when it came to RAM usage but true multitasking or other things that stayed resident generally had a massive hit on system performance.
- pjmlp 3y ago
  Windows Phone and Symbian could.
- deleted 3y ago
  [deleted]
- mpweiher 3y ago
  Well, NeXTstep could multitask in 8MB of RAM. And do it well in 16MB.
  - saagarjha 3y ago
    I mean the concept of multitasking takes basically no overhead. The question is what resources your "average app" takes. On NeXTSTEP those requirements were quite low.
pjmlp 3y ago
Symbian, Windows Phone did just fine with C++, and also .NET. The power of AOT compiled languages instead of plain interpreter. Apparently the original Android as it was bought by Google, was planned to use JavaScript, then they pivoted into Java, and it took decades until they got any kind of good AOT/JIT story (starting with Android 5).
saagarjha 3y ago
I would say it's more the power of incentives, really. Android has historically never had the performance investment that Apple has put on their platform. If anything, early Android was much closer to iOS in terms of hardware specs and diverged quickly as they were unable to keep their resource usage down.
- pjmlp 3y ago
  I wouldn't call the JIT, AOT and PGO efforts nothing, and stuff like project butter. On the other hand going with a basic Assembly interpreter for Dalvik, when Nokia and Sony-Ericson already had JIT compilers for Symbian, while claming Android was better, no comments. Likewise when comparing Symbian Series 60 3rd edition phones with Android.
  - saagarjha 3y ago
    There are plenty of smart people who work on Android system performance, unfortunately the work put into iOS overshadows it.

1over137 3y ago

It's because they weren't running everything on top of Electron. :)

canucker2016 3y ago

I remember people complaining about how slow the magneto-optical drive was. By the time they ditched the MO-drive as the default, NeXT already had a bad taste in people's mouths, esp. at the introductory price of US$6.5K.

badsectoracula 3y ago

> Heck, I think XClock is challenged to run in 20MB today. Assuming you mean the 'xclock' binary you'd find in Xorg installations, it seems to use about 8MB of RES memory. But keep in mind that it drags in a bunch of libraries (objdump shows Xaw, Xmu, Xt, X11, Xrender, Xft, xkbfile and the math and C libraries as direct dependencies) and those drag their own (ldd shows 26 libraries) and all of that stuff add to the memory overhead for their own purposes even if at the end xclock didn't use them. Chances are an xclock reimplementation that talked the X11 protocol directly, used only the minimum functionality needed to display the clock lines and was statically linked to some minimal C library without any external dependencies would use much less memory. Though even that would probably feel as too much memory since a lot of the memory used by a program in a Linux system relies a lot on what is already there - including the hardware and kernel drivers. (which is also why these articles comparing memory usage between various desktops tend to make zero sense as they measure the entire system memory usage, the largest part of which is outside the control of the desktop environment in the first place and in most cases will vary between different computers even with the same distro)

anthk 3y ago
Back in the day with i686 Linuxes you ran terms with screen under 8MB of RAM and lots of SVGAlib software.
- badsectoracula 3y ago
  I had a Pentium 1 laptop with 8MB of RAM in early 2000s (bought it for very cheap, my first laptop) running Slackware with Window Maker and Emacs :-)
  - anthk 3y ago
    Wmaker and Emacs? You did a custom kernel build right? For being something to brag against, you used XEmacs, I guess. Or X-compiled Emacs, in order to be a "big" accomplishment. UXTerm+Emacs under the CLI was "big", but manageable; the X build (even the Athena or Lucid one) wasn't a light thing at all.

johnklos 3y ago

Not quite, but close. 12 megabytes is still much, much more than is easily explainable. Here is xclock on a 36 megabyte m68030, hosted on the same machine (so be patient). On the other hand, modern OSes do a pretty good job of hiding resource abuse with excellent memory management. http://elsie.zia.io/xclock.png http://elsie.zia.io/xclock.png