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.
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.
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.
That, and it's been developed in fits and starts. There was like a year where the primary (and AFAICT only) developer lost access to the domain name he was using.
I had this installed on an old X220 running Fedora and it was fun, but I wouldn't dare run it on anything that I needed to work day in and day out.
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.
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.
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 :)
MIPS CPUs were showing up in consumer networking gear for quite some time. I was a little bit sad that I couldn't run Irix on one of my last routers given that it had a faster CPU and more memory than any Indy I ever owned.
My undergrad email server at University of Rochester was a two node SGI origin 200 cluster, which is where I learned unix and C, and later in my career, through a series of amazing coincidences, had the honor of working at startups with a few of the UofR sysadmins who used to chase my hacker friends and I around their network.
IRIX has an amazing and indelible place in my heart for being the playground that taught computers to me.
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.
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.
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.
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.
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.
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.
Before the advent of Mac OS X, Irix definitely had the best looking, most consistent and most usable GUI of any Unix system.
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.
Back in the day you could have a X client environment with Hummingbird.
Still around under a new name.
https://www.rocketsoftware.com/en-us/products/remote-access/...
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.
That, and it's been developed in fits and starts. There was like a year where the primary (and AFAICT only) developer lost access to the domain name he was using.
I had this installed on an old X220 running Fedora and it was fun, but I wouldn't dare run it on anything that I needed to work day in and day out.
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.
Probably fair re: NeXTSTEP, as I never had a NeXT to play with.
Next was cool, but openlook fugly!
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.
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.
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 :)
MIPS CPUs were showing up in consumer networking gear for quite some time. I was a little bit sad that I couldn't run Irix on one of my last routers given that it had a faster CPU and more memory than any Indy I ever owned.
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...
Go look at how much money different people had to do chip development in the 90s.
My undergrad email server at University of Rochester was a two node SGI origin 200 cluster, which is where I learned unix and C, and later in my career, through a series of amazing coincidences, had the honor of working at startups with a few of the UofR sysadmins who used to chase my hacker friends and I around their network.
IRIX has an amazing and indelible place in my heart for being the playground that taught computers to me.
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
FSV is fun, I used to run it occasionally 20 years ago on my Linux desktop.
Nice to see it updated.
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.
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.
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..
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.
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.
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.
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.
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.