[rescue] SGI Indigo2 & IRIX 6.5

[Jonathan C. Patschke]

On Sun, 30 Nov 2008, Patrick Finnegan wrote:

> In general, I find that Linux has a better selection of hardware support
> than any proprietary UNIX does.

If your platform has commodity buses like PCI and USB, this is undoubtedly
the case vs. IRIX.  I think you'll find, though, that IRIX's support for
the sort of hardware you can actually plug into an SGI workstation far
exceeds what Linux can manage.

>> one well-integrated journaled FS with GRIO instead of 20-something
>> bag-on-the-side filesystems with patented "LOL, WTF, whenever" IO
>> scheduling,
>
> I've generally never had a problem with ext2/ext3 on linux, unless I did
> something unholy to the RAID or disks underneath.

Right, but Linux still schedules the IO whenever it wants to get around to
it.  Linux's realtime facilities are mostly an afterthought.  IRIX did a
very good job of being a general-purpose OS for typical end-user things,
but doing IO in ways that most folks only expected from an RTOS.  GRIO on
IRIX isn't just marketspeak.  If you have the disk bandwidth, you Will Get
the IO you ask of GRIO, predictably and on-schedule.  This is critical for
the sorts of things you'd use IRIX for (which ties closely to the sort of
hardware you'd plug into an SGI).

> XFS on Linux is another matter though that has caused us many problems,
> and occasional data loss.  I'm not saying that XFS itself is bad, and it
> probably works great on IRIX, but its Linux port has major issues (and
> there's some well known reasons why that I won't get into).

Part of it is the Linux implementation, and part of it is that XFS has
certain assumptions about the underlying hardware.  For example, there's a
kernel hook that gets called when the machine enters a powerfail state.
This hook kills has the kernel stop -everything- it's doing, power down
what it can, and shove the last bits of the transaction log out to disk.
SGI found that, without this, XFS wasn't very reliable in the face of
losing power.

>> context-sensitive help facilities that are actually relevant, accurate
>> man pages
>
> I generally don't use/care about context-sensitive help, so I can't
> comment on that,

You've never been stuck in the desktop environment and trying to figure
out what cutesy name some moron decided to give to some useful system
component ("kudzu" for hardware management?  "Anjuta" for an IDE?
"Evince" for a document previewer?  "K3b" for creating ISOs?) only to find
the online help utterly useless for helping you sit down and get work
done?

> but I've never had a problem with the accuracy of man
> pages on Linux.

I run into plenty of problems.  Thankfully, they're usually flagged with
text that reads something like "This documentation is out of date because
the FSF thinks you'd rather use the "info" command to navigate twisty
little passages of hypertext, rather than see the whole manual and once so
you can user your pager to search for what you actually wanted to know."

>> support for possibly the best optimizing compiler ever written
>
> Intel does a really good job at writing an optimizing compiler, as much
> as I don't want to admit it.

Intel do a -fantastic- job, so long as you use their parts.  Their
compiler does a not-so-great (verging on pessimal, where they can help it)
on AMD parts and ho-hum on VIA parts.  That said, MIPSpro optimizes the
code at a static level to a degree that's still awe-inspiring, even 5
years after their its last release.

> Gcc works, but is slow sometimes.  I've had a much harder time getting
> most code to just _compile_ under proprietary UNIXes (or compilers) in
> general because they all seem to have different headers, and in
> different locations, or support different subsets/supersets of library
> functions in their system libraries, or interpret some part of the C
> standard differently.

I've not had any problems compiling standards-compliant C or C++ with
MIPSpro, Sun Studio, xlC, or HP C.  There is, however, a large body of
code that claims to be standards-compliant, but only compiles with gcc.

And, yes, the header files are in different spots.  The various standards
say that's okay.  Linux's placement of the header files is no more or less
correct that anyone else's.

>> , ONE snappy interactive desktop environment instead of eleventy
>> competing ones that share neither config data nor system resources very
>> well
>
> You still have a large choice of desktop manageres on IRIX, you just
> have the inconvenience of (usually) having to compile the one which you
> actually like.

