Slashdot Mirror

Actually, I just looked it up, and you're wrong. On Page 4-6 of IA-64 Application Developer's Architecture Guide, Rev 1.0, it says specifically, and I quote: (emphasis mine)

The shift right pair (shrp) instruction performs a 128-bit-input funnel shift. It extracts an arbitrary 64-bit field from a 128-bit field formed by concatenating two source general registers. The starting position is specified by an immediate. This can be used to accelerate the adjustment of unaligned data. A bit rotate operation can be performed by using shrp and specifying the same register for both operands.

So there.

Tee hee! Actually, it's kinda interesting, speaking of 4GB RAM, the next workstation I'm scheduled to get at work will have ~4GB RAM in it, and two happy UltraSPARC III CPUs in the ~800MHz range. Whee! (And to think those US IIIs came out of our fab just up the street! Whoo hoo!) The design jobs that run on my workstation really use that much RAM too. They're not my jobs though -- I'm a software guy. All our workstations are in a load-sharing queue, offering gobs of MIPS for crunching all of design's jobs day in and day out. I can kick the jobs off my node during the day as needed, though, which is nice, especially on my current workstation which only has a half-gig of RAM.

As for light, content-free entertainment, you can get that anytime by setting your threshold to -1. I find it rather amusing. :-)

1. Many modern CPUs perform 'Predication', often called something speculitive execution insted. Processors such as P6, K7, and EV6 all perform this optimization.

This is somewhat true but not completely. Predication is a form of speculative execution, but is qualitatively different from the speculative execution that most CPUs do when they branch-predict. The problem is that these architectures don't really have a way to execute down both sides of a branch. To equal what predication provides, you'd actually need to be able to fetch down several code paths in parallel and know which instructions to discard. Icky. Predication allows that to happen in a single code path, because you can put both "if (cond)" and "if (!cond)" paths directly in parallel, or even better, "if (cond1)", "if (cond2)" ... "if (condN)".

Predication is very useful for eliminating short branches and flattening small switch-case statements into effectively straight-line code. It's a much, much, much more effective method for speculative execution than trying to fetch and execute down multiple code-paths.

Not that you could do rotates from C or anything...

The preprocessor is supposed to strip comments before processing preprocessor directives, so that commented-out directives don't get processed. In ancient compilers, the comment was completely stripped in some compilers, leading to the following idiom for symbol concatenation:

• #define CONCAT(x,y) x/**/y

As you can imagine, it may have worked, but it wasn't hugely portable. ANSI put its foot down and stated that comments are replaced by a single character of whitespace, and so the CONCAT(x,y) macro above won't work. ANSI, recognizing that something like CONCAT(x,y) might actually be useful, though, specified the ## operator:

• #define CONCAT(x,y) x##y

Now what does this have to do with C++ comments?

Well, nothing in C (or I believe early C++) says that the preprocessor need be aware of C++ style comments. I beleive early Cfront-based C++ compilers just reused the existing C preprocessor. The result is that the C++ comment gets included as part of the macro. Wackiness ensues when the macro is used in the middle of a line:

• #define MYCONST (42) // The answer!
  
  x = MYCONST;
  y = 69;
  

In that snippet, on older compilers whose C preprocessor is not C++ comment aware, you'll get x = y = 69; (spread over two lines, of course). Whee.

Well, it seems Sharky glossed right over this one. They don't seem to get what rotating registers are for. They just make some vague statement about them working well for streaming things or something. *sigh*

One of the chief techniques that VLIW (and EPIC) processors will use to extract parallelism from looping code is Software Pipelining. This technique extracts parallelism across multiple loop iterations by scheduling them in parallel. The most popular form of software pipelining, Modulo Scheduling, offsets the loop iterations by a fixed interval known as the initiation interval.

The minimum possible initiation interval for a software pipelined loop is limited by two factors: The resource bound for the loop, and the recurrence bound for the loop. The resource bound is determined by counting up all the resources the loop uses and finding the minimum # of cycles (ignoring dependences) that you could pack everything into. The recurrence bound is a little trickier.

