OT: cosmo, HTML GUi editors, graphics, games, computers, etc. (was Re: More on fP 6.0 features)

[Bill Vermillion]

> On Tue, Oct 26, 2004 at 07:56:39PM -0400, Bill Vermillion may or may not have
> proven themselves an utter git by pronouncing:
> > 
> > You just haven't had the pleasure of working with a good
> > HTML/web editor/construction tool then.

> Apparently.

> > For about a year or so I was using Cosmo.  It shipped included
> > in the SGI Indys.  But when you pay $7K to $15K for a workstation
> > you expect a bit more for your money.  The $15K version we had
> > there was capable of real-time video editing and could also read
> > and write audio DAT files.

> > Not much bloat at all but productivity was truly amazing.

> That's a -bit- more than your typical HTML layout package was
> delivering when I last looked. That's an understatement, btw.

Well it did come with the system.  At prices like that you do want
productivity tools included.

> > Cosmo was great for quick development and it was excellent for
> > bringing in graphics and reszing them as you went.

> Sweet. Almost all the graphics work I need to do though, I've
> done before the actual page design, in separate programs.
> So that would be of little use to me, as most of what I did
> wouldn't rescale--at least the 3D doesn't usually fare well.

And I forgot what the name of the other program was that you could
use.  It was amazing at that time.  You would see a scene and you
could pan 360 degrees around it - using photographs made with a
camera that pivoted 360 degrees to expose the pictures - and then
stitch them together.

This was when SGI was riding high with film work like Jurassic
Park.  I think I sent Jay a copy of the 8MB .tiff file they had
that was part of their poster that said "Building a better
dinosaur".

> > I can beleive that - but for intricate graphics the Cosmo was
> > really nice.  And with the MIPS chips [RISC processor] it was fast.
> > [You should be able to infer that from the real-time video editing
> > I mentioned above].

> I don't get it. I have a Nintendo 64. The thing was -supposed-
> to perform like mad, but it always ran slower than it should.
> Every single last person I've talked to over the years said
> that it was because the MIPS chip they used wasn't up to the
> challenge. I thought MIPS were really to be avoided ever since.

That's sort of like not having good luck with a system running
an Intel 8008 and blaming all of Intel - missing such things
as the Xeons with 4MB of L1 cache.

MIPS came in all sizes and shapes.  The Indy's were the 4000
series - that was basically a 40x64 design.  And we had 
a Challenge DM and XL - huge beasts - 8 hot swap drives in one
with 4 CPUs.  [My partner literally stole that at an auction - and
then sat on it till it was worth what he paid for it instead of
selling it for 10 times his cost :-(].

I forget which chip was to be the end of the line - 10000 or 12000,
but then Intel got so far behind with their 64x64 chip [the failure
to deliver was one reason Project Monterey fell apart and SCO,
IBM and I think HP parted company on that].  So they came out with
the 14000.  It and the Alpha were the only true 64x64 chips
available.  Real screamers.

> Maybe they overtaxed it in some games, but I'm talking -first-
> generation games here--and usually you don't start stressing
> the console's limitations until about the fourth year and
> generation of games.

What model number MIPs.  They had at least as many models over the
years as Intel did.

...

> I suspect SGI's were nice to use for design, multimedia, and
> the like. The only experience I have with them personally is
> trying to compile things on them for an acquaintance at a
> university whose cluster was running IRIX. Oh, ye gods, I'd
> rather port to SCO, thanks. IRIX had to be -the- least friendly
> platform for which you could port that I'd seen at that time.
> I'm hard-pressed to recall another experience as bad as that.

I didn't have any problems.   What version of IRIX.  When the 5.3
?? came out and all the COFF files went away for ELF, the install
was the nicest I've ever run.  It checked everything.  And the
application installs were the best I've ever seen. Supreme
dependancy checking for everything with choices all along the way.

We also had one that we were storing - and it was a big beast.
And had been retired from TNT after performing several years
of video production.  The power to weight ratio had to be about the
worst around by the time it arrived at our doorstep.

> But the way they were designed, and the way you've described
> them before, I get the distinct idea that the target market was
> the type that was never really supposed to get under the UI
> unless they were writing the applications -for- the UI. Wasn't
> even the fsck graphical? I seem to remember you mentioning that
> a few years back.

You had a choice.  I ran in console mode a great deal of the time.
Working with vi with READABLE lines of 200+ character lines all
on the screen was nice.  I worked in text mode most of the time.

> I do know that IRIX was rated one of the two worst platforms
> you could put on the net unfirewalled. Funny thing is that one
> old acquaintance of mine originally from here in Louisville
> worked at a competing ISP that had dual Challenge's for their
> servers. I have to wonder about them. :)

I think I mentioned that too.  A friend of mine who retired with a
big wad of money after 4 years of 24x7 on call when Verio bought
out the ISP he was head tech at once told me that he'd never
put an SGI or and SCO system on the 'net.

He was an engineer and worked in process control and automation and
I remember when he first moved to Unix.  Then when several of us
were running Microport and he had the largest node in the area,
and often in the top-100 groups - he kept running out of inodes.

It was the old AT&T bug that if you had a lot of activity - and
running news spools and expires got you a LOT of activity - all of
a sudden you'd have no inodes left but lots of free disk space.

So one day he sat down, disassembled the kernel, traced the code,
and found the problem.  AT&T had screwed up in re-scanning for free
blocks, and in one spot the system thought it had scanned from the
front and it had not.  So he developed a binary patch that all the
Microport users had, but it took almost a year before AT&T
put the fix into the releases and the rest of the Unix world
didn't have to worry about that but.

He's on a first name and phone call basis with all the old 'net
gurus - whose names are recognizable to almost all.

So if/when I get a really bad problem I can give him a call.

So I believed him when he said he'd never put those machines on the
.net.  I was running a pair of Challeng servers.

I think they were 400MHz with ECC memory - probably 500MB.

Then after having someone use the system as a mail RELAY [this was
in the early days], I got that patched, and then built up
a FreeBSD 2.7.

That machaine was running a 120MHz Pentium with 128MB of RAM.
It ran faster than the SGI.   But the FreeBSD's of that era
were exceptionally lean.

Bill

-- 
Bill Vermillion - bv @ wjv . com