I contacted SGI in their later years when my department had a little extra budget. Knowledgeable guy on the phone tried to talk me out of buying one of their workstations. They really were only interested in selling to a certain type of customer. Innovative, flashy, and desirable products for a hot minute, but that company was managed to death. Apple beware.
SGI hosted the initial C++ STL documentation, as such I used to regularly visit their site, and also dive into Irix documentation dreaming of such systems.
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. where 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. so it is much easier to adapt to incompatible changes.
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.
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.
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.
Unsung heroes perhaps but don't underestimate the impact of Dell, ie "x86 getting good enough" was more than just about clock speed and branch prediction type stuff. Mass production of x86 servers killed Big Unix as much as advances in the chips.
After all, Unix on x86 was very widely deployed thanks to SCO, who had a lock on the retail POS and store backend type of IT, but who ran on PCs that were not what we would call servers today.
However once Dell mastered volume production of servers to similar build quality as the Sun SS20 pizza boxes at a fraction of the cost, they had the runway to build bigger and better servers and it was all over for Big Unix.
This isn't a Dell post, but they offered both Dell Unix and Solaris for a time, before Sun tried to fight them off with Cobalt rack servers. But it was too late.
You’re making me pretty nostalgic. I helped maintain a SCO “beefier than a desktop but cheaper than a server” server that ran a clothing factory’s serial terminals for years. And I had a Cobalt Cube :)
Ah yes, IRIX. My biggest recollection of it was being annoyed that they had a bug in updating the utmp file correctly, so that it would sometimes leave users in it that were no longer logged in the system. I wrote a quick and dirty cron job hack that would compare the utmp to the wtmp entries once a minute and delete any stale users it found, and I posted it to usenet for anybody else annoyed by the issue. I was surprised a while later to see that rather than fixing the bug, SGI employees were recommending people install my dirty little hack.
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.
My guess would be that it's a split between employees in support (where being helpful to the customer is the aim and suggesting workarounds is part of the job) vs development (where it was almost certainly acknowledged as a bug but had to be weighed up against every other bug and feature for priority). Bugs with known workarounds which only affect a small slice of users are often not fixed very quickly.
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.
You are of course correct. I also use XFS and not on Red Hat distros. That said, XFS is the default filesystem on RHEL since RHEL7 and I think it was the first major distribution to make that choice. Even today, both ext4 and btrfs are far more common choices.
Red Hat is probably the biggest contributor to XFS at this point as well.
You and I might have a different understanding of the word recent, but RHEL 7 is over ten years old, and Red Hat itself was one of the first companies based around Linux.
Red Hat has had this project for a while to give XFS (a traditional journaled filesystem) the features of "3rd generation" filesystems like ZFS or btrfs (i.e. checksums, snapshots and deduplication). That's mostly glued together using LVM and new LVM addons like VDO, but also new work in XFS itself like reflinks, metadata checksums etc. To me it seems like Red Hat lost faith in btrfs in the RHEL 7 time frame and that's why they dropped it from Tech Preview status.
SGI's Forms programming toolkit led to both XForms:
http://xforms-toolkit.org/doc/xforms_1.html#Preface
(The original basis of the Xfce desktop -- "XF" stood for XForms.)
And the FLTK toolkit:
https://www.fltk.org/doc-1.1/intro.html
FLTK dropped a new version last year after a gap of 13 years, which I wrote about:
https://www.theregister.com/2024/11/26/fltk_14_released/
I used this summer pyFLTK for providing a configuration GUI.
I enjoyed it a lot.
I contacted SGI in their later years when my department had a little extra budget. Knowledgeable guy on the phone tried to talk me out of buying one of their workstations. They really were only interested in selling to a certain type of customer. Innovative, flashy, and desirable products for a hot minute, but that company was managed to death. Apple beware.
SGI hosted the initial C++ STL documentation, as such I used to regularly visit their site, and also dive into Irix documentation dreaming of such systems.
Before the advent of Mac OS X, Irix definitely had the best looking, most consistent and most usable GUI of any Unix system.
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. where 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. so it is much easier to adapt to incompatible changes.
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.
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.
I really appreciate the help.
Personally I find libxcb is better for bindings.
Unfortunately I mostly use my work Windows11 laptop and I think lack of Motif is a big omission.
But o lot of X libraries work under Windows too.
I've wondered why MIPS didn't conquer the high and the low.
The difficulties of the instruction set might have had a hand.
https://www.jwhitham.org/2016/02/risc-instruction-sets-i-hav...
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.
Unsung heroes perhaps but don't underestimate the impact of Dell, ie "x86 getting good enough" was more than just about clock speed and branch prediction type stuff. Mass production of x86 servers killed Big Unix as much as advances in the chips.
After all, Unix on x86 was very widely deployed thanks to SCO, who had a lock on the retail POS and store backend type of IT, but who ran on PCs that were not what we would call servers today.
However once Dell mastered volume production of servers to similar build quality as the Sun SS20 pizza boxes at a fraction of the cost, they had the runway to build bigger and better servers and it was all over for Big Unix.
This isn't a Dell post, but they offered both Dell Unix and Solaris for a time, before Sun tried to fight them off with Cobalt rack servers. But it was too late.
You’re making me pretty nostalgic. I helped maintain a SCO “beefier than a desktop but cheaper than a server” server that ran a clothing factory’s serial terminals for years. And I had a Cobalt Cube :)
The R3000 had a moment in the sun, it was used in everything from SGI and DEC workstations down to the Sony PlayStation.
Should've made it into a long-playing laptop, imho...
Ah yes, IRIX. My biggest recollection of it was being annoyed that they had a bug in updating the utmp file correctly, so that it would sometimes leave users in it that were no longer logged in the system. I wrote a quick and dirty cron job hack that would compare the utmp to the wtmp entries once a minute and delete any stale users it found, and I posted it to usenet for anybody else annoyed by the issue. I was surprised a while later to see that rather than fixing the bug, SGI employees were recommending people install my dirty little hack.
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.
My guess would be that it's a split between employees in support (where being helpful to the customer is the aim and suggesting workarounds is part of the job) vs development (where it was almost certainly acknowledged as a bug but had to be weighed up against every other bug and feature for priority). Bugs with known workarounds which only affect a small slice of users are often not fixed very quickly.
It's what they use in Jurassic Park.
The 3D file manager is fsn.
https://en.wikipedia.org/wiki/File_System_Visualizer
Regular advertisement for my fork updated to Gtk+3 and core OpenGL 3 at https://github.com/jabl/fsv
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.
IRIX, it has to make a come back.
It would be so nice to have an SGI laptop that gave Apple a run for its money.
Like the good old days.
Red Hat's XFS file system originally came from IRIX.
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..
You are of course correct. I also use XFS and not on Red Hat distros. That said, XFS is the default filesystem on RHEL since RHEL7 and I think it was the first major distribution to make that choice. Even today, both ext4 and btrfs are far more common choices.
Red Hat is probably the biggest contributor to XFS at this point as well.
So, I kind of get the comment.
> That said, XFS is the default filesystem on RHEL since RHEL7
RHEL is quiet recent.
Linux itself is only nine years older than RHEL. I think you might be operating on a different scale of recency than most.
You and I might have a different understanding of the word recent, but RHEL 7 is over ten years old, and Red Hat itself was one of the first companies based around Linux.
Red Hat has had this project for a while to give XFS (a traditional journaled filesystem) the features of "3rd generation" filesystems like ZFS or btrfs (i.e. checksums, snapshots and deduplication). That's mostly glued together using LVM and new LVM addons like VDO, but also new work in XFS itself like reflinks, metadata checksums etc. To me it seems like Red Hat lost faith in btrfs in the RHEL 7 time frame and that's why they dropped it from Tech Preview status.
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.
As well as OpenGL, originally IRISGL, See for example,
Unfortunately the actual cool part, Inventor, wasn't part of it, and took several years until OpenInventor came to be.