The collected works of SAQ - Page 5

It's a number of things. In general, smaller faster systems tend to go for a higher price as people migrate off a platform but need to keep something around for one or two apps. A 1 or 2u system (or a small workstation like the XPsomething) is more enticing than an old DEC 7000.

Also "last systems to support..." are another thing. VME, XMI, ... someone probably has a process control system that interfaces to it (not so sure about Futurebus+), and will want to have spares around. Likewise for a system such as a 250MHz R4400 Indigo2 - COFF binaries anyone?

Third thing are systems qualified to run in certain other systems, such as the MRI controllers or various other things. It costs more to requalify with something else than it does to keep many spares around.

The graphics travels over the network as X11 calls/OpenGL GLX remote calls/DGL calls that use the capabilities of the machine running as the X server. In short, you'll get very close to the same graphics performance that you would running it locally (the only downside would be if you're running something that requires a lot of data to be moved around - the network (especially on O2s, no Gbit) is slower than local data.

I remember seeing, many years ago, a comparison that someone did between MS's top tech support and a call to the Psychic Hotline regarding a moderately complex DB question. Neither was able to fix the problem, the difference was that the Psychic Hotline admitted that they didn't know what they were doing, whereas MS kept trying to sell them stuff (I think).

Pymble- did you run the original Alpha x86 (MS) emulator or DIGITAL's FX!32? My FX!32 experience is limited (I do have a copy somewhere, but the AS2100 I had NT on died), but it looked like a very strong approach to the problem - writing out pretranslated blocks of code to create a semi-"fat-binary" so after several runs very little of the code needed to be translated "in-flight".

Tru64 is an interesting breed. Most Unices have some parts that are advanced and some that are a bit ... anachronistic, but Tru64 seems to have more of the extremes. TruClusters at one end and the only current UNIX that still uses COFF on the other end (there are other examples of both - fortunately AdvFS has been stable for the last few releases).

Your VMS licenses should come through within a day of applying, or at least they do for DECUS/Encompass members. The disks take somewhat longer. Enjoy - VMS is frustrating at first, but then you learn to like bashing your head against it It's very different from UNIX, and unfortunately while I've seen about 2-3 different "UNIX for OpenVMS users" guides I've seen zero for going the other way.
BTW - You might as well start looking for a second machine to start a VMScluster with.

Origin2000 is pretty good looking as far as a rackmount goes, considering. I do find that the system controller in Everest boxes is much more useful than the MSC on Origin machines.

The "refrigerator" comment is understandable in context, but I can't understand the guy who noted that the new system was "portable". Easier to move, perhaps, but I don't see how anyone could consider an Onyx portable.

13W3 is a wonderful standard that defines pins for composite H+V sync, separate H&V sync, and sync on green. There are enough possibilities for many vendors to have their own semi-proprietary connector if they ignore the other possible permutations. Haven't seen one yet with horizontal sync on green with separate vertical, but wouldn't put it past someone...

On the plus side a number of 13W3 monitors do support all standards (though generally not the V6/V8 refresh rates), sadly they're mostly big tubes (though a 21" Trinitron in the flower of health is a sight to behold).

Xorg = have fun. Newport is documented and possible, everything else will be "fun".

There is a point to this work. As IRIX slips gently into the "hasn't been patched for many many years" stage something will need to be done for security patches... OpenSolaris would be a closer match than GNU, though.

Try mounting the images using the loopback driver. Try running "file" on the images.

NetBSD - it preserves the "true path" of BSD on DEC. Comes with a pretty good selection of software available, too.

Do have a disk with Ultrix 4.5 on it if you can. It does bring back that vintage feel (the one that gave rise to the "UNIX Hater's Handbook" )

Ultrix wasn't a bad implementation of UNIX, indeed for the time it was in active development (really the late '80s, after that things shifted to OSF/1 and Ultrix stalled) it was pretty good. However, UNIX from that time tended to not be the system that we know and love today (although the seeds were there). I guess a more generalized version of what I was saying is that everyone who can should experience the development of UNIX to where it is today, including something from the period that inspired the UNIX Hater's Handbook

