The collected works of smj - Page 10

I remember everybody who came to see the then-new 5000/200 we had on loan to the uni for demos and testing code was gob smacked at the idea of putting a box with almost half a gigabyte on their desk. Might've been possible with other platforms but these were much closer to being in-reach of humble grad students and post docs...

Any idea roughly when that change occurred? Which models or types of graphics cards, etc?

Thanks, good to know!
--S.

Aaron's rant appears to be from 2008 - just over 5 years ago. Hey, I have to remind myself how long ago that was now too...

Bummer - the whole thing seems pretty sad.

So the other Nekothread points to a fixunix.com thread that dates from five years ago. Any idea of the intervening four minor versions (2.3 -> 2.3.4) have addressed the problems in the initial branch?

So we have an LGPL version of Motif 2.x that's bug-competitive with KDE and GNOME? I suppose 2.1.x is still restricted? I guess not, having poked around opengroup.org -- so long as it's delivered on an "open source" platform. Sorry if I'm repeating things previously mentioned. Hey, at least you can register and download a bunch of stuff...

Hooray, binary packages from 2000!!

EDIT: Hrm, "THE OPEN GROUP PUBLIC LICENSE"

How fast can anybody punch those goofy round keys? Where did an experienced operator top out on one of those horrid keyboards?

Nice job, hamei.

I'm mostly free of any urges for a real TTY. There's a tad of nostalgia because for one year every other week I used one to learn a trifling amount of BASIC one some unidentified machine that the Philadelphia school district made available. Still have the printouts on that characteristic yellow paper, somewhere.

Impressive Goldbergian devices, and certainly deserving of some respect for the role they played for decades if not for the objective quality of the design.

Recently a photo of my "office" setup back in 1990 came to light. For some perverse reason this is the only photo I've found of my IRIS 3130. Must be fairly early in my stewardship, because fairly soon I cut a hole in the floor and put the machine in the basement and just had the keyboard/mouse/monitor there...

Well, terrifying to think how long ago that was - I only bear a vague resemblance to the kid in the chair now.

I still have some of those hard drive platters, but gave at least half away. At lunch one day we both left our office - one of us should have stayed to handle calls, but... - and walked to the Surplus Property Office. A wonderful dark and dusty place with all manner of old stuff piled up. I probably paid $10-20 for an 8-10 platter pack and proceeded to start disassembling the spindle and bearings in the office that afternoon.

There was another day where we invented some reason to head to one of the storage rooms in the basement of Building 10. I forget what we were ostensibly looking for - what I remember is finding literally pallets of printouts I believed came from MULTICS systems, though I couldn't say what all that PL/I was actually part of - the OS, some libraries, or an application/project.

Sadly, I ended up just goofing around with it. GL2-W (what they called the System III UNIX port) was already fading away by 1990, and I had no docs on the OS or on IRIS GL. I found it difficult to translate much of what I was doing during the day with Ultrix and SunOS, each with plain X straight from the Consortium. So I fiddled with and trivially modified the GL demo programs, tried to get UUCP working, recorded a lot of sorties with "dog" to fly against, and struggled to get emacs to build.

When the monitor died after a few months, I decided the beast wasn't doing me much good since I couldn't really come to grips with the software. So I sold it on, only recovering my $2k, and bought a Sun-3/140, classic Sun-3 storage shoebox, a 300MB CDC Imprimis drive, and a Telebit Trailblazer. Tempting to think I should have kept the 3130, but unless I was going to seriously attack the graphics it was probably the right call for that period.

Seems reasonable. What do you plan to do with it?

Seems reasonable. My TiBook is convenient for browsing, though prone to showing a spinning beach ball too long after waking up from sleep mode...

Oh, different MrBill than I thought - welcome either way!

