The collected works of jpstewart - Page 5

Alver wrote: It's been a good while since I've had to open up my C8000's, but do they have drive caddies at all?

Yes, there are caddies. Purplish plastic rails on the sides of the drive with a little metal plate underneath. H-P assembly P/N AB601-62006.

Edit: to answer the original question, page 3-20 the HP C8000 Technical Reference Guide (which can still be downloaded from HP) says:

Snap the drive inside the drive tray to attach rails to the hard drive. Pull outwards on the drive rails, then place the tray onto the drive. Align the pins on the tray wtih the holes on the drive and let the rails snap into place.

The illustration shows that being done with the drive upside down and snapping the tray in place from above (so that the tray is under the drive when installed right side up).

I've only had a quick look at the batch file but I've noticed a few things:

1. The first line is '@echo off'. You can delete that line (or put REM in front of it to comment it out) to cause the file to print each command before it is executed. That might help debug where it is failing.
2. The syntax of the 'format' command (at least under XP) is very different from what it used to be. The batch file passes both the '/U' and '/AUTOTEST' flags which are no longer documented as being available in XP. The format command will also stop and prompt you to label the disk manually unless passed the '/v:' option which is missing in the batch file. So there's a little work to be done to modernize those lines of the batch file. I'd start by just getting rid of '/U /AUTOTEST' and adding '/v:' to all of the 'format' lines and see where that gets you.
3. The syntax of the 'attrib' command may not work as used in the batch file. Under XP, it is documented that the +S +H +R options should come before the file name but the batch file puts the file name first. So this may or may not work as-is in XP, but it's an easy change if it doesn't.

It should, however, be possible (but tedious!) to run the commands manually to create the necessary disks by hand if you can't get the batch file updated to work on something more modern. There may be more problems than I've noticed, but the batch file is actually pretty straightforward using mainly 'echo' and plain 'copy' commands. The copying part could easily be done in a GUI file manager if you prefer. There are only a few echo commands where the output is redirected to a file so you could use your text editor of choice to create the 4 files (disk.num, autoexec.bat, config.sys, and blistlay.out) by hand. There isn't any complex logic or looping in the batch file that would preclude a manual approach.

And how are you calling the batch file? It should be run as 'cdtodisk X: A:' where X: is your CD drive and A: is your floppy drive. Running it without specifying those may cause problems.

Since it doesn't look like anybody else has responded yet, I'll offer a couple of comments:

MrBill wrote: I know the main focus of the forums here is SGI hardware, but i figured I would ask this here because I'm not really sure of where the best place to get information for sun machines would be.

Have you tried asking on any of the mailing lists at sunhelp.org ? That's probably the best place to find old Sun info. (And, co-incidentally, the lists are run by a guy who goes by a name similar to your own.)

MrBill wrote: I picked up 2 SUN IPC workstations today from a warehouse. [...] The power supply uses an odd short 12 pin cable, i was curious if there is a pinout for this so i could test to see if the power supply is the issue.

The pin-out for the IPC's power supply can be found in the Sun-4c Handbook .