If you're really masochistic it would be an early AIX, SCO UNIX, or vanilla SysVr2.

AIX v3 (and before, I suppose) was the "AIX is not quite UNIX (from either a user or programmer standpoint) and we really don't care, we're IBM" release. v4.3 (haven't used any v4 before 4.3) was better, and with v5 IBM started making a concerted effort to play well with everyone else.


AIX does have some technical features that were ahead of its time when introduced - JFS and the systemwide use of logical volumes, almost everything being done dynamically without rebuilding a kernel/rebooting, and the sysadmin hand-holding in AIX is about the best of the lot (smitty and msmit), only possibly matched by HP-UX's SAM (though to be fair AIX has it because it needs it - the admin setup is still (as of v5.1) drastically different from any other UNIX).

Nah - there's always the circa-1908 Cockney and absurdly heavy Scottish dialects that everyone thinks of .

Oh, and lest I forget, the rugby players from Monty Python.

But then don't all US people sound like either New Yorkers or a caricature of the Louisiana or Texas drawls?

Why? Corel just started shipping WINE with WP (back when they did that, what was it, WP9?)

I wonder why they confused the issue, already having the successful Altix line for Intel-based machines (XE for x86_64).

Why would someone bother licensing? Didn't Intel run off with "Extreme Graphics" and "vPro" for free?

How are they (HP) doing it on the Itanium now?

Early R4000s had a bug in them that prevented 64-bit operations. Pedantic, but some R4000s were not 64-bit capable.

IP19 can run 64-bit IRIX.

It would be nice if you could get a buyer to take the whole thing, but your maximum rate of return (if measured solely in $$) will be in parts. The MMSC and nodeboards alone will probably bring more than the system as a whole, but then you do have to deal with shipping.

Nah - too much custom work. Crimson2 would be an off-the-shelf case from someone.

HP1 -> Indigo R3000 (IP12)
HP2 -> Indigo R4000 (IP20).

HP1 is all the major components of an IP12 (PI 4D/3x) (minus VME interface) in a different layout. HP2/IP20 has no siblings. I think the only reason that they kept the "HP" number was for historical reasons. HP1 was the first time that they "rearranged" a system board, so perhaps that's the reason they did the different naming. Later (Indy) they gave it a different IP number (essential components of an IP22, but labeled IP24).

They might have some creativity but just not the budget to do anything with it. Off the shelf stuff that's made in quantity is noticeably cheaper than a custom job.

I remember seeing a commentary on Apple advertising to the effect that they had mastered the art of telling people to demonstrate their individuality by purchasing a mass-produced object.

Anyone seen any? Nice OS, pretty well known, but little prebuilt software. I guess I can start by building GCC 2.7 with the cc and go on from there, but prebuilt binaries can be so much easier.

6.1. ECOFF was obsoleted in 6.2



Seems few people admire extreme dryness anymore. I suppose few got my "deal with the devil" joke either.

IRIX 5.0/5.1 (they were released simultaneously) introduced the ELF format and DSOs to IRIX (what would become the o32 ABI once they had multiple 32-bit ELF ABIs). ECOFF was used in earlier versions of IRIX and, I imagine, GL2-W. ECOFF support was maintaned (for both building and executing) through IRIX 5.3, which would include IRIX 6.0, 6.0.1 and 6.1 (though I have heard that support is incomplete in IRIX 6.1). It was removed starting with IRIX 6.2. The default with IDO 5.x is to build ELF, with ECOFF support in there primarily for people who used a 5.x only machine (IP22, IP19) as a build machine for IRIX 4.x binaries. Some software was ECOFF only in the 5.x era (most notably the PS RIP for Impressario 1.x), but most was ELF or shipped with ECOFF and ELF, since ELF had some useful tricks that IRIX ECOFF didn't have (DSOs for one).

Since IRIX 5.x introduced many other advantages (OpenGL and X11R5 for one), there was incentive for developers to move to IRIX 5/ELF from the older IRIX 4/ECOFF format.

I don't think the old ECOFF compiler did anything other than MIPS1 code, so if it's MIPS-3 it's ELF.

I'm looking for one that can do MIPS RISC/OS, which is the same basic hardware but in big-endian mode.

NCR used to be owned by AT&T, so that probably explains why you had the NCR server. Surprised you didn't have any 3Bs hanging out there as well.

Alpha was a good platform, so I wouldn't be surprised if technical merit was what convinced the company to use that box.

Or to put in more succintly: Fuel is essentially a graphics equipped Origin 300/350 restricted to single-processor-single-node operation built in a PC-ish case. The Bedrock is there, the XBRIDGE is there, the R14k is there - it just doesn't scale.

It's OK, you just have to make sure to get 100% HCL'd hardware. If you get something "mostly compatible" you'll have trouble.

I wound up going the SPARCstation route because of the trouble, though I suppose if you looked globally/nationally rather than locally it would be easier.

I wonder if VirtualBox will do it - Vbox can run OS/2 which is an achievement, maybe it will also run AIX PS/2.

I wouldn't count on it being sluggish - I'm running OpenVMS 8.4F on a 384MB AS1000A 5/333 and it's not bad. The glass console code has been redone at some point and it's now much speedier at text scrolling on the glass console (outside of DECwindows).

It's in field test, and for a while the program was open to anyone interested who would run it and provide feedback.

I'll get back to you on DECwindows. Are you interested in local performance or remote?

Express graphics (XS/XZ/Elan/Extreme) are OpenGL native - everything from RealityEngine on had a native OpenGL implementation. It doesn't have hardware texturing, though. The only oddity is Express graphics without Z-buffer, which do not have any sort of Z-buffering support. This would only affect XS (without Z) and homemade Indigo graphics variants that SGI didn't distribute.

A 1999 program should have support for IRIX 6.5 (released June 1998), but would probably run under IRIX 6.2+.

A 1999 program would not be using IRIS GL, so it shouldn't have the IGLOO performance hit.

I think we're talking at cross purposes - another SGI piece has the following:



The implementations listed as supported starting in IRIX 5.3 don't have an OpenGL implementation that makes full use of the hardware, so some routines that you'd expect the graphcis to do are instead bustled off to the software renderer with the attendant decrease in performance (most notably texturing in VGX, and the OGL implementation doesn't make good use of the Turbo option on GR1).

The middle graphics had full hardware implementations for both OpenGL and IRIS GL, doing what the graphics could do in hardware and using software for unsupported functions (e.g. texturing on Express).

IMPACT/InfiniteReality and later are "OpenGL only", optimized for OpenGL and using the emulation layer (IGLOO, which uses DGL calls) to support the older IRIS GL library rather than having a "native" implementation.

I think I figured it out - Jan Jaap is talking hardware and I'm talking software. In that case yes, IMPACT and InfiniteReality are the first "native OpenGL implementations" in that the hardware was designed around OpenGL. I suspect that RealityEngine2 and Express graphics were designed looking forward to OpenGL (not sure about RealityEngine1), and thus they don't have the limitations in hardware that caused VGX/VGXT/GR1.2 to need to do things in software under OpenGL, but they did come out first with an IRIS GL implementation with the OpenGL following. Scratch that - I know that RealityEngine2 was designed looking forward, since it shipped with Onyx and thus was designed around IRIX 5.1 (which introduced OpenGL).

From a software standpoint there were "full OpenGL implementations" prior to IMPACT and InfiniteReality in the sense that there were SGI graphics options that had native (untranslated) OpenGL support up to the capacity of the hardware - i.e. Newport did raster operations in OpenGL on hardware, Express did (with the exception of Indigo options lacking a hardware Z-buffer) geometry, Z-buffering and raster operations on hardware, and RealityEngine did everything (geometry, Z-buffer, raster, texture) in hardware, with the missing parts filled in on the main CPU (similar to how IRIS GL did it). This is similar to IMPACT and CRM - on a number of IMPACT options texturing is done by the main CPU, and CRM does geometry on the CPU, only these graphics do not support the parallel hardware IRIS GL implementation (using IGLOO instead).

EDITED to replace typo (hardware used instead of software)

Probably because your O2 was running IRIX and IndigoMagic.

MaXX is a neat project, but do remember that it is in prerelease, so not everything is there yet.