Nekochan Net

It's still around, called SeaMonkey. Worryingly it's faster than Firefox sometimes.

_________________
<>

As a user I second that.

But as bri3d says, as a developer I could not live without a workhorse for compiling some megabytes of source I need to do sometimes.

_________________

<- MicroVAX 3500 <- DECsystem 5500 <- MicroVAX 3300
Pictures of my collection: www.pdp8.se

Well the hell with it. I still want to try!

I use both, because each has a couple of things the other doesn't have, at least for the IRIX builds.

Firefox 'remembers' what tabs were open if it suddenly dies, or more usually because I've shut down the
system. Next time it starts up, the tabs open before are restored. I like this. Each tab has its own 'X' close
icon, there's an Undo Close Tab option and I like the positioning of the 'New Tab' option. However, it's not
so good for sorting out helper applications and I can't get gnash to work with it.

Seamonkey doesn't remember what tabs are open, but gnash works ok, though only in a separate window
(any way of getting the animations embedded in the Seamonkey window where they're supposed to be?).
It doesn't have an Undo Close Tab option and tabs don't each have a close-tab icon, but Seamonkey is
perhaps a bit faster.

Other minor difference: if each browser is behind some other window, pasting a URL onto the browser will
make Firefox pop to the front, but Seamonkey will stay where it is. I find both behaviours useful depending
on what I'm doing.

The only thing that lets both browsers down badly on IRIX IMO is how they deal with Java or whatever it is
that some sites use which can make both browsers crawl.

Classic example: try viewing any main article on tomshardware.com, it takes ages to fully come in, the page
hangs like it's waiting for stuff, and often there'll be a popup saying a script has locked up (& does one wish
to stop the script, etc.) On Windows/Firefox the site works fine. Other sites seem to be written in a different
way though, eg. Anandtech works ok with both IRIX Firefox and Windows Firefox. For example, see:

http://www.tomshardware.com/reviews/gef ... 684-8.html

Compare this to:

http://www.anandtech.com/show/3809/nvid ... 200-king/6


hamei, do any tabbed browsers use multiple threads for tabs?

Ian.

PS. There are (or were) more than 90 different browsers btw. All sorts of custom versions, internal company
versions, restricted programs iIn the mid/late-90s, 7% of all accesses to my SGI site were from .mil domains),
text-only versions, etc. I used to keep an eye on logs to see what was being used, maximise the range of
browsers which could access my site ok.

More productive to fart in a thunderstorm.

Ian.

I'm not hamei - but yes. Google Chrome and Internet Explorer 8+9 both use entirely separate processes for each tab, and Chrome uses a new process for each plug-in as well (useful for the ten thousand times a day Flash crashes). Firefox is just starting to catch up in the plug-in department, and multi-process/threaded tabs are not coming anytime soon as far as I know.

_________________
<>