I took a quick look at the source, and the only C++ source files I could find are all in the tests/ directory. It looks to me like m4 is just using the C++ compiler to build some files that test function signatures. (E.g., the test-sys_time-c++.cc that hamei's post mentions just checks that gettimeofday takes "struct timeval *" and "void *" parameters and returns "int", AFAICT.)

I don't see any loss of functionality by skipping the C++ stuff.

According to my sources, Octane2 prices in late 2001 ranged between the following:

Octane2, V6, 1x360MHz, 256MB RAM, 9GB 10K HDD, 21" monitor for $17,495 MSRP.
Octane2, V12, 2x400MHz, 512MB RAM, 18GB 10K HDD, 21" monitor, DMedia options for $71,445 MSRP.

Without DMedia, the price of the last one dropped by about $30,000!

Trippynet wrote: Now the model number definitely matches the 146GB drive (it wasn't a mistake), but it also has an IBM sticker on it with 36GB listed as the capacity. Maybe the IBM sticker is wrong, I'll have to test it. If it's actually a super-quiet 146GB drive then I'm not complaining!

There used to be a guide on Seagate's website explaining how to decode their model numbers. I can't find it anymore, and only remember parts of it. The first digit was a code for physical size, and the rest of the digits represented capacity. Maybe the last digit was the generation.

So ST3146855LC is definitely a 146GB drive; maybe the last "5" indicates that it's from the 15K.5 series. It's possible the IBM sticker is wrong. It's also possible that IBM deliberately crippled the drive. I've heard of drives being "short stroked" for performance reasons (to use only the tracks with the fastest data access). It's also possible that IBM was still supporting 36GB disks after Seagate stopped making them. In that case, altering their firmware to limit capacity would make sense if IBM was sending them out as warranty replacements for real 36GB drives in RAID arrays (where the controller would complain about size mis-matches).

I've actually got a 73GB U320 Seagate drive that was pulled from an IBM storage array. The IBM firmware limits it to U160 speeds despite the Seagate label and part number very clearly being for a U320 drive. It wouldn't surprise me at all if IBM did something similar to make a 36GB drive out of 146GB one for you.

BTW, the same part number decoding suggests that the "36GB, 15K, ST373455LC (VERY Low noise) - my current Indigo2 system drive" in your list is actually a 73GB drive, and probably one generation newer than the ST373454LC you have listed right below it.

ajw99uk wrote: Makes me suspect RAM was one of the "out there"-priced accessories!

Indeed. What I've seen (from November, 2001) were the following for Octane RAM:

256MB: $1000
512MB: $2000
1024MB: $4500
2048MB: $13500

Each of those prices is for a kit to fill one bank of the four in the Octane. Keep in mind that those are list prices and most (if not all) customers would receive a hefty discount. But still....

The error message from inst shows that neko_sdl package version 9 or higher is required. The SDL packaged linked to in Nekoware /current is only version 8. Use the one from /beta instead, which appears to have package version number 12.

It's important to understand that inst doesn't care about the SDL version number in the file name; it's only going by the version code of the package itself. There's a bit more info about package versions in the Nekoware wiki page about Packaging Software that might help clarify things if you want to understand why inst is complaining. Whether you want the background info or not, hamei's suggestion to use the newest SDL package is correct. Always check Nekoware /beta when you encounter this sort of error.

I agree with duck's suggestion that the XFS service is likely the old X Font Server rather than anything to do with the filesystem. More importantly, I agree with his recommendation of Debian. I use Debian on XFS on both my main workstation and my in-house fileserver.

Two things to note, though, if you're trying to use a Linux box to read XFS filesystems from IRIX:

1. While Linux should theoretically be able to read XFS filesystems created on IRIX, I've never actually tried it. I've only used XFS filesystems created on the same Linux box. So no guarantees from me that it'll work for you.
2. You need to be sure that the Linux box has the proper options enabled in the kernel in order for it to understand SGI's partition table format. AFAICT, the current Debian stable kernel does. It's possible that the CentOS box you tried couldn't understand the IRIX partition table, even if it could have supported the XFS filesystem.

Of course, if you've got XFS filesystems from a Linux box to read on another Linux box, then the above are moot points.

JSAMPLE should be defined in jmorecfg.h which should be included by jpeglib.h. So make sure that somewhere near the top of jpeglib.h there's a line that reads:

Also make sure that jmorecfg.h is located in the same directory as jpeglib.h. But beware that if either of those are missing, that would indicate problems with your whole libjpeg installation....

If you're missing the definition of JSAMPLE, it makes me wonder what else will be broken. There's a lot more stuff defined in jmorecfg.h. So while I'm sure foetz's suggestion will solve the immediate problem, it might not get you much farther.

It shouldn't matter whether you're using the IJG libjpeg or libjpeg-turbo. Both seem to the same in this regard, AFAICT from a quick check of both sets of sources.

chicaneuk wrote: Firstly with no HDD installed in the internal slots, the system won't get to the prom. It powers on, makes the chime, and then just dumps some horrible kernel panic type error message that starts with an: 'Exception: <vector=UTLB Miss>'

Unfortunately that's a sign there's something very wrong with your Indigo. It should get you to the PROM just fine. With the disk pulled from mine, I get the following on the console:

Pressing any key takes me to the usual PROM menu. (And it works the same with either a serial console or a directly attached monitor/keyboard.)

The other symptoms make me wonder if your power supply is marginal. Or maybe there's a problem with the SCSI cabling/backplane. Or the host-side of the SCSI bus. Or ...? Sorry I can't offer much help on the diagnosis of the problem. All I can say is that you should get to the PROM menu even without a disk installed. Yours seems to be failing very early, while running the internal diagnostics. (In which case, maybe try re-seating the RAM and the CPU module?)

foetz wrote: irix has no getopt.h and no long options either.

Odd. My IRIX boxes all have getopt.h in /usr/include. You're quite right about the lack of long options, though. (I can't count the number of times I've fought with autoconf finding getopt.h and assuming the presence of getopt_long()! That's one of my biggest pet peeves.)

Edit: according to 'showfiles -- /usr/include/getopt.h' it comes from the irix_dev.sw.headers package, which is on the "Development Libraries" CD in the IRIX media set.

ChrisR wrote: When I installed GCC 4.7.1 from the main site (nekoware.dustytech.net) and tried to compile the program, gcc complains that there is no getopt.h, and indeed the /usr/nekoware/gcc-4.7/include only includes a "c++" folder, and no pure c files.

Do you have /usr/include/getopt.h? If so, then you've got a problem with GCC's include path. If not, then you're missing some/all of the IRIX development headers. AFAICT, getopt.h is not supposed to be part of the GCC package.

Also note there's an older thread about Dustytech mirror being out of sync . I'm not sure if that's been cleared up, or perhaps worsened over time. Maybe try a different mirror to see if there's an updated GCC package.

FWIW, here's what the Linux source (in fs/xfs/libxfs/xfs_format.h) has to say about XFS (superblock) versions:

XFS V4 and above use two additional bitmask fields to specify which features are/aren't supported in a more fine-grained manner. The Linux kernel will only mount some version 4 filesystems with certain feature bits set, and filesystems with version code 5. Specifically, the directory format version 2 flag. So what SAQ called "version 2" is what the Linux kernel source calls either version 4 with the DIRV2 bitflag set, or version 5. There's a bit of info in the XFS FAQ about this, but not much.

Interestingly, the Linux version 5 info doesn't appear in the corresponding header (/usr/include/sys/fs/xfs_clnt.h) on IRIX. I wonder if IRIX supports it or if it's a Linux extension?

(Aside: don't you just love the way the "version 2" on-disk format was introduced with what the kernel calls "version 4"? I guess consistent numbering is over-rated.)

At first, my SGI machines tended to get named after cartoon characters.

It all started with my Indigo2 Impact. When I unboxed it, I was quite surprised at how very purple it was in person. And it was old when I got it. Practically a dinosaur in computer terms. So it was named Barney, because what else do you call a purple dinosaur? That led to the Octane getting named Gumby, by virtue of being green and nearly (but not quite) rectangular.

The Indigo was named Ziggy, largely because I couldn't come up with anything better for him. Try pronouncing "SGI" as a single word rather than three letters. I figured Ziggy was the closest cartoon name I could come up with. Similarly the HP C8000 runs HP-UX and if you sound it out (the "H" is silent), the closest name I could come up with was Puck (but that's Shakespeare rather than a cartoon...sigh).

The Origin 300 is Orion. Because I figured Origin and Orion were linguistically close, and I'm not very creative. The fileserver with Xeon CPUs is Xena for similar reasons.

My SparcStation 20 runs primarily Solaris which sometimes gets shortened to "Sol" which sounds kinda-sorta like Saul. So that's it's name.

At one point there was a bit of a naming convention based on twisted logic and odd associations. Now it's more whimsical. Whatever makes me chuckle. There'll be a new fileserver here soon. I'm thinking it'll be Tyler. As in "Tyler the Filer". Because the rhyme is what I find amusing at the moment.

ChrisR wrote: "irix_dev.sw.headers (Development Environment Headers) (1274627335) is incompatible with doe.sw.base (IRIX Base Execution Environment) (1289662620).

Does this mean I have to rebuild a hard drive and install the development components before the overlays?

No. You need compatible versions of irix_dev.sw.headers and eoe.sw.base. That's the base 6.5 dev subsystem, while you appear to be running 6.5.30.

Evidently, I provided bad information earlier in the thread. Taking a more detailed look at my CD sets, it seems that instead of the previously mentioned irix_dev on the Development Libraries CD (in the base set) you need irix_dev_6530m from the 6.5.30 overlays (probably on Disc 1 of that set) instead.

Sorry for the confusion.

foetz wrote: does the link line have -lpng ?

And is it after whatever files are causing the errors about unresolved symbols?

GNU tools let you get sloppy and list libraries and object files in any order. The GNU linker doesn't care. The IRIX linker, on the other hand, will only use libraries to satisfy previously unresolved symbols; it's much pickier about order. So 'ld -lpng foo.o' will work with GNU ld while IRIX would have unresolved symbols, requiring 'ld foo.o -lpng' instead.

It gets tricky when there are circular references between libraries (sometimes having to specify a library multiple times), so the GNU extension makes sense. But it also causes problems like this if the Makefile assumes libraries and objects can be in any order.

(Sorry for the delay, I've been swamped lately.)

The link line looks a little odd, especially the inclusion of -L/usr/lib for an n32 binary. It's also odd to use -nostdlib (which tells the linker not to look in the standard library locations) followed by two -L options which explicitly name those default locations. Off hand I'm not sure if the -L locations might only apply to the libraries specified after it, in which case it's looking at the wrong libpng.so.

I wonder: was there an error/warning earlier in the output about an incompatible ABI type? The linker might be finding the unusable o32 /usr/lib/libpng.so and ignoring /usr/lib32/libpng.so with those settings.

As a first guess, try leaving out all of the -L options except -Lrw, and leave out -nostdlib.

It might also be an issue of combining static and dynamic libraries. Were there any messages about a non-existent libpng .a ? If so, try adding -dynamic after -mips3.

It might be an issue of circular references. It's complaining about unresolved symbols in librw.a, while those same symbols (at least the PNG-related ones) are defined elsewhere in librw.a.

So add a second instance of -lrw to the end of the link line (keeping whatever is already there) and see where that gets you.

nekonoko wrote: If it's not sustainable I'll see about passing the torch on to someone else.

If it's unsustainable on voluntary donations have you considered membership fees?

I'm sure I'm not the only one who sees great value in the info in these forums, so I'm sure lots of us wouldn't mind paying annual dues so that you can maintain the site. I've made a donation now, and will try to remember to do so again in 6 to 12 months. If this site was subscription based, I'm sure it would remind me to make those payments!

In any case, thanks for the service so far!

nekonoko wrote: I got the same thing - I assumed they were migrating to a new system.

Me too.

Actually, I got a fairly similar e-mail almost exactly a year ago (Oct. 12, 2014) telling me my that my Supportfolio account was about to expire since I hadn't logged in for a year (at that time). So I assumed that this one was either something similar (although mis-worded as a new account) or that maybe they were migrating accounts to a new system as Nekonoko suggested.

In any case, I'm just glad to see I'm not the only one who is wondering what's going on!

necron2600 wrote: https://h20392.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=HPUXJAVAFFTB

The links on that page timeout for me.. Does anyone have local copies of Firefox 3.5, Thunderbird,and GTK libraries for HPUX that HP provided?

The software is still available from HP at the following URLs:

• Firefox 3.5: https://h20392.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=HPUXFIREFOX
• Thunderbird: https://h20392.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=HPUXTBIRD
• GTK 2.6.8: https://h20392.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=GTK268

(For what its worth, those URLs are the same as the URL in the original post, with the product number changed to the values gleaned from the dead links that page contained.)

You'll need a (free) HP Passport account to download the software.

Let me preface the following by saying that I have more experience with Apache/PHP on Linux than I do with the Nekoware packages for IRIX. I'm not an expert here.

The default php.ini should suffice for testing, so I don't think you need to worry about those settings until after you get the Apache configuration to run PHP. There are several parts to that. The following should work with the Apache2 and PHP5 packages from Nekoware /beta. If you're using the older stuff from /current the syntax will be different. (But I'd encourage you to use the /beta packages since they're much newer and need to be tested by somebody.)

First off you need to tell Apache to load the PHP module:

Then enable the PHP processor on files with names ending in .php:

And tell Apache that index.php can be used as well as index.html:

Restart Apache, and you should be good to go. If not, report back here with any messages from the Apache error logs and/or the web browser.

I haven't tested this on IRIX yet, so I'm kind of extrapolating from what's working on Linux boxes. In particular, be sure to double check the location of libphp5.so in the first configuration step! Also note that the above is a minimalist configuration for testing, just to get up and running. There are some other changes I might recommend later.

Once PHP is running, I'm sure we'll get HTTPS going, too.

techgrrl wrote: Jpstewart - good outline, and I thank you - what package contains libphp5.so?

It's in neko_php5-5.2.17.tardist (from /beta).

techgrrl wrote: Also in some threads I've been reading they say to install 'neko_php5.sw.sapi_apache2' but when I bring up the software manager for the package it doesn't show a check box next to it as 'installable' - it has 'cgi' instead.

That's the subsystem that contains it. Does software manager offer any suggestions as to why it isn't installable? Perhaps a missing dependency?

I think you're running too old of an IRIX release. Nekoware requires at least 6.5.21. Not so coincidentally, 6.5.21 is where strlcpy and strlcat were added. (It looks like mbrtowc and wcrtomb were added at 6.5.17.)

ssch1034 wrote: I wonder however, why would IRIX look it up in the patched emu_dd.o rather than mad_dd.o or rad_dd.o if it wasn't a EMU card?

All that matters is which file has the correct vendor/device ID pair. Rather than thinking that IRIX looked up the card in emu_dd.o, you should think of it as IRIX looked in all the driver files until it found the matching vendor/device ID. Basically, you told IRIX to use emu_dd.o, and IRIX trusted you.

ssch1034 wrote: As I only modified this object and got IRIX to accept it I am sure it must have been the correct object file.

Don't be so sure. I suspect you could modify any driver file to have your card's vendor/device ID and get IRIX to recognize the hardware as whatever corresponded to that driver. Of course the hardware wouldn't actually work, but IRIX would try to use any driver you told it to.

ssch1034 wrote: After all the entries in emu_dd.o were already close to the IDs of this card (If I remember correctly I changed the device from 0x0004 to 0x0006 or vice versa as the vendor id was the same).

That doesn't necessarily mean much. It's normal for different products from the same vendor to require very different drivers, regardless of their device IDs.

In fact, looking at device IDs from the Linux driver for the EMU 10K series soundcards, device IDs 0x0002, 0x0004, 0x0008 all use the same emu10k1 driver, while device ID 0x0006 uses the completely different emu10k1 x driver. Note that Creative and Ectiva both use vendor ID 0x1102. So what you have there is a clone of a similar, but different sound card that the IRIX driver won't be able to use. The fact that the device IDs are close is meaningless.

Wow, that's an unusually complete package of hardware you've got there. I often see the dials and/or buttons boxes on their own without cables, power supply, etc. It's rare to see everything together in one auction, plus a spaceball too! I'll be watching that auction for sure, and hoping it doesn't get out of my price range. I'm sure that such a complete setup will attract a lot of attention.

Thanks for letting us Nekochanners know about the auction!

pentium wrote: $200 after shipping. Daaaayum.

I'm not surprised. There's another seller who wants about $100 for just the dials box. No buttons box, no spaceball. Then there was another recent seller who was asking something like $200 for just the buttons box. PixelDust1 was offering everything (including cables) in one bundle.

I'm disappointed that I got outbid, but I also expected that to happen. I've got too many other more important expenses at the moment to spend much on my SGI hobby.

I just hope whoever got it enjoys it!

Devil Master wrote: So what would the lag be? Would it be feasible, for example, to use a headless desktop configuration to run graphical demos?

The only way to know is to try it and see.

It will depend on the graphics performance of whatever machine you're using to do the displaying. Both hardware and software can affect that. Likewise the network connection between the machines will play a big part. Local ethernet with little other traffic will perform very well. A congested network and/or multiple hops through multiple routers will not.

Also keep in mind that some demos may require some of SGI's proprietary extensions. So some demos may only work if the displaying machine is also an SGI.

That said, remote X11 works quite well in my experience for pretty much everything I've tried. That includes running Pro/E on a headless O300 with the display on a Linux box! Now, admittedly that was more to see if it would work than to do anything serious with it. I doubt it would be a pleasant experience with a complex model in Pro/E. But for doing simple stuff across a quiet LAN, it was surprisingly usable.

But really, you'll have to try it to see if your hardware, your software, your network can meet your performance expectations.

Knezzen wrote: Now it stops here:

Code: Select all

bsdinstall.c: In function `main':
bsdinstall.c:188: warning: implicit declaration of function `errx'
bsdinstall.c:264: warning: implicit declaration of function `err'
bsdinstall.c:265: warning: implicit declaration of function `getmode'
bsdinstall.c:340: warning: implicit declaration of function `warnx'
bsdinstall.c:377: warning: implicit declaration of function `warn'

I'm not at all familiar with pkgsrc, but I can tell you that errx, err, warnx, and warn are all functions that are defined in err.h which simply doesn't exist on Solaris 10. Those functions all appear to be part of (GNU and BSD) libc. A quick Google search suggests that pkgsrc/pkgtools/libnbcompat might be of help on platforms lacking them in their native libc.

As for getmode, it also seems to be a BSD-specific function (not even in GNU libc). I suspect it, too, can be found in libnbcompat since that's a NetBSD-compatibility library.

Sorry I can't offer more specific advice. All I can tell you for sure is that the code is written to assume to the presence of err.h and its functions, but you're building on a platform without them.

The ATA100 interface is (up to) 100 MByte/sec. Convert bits to bytes and you'll see that a gigabit network interface is only 125 MByte/sec. That's not much of an improvement. And that's before factoring in the network overhead that SAQ mentions, too!

It's also important to realize that 100 MByte/sec is the maximum burst speed of the ATA100 interface. It's very unlikely that the disk can actually sustain anything anywhere near that. Look up the manufacturer's specs for your brand/model of disk and see what its sustained transfer rate is. You might be able to find a compatible replacement disk that is noticeably faster. Or, if your disk is really slow and you've got fast a RAID in your NFS server, then NFS might be faster despite the above caveats.

A couple of points to add to what jan-jaap already said:

The fibre channel switches I've seen are backwards compatible for two generations. So a 4Gbps unit can be expected to support 2Gbps and 1Gbps, but an 8Gbps switch may not support 1Gbps (which is what the T3 runs at, IIRC).

With a SAN setup, you can easily partition the T3 to have a different filesystem for each of the clients. You cannot easily share a single common filesystem among multiple clients unless you're using a cluster filesystem such as CXFS. Beware the licensing costs and difficulties with CXFS! (There are open-source cluster filesystems on Linux but they're not supported under IRIX, AFAIK.) Good old NFS is simpler if you need multiple clients to have access to the same filesystem.

Based on my own experience, I'd suggest reading the manual and anything else you can find on Google for any SAN hardware (switch or storage) you're interested in before you buy. That way you'll know ahead of time if you need expensive (or impossible to get) licenses, management software, or support contracts. Assume any gear you get will have old passwords. Fortunately, there was a well-documented way to reset the passwords on my switches using a serial terminal without erasing the existing licenses for add-on features. Some sellers will reset passwords and/or itemize installed licenses. Then they'll charge extra. Other sellers who aren't so familiar with SAN hardware will offer much lower prices for as-is hardware with unknown passwords. If you know how to reset passwords yourself and are willing to take a chance on what extra licenses are installed, great deals can be had. So I highly recommend reading about whatever specific hardware you're looking at.

That's an impressive selection of hardware and software you have there. But what impresses me most is the depth of the research you've done on these machines and the companies that used to own them. Great job tracking down all that history!

vishnu wrote: Donations have been stuck at 500 dead p's for a while now, come on guys let's rally 'round the flag!

I suspect that's just the donation counter that's stuck, not the actual donations themselves! Several people have donated since then, and it's still saying $500. I just hope that's not a sign that PayPal is holding our donations hostage and keeping them from Pete.

I just donated now, and I did so the first time around, too. I had intended it to be a semi-annual thing, "paying my dues" for membership here. Apparently I lost track of time. I'll try to remember again in an actual six months. The info on this site is definitely worth paying for!

Raion-Fox wrote: There's more info on the Management Engine and the Platform Security Processor

Thanks for those links. That was some very interesting reading. (The rest of your post was appreciated, too.)

Wow. I know my way around a kitchen, but I only do simple stuff. I would never even consider attempting something so fancy. And by the time I'm done making the food, I certainly don't have the patience required to plate it so elegantly and offer up such a nice presentation. I'm very impressed with what you've done.

Krokodil wrote: So the postal workers have the customs forms on hand? I don't have to go chasing it all over town?

Yes. Package it all up ready for shipping. Walk in to the post office, hand them the box, and say "I need to send this to the US" (or wherever). They'll give you various price/service options (regular parcel, expedited, XpressPost, etc.), and then hand you the necessary forms to fill out. Once you've filled out the paperwork and paid, there's nothing more to do. It all happens at the post office counter.

You can get shipping quotes on-line if you like, but I actually find it easier to just go into the post office. They'll measure and weigh the package very accurately. They'll explain all the options. They'll provide all the right forms without you having to ask. Shipping internationally is easy with Canada Post. They do it every day. I've sent lots of stuff to the U.S. and Europe through them.

One piece of advice, though, is to try to find an actual Canada Post office nearby as opposed to a Canada Post counter in a larger store. In my town, there's a real Post Office and Canada Post counter in the back of a pharmacy. I don't know if the counter at the pharmacy is up to the same level as the true Canada Post location.

It looks like it is available from the Nekochan FTP site:
ftp://ftp.nekochan.net/pub/irix/General/OOo_1.0.3_IrixMips_install_english.tar.gz

I always liked the LSI SAS/SATA controllers. The LSI SAS3080X in particular is fairly cheap and easy to find on ebay. It has 8 internal SAS/SATA ports, but you'll need the appropriate breakout cable(s). There are other models with only external ports or a mix of internal and external, depending on what your needs are. The important thing is the X at the end of the model number to indicate the PCI-X version of the card. There's also a 3080E which is PCI-Express, so stay away from that!

uunix wrote: When people come round your house and say.. 'wow .. what do you do with that stuff?' [Your' SGI gear]

What do you say?

"Everyone needs a hobby."

Some people seem to think that you need to "do" something with computers, because those people only see computers as tools at the office. But not people like us Nekochanners. I like the old systems because they're very different from the stuff I use for daily work & productivity. Learning about those differences is something I'm interested in that's "not work". Why do some people own golf clubs? Why do some people own fishing gear? To play around with and have some fun. Same with computers. I don't understand why they have to be used exclusively for productive work. Fun and relaxation is a valid excuse to own golf clubs and fishing rods, so why not computers?

I think the best answer I ever heard (probably on the cctalk mailing list) was, "Some guys like to fix up old cars. I like to fix up old computers." That seems to get the point across.

MrBill wrote: I also keep putting off creating a proper symlink so i can call things in /usr/nekoware bin. I have not been able to read the documentation for lighttpd either. again, i think i need to make a sym link to the man pages or something, but i am not sure.

Symlinks aren't necessary. All you need to do is adjust the PATH (to execute programs) and MANPATH (to read documentation) environment variables.

Assuming you're running the default shell (which is csh on IRIX, IIRC) add the following two lines to your ~/.cshrc file:


I use the bash shell myself, so the above might not be quite correct for csh. If you also use bash, then edit ~/.bashrc instead and add:


A few notes:

1. You can add /usr/nekoware/bin to your existing path by referring to $PATH as shown above. The same doesn't necessarily work for MANPATH unless you've already set it. By default MANPATH is empty, which means that man uses a path hard-coded into it. Setting MANPATH will then override (rather than add to) the hard-coded one. So when setting MANPATH you typically also have to include the defaults rather than referring to $MANPATH.
2. Some packages put their documentation in share/man while others just use man. So it's usually necessary to include both.
3. IRIX ships with preformatted man pages in the catman directories, so you need to include both man (unformatted) and catman (formatted) directories in your MANPATH for standard IRIX stuff. I don't know of any Nekoware packages that use catman, though.