Slashdot Mirror

• AudioCatalyst vs. Producer
  
• MP3 bitrate comparison
  
• MusicMatch Jukebox vs. RealJukeBox
  
• Ars technica, worth reading.
  

Here's a good ars-technica article comparing the various mp3 encoders. The summery is that bladeenc outdoes xing at high bitrates but read the whole article yourself to get the full picture.

actually, there can (and is) great differences in the sound quality that different encoder produce.

Here's an article that explains why.
http://arstechnica.com/wanker desk/1q00/mp3/mp3-1.html

It's a lossy compression, so what gets 'lost' greatly affects the sound quality.

Deciding what to 'lose' is what makes one encoder different from another

oops

There has been a dearth of good technical analyses of the Crusoe
available on the web. There is this official White
paper (PDF), and I liked this
article by Jon Stokes at at Ars Technica, but apart from that I
have seen very little quality information. This essay is much needed.

If there is still anyone out there who hasn't read the technical synopsis of MP3 encoders that was on ArsTechnica a while back, I highly recommend it. You don't even have to understand what it all means to see that even the best MP3-encoded files don't quite match the quality of the original source. MP3s are low-fidelity, and Lars's liberal tossing around of the phrase "1st generation, perfect digital copies of master recordings" is incredibly misleading. It is also a blatant disregard for basic recording fundamentals and I can't believe that Lars doesn't know what a master really is; he does, so he was exaggerating on purpose.

And considering that (speculating) most of the MP3s you download have been ripped using a 15-month old version of Xing, I'd compare the average quality of internet MP3s to that of a second-generation analog copy. Sure, it won't degrade any further as you copy it, but that's a long way from "near-perfect" copies from a "master".

So Lars, don't admit to blatant ignorance of computers and then try to justify your assessment of technology by claiming you learned it all from advisors and press-releases.

Also, how come no one has yet to mention Hotline? Oh, oops... guess I just did.

Don't bother putting up a page unless you can do better than Ars Technica's Physical Home Networking Guide.

Anomalous: inconsistent with or deviating from what is usual, normal, or expected

For those of you now wishing you had bought a new home so you could do this, there's a recent nice article in Ars Technica about how to wire your existing home properly. An interesting read.

For those of you now wishing you had bought a new home so you could do this, there's a recent nice article in Ars Technica about how to wire your existing home properly. An interesting read.

Where the PPC scores here is that it is fundametally RISC by nature, although IIRC the PPC has a basic 68k emulation frontend for legacy purposes. However most modern apps on the Mac are tailored for the PPC, and as such, can use some of the funky RISC features to gain a speed advantage. For example, some Photoshop filters will render quicker on a G4@400MHz than on an equivalent, or higher spec x86 box, simply because the architecture is less cluttered, and the compilers don't have to take the legacy baggage into consideration. The same applies to the Alpha, in that by using MHz as a speed comparison between architectures, you are doing the more modern chips a major disservice, because they don't need to be clocked as high to gain comparable application performance.

As for the colour and font handling, he's right. The Macintosh's ease of use made it a very strong contender in the DTP arena early on, and as a result, programs like ATM and ColorSync allow a far greater degree of output control than the Windows (or Linux, sorry guys) equivalent. This is just by the nature of having existed on the platform longer, however.

Of the screenshots posted, I found the ones of the new QuickTime player particularly encouraging. The current incarnation of the QT player is an affront to UI design principles, and has been rightly pilloried and excoriated. The screenshots of the new QT player seem to address the bulk of the criticisms made; perhaps it's a testament to my cynicism that I am encouraged by a company that seems to have listened for a change.

Coupled with the changes to the Dock, I am now more hopeful that the final version of MacOS X will also take into account the critiques of the previous preview that have appeared on the web.

Happy overclocking! I've got my Athlon "700" running at 900, and it maintains 30c!

A bit of advice - always spring for a 300W+ power supply with Athlons...400W if you plan to use the Peltier!