More likely the current SGI do not even have the sources anymore. They just don`t want to admit it openly. Otherwise I believe if they really wanted, they could release the source under a more restrictive license.

Besides, it is only in their best interest to kill the MIPS workstations and get people to buy their new Intel crap.

They're already dead. Anyone buying new is buying Intel for workstations as there are no other options. For servers you have Intel and POWER (SPARC's still around, but Oracle doesn't seem to have a firm plan going ahead yet beyond "say as little as possible").

SGI's not threatened by hobbyist upgrades that have no commercial support, we're just not worth the trouble from a business standpoint.

_________________
Damn the torpedoes, full speed ahead!

Systems available for remote access on request.

(single-CM)

having worked in similar large systems, high tech, engineering for 30 years, i can confirm comments about the sources, schematics, code, etc... having a very high likely hood of being impossible to resurrect. prior to ISO9000 there was no incentive to commit design documents to any kind of archival control beyond supporting the product until EOL. Often the only source of detailed info was lock in the heads of design engineers. after everyone figured out how ISO9000 was, and nobody really cared (i.e. maybe, just maybe, the federal ties with sgi some of this was mitigated), the process was informal again. it just caused more disconinutiy is whatever people were using to document the product. after 15+ years for these product, the stuffs gone guys; nobody knows what anything really is, or where it might be found, or how accurate it is. you can tell from the design's, documentation, and public statements of engineers just how things progressed.

you can keep asking, but IT WILL NEVER HAPPEN.

_________________


DECUS Member 368596

btw: someone needs to make a sticky (as if that is going to work) to bring Ian's and SAQ's response to the top which concerns overriding constraints on the problem of getting anything remotely considered IP from sgi. seriously; the licensing issue, and an official answer closes the subject forever...

_________________


DECUS Member 368596

Good idea.

And to all, a couple of things I forgot to mention...

a) Please don't think I didn't press this issue. I did, vigorously. The degree of which could perhaps be conveyed by the fact that
Bo Ewald was even willing to spend time discussing it with me at all, given he was right in the middle of the Rackable buyout back then.

b) Bo forwarded my queries to Bob Ainsworth (Sr. Director, RPG), who phoned me for a lengthy chat about the PROM issue and other things.

I don't think I could really expect to ask any higher up. Since the Rackable buyout, I no longer really know anyone at the new SGI.

Anyway, surely the energies of those with appropriate skills here would be far better spent porting the open source version of Google Chrome
to IRIX? (ie. Chromium) With the recent changes to GCC for MIPS support, this should be easier, at least with respect to obtaining good
performance, and it would be threaded so the issues hamei pointed out would no longer be a problem.

Ian.

yes i remember berating the uselessness of it all :) however, it should be put to good use convincing others.

RE: Chrome, as long as it has 'ad blocking', no memory leaks, not dog slow, go for it.

_________________


DECUS Member 368596

Shit. I was hoping to wake up in Denver one day with a new identity

bri3d, do you know if they programmed it to start off with one thread specifically to listen for user inputs ? That was the cure for the OS/2 synchronous input queue problem. Okay, so the siq was bad design but the result of making programmers use a separate thread dedicated to listening for input was (partially) that the Workplace Shell was the most responsive desktop I've ever used. Equal to Irix and better than Solaris, Windows, even BeOS.

I can't say about browsers but the tabbed interface is really old. Ami Pro 3.1 (Windows 3.1) used it and the developer's toolkits for OS/2 all had a tabbed "notebook" setup. My fave email client used the tabs and you could go from tab to tab starting processes which would happily run while you proceeded to the next tab. The program itself and the user interface never became unresponsive. Never. Fireflop seizes up if you look at it crosseyed.

This was fifteen blankety-blank years ago. Those people are such buffoons, do you know if they write their code in crayons, bri3d ?


That's pretty cool, Ian ! Did you happen to ask him if he was wearing his big red nose and floppy shoes ?

Here's some info I was sent about GCC/MIPS support, etc. I hope it proves useful, and perhaps someone may actually try and
port the kind of browser which would satisfy everyone, instead of just moaning about there not being a decent browser...


**********************************************
GCC 4.4.x has added the following support for MIPS:


MIPS
* MIPS Technologies have extended the original MIPS SVR4 ABI to include
support for procedure linkage tables (PLTs) and copy relocations. These
extensions allow GNU/Linux executables to use a significantly more
efficient code model than the one defined by the original ABI.
GCC support for this code model is available via a new command-line option,
-mplt. There is also a new configure-time option, --with-mips-plt, to make
-mpltthe default.
The new code model requires support from the assembler, the linker, and the
runtime C library. This support is available in binutils 2.19 and GLIBC 2.9.
* GCC can now generate MIPS16 code for 32-bit GNU/Linux executables and
32-bit GNU/Linux shared libraries. This feature requires GNU binutils 2.19
or above.

* Support for RMI's XLR processor is now available through the
-march=xlrand -mtune=xlroptions.

* 64-bit targets can now perform 128-bit multiplications inline, instead
of relying on a libgccfunction.

* Native GNU/Linux toolchains now support -march=nativeand -mtune=native,
which select the host processor.

* GCC now supports the R10K, R12K, R14K and R16K processors. The canonical
-march=and -mtune=names for these processors are r10000, r12000, r14000and
r16000respectively.

* GCC can now work around the side effects of speculative execution on
R10K processors. Please see the documentation of the
-mr10k-cache-barrieroption for details.

* Support for the MIPS64 Release 2 instruction set has been added. The
option -march=mips64r2enables generation of these instructions.

* GCC now supports Cavium Networks' Octeon processor. This support is
available through the -march=octeonand -mtune=octeonoptions.

* GCC now supports STMicroelectronics' Loongson 2E/2F processors. The
canonical -march=and -mtune=names for these processors are loongson2eand
loongson2f.


On the minus side GCC-4.5 has deprecated bootstrapping and support for anything
less than IRIX 6.5. 4.5.x will still support older IRIXes, but the next major
release 4.6 will not. The "deprication" means it will go away in the next major
release.

If the guy at Nekoware can bootstrap a GCC-4.4.3, then they may be able to get
some decent performance. It also means that they will be able to compile firefox
easier since gcc is what is used to compile it on Linux.

Another browser approach would be for them to port the Google Chrome browser. It
is a webkit based browser (like Apple's Safari). It is much lighter weight than
firefox. The open source version is called Chromium. They use GTK for their
widgets and windowing on Linux, which is the fastest of all the alternatives.

I saw in the archives that their main problem with Firefox is getting it to
compile under MIPSPro. There are a lot of advanced template things that the
MIPSPro does not handle in the same way as GCC. This is common with C++ (it is
getting better as the standard is evolving and the "gray" areas are getting
cleaned up).

The URL for a summary of the GCC-4.4.x changes are here, you will have to
scroll down to the MIPS architecture category.

http://gcc.gnu.org/gcc-4.4/changes.html


For the 4.5.x changes (the deprication of any IRIX before 6.5), look under
"Caveats" at the top.

http://gcc.gnu.org/gcc-4.5/changes.html

The URL for the chromium project is here:

http://sites.google.com/a/chromium.org/dev/Home

They mention a port to Solaris:

http://code.google.com/p/chromium/issue ... l?id=30101

The javascript engine does the same trick as Apple's squirrelfish, they use a
machine code substitution for some Javascript primitives. It looks as if Google
has only done an Intel version of theirs. The Chrome browser only run on Intel
architecture OSes (Linux x86/64, OSX (intel only), and Windows.

Apple's squirrelfish has a PowerPC port and an ARM port (of course for the
iPhone/iPad).

Just found this:

http://www.favbrowser.com/next-firefox- ... se-webkit/
**********************************************


Ian.

Here's something you might find amusing : the current 'Loongson' started out life as the 'Godson'. Godson is a sound-similar to the real Chinese name, gaosheng -- which means "dog shit." True