While ArcInfo was certainly supported on Irix I'd venture a guess and say Erdas Imagine for "heavy lifting" raster. Remote Sensing was such a fun class.
Agreed. Holy cow did I have fun in my remote sensing classes. I'll still remember learning about false color composites from landsat ETM+ data. The first time vegetation just popped out and I was hooked.
My guess is on Erdas Imagine too.
That or some more programmatic stuff like an OGR/GDAL pipeline.
Instead, you should netboot them, and run nfsroot; works with irix so I suspect it will work with linux; dhcpd will inform of the tftp location of the kernel and pass the right parameters, should be doable and faster, more reliable. Now what I wonder is if X11/Xorg supports any of these framebuffers.
I've seen SCSI adapters of many types - SD card ones as well, don't have any direct product I could link, google pulled up many avenues - including this: https://www.crucial.com/usa/en/upgrades/sgi-%28silicon-graph... though didn't see SGI on list, so hard to rabbit hole that one without using live chat perhaps and may well be a legacy placeholder that time forgot.
Though network booting and storage may well be an easier avenue and cheaper. If you already have a NAS, that may well be the easiest path.
There are also Fibre Channel adapters for these if you have the XIO-PCI card cage. Can boot from it with some special magic IIRC, but a local SCSI drive is fine for most things.
Actually IRIX works with old Adaptec PCI FC cards, but to get it running you need to recompile the kernel with some arcane, undocumented parameters. Back then when I was a regular of comp.sys.sgi.* newsgroups, Alexis Cousein gave me the trick and saved my day when my official SGI card died.
Now that's a name I haven't heard in a long time...
It might have actually been Adaptec PCI in an SGI XIO-PCI card cage, memory is failing me. Definitely some dark magic required on Irix and on the FC switch and storage target side.
Yes, that's right. I had an XIO FC board in my O2000 that died, and I had spare Adaptec FC PCI cards for PCs. I had previously noticed that the SGI PCI FC cards for O2s or O200s were actually the same as the Adaptec, physically, but with an SGI ROM.
So after my XIO FC board died, I added an Adaptec board to my O2K to get my RAID array back online (the whole company was out of work because of that failure).
However though the card appeared in "hinv", it didn't work... After I asked for help on the newsgroups (the system was out of maintenance...) Alexis sent me a private email with the necessary invocation of the kernel rebuild command, and it worked like a charm from there.
Been wanting one of these machines for years, but they are sooo pricey it is insane. Mainline Linux support will be good, but I tbh I would be running IRIX as intended.
That is an interesting problem. In the 00's they were cheap and plentiful. Buying old SGI hardware to play with was pretty affordable. Now people want thousands. Same with old x86 hardware.
Older x86 hardware is incredibly cheap and plentiful in my experience. Of course stuff goes up in price as it ages and gets rarer, but that's just expected.
That is more true of old x86 hardware and older micro-computers (Amigas, Ataris etc).
The SGI machines are difficult to get hold of in the UK to begin with plus they are as other said short supply. There is one Octane in the country and it is the machine only (even though the monitor and keyboard are pictured) and it is going for about £800 on ebay.
If it was everything I would have said "that probably the best deal I am going to get" and went for it.
In the late 90s a lot of these machines were being abandoned. Properetary Unix was dying due to Linux, and non-intel CPUs were also getting crushed. Plus there was the dotcom crash meaning defunct companies got rid of gear.
In those days I got an extremely cheap Sun workstation on ebay as an example.
Anyway, I guess supply is low but there are still nerdy people who think an old Unix machine is cool. (I'd take one running Irix just to play with for sure.)
I believe they are used in certain models of CT scanner, MRI or some such expensive medical equipment. That probably drives at least some of the demand.
I think it's just low supply. They were quite expensive so not that many existed to begin with, and then the last generation of SGI MIPS machines were largely cleared out by companies and academia in the mid-late 2000s. Anything left for sale now is either from hobbyists, surplus sellers hoping to cash in on the few niche markets that still use these, or just really late clearouts.
I bought my Octane on eBay in 2008 (it was previously used at Ford), I think it was around $80 and shipping was more than half of that (an Octane weighs ~80 lbs).
I had two Octanes in the mid 00s. One of them got damaged by a water leak and the other I sold for £5. The 21 inch Trinitron CRT I had with it sold for £20!
I remember saving for what seemed like an eternity, then buying a used (and only slightly defective) Trinitron from a friend's dad (who was a draughtsman) round about '97.
I don't recall what size it was, but the point was it was big for the day, like 24" - it was so heavy that me and my dad could barely lift it! When we got it home, it bowed my wooden desk in a very threatening way, but managed to sit there for a couple of months before it finally broke through the desk!
When I finally got rid of it round about 2010, it was still working as it always had. But it was hard to justify keeping that massive, heavy box around forever (IIRC, it was something like 40kg!)
It seems to be my understanding that Linux will allow supporting any hardware or software API as long as at least a few people care about it. It doesn't matter how old or impractical it is.
This is not a criticism, but I would like to deeply understand, what does Linux leadership want it to be? An OS that just runs on anything for the sake of it?
It already seems true that Linux aspires to be much more than what UNIX is. It can be a dumping ground of sorts for your ideas and research projects. As long as the code does something useful enough without corrupting the entire system, it seems to be fair game. That is kind of freeing and it would stand to benefit the project to be communicated more directly. These are my observations.
> It seems to be my understanding that Linux will allow supporting any hardware or software API as long as at least a few people care about it. It doesn't matter how old or impractical it is.
It's not quite like that, there's quite a bit of hardware support that has been dropped along the way. It's not enough for people to care about stuff, they have to care about it enough that they maintain that support in line with kernel devs' expectations. That's not always easy.
A counterexample would be that most other open source Unixes' "MVP-level" of hardware support meant that none of them gained much traction and market share. The real world does not run entirely on Thinkpads.
More to the point, the real world doesn't run entirely on Real Computers.
It happens again and again:
There's a plateau of Real Computers, where Real People do Real Work, because they wouldn't deign to deal with the oddities and lack of performance peasants put up with on their Bitty Boxes.
Then something nasty happens, and those Bitty Boxes become more capable without becoming correspondingly more expensive. All of a sudden, the companies selling Real Computers no longer have a value proposition: Their stuff may not be hugely more capable, but at least it's massively more expensive!
Eventually, not even the Real People can continue to ignore the fact the Toys are smoking them in every benchmarkable metric aside from cool factor.
It happened to DEC when minicomputers fell to PCs, and it happened to Sun and SGI when the "workstation" category got folded into the "somewhat-more-expensive-than-usual PC" category.
Linux originally ignored the extreme low-end PCs, but in 1991, it was pretty clear than 16-bit x86 CPUs were more trouble than they were worth in the Unix-like world and it wasn't a good move to mutilate the kernel to fit on a kind of system which was rapidly becoming obsolete. However, Linux is not ignoring the current Bitty Boxes, the SBCs which can run the kernel with no compromises once you navigate the weirdness of ARM-based hardware.
(Yes, there is a project to run Linux on 16-bit x86 chips and other MMU-less CPUs. It's called ELKS and it was never very active.)
That makes it sound like Linux is just a big dump of code. In reality, if you want to add some sort of device support, it's expected that your code will fit in with the rest of it, e.g. use device tree and all the other infrastructure, and use it correctly.
Some subsystems have stricter guidelines yet, e.g. if you want to add support for graphics hardware to DRM, the graphics subsystem, there must be a corresponding, fully featured open source userland implementation for it.
It's definitely not a dumping ground, try get a new feature merged into Linux and see how easy it is.
The inclusive attitude is exceptional for drivers and new architecture support. The kernel is intended to be portable, the more architectures supported the more mature the abstractions become. So as long as there's existing hardware capable of running the kernel for the new architecture, you probably won't meet much resistance landing support, provided it's not a disaster.
It's become trendy to say that supporting more things means only new work and a big waste of time. The "validating the abstraction" thing is overlooked.
The OpenBSD guys also used to write about this for why they support obsolete hardware and compiling itself on said hardware. That it surfaces bugs.
You're acting as if a kernel can only have one aim.
This is not a criticism, but I would like to deeply understand, what does Linux leadership want it to be? An OS that just runs on anything for the sake of it?
NetBSD falls under this, for example, but NetBSD also has many other benefits and aims than "Can run on your Burroughs P100."
Linux has ~5k people a year contributing patches to the kernel; it can have many aims, because "Linux leadership" doesn't mean "Linux dictatorship."
It can be a dumping ground of sorts for your ideas and research projects.
I don't think so. I mean, yes, there's some pretty obscure things in there. But to be part of the mainline kernel means that you're code must pass all sorts of gatekeepers. The code has to meet a number of quality and appropriateness checks. A good number of eyeballs have to sign off, or at least no object.
Anyway, it is a shared memory system, and under IRIX, that was done dynamically. The same chips were used in their NT visual workstations. Those did not manage the graphics memory dynamically, but were capable in every other way.
At the time, one could push 500mb plus images around like nothing. Was a big deal.
SGI did Linux drivers, and the SGI / Microsoft Farenheit project got in the way. Those never left SGI for legal reasons. Had that happened, perhaps Linux for an O2 would make sense.
I am not sure that system has ever seen a low level document release.
That is what I was remembering. The two shared the same graphics core.
Cobalt. I knew Copper was not quite right. That is Amiga.
Anyway, at the time, PC busses were slow, and one could get a fair amount of RAM on either side of it and sort of do what that system did easy.
The plan was to get that graphics system into Linux proper, and legal got in the way. All we ended up with was a frame buffer and no real docs for the graphics chipset that I ever knew of.
Too bad. We may have seen some very differentiated PC innovation a bit earlier. If one wanted to do things like real time sub pixel accurate compositing, or mapping video onto dynamically changing surfaces, etc... anything requiring either/or large image data, high throughput between gfx, CPU and RAM, the performance was exemplary.
A lot of that was true on a few hundred Mhz O2 as well as the 1ghz Visual Workstations.
I spent a fair amount of time using both. Pretty sweet for the time period.
"The OpenBSD/sgi port was discontinued after the 6.5 release."
That said, it was a very mature port and ran on many models, in 64-bit mode.
The code remains in -current for now.. the last release, 6.5 is a complete modern (was released in 2019) Unix operating system, which is more than can be said for running IRIX or Linux on these machines. I'm not even _aware_ of any binary distros of Linux for these. And good luck building your own kernel and userland.
I missed that when it happened, too bad. OpenBSD's sgi hardware support is much better than NetBSD's (although that
I guess the reason is that they used an Origin 350 for builds, but the disk controller driver had a bug causing lockups and FS corruption which never got fixed.
The Indy was a really important machine in my journey and I occasionally think I should pick one up for nostalgic use... but... meh, Irix is frozen (there is no OpenIRIX soldiering on...) and if I ran say FreeBSD on it, it'd just be a really slow machine that doesn't have enough RAM to build x, y or z. At least, that's how I talk myself out of turning my house into a tech museum!
65 comments
[ 2.9 ms ] story [ 150 ms ] threadMy guess is on Erdas Imagine too.
That or some more programmatic stuff like an OGR/GDAL pipeline.
Makes me feel very old!
But sure, if you're just tooling around, nfsroot is convenient.
Though network booting and storage may well be an easier avenue and cheaper. If you already have a NAS, that may well be the easiest path.
It's possible to install gigE, but you will need a PCI-X shoebox and also a NIC with compatible firmware. Not super easy to find.
You will want gigE if you are going to do anything interesting over the network on an Octane.
https://store.inertialcomputing.com/product-p/scsi2sd-v5-st3...
There are also Fibre Channel adapters for these if you have the XIO-PCI card cage. Can boot from it with some special magic IIRC, but a local SCSI drive is fine for most things.
It might have actually been Adaptec PCI in an SGI XIO-PCI card cage, memory is failing me. Definitely some dark magic required on Irix and on the FC switch and storage target side.
So after my XIO FC board died, I added an Adaptec board to my O2K to get my RAID array back online (the whole company was out of work because of that failure).
However though the card appeared in "hinv", it didn't work... After I asked for help on the newsgroups (the system was out of maintenance...) Alexis sent me a private email with the necessary invocation of the kernel rebuild command, and it worked like a charm from there.
e.g. 10 years ago people were dumping CRT monitors, now a decent Sony Trinitron starts at 150-200 €
The SGI machines are difficult to get hold of in the UK to begin with plus they are as other said short supply. There is one Octane in the country and it is the machine only (even though the monitor and keyboard are pictured) and it is going for about £800 on ebay.
If it was everything I would have said "that probably the best deal I am going to get" and went for it.
In those days I got an extremely cheap Sun workstation on ebay as an example.
Anyway, I guess supply is low but there are still nerdy people who think an old Unix machine is cool. (I'd take one running Irix just to play with for sure.)
I bought my Octane on eBay in 2008 (it was previously used at Ford), I think it was around $80 and shipping was more than half of that (an Octane weighs ~80 lbs).
Here's a crazy one I saw yesterday: the Canadian government auctioning an unused Origin 3400, still in shipping crate. https://www.gcsurplus.ca/mn-eng.cfm?snc=wfsav&sc=enc-bid&scn...
I would love to own an Onyx, even just to look at the case. Just because of what it represented for me as a kid who could barely afford a Voodoo card.
I remember saving for what seemed like an eternity, then buying a used (and only slightly defective) Trinitron from a friend's dad (who was a draughtsman) round about '97.
I don't recall what size it was, but the point was it was big for the day, like 24" - it was so heavy that me and my dad could barely lift it! When we got it home, it bowed my wooden desk in a very threatening way, but managed to sit there for a couple of months before it finally broke through the desk!
When I finally got rid of it round about 2010, it was still working as it always had. But it was hard to justify keeping that massive, heavy box around forever (IIRC, it was something like 40kg!)
This is not a criticism, but I would like to deeply understand, what does Linux leadership want it to be? An OS that just runs on anything for the sake of it?
It already seems true that Linux aspires to be much more than what UNIX is. It can be a dumping ground of sorts for your ideas and research projects. As long as the code does something useful enough without corrupting the entire system, it seems to be fair game. That is kind of freeing and it would stand to benefit the project to be communicated more directly. These are my observations.
It's not quite like that, there's quite a bit of hardware support that has been dropped along the way. It's not enough for people to care about stuff, they have to care about it enough that they maintain that support in line with kernel devs' expectations. That's not always easy.
It happens again and again:
There's a plateau of Real Computers, where Real People do Real Work, because they wouldn't deign to deal with the oddities and lack of performance peasants put up with on their Bitty Boxes.
Then something nasty happens, and those Bitty Boxes become more capable without becoming correspondingly more expensive. All of a sudden, the companies selling Real Computers no longer have a value proposition: Their stuff may not be hugely more capable, but at least it's massively more expensive!
Eventually, not even the Real People can continue to ignore the fact the Toys are smoking them in every benchmarkable metric aside from cool factor.
It happened to DEC when minicomputers fell to PCs, and it happened to Sun and SGI when the "workstation" category got folded into the "somewhat-more-expensive-than-usual PC" category.
Linux originally ignored the extreme low-end PCs, but in 1991, it was pretty clear than 16-bit x86 CPUs were more trouble than they were worth in the Unix-like world and it wasn't a good move to mutilate the kernel to fit on a kind of system which was rapidly becoming obsolete. However, Linux is not ignoring the current Bitty Boxes, the SBCs which can run the kernel with no compromises once you navigate the weirdness of ARM-based hardware.
(Yes, there is a project to run Linux on 16-bit x86 chips and other MMU-less CPUs. It's called ELKS and it was never very active.)
https://github.com/jbruchon/elks
Some subsystems have stricter guidelines yet, e.g. if you want to add support for graphics hardware to DRM, the graphics subsystem, there must be a corresponding, fully featured open source userland implementation for it.
The inclusive attitude is exceptional for drivers and new architecture support. The kernel is intended to be portable, the more architectures supported the more mature the abstractions become. So as long as there's existing hardware capable of running the kernel for the new architecture, you probably won't meet much resistance landing support, provided it's not a disaster.
> the more architectures supported the more mature the abstractions become.
The OpenBSD guys also used to write about this for why they support obsolete hardware and compiling itself on said hardware. That it surfaces bugs.
This is not a criticism, but I would like to deeply understand, what does Linux leadership want it to be? An OS that just runs on anything for the sake of it?
NetBSD falls under this, for example, but NetBSD also has many other benefits and aims than "Can run on your Burroughs P100."
Linux has ~5k people a year contributing patches to the kernel; it can have many aims, because "Linux leadership" doesn't mean "Linux dictatorship."
I don't think so. I mean, yes, there's some pretty obscure things in there. But to be part of the mainline kernel means that you're code must pass all sorts of gatekeepers. The code has to meet a number of quality and appropriateness checks. A good number of eyeballs have to sign off, or at least no object.
Anyway, it is a shared memory system, and under IRIX, that was done dynamically. The same chips were used in their NT visual workstations. Those did not manage the graphics memory dynamically, but were capable in every other way.
At the time, one could push 500mb plus images around like nothing. Was a big deal.
SGI did Linux drivers, and the SGI / Microsoft Farenheit project got in the way. Those never left SGI for legal reasons. Had that happened, perhaps Linux for an O2 would make sense.
I am not sure that system has ever seen a low level document release.
The 1st gen Visual Workstations had a different chipset called 'Cobalt', but also had a Unified Memory Architecture.
Cobalt. I knew Copper was not quite right. That is Amiga.
Anyway, at the time, PC busses were slow, and one could get a fair amount of RAM on either side of it and sort of do what that system did easy.
The plan was to get that graphics system into Linux proper, and legal got in the way. All we ended up with was a frame buffer and no real docs for the graphics chipset that I ever knew of.
Too bad. We may have seen some very differentiated PC innovation a bit earlier. If one wanted to do things like real time sub pixel accurate compositing, or mapping video onto dynamically changing surfaces, etc... anything requiring either/or large image data, high throughput between gfx, CPU and RAM, the performance was exemplary.
A lot of that was true on a few hundred Mhz O2 as well as the 1ghz Visual Workstations.
I spent a fair amount of time using both. Pretty sweet for the time period.
Little ominous though how heavily it’s reliant on linus being available. I hope the business continuity planning is up to spec
"The OpenBSD/sgi port was discontinued after the 6.5 release."
That said, it was a very mature port and ran on many models, in 64-bit mode.
The code remains in -current for now.. the last release, 6.5 is a complete modern (was released in 2019) Unix operating system, which is more than can be said for running IRIX or Linux on these machines. I'm not even _aware_ of any binary distros of Linux for these. And good luck building your own kernel and userland.
I guess the reason is that they used an Origin 350 for builds, but the disk controller driver had a bug causing lockups and FS corruption which never got fixed.
https://marc.info/?l=openbsd-cvs&m=156941089510768&w=2
I also remember Miod Vallat doing a lot of the work on sgi, but he left the project a few years ago.
I feel the same. Indy amd O2 were amazing computers. I got rid of all my SGI gear. Every so often I feel a pang of regret...