Even if you have a compatible optical drive, swapping physical CDs gets old fast. When you get your IRIX media you'll want to have a look at (Harry) DeBug's IRIX Netboot Appliance, or DINA. Check out the wiki page here , and you can find Harry's official page here . The v1.0 appliance needs some configuration out of the box, so I'd highly recommend keeping that wiki page handy. You'll also want a reference on the IRIX install process, which you can find by skipping down through this netinstall of an Octane from FreeBSD wiki page. See also Ian Mapleson's IRIX installation guide and netboot guide .

Good luck!

You probably have good reasons for this, but still it begs the question: Perhaps given the low running time, it's worth a little more effort to try and uncover the cause of the problem?

Looks good, Pentium! What's the Origin up top hooked up to?

Glad it's finally working for you! OS installation can have a pretty steep learning curve, something easily forgotten as the industry gets closer to a monoculture (or tri-culture).

In addition to the netboot/installation process, DINA is setup to act as a local nekoware repository.

Hrm -- it looked to me like it might be two different cables. I haven't gotten close to any O2k gear in a long time, but I was wondering if he might have managed to hook the O2000 up to one or two O200s at the top of the stack...

It was a tempting lot, with respect to that MultiMax.

I know you're here for help with the Onyx, but if you have the time and inclination please feel free to post as much as you'd like over in "Miscellaneous Operating Systems/Hardware."

I noticed that but thought I'd bitched enough for one day. Yes, with a single page (no multiple tabs) the window title updates as expected. But once you start opening multiple tabs, the window title seems to get set to the title from the last tab or page opened. Then it didn't matter if I close that tab, the window title stays the same. if I click on links in a remaining tab, no change to the title. If I type a new location in the location bar, though, the title will update. And the same if I open a new tab.

About this time last year, mia requested that some programs be packaged in this thread . Among them was something called pigz: a Parallel Implementation of GZip .

More recently I was looking for something simple to port and package, and this seemed to fit the bill - especially as testing it would be a good excuse for firing up the Origin. I've done all that and uploaded neko_pigz-2.3.tardist to ftp.nekochan.net/incoming. I'd appreciate a cautious eye from somebody familiar with the packaging process. This package includes release notes, spec and idb file, and the original sources and patches so it should be possible to see where I might have gone wrong.

I tested the program itself with a 1.1GB sendmail logfile. Stock /usr/sbin/gzip took an average of 244.4 seconds over three runs to compress at level 9 ("gzip -9") on an Origin 300 @ 600MHz. Limited to one thread pigz averaged 243.1 seconds on the same system, and when using all 8 CPUs it averaged 36.9 seconds. Increasing the buffer/chunk size changed average timing as follows: 256KB, 35.1 sec; 1MB, 34.4 sec.

Uncompressing the gzip output with pigz, using just 1 thread took 24.9 seconds (single run, but typical of others). But the same operation with 8 threads took 32.5 seconds - again a single run, but other runs were within a second higher. During the 8-way decompression runs pigz was typically only using 2/3 to 3/4 of two CPUs, though sometimes that was reflected as roughly that level of usage spread across as many as five CPUs.

For more information about pigz, go to: http://zlib.net/pigz

If it will help in porting a modern browser to IRIX, then yes. Or no. What I'm saying is, do whatever is best for the nekochan community.

Kidding aside, go read Dan Savage 's advice column if you aren't familiar with it. The only person's opinion who matters is your own.

Got a little ahead of myself - next time I'll PM somebody and get it moved into /beta before I post... PM sent, it'll be along sometime soonish-like.

Er, right. I can't help but think of the time somebody suggested that they preferred to walk instead of flying around Second Life because they "enjoyed the exercise." To which a fellow resident replied, "They're avatars. They don't need a sodding fitness regime!"

The package is in /beta now . Share & Enjoy !

Thanks for the quick test - I take it the dependency on zlib worked alright? I used the package version from the zlib in nekoware/current, which might cause a complaint for somebody using an older version - but then, that seems like what it should be doing...


I just pulled the package from /beta, opened it in swmgr, and the description is about the same length as neko_libidn. Granted it's on the long side, but it's hardly the only package with a description that length. Check out neko_fvwm or neko_wxGTK for some long names.