The recurrence bound is the bound imposed by loop-carried dependences in the loop. That is -- dependences that feed from one iteration of the loop into future iterations. For instance, in the following loop, there's a dependence from the result written to "z" on one iteration to the calculation of "x" on the next:

• for (i = 0; i &lt N; i++)
  {
  • x = z ^ 3;
    y = x + 42;
    z = y * 69;
    
  }
  

On an architecture with infinite resources, this loop is still recurrence bound by the path from x to y to z, back to x. So, what does this have to do with rotating registers?

Well, so far, I've just described flow dependences. If you pick up a copy ofHennessy and Patterson's Computer Architecture: A Quantitative Approach , you'll see that this corresponds to "Read after Write" hazards -- meaning a later instruction reads a result written by an earlier instruction. There are two other sorts of hazards to watch out for: Write-After-Write (two instructions writing to the same place have to write in order), and Write-After-Read (a later instruction might clobber a value read by the current instruction).

Write-After-Read hazards are particularly interesting in the case of software pipelined loops. First, some terminology: a value is live from its earliest definition to its last use. In the example above, x is live from the first statement until the second within the body of the loop. In a given loop, a value may be live for quite a long time. However, the initiation interval for the loop might be quite short. This can lead to problems, such as violated Write-After-Read hazards.

Suppose we have the following code:

• for (i = 0; i < N; i++)
  {
  • b = a[i];
    c = b + t;
    d = c + u;
    e = d + v;
    g[i] = e + b;
  }

Suppose we can fit all of this into a single cycle loop on our hardware because we can do four ADDs in parallel, plus the load and the store. Notice that the instructions in the middle are just dependent on each other, and on constants that are initialized outside the loop. Notice that the final instruction uses the second-to-last ADD's result as well as the value we loaded initially.

If we try to put this into a single-cycle loop, we'll have a problem, because we'll load multiple values into b before we even get to the calculation which finds g[i]. Oops. This is because the b = a[i] from a future iteration has moved up above an instruction from the current iteration which reads b--that is, we've violated a Write-After-Read hazard. In software-pipelining parlance, this is a "live-too-long" problem. The value of b is live across multiple iterations.

In a device without rotating registers, you solve this problem by manually copying b to temporary registers. In C code, this might look like so:

• for (i = 0; i < N; i++)
  {
  • b = a[i];
    b1 = b;
    b2 = b1;
    b3 = b2;
    c = b + t;
    d = c + u;
    e = d + v;
    g[i] = e + b3;
  }

Fine, except that can increase codesize, and in some cases impact performance. (It is, however, the technique of choice on processors that implement a minimum of hardware, so as to save power and cost.) Rotating registers alieviate this by performing these copies implicitly whenever the loop branch is taken.

So there you have it. That's the scoop behind rotating register files.

Yeah, except the PSX2 doesn't quite put out enough heat to melt the DVDs you put in it...

Ok, Pheon, are you sure of this? What if your L1 cache is on chip and super fast? Isn't this just as good as having a zillion registers?

Not really. Cache memory is never truly as fast as registers. The primary reason (in a parallel architecture) is porting. A register file has ports which connect it to all of the functional units. (A port is a connection from a memory cell to a device which reads or writes that memory.) Multiple functional units can all access the register file in parallel. In contrast, most memory is single ported. Multi-porting a memory either slows it down, or drastically limits its size. When you throw in the cache tag RAMs as well for an L1 cache, you further limit its size and speed, and add a layer of indirection that simply does not exist with registers. And that's just some of the hardware reasons why L1 will always be slower.

In the compiler, things get messy as well with memory operands, as now the compiler must disambiguate references to these operands to know which operations may be safely moved past each other. In languages such as C, you have the unfortunate problem that pointers can point just about anywhere. Many compilers are unwilling to consider pointer arguments as pointing to storage that's independant of even the function's local stack frame, and so you get artificial scheduling hazards which limit the parallelism that the compiler can expose in the code.

