MaXX Interactive Desktop: A Re-Implementation of the IRIX Interactive Desktop
maxxinteractive.com
maxxinteractive.com
I know it’s been posted here many times about how computers have become perceptually slow, but that Indy after a couple minutes of poking around really drove the point home in a way that no numbers ever could.
Computers have gained a lot, for sure, but they’ve also lost a lot. I wonder if it’s even possible to make a modern computer fast in a way that feels fast again.
Windows Explorer gets your particular example right: When you copy a bunch of files into a folder, it will highlight all of the copied files after it is done, so it doesn't matter if you saw the progress bar or not.
Hmm, perhaps if you replace the word "latency" with "duration"?
However, this was a trust thing, and not an innate limitation of human capacity.
Now that we’re in 2020, I would argue that almost 0 users need that crutch.
If the work is done, it’s done. Similarly, employees on early keyboard-only terminals didn’t need any delay either. They trusted that when they said do X, the system did it. How else could you process dozens (or hundreds!) of items a minute?
EDIT: After googling SGI workstation models I think what I used was actually most likely an O2[1]. Great design, I remembered its distinct look even after so many years.
In old GUIs (e.g. Windows 3.1), many things—file associations, program launchers, etc.—got loaded from disk into memory once—usually at GUI startup—and then the state of those things was maintained entirely in memory, with programs that updated the on-disk state of those things either 1. also independently updating the in-memory state with a command sent to the relevant state-database-keeper; or 2. requiring that you log out and back in to see changes.
Today, we don't have everything sitting around loaded into memory—but in exchange, we have soft-realtime canonicity, where the things you see in the GUI reflect the way things are, rather than a snapshot of the way things were plus (voluntary, possibly missable/skippable) updates. Install a program that has higher-than-default-binding file associations? The files in your file manager will update their icons and launch actions, without the program needing to do anything.
There's ways to eat your cake and have it too—to have on-disk canonicity and instant updates—but this require a very finicky programming model†, so we haven't seen any GUI toolkit offer this, let alone one of the major OSes do so.
† Essentially, you'd need to turn your Desktop Environment into a monolithic CQRS/ES aggregate, where programs change the DE's state by sending it commands, which it reacts to by changing in-memory state (the in-memory aggregate), and then persists a log of the events resulting from those commands as the canonical on-disk state (with other aggregates fed from those to build OLAPable indices / domain-state snapshots for fast reload.) This gets you "Smalltalk windowing semantics, but on a Unix filesystem substrate rather than a VM memory-image substrate."
I'm going to say the three largest contributions to general desktop lag are:
Animations and intentional delays. It can't be said, how much faster a machine feels when something like MenuShowDelay is decreased to 0, or the piles of animations are sped up.
Too many layers between the application draw commands and the actual display. All this compositing, vsync, and minimal 2d acceleration creates a low level persistent lag. Disabling aero on a win7 machine does wonders to its responsiveness. But even then pre-vista much of the win32 GDI/drawing API was basically implemented in hardware on the GPU. If you get an old 2d win32 API benchmark, you will notice that modern machines don't tend to fare well in raw API call performance. 30 seconds poking around on youtube, should find you a bunch of comparisons like this https://www.youtube.com/watch?time_continue=25&v=ay-gqx18UTM.... Keep in mind that even in 2020 pretty much every application on the machine is still relying on GDI (same as linux apps relying on xlib).
Input+processing lag, USB is polling with a fairly slow poll interval rate (think a hundred or so ms). Combined with the fact that the keystrokes/events then end up queued/scheduled through multiple subsystems before eventually finding their way to the correct window, and then having to again reschedule and get the application to retrieve and process it via GetMessage()/etc. Basically, this is more a function of modern software bloat, where all those layers of correct architecture add more overhead than the old school get the ps2 interrupt, post a message to the active window queue, schedule the process managing the window messages. (https://social.technet.microsoft.com/Forums/windows/en-US/b1...)
There are a number of other issues, but you can retune those three areas to some extent, and the results are a pretty noticeable improvement. Having someone at MS/etc go in and actually focus on fixing this might have a massive effect with little effort. But that doesn't appear to be in the cards, since they appear to be more interested in telemetry and personal assistants.
Tragically, it seems the only way to completely get rid of tearing in youtube is to re-enable Aero :( (at least with nvidia hardware). RIP classic.
These animations effectively increase the input lag significantly. Even with them turned off there are extra frames of lag between a click and the updated widget fully rendering.
(Everything below refers to a 60 Hz display)
For example, opening a combo-box in Windows 10 with animations disabled takes two frames; the first frame draws just the shadow, the next frame the finished open box. With animations enabled, it seems to depend on the number of items, but generally around 15 frames. That's effectively a quarter second of extra input lag.
A menu fading in takes about ~12 frames (0.2 seconds), but at least you can interact with it partially faded in.
Animated windows? That'll be another 20 frame delay, a third of a second. Without animations you're down to six, again with some half-drawn weirdness where the empty window appears in one frame and is filled in the next. (So if you noticed pop-ups looking slightly weird in Windows, that's why).
I assume these two-frame redraws are due to Windows Widgets / GDI and DWM not being synchronized at all, much like the broken redraws you can get on X11 with a compositor.
> USB is polling with a fairly slow poll interval rate (think a hundred or so ms).
The lowest polling rate typically used by HID input devices is 125 Hz (bInterval=8), while gaming hardware usually defaults to 500 or 1000 Hz (bInterval=2 or 1). Most input devices aren't that major a cause of input lag, although curiously a number of even new products implement debouncing incorrectly, which adds 5-10 ms; rather unfortunate.
https://epub.uni-regensburg.de/40182/1/On_the_Latency_of_USB...
This isn't usually what I think of when I think of "latency." Latency is, to me, the time between when the user inputs, and when the system recognizes the action.
This becomes especially problematic in situations where events get queued up, and then the extra latency causes an event to attach to something that is now in a different state than the user perceived it to be when they did the input—e.g. double-clicking on an item in a window you're closing right after telling the system to close the window, where you saw the window as open, but your event's processing was delayed until after the window finished closing, such that now you've "actually" clicked on something that was, at the time, behind the window.
On the other hand, the type of latency you're talking about—between when the system recognizes input, and when it finishes displaying output—seems much less troublesome to me.
We're not playing competitive FPS games here. Nobody's trying to read-and-click things as fast as possible, lest something horrible happen.
And even if they were, the "reading" part of reading-and-clicking needs to be considered. Can people read fast enough that shaving off a quarter-second of display time benefits them?
And, more crucially, does cutting that animation time actually cause users to be able to read the text faster? Naively you'd assume it would; but remember that users have to move their eyes to align with the text, to start reading it. If the animated version more quickly "snaps" the user's eyes to the text than the non-animated version, then in theory the user using the animated combo-box might actually be able to select an option faster!
(And remember, none of this matters for users who are acting on reflex; without the kind of recognition latency I mentioned above, the view controller for the combo-box will be instantly responsive to e.g. keyboard input, even while the combo-box's view is still animating into existence. Users who already know what they want, don't need to see the options in order to select them. In fact, such users won't usually bother to open the combo-box at all, instead just tabbing into it and then typing a text-prefix to select an option.)
I can deal with 9 seconds latency, if I can mentally precompute the expected path taken and the results match it - this happens just by being familiar with what you're doing, and can be compared to using Vi in edit mode with complex commands.
I can't deal with 400ms lag if the result is that a different action than the one I wanted is executed.
My points were under the mode of thought where you look at a modern system already aimed at being "fast because it's lightweight" (e.g. XFCE), and then you ask why it still feels laggy compared to BeOS/AmigaOS/etc.
Where such "lightweight" DEs do have perceivable latency, that latency mostly comes down to operations hitting the disk where these older systems didn't. (Also the input stack, yes, but that's not universal: modern hardware still has PS/2 ports, and modern OSes still access those with rather direct reads. Many gamers swear by PS/2 peripherals—though probably mostly for cargo-cult reasons.)
Some of the minimal-est Linux WMs, e.g. Fluxbox, are run entirely from memory once started, and so are comparably fast—but need an explicit restart/reload to do anything. Plus, the apps launched in the WM aren't designed with the same paradigm, so most of your experience there is still slow.
AROS goes through the full AmigaOS-style boot, registering devices, and everything.
It handily beat my Emacs startup.
Now, you can make Emacs start quicker, and FrexxEd is not by default as capable (but it's scriptable with a C-like scripting language), but there's no wonder people feel software has gotten slower, because so often the defaults assume we're prepared to wait.
E.g. one of my pet peeves with typical Emacs installations: Try misconfiguring your DNS and watch it hang until the DNS lookups fail.... It's not an inherent flaw in Emacs; you can certainly prevent it from happening, but so many systems have Emacs installations where you face a long wait. Normally of course this is not a big issue, but those setups still have a DNS lookup in the critical path for startup that adds yet one more little delay.
All of these things add up very quickly. In the cases where these things are an issue in older software, they tend to either need to be explicitly enabled, or there is concurrency.
I submitted some patches to AROS years ago, to implement scrollback buffers and cut and paste in the terminal, and one of the things it really brought back is how cautious AmigaOS was in making everything painstakingly concurrent all over the place. At the cost of throughput but cutting apparent responsiveness.
E.g. when you cut and paste from a console window on AmigaOS, data about the copied region gets passed to a daemon that will write it to a clips: device. It gets passed to a separate daemon because the clips: device that the clibboards are stored to, like everything else in AmigaOS can be "assigned" to another location. By default it is stored in T: (temporary). By default T: points to a RAM disk. However, clips: or T: could very well have been reassigned to MyClipboardFloppy:. In which case copying would prompt you to insert the floppy labeled MyClipboardFloppy: after which writing the copied section would take way too long. (That actual write to the floppy would happen in yet another task)
So copying as a high level system service is handled in a separate task (thread).
Everywhere throughout the system everything that could ever potentially be slow, and on a 7.16MHz 68k machine with floppies and limited RAM that was a lot of things, would be done in separate tasks so that at least the user could just get on with other things in the meantime. "Other things" then as a consequence often meant "just keep using the current application" because the concurrency would mean a lot of these things would lazily happen in the background.
For e.g. a typical shell session, just pressing a key will involve half a dozen tasks or so, e.g. gradually "cooking" the input from a raw keyboard event, to an event for a specific window, to a event to a specific console device attached to a window, to an event to a high level "console handler" that handles complex events such as e.g. auto-complete, to the shell itself. It is inefficient in terms of throughput, but because the system will preempt high priority tasks (including user input related ones), and react with low latency and offload less latency critical tasks to other tasks, the system feels fast.
A key to this was that on a system that slow, a lot of the things that could be slow, would regularly be slow for the developers and would get fixed so that you'd opt in to the slow behaviour. E.g. I doubt most people using Emacs are ever aware if their installation is slowed down by DNS lookups on startup for example, because most of the time it's fast enough that you won't really notice that one extra little papercut.
BeOS also has this design. Modern programming languages and platforms do make async and event-based programming a lot more intuitive, so we might well see this paradigm make a comeback.
I’ve been thinking about the landmark announcement by Apple that surprised absolutely nobody by informing its developers and the wider world that it will be switching to “Apple Silicon”, a yet-to-be-filled placeholder for a brandname-to-be. (The only thing it almost guarantees is that officially they won’t be any reference to ‘ARM’.)
So, famously Gil Amelio quipped that he had chosen to buy NeXT “rather than Plan Be” when, panicked by declining sales and hampered by an obsolete OS, he plonked down a sizeable amount of an on-the-verge-of-bankruptcy Apple to buy a working OS to succeed their decidedly musty old eighties tech; something they hadn’t been able to develop internally. NeXTStep had excellent developer tools, a close tie to graphic design (by way of its Display PostScript), and rather Frankenstein-ish UNIX core, though I’d hesitate to call it a “beating heart”. The core OS, the kernel, and so forth, were not the main strong point and were not great performers. It’s what stood above that had value and that has, apparently, driven and undergirded much of what Apple did since then and until now.
And yet, just as they finally abandon the charade of macOS X being “Mac Os Ten” and move forward to “macOS 11”, I can’t help but think that the path they have traced themselves will lead them to need to reimplement much of their core technology in a manner that is more akin to how BeOS’s “pervasive multithreading" was conceived almost thirty years ago. What do our devices provide us with now? Real-time media streams and lag-free interactivity whilst connected to a network and running on a fairly modest platform. When I first heard Be’s motto “One Processor Per Person Is Not Enough!” I was bewitched (to the point that my teenage-self me insisted obstinately that his next PC be a dual-processor, to experience the exotic thrill of it). But now it’s normal.
Apple’s switching to its own silicon, which probably means larger grids of the cores it already has shown are so incredibly overpowered for the likes of the iPad Pro (so much so that what every iPad Pro over has secretly suspected—that their machine could comfortably run macOS and a bunch of demanding applications—has been confirmed). I heard somewhere that the A12Z that powers the current-generation iPad Pros (and now coincidentally is pulling very honourable double duty as the SoC in the Developer Transition Kit) is a 4W part, and that the current MacBook Air is apparently designed for a 16W thermal capacity, therefore we can expect something along the lines of “four times as many of whatever will go in the A14”, and that’s a fair first-order approximation. So like with the AMD case, we’re going to have a lot of cores.
They’re going to need the BeOS ethos to master all those cores. And it’ll be interesting to watch, because our collective success with GPUs and some embarrassingly-parallelisable non-graphics corollaries have given us a collective false sense of security of having somehow ‘mastered’ parallelism. Ultimately at root our systems are built on mechanisms and assumptions that only scale favourably so far. Maybe it’s time to go back and have a good look at what those folks did in the early nineties when they delivered realtime multimedia streams on interactive devices with an absolute minimum of lag and did it all with what now we’d consider a pittance of resources.
Windows NT family branch has had asynchronous and event based support since the early days, being heavily multi-threaded, yet not many cared to use it properly.
To the point that Microsoft pushed for an async only world with WinRT(UWP) and it got mixed up responses. Now with Project Reunion going forward it remains to be seen how async will faire.
However at least .NET, C++20, Rust and JS now have full asynchronous support, as the main Windows desktop stacks.
On Android, Google only had AsyncTask, with multiple caveats how to use it properly, then came the fashion with RxJava, Java executors, now it seems Kotlin co-routines are the future, assuming a #KotlinFirst world, with C++20 on the NDK.
On the Apple side we have GCD still as the main workhorse.
As for the other OSes, I guess they are pretty much still the same as they always have been, so that leaves language runtimes for better async and event-based programming.
This is what enabled fast drawing despite very primitive drawing system (essentially GDI would get you a pointer to a window of VRAM, the origin of various fun graphical bugs people remember from windows, like dragging broken dialog boxes around that leave a "trace").
WinNT OTOH, has realized async support across the whole I/O stack, essentially finishing the never-finished concurrent QIO of Digital's VMS (VMS afaik to this day haven't got fully working concurrent QIO - the API is there, but if you actually enable concurrent operation too many applications die), and has a bunch of undocumented async mechanisms as well (including mostly free-form asynchronous calls from kernel to user - again a VMS invention - which are in many ways similar to POSIX signals except you aren't limited to a small table of events to attach handlers to, and they support concurrency by default)
For languages like javascript for example people all too often write evented code with an expectation that events will be processed 'practically immediately'. They're writing evented code, but not code designed for concurrency.
To get this right, you need to actually have the code executed with actual preemptive multitasking, and test it with random substantial delays in processing of messages.
On linux (which always seem to trail on the responsiveness metrics) a lightweight DE can help, but scheduler tuning makes a even bigger difference. Just switching the power profile to performance is far more noticeable on linux than most other OSs. If your not aware of the work of Con Kolivas you should read up on the history there. Everything is a lot better than it was 15 years ago, but a number of the core problems really haven't been solved.
On the software side, operating systems, desktop environments, GUI SDKs, frameworks, and so on could all take the problem a lot more seriously, but I wouldn't hold my breath waiting for that. There are too many people involved who believe it's reasonable to pause and play a little animation before doing what the user asked for.
There are other forces at work.
For instance on my primary workstation after a period of time from cold boot, pretty much everything is sitting comfortably in 32 GB of memory. A lot of time is more due to the
1) sheer volume of crap that has to be shuttled in memory, because memory accesses still aren’t free 2) there’s a surprising amount of repetitive CPU intensive tasks just to get a program started up on merely bookkeeping tasks like linking, conversion, parsing.
In addition to all the built in latencies already mentioned.
To prove this you can setup a system using a RAM disk and notice that responsiveness is often still subpar.
Special example for me is Chrome, which has a huge singleton in the form of Browser Process that can make your experience a hell even if all other chrome processes are idling - simply because it's the central hub that handles among other things all of Input handling and UI.
This compounds with other latencies, where often I can start building patterns of "if a windows containing that kind of content is on, expect macOS WindowServer to start lagging insanely despite being under low load)
To the point that old Macs had most of the system routines in ROM[0].
"Whoa, why does this seem so much more responsive than my modern machines?" Two things, I think: 1) the mouse cursor is being updated with every vertical refresh (80Hz), and 2) the latency of the CRT must be lower than an LCD.
Not bad for a 700MHz, 18 year old machine!
LCDs that aren't optimized for low latency will generally just buffer a full frame before displaying it, coupled with a slow panel these will typically have 25-35 ms of input lag at 60 Hz. LCDs meant for gaming offer something called "immediate mode" or similar, where the controller buffers just a few lines or so, which makes the processing delay irrelevant (<1 ms). The image is effectively streamed through the LCD controller directly into the pixel array.
I seriously doubt it's an SGI optimization.
I had an SGI Octane (multiple levels higher than an Indy). I've never felt IRIX's UI was noticeably more performant the contemporaneous Windows running on standard consumer PC hardware..
Xsgi included some interesting optimizations, starting with how it was a compositing X server and a feature that is known to break GTK3 all the time - Xsgi would provide a low color visual as the first choice, and this was reflected in the provided Motif and other libraries and exploited by software developed for Irix - the latter mostly because you could not depend on the end user having a 24bit display, though.
This means that the bandwidth requirements across all stages of drawing was reduced for common UI components, instead of slinging around high resolution 32bit RGBA bitmaps for everything as is the norm today on Linux. I haven't checked, but I strongly suspect that the more ascetic UI controls combined with classic X11 drawing calls also resulted in higher speed vs. slinging lots and lots of bitmaps with overdraw using XRender.
For more on that, consider checking the literature written about avoiding overdraw on Android and how much of an impact it had on latency of user interface. iOS, btw, actually did a lot of dirty tricks to essentially prevent developers from doing any overdraw without explicitly going for it, and supposedly a strong part of early review process was checking for overdraw - because the actual iPhone hw was not that powerful and they ran close to the bandwidth budget per frame.
I just started using Linux part time on the desktop, and it’s significantly more responsive than MacOS, to the point that I prefer using it, even though the Linux UI otherwise stinks in a lot of ways.
One big problem with all these old "workstation" computers, is that while us hobbyists still have our ways of getting the OS installed... The actual applications people ran on them almost seem lost to time. When software is so unbelievably expensive during its heyday, it tends to not make the jump over to "abandonware" repositories once its time has passed. This unfortunately makes demos of these old machines far more boring than demos of old PCs.
I always recommend developers to get the cheapest possible laptop for testing.
>I always recommend developers to get the cheapest possible laptop for testing.
Yeah that is stupid, until you are the developer of that Laptop, or your dev's have too much time, take trusty Hardware and Down-clock it if you need to (you don't want to debug cheap hardware).
And you should test on slow and unreliable hardware. You'd be surprised, for instance, how frequently servers fail to boot because the BMC ignored your instructions.
That is exactly NOT true, since there is no 100% correct emulation around, think of x64 emulation with integrated Meltdown, if you don't know about meltdown your emulation has no implementation for it.
Look you made a perfect counterargument, using unreliable hardware...with your words you could just test it with unreliable emulation ;)
>unreliable hardware... how frequently servers
Wait...server's and unreliable do not match together...and then the BMC argument..sound's bit crazy to me.
One big problem with running a 3rd party OS on these old machines (specifically SGI, Sun doesn't have this issue) is that they tend to not really support any of the hardware that actually makes these machines interesting.
It is the close marriage between IRIX and the hardware and top engineering that shines.
I use that machine for what i want to use it, i also use my C64 as a Webserver and my Leemote-Laptop as my Mainbackup. Better having Hardware you can use for something then not...and you know, you can reinstall Irix later if you want.
EDIT: After googling SGI workstation models I think what I used was actually most likely an O2[1]. Great design, I remembered its distinct look even after so many years.
There wasn't a lot of movement in the 3D workstation space at the time, whereas PC 3D accelerators were taking off big time. So you ended up with a system that was faster, a lot cheaper and where the regular PC maintenance software and infrastructure could be used (boy, homogenous Unix devops was a nightmare).
Having said that, CATIA was more a workhorse CAD and CAE software, so probably not the best to show off neat UIs, and amongst engineers it had a somewhat ponderous reputation.
Some software, made on IRIX, like Alias and I-DEAS did show it all off. Other apps ran great, but did their own thing no matter what UNIX you were on. Then again, some of those interfaces were amazing in their own way. I would count CATIA R5 in that group for sure.
If your meteorologist didn't want to hold a remote, the weather producer would have to sit in front of the workstation with their hand over the spacebar waiting for the right cues to advance to the next loop/pause point.
At some stations, it wasn't about the talent not wanting to hold the remote, it was about the station not having an engineer on staff who could rig up the remote.
At many stations in the 90's, and even some today, the "remote" is nothing fancier than a garage door opener, with the relays hooked into a breakout box to a DB25 serial port.
Piled up a bunker of Sgi machines, O2, Octane, Indigo, Indy, most very well equipped with the advanced memory and graphics options.
Alias, I-deas, Maya, Adobe, 3DS Max... Let's just say I could license most of that at will due to an error...
Learned a ton of high end skills that I benefit from today too. Great fun. And amazing demos. Putting those together was a total blast. People would get blown away using Showcase, the Sgi tools for video capture, audio, and Composer to mix, RIP, burn. This was mid 90's when most people were using Win 98, or maybe NT 3.5.1
Let's also say I got rid of said error (so don't ask) and gave the whole lot away to a 20 something me just itching for those same experiences. Those machines were well loved and used. Cool.
I needed a change away from that kind of computing as it went on the wane. Didn't want to look back.
But at the peak? I was very seriously productive on Irix. The Indigo Magic Desktop took everything I ever threw at it.
And one could flat out bury those machines with a heavy workload and still the UX was golden, responsive almost as if idle!
At one point, at some conference, the head scientist at Sgi said, "We turn compute problems into I/O problems."
How the machines performed showed that ethos off well, IMHO.
Honestly, today on say, Win 10, I can do all I did then on a laptop, but not enjoy it as much as I did that environment. It is responsive and fun!
Big software on Irix remains one of the peak computing experiences I have had. Damn good times.
I may have to put this on a Linux install and have some fun.
In my view, the Irix scheduler is insane good at balancing UX with workloads. It may not always be the peak possible throughput, but a skilled user can continue to blast through their tasks pretty much no matter what the OS load is.
On a lark, I got to try an extreme example of that:
Irix 5.3 on an Indigo Elan, 30Mhz CPU. I forget which one. I want to say R3k. (Check Ian's SGI Depot for more info)
I compiled "amp", which is an optimized mp3 player that formed the basis of many players after it was written.
At 30 Mhz, that Indigo Elan could play up to 192Mbps mp3 files, over NFS, while the desktop remained responsive.
At 256Mbps, CPU load was about 95 percent. Would glitch on occasion.
I found that quite impressive personally. I used that little Elan as a X terminal for a while and it was a pleasure to use.
...ah, Sgi.
Damn. Say what you want, their stuff was fun, had amazing docs, and got work done.
[Looks at Android / Win 10]
Meh.
That's part of why I scaled down. Unloaded that gear and went small, embedded retro for my fun computing. The work is easier today, and fine by me, because it is just work.
By glitch, I mean the music would drop, not the desktop.
These machines are excruciatingly slow by today's standards and I wouldn't want to run modern software on them. Still, they are the dinosaurs of the PC ecosystem - evolutionary dead-ends that hint at what could be. Who wouldn't want to study a living dinosaur?
This page about AVS is dated 1995 and cites a 1989 paper:
https://web.cs.wpi.edu/~matt/courses/cs563/talks/avs/avs.htm...
That said the desktop looks amazing! Love the theme.
I feel like my i3wm setup is extremely streamlined for instance.
That's why I keep Hatari installed... but I don't try to use it as my development environment.
Didn't the ST run GEM? Now that I think about it, I believe GEM could run on a bunch of different computers. I'll have to see if I can find a version to install on one of my banger laptops.
I got some janky 486 laptops for note-taking in university and swapped between that and OS/2 3.0 with its rudimentary pack-in wordprocessor. PC/GEOS would have been even better, but was not readily available at thwe time, as I think it was still a commercial product targeted towards schools using hand-me-down PCs.
AFAIU the atari version was a little more capable and a bit more fun than the other versions, due to Apple suing DRI and crippling later versions to comply with Apple's demands, yet somehow Atari was excluded from those demands since they bought rights to the source code for further development so continued with the original concept.
Things like the CPU performance monitor were a joy to see and haven't been improved on. Same goes for the screen savers, not that we have them now.
There was nothing clunky about the magical desktop and normally your applications were tools that cost tens of thousands. Mere mortals thought they were seeing the future and what a brilliant future that was. The web was going to be VRML 3D in those days but we ended up with 2D bloat.
The tools you have shape how you think and SGI just made your thinking creative and imaginative. Everyone else was on Windows which had great apps like MS Office but an SGI machine had none of those civilian programs.
IMHO Ubuntu has a desktop that falls short of what SGI had even though it is an environment that doesn't distract in the way that Windows does.
How I see it is that you have consumer operating systems such as Windows, ChromeOS and OSX and you have professional operating systems such as what classic UNIX machines had. Linux desktops are in this professional mould.
Susan Kare?
More information about her work on SGI:
In the old days Silicon Graphics had this almost mythical reputation. As a kid with a home computer I used to daydream about one day getting my hands on an SGI, what kind of games I'd be able to make on it.
The computer scene was more fragmented back then. Graphics Workstations sat apart from home computers, and the ordinary Amiga or C64 user would only read about them in magazines or see them featured in TV shows about movie special effects.
If you liked computer graphics, these TV shows and articles were like glimpses ten years into the future. Because of this, SGI became a byword for "amazingly cool computer with powerful, exotic graphics hardware that I will never get my hands on" Many of us hoped that one day we'd be playing video games on an SGI home computer or vr deck.
Seeing this question asked makes me sad. If you are browsing this on Linux then you're probably using code descended from Netscape which was developed by a guy called Zawinski on an SGI Indy.
Or if you have seen a movie, then all the special effects are descended from work done on SGI machines.
If you have fuel in your car, the oil field was probably originally found after running seismic analysis on an SGI. They were famous for their movie work but Oil & Gas was actually a far bigger market for them.
If you have flown anywhere, the pilot was trained on a simulator descended from technology developed by SGI.
If you program C++ then STL comes from SGI. As does the XFS filesystem.
If you have seen a weather forecast on TV, that probably was done on a Cray, who for a while were owned by SGI and who developed a lot of their tech. Many TV stations used SGIs to render the forecast on the green screen behind the presenter too.
If you have played Nintendo, the MIPS processor in it was developed by SGI. If you play games on PC, OpenGL was developed by SGI.
They were once one of the most influential computing companies in the world. Now they are merely a legend, and a fading one at that :-(
Me too, Irix, XFS (The Redhat std FS) and so much more was made by SGI.
Been a while and I had nearly forgotten! It used to be that when you googled an STL container, SGI documentation came up first. This was occasionally annoying as there were a few things that were slightly different from what was standardized. If memory serves, they had a better hash table before the standard did...
Didn't STL came from HP?
On the early days of the Web, and pre C++98, it was where most of us would read how to use the existing STL implementations.
These workstations were incredibly powerful and extremely expensive (think > $250,000 for the higher end gear in the 1990s) but pretty amazing.
Also, for the time it had very advanced user interfaces. SGI Irix was the name of the OS which ran on these machines.
However, after thinking about whether I'd actually use MaXX over GNOME for a few minutes, I decided that there was no compelling reason to do so other than nostalgia.
Has anyone tried this out and decided to use it as their daily desktop? If so, I'm interested to hear your experiences and rationale. Cheers!
Also I think FVWM was heavily inspired from this, and I’ve used that as a very efficient UI over VNC (gradients, images, rounded corners, etc. are expensive in terms of bandwidth. The minimalist aesthetic of this interface conveys a lot of structure in little data).
At my first software development job in the mid 90s, the "cool" basement room with all of the smart/weird developers in it had a a mix of Sun SPARCstation 10/20 and Sun Ultra 1 workstations.
There was also this one weird SGI O2 they had just bought to port their software to the IRIX platform, but noone wanted really wanted to use it, because of IRIX. So I picked that workstation, just to be in that room. Smartest decision of my life - what I learned in there defined my career.
The Irix Interactive Desktop (based on Motif) felt so incredibly responsive on the O2, compared to Motif/CDE on the Sun workstations. It was almost BeOS-like in that regard. It was the little touches that mattered. A random example: the CPU usage monitor updated at like 10-20 Hz, instead of like 1 Hz on the Sun workstations.
Not that anyone really used CDE in normal work - other window managers were far more efficient. I ended up using http://www.lysator.liu.se/~marcus/amiwm.html on this O2.
edit: Remembering, I got the machine with original SGI keyboard, mouse and screen.
I'm more interested on reliving the CEDAR/Tioga interactive desktop environment pioneered by the Xerox R&D team back in 1980s/1990s for their in-house productivity tools [1]. The system still have some productivity enabling features that are still not widely used as of now. Xerox also managed to port the system to SunOS at the time.
Anyone aware of any effort or clone that can enable CEDAR/Tioga to run on or emulated Linux?
I found out two years later that the root password was the empty string.
Then there was the time I went to Syracuse for the first conference on Java for scientific computing and Geoff Fox had two identical twins from eastern Europe to run a demo on two workstations hooked up to a big SGI computer unsuccessfully which Geoff answer with 'never buy a gigabyte of cheap RAM'.
For the youngsters, back when we had multiple prototypes of Stepanov's work for the C++ STL library, SGI was one of the companies hosting the documentation.
And then there was OpenGL, while ARB was formed in the process to standardize IrisGL into OpenGL, reading the documentation from the source was much better.
I think it worked remarkably fast even on 56k connection, and definitely worked fast on 512kbit that became available around that time.
(And there won't be an ARM version, I guess?)
I wonder if it has the Twilight background
Unfortunately it's pretty slow.
Beyond aesthetic reasons, it's hard to understand when one would really use these for daily driving. Anyone using this or CDE able to offer insight?
Also similar to bullet journaling, it doesn't take a modern DE to do so. An old one with a usable text editor will do fine.
In fact the clean lines, sensible design, and visible pixels give some of us a mental cue toward a simpler, gentler productivity reset. I find that my main DE is much less compelling in that way, modern though it may be.