The entire Itanium platform is basically nothing more than a test platform for the next IA-64 chip, McKinley.

This is because Merced/Itanium is 2.5 years late, and poorly designed. It is struggling to hit a meagre 800MHz (it was designed to debut at 800MHz, but on .25u process and in 1998), and appears to have only 96k L2 cache and 64k L1 cache, because rather than reaping the predicted simplifications of moving to a VLIW design, the Itanium core has fallen into a stew of complexity which leaves very little room for large cache size, even at .18u. This project has chewed up and spit out all of Intel's seasoned engineers on their Santa Clara design team, and was basically finished up by a huge committee of inexperienced kids fresh out of college. Every knowledgeble independent hardware analyst I've seen has said that, while IA-64 has some potentially promising ideas behind it, Itanium is going to be an ugly plodding beast of a chip, and its only chance at success is through miraculous marketing. Too bad for Intel's marketing machine that they're trying to move into a new space (high-end servers) with Itanium, and thus the people buying these machines are going to be well-informed and used to buying from vendors other than Intel.

The good news for IA-64 is that McKinley, the successor to Itanium, is much more on track (it should be out in volume by Q2 or Q3 2001), and appears to be performing quite nicely. Incidentally (or not), McKinley has been designed almost entirely by a much smaller (and more experienced) team over at HP (where EPIC, the philosophy behind IA-64, was designed as well); about all Intel will have to do with it is the fabbing and the Intel Inside logo. Also, McKinley will have the advantage of being fabbed with a brand-new .13u process, which ought to leave it enough room for a real L1 and L2 cache, and allow for presentable clock speeds. Thus, most organizations are looking at Itanium as a sort of public beta for McKinley--they'll buy a couple to get used to the platform, start to develop software for it, and have a core understanding in place in case they decide to upgrade all of their high-end servers to McKinley in a year or so. Almost no one is planning on deploying Itanium as a long term solution, because it will simply not be cost effective for the mediocre performance it will have.

And thus the "race" to get a good IA-64 OS up and running really isn't all that important. MS will be sure to have W2K-64 "gold" well before McKinley is released, and that's all that really counts. Getting Linux on Itanium solid before W2K-64 goes gold will be nice, but it most certainly isn't going to win Linux a beachhead in the high-end corporate market, simply because most high-end corporate stuff can afford to wait for W2K-64 to be ready before they switch to IA-64.

On the other hand, a rather peculiar consequence of the IA-64 design is that applications need to be recompiled for each new processor core in order to take advantage of the EPIC features. (This is because, in IA-64, the compiler does most of the instruction scheduling, and not a scheduler in the CPU's logic; thus, the compiler better know how many functional units the CPU has, for example, or else it will schedule things all wrong.) This might seem to give an advantage to OSS, since one can just get a new compiler and recompile all of one's applications if one has the source to them. However, considering the market all of this is directed towards, I'm quite sure no one will have any trouble getting seperate versions of W2K or Oracle or whathaveyou optimized for Itanium or McKinley or any subsequent IA-64 chips.

For anyone who was expecting IA-64 to show up on the desktop anytime soon: don't. The first IA-64 chip scheduled to have a shot at the high-end consumer market is Deerfield, planned for 2004, but expected to come out later if at all. It would take a little bit to explain why, but EPIC is very much better suited to single-tasking machines running streamlined, well-tuned code--things like databases. It's just a poor fit for consumer applications. And anyways, if you want a neat Intel chip to get excited about, Willamette--the next desktop chip--looks way sexier than Itanium, and has a lot of cool design features (eg. double-pumped ALU, trace cache) which are just as innovative as IA-64's VLIW stuff.

Just to close things off, here's a couple links for those looking to learn more about Itanium and IA-64. (Even if the design doesn't pan out, some of the principles behind it are very interesting.)

Hannibal at Ars Technica on IA-64: a bit old, but a very well written overview of the design theory behind EPIC.