Other fun reasons: You can't do register renaming on memory locations. You actually have to do memory allocation for memory (pushing values on a stack IS register allocation). You take memory faults and cache misses at least occasionally for memory -- you NEVER do for registers.

So no, memory can never be as fast as registers. It can get close, but never quite 100%.

It was supposed to be the first mass-market VLIW chip, though Transmeta beat them to it.

Erm, and how exactly do I program Transmeta's VLIW assembly language? What's that? I can't? Although Transmeta's TMxxxx family of CPUs uses a VLIW architecture presently, nothing constrains them to a particular VLIW instruction set or even to be VLIW on future parts, since the only interface they expose is their emulation of the x86 instruction set. They may as well have a little hamster running in his wheel in there -- as long as it cranks out x86, it won't change the instructions you program it with. (The hamster might not be as fast as the VLIW, though. ;-)

So, with that in mind, I'd say that Itanium will probably be the first mass market VLIW-like programming platform. Of course, TI's TMS320C6000 DSP was probably the first volume-shipping VLIW-on-a-chip, even if it wasn't targeted at the desktop market. The old Multiflow and Cydra machines of yore never quite got that small.

I suppose you've never heard of Sun's MAJC, eh?

(FYI, MAJC == Microprocessor Architecture for Java Computing.)

Actually, troll, it's pretty common to include the name of the required runtime environment in the name, particularly if said runtime environment is likely to not be the default. Java may be a language, but it also implies the requirement of a JVM. (At least, if you don't have one of the (nonexistant) Java CPUs Sun tried to make.) As you may recall (or not -- you sound like you were born yesterday), when Windows was still fairly new and DOS was still the norm, Windows apps included "for Windows" as part of their name. Such as "MyLeetProgram for Windows 1.25".

Go away troll.

Unlikely. IBM's been working on DAISY for a loooong time.

That works as long as you can identify all of the code cleanly. Particularly outside the UNIX world (think DOS / Win9x), it's commonplace to treat data as code and code as data. (Most UNIX programs just rely on the ELF/COFF file format and don't muck with code vs. data attributes, unless they're doing something icky like GNU C's trampolines which put executable code on the stack.... *blech*)

