Old versus new, and why SGI?

Elf

Storybook
Feb 4, 2019
336
76
28
Discussion on this thread and previous ones in the chat have made me think once more about the "old versus new" paradigm in the community.

Originally the User Group was founded out of ex-IRIX Network members because people were getting criticized and harangued for not following the one true path of SGI software development, and they wanted a space to be able to pursue their own projects in a more supportive environment. I think it sometimes appears to people though -- with the human propensity for tribalism -- that we just formed another camp, e.g. the GCC camp vs. the MIPSpro camp.

I certainly hope this is not true. I think the ideal behind the User Group is that we are just happy that anyone is constructively turning on, using, fixing, and enjoying SGI hardware. Some people enjoy porting modern software with a GNU tool chain so that IRIX can become more of a "daily driver" environment. Some people enjoy using the original tool set and having a more authentic environment. Some people might want to run Linux on their SGIs or develop new Linux device drivers for the hardware. Some people just want to install software that other people have ported, and some people want to do everything from scratch themselves even though it means duplicating effort. Some people might even find it interesting to develop a new operating system entirely, or to use an Indy for home automation, to figure out old power supplies (;)) or any number of things!

I think the important thing to remember is that everyone has their own particular interest in these machines or their own particular nostalgia for SGI that draws them in. Their interests and nostalgia are likely slightly different than everyone else's. @onre recently remarked that he would not mind running Linux or BSD on SGI hardware if it had better hardware support, but from myself, I would still run IRIX because I enjoy the 90s commercial UNIX workstation experience and aesthetic. As someone pays for non-GCC compilers for embedded development (RL78 etc.) I understand the inclination to be biased against GCC, but I am also not one of the people trying to port a modern browser or GTK 3.

If a GCC user suggests GCC to someone else struggling to get something to compile using MIPSpro, I don't think that should be viewed as SGUG being "GCC only" or "hating MIPSpro," both things I have heard from actual users. It's just one person trying to help another by saying how they solved similar issues. But they may not consider that someone is using MIPSpro for other reasons not stated.

This isn't a reprimand and I hope it doesn't turn into just a monologue with no replies. What people are doing is okay! Both the divergent projects they pursue as well as the minor conflicts they run into with people who don't see things the same way. I think it would be interesting, though, if people thought about and posted about why they use SGI and what draws them to the platform.

What do you enjoy about SGI machines and how does that drive what you do with them? I'll post my own view after a few others add their stories :)
 
  • Like
Reactions: foetz and stormy

drmadison

New member
Jun 30, 2020
15
8
3
I'll start by saying that I feel personally attacked, as you didn't mention people like me, the masochists who insist of trying to make new software for these old machines using the original toolchains because for some reason we're warped enough to find that "fun" :p

Seriously though, it's important to remember different people are allowed to like different things about our shared hobby.
For me, I got into SGIs in the early 2000s, when they were still being made brand new and how amazing they were. I started with nekochan in 2003 and fell in love. I worked in the game industry, particularly working with game consoles, a huge portion of my adult life and for me it was a mix of playing with computer hardware that was closer to what console hardware was like. And the history. And just the cool factor - nothing else looked like an SGI. Back then I wanted to use one regularly and eventually got my chance.

Now, here I am 17 years later, I find something different that appeals to me. They harken back to a "better" (read: older) time in computing. Here were these crazily advanced machines, that were still at the point where you could largely understand how all of the pieces worked. 4DWM has a charm to it. So now I decided what excites me is getting my SGIs to the point where I can use them as a daily driver so to speak. And yes, there's a software gap if I want things to "feel native" but that just means I make the software I feel is missing. So I've made a little motif-based IRC client. And I'll be making a little mail client for myself. And I've toyed with the absolutely insane idea of making my own web browser. These are all things I can do purely for me, and they only need to work well enough that I want to use them. The fact that there is no other "easy" option pushes me to create, and for me that's fun. Especially in a purely selfish environment where it only has to make me happy and there is no customer to demand things, or bosses to dictate priorities.
 
  • Like
Reactions: Elf

nuclear

New member
Jun 3, 2020
10
10
3
nuclear.mutantstargoat.com
It never crossed my mind that there might be "camps" of old-style vs new-style UNIX tools. It's all UNIX in my mind, with different degrees of "nice features". It's a continuum. For me GNU is the currently active thrust of UNIX development; the community with the most people hacking on tools. So from day 1 when I got my first SGI machine sometime around 2006, the first thing I did was to replace everything that I could replace with new GNU equivalent tools, because it seemed like the obvious quality of life improvement.