Hannibal on IA-64 vs. Sun's MAJC: mostly about MAJC (very interesting in its own right!), but a good example of a different approach to VLIW than IA-64's. (Crusoe is yet another example of a completely different approach to VLIW.)

Paul DeMone's Itanium article on realworldtech.com (unfortunately, the site seems to be down at the moment, so I can't get a link): an impressive technical argument about why Itanium might not actually achieve higher ILP in actual conditions, along with an interesting historical parallel of why this wouldn't be the first time Intel pushed a radical new chip architecture and it completely flopped (I forget the name of the previous chip, but it's an interesting story).

The entire Itanium platform is basically nothing more than a test platform for the next IA-64 chip, McKinley.

This is because Merced/Itanium is 2.5 years late, and poorly designed. It is struggling to hit a meagre 800MHz (it was designed to debut at 800MHz, but on .25u process and in 1998), and appears to have only 96k L2 cache and 64k L1 cache, because rather than reaping the predicted simplifications of moving to a VLIW design, the Itanium core has fallen into a stew of complexity which leaves very little room for large cache size, even at .18u. This project has chewed up and spit out all of Intel's seasoned engineers on their Santa Clara design team, and was basically finished up by a huge committee of inexperienced kids fresh out of college. Every knowledgeble independent hardware analyst I've seen has said that, while IA-64 has some potentially promising ideas behind it, Itanium is going to be an ugly plodding beast of a chip, and its only chance at success is through miraculous marketing. Too bad for Intel's marketing machine that they're trying to move into a new space (high-end servers) with Itanium, and thus the people buying these machines are going to be well-informed and used to buying from vendors other than Intel.

The good news for IA-64 is that McKinley, the successor to Itanium, is much more on track (it should be out in volume by Q2 or Q3 2001), and appears to be performing quite nicely. Incidentally (or not), McKinley has been designed almost entirely by a much smaller (and more experienced) team over at HP (where EPIC, the philosophy behind IA-64, was designed as well); about all Intel will have to do with it is the fabbing and the Intel Inside logo. Also, McKinley will have the advantage of being fabbed with a brand-new .13u process, which ought to leave it enough room for a real L1 and L2 cache, and allow for presentable clock speeds. Thus, most organizations are looking at Itanium as a sort of public beta for McKinley--they'll buy a couple to get used to the platform, start to develop software for it, and have a core understanding in place in case they decide to upgrade all of their high-end servers to McKinley in a year or so. Almost no one is planning on deploying Itanium as a long term solution, because it will simply not be cost effective for the mediocre performance it will have.

And thus the "race" to get a good IA-64 OS up and running really isn't all that important. MS will be sure to have W2K-64 "gold" well before McKinley is released, and that's all that really counts. Getting Linux on Itanium solid before W2K-64 goes gold will be nice, but it most certainly isn't going to win Linux a beachhead in the high-end corporate market, simply because most high-end corporate stuff can afford to wait for W2K-64 to be ready before they switch to IA-64.

On the other hand, a rather peculiar consequence of the IA-64 design is that applications need to be recompiled for each new processor core in order to take advantage of the EPIC features. (This is because, in IA-64, the compiler does most of the instruction scheduling, and not a scheduler in the CPU's logic; thus, the compiler better know how many functional units the CPU has, for example, or else it will schedule things all wrong.) This might seem to give an advantage to OSS, since one can just get a new compiler and recompile all of one's applications if one has the source to them. However, considering the market all of this is directed towards, I'm quite sure no one will have any trouble getting seperate versions of W2K or Oracle or whathaveyou optimized for Itanium or McKinley or any subsequent IA-64 chips.

For anyone who was expecting IA-64 to show up on the desktop anytime soon: don't. The first IA-64 chip scheduled to have a shot at the high-end consumer market is Deerfield, planned for 2004, but expected to come out later if at all. It would take a little bit to explain why, but EPIC is very much better suited to single-tasking machines running streamlined, well-tuned code--things like databases. It's just a poor fit for consumer applications. And anyways, if you want a neat Intel chip to get excited about, Willamette--the next desktop chip--looks way sexier than Itanium, and has a lot of cool design features (eg. double-pumped ALU, trace cache) which are just as innovative as IA-64's VLIW stuff.

Just to close things off, here's a couple links for those looking to learn more about Itanium and IA-64. (Even if the design doesn't pan out, some of the principles behind it are very interesting.)