IMHO package descriptions that just repeat the name of the package aren't terribly helpful, so there's a trade-off to be made...

I did leave off the software version number (2.3) which I can fix with a respin. Is there something other than that and length? The format seems to be " package X.Y.Z description "


You mean how I used neko_pigz.sw.eoe instead of neko_wget.sw.wget and neko_pigz.man.manpages instead of neko_wget.man.wget ? I was just following the wiki guide and what swpkg(1m) suggested...

I did notice that I put the relnotes in the "man" image instead of "opt" (?? pkg .man.relnotes instead of pkg .opt.relnotes), but that was because the discussion over here indicated the relnotes shouldn't be optional any more, and since "opt" is optional...

At any rate, if I can understand this better I'll happily correct it and add some guidance to the wiki page on packaging.



If the package doesn't follow the standards, I'd rather respin the package. Just need to understand where I veered off.


That's no typo, it took several seconds longer trying to use multiple threads -- in this specific example. Maybe a much larger compressed file would yield different results.

I'm running tests with an 11GB logfile, but in the meantime I thought the following passage from the pbzip2 man page was interesting:

Maybe there's a similar structure to the gzip output stream. Last time I only decompressed with the opposite tool from compression, since I was using that as a verification for the pigz build. After I've finished the compression timing runs, I'll see if decompressing the pigz-compressed files with multiple threads/CPUs offers any speedup.

Right now all these tests have been run from a single 10k SCSI drive, so we're going to find a limit there. If I didn't have work to do, I could drag out a couple different drive arrays...

Ran the timing tests again using an 11GB sendmail logfile. Times are the average of three runs compressing that logfile:
Glancing at gr_osview from time to time during runs, none of them kept the CPUs running flat-out - probably hitting an I/O limit with that single drive. The 1MB block size appeared to do the best.


On the decompression side, looks like the gzip scheme doesn't lend itself to the scenario suggested in the pbzip2 man page. Just did a single run of each to see if it was worth pursuing.

Uncompressing gzip-compressed logfile:
pigz -p 1: 5'48"
pigz -p 8: 6'16"

Uncompressing logfile compressed with "pigz -p 8":
pigz -p 8 -d: 6'22"

So that's that for this little informal benchmarking exercise. At least for tonight.

Given that this is a dedicated parallel compression utility, I don't think taking the simple approach is unreasonable. You might wish it tried to use all four CPUs from the beginning on your old reliable Pentium III Xeon machine, rather than second guessing the user. Should it try to infer something about I/O bandwidth and adjust to that?


I'm sure it could be built to adjust the number of threads dynamically during a run, but I can't think of an OS scheduler - kernel code, most cases - that's going to tell the application it should be spawning more threads. Maybe that's just because I should've been asleep four hours ago...

Seeing this thread again prompted me to go have a look at my O300 bricks, and one of them actually has a complete set of sliding rack rails attached. I'll try to get part numbers by the end of the week, need to shift some things around to get at them.

It's often good to check for the latest/last version of Kermit for a given platform. Kermit95 supports Windows back to at least NT, OS/2, and several others. It offers dozens of terminal emulations from ADM3A to Wyse 50, including the usual DEC suspects. But you also get telnet, ssh, Kerberos, and on and on.

Kermit95 page at The (Newish) Kermit Project .

I don't get it - which SGI machine is that supposed to be?

I've used a Dell 2001FP with several Octanes, both MXE and VPro, using the correct 13W3-HD15 adapter. This monitor is listed in the "Sync-on-Green tolerant monitors" section of the [http://forums.nekochan.net/viewtopic.php?f=3&t=8113 O2 Hardware Aggregator], so I'd guess others in that category would be safe. In general, while some won't work it seems like there are plenty out there that will.

But the O2A's list may not include anything you see at the local Dubai nerd yurt. It might be best to stroll to the larger, more luxurious nerdserai or geek fondouk where they will let you return or exchange it if it doesn't work...

Nice summary, SunForSun. And of course that should work whether you're running OSX or Windows.