I remember trying fsn back when everyone in our company used SGI computers.. and realized that in practice the 3D file manager is completely useless. In the movie they set it up so that it looked like you could navigate that way. Very cool. But nobody in our office tried it more than once.

I haven't heard it being called "Red Hat's XFS". Silicon Graphics, when it was still a company, ported XFS to Linux and Linus accepted it.

I've been using XFS for a very long time, and I've never been on Red Hat on my own machines..

As well as OpenGL, originally IRISGL, See for example,

  https://www.slideshare.net/slideshow/sigraph-asia-2008-modern-opengl-presentation/905245#13

XFS was/is astonishingly fast. When I had a an Indy in early 1990s I ran `find /` and it ran so fast (on a 4gb disk) that I thought it was an error.

It would be so nice to have an SGI laptop that gave Apple a run for its money.

Like the good old days.

Broadly speaking I think the instruction set doesn't make much difference (assuming it rises above a baseline level of capability). What did for all the workstation and minicomputer class vendors with non-x86 architectures was that x86 got good enough and was much much cheaper because of the volume of the PC market. At the lower end the business model (sell your CPU core to go into other companies' SoCs) was a lot more important than the architecture in Arm's eventual success I think (and the rise of riscv is absolutely down to its business model too).

Some of the things listed in that article are definitely architecture design mistakes (especially the lack of interlocks in MIPS I), but they're not deal breakers and some of them are fixable (later MIPS versions put in the interlocks so you didn't need to care unless you were targeting the older CPUs). In the end not that many programmers write assembly or compilers.

The R3000 had a moment in the sun, it was used in everything from SGI and DEC workstations down to the Sony PlayStation.

Go look at how much money different people had to do chip development in the 90s.

If you install EMWM and the goodies from the author's page you can get a very close system. Also, some guy at Nixers.net it's trying to recreate the whole Irix interface under EMWM.

https://fastestcode.org/emwm.html

Also if you want to program something in Motif:

Motif prog. manual https://www.oreilly.com/openbook/motif/vol6a/Vol6a.pdf

Motif reference manual https://www.ist.co.uk/motif/download/6B/6B_book.pdf

For the X11 books, current X.org manuals are easily found under X.org docs and they will work nealy the same. Now they promote xcb instead of xlib but xlib itself still works.

You'll might (not sure) need:

- Xmu.pdf XMU, low level

- intrinsics.pdf X11 inners, useful to debug X11 stuff

- icccm.pdf Basically window manager standards

- libXaw.pdf Athena/X11, if you need something lighter than Motif

For instance, you can create some MPV frontend with XEmbed and Motif. MPV can be controlled by sending commands to a socket, and creating a GUI for it can be first prototyped with TCL/Tk and then done with MPV.

There's a Linux version.

https://docs.maxxinteractive.com/

I do not know of a single distro that includes it, but then, this may be because I think it's not 100% FOSS.

I disagree, due to NeXTSTEP and Sun NeWS/OpenLook.

However I do agree those three were the only UNIXes that I actually enjoyed exploring/researching as desktop experience.

Irix did have a very nice and flashy desktop, but compared to bsd or even linux the underlying unix system was... a bit off. and I don't think this was just familiarity with bsd, solaris felt the same way.

I think it is the dynamic pressure of a commercial closed source unix vs a community source available unix, where the commercial unix is pressured to maintain compatibility and thus also maintains a ton of old footguns. The community unix allows itself to file them smooth and become more ergonomic over time. At the cost of being incompatible. However compatibility is not as much as an issue because you have the source for most of your programs, it is much easier to adapt to incompatible changes.

Wonder what internal process at SGI made it less acceptable to fix the defect than to resort to relying on a community developed workaround. They were expensive, premium machines. Seems like image alone would be reason enough to fix something once it got to the level of someone from the outside developing a workaround.

I used this summer pyFLTK for providing a configuration GUI.

I enjoyed it a lot.

That’s a problem but I can somewhat understand. One SGI workstation was not their strength. My memory is that while they had Netscape, there was no LibreOffice (StarOffice at the time). No consumer apps to speak of. One had to hope for FOSS apps to get ported, and check their package manager site occasionally for updates.

The web would eventually take over most things, but not for a decade plus, and we didn’t know for sure. By that time the hardware would be obsolete. :sad-trombone:

For a while it was like living twenty years in the future though, if your profession revolved around graphics.