While SGI boxes were beautiful, IRIX itself was... not. It had a Motif look which looked outdated, even compared to OS/2.
Linux has some of these properties today so that's what I'm using now.
IRIX users would beg to differ. Towards the end of SGI's life, IRIX has a amassed a laundry list of bugs labeled critical that weren't getting fixed and the list was getting bigger, prompting many of the staff to leave SGI and many SGI customers to switch to BSD or Linux, further driving more nails into SGI's coffin.
[0] http://preserve.mactech.com/articles/mactech/Vol.13/13.06/Ju...
This[1] is a picture of a WebForce Indy unboxed, complete with Photoshop, Illustrator, and Indyballs.
And this[2] is a brochure for the WebForce Indy.
[0] https://therealmccrea.com/2014/01/09/january-1994-a-very-goo...
[1] https://old.reddit.com/r/retrobattlestations/comments/6oohy7...
Found out SGI machines seek out each other and elect a TimeMaster based on up-time, clock changes. Turns out we had a machine that predated all of the new ones that had not been restarted in 2 years that had incorrect time.
Definitely workhorse machines.
Screenshots, config file, etc anything, please share.
I worked with stuff like AIX and Solaris for years but like why would I ever bother with them again. What am I going to do, install DB2 for fun?
Myself I'd never put the effort in, but I have fond memories of telnetting into the Indigo my brother's college roommate had in their dorm room, so when people do this nostalgia retro stuff and post it on the web I enjoy browsing it for a bit.
For the youth: The AIX machine I remember did not even boot without a proper network. They featured obscure key combos, a tiny LCD screen and even more obscure beep codes to let you configure the network parameters. Only then they would boot into a proper OS.
Anyways my point was more that with this old tech you'll probably spend a lot of time on boring details before you'll even get to the fun part, like running DB2.
A mate of mine has an absolutely beautiful old Austin 12 which turns 100 years old this summer. It actually drives surprisingly like a modern car, modulo things like no syncromesh so you have to double-declutch - it doesn't have the "funny" pedal layout of a Ford Model T, for example - and its 1800cc engine still produces most of its 27bhp taking it to a top speed absolutely flat out downhill and homesick of about 50mph, not that you'd want to with its cable-operated brakes. Most of the mechanicals would be familiar to anyone who'd worked on any sort of car.
You could take that 100-year-old car and daily it, around town. It is a joy to drive, and everyone wants a good look at it. It's clearly a thing of beauty made in a way that nothing will ever be made again. However!
Pretty much every time you go to drive it you need to fiddle with the carburettor, or do something to the magneto, or take the spark plugs out and give them a clean, or prime something, or oil something, or generally fettle some part. You've got to set the throttle, the choke, and the magneto timing *juuuuust* right before you swing the starting handle or it'll break your wrist. The cooling system either overheats or doesn't heat up enough and the only way to tell is it doesn't run properly and sometimes steam comes out - for both conditions.
I love driving it. I also love old OSes like AIX and SunOS. I've even run 2.11BSD on a real PDP11!
Here's the thing, though. I have Linux on my desktop, and a 25-year-old Range Rover parked outside. They're both a bit old-fashioned with some clunky bits of styling that you wouldn't have these days. They're a bit crude mechanically (it has a 1960s V8 boat engine under the bonnet!? It has a *monolithic* kernel under the bonnet?!) but they both start on the button, run all day without having to get out and fiddle, and they're comfortable to sit at for long period and actually *get shit done*.
No-one stops to turn and gawp as you go past though.
(this was in the early 2000s when the Internet was still nascent, and I didn't have any IBM experts in my circle)
but when i think of using them, i am asking myself, what am i going to do with these old systems? on some i can install linux, ok, that's nice, but then all i got is linux in a nice looking box. even at the time, when i had scored an apollo domain workstation that was acting as a door stop in a university library. it had a very interesting networking system. i looked around on it for a while but then i just left it sit there.
i'd probably be more happy if i could find a modern case designer that makes PC cases look like the sun or sgi boxes of old.
[1]i have joy, i have fun, i run linux on a sun
A friend of mine made a 6dof shooter recently[0][1] for IRIX and O2 for a retro platform game jam.
[0] https://nuclear.itch.io/deeprunner
[1] https://www.youtube.com/watch?v=0-zUOuBWFZY (older build but shows the O2)
I also used the SPDIF input on my Octane (connected to a Philips DCC player) to digitize a bunch of my old cassette tapes. Many of those tapes don’t have commercial digital releases.
This isn’t at all difficult today. You can buy a S-video to USB interface from Wal-Mart for $25. 20 years ago they were more expensive but still easy to get.
https://www.walmart.com/ip/Composite-RCA-S-Video-To-USB-Conv...
I also have rose-tinted glasses now on IRIX and SGI since I worked on those machines for better part of 90's and early 2000's in VFX (both VFX work and software for it). There was mystique about those daylight robbery machines that made you feel you could and should achieve more. There's nothing like that today anymore, except maybe getting a DGX - Carmack even mentioned something similar ( https://twitter.com/ID_AA_Carmack/status/1398519867280609282... ) which I can definitely relate to from SGI era.
Except unlike current Linux, the SGI workstations didn't have screen tearing and had HW accelerated GUIs working out of the box. Shots fired! :D
I feel sorry for you if you didn't experience it directly. It was a magical time.
Why? Why not!
I'm biased, because I did work with IRIX at SGI and I did in fact touch some kernel code as well.
What I miss from IRIX, that no other system has yet replicated: 1) Realtime mode. RTLinux doesn't count. In IRIX, you could run your own code at a higher priority than the scheduler itself (this was called hard realtime), and you'd give it time slices when you could, or a core or two. 2) Frame scheduling. When rendering 3D, you could have the scheduler connected to the monitor refresh rate to make you less likely to miss a frame boundary.
Yes, Motif was very plain, and X11 was a hot mess to work with, but the thing had capabilities which are still hard to find.
FWIW, SGI didn't seem to agree.
From SGI's own whitepaper: "In addition, REACT for Linux adds unique capabilities including sgi-shield and kbar that were not available on IRIX. The Linux based platform delivers better real-time performance than SGI Origin running IRIX with realtime extensions: 30µs guaranteed interrupt response time versus 50µs for Origin."
https://static.aminer.org/pdf/PDF/000/565/463/operating_syst...
Without REACT extensions, Irix realtime facilities aren't any different than the scheduling policies of Linux (this is akin to bypassing the normal scheduler).
https://nixdoc.net/man-pages/IRIX/man5/realtime.5.html.
I have a soft spot for Irix from the early 90s, and it had some clever accomodations for the technology at the time, but things have moved on and advanced.
They were also insanely expensive, affordable to only the wealthiest of established companies. A basic SGI workstation would cost as much as a sports car, and professional workstation as much as a house. At those prices they had better damn be beautiful and well built.
In the early '00s ugly beige boxes with Intel CPUs and Nvidia GPUs running BSD, Windows NT and Linux started wiping the floor with those beautiful SGI workstations at only a fraction of the price, that it made SGI basically irrelevant overnight. It was a bloodbath. The only market they held onto for a little while were supercomputers and compute workstations for wealthy customers that were running massive simulations like oil & gas for which money was no abject.
The VFX team of the original Matrix movie from 1999 was grateful they could save huge amounts of time and money by running their rendering pipeline on networked commodity Dell workstations with off the shelf Intel CPUs.[1] That was one of the last nails in SGIs coffin.
[1] "Manex Visual Effects used 32 Dell Precision 410 Dual P-II/450 Processor systems running FreeBSD as the core CG Render Farm. Charles Henrich, the senior systems administrator at Manex, says, "We came to a point in the production where we realized we just did not have enough computing power on our existing SGI infrastructure to get through the 3-D intensive sequences. It was at that point we decided on going with a FreeBSD based solution, due to the ability to get the hardware quickly as well as the reliability and ease of administration that FreeBSD provides us. Working with Dell, we purchased 32 of these systems on a Wednesday, and had them rendering in production by Saturday afternoon. It was truly an amazing effort on everyone’s part, and I don’t believe it would’ve been possible had we chosen to go with any other Operating System solution."
SGI was my favourite UNIX until OS X, and I still have an SGI Fuel (with all the Nekochan extras) that I boot up each time I need a nostalgia kick:
That is true, and it gave a super confusion feeling about seeing stuff like Maya running on it, which was peak software IMO (I mean, algebra friendly reactive DAG based, complex geometry rendering, including near real time constrained physics simulation.. with server/client split and noob-moldable/scriptable UI). So even if the DE felt lagging, you never cared much.
What I remember most was the startup chime - in an era when piezo electric speakers would be the norm the SGI startup chime was incredibly rich and extravagant.
It kind of makes sense tho.
Some people were making CGI for movies on SGI boxes.
And naturally, some of the movies where SGI machines were involved ended up putting those machines in the movie itself:
> Jurassic Park featured a lot of computer generated images and it was one of the first movies to show SGI computers on screen.
http://www.sgistuff.net/funstuff/hollywood/jpark.html
http://www.sgistuff.net/funstuff/hollywood/index.html
So if the SGI computers made a lot of computer noises. Perhaps this helped inspire the portrayal of noisy computers in hacker movies.
They were fun machines to play around on; even when we first got them c ~ 1999 PCs with a graphics card were catching up, but there was just something solid about them. I miss those days of *NIX workstations.
Edit:
You might not see the problem if you have a computer with 32 GB of RAM and I certainly do. However I like to ensure that responsiveness is first up.
IRIX Motif is 2D accelerated and very snappy as it's multi threaded and designed for power users.
I've never used KDE but remember Windows Aero? Metro? What about macOS's Aqua UI? They use tons of resources and often times when the computer is just a couple years old it becomes unusable with the typical system bloat that occurs.
What I'm basically trying to say is that visual effects that aren't well designed aren't worth the resources they take up. Functionality over aesthetics any day.
I personally don't care much for the Motif looks (although I've only used OpenMotif – I'm not sure how it compares to IRIX's implementation; from some quick screenshots I looked up it seems IRIX looked better) but describing it as objectively "ugly" or "a sin against life" is just wrong.
No.
Strongly divided, as to the strength of like or dislike, yes.
But as for the split, it's pretentious architects and a handful of laymen outliers on one side, and billions of people on the other. And whenever people vote with their wallets (as tourists, or picking where to live, etc) they shit all over brutalist monstrocities.
But we can use other examples – I don't really want to talk about brutalism as such – like metal music, or paintings from Picasso or Mondriaan, or the discussion about whether or not Alien is a good film that still holds up in 2023 from earlier this week, or any number of things.
Hill of the Buddha, Sapporo:
https://en.wikipedia.org/wiki/Hill_of_the_Buddha
Cathedral of Saint Mary of the Assumption, San Francisco:
https://en.wikipedia.org/wiki/Cathedral_of_Saint_Mary_of_the...
Spomenik Memorials, Former Yugoslavia:
https://www.spomenikdatabase.org/
None of those are ugly.
While those are not hideous, they're hardly anything to write home about, much less call beautiful either. Compare them with a traditional budhist shrine, national monument, or church, and they're seen as the regression to ideology and "architect as god" arbitrariness that they are.
Do yourself a favor and try comparing the responsiveness and resource usage of, e.g., KDE Plasma with desktop composition off vs on. You’ll probably be really shocked when you see how much more CPU you need to do something as simple as scrolling a browser window.
Really, try it. Any browser, scroll around on something and look at your CPU usage and the framerate of your screen.
Or image editing — try panning around an image. Doesn’t matter what editor/viewer either, since they all have to draw on your X server.
Even just moving windows around on top of one another — everything is just so much more efficient when you offload it to a hardware accelerator.
Does it use more RAM? Yeah, a little, because the way it works is by keeping the entire contents of the windows in memory rather than culling anything that’s not exposed in front. It’s definitely not 500 MB more, though, and it definitely can (and does) take advantage of any dedicated VRAM available.
And the trade off of being able to just dump a framebuffer to the viewport instead of repeatedly computing what’s been culled 60+ times a second is definitely worth it to me, but if you still prefer not using acceleration, there’s always the option to just not use it.
What I have seen is many computers that seem to spend more time calculating various animations than actually animating stuff. When I worked in a computer shop years ago I often turned off animations and transparencies for people who came in with slow computers (XP, Vista, 7) and they were generally happy with the speed-up and didn't mind the lesser visuals at all.
Without composition, each program repaints itself. Which means there's an appreciable lag, and if the program is stuck you can get a blank box if a previously covered program is uncovered. This can be an annoyance if you need to read something from there.
Eg, an actual example is a program being blocked by a modal dialog stops being repainted. If the dialog asks you "Enter a password" and the what for is written on the no longer repainting parent you may have a problem.
You're misattributing blame here. Aqua, Aero, and Metro were themselves just UI themes/design languages. They did not cause performance problems. To the underlying compositor it doesn't matter if a button is brightly colored beveled triangle or a flat rectangle. A 32x32px button is 1,024 pixels that need to be drawn to a buffer irrespective of what's in those pixels.
The performance problems in those UIs were almost always related to the compositor and underlying hardware (or drivers for same). Without hardware accelerated drawing, even just 2D acceleration, the compositor was limited by the CPU and memory.
The hardware limitations are only problematic at the margins though. At those various systems' introduction the performance issues were only at the low end. As the "low end" improved performance became a non-issue. Aero sucked when it was introduced because the 3D compositor was enabled on underpowered graphics hardware at the request of OEMs. Aqua ran great on then-new PowerMacs but sucked on the mobile graphics chips in iMacs and all the Mac notebooks of the time.
That's an extreme view; GP didn't indicate that all UI toolkits needed to resemble Motif.
I mean, would it be fair to sum up your point as "Prisons are maximally efficient concrete boxes, all houses should be eye candy"?
Motif is (was at the time) just one of a large number of GUI designs. I quite liked it myself at the time, too.
https://www.researchgate.net/publication/202165712_Emotion_D...
I use this: https://github.com/grassmunk/Chicago95
That changed with KDE 4 and a lot of people rejected it. One would assume those people are the same ones who now use Trinity.
Things they got right: contrast. Shapes. I don’t need my glasses to use this stuff.
Things they got wrong: over the top 3D look. Fonts are shit. Italics in menus? Ragged bitmap italics? Gotta be fucking kidding me.
A computer is a tool, most tools are not sleek, they have buttons and dohickies, sharp edges that do work, etc. There is nothing wrong with polishing something up, sure, but it has to be strictly secondary to usability.
The high contrast 3d look in motif wasn't because its creators had bad taste. They may well have also had bad taste, but the appearance served a utilitarian purpose. :)
Hello, Firefox, I'm looking at you, especially during start-up. I don't know whose idea it was to "fade-in" the toolbars on start up, but I noticed that one right away, when firing it up over both x2go and (especially) X-over-SSH. Cute thing to do in the middle of a pandemic where everyone is using remote displays!
>The X-Windows Disaster
[...]
>The Motif Self-Abuse Kit
>X gave Unix vendors something they had professed to want for years: a standard that allowed programs built for different computers to interoperate. But it didn’t give them enough. X gave programmers a way to display windows and pixels, but it didn’t speak to buttons, menus, scroll bars, or any of the other necessary elements of a graphical user interface. Programmers invented their own. Soon the Unix community had six or so different interface standards. A bunch of people who hadn’t written 10 lines of code in as many years set up shop in a brick building in Cambridge, Massachusetts, that was the former home of a failed computer company and came up with a “solution:” the Open Software Foundation’s Motif.
>What Motif does is make Unix slow. Real slow. A stated design goal of Motif was to give the X Window System the window management capabilities of HP’s circa-1988 window manager and the visual elegance of Microsoft Windows. We kid you not.
>Recipe for disaster: start with the Microsoft Windows metaphor, which was designed and hand coded in assembler. Build something on top of three or four layers of X to look like Windows. Call it “Motif.” Now put two 486 boxes side by side, one running Windows and one running Unix/Motif. Watch one crawl. Watch it wither. Watch it drop faster than the putsch in Russia. Motif can’t compete with the Macintosh OS or with DOS/Windows as a delivery platform.
>[...] X will not run in these 4 bit overlay planes. This is because I’m using Motif, which is so sophisticated it forces you to put a 1" thick border around each window in case your mouse is so worthless you can’t hit anything you aim at, so you need widgets designed from the same style manual as the runway at Moscow International Airport. My program has a browser that actually uses different colors to distinguish different kinds of nodes. Unlike a PC Jr, however, this workstation with $150,000 worth of 28 bits-per-pixel supercharged display hardware cannot display more than 16 colors at a time. If you’re using the Motif self-abuse kit, asking for the 17th color causes your program to crash horribly. [...]
http://www.art.net/~hopkins/Don/unix-haters/x-windows/motif....
>MOTIF ANGST PAGE
>If you have any ANGSTFUL Motif code, comments, documentation, or resources, please share them with me! Here is some of the stronger stuff I've found. Note: this is only for official Open Software Foundation Motif inspired Angst. If you're experiencing TCL/Tk That Only Looks Like Motif But Doesn't Suck Angst, then you should stop whining and fix the problem yourself, if somebody else hasn't already.
/* Note that the text callbacks are "weird" in that they expect values in the callback structure to be set inside the callback proc to determine what actions need to be taken after the callbackproc returns. In particular, the XmTextVerifyCallbackStruct's 'doit' slot is always set to True, and must be set to False if the callbackproc doesn't want the action to be taken. To do this, Set_Call_Data_For_XmTextVerifyCallbackStruct() is called by Wcb_Meta_Callbackproc() after the callback lisp code is evaluated, and the values bound to these settable variables are set inside call_data....
Another inconsistency with the Text widget is that some callbacks on this widget return XmAnyCallbackStruct's (XmNactivateCallback, XmNfocusCallback, XmNvalueChangedCallback), whereas XmNlosingFocusCallback, XmNmodifyVerifyCallback, and XmNmotionVerifyCallback return XmTextVerifyCallbackStruct. In the code below, we look at the 'reason' slot of the call data, (which is present in both XmAnyCallbackStruct and in XmTextVerifyCallbackStruct) to determine the kind of callback that occured and we only bind the values that are appropriate for that kind of callback. Information about which slots are valid for particular callback was taken from the documentation on the XmText(3X) widget, and verified against the Motif 1.1 source -- this is valid for both XmText and XmTextField widgets... */
static LVAL s_CALLBACK_CUR_INSERT, s_CALLBACK_NEW_INSERT, s_CALLBACK_START_POS, s_CALLBACK_END_POS, s_CALLBACK_TEXT;
static void Lexical_Bindings_For_XmTextVerifyCallbackStruct(bindings_list,
lexical_env,
call_data,
client_data)
LVAL bindings_list; /* a list of symbols to which values from XmTextVerifyCallbackStruct are bound */
LVAL lexical_env;
XtPointer call_data;
LVAL client_data; /* XLTYPE_CALLBACKOBJ */
{
extern LVAL true;
register LVAL s_bindname;
XmTextVerifyCallbackStruct* cd;
/* How long can this go on???? */
}
At the time, it was quite impressive (110dpi) and now is probably bested by a randomly-chosen $100 LCD at Microcenter.
I only used IRIX-themed window managers in Linux, back in the 90s, but I absolutely love that clean look
PERFORMANCE UPDATE
"Indy: an Indigo without the 'go'". -- Mark Hughes
"X and Motif are the reasons that UNIX deserves to die." -- Larry Kaplan
>The performance story is just as bad. I was tempted to write simply, "Try to do some real work on a 16 megabyte Indy. Case closed.", but I'll include some details.
>In May, I listed some unacceptable Motif performance measurements. Just before 5.1 MR, someone reran my tests and discovered that the performance had gotten even worse. Some effort was expended to tune the software so that instead of being intolerable, it was back to merely unacceptable performance.
>We no longer report benchmark results on our standard system. The benchmarks are not done with the DSO libraries; they are all compiled non-DSO so that the performance in 5.1 has not declined too much.
>Before I upgraded from 4.0.5 to the MR version of 5.1, I ran some timings of some everyday activities to see what would happen. These timings were all made with the wall clock, so they represent precisely what our users will see. I run a 32 megabyte R4000 Elan.
Test 4.0.5 5.1 % change
---- ----- --- --------
C compile of a 25 sec 35 sec 40%
small application
C++ compile of a 68 sec 105 sec 54%
small application
Showcase startup, 13 sec 18 sec 38%
May report file
Start a shell <2 sec ~3 sec ~50%
Jot 2 MB file <2 sec ~3 sec ~50%
>Bloating by itself causes problems. There's heavy paging, there's so much code and it's so scattered that the cache may as well not be there. The window manager and X and Toto are so tangled that many minor operations like moving the mouse or deleting a file wake up all the processes on the machine, causing additional paging, and perhaps graphics context swaps.
>But bloat isn't the whole story. Rocky Rhodes recently ran a small application on an Indy, and noticed that when he held the mouse button down and slid it back and forth across the menu bar, the (small) pop-up menus got as much as 25 seconds behind. He submitted a bug, which was dismissed as paging due to lack of memory. But Rocky was running with 160 megabytes of memory, so there was no paging. The problem turned out to be Motif code modified for the SGI look that is even more sluggish than regular Motif. Perhaps the problem is simply due to the huge number of context swaps necessary for all the daemons we're shipping.
>The complexity of our system software has surpassed the ability of average SGI programmers to understand it. And perhaps not just average programmers. Get a room full of 10 of our best software people, and you'll get 10 different opinions of what's causing the lousy performance and bloat. What's wrong is that the software has simply become too complicated for anyone to understand.
What I do know is that children and smooth-brains alike in the 1990s could figure out Windows 9x and Mac OS 7 with little effort as "ugly" as they were. Even CDE, the ugliest girl in the village, was still usable.
I have a genius-level IQ (it's been tested) and I cannot figure some of this new shit out. It's often poorly thought out and illogical. Modern OS design has turned into a virtual escape room, where the puzzle has now become accomplishing basic tasks but you get to take an acid trip with animations and hamburger buttons along the way.
And 30 years after them nobody is able to do something at least at the same level of design. Today the level is at "RGB LEDs and transparent case".
Design has died.
If you're building a PC at least you can still get some pretty creative custom case designs on AliExpress etc https://www.youtube.com/watch?v=FPF7Z7TLdsk