So I use bash because I can't stand C-shell, GNU ls for the nice color coding, GNU tar for the nice decompress flags, and GCC, because I can't be bothered to muck around with licenses for proprietary nagware. For me it's an affront and an insult to not provide by default a ready to run C compiler on a UNIX system, so I can't stand for that. I don't bother making my makefiles compatible with non-GNU make, because I enjoy the GNU make features.

But I don't change the window manager. I kinda like 4Dwm even though it's strictly worse than fvwm which I use on my main computer, and I don't see a point in installing GNU/Linux on it, because then what would be the point of using the bulky loud octane rather than any of my GNU/Linux PCs.

But that's just where I draw the line between usability and a unique experience. It seems obvious to me, that other people might prefer to draw the line at different spots. Can't fathom why this would ever be a point of contention.
 

austinramsay

New member
Jul 18, 2020
9
6
3
What I find interesting the most about the SGI hardware is the engineering and uniqueness of it for a niche market. The same things also interest me in Sun hardware although they target a wider audience, they were usually targeting power users seeking high performance. It seems that now most computer manufacturers just try to target the widest market they can without actually specializing in anything. They all use the same hardware basically across dozens of different brands. Of course now we have way faster and more efficient hardware but it's nice to enjoy the old special hardware for what it was. I'm 24 years old and can see that I really missed being able to enjoy the fast-paced world where computers were exciting and innovative back in the 90s and of course the 80s. Yes, we are still moving forward and innovating today with some amazing technology that blows my mind but like I said it's just very generic.
 
  • Like
Reactions: Elf

hammy

Active member
Jun 1, 2019
106
59
28
UK
If a GCC user suggests GCC to someone else struggling to get something to compile using MIPSpro, I don't think that should be viewed as SGUG being "GCC only" or "hating MIPSpro," both things I have heard from actual users. It's just one person trying to help another by saying how they solved similar issues. But they may not consider that someone is using MIPSpro for other reasons not stated.
This is a good point, and if you (dear reader) don't mind indulging me for a few minutes, some background may be useful to explain "how we got to where we are today" (point-of-view SGUG-RSE, gcc, why not MIPSPro etc).

Up until relatively recently (back in the nekochan still alive days), the only "premade" packages you could get hold of were the nekoware builds. Time had not been kind to them - with quite a few outdated packages - and in some cases outright broken packages due to half-done upgrades (emacs + libtiff being my tipping point).

I personally started + maintained a repeatable build tree of software made with MIPSPro - based on almost-up-to-date versions of things like perl, openssl, autotools, sed etc. Other efforts were ongoing at that time either to try and drag nekoware a little more up to date, or to provide "tarball" downloads of more recent tools.

A new effort was started to see what it would take to get a more recent GCC up and running by some members of SGUG here. It was a bit raw, but it showed promise - and it showed that _maybe_ we could get something to advance a little the C and C++ support on IRIX without the bugs of MIPSPro. I don't have a list of those MIPSPro bugs offhand, but if you look through the DIDBS packages looking for things that aren't "-O3" optimised for MIPSPro - it's because of optimiser problems. The patches in there can reveal other issues too (like static initialisers not conforming to C99).

But back to GCC. Further effort was put into the more modern 8.2, putting back IRIX support, fixing long standing bugs in configuration, or header rewrites. Updates to get newer binutils were made too, and we got C++ exceptions working again. Eventually we arrived at a place where GCC was now able to build and run modern software that simply cannot be built with MIPSPro without rewriting the entire thing.

Once the GCC based toolchain was "good enough" - the DIDBS project was released in "dual toolchain" mode for a little while - you could download either a full set of tools built with MIPSPro - or the same set of tools built with GCC.