Hannibal at Ars Technica on IA-64: a bit old, but a very well written overview of the design theory behind EPIC.

Hannibal on IA-64 vs. Sun's MAJC: mostly about MAJC (very interesting in its own right!), but a good example of a different approach to VLIW than IA-64's. (Crusoe is yet another example of a completely different approach to VLIW.)

Paul DeMone's Itanium article on realworldtech.com (unfortunately, the site seems to be down at the moment, so I can't get a link): an impressive technical argument about why Itanium might not actually achieve higher ILP in actual conditions, along with an interesting historical parallel of why this wouldn't be the first time Intel pushed a radical new chip architecture and it completely flopped (I forget the name of the previous chip, but it's an interesting story).

I don't really know how much it pertains to actuall AI or not, but a detector/tracer type utility for DOS attacks might be a good idea.
I saw a paper pertaining to that the other day if I remember correctly.

A simple cheap processor that still has a decent amount of oomph coupled with a mobo like this is quite the combination. What's even better is that when you win the lottery, you can pop out the Duron and drop a 1000MHz Athlon in its place!

--
"Give him head?" ... "Be a beacon?"

"One World, one Web, one Program" - Microsoft Ad

Try:

www.arstechnica.com. The articles are mostly slanted towards gamers who are hardware enthusiasts, but don't let that fool you--they have a lot of good info there behind the scenes.

500mhz, in a new box? I don't think so, not when a 1ghz Athlon costs like $300 or something.

Please read this article on The G4 vs. K7, then check your prices on the K7: $769 for the 950mhz (probably $1k for the 1Ghz?).

Try out this old article on Ars Technica about the issue. Basically, everything that holds true for Quartz also held true for Display Postscript. The originating markup language behind the display version has just changed from Postscript to PDF. DPS was WAY ahead of its time. I just hope Apple keeps the networked aspect of the rendering system or makes it easy to extend to do networking.

Then how about this article from Ars-Technica that supports much of the detail in the MSNBC one?

Ars Technica has a review of MP3 encoders -- they compare Bladeenc, LAME, Xing and Fraunhofer.

For those too lazy to read it, Fraunhofer comes out the winner, followed closely by LAME. Bladeenc and Xing get ripped apart (no pun intended).

Ars Technica has a review of MP3 encoders -- they compare Bladeenc, LAME, Xing and Fraunhofer.

For those too lazy to read it, Fraunhofer comes out the winner, followed closely by LAME. Bladeenc and Xing get ripped apart (no pun intended).

Incidentally, ArsTechnica did some intersting comparison tests between various MP3-Encoders recently.

"When I'm singing a ballad and a pair of underwear lands on my head, I hate that. It really kills the mood."

Mac OS X uses XML as the standard format for all its configuration files. Which is in my opinion, a wonderful development. I hope it catches on elsewhere. Using Linux, I despise having programmers use many different formats. Jumping between them is incredibly annoying, trying to recenter yourself everytime. "Why isn't this WORKING! Oh yeah, that's how it's done in the other app!"

The analogy anyone (meaning non-wired people) can understand, is: would you trust one of those news magazines at the checkout counters that have stories about the return of Elvis on the cover? Of course not. Well, how about if your local Sun or Tribune started selling out? You'd find another one. So yeah, there are bad news sources online, but don't hurt the good ones by making blanket statements like that.

"Now, at this point I should say something about privacy. TiVo guarantees that they neither monitor nor report your TV watching habits and preferences. All taste matching is reportedly done on your local machine, and no such data is sent back to TiVo. While I can't verify that claim, I will note that they are vigilant in making it clear that they respect your privacy."