Yes, but the one that comes with the box is fast and useful, not bloated
and slow like KDE and GNOME.

> What's wrong with choice, anyways?

May I refer you to the last few elections in this country?  When all the
choices suck, you don't really have a choice at all.

>> solid System V and UNIX 95 API support, and I/O throughput Linux could
>> only dream of?
>
> All I can say is "show me the numbers."

I don't have any handy, but people were doing realtime video recording
with XFS on SGI hardware in the mid 1990s, and I would be -extremely-
surprised if Linux could manage that on SGI hardware of that vintage, even
if the hardware had drivers in the Linux kernel.

> Also, is seems like few people are writing any software these days
> that's meant for proprietary UNIXes vs the open-source things.  They're
> out there, but getting fewer each day.

There's no reason not to support "proprietary" UNIX.  The SUS standards
are published and free to read.  Making software that only runs on Linux
or BSD is pure laziness.

>> Plenty of performance-enhancing features that other OSes are just
>> -finally- starting to implement were in IRIX years ago; "quickstarting"
>> comes to mind.
>
> I'm not familiar with this, but if this is what the Wikipedia page
> "QuickStart" describes, it doesn't sound like something I'd want.

In the SGI context, quickstarting an object means to fix-up the virtual
addresses of all the libraries and executables registered with the package
manager such that any combination of libraries can be loaded into virtual
memory without collision.  Most OSes are set up such that executables load
at a fixed virtual address; I believe IRIX does this, as well, but the
maximum size of an executable text segment is necessary to know the lowest
address where one can load a library.

Most OSes defer the entire address fixup process until an application
launches.  This means that programs which use a large number of libraries
must load each library individually, find somewhere in VM to stash it, fix
up all the symbol addresses relative to that load address, and export that
fixed-up symbol table to any other object.  This is a large part of what
ld.so does.

IRIX does all this at once, so that each library on the system has a
predefined load address that's guaranteed not to collide with any other
library registered with the package manager.  If the dynamic loader hits a
snag, it falls back to the safer on-the-fly behavior, but, when things go
right, you wind up with much less work to toss a program into memory and
begin running it: the linker just loads the library into memory at the
address given in the header, and that's the end of it.

> My biggest problem with IRIX is its traditional minimal-security
> mentality, and bass-ackwards ways it does things.  (Like chosing what
> init scripts to run at startup, and the fact that SGI still says in
> their training material for SuSE on an Altix that changing passwords
> is "optional".)

I suspect if IRIX hadn't been gunned, IRIX 7 would've come up to par with
the rest of the world security-wise.  They got their asses handed to them
over 5.x and really cleaned things up in 6.x.

> My other reason for not caring about IRIX's graphical stuff, I guess, is
> that I spend 80% of my time while I'm working at a computer either
> staring at a command line or looking at fixed-point text in a simple
> GUI, like this message I'm writing in kmail. :)

Well, I'm using vim inside of screen.  That said, if you have an SGI, you
probably have it for the graphics subsystem.

> Anyways, with graphics acceleration, I shouldn't need it unless I'm
> doing 3D video stuff, or video games.  I certainly shouldn't need it on
> a "typical office desktop".

Sure you do.  2D acceleration is why you can take an SGI system with a
relatively slow CPU (say, Indigo Elan 100MHz R4000) and a Sun system with
a relatively fast CPU (UltraSPARC-II 300MHz w/ TGX graphics), and the SGI
will be loads faster for interactive work.  I've run both on my desk, and
even an Indigo XS will make the Sun look slow, right up until you get to
something CPU-bound.

But, like you've pointed out, most work isn't CPU-bound.  I would
frequently use an SGI system as a frontend to applications running on
larger Suns, which was a winning combination.

> If I felt like hacking together better support for Linux, NetBSD, or
> something else on an O2, why not?

By all means, go right ahead.  I just don't see the point in it when IRIX
runs so well.

-- 
Jonathan Patschke < "There is great satisfaction in building good tools
Elgin, TX          > for other people to use."
USA               <                                     --Freeman Dyson