The driving force between the Chinese space program is the fear of US dominance. It's in their interest (and in the interest of everyone else) that no single nation has significantly more power than others; that means world wide and concerning a small region.
That's why China sold the nukes to Pakistan. One nation being significantly more powerful than everyone around them is a recipe for instability and desaster. It's the same axiom by which the US and Israel governments act as well, when they give Taiwan weapons or access to espionage satellites.
The only detail that is not obvious about this is why the world has let the US become so dominant in the first place. Maybe because there was nobody powerful enough to stop them?
The international fear and uncertainty has become so large that the Pentagon even feld compelled to say they wouldn't enact a global GPS blackout during war time. This is obviously a completely unbearable situation for anyone besides the US government. Here is a link:
I don't know what happened to the Russian space positioning system that was once discussed as alternative, but the European Union is completely right in that they think they have to create an alternative to GPS. Even more puzzling is the fierceness with which the USA have tried to stop Galileo (why would they do that if not to leverage their monopoly pressure?). Here is a satnews.com story about it:
The argument of the US government against Galileo was that it "could be abused by future enemies". So you can see how the US government is using GPS to pressure others. It is very important to create an alternative to GPS, even if it's just to stop the US from bullying other nations.
So much about Galileo, but what about other reasons for a non-US space program? I think one of the most dramatic display of bullying ever to be seen by any government is what the US government semi-openly discussed according to a Reuters story this February: to deny other nations access to space:
If any sovereign nation sees something like this, it is obvious that a big space program besides the US one is absolutely necessary. The USA have proven time and again that they are a very volatile friend who on a whim decides to deny their resources to their friends.
There was one well documented case in the Bosnian war that is quite telling. The US vehemently denied ground troops and any real war involvement of theirs in Bosnia, on the grounds that Clinton thought his political career would be over of pictures of dead soldiers arrived home. So the role of the USA was mostly reconnaissance and intelligence and they did help keeping the air space empty. However, it later turned out that they gave weapons to the rebels, in violation of NATO orders. Here is one link about it:
This is a very serious issue, please don't take my word for it, look for yourself. There was a good joint European documentary about it a while ago, where they interviewed the NATO official in Bosnia, a Norwegian military official, and he said that the USA basically denied their allies the contractually guaranteed intelligence to cover up their covert operations.
In my eyes this kind of behaviour leaves Europe no other choice but to go for independence in space and military. Most nations have given in to US surveillance and intelligence superiority, some like Australia and Britain even joined the Echelon system. There are stories that even those very close allies do not have full access to the jointly generated intelligence. In effect, the USA is exploiting and abusing everyone else around them, and now Mr Bush has stepped over the line with his excessive bullying and the other nations are banding together.
I have been waiting for this for many years, and I am happy that it finally happened. While I despise Bush on all levels, he did something very valuable for the world. He gave them enough motivati
Ah, you are talking about the filter method where you pipe your mail through another smtp daemon. Since that is obviously trivial to do with any other MTA as well, I didn't think anyone would sink so low as to actually mention this as feature, let alone "advanced filtering".
With postfix, stdin for filters is non-seekable. The reason is the funky queue file layout that Wietse chose.
Virus scanners need to seek around in the mail files (or they buffer the whole mail in memory, which is even worse performance-wise). All modern virus scanners are running as daemons and are given a file name over a unix domain socket. To be able to give a file name of a file that contains the mail (and not some other postfix queue junk as well) to the virus scanner, you need to write a temp file. There simply is no way around that.
Seems someone doesn't know the difference between a "security model" and a buffer overrun...
Yeah, a security model is what you implement to make sure buffer overruns don't matter. In qmail, for example, the security model has the smtp daemon run with just enough permissions to write incoming mails in the incoming queue.
you may wish to read about queue groups and multiple queues
You really believe this marketing crap, do you? Wohoo, "queue groups", I bet it's almost as great and innovative a feature as thread pools.
using LDAP already puts the administrator in the awkward position of requiring unsupported 3rd-party patches
Actually, no. Not at all. I implemented a qmail with all-virtual LDAP users and did not have to touch the qmail source code once. I did not even have to replace or overwrite any binaries.
qmail is modular enough that you can specify other delivery and the password authentication modules, in my case LDAP speaking onces. That's it. Partial sources are here.
The code is very well-written and and properly commented. Something you can't say about qmail.
The qmail code is obvious enough not to need much commentary. You can judge the quality of a code base pretty well be looking at a) how many patches are available (if the code base sucks, nobody will want to patch it; people will rather write their own MTA), b) how big the patches are (if the code base sucks, you need to touch more in your patches to get your problem fixed), and c) how often it needs updates.
It is true that qmail is missing functionality that many people want. On the other hand, much of that functionality does not need patches at all; for example Dan implemented RBL checks in a separate program without even touching the qmail code base.
Your other remarks about the qmail code are totally unfounded as well. I have never been more happy with a code base to patch than with qmail and djbdns. The helper functions are all there, qmail even contains man pages for most of them, the manual (and source code!) are small enough that I don't have to spend a year in a monestary in Tibet to even survey all of it...
I really wonder where that urban legend comes from that the qmail code is hard to read or maintain. Your other point about relay debugging is wrong as well, you can check relaying in qmail without even running it, you just have to run the smtp part of it, and that part can be run without even binding to a TCP port. In short, there is no way it could be easier or better to debug.
How can you claim that one needs procmail with qmail? One of the reasons I switch to qmail in the first place was to get rid of procmail. It is an evil kludge around broken designs like sendmail, it is not needed with qmail any more.
So, in conclusion, please keep the FUD to yourself and bring us some real arguments here.
It's easiest to use a virtual domain with a two-line shell script glue, but you can also just use spamassassin as default delivery method and let the users override it in their.qmail files.
Who says Dan isn't planning any more releases? And who cares if you can patch your own release? Why would you care if you can distribute a patched release when you can distribute an unpatched pristine version and a patch (which, incidentally, is what all the Linux distributions do anyway)?
Also, qmail is the only MTA I know that can virus check email without bogging down the system with temp files. The reason is qmail's advanced queue layout (which Wietse in his inexperience and incompetence preferred to bash for personal reasons and now Postfix needs temp files for virus scanners and whatnot, doubling real life disk I/O in comparison to qmail. Good job, Wietse).
The downside of qmail is that you need to spend time understanding it. The upside is that you can thorougly understand it in a week or so, while you can barely skim through all the cruft in the Exim manual in that time.
ROTFL, sendmail has an excellent security model in 8.12? Yeah, you can see that clearly when you read things like the last remote root exploit in sendmail 8.12.7, or are you now going to argue that 8.12 really starts with 8.12.8?
And what "advanced queueing features" are you talking about here? If you mean milter, that is a kludge akin to fastcgi, and it typically involves linking untrustworthy sendmail code to your filter application. I don't know about you, but for me that is not an option. Never has been, never will be.
And qmail looking outdated, that claim is so ridiculous, it does not even warrant an argument. Sorry, dude, but my little brother is a better troll than you are. Muhaha, you are even cheap enough to post as AC instead of using a throwaway account...
On the other hand, every software that gets people off sendmail is to be applauded. So if you can't go for qmail and currently run sendmail, and postfix is not an option as well, go for exim.
Exim has the same bad monolithic setuid-root style design as sendmail and even more useless (for the majority of people) features. It is a big messy pile of bloat code.
I don't understand why anyone would want to use a piece of software where the author apparently does not have even a small bar of quality or usefulness that a patch must fulfill to be accepted in the main code base. Someone asks for it on the mailing list? It gets added to Exim.
Server software has to be simple, understandable, small yet modular and powerful enough to make it possible to extend it if need be. Exim does not want to be extended, it wants to assimilate everything, making the result too big to be understandable by anyone (I wonder if even the author claims to understand every single line of code in there).
Postfix and qmail have vastly better design, can be extended easily and are minimal for what they strive to offer (in particular qmail).
qmail is used by more people than exim, yet fewer bugs (and in particular security problems) have been found in it. If you have a choice, go for qmail instead.
Some recent viruses mass mailed themselves using other people's domains at random. You might not have noticed this, but my traffic more than quadrupled because of me getting all the bounces -- over 18000 per day.
RMX would help here as well. And since there is no advantage in adding an RMX record of 0.0.0.0/0 over not adding an RMX record, this is per definition a spammer and his mail can be rejected.
Hell, I would implement it for djbdns and qmail any minute, but I didn't see a numerical record number yet, which means I don't know how to query this record type.
I can buy a regular transmitter and modify it to transmit on a forbidden frequency. Does that mean we can't sell transmitters or books telling people how to build one? No!
Keep-alive is important because it substantially reduces the amount of traffic used in service multiple small requests
No. The traffic difference between using keep-alive and not are two TCP packets, 60 bytes each (unless you use a modem line with header compression, in which case it is even less).
Keep-alive reduces the latency, though. The difference is big in benchmarks but small in practice. Without keep-alive I can still make over 2000 connections a second on my old notebook.
Not all clients support dynamically compressed content.
Oh, really? Which client are you talking about? wget? Mozilla, old Netscape, Opera and Internet Exploder support compressed content. That is about 99% of the market. Whom are you kidding here?
Many servers do not provide dynamically compressed content because it is heavy on CPU load.
No shit, Sherlock! So? They are generating dynamic content, which is inherently heavy on the CPU. Are you telling us that they didn't buy a large machine with powerful CPUs in the first place? Sorry but I call bullshit.
The issue isn't memory allocation, its speed of response. Dynamic pages can take a long time to generate.
If the user has to wait a long time for your content, the latency win of having content-length is neglegible in the first place. You just shot down your only argument.
First of all, it's perfectly OK to serve the dynamic content without a content-length header.
Second of all, the whole point of the content-length header is so that the client knows how much data will come and is thus able to allocate memory, see whether it will be able to process the whole content and display a progress bar. All of these are not possible with chunked encoding, so you get none of the benefits from content-length. Why not drop it in the first place?
Not having a content-length header has only one drawback: it breaks keep-alive connections. But since sane sites are compressing their dynamic content anyway to save bandwidth cost and make it appear quicker on the client machine, and dynamic HTML pages of 100k typically compress down to below 10k because HTML is so bloated, there really is no point in not buffering those 10k. The system has larger buffers than that for TCP anyway, so memory consumption is not a valid excuse. Also, if you do the buffering, you can add the content-length header and get all the benefits.
Oh, and one last point: we have had security problems caused by chunked encoding. We also have had a trillion security problems by idiots and static buffering, but so far nobody has been stupid enough to do compression and HTTP output buffering using a static buffer.
Standards should be lean and so easy to understand and so trivial to implement that one undergrad student can implement it to full compliance in one afternoon.
HTTP 1.1 has over 100 pages, most of them absolutely useless for implementors. Unnecessary verbiage, unnecessary optional parts, unnecessary warts, unnecessary "I'm working on a thesis about foo, let's put it in this standard and see what happens" crap.
Examples: chunked encoding -- absolutely superfluous! Amazingly useless. Or what about the range support? HTTP allows to request a byte range from a file. Normally you would use that to fetch the second half of an aborted download, or maybe for PDF reading you would fetch bytes 10 to 100 or so. HTTP 1.1 allows to specify several ranges in the same request, and the server is expected to construct some MIME abomination as answer, if it supports this at all. If it doesn't, it is allowed to coalesce the ranges and just send the whole range. This makes this feature horrendously useless for clients (why bother with it if you a) have to implement some sort of complicated parser to understand the result and b) won't even save bandwidth because the server isn't going to implement it in the first place and c) it is not even cheaper than just using keepalive connections and asking for the parts one by one.
In short: HTTP needs to die quickly and be replaced by something sane.
Did I mention the monstrosity that is content negotiation? It is impossible to write a proxy that can cache content in the face of content negotiation. Luckly, nobody uses it on their servers, because it is a pig to implement and configure on the server. Clients tend to support it, but who cares.
That is strange because in Europe the Norah Jones CD is one of the few titles that is not copy protected.
I wouldn't have bought it otherwise. I will not have my money be used to fund consumer crippling technology.
This is a joke, right? Right?!?
on
DRAM Price Fixing
·
· Score: 2, Interesting
Come one, RAM manufacturers are in deep trouble, and have been for many months if not years. RAM prices have fallen to their lowest point in history, much stronger even than CPU prices have tumbled.
How can anyone claim they "kept the prices high"?!
Or more interesting: Are they going to smoke it all alone or are they going to pass it around?
Slashdot Mirror
I need something against my haystack, not a software that does more sedimentary data storage.
Currently everyone is afraid of US hegemony.
The driving force between the Chinese space program is the fear of US dominance. It's in their interest (and in the interest of everyone else) that no single nation has significantly more power than others; that means world wide and concerning a small region.
That's why China sold the nukes to Pakistan. One nation being significantly more powerful than everyone around them is a recipe for instability and desaster. It's the same axiom by which the US and Israel governments act as well, when they give Taiwan weapons or access to espionage satellites.
The only detail that is not obvious about this is why the world has let the US become so dominant in the first place. Maybe because there was nobody powerful enough to stop them?
wired: U.S. Could Deny GPS To Taliban
The international fear and uncertainty has become so large that the Pentagon even feld compelled to say they wouldn't enact a global GPS blackout during war time. This is obviously a completely unbearable situation for anyone besides the US government. Here is a link:
Reuters: Pentagon pledges 'no global GPS blackout'
I don't know what happened to the Russian space positioning system that was once discussed as alternative, but the European Union is completely right in that they think they have to create an alternative to GPS. Even more puzzling is the fierceness with which the USA have tried to stop Galileo (why would they do that if not to leverage their monopoly pressure?). Here is a satnews.com story about it:
EU Postpones Decision on Galileo System Until 2002
The argument of the US government against Galileo was that it "could be abused by future enemies". So you can see how the US government is using GPS to pressure others. It is very important to create an alternative to GPS, even if it's just to stop the US from bullying other nations.
So much about Galileo, but what about other reasons for a non-US space program? I think one of the most dramatic display of bullying ever to be seen by any government is what the US government semi-openly discussed according to a Reuters story this February: to deny other nations access to space:
U.S. Pentagon Sees Space as Military 'High Ground'
If any sovereign nation sees something like this, it is obvious that a big space program besides the US one is absolutely necessary. The USA have proven time and again that they are a very volatile friend who on a whim decides to deny their resources to their friends.
There was one well documented case in the Bosnian war that is quite telling. The US vehemently denied ground troops and any real war involvement of theirs in Bosnia, on the grounds that Clinton thought his political career would be over of pictures of dead soldiers arrived home. So the role of the USA was mostly reconnaissance and intelligence and they did help keeping the air space empty. However, it later turned out that they gave weapons to the rebels, in violation of NATO orders. Here is one link about it:
Washington finances ethnic warfare
This is a very serious issue, please don't take my word for it, look for yourself. There was a good joint European documentary about it a while ago, where they interviewed the NATO official in Bosnia, a Norwegian military official, and he said that the USA basically denied their allies the contractually guaranteed intelligence to cover up their covert operations.
In my eyes this kind of behaviour leaves Europe no other choice but to go for independence in space and military. Most nations have given in to US surveillance and intelligence superiority, some like Australia and Britain even joined the Echelon system. There are stories that even those very close allies do not have full access to the jointly generated intelligence. In effect, the USA is exploiting and abusing everyone else around them, and now Mr Bush has stepped over the line with his excessive bullying and the other nations are banding together.
I have been waiting for this for many years, and I am happy that it finally happened. While I despise Bush on all levels, he did something very valuable for the world. He gave them enough motivati
Ah, you are talking about the filter method where you pipe your mail through another smtp daemon. Since that is obviously trivial to do with any other MTA as well, I didn't think anyone would sink so low as to actually mention this as feature, let alone "advanced filtering".
Heck, MS Exchange can do that!
ROTFL
With postfix, stdin for filters is non-seekable. The reason is the funky queue file layout that Wietse chose.
Virus scanners need to seek around in the mail files (or they buffer the whole mail in memory, which is even worse performance-wise). All modern virus scanners are running as daemons and are given a file name over a unix domain socket. To be able to give a file name of a file that contains the mail (and not some other postfix queue junk as well) to the virus scanner, you need to write a temp file. There simply is no way around that.
Please get your facts straight next time.
Yeah, a security model is what you implement to make sure buffer overruns don't matter. In qmail, for example, the security model has the smtp daemon run with just enough permissions to write incoming mails in the incoming queue.
You really believe this marketing crap, do you? Wohoo, "queue groups", I bet it's almost as great and innovative a feature as thread pools.
Actually, no. Not at all. I implemented a qmail with all-virtual LDAP users and did not have to touch the qmail source code once. I did not even have to replace or overwrite any binaries.
qmail is modular enough that you can specify other delivery and the password authentication modules, in my case LDAP speaking onces. That's it. Partial sources are here.
Get your facts straight next time, FUDster.
The qmail code is obvious enough not to need much commentary. You can judge the quality of a code base pretty well be looking at a) how many patches are available (if the code base sucks, nobody will want to patch it; people will rather write their own MTA), b) how big the patches are (if the code base sucks, you need to touch more in your patches to get your problem fixed), and c) how often it needs updates.
It is true that qmail is missing functionality that many people want. On the other hand, much of that functionality does not need patches at all; for example Dan implemented RBL checks in a separate program without even touching the qmail code base.
Your other remarks about the qmail code are totally unfounded as well. I have never been more happy with a code base to patch than with qmail and djbdns. The helper functions are all there, qmail even contains man pages for most of them, the manual (and source code!) are small enough that I don't have to spend a year in a monestary in Tibet to even survey all of it...
I really wonder where that urban legend comes from that the qmail code is hard to read or maintain. Your other point about relay debugging is wrong as well, you can check relaying in qmail without even running it, you just have to run the smtp part of it, and that part can be run without even binding to a TCP port. In short, there is no way it could be easier or better to debug.
How can you claim that one needs procmail with qmail? One of the reasons I switch to qmail in the first place was to get rid of procmail. It is an evil kludge around broken designs like sendmail, it is not needed with qmail any more.
So, in conclusion, please keep the FUD to yourself and bring us some real arguments here.
It's easiest to use a virtual domain with a two-line shell script glue, but you can also just use spamassassin as default delivery method and let the users override it in their .qmail files.
Who says Dan isn't planning any more releases? And who cares if you can patch your own release? Why would you care if you can distribute a patched release when you can distribute an unpatched pristine version and a patch (which, incidentally, is what all the Linux distributions do anyway)?
Also, qmail is the only MTA I know that can virus check email without bogging down the system with temp files. The reason is qmail's advanced queue layout (which Wietse in his inexperience and incompetence preferred to bash for personal reasons and now Postfix needs temp files for virus scanners and whatnot, doubling real life disk I/O in comparison to qmail. Good job, Wietse).
The downside of qmail is that you need to spend time understanding it. The upside is that you can thorougly understand it in a week or so, while you can barely skim through all the cruft in the Exim manual in that time.
ROTFL, sendmail has an excellent security model in 8.12? Yeah, you can see that clearly when you read things like the last remote root exploit in sendmail 8.12.7, or are you now going to argue that 8.12 really starts with 8.12.8?
And what "advanced queueing features" are you talking about here? If you mean milter, that is a kludge akin to fastcgi, and it typically involves linking untrustworthy sendmail code to your filter application. I don't know about you, but for me that is not an option. Never has been, never will be.
And qmail looking outdated, that claim is so ridiculous, it does not even warrant an argument. Sorry, dude, but my little brother is a better troll than you are. Muhaha, you are even cheap enough to post as AC instead of using a throwaway account...
(replying to myself again... ;-})
On the other hand, every software that gets people off sendmail is to be applauded. So if you can't go for qmail and currently run sendmail, and postfix is not an option as well, go for exim.
Exim has the same bad monolithic setuid-root style design as sendmail and even more useless (for the majority of people) features. It is a big messy pile of bloat code.
I don't understand why anyone would want to use a piece of software where the author apparently does not have even a small bar of quality or usefulness that a patch must fulfill to be accepted in the main code base. Someone asks for it on the mailing list? It gets added to Exim.
Server software has to be simple, understandable, small yet modular and powerful enough to make it possible to extend it if need be. Exim does not want to be extended, it wants to assimilate everything, making the result too big to be understandable by anyone (I wonder if even the author claims to understand every single line of code in there).
Postfix and qmail have vastly better design, can be extended easily and are minimal for what they strive to offer (in particular qmail).
qmail is used by more people than exim, yet fewer bugs (and in particular security problems) have been found in it. If you have a choice, go for qmail instead.
You know, I would mind.
I am paying for my incoming email bandwidth with money and time. I am not willing to read anyone's commercials or newsletters in email.
If I were interested in their crap, I'd check their web site.
Some recent viruses mass mailed themselves using other people's domains at random. You might not have noticed this, but my traffic more than quadrupled because of me getting all the bounces -- over 18000 per day.
RMX would help here as well. And since there is no advantage in adding an RMX record of 0.0.0.0/0 over not adding an RMX record, this is per definition a spammer and his mail can be rejected.
Hell, I would implement it for djbdns and qmail any minute, but I didn't see a numerical record number yet, which means I don't know how to query this record type.
Ah, so these are the people OpenBSD learned everything from, right?
is because nobody wants to have anything to do with Qualcomm ;-)
HE WROTE the OSI position paper, you dimwit!
I can buy a regular transmitter and modify it to transmit on a forbidden frequency. Does that mean we can't sell transmitters or books telling people how to build one? No!
I think this is a straw man argument.
Keep-alive is important because it substantially reduces the amount of traffic used in service multiple small requests
No. The traffic difference between using keep-alive and not are two TCP packets, 60 bytes each (unless you use a modem line with header compression, in which case it is even less).
Keep-alive reduces the latency, though. The difference is big in benchmarks but small in practice. Without keep-alive I can still make over 2000 connections a second on my old notebook.
Not all clients support dynamically compressed content.
Oh, really? Which client are you talking about? wget? Mozilla, old Netscape, Opera and Internet Exploder support compressed content. That is about 99% of the market. Whom are you kidding here?
Many servers do not provide dynamically compressed content because it is heavy on CPU load.
No shit, Sherlock! So? They are generating dynamic content, which is inherently heavy on the CPU. Are you telling us that they didn't buy a large machine with powerful CPUs in the first place? Sorry but I call bullshit.
The issue isn't memory allocation, its speed of response. Dynamic pages can take a long time to generate.
If the user has to wait a long time for your content, the latency win of having content-length is neglegible in the first place. You just shot down your only argument.
First of all, it's perfectly OK to serve the dynamic content without a content-length header.
Second of all, the whole point of the content-length header is so that the client knows how much data will come and is thus able to allocate memory, see whether it will be able to process the whole content and display a progress bar. All of these are not possible with chunked encoding, so you get none of the benefits from content-length. Why not drop it in the first place?
Not having a content-length header has only one drawback: it breaks keep-alive connections. But since sane sites are compressing their dynamic content anyway to save bandwidth cost and make it appear quicker on the client machine, and dynamic HTML pages of 100k typically compress down to below 10k because HTML is so bloated, there really is no point in not buffering those 10k. The system has larger buffers than that for TCP anyway, so memory consumption is not a valid excuse. Also, if you do the buffering, you can add the content-length header and get all the benefits.
Oh, and one last point: we have had security problems caused by chunked encoding. We also have had a trillion security problems by idiots and static buffering, but so far nobody has been stupid enough to do compression and HTTP output buffering using a static buffer.
Standards should be lean and so easy to understand and so trivial to implement that one undergrad student can implement it to full compliance in one afternoon.
HTTP 1.1 has over 100 pages, most of them absolutely useless for implementors. Unnecessary verbiage, unnecessary optional parts, unnecessary warts, unnecessary "I'm working on a thesis about foo, let's put it in this standard and see what happens" crap.
Examples: chunked encoding -- absolutely superfluous! Amazingly useless. Or what about the range support? HTTP allows to request a byte range from a file. Normally you would use that to fetch the second half of an aborted download, or maybe for PDF reading you would fetch bytes 10 to 100 or so. HTTP 1.1 allows to specify several ranges in the same request, and the server is expected to construct some MIME abomination as answer, if it supports this at all. If it doesn't, it is allowed to coalesce the ranges and just send the whole range. This makes this feature horrendously useless for clients (why bother with it if you a) have to implement some sort of complicated parser to understand the result and b) won't even save bandwidth because the server isn't going to implement it in the first place and c) it is not even cheaper than just using keepalive connections and asking for the parts one by one.
In short: HTTP needs to die quickly and be replaced by something sane.
Did I mention the monstrosity that is content negotiation? It is impossible to write a proxy that can cache content in the face of content negotiation. Luckly, nobody uses it on their servers, because it is a pig to implement and configure on the server. Clients tend to support it, but who cares.
Yet another disappointment from Sun.
They keep using inferior PC technology so there are at least some minor benefits from SPARC left over to point at.
How disgusting.
Who knows whether it will still be competitive in several months when they actually want to offer it.
On the other hand Apple users won't have much of a choice, and neither has Apple.
That is strange because in Europe the Norah Jones CD is one of the few titles that is not copy protected.
I wouldn't have bought it otherwise. I will not have my money be used to fund consumer crippling technology.
Come one, RAM manufacturers are in deep trouble, and have been for many months if not years. RAM prices have fallen to their lowest point in history, much stronger even than CPU prices have tumbled.
How can anyone claim they "kept the prices high"?!
Or more interesting: Are they going to smoke it all alone or are they going to pass it around?