"Now, at this point I should say something about privacy. TiVo guarantees that they neither monitor nor report your TV watching habits and preferences. All taste matching is reportedly done on your local machine, and no such data is sent back to TiVo. While I can't verify that claim, I will note that they are vigilant in making it clear that they respect your privacy."

There already is a great benchmark for processors, and it's called SPEC. Yes, it's not open source, but it's really quite reliable for comparing CPUs of any architecture. As slashdot user "cweber" pointed out in his post, they have been doing this for 11 years, and they periodically revise their benchmark suite to stress CPUs more uniformly.

The open-source method. This is really good to ensure that there are no cheaters at the benchmark level.

Tom's interesting ideas on Crusoe. This stems from the fact that SPECmarks don't quite approximate real usage that Crusoe depends on to use it's hotspot optimizations. However, we are interested in the raw sustained speed of the processor (in this case), not the speed of the OS or it's task swap latency. Tough problems to solve.

Open-source means that the benchmark code will be able to take advantage of the best compiler available for the target CPU (see comment at end).

The Bad:

Anyone who has done benchmarks knows that even small variations in system config can have strage or harmful effects on the benchmark results. This open-source effort is going to have to have a database of hardware configs in order for this to be useful.

The Ugly:

Vendors are going to oppose this (at least not support it). Why? Because plain and simple they have an interest in promoting the most favorable statistics possible about their products. They want to keep feeding you "polygon fill rates" and "texels per second" because their card may not stand up in a direct test program comparison. Plus, they are just dying to convince you that they have new BogusMarketingAcronym (tm) technology and their competitor does not. Nevermind that SSE and 3Dnow do pretty much the same thing -- companies have an interest in differentiating themselves as much as possible.

If this benchmark actually takes off (and gets widely accepted), we might get cheaters at the firmware or hardware level. This has happened before -- although which company it was and which benchmark they cheated I can't remember. I can't find it on the net or remember to save my life (sigh)...

I also need to say something to the people who think a processor should be judged independently of a compiler. This is just plain dumb. Why? Because a processor and it's compiler are a team. You can't use one without the other. When a chip is designed, there is a direct information dependence between the chip architects and the compiler writers. They are designed as a pair (ideally), and they should be tested as such. If a given compiler has great optimizations, then great! That means the compiler understands its target real well. It is a win for both the CPU and the compiler for pulling it off. This compiler is going to do the same kinds of optimizations when vendors use it to write programs, so that helps the comparison between benchmark code and apps.

However, I can see the need to compare not only the best compiler, but GCC as well, because of its broad acceptance. But if you are serious about performance, and want to get every once of juice out of your chip, you use the vendor provided compilers, not GCC. Don't get me wrong, GCC is great for compliance and portability, but it usually doesn't compare well with vendor compilers for generated code speed (with the possible exception of IA-32).

Ars Technica also published, a while back, some good information regarding CPU benchmarks. Check it out if you are interested in SPEC or CPU benchmarks in general.

But there's more than higher clock speeds to these puppies. For one thing, they include the SSE instructions which, while they may or may not help you personally, definitely can't hurt to have. More importantly, they will be fabbed at 0.18 micron and include 256k of L2 cache. Now before anybody gets too excited, they plan to cripple them down to the standard 128k cache size. But if the BP6 showed us anything, it's that disabling can beundone... could be some exciting times ahead for overclockers...

If you're going to be using both an Athlon and a Peltier cooler, you should make sure your Power Supply can crank out a whole lot of current. For some more information on doing Peltier cooling well, check out the ars technica article on the subject.

For those interested in the science behind this, Ars Technica is running a good piece on Peltier cooling, including a summary of how they work.
--

For those interested in the science behind this, Ars Technica is running a good piece on Peltier cooling, including a summary of how they work.
--

Transmeta's codewarping is one of the reasons with the same ISA a transmeta CPU needs an extra 250Mhz or so to match an PIII-450.

