>I fully expect that we're going to start to see processors--possibly even from hobbyists--optimized for running Python or other high-level languages
Great, and then in 12 months someone will release an emulator for this type of chip that runs on industry standard processors at the same speed. Intel did a great job in the 90s of heading off all sorts of coprocessor based designs in favor of "do it all on the CPU". Hardware crypto accelerators (for SSL) looked kinda sorta like a good idea for about a year but they couldn't compete with Moore's law.
Unless someone can come along with a mass-market coprocessor like you describe which has a clear price advantage, then this sort of thing will remain a curiosity.
You're overlooking the all-important open source requirement: "I have to be the primary author". That's why there are so many aborted fetuses of open source software on SourceForge, Freshmeat, etc... starting from scratch seems sexy and it's all fun to write up project goals and mock up screen shots, but when it comes time to actually write the thing, and especially to write documentation and QA the thing, there's a lot of drudgery to be done.
I'm using Subversion now, have been for about 6 months, and it's IN EVERY WAY better than CVS, EXCEPT for industry adoption.
TL needs to spend some time on Arch marketing. What exactly is bad about Subversion? Give me an example scenario that shows me just how fucked I would be with svn and how Arch would ride in on a white horse and save the day. Then give me four or five more. Write a couple of whitepapers explaining how Arch is fundamentally much better than Subversion in its theoretical design and how that's going to save my project lots of time that we're wasting with Subversion. Otherwise I'm just going to assume that learning Arch is a waste of time because it's not any better, just different, and exists just because TL wanted to write his own VC system.
BTW, we just did a big branch and merge on my project. Not a big deal. Maybe with 100+ developers, Arch would rock Subversion's world, but how am I supposed to know that? It's not my responsibility to research every product out there just so I can find out whether needs I don't have are better filled by a different product than the one I'm using. That's the product/project evangelist's job.
No points are awarded for "it's totally different and strange, so you'll have to spend a lot of time learning it, and it's really slow, but it's way better than that other crap, because I say so."
Real Programmers do make mistakes. However, they don't ship code with great big galloping bugs that a quick code review or many many code analysis tools could have found.
In Knuth's case, he didn't say "I bet $100,000,000,000 that nobody can find a bug!". He created an incentive for people to review his code for bugs. There's a big difference.
I was gonna say something like "well at least it's good to see that Microsoft is reusing code!" but if you have to separately update each application, that's pretty lame. They get all the benefit of reuse but you still have to install redundant binaries all over the place?
Why isn't there just a shared library (or two or three, if there are incompatible versions) that needs to be updated at an OS level, fixing everything that links to it?
1) 24-hour security guard. Make sure to provide coffee and a GameBoy lest this guard fall asleep on the job. 2) Take the radio out of the car and put a sign on the car window that says "no radio in car". 3) Get insurance and STFU. Seriously.
If your mom lives in a neighborhood that's so bad that people will walk up and break into a car that has an alarm and a security light just to see if something interesting might be inside, then there's not much you can do to stop them with force, short of a locking garage or a grumpy ape on a chain in the front yard.
Maybe you should make the car look like less of a valuable target. If you're worried about the windows being smashed, leave the doors unlocked (and maybe the windows rolled down a bit) but buy a Club and/or LoJack so that there's no damage done while the attacker figures out that this car is a P.O.S. that's not easy to steal.
>Why should I remember the filepath to a file (or in my case wich computer). That is not how I pick a book from the shelf is it.
You don't have to. You can use locate or a GUI-based full text search right now.
If you have 10 books, no you don't need to do a keyword based search. If you have 1,000,000 books, you can't just reach for it and grab it, nor does looking for the size and color help you. Librarians know all about this, which is why they have metadata catalogs with all sorts of juicy information in them.
I have several hundred books at home and it still takes time to find one (possibly because it's not worth the trouble to create a catalog of them). Which bookshelf is it on? Which shelf? Maybe it's stacked 2 books deep, in which case I have to look behind the front stack to see if it's there. Maybe I don't know what color it is.
I have a few hundred CDs as well. Are they just tossed in a heap in the corner? No, they're alphabetized. I use artist name and then album name alphabetic sorting; one of my friends sorts first by genre, then by artist.
My point is, people who are totally disorganized aren't going to be able to find their stuff no matter what tools you give them. There are metadata fields in Word but how many people use them? Only when you feel the pain of disorganization do you actively fight it. If you just hire an IT staff to buy bigger tape drives and faster servers (so you can full-text search every file you've ever created), you're delaying an actual solution to the problem. My wife works at a law firm and they have tons and tons of documents to manage; not surprisingly, they have a law-firm-specific document management system that lets users organize and find stuff.
Databases are great for searching except for the fact that people can fill them with crap data also, as you indicated. This is not a problem that technology can fix on its own; technology plus user diligence plus some usability research are what's needed... meaning, people have to have tools that are easy to use and which support explicit, easy metadata based searching.
Your anime search example is no different from an MP3 example. If you're working with an opaque binary file format (as opposed to one like PowerPoint where "grep -l -i -r *" would succeed), somebody has to put the metadata you're looking for on those files. I mean, we can daydream about a search technology that will decompress the audio, do speech-to-text, and search based on the translated text (or decompress the video and OCR the subtitles?), but until then, somebody will have to type stuff in to be searched. If you want to find all the MP3s in your collection that have a female singer singing about the moon, a relational search doesn't realy help if the metadata was never there.
I think the trick (that Apple and Microsoft are figuring out presently) is that this needs to be an OS-level service (or specification, at minimum) so that developers and users can get used to the idea of metadata being available for every file, separate from long filenames or folder names. How exactly you implement the storage mechanism and the indexing is a minor detail by comparison. The dream you described can't happen as long as filesystems are composed of just a teeny filename with a binary stream attached.
I think a second major hurdle is the definition of "standard metadata" that says things like what the name of the author name field, copyright field, etc. should look like.
What does the Andrew File System have to do with this?
Oh, I get it. You don't even know what filesystems are available on Mac OS X. Feel free to speculate about possible design advantages of things you can't even be bothered to name, though. "That, uh... Mac thing."
ReiserFS is stunningly fast, and efficiently stores small files. That's why I use it. It's not much harder to type "mkfs.reiserfs" than "mkfs.ext3" or whatever.
I'm aware that disk space is cheap vs. sysadmin time, but it really is trivial to use ReiserFS, and (especially on Unix) the prospect of having a major space *and performance* saving from just using a different filesystem is very appealing.
If your distro doesn't provide ReiserFS, on the other hand, then maybe you should ask yourself why you're using that distro.
No, you just need apps that have a startup script (or double-clickable runner icon or whatever). If you're running "java -Dfoo -Dbar -Dbiz" you're doing it wrong, or your app supplier is lazy.
Dumping all your libraries in the JRE lib dir for autoloading is risky, unless you're careful to avoid duplicate libraries with different versions.
Java as a platform suffers from "jar hell" (kinda like "DLL hell") because there isn't a systemwide package management concept for Java itself. Most OSs at this point have a central package management scheme that includes manifests that say what dependencies exist as well as installers that know how to put the files in the right place. The Jar manifest file has entries for relative URLs of dependencies and a pacakage version number, but that's not really enough to build a package manager around. That stuff was really designed to solve applet requirements, not app requirements.
So, you take a risk when you upgrade a library to a version that didn't ship with the app you're using, because there's no declarative structure that tells you that the new library uses the same API as the old one, or which packages depend on the old one and thus need to be upgraded at the same time, etc. like you'd find with RPM, APT, etc.
It's better (where "better" is defined to mean "more stable", not "more efficient in terms of disk space usage") to just install the libraries you need multiple times - once per application. If you consider that disk space is cheap and sysadmin time is not cheap, it really doesn't make a lot of sense to obsess over pointing a bunch of Java apps on the same box at a shared copy of a.jar file.
A couple of things could fix this problem. One fix would be to have each OS package management organization start to "own" Java libraries along with native libraries. That's not very cross-platform, though. So maybe Sun should propose a new Jar manifest format that solves this? Or maybe it's in a JCP committee somewhere that I'm not aware of.:)
You might as well blame HTML for the fact that there are web sites that only work in IE.
The problem is that you bought some big complicated apps, then tried to do something with them that the vendor doesn't support and for which the vendor didn't QA their product. Amazingly, it didn't work.
>the main difficulty of getting Windows software companies to provide a Linux version is the tiny market share of Linux compared to Windows
Mac users are used to paying money in order to get something that works. Linux users are used to spending hours on end putzing around in order to get something that more or less does the job. Which one would you rather try to sell software to?
>you typically only need to pay the hashing cost once, unless of course you are a spammer (in which case people will not mark you as trusted).
They don't need to. If you're a spammer you just use spyware or worms to look for email + private key combinations, and then sell them by the millions on CD.
(All it takes to get around a passphrase protecting the private key is a keylogger.)
>He was talking to business people in the real world. They don't read slashdot.
They also don't care about security. Their IT people keep telling them not to install wide-open access points, and not to let random visitors plug in laptops, but they do it anyway.
Two words: "staging environment". Or perhaps one word: "testing".
Do you really blame the coder when something this important gets rolled out and all hell breaks loose? I'm sure the manager in charge of running that system did, but that doesn't mean he's right.
I wonder if there's a written specification that says that the system was supposed to work in a certain way, and the "coding error" resulted in a different implementation. Maybe the "coding error" was really a bit of undocumented functionality that nobody spec'ed out, nobody tested, and which (shockingly) failed when put into production.
When this sort of thing happens, it means that a coder didn't write the code that the customer needed, but that doesn't automatically make it the coder's fault. Did the customer (or "customer" in an all-internal situation) require it in writing? Did the development manager make sure it was in a spec? Did the analyst writing the specs capture that requirement correctly? Did the QA folks test for that feature? Did the docs say that the feature worked in the way the customer thought it would? Did the paper thoroughly test the software, accept it in writing, and train the users before rolling it out?
Only if all of this happened and there was *still* an obscure scenario in which the app behaved in a way that didn't adhere to the spec is it the coder's fault. Maybe. Or maybe it's the QA folks' fault for failing to test for that case, etc. etc.
It's much more likely to be a failure in pre-rollout testing, which isn't the coder's job. It's the IT manager's job at the paper.
Good point. What's the total cost of your whole company not having e-mail for days because your Exchange server is hosed, or Melissa 2005 just hit, etc. etc. Folks don't realize that people who don't use Outlook and IE just don't have the same degree of problems.
Jesus christ I'm tired of seeing speculation about this. In a thread talking about how Apple can't ship a G5 iMac, people are still talking about the mythical G5 PB. Let's all start speculating now about when the G6 desktop and dual-G5 PB will ship! Whee!
Here's why this doesn't matter at all. If you've ever spent any time shopping for a computer, you'll notice that prices on existing models always drop, and new exciting models are always around the corner. It never ends.
Either you can wait for a new computer, or you can't. You'll go crazy trying to dig for rumors and hints as to when model XYZ with the 5 terawooble whosie-whatsis will be released, instead of the 4 terawooble that's available now. Gotta have the 5! I just gotta!
But really, you don't. If you have urgent important money-making work that needs doing now, buy something now. You can sell it later when a newer model comes out that's so much better that it's worth the switch. It's not like you're going to church and declaring your lifelong pledge to use this and only this computer so long as you both shall live.
If you don't need something today, then why are you in such a hurry to buy the latest-greatest? The top end product always carries a price premium, and quite often has availability problems. You're just setting yourself up to pay extra for something you don't need.
Most vendors let you return the computer within a few days if there's a new model announcement right then, or at least they'll price-protect you if you complain enough (i.e. you get the lower price under the new model lineup, so they refund you the difference).
If you're really in such a hurry, you could lift a finger to try to speed things up.
I just went to www.apple.com/store and clicked through the configurator for the 3 featured G5 configs. No changes, just Select->Continue->Continue from the store main page to get to the shopping cart where there's a ship time estimate.
The dual 1.8GHz: 3-5 business days. The dual 2GHz: 3-5 business days. The dual 2.5GHz: 4-6 weeks.
Changing the configuration delays things a bit, but not much. I took the dual-2.0GHz G5 and maxed out the RAM, HD, and video card options, and now it says 7-10 business days.
It looks to me like only the dual 2.5GHz G5 is in short supply (not surprising since it's probably the one that IBM is having the hardest time making the CPU for, though that's just my speculation). The other models aren't. Cancel your order for a dual 2.5 and get a 1.8 or 2.0 dual G5 instead, and tweak the config to your heart's content. Or, if you really really need that 2.5, wait. If you're in a tearing hurry, you could probably walk into an Apple retail store and walk out with one the same day.
Alternatively, you could buy your G5 from MacWarehouse or Outpost.com. Some of them will add RAM and stuff for you; others might not. Outpost.com says they can ship the dual 1.8 and dual 2.0 same-day. CDW says they have dual-1.6 G5's also available same day. This is right on their search results page. I didn't even pick up the phone to find this out. I searched for "G5" on Outpost.com, and MacWarehouse had a link to the closeout 1.6GHz model on their home page.
Using C|Net shopper to find the best price on a dual 2.0GHz G5 shows a list of merchants in which every single one claims to have this model in stock now.
This took me about 10 minutes of surfing to find out. Maybe you should spend a few minutes yourself since it's your computer order?
Slashdot Mirror
>I fully expect that we're going to start to see processors--possibly even from hobbyists--optimized for running Python or other high-level languages
Great, and then in 12 months someone will release an emulator for this type of chip that runs on industry standard processors at the same speed. Intel did a great job in the 90s of heading off all sorts of coprocessor based designs in favor of "do it all on the CPU". Hardware crypto accelerators (for SSL) looked kinda sorta like a good idea for about a year but they couldn't compete with Moore's law.
Unless someone can come along with a mass-market coprocessor like you describe which has a clear price advantage, then this sort of thing will remain a curiosity.
Gosh... I guess choosing MySQL *doesn't* automatically eliminate database performance problems.
You mean you have to actually RTFM and then test stuff before rolling it out? With more than just one's own web browser?
If only someone had ever written a web load tester that was multithreaded! But since they haven't I guess I'll have to write my own...
You're overlooking the all-important open source requirement: "I have to be the primary author". That's why there are so many aborted fetuses of open source software on SourceForge, Freshmeat, etc... starting from scratch seems sexy and it's all fun to write up project goals and mock up screen shots, but when it comes time to actually write the thing, and especially to write documentation and QA the thing, there's a lot of drudgery to be done.
I'm using Subversion now, have been for about 6 months, and it's IN EVERY WAY better than CVS, EXCEPT for industry adoption.
TL needs to spend some time on Arch marketing. What exactly is bad about Subversion? Give me an example scenario that shows me just how fucked I would be with svn and how Arch would ride in on a white horse and save the day. Then give me four or five more. Write a couple of whitepapers explaining how Arch is fundamentally much better than Subversion in its theoretical design and how that's going to save my project lots of time that we're wasting with Subversion. Otherwise I'm just going to assume that learning Arch is a waste of time because it's not any better, just different, and exists just because TL wanted to write his own VC system.
BTW, we just did a big branch and merge on my project. Not a big deal. Maybe with 100+ developers, Arch would rock Subversion's world, but how am I supposed to know that? It's not my responsibility to research every product out there just so I can find out whether needs I don't have are better filled by a different product than the one I'm using. That's the product/project evangelist's job.
No points are awarded for "it's totally different and strange, so you'll have to spend a lot of time learning it, and it's really slow, but it's way better than that other crap, because I say so."
...and because it worked so well for Apple with Copland.
Google search licensee has web site. News at 11.
Oh my god, they put a couple of other things on the results page. Somebody call the President!
I have a little Google search box on my web site. Does that mean that I get a Slashdot article announcing the launch of my kewl search technology too?
Real Programmers do make mistakes. However, they don't ship code with great big galloping bugs that a quick code review or many many code analysis tools could have found.
In Knuth's case, he didn't say "I bet $100,000,000,000 that nobody can find a bug!". He created an incentive for people to review his code for bugs. There's a big difference.
I was gonna say something like "well at least it's good to see that Microsoft is reusing code!" but if you have to separately update each application, that's pretty lame. They get all the benefit of reuse but you still have to install redundant binaries all over the place?
Why isn't there just a shared library (or two or three, if there are incompatible versions) that needs to be updated at an OS level, fixing everything that links to it?
1) 24-hour security guard. Make sure to provide coffee and a GameBoy lest this guard fall asleep on the job.
2) Take the radio out of the car and put a sign on the car window that says "no radio in car".
3) Get insurance and STFU. Seriously.
If your mom lives in a neighborhood that's so bad that people will walk up and break into a car that has an alarm and a security light just to see if something interesting might be inside, then there's not much you can do to stop them with force, short of a locking garage or a grumpy ape on a chain in the front yard.
Maybe you should make the car look like less of a valuable target. If you're worried about the windows being smashed, leave the doors unlocked (and maybe the windows rolled down a bit) but buy a Club and/or LoJack so that there's no damage done while the attacker figures out that this car is a P.O.S. that's not easy to steal.
h... e... '... s... j... u... s... t... a... v... e... r... y... s... l... o... w... t... y... p... i... s... t... .
>Why should I remember the filepath to a file (or in my case wich computer). That is not how I pick a book from the shelf is it.
You don't have to. You can use locate or a GUI-based full text search right now.
If you have 10 books, no you don't need to do a keyword based search. If you have 1,000,000 books, you can't just reach for it and grab it, nor does looking for the size and color help you. Librarians know all about this, which is why they have metadata catalogs with all sorts of juicy information in them.
I have several hundred books at home and it still takes time to find one (possibly because it's not worth the trouble to create a catalog of them). Which bookshelf is it on? Which shelf? Maybe it's stacked 2 books deep, in which case I have to look behind the front stack to see if it's there. Maybe I don't know what color it is.
I have a few hundred CDs as well. Are they just tossed in a heap in the corner? No, they're alphabetized. I use artist name and then album name alphabetic sorting; one of my friends sorts first by genre, then by artist.
My point is, people who are totally disorganized aren't going to be able to find their stuff no matter what tools you give them. There are metadata fields in Word but how many people use them? Only when you feel the pain of disorganization do you actively fight it. If you just hire an IT staff to buy bigger tape drives and faster servers (so you can full-text search every file you've ever created), you're delaying an actual solution to the problem. My wife works at a law firm and they have tons and tons of documents to manage; not surprisingly, they have a law-firm-specific document management system that lets users organize and find stuff.
Databases are great for searching except for the fact that people can fill them with crap data also, as you indicated. This is not a problem that technology can fix on its own; technology plus user diligence plus some usability research are what's needed... meaning, people have to have tools that are easy to use and which support explicit, easy metadata based searching.
Your anime search example is no different from an MP3 example. If you're working with an opaque binary file format (as opposed to one like PowerPoint where "grep -l -i -r *" would succeed), somebody has to put the metadata you're looking for on those files. I mean, we can daydream about a search technology that will decompress the audio, do speech-to-text, and search based on the translated text (or decompress the video and OCR the subtitles?), but until then, somebody will have to type stuff in to be searched. If you want to find all the MP3s in your collection that have a female singer singing about the moon, a relational search doesn't realy help if the metadata was never there.
I think the trick (that Apple and Microsoft are figuring out presently) is that this needs to be an OS-level service (or specification, at minimum) so that developers and users can get used to the idea of metadata being available for every file, separate from long filenames or folder names. How exactly you implement the storage mechanism and the indexing is a minor detail by comparison. The dream you described can't happen as long as filesystems are composed of just a teeny filename with a binary stream attached.
I think a second major hurdle is the definition of "standard metadata" that says things like what the name of the author name field, copyright field, etc. should look like.
What does the Andrew File System have to do with this?
Oh, I get it. You don't even know what filesystems are available on Mac OS X. Feel free to speculate about possible design advantages of things you can't even be bothered to name, though. "That, uh... Mac thing."
Thanks for your insightful post.
>Apple did OS X more or less from scratch
Yeah, never mind that FreeBSD and NextStep stuff they used. It doesn't really do much.
ReiserFS is stunningly fast, and efficiently stores small files. That's why I use it. It's not much harder to type "mkfs.reiserfs" than "mkfs.ext3" or whatever.
I'm aware that disk space is cheap vs. sysadmin time, but it really is trivial to use ReiserFS, and (especially on Unix) the prospect of having a major space *and performance* saving from just using a different filesystem is very appealing.
If your distro doesn't provide ReiserFS, on the other hand, then maybe you should ask yourself why you're using that distro.
No, you just need apps that have a startup script (or double-clickable runner icon or whatever). If you're running "java -Dfoo -Dbar -Dbiz" you're doing it wrong, or your app supplier is lazy.
.jar file.
:)
Dumping all your libraries in the JRE lib dir for autoloading is risky, unless you're careful to avoid duplicate libraries with different versions.
Java as a platform suffers from "jar hell" (kinda like "DLL hell") because there isn't a systemwide package management concept for Java itself. Most OSs at this point have a central package management scheme that includes manifests that say what dependencies exist as well as installers that know how to put the files in the right place. The Jar manifest file has entries for relative URLs of dependencies and a pacakage version number, but that's not really enough to build a package manager around. That stuff was really designed to solve applet requirements, not app requirements.
So, you take a risk when you upgrade a library to a version that didn't ship with the app you're using, because there's no declarative structure that tells you that the new library uses the same API as the old one, or which packages depend on the old one and thus need to be upgraded at the same time, etc. like you'd find with RPM, APT, etc.
It's better (where "better" is defined to mean "more stable", not "more efficient in terms of disk space usage") to just install the libraries you need multiple times - once per application. If you consider that disk space is cheap and sysadmin time is not cheap, it really doesn't make a lot of sense to obsess over pointing a bunch of Java apps on the same box at a shared copy of a
A couple of things could fix this problem. One fix would be to have each OS package management organization start to "own" Java libraries along with native libraries. That's not very cross-platform, though. So maybe Sun should propose a new Jar manifest format that solves this? Or maybe it's in a JCP committee somewhere that I'm not aware of.
You might as well blame HTML for the fact that there are web sites that only work in IE.
The problem is that you bought some big complicated apps, then tried to do something with them that the vendor doesn't support and for which the vendor didn't QA their product. Amazingly, it didn't work.
>the main difficulty of getting Windows software companies to provide a Linux version is the tiny market share of Linux compared to Windows
Mac users are used to paying money in order to get something that works. Linux users are used to spending hours on end putzing around in order to get something that more or less does the job. Which one would you rather try to sell software to?
>you typically only need to pay the hashing cost once, unless of course you are a spammer (in which case people will not mark you as trusted).
They don't need to. If you're a spammer you just use spyware or worms to look for email + private key combinations, and then sell them by the millions on CD.
(All it takes to get around a passphrase protecting the private key is a keylogger.)
Holy shit, this warrants a /. headline?
Next up: news about the new mod that makes game save files take less disk space. STOP THE PRESSES!!!
>He was talking to business people in the real world.
They don't read slashdot.
They also don't care about security. Their IT people keep telling them not to install wide-open access points, and not to let random visitors plug in laptops, but they do it anyway.
Yeah, good idea. Make a web site that doesn't work with the browser that has 95% market share, and then preach to users about standards. Good one.
Two words: "staging environment". Or perhaps one word: "testing".
Do you really blame the coder when something this important gets rolled out and all hell breaks loose? I'm sure the manager in charge of running that system did, but that doesn't mean he's right.
I wonder if there's a written specification that says that the system was supposed to work in a certain way, and the "coding error" resulted in a different implementation. Maybe the "coding error" was really a bit of undocumented functionality that nobody spec'ed out, nobody tested, and which (shockingly) failed when put into production.
When this sort of thing happens, it means that a coder didn't write the code that the customer needed, but that doesn't automatically make it the coder's fault. Did the customer (or "customer" in an all-internal situation) require it in writing? Did the development manager make sure it was in a spec? Did the analyst writing the specs capture that requirement correctly? Did the QA folks test for that feature? Did the docs say that the feature worked in the way the customer thought it would? Did the paper thoroughly test the software, accept it in writing, and train the users before rolling it out?
Only if all of this happened and there was *still* an obscure scenario in which the app behaved in a way that didn't adhere to the spec is it the coder's fault. Maybe. Or maybe it's the QA folks' fault for failing to test for that case, etc. etc.
It's much more likely to be a failure in pre-rollout testing, which isn't the coder's job. It's the IT manager's job at the paper.
I'll take emacs or vi over regedit any day, thanks.
Good point. What's the total cost of your whole company not having e-mail for days because your Exchange server is hosed, or Melissa 2005 just hit, etc. etc. Folks don't realize that people who don't use Outlook and IE just don't have the same degree of problems.
Jesus christ I'm tired of seeing speculation about this. In a thread talking about how Apple can't ship a G5 iMac, people are still talking about the mythical G5 PB. Let's all start speculating now about when the G6 desktop and dual-G5 PB will ship! Whee!
Here's why this doesn't matter at all. If you've ever spent any time shopping for a computer, you'll notice that prices on existing models always drop, and new exciting models are always around the corner. It never ends.
Either you can wait for a new computer, or you can't. You'll go crazy trying to dig for rumors and hints as to when model XYZ with the 5 terawooble whosie-whatsis will be released, instead of the 4 terawooble that's available now. Gotta have the 5! I just gotta!
But really, you don't. If you have urgent important money-making work that needs doing now, buy something now. You can sell it later when a newer model comes out that's so much better that it's worth the switch. It's not like you're going to church and declaring your lifelong pledge to use this and only this computer so long as you both shall live.
If you don't need something today, then why are you in such a hurry to buy the latest-greatest? The top end product always carries a price premium, and quite often has availability problems. You're just setting yourself up to pay extra for something you don't need.
Most vendors let you return the computer within a few days if there's a new model announcement right then, or at least they'll price-protect you if you complain enough (i.e. you get the lower price under the new model lineup, so they refund you the difference).
If you're really in such a hurry, you could lift a finger to try to speed things up.
I just went to www.apple.com/store and clicked through the configurator for the 3 featured G5 configs. No changes, just Select->Continue->Continue from the store main page to get to the shopping cart where there's a ship time estimate.
The dual 1.8GHz: 3-5 business days.
The dual 2GHz: 3-5 business days.
The dual 2.5GHz: 4-6 weeks.
Changing the configuration delays things a bit, but not much. I took the dual-2.0GHz G5 and maxed out the RAM, HD, and video card options, and now it says 7-10 business days.
It looks to me like only the dual 2.5GHz G5 is in short supply (not surprising since it's probably the one that IBM is having the hardest time making the CPU for, though that's just my speculation). The other models aren't. Cancel your order for a dual 2.5 and get a 1.8 or 2.0 dual G5 instead, and tweak the config to your heart's content. Or, if you really really need that 2.5, wait. If you're in a tearing hurry, you could probably walk into an Apple retail store and walk out with one the same day.
Alternatively, you could buy your G5 from MacWarehouse or Outpost.com. Some of them will add RAM and stuff for you; others might not. Outpost.com says they can ship the dual 1.8 and dual 2.0 same-day. CDW says they have dual-1.6 G5's also available same day. This is right on their search results page. I didn't even pick up the phone to find this out. I searched for "G5" on Outpost.com, and MacWarehouse had a link to the closeout 1.6GHz model on their home page.
Using C|Net shopper to find the best price on a dual 2.0GHz G5 shows a list of merchants in which every single one claims to have this model in stock now.
This took me about 10 minutes of surfing to find out. Maybe you should spend a few minutes yourself since it's your computer order?