What became clear (to me, at least) during this time:
  • Mixing of MIPSPro and GCC built software is a house of cards - there are various incompatibilities between the two toolchains that mean you might "get away" with building some bits with MIPSPro and some bits with GCC - but you'll hit a roadblock you can't get past at some point
  • MIPSPro development / maintenance had a significant overhead compared to using GCC (bugs, working out what optimisation level wouldn't cause problems, having to find version X before they started using thread local etc)
  • MIPSPro began holding back the incorporation of newer more modern tools
So at one point DIDBS went GCC only, purely to be able to start to include more modern tools.

This is why (certainly for myself) when someone asks "I'd like to build PACKAGEX on IRIX" - I'm going to say - choose one toolchain (MIPSPro/GCC) - and stick with it. If your software requires more modern language constructs, you'll be wanting the GCC toolchain.

This is not say that the GCC toolchain is perfect, by the way. It isn't. We've still got some fundamental bugs and missing functionality that make working with GCC painful too. Out of the frying pan into the fire, so to speak.

But here's the thing -> there aren't any fixes or updates coming for MIPSPro. If that works for you, that's great!

At the end of the day, this is a hobby platform for people to tinker and indulge in a bit of nostalgia - so fire em up and do whatever it is that gets your juices going. My goals are perhaps not yours!

Enjoy.
 
  • Like
Reactions: Elf

drmadison

New member
Jun 30, 2020
15
8
3
The MIPSPro optimizer problems are real btw. Not everything gets broken (more things don't than do) but when they do break, it can be incredibly frustrating to track down.

Personal experience from oh, a few days ago. I built bash 5.0 on my O2. Built fine, been running it fine. And then I tried to run a configure script for another project. And the WEIRD errors starting coming in. Turns out compiling bash with -O3 broke command substitution in bash. So all of those scripts that do things like
Bash:
X = $(echo whatever)
just failed in a super weird way (the first character of the command would be cropped off, so echo because cho). It took me hours of stepping through my build to make sure that one of the changes I made to get bash working (which after digging through diffs turned out to be basically none...) and only when I started littering debug printfs in the code and the bug magically went away did it become clear - the optimizer got me.

Now In a programmer by trade, and decided I'd stick with the "old way" and go with MIPSPro because I tend to know enough to work around the changes needed. Hunting down weird issues is fun for me. I also don't plan to run a lot of up-to-date software on my O2, just a few quality of life things (latest bash, vim, modern SSH, gmake) and beyond that anything I'm compiling is code I wrote myself and so it compiles clean.

If you want to write your own software, MIPSPro is a perfectly valid path to take. Or if you just want to build a few things and know enough to get your hands dirty it's great.
But if you're not experienced with C/C++, and just want to take open source projects and get them building, the GCC route is infinitely easier.
 
  • Like
Reactions: Elf

TruHobbyist

New member
Jul 27, 2019
6
3
3
When porting software, its easy to relate compiler/linker flags across different platforms (like -c, -o, -l, and so on). When it comes to optimizations though, it's a different topic and one should be very conservative with his own assumptions about it. From my experience, one of the pitfalls on this type of machines (RISC with proprietary OS and toolchains) is using any optimization at all from the very beginning of a porting process. The way that worked for me is:

Port without optimizations (repeat compile, test, debug) umtil it works. And only then try applying optimizations starting with the less invasive ones (-O1) upto the most aggressive (-O3).

The aim should be -O0, and only in very small number of cases should this be changed.


The list of packages that break just because of optimization levels higher than -O1 is long. Optimizations, by definition, do not introduce bugs. But they may because of its implementation (heuristic algorithms).

I recommend the following lecture (pages 67-126):



Tru
 

foetz

Member
Feb 19, 2019
68
33
18
in regards to the optimization issues, these should probably be put a little into perspective.

i've literally compiled thousands of programs with different mipspro versions. including heavyweights like the mozilla product line. i've used that stuff myself on a daily basis and some of it even ran in hpc environments under heavy load. i've always used -O3 and the number of problems i ran into which could be tracked down to the optimization level was in the 0.x% range.
this very post here right now was sent through a proxy running on irix which was built with -O3 and so were all its dependencies. all of that has been running for close to 10 years now and i never had a single issue.


now before the nit-pickers start jumping at me, i'm not saying these issues don't exist. but it's important to clarify that they rarely come to pass.
 

mgtremaine

New member
May 3, 2020
25
12
3
San Diego, Ca
www.stellarcore.net
I agree with the it's your system do what you want with it.

My own tendency is to follow the solutions with the most "eyes" and "hands" supporting it. I'm not a C/C++ programmer but I have enough years of sysadmin across multiple architectures to get things built and working. MIPSpro was the default for nekoware and that was great. But the years have passed and the number of people doing MISPro builds has dwindled, we now have a handful of high competent people but it is still only a handful. If GCC gets more "eyes" and "hands" and it works. well good enough for me. I have single 300mhz O2 in the house (and it's not even technically mine since I bought it for my son for Easter when he was 7 - 13 years ago.)

I do appreciate everyones efforts to keep IRIX running and my interesting arguing about merits and values of different approaches is exactly... zero.

-Mike
 

stormy

Member
Jun 23, 2019
32
12
8
Personally I'm not some old school programmer like most of you guys. I'm a computer enthusiast who was a teenager in the '3D explosion' of the late 90's, where Nvidia, 3Dfx, Matrox and ATI (and a few others) battled it out. Probably the first generation of kids that bought computer magazines to see the latest graphics reviews rather than motorbikes or... other things ;)

Anyway, I found myself to be very interested in OpenGL specifically. I loved how ID software engine games like Quake showed you all the gory driver details, all the GL extensions, my little 16 year old brain was amazed by it all. I loved playing with different GL drivers, swapping my ICD client drivers, testing versions, performance benchmarking etc. Those days were so much more amazing, each company had a slightly different rendering style and technique, meaning the graphics output looked very different from each other - unlike today where you cannot tell the difference between an Nvidia screenshot vs AMD.

I've been trying to learn, very slowely, and with much support and help from others around me how to port software and Sgug. I have gone from zero unix knowledge to installing Irix on my Octane with booterizer (thanks Unxmaal) to installing Sgug (thanks hammy, massiverobot, jupo, onre, unx, etc etc everyone in porting channel) My aim? Although blasphemous, eventually I want the knowledge and skill to compile open source games that support Irix GL 1.1. I just think games (although offensive to some diehard unix people) are a great community builder, we all like some enjoyment. And experiencing the beautiful 3D our machines were so famous for, letting them entertain us and flex their OpenGL muscles is what excites me.

What makes SGI unique in the unix workstation world? 3D. OpenGL is their lasting legacy. Why just port a web browser, chat program or office software when you can do that on Sun hardware? Why leave that beautiful 3D OpenGL hardware to languish.

My first game I would like to port would be Homeworld. Its source code was released recently after a nice developer acquired the rights and created the remastered version. It is a 3D OpenGL space tactical RTS, with beautiful visuals, music and story. If anyone wants to help me along the way it is appreciated.
 
Last edited:
  • Like
Reactions: omljud and Elf

Elf

Storybook
Feb 4, 2019
336
76
28
Thank you for all the stories; now I will add my own as promised!

:4dwm-mic-1:

I grew up around commercial UNIX workstations in a university environment. Some of the first computers I used were the classic Sun SPARCstations (1-20) and all-in-one X Terminals like the SPARCstation SLC, as well as using SunOS 4.x remotely via amber screen DEC VTs and dial-in from lab machines. It was a while before I got my first computer at home (a 486DX2 66MHz PC), so I suppose I had much the opposite experience of most people during that era.

During the mid-90s I was an early adopter of FreeBSD, and then later Slackware Linux. At the time Linux was not such a well accepted phenomenon, and I remember all the business magazine publications amazed or even derisive at the concept of people using a free operating system in a business. It was quite scary at the time to run these alternative operating systems at home, having to (usually) completely destroy the working DOS or Windows installation on my only hard drive, on my only computer, to use an OS that didn't "just work" with all the games, applications, and Office documents from school and friends running Windows or MacOS. I remember very well the time that Linux decided to transition from libc5 to glibc, with my CD-ROM based upgrade leaving the computer quite unusable, and in the middle of a week-long school project. Needless to say, my assigned partner on the project was not very understanding about my choice in operating systems.

Of course being familiar with the commercial UNIX ecosystem from early on, SGI eventually caught my attention; not even necessarily as graphics workstations, but just as another new and exotic type of UNIX machine alongside the Suns, DEC Alphas, and HPs. It was during high school and needing a new home computer that I almost, but not quite scraped together the money to buy the then new (and expensive) SGI Visual Workstation 320, ending up with a high end Dell instead. And later when I saw the advertisement for the very visually unique Tezro along with exclamations of it being able to process and edit 4K video, now that Hollywood was moving to Digital Intermediate workflows and long before 4K was a consumer buzzword.

The first SGI I ever bought was an Origin 200 in the mid-2000s, and later I did some business with Reputable Systems back when they were still around. Around that time I also kept up with Nekochan (but never registered until much later, in 2016).

Why do I like Silicon Graphics machines in particular? I think for me it was always the combination of the unique hardware architecture and visual design of the machines. They represented the creativity and ingenuity of an engineering team unleashed to create things that other companies wouldn't. For example, a read-through of the Octane's specifications in the early 2000s was my first, personal introduction to crossbar switching, though it was hardly a new engineering concept.

Although Silicon Graphics was deservedly known for their pioneering work in computer graphics and high performance computing, oddly by the time I started buying them I never really cared much about their graphics performance, or indeed even about the machines' performance in general! I was much too used to running NetBSD on a SPARCstation 1+ with a SLIP connection to the outside world, as my retro-UNIX experience. Trying to assemble the fastest SGI is, to me, sort of like trying to win the "world's tallest midget" competition when set against the backdrop of the brute force we have on tap today with multi-core machines, GPGPUs, and AWS, or even just cheap ARM microcontrollers. It couldn't bother me less whether I have a V6, V10, or V12 in a machine, and in many ways an Indigo 1 is more interesting than a Tezro.

Just exploring their uniqueness, especially from a hardware perspective, is enough for me.

I think that also taps into what motivates me to continue using SGIs and participating in the community. I have a wealth of software and UNIX knowledge on hand just from what I have chosen to do with my life, but unlike our wonderful SGUG-RSE team, and very unfortunately (since I am all too aware they could use extra manpower), I just don't find that side of things all too motivating! I would much rather spend my time exploring and interfacing with the hardware side of these machines. With that, I also have to start simple. Everyone has seen the power supply projects, I am sure. I would find it awfully neat to make my own GIO32 card for an Indy, or more keyboard, video, and other HID accessories. I very much doubt I will ever have the time to interface with things like the Octane's crossbar bus that taught me so much a long time ago, but I certainly have enough to keep my attention for the foreseeable future. :)