The only place runtime optimization actually offsets the slowdowns from doing JIT compiliation are pathological cases arranged by vendors for demos. In the real world, java is ALWAYS slower, sometimes 10%, occasionally 100%.

The reason not to dismiss java out of hand is that most apps these days don't need the speed. The problem comes when someone tries to use java for an app that does, because they heard that java is "just as fast, or faster than C++, thanks to the patented HotSpot Technology (TM) (C) (all rights reserved)" marketing bullshit.

Sorry, this is just not true. I work on a team implementing a Java2 JVM and JRE. We were pleasantly surprised at the performance gains we saw when using HotSpot. It really does dramatically increase Java execution speed. We commonly see Java applications executing only 25-50% slower than their C++ counterparts.

But we also do see some not-uncommon cases of Java code excuting faster than natively compiled C++ code. This seems ocounter-intuitive, until you realize how optimizing native compilers work. They can only optimize within compile-time boundaries - typically they optimize within class or methods. They miss many potential runtime optimizations. There are repetitive code execution patterns that static compile-time optimization just misses.

For a detailed description of this sort of optimization, read: this ArsTechnica article. It describes HP's Dynamo technology, but HotSpot uses some of the same principles, as does TransMeta's code warping.

I can assure you this is not (just) marketing hype. There really are dramatic speed ups to be gained from this approach, and we are seeing them with real world code examples, not just "pathological cases arrranged by vendors for demos."

Hey, wake up. The guy asked a question and all he gets for a response is "Motorola 68000's are the best for embedded applications." and "I seem to remember that Intel chips are best for math calculations." Duhrr.. No. First of all this guy is not looking for an embedded application, and he wants to now the current state of relative processor power. For mathematical operations, you have two choices. Intel is not one of them. Intel's processors still use the same archaic method for math calculations as the pentium. Until Intel comes out with something new they are out of the race. Plus, their chips are more expensive than AMD's. The Athlon however, uses a monster math process it inherited from the Alpha. This thing eats, sleeps, and breathes math. Plus it's cheaper. For comparison, here are the specInt & specFP (Industry standard Integer and Floating Point benchmarks (the math in a processor))
Athlon 600 : specInt: 28, specFP: 22
Pentium III 600: specInt: 24 specFP: 15.9
Add to this that floating point calculations are the more important of the two, and the athlon is the clear winner. Now, there is another contender. The IBM 7400 (G4), it's spec scores are:
specInt: 450Mhz specInt: 21.4 specFP: 20.4
pretty close to the athlon 600mhz. But the important part is the Altivec unit (Velocity Engine), which is a monster 128 bit wide SIMD math destroyer. The only thing is the software has to be optimized for it. With an Altivec enhanced RC5 decryption client, an G4 450 outperforms a 1ghz (700mhz overclocked) Athlon. With properly coded programs this thing absolutely screams. So, if you are writing your own program, and are proficient enought to include altivec, a G4 may give you the most bang for your buck. The only way I know how to get one is to buy an Apple thought, I hear IBM may be releasing reference boards for Linux systems though. Check it out. As for multiprocessor systems, unless you know specifically that your math calculations won't be done in a series of steps, i.e. one calculation can be performed without knowing the results of a previous calculation. Which, by the way, is rather unlikely. I wouldn't suggest them. If you want some more information, check out these articles.

G4 vs AMD Athlon:
http://www.arstechnica.com /cpu/1q00/g4vsk7/g4vsk7-1.html
Comparison of Altivec, and some other SIMD's:
http://www.arstechnica.com/cpu /1q00/simd/simd-1.html
Pentium III vs. Athlon:
http://www7.tomshardware.co m/cpu/99q3/990809/index.html
http://www7.tomshardware.co m/cpu/99q3/990823/index.html

Spec scores taken from http://www.ugeek.com If you have anymore questions, you can email me at guso@geek.com

