> A smaller, more secondary reason for creating this was to sort of observe how a Classic-era app might run on today’s hardware. As our hardware gets beefier, it seems like our software gets chunkier. If we could port yesterday’s software to run natively on today’s hardware, how might it perform? Very fast, I’d imagine.
This reminds me of a small personal project I decided to take on a couple years ago. I did it both as an experiment in performance and for nostalgia's sake.
I bought as pristine an example as possible of Apple's last machine that could run Mac OS 9 natively, a PowerMac G4 (the 2003 MDD vintage). I upgraded the CPU and RAM as much as possible (dual 1.25 GHz G4, 2GB RAM), and replaced the hard drive with as fast an SSD as the system could handle (don't recall which SSD model at the moment).
In short, I was astonished at the "snappiness" of the system. Boot time took no more than 15 seconds. Shutting down took only about one second. The system entered sleep mode near-instantly. Opening and closing windows within an app happened as fast (or faster) than I could react to it. Opening and closing classic apps themselves was at least an order of magnitude faster than what I would consider reasonable analogs from today.
I already had a decent amount of disdain for how much time I spend on a modern Mac/iOS device waiting for the system to catch up to my inputs, but it got worse after having done this experiment. A simple example, but which pains me near-daily, is the creation of folders in the modern Finder. After typing cmd+shift+N, I often must wait an amount of time that must be on the order of several hundred milliseconds before typing the name of the folder (if I don't wait, the first couple characters I type will be missing from the folder's name, which is yet another time-sink to go back and fix the missing characters). And this is on an iMac Pro! I tried this exact test on my old-but-quick PowerMac G4, and I never had to wait nor lost any chars no matter how quickly I attempted to type the command and the subsequent folder name.
Classic Mac OS always perfectly queued any number of input events and executed them in order exactly as expected, regardless of how much the system was lagging. None of the input would be silently discarded or mishandled like it is today. You could easily do something like this:
>type command-N to create a folder
>type its new name "abc"
>type command-O to enter folder "abc"
>type command-N to create another folder within folder "abc"
>type its new name "123"
>type command-O to enter folder "123"
>change mind and type command-W and command-delete to put folder "123" in the trash
>type command-shift-W to close all windows
>type "Macintosh HD"
>type command-O
>type "Applications"
>type command-O
>type "Adobe Photoshop"
>type command-O
>type command-N to create new Photoshop document
>type command-S to open the save dialog
>type command-D to navigate to desktop
>type "abc" to select your new folder
>type command-O
>type the return key to save the new document
It doesn't matter whether the system was able to keep pace with your input. You were guaranteed to have a new folder named "abc" and your new Photoshop document already saved inside.
Now in OS X (I'm sorry, "macOS"), you need to pause at every step and wait until it's done executing before doing the next. Otherwise your input will be lost in the multithreaded abyss.
I don’t think it’s macOS that’s dropping your keyboard events, rather, they’re being forwarded to the old application or nowhere at all while you’re transitioning.
Yes, but that's kind of the point - the system as a whole loses events, it's no help to the user to abdicate responsibility for that. Especially if there's no way to fix it without redesigning the system.
>A simple example, but which pains me near-daily, is the creation of folders in the modern Finder. After typing cmd+shift+N, I often must wait an amount of time that must be on the order of several hundred milliseconds before typing the name of the folder
If it helps, I might have a solution for this one - if you have Dropbox installed, something about it causes delays when creating new folders or right-clicking anywhere in the Finder. I used to get beachballs for a half-second when creating a new folder, but after doing a clean install of macOS & not installing Dropbox, everything is snappy.
But I totally agree with your main point. I have a Pismo PowerMac G3 and was similarly surprised at its UI speed compared with modern machines. (I'd love to try again with BeOS or Haiku on that machine sometime too...)
Sort of. Dropbox does add menu items to the right-click context menu on the Mac, and icons indicating whether a file has been synced or not. But if I understand correctly, it does this by installing a kernel extension:
"Traditionally, Dropbox operated entirely in user space as a program just like any other on your machine. With Dropbox Infinite, we’re going deeper: into the kernel—the core of the operating system. With Project Infinite, Dropbox is evolving from a process that passively watches what happens on your local disk to one that actively plays a role in your filesystem."
I think Apple discourages the practice now. There used to be a lot of UI enhancement apps for Mac OS X (called haxies, managed by an app called APE - Application Enhancer). But they were a source of system instability & occasional kernel panics.
Some of us run an old OS on old machines because it just works.
I got an old Thinkpad for an experiment with coreboot. I found it sexy, so I upgraded it like you did.
It feels "snappier" than anything else I have tried. All I need is SSH, and a confortable keyboard, so has become my work computer! No maintenance, no distractions. Just ssh.
I highly encourage everyone to do the same experiment you did, to realize how poorly we are served by current offerings. (or maybe I am just in retrocomputing. I don't know. I just like it)
Calling geeky things “sexy” feels like trying to justify liking the geeky thing by giving it a different name. I understand why you do it.
What I don’t know is how your project relates to both older computers and older operating systems, because this sounds like something ideal for an operating system much more modern than the popular Windows 7 that is used a lot today: Centos 7. Setup for that purpose, fast and powerful, while being perfectly reliable and having modern ease of use through systemd. I have a similar idea going on another laptop with a minimal Debian 9 installation (takes a little more setting up, but I can install more CLI programs outside your SSH use case).
And from that comes me wondering why you think the older hardware has a benefit. I sure find the lack of IPS screen noticeable even when the screen for the most part just displays text on a black background. Since the CLI has the best HDPI support out there (increase the font size), you could even take advantage of a high resolution screen.
What I do find especially good in your case is how you show how long hardware can last when not skimped on. An old thinkpad has great build quality, and for the most part there is no reason to stop using it. The best way to reduce waste is to not waste at all.
My "favourite" (well, it's really a bit depressing) example is that I can boot AROS (an AmigaOS API reimplementation) in its Linux-hosted form on Linux, into Workbench (Amiga desktop) using a startup script that then automatically starts an Amiga GUI based text editor called FrexxEd on my laptop in less time than it takes a near pristine terminal-only Emacs install to start on the same machine.
If this was some incredibly primitive editor it'd be one thing, but it's an editor with a bytecode compiled C-like extension language build in, as well as AREXX support, so it's fully programmable.
> A simple example, but which pains me near-daily, is the creation of folders in the modern Finder. After typing cmd+shift+N, I often must wait an amount of time that must be on the order of several hundred milliseconds before typing the name of the folder (if I don't wait, the first couple characters I type will be missing from the folder's name, which is yet another time-sink to go back and fix the missing characters). And this is on an iMac Pro!
That is very odd. I tried this a few times now on my 4 year old MacBook Pro and it was instantaneous each time. No delay. I wonder what may be causing the delay on your side. iMac Pro is after all absolutely state of the art.
FWIW I absolutely see that issue on a 2010 MBP running Cap'. If I quickly type M-S-n "foo" I end up with either a folded called "untitled folder" in edition mode (all selected) or a folder called "o" in edition mode (caret at end).
I only upgraded to High Sierra a month ago, and it was probably good that I waited, as I've seen no negative consequences so far. It's lightning fast, even with APFS and the other changes it brought.
This reminds me of a small personal project I decided to take on a couple years ago. I did it both as an experiment in performance and for nostalgia's sake.
I bought as pristine an example as possible of Apple's last machine that could run Mac OS 9 natively, a PowerMac G4 (the 2003 MDD vintage). I upgraded the CPU and RAM as much as possible (dual 1.25 GHz G4, 2GB RAM), and replaced the hard drive with as fast an SSD as the system could handle (don't recall which SSD model at the moment).
In short, I was astonished at the "snappiness" of the system. Boot time took no more than 15 seconds. Shutting down took only about one second. The system entered sleep mode near-instantly. Opening and closing windows within an app happened as fast (or faster) than I could react to it. Opening and closing classic apps themselves was at least an order of magnitude faster than what I would consider reasonable analogs from today.
I already had a decent amount of disdain for how much time I spend on a modern Mac/iOS device waiting for the system to catch up to my inputs, but it got worse after having done this experiment. A simple example, but which pains me near-daily, is the creation of folders in the modern Finder. After typing cmd+shift+N, I often must wait an amount of time that must be on the order of several hundred milliseconds before typing the name of the folder (if I don't wait, the first couple characters I type will be missing from the folder's name, which is yet another time-sink to go back and fix the missing characters). And this is on an iMac Pro! I tried this exact test on my old-but-quick PowerMac G4, and I never had to wait nor lost any chars no matter how quickly I attempted to type the command and the subsequent folder name.