It's hard enough to write a reliable disassembler that doesn't fall over when it hits a jump table, callback, overlay, dynamic library or other indirect method for loading / invoking code. (At least, one that's reliable in the absence of a symbol table that highlights all of the valid entry points.) What makes you think you can reliably re-assemble a binary for a different target in such a setting?

Not really. Amiga's just implementing a thin virtual machine layer, providing an "ideal assembly language" that provides more control than, say, C, but still provides sufficent abstraction that the code can be targeted to a wide range of CPUs easily. (This is in stark contrast to, say, the Java VM, which is comparitively quite heavy.) You can think of Amiga's virtual assembly as a "medium level language", if such a term exists.

DAISY translates other ISA into its own native Tree-VLIW ISA. Rather than providing an abstract assembly language that gets targeted to a wide variety of CPUs, DAISY is doing the reverse: Take a wide variety of ISAs, and target them to this specialized CPU. Transmeta is similar, although they've chosen to focus primarily on x86 to get the biggest bang for their limited bucks.

Newer GCCs have something like this. Look up -fprofile-arcs -ftest-coverage in the GCC/gprof documentation. I haven't looked super closely at how well it works, but the documentation seems to hint that it's doing similar types of optimizations. Basically, it takes the profile information for each arc in the control flow tree, and uses that to decide how to lay out the basic blocks when it generates the code.

In my limited experimentation, I didn't see much of a difference (too small to measure) using these tricks, so either my code wasn't helped by it (too small?), or GCC was just going through the motions. YMMV.

I seem to recall someone (perhaps IBM's old DAISY website) mentioning that the name DAISY was picked as an obscure reference back to that. Goes back to the old HAL == IBM << 1 thing...

BTW, Transmeta has been working on their stuff since 1995, so the technology mentioned in the 1997 paper doesn't strictly predate it.

I read about Daisy a few years back when I was studying VLIW scheduling techniques and whatnot. The DAISY VLIW is quite different than most VLIWs around. Their instruction word is built upon the ability to execute large numbers of "branches" in parallel every cycle. (As best as I can tell, these "branches" are actually closer to being composite predication conditions in many cases, which is why I put "branches" in quotes.) Their experimental physical implementation could execute something like 8 branches every cycle. Downright weird.

A more traditional VLIW uses predication to convert short branches into a simple "if (cond)" prefix on individual instructions. (This technique is known as if conversion.) Also, traditional VLIW instruction words are flat -- all N instructions in a VLIW bundle execute together in parallel, with no tree structure implicit in the encoding.

All that aside, the DAISY scheduling techniques sound pretty similar to trace scheduling , which was used on the old Multiflow VLIW machines. The actual process of converting PowerPC instructions to individual DAISY operations is mostly search and replace, and preserving program order is a matter of constructing proper dependences between the instructions.

Feel free to ask me questions if you're curious about this kind of stuff. It's my day job.

The poster a couple levels up talked only of letting this mutation spread into the populace, which implies simple reproduction, not genetic engineering. Animal husbandry and genetic engineering are two different things. If I pick a mate because I like some aspect of that mate and subsequently have offspring, is that wrong? Does it matter whether that critereon is "explicitly vital to the existance of the species"?

I find the concept of genetically engineered children to be repugnant. The thread I was on wasn't talking about that though. I didn't miss your point, but it was covered in a different thread that I just chose not to participate in.

If the Males can't see the difference, though, how does this improve desireability (unless it becomes one of those unconsciously perceived bits...)?

Hey, maybe she's into other women, and they decide to have kids by visiting the local sperm bank. I guess that'd be a case of two tetrachromats hooking up and passing their unique genes on, eh? You never know in today's world.

(And if that is the case, I say more power to them! I'm all for a little diversity.)

Actually, depending on how the four colors are distributed, the male children may not be completely color blind, just differently sensitive to color. For instance, suppose the mother has "Green" and "Red1" on one X chromosome, and "Green" and "Red2" on the other. Suppose "Red1" and "Red2" are sufficiently far apart in their response curves that the mother is a tetrachromat. Any sons that she has will still be trichromats.

The reason the reasearchers looked specifically for mothers of colorblind men is that it narrows the search. It means that one X chromosome has both "Red1" and "Red2" on it (or perhaps "Green1" and "Green2"), rather than spread across the two X chromosomes. It makes the search easier, but I see no reason why a tetrachromat must have the two nearly identical colors on the same X chromosome.

With this in mind, I wonder if women just generally have better color perception then men, since they'll tend to actually have up to five chroma channel, since the reds and greens in both X chromasomes aren't going to be identical to each other. The differences might not be large enough to really affect their vision deeply, but it might add a subtle touch. Thoughts? Maybe that's why my fiancee and I always argue about what color something is...

As you point out, it does no good in the framebuffer.

Actually, if your video card does real-time compositing with an external video source, that alpha channel is pretty darn handy.

No, but possibly their trademark.
--
Program Intellivision!

That's ok, we can sue them for infringement, since we didn't give them a license to do so. ;-)

I currently burn CD-Rs of all of my music to put in my CD changer in my car. This is due to the fact that I get higher density that way (I can fill those CD-Rs up to 74 minutes vs. the 45-55 minutes that are on a typical CD. And yes, I know about 80min CDs, but the firmware in my car's CD changer gets confused by them). This is also due to the fact that my car tends to damage the CDs over time (long radial gashes along the CD when I hit a bump, combined with the extreme heat of Texas summers). By putting my music on CDRs, I protect my original investment. As an added bonus, I can bring along just the tracks I'm interested in. Anti-circumvention policies applied to new media would restrict my ability to make these lawful copies.

Eventually, I plan to get an MP3/Ogg Vorbis player installed in my car. (Probably when I get my next car.) By the time I get it, the music industry is likely to have a favorite new digital music format with some sort of access control. Meanwhile, I'm going to be trying to put all of my music into my car in Ogg Vorbis format where possible, to provide the highest possible quality with the least likelihood of getting sued by Fraunhaufer. I won't be able to do that legally, though, if the new music formats have some sort of "encryption" ("XOR 64" anyone?) on them.

On a side note, the DMCA's anti-circumvention clause almost guarantees weak "encryption" and "protection" measures by exchanging technology for laws. Fun.

And now for a fun odd-ball question: Is the pattern of light-movement created by a graphic equalizer or other visualization method (eg. the visualizations that various car stereos and such provide) considered a "derivative work"?

Huh? 30GB? Linux 2.2.16 (which is the kernel tarball I had handy) is ~70MB uncompressed, and that includes all of the source, documentation and drivers.

The core kernel is pretty small. It only looks big when you take all of the drivers and other bits into account, most of which are not used on a given platform. For instance, the stuff under arch/s390 is only needed if you're building for a mainframe.

I don't see what POSIX capabilities has to do with this. Perhaps you can enlighten me?

Back to the discussion at hand: I can set MAX_TASKS_PER_USER and MIN_TASKS_LEFT_FOR_ROOT in linux/tasks.h. I can also limit the maximum memory usage of any given task with the ulimit mechanism you mention. (I can do that as root from getty or login before the user has a chance to do anything.) Both of those mechanisms would work towards preventing a mortal-user fork-bomb from trashing the machine. (A "max total memory per user" would be nice, but I would think the way modern UNIX VM's work make such an idea rather difficult to pin down, in practice.)

What I understand capabilities to be (referring to POSIX capabilities here) is just fine-grained access to the abilities that normally only root has. I don't see how that prevents a fork-bomb from happening (although I suppose I do see how this prevents a fork-bomb from happening accidentally as root).

So what am I not understanding?

As some have noted, it's because they're a known quantity. That's important. Also, as some of my friends at work point out, the older process technologies are more robust in environments like space, since you need more electrons to flip transistors and the like. As you get to smaller and smaller geometries, radiation-induced errors become more prevalent, and so it's harder to prevent them or compensate for them.

Sure, you can shield the components and whatnot, but at some point you reach practical limits. (Bear in mind that the shielding also needs to dissipate heat, etc....)

Dude, read the article. The problem is that the solar arrays raise the potential of the entire space station relative to the thin plasma bath that's around it. In other words, the space station is like a live wire at ~120V and space is the ground. It doesn't matter where you're at, if you're doing EVA, you're the lightning rod.

That's BAD.

Good question. What's really sad here is that SVID, POSIX, and BSD all probably do state that these sorts of non-ANSI APIs are supposed to show up in string.h (or maybe even strings.h !!) as part of their interface definition. Ick. To change that now would be tantamount to changing these standards. (Not that that would necessarily be bad, but then you'd have another set of not-quite-compatible standards to try to be compatible with.)

One way to adapt your code in a semi-portable (or at least in a somewhat self-documenting) fashion is to #define _POSIX_SOURCE and #define _SVID_SOURCE (or _BSD_SOURCE depending on your code) explicitly to enable some of these features even in the presence of -ansi. By explicitly defining these in your code (say, in a configuration header), you effectively state to the human reading the source that you rely on non-ANSI APIs being exported in these otherwise standard headers.

The unfortunate mess that we've inherited has all of these non-standard APIs spewn across all of these standard headers. It's for that reason that tools like GNU autoconf exist. I'd rather these APIs all be confined to their own headers as you suggest. *sigh*

So does Linux. Sometimes I wished Windows did.

At any rate, if you have your resource limits cranked up for some reason, or a privileged process develops a bug and goes ape-shit, well then... :-) As the poster a couple levels up said, the reason the one machine needed a reboot was because some in-house application did exactly that.

Me, clueless about C? I think not. Email me sometime and we can compare notes. I could give a sh*t if this discussion were about Linux. The compiler's behavior was correct, and I'm sorry, but you were just simply wrong.

Of course that works -- you have a prototype for flockOfMeese in scope. When you use the -ansi switch on GCC, the compiler defines the macro __STRICT_ANSI__, which causes the prototype for strdup to be excluded from string.h. This can be overridden by an application by explicitly enabling various non-ANSI featuresets by defining one of the following macros: __USE_SVID, __USE_BSD, __USE_XOPEN_EXTENDED. Each of these macros enables one of several non-ANSI API sets to be visible from the standard headers as a portability aid for other platforms which (unwisely) chose to export their APIs within the ANSI C headers. In an ideal world, these other interfaces would be exported in their own platform-specific headers.

Just because your example works under FreeBSD doesn't mean it's right. FreeBSD happens to allow some of the BSD-specific APIs to leak through the standard headers, even with -ansi on the compiler command line. Ideally, the ANSI-specified headers would only define the ANSI-specified APIs (particularly in the case of supplying -ansi -pedantic to the compiler).

And, BTW, this isn't just about Linux. I've run into the "strdup isn't part of ANSI C" problem on plenty of platforms, including Macintosh and on DSPs. In your example, the compiler was doing its job: It informed you that you were calling an API that was not defined in any of the headers you included, and since you were including only ANSI C compliant headers (made compliant by -ansi), you can then fix your program. Why else have compiler diagnostics? If anything, this says the FreeBSD headers are sloppy.

Furthermore, their adoption of VHS over the superior Betamax was because VHS was _cheaper_. The reason people originally bought these VHS tapes was because there was very litle else to buy. legitimate companies imagined video to be a threat to their business. That wouldnt have been a factor for porn producers at the time (and now, for that matter) because "Fat Moe and his credit card" isnt exactly a business situation where the concerned parties need to sit on the facts pending further study.

No, Sony wouldn't allow adult content on Betamax, plain and simple. I'm sure had Sony not placed any such restrictions on Betamax, the format would've thrived for much, much longer.

Uhm, two things of my own:

• strdup is not specified by ANSI C. You need to compile without -ansi in order to see strdup, so the first warning is your own damn fault. Lack of a warning in this case should be considered a bug.
• Second, I don't get the same second warning as you do. Rather, I get a secondary warning related to strdup not having a prototype in scope. Again, if you compile without -ansi the warning goes away.

In short, it's your own damn fault for using -ansi while trying to use an API entry that's not part of ANSI C's standard library.

I disagree. An application that starts thrashing the machine sometimes can only be brought under control via a reboot. Imagine if a privileged process starts the equivalent of

while (1) { char *c=malloc(1); *c = 0; fork(); }

I don't care what OS you have, the easiest way to reign that one is is to reboot. Things get even worse if said task is allocating other resources along the way (such as file descriptors, network sockets, what-have-you).

BTW, why do all of your periods come up as copyright symbols on my screen? Am I the only person who sees that?

I also want to hear Sony's SACD: like 2.4Mhz sampling rate, but 1 bit.

The bitrate is only 50% higher than a CD's bitrate (1.5Mbit/sec), so don't go creaming in your pants just yet.

The main difference the 1 bit/sample makes in this case is that your bandwidth theoretically stretches to a much higher (and quite ridiculous) 1.2MHz. Of course, the SNR is really, really low at 1.2MHz. For such a system, the effective dynamic range (and SNR) is inversely proportional to the frequency. You'll gain high-end range at the expense of high-end precision and range. Assuming they use something like sigma-delta demodulation to decode this into listenable audio, you also lose dynamic range over most of the listening band due to the concept of "slope overload".

(ObDisclaimer: That is, if I remember my signal processing courses from school correctly. I may program DSPs for a living, but that's because I'm a good coder, not because I was good with DSP theory. Most of what I do is other engineering, not actual signal processing.)

Yup, which is why every few months I show up to work with signs plastered over the walls and on all of the entrances saying "Do not open attachments named whatever.exe". Currently we have signs saying "navidad.exe" that went up a couple days ago.

Also, depending on the nature of the virus, they will also disable the dial-in modem pools, turn all the file servers to read only, and damn near send everyone home for the day. Meanwhile, I'm sitting there, reading mail in mutt on my Solaris box wondering what all the commotion is about.

I fail to see how this is a troll. I was being dead serious.

It's sorta like a business-model patent. You could take the oldest profession, rephrase it in terms of a "method", and strap on "involving a computer" and/or "network", and voila! Get yourself a patent.

Why don't you and the laser get a freakin' room?

I don't see a noun form of affect in my Webster's. (Specifically, "Webster's II New Riverside Dictionary, Revised Edition.") Granted, it's not quite as comprehensive as, say, the Oxford English Dictionary, but it does do a pretty good job of covering the portion of the language people actually still use. ;-)

Is this going to have an affect on any of your offices?

ObGrammar: It might affect my office, and it may have an effect on my workplace, but I have no idea what an affect is or means.

You liked the flashbacks? I prefer flashbacks that actually flash back to scenes rather than introducing new material. Sorta like your English teacher tells you: Never introduce new information in a conclusion. These flashbacks tend to conclude various subplots, yet they introduce new information. Urgl!

[OT: Hey great user #!!]

Basically, I enjoyed the movie as a "don't think to hard, sit back and enjoy the special FX" sort of movie, and that was about it. There was some bad science, the occasional correct science (such as the fire extinguisher in zero-G), and a fair amount of action. Not too bad.

But, it was definitely one of those movies that, as you get more distant from it, you realize how empty it was. Like a firework after it's been lit, the flash is gone, the wow is gone, and you're left with just so much hollow shell.

That said, the movie was worth it, but only because we got in with discount tickets so it was $3.00 a head instead of $7.00. W/out the discount tickets, I'd say wait for it to come out on VHS/DVD/Beta/Whatever and rent it from Ballbuster or something.

I had a similar problem (root perms) when I installed one of the NS6 preview releases. It appears the installer honors your umask setting, and that ends up removing permission bits all throughout the install dirs. Not too bright, I guess.

The fix was to find and make all the files in the install dir globally readable, and files w/ the X bit executable. Something along the lines of:

• find /usr/local/netscape -print | xargs chmod go+r
  find /usr/local/netscape -perm +0100 -print | xargs chmod go+rx
  

Good luck.

Depending on which version of Linux you're running, you could be running into threading bugs in Linux's libc. I found that upgrading my libc on my RH6.0 box to the same libc that's in RH6.2 made a bit of difference for Netscape (and Mozilla's) stability. It showed more for Mozilla.

Is it showing 135MB for the RSS or the SIZE on xmms and kdeinit? If the RSS is that big, then top is confused. If the SIZE is that big, then perhaps one or both applications is (a) memory mapping some devices (sound card, perhaps) and that mapping is being counted towards the process, or (b) one or both is leaking / allocating large amounts of memory but never faulting it in.

Memory that's allocated but never faulted in won't show up in RAM or in swap.

mozilla is not fast (interface-wise) and robust yet

Agreed! Mozilla might be able to render a 700-post Slashdot nested table in 3 seconds, but it takes as long to open the bloody-freaking "File" menu.

Also, the GTK-style right-click widgets are simply not as efficient as the Motif ones. (Here's one place I feel Motif wins.) In the Motif-based Netscape's, I can right click, and while holding the button, slide over and select "Back" and release, all in about a half-second. In the GTK-based Mozilla (and Netscape 6), I have to click, release, wait for the window to pop up, select back, click, release. Slow.

Another annoying tidbit of Mozilla (and NS6) is that it blacks out the screen when it starts loading a new page. On NS4.7x, I can click on a link, and keep reading the current page (I can even scroll up and down) while I wait for the other page to load. In MZ and NS6, as soon as it gets a byte from the remote webserver, it blacks the page out. No more "pipelining" my web-browsing as I visit lagged sites. Slower still.

And then there's the small detail that refreshing under various pop-ups and pull-downs is hit-or-miss, and the whole GUI packs up and goes South a couple times an hour, and it all just doesn't add up to an efficient, enjoyable browsing experience.

Anyway...

No, subliminal.