Hey, wake up. The guy asked a question and all he gets for a response is "Motorola 68000's are the best for embedded applications." and "I seem to remember that Intel chips are best for math calculations." Duhrr.. No. First of all this guy is not looking for an embedded application, and he wants to now the current state of relative processor power. For mathematical operations, you have two choices. Intel is not one of them. Intel's processors still use the same archaic method for math calculations as the pentium. Until Intel comes out with something new they are out of the race. Plus, their chips are more expensive than AMD's. The Athlon however, uses a monster math process it inherited from the Alpha. This thing eats, sleeps, and breathes math. Plus it's cheaper. For comparison, here are the specInt & specFP (Industry standard Integer and Floating Point benchmarks (the math in a processor))
Athlon 600 : specInt: 28, specFP: 22
Pentium III 600: specInt: 24 specFP: 15.9
Add to this that floating point calculations are the more important of the two, and the athlon is the clear winner. Now, there is another contender. The IBM 7400 (G4), it's spec scores are:
specInt: 450Mhz specInt: 21.4 specFP: 20.4
pretty close to the athlon 600mhz. But the important part is the Altivec unit (Velocity Engine), which is a monster 128 bit wide SIMD math destroyer. The only thing is the software has to be optimized for it. With an Altivec enhanced RC5 decryption client, an G4 450 outperforms a 1ghz (700mhz overclocked) Athlon. With properly coded programs this thing absolutely screams. So, if you are writing your own program, and are proficient enought to include altivec, a G4 may give you the most bang for your buck. The only way I know how to get one is to buy an Apple thought, I hear IBM may be releasing reference boards for Linux systems though. Check it out. As for multiprocessor systems, unless you know specifically that your math calculations won't be done in a series of steps, i.e. one calculation can be performed without knowing the results of a previous calculation. Which, by the way, is rather unlikely. I wouldn't suggest them. If you want some more information, check out these articles.

G4 vs AMD Athlon:
http://www.arstechnica.com /cpu/1q00/g4vsk7/g4vsk7-1.html
Comparison of Altivec, and some other SIMD's:
http://www.arstechnica.com/cpu /1q00/simd/simd-1.html
Pentium III vs. Athlon:
http://www7.tomshardware.co m/cpu/99q3/990809/index.html
http://www7.tomshardware.co m/cpu/99q3/990823/index.html

Spec scores taken from http://www.ugeek.com If you have anymore questions, you can email me at guso@geek.com

isn't Mac OS X going to use XML to their config files in /etc/ and /etc/rc*. I seem to have seen something about that over at arstechnica: Mac OS X DP3 . It would be the next logical step to configure BSD kernels the same way. This might be some thing we will see in Linux 3.0 or 2.6 if there is enough interest. Or maybe we will see it in one of the cutsy distributions, ie: Corel, SuSE, Caldera, etc..

It installed relatively painlessly with InstallShield (no restart required).

The cool stuff is it includes a Java 2 virtual machine licensed from Sun. I've tried a few java enabled pages today, and everything's worked fine on this relatively slow computer, at a comparable rate to MS's virtual machine.

SSL is enabled, so on-line shopping works well. The widgets don't feel nearly as "glitchy", especially the side toolbar. Dialogs are cleaner and closer to Netscape 4.7's. Page updates are as fast as recent Mozilla snapshots, if not more so, and easily comparable to IE5 on the same machine. Rendering speed is (subjectively) up there with Opera. And the new Netscape throbber really kicks ass. The memory footprint seems to be much smaller too, because I'm able to open a few windows without the usual disk grinding I had before.

The bad stuff - they still haven't fixed the button placement in the top toolbar. Grrrr...this is really ugly (but functionally irrelevant I should point out). No URL auto-completion. AOL have bundled some crappy Net2Phone application, and built in AIM to the browser. If these had been left out, I'm sure the 13MB download size would be significantly reduced (ie the bloat is not appreciated). And while I don't mind the general look of the Gecko widgets, I think the flat grey menus need at least a little sprucing up.

