'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.

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.

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?

I thought the HTC Dream/G1 also had 128 MB RAM, but you're correct - it had 192 MB! :)

> The power of Objective-C?

Sort of. I kind of like objective-C in that it gets more fundamentals right than it gets wrong - better than fucking reimplementing Java and then hoping with years and millions of dollars it will perform acceptably - it’s quite sad given how naive ObjC is at it’s core. But iPhone probably would have been successful even with plain C or C++ with a decent library.

Smartphones and PDAs like Palm and PocketPC arguably did relatively more with much less - (this is not to diminish the UX achievement or advancement of iPhone so please put the pitchforks down).

Yeah but it couldn't multi-task could it?

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.

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.

Windows Phone and Symbian could.

Well, NeXTstep could multitask in 8MB of RAM. And do it well in 16MB.

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.

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).

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.

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.

There are plenty of smart people who work on Android system performance, unfortunately the work put into iOS overshadows it.

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

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.

> 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)

Back in the day with i686 Linuxes you ran terms with screen under 8MB of RAM and lots of SVGAlib software.

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 :-)

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.

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