:4dwm-chest:
 
Last edited:
  • Like
Reactions: mgtremaine

mach_kernel

Administrator
Dec 26, 2019
11
4
3
New York City
github.com
The first time I've ever touched a UNIX machine was a Sun Ultra 5 pizza-box on a DSL line. I had only used Win 9x up to that point in life on consumer PCs with 800x600 resolution and such. It was crazy to see a huge display and fast internet and the ability to do like two things at once without BSOD or plug and play gore.

I wanted the same kind of setup at home and then found out about Linux, and started with a Knoppix live distribution and later set up Slackware. I used to be on some levels a Windows power user: had all my warez, AV, services, auto defrag, etc set up to as much of a science as one can achieve. It was annoying to maintain. Linux never was painful in those ways (other than, back then X autoconfig wasn't a thing, and it took a lot of time to learn some things), and the amount of awesome free software was astonishing. I was like 13, it was cool to download a high fidelity planetarium and open source Lego Mindstorms drivers that let you try coding a robot in something like Ruby! It was great.

Fast forward many years later, I went to school for CS and ended up working as a software developer. I wanted something challenging to do, where StackOverflow doesn't save you. For a lot of web development, you're gluing pipes. I got my first SGI and started to try building software on it with the Neko GCC (because I found installing any package, let alone MIPSPro to be daunting (the SW manager seems very foreign and unintuitive to someone used to apt/yum)). At the time I think a bunch of us just fell into a chatroom and then we all of a sudden had forums and all of this stuff happening. It's cool to see that UNIX principles and design mean that even with some work, these machines can run new software. I am a total newbie and managed to build Ruby 2.5x (albeit, with broken sockets), because of a ton of Google showing you that "on old UNIX, you can do this instead". It's all out there!
 
  • Like
Reactions: Elf

LarBob

Administrator
Feb 8, 2019
34
11
8
I don't think I have a super interesting story. I have been interested in retro/vintage computing for as long as I can really remember, starting with vintage PDAs as a young child. Somehow I learned of SGI and Nekochan and thought the hardware was super interesting. I obsessed over it for a few months until I finally found an Octane on eBay (and proceeded to have to basically replace everything in the machine after getting it... :D).

I really enjoy reading about the hardware as well as tinkering on the software side of things. I think 4Dwm is a compelling UI and much more enjoyable than contemporary DEs (CDE). The idea of UNIX workstations with such a relatively large cult following was also very appealing. Plus, we have the Jurassic Park thing in SGI land ;)
 
  • Like
Reactions: Elf

About us

  • Silicon Graphics User Group (SGUG) is a community for users, developers, and admirers of Silicon Graphics (SGI) products. We aim to be a friendly hobbyist community for discussing all aspects of SGIs, including use, software development, the IRIX Operating System, and troubleshooting, as well as facilitating hardware exchange.

User Menu