BTW, I'm not complaining. I actually used Communicator 4.x betas, so I realise that a lot of the final functionality will be fixed for the final release. It's disappointing the number of people who complain that Mozilla is unstable and not feature-complete. Well duh, it's a pre-release isn't it? The other frequent comment that bugs me is "Why Netscape 6 and not 5?" Well to the average consumer (and bear in mind Netscape is being produced by AOL for consumption by their user base, as the inclusion of the AIM messenger attests) version numbers are as good a way as any to compare software packages. Psychologically, a Netscape 5 release would imply a lagging of technology, considering IE5.5 is just around the corner. It's pretty obvious to me that this is a case of keeping up with the Jones's.

I should also warn to be wary of downloading this from the link at betanews because it appeared to link to a 4.7 release of Communicator. Use the direct link at arstechnica instead (if it's still up).

Cheers,

(posted with Netscape 6.0 Preview Release 1 :)

Apple is exposing (correct me if i'm wrong here) three APIs-- one for Darwin, which is most of the BSD/Unix api's, one for "Carbon"-- halfway between old-style mac stuff and the newest-coolest, and "Cocoa", which aside from being a lame reference to Java, should provide real advantages in speed, and of course stability. Did I get that right?

anyway, it looks like lots of Linux stuff should now be trivial to port to mac, and THIS IS GOOD FOR EVERYONE because it means that Windows will have less software than Mac or Linux. cool.

Actually, from what I read on ArsTechnica a while back the G4 and Athlon aren't that different at all. If I remember rightly the main architectural diferences were due to the fact that AMD's engineers had to fully support the x86 instruction set while the G4 engineers had the luxury of doing their own thing. Here's the link if you'd like to read the article.

There's a good article at Ars Technica on SIMD architectures, including Motorola's Altivec.

Altivec support has been in all of the 2.3.x kernels, but it hasn't done much yet -- only #ifdef'ed in a handful of lines of code. This is really quite cool; I'm already running Linux on a PowerPC 750 (the G3). My next machine will likely be a G4 or whatever's next.

There's a good bit of info on the alti-vec and the G4 in this Ars Technica article (that was slashdotted a while back).

John

http://arstechnica.com/wankerdesk/1q00/arswards99- 2.html#vidcard

The wheel is turning but the hamster is dead.

http://arstechnica.com/wankerdesk/1q00/arswards99- 2.html#vidcard

The wheel is turning but the hamster is dead.

If x86 is sooooo bad, don't wait and buy a fucking pink IMAC and stop BSing about something you don't know.

Why is the Macintosh the only other alternative to x86? How about Alpha or Sparc? Or was this just another opportunity for you to bash 'pink' iMacs?

(please no ALTIVEC RuLeZ pathetic replies)

You should go to arstechnica and check out the article comparing SIMD units. You'd be surprised. I'm not ragging on the x86 architecture, but you have some weird ways of determining performance (MHz only).
--

• The Tech Report
• Ars Technica
• AnandTech
• HardOCP

The other sites are www.cnet.com and www.sysopt.com if you wondered. :)

Iridium (or rather, Motorola) is planning on deorbiting the satellites, rather then just leaving millions of dollars worth of stuff up there. I read it on Ars, but they didn't seem to site a source (besides the guy who sent in the story) so it might not be true. But they're obviously not gonna to play finders-keepers with the things. If they don't find a buyer (I don't know what they would be good for, maybe some sort of wireless internet or something, or just use them to tie into another network), then they'll certainly take them down and sell them for something else (i bet a lot of the equipment in them is useful in and of itself).

Sorry guys, no free satellites...

Speaking of ArtX (Which ATI recently bought), there's an interesting article up at Ars Technica, "ArtX: Half-truths and Misrepresentation?".

The article details what happened when Jon "Hannibal" Stokes, a writer for Ars Techica, posted a negative article on an ArtX trade show appearance. Afterwards, a number of Anonymous posts appeared on the Ars Technica forum which appeared to support ArtX, but which turned out to be from an ArtX's Director of Marketing.

This incident appeared on Slashdot as ArtX, Hannibal and Consumer Fraud.

-----------------------