The economy is dependant on diesel. Gas is just the thing that get's individuals in their cars from place to place. Diesel is what they burn to ship frieght.
There are no electric or "alternative fuel" based forms of transportation that provide the thrust/weight ratio Gasoline is too expensive to ship frieght. Gas engines are horribly inefficient compared to diesel. A truck driver with his 20-gear diesel engine gets terrible mileage. But that's because he's lugging along a huge amount of weight. If you used gasoline, nobody could afford to ship anything around. Do you think it's a coincidence that even the smallest commercial trucks burn diesel? BTW, diesel is also a lot cleaner (except for the particulates) than gasoline, as well.
Also, I very specifically pointed out that diesel prices would _drop_ if you cut gas consumption. Every gallon of gas burnt is a bit less petroleum available for diesel.
Yes, raising the price of diesel would do horrible things to the economy. But that is most definately NOT what I suggested.
A real performance car (one that's meant to go fast + handle well) gets much better mileage than any SUV. Some of them even get pretty good mileage. They're generally smaller than an ordinary car, and they are made from much lighter materials. A 250 hp engine is an engine that _can_ produce 250 hp. It's also perfectly capable of only produce 100 hp, or some lesser amount. An SUV, on the other hand, is very heavy, so it takes much more energy to get it going, and all of that energy is lost whenever you brake.
Read this month's Consumer Reports, for example (sorry, the link to the article is paid subscription only, try your local library). They're reviewing the Honda S2000, Toyota MR2, Toyota Celica, and Mitsubishi Eclipse. All of them get more than 20 mpg, and I think the Honda gets nearly 30. Compare that to an SUV's 10-15 mpg.
There's an old adage that in order to convince people to switch from an entrenched standard, you have to be 10x better. The infrastructure behind gasoline is extensive, and despite the technological deficiencies of gas, economically it is the cheapest way to get around.
The only way to make the alternatives that much better is to make gas worse.
Tax gas. Tax inefficient cars. Raise the pollution controlls on _gas_ powered vehicles through the roof.
You may think that this will hurt people and drive up prices. It may drive up the price of gasoline, and the price of driving around, but if you do it right, you can keep the cost of living about the same. Remember, the more expensive it is to drive around burning gasoline, the less gasoline will be burnt. The gas we burn, the less crude oil goes into its production. And the more crude we have, the cheaper we can make diesel, kerosene, plastics, etc. Artificially expensive gas means cheaper frieght charges (cheap diesel), cheap power (cheap crude/kerosene), and cheap consumer goods (plastics and other petrochemicals).
Of course, this would still look bad politically, but you can balance that out by putting all those tax revenues towards gas price relief for poor people, tax credits for efficient cars, etc. It would also (possibly) have the effect of breaking up OPEC. If demand falls, the marginal OPEC members (Veneualia (sp?) et. al.) will almost be forced to cheat on their quotas to make ends meet. And once enough of the small ones start cheating, the rest will follow suit, cutting the price of diesel/electicity/plastics/whatever even further.
If you are careful to balance the effects against each other, you can have your alternative fuels/low pollution without fscking everybody over.
especially with gas being as high as it is right now
The reason gas prices are so high is because people are buying gas-guzzling SUV's and driving up the demand for gasoline to insane levels, while OPEC has not increased production to match. If any chunk of the population switched to alternative fuels, the price of gas would drop through the floor. The lower demand would also severly hinder OPEC, and possible break the cartel, allowing the price of gas to fall further. But with gas at ultra-low prices, nobody in their right mind would want to pay for the (comparitivly) expensive alternatives.
Car companies will start making high-efficiency cars, since a fringe of the population (myself included) has grown large enough to make it profitable to satisfy the demand. Honda has that new car (the Prius?) that gets ~60-70 MPG, and Toyota is going to start shipping a similar car. The vast bulk of people (at least in the US), however, will still want their huge inefficient SUV's.
I belive a Ford exec said that the company would be overjoyed to stop manufacturing SUV's, but that as long as people demanded them, Ford had to supply them to stay afloat. The solution is in convincing John Q. Public that running an efficient, clean car (gasoline or otherwise), rather than his big, overpowered SUV, is what he wants to do.
...but if you are suggesting that RDRAM is better then SDRAM, and that the reviews in favor of SDRAM are 'bought', then you're wrong.
Well, maybe they're bought, but SDRAM has a much lower latency, and therefore works better with modern processors. RDRAM only gives benefit if you use it in a unified memory architecture, and that's only used for low-end PC's where the price of RDRAM makes it out of the question. On a high-end PC, where the extra cost could be justified, it may end up hurting performance a tad.
Best that I can tell, sendmail doesn't implement it. I might be horrible misreading the RFC, but it seems that EHLO will cause a supporting MTA to return a line with STARTTLS on it, and that STARTTLS is a valid imperitive on such MTA's.
I'm trying this on 8.9.3. I looked on sendmail.org, and couldn't find any reference to STARTTLS, or RFC 2487, so I don't think 8.10.* does either. If you have info on an official version of sendmail that supports this, I'd be very interested.
Now, if STARTTLS were supported on sendmail, then the main problem would be the key exchange mechanism. If it is supported on sendmail, then you have (with sendmail alone) a large chunk of the MTA's. But as I said, sendmail doesn't appear to support this.
use a client that connects to the addressee's mail server directly
I was sort of assuming that. I was fairly sure that most clients do that anyway, although I could easily be wrong. I've never been at a site that allowed mail to be sent in any other way, but I don't really have a large sample size.
It is perfectly true that even assuming that all communications are between your machine and the addressee's ISP, all the FBI needs is to get the ISP's private key. (Although as I mentioned elsewhere, Diffie-Hullman eliminates that somewhat). However, the point is to make semi-targeted automatic scanning infeasable.
True, but they would have to get it from the recipients ISP, not the senders, which is a lot more work.
I suppose a better system that RSA would be to use Diffie-Hullman, and don't log the exchange. No private key to give away. They still may be able to pull the unencrypted mail from a user's mail spool file, but that can be done on a per-individual basis.
My point isn't keeping the FBI from reading the mail of people they have a warrent to monitor. I don't want it to be technically feasible for them to monitor large numbers of people indescriminately.
If the FBI gets a warrent to put a Carnivore machine in my ISP's network, they get to read everything, including my mail which they do not have a specific warrent for. If they cannot just pull stuff indescriminately, they have to get a warrent for the particular individual that they want. No judge would issue a warrent for 'every mail spool on the server' (I hope), although the may (wrongly) issue a warrent to monitor a criminal's ISP. By reducing the feasability of a quasi-legal general tap, I protect my own liberties, while still allowing the FBI to monitor those people who really need it, in the eyes of a judge.
If sendmail supported these extentions, and the default behavior of the clients was to try to use STARTTLS, then, well, everything would be happy.
That is, postfix admits that it is a bit different than sendmail, and can cause problems (although minor and few). In any case, the effort spent into developing parallel projects would (IMHO) be better spent extending what is essentially _the_ SMTP program, sendmail. You would get 'automatic' deployment of secure SMTP, transparently to the end users, and almost transparently to the sysadmins (just upgrade sendmail, which is a good thing to do anyway).
PGP isn't a good solution because it requires too much work on the part of the mail senders/recipients. Postfix w/the TLS extension won't work for a related reason. It's too much to expect sysadmins all over the world to switch software, put work into learning it's quirks, and possibly loose functionality that was in sendmail.
One possibility would be extending sendmail. If sendmail.org added a secure version of the various protocols (using the (almost) newly expired RSA public-key system), it would be invisible to the user.
I suppose one could have SMTP report if it supports the new protocol, (SHLO to go along with EHLO/HELO ?) and if wherever the mail is being send does, you could use an extended set of commands to request a public key (KREQ ? ) from the server, send a session key (SKEY ), and encrypt the remainder of the session.
Since sendmail is nearly umbiquitous, they could define the protocol however they pleased, publish it as a RFC per the usual routes, and have a defacto standard. One could (should) do the same thing with http, IMHO. Of course that would be up to the WC3.
Unfortunatly encrypting the content of SMPT transfers/http doesn't protect against traffic analysis. Oh well...
It really wouldn't help the spammers. Spammers get by nowadays with people running out-of-date/insecure versions of programs like sendmail. It's already possible for a technically skilled spammer to send an essentialy unlimited quantity of spam anonymously. Until you lock down all of those idiots who never bothered turning off the unnecessary services, you're going to get spam. At least Fling has a valid alternative use.
In any case, it would be really easy to set up procmail to give special treatment to anything coming in from your Fling-ized mail daemon.
They have "not packaged for individual resale" stamped on them because they don't have all of the nutrition information and ingredients listed that they are required to have by the FDA.
Now, if a store owner pops open a bag of candy, and labels them all with the nutrition information, then it is perfectly legal for them to sell the bars. It isn't the company making the candy bars that is keeping them from reselling, but the FDA.
With the OEM software, however, it is Microsoft telling retailers that they don't really have the Right of First Sale that is traditionally (read, always was until this new-fangled computer stuff came along) applied to the tranfer of copyrighted works. Also, most European companies have very strict anti-bundling laws (usually as anti-trust laws), making the practice illegal/unenforcable. It won't be that OEM software will cost more, it's that it shouldn't have ever cost so little.
Besides, M$ has every reason to keep OEM software cheap, so that everybody installs their OS, and then later runs out and buys their applications. Of course, the anti-trust case in the US may change that.
The majority of a modern processors speed comes from massive pipelining and predictive techniques. While a high bandwidth data connection to system RAM helps some (RDRAM), what is really important is low latency.
When the processor executes all of its instructions and has to fetch the next set from system RAM, it 'stalls', and just sits there spinning it's gears until the RAM gets back to it. The same thing happens if the processor needs some data value from the RAM. While the system RAM may be very fast, it is very slow compared to the processor, and it can take up to a hundred clock cycles for the RAM to reply. That entire time, the processor is doing jack squat.
In order to keep the processor busy, modern processors have caches. The L1 cache is a (usually small) cache that lives on the same chunk of silicon as the processor. It is incredibly fast, and can be considered to have a latency of one clock cycle or less. Whenever the processor requests something (data or an instruction), it tries to fetch it from the L1 cache first. If it is there, all is happy. Otherwise, there is a cache miss, and the processor has to look elsewhere for the data. When it get said data, the L1 cache is also loaded with many nearby chunks of data, in the hopes that what the processor wants next will be nearby to what it wants now.
In the event of an L1 cache miss, the the L2 cache is checked. The L2 cache is not on the same silicon, but it is still inside the same package. The L2 cache is much larger than the L1 cache, but also much slower. It has a latency of around 2 to 10 clock cycles. Just like the L1 cache, when there is a miss, it fetches in more than what is needed.
If there is a L2 cache miss, then you may very rarely go to an L3 cache. Your system (probably) does not have an L3 cache. Next in line is therefore the system RAM. And, if you increadibly unlucky, what you need is not in the RAM, but has been swapped out, and you have to wait an eternity for it to be paged back in.
Given all of this, one can surmise that if you are going to make a processor perform better at the same clock rate, then you can:
1) Get more L1 cache. 2) Get more L2 cache. 3) Get more (or get a) L3 cache. 4) Get more system RAM.
Xeons perform so much better that the ordinary processors, especially if used in a multi-tasking intensive environment, because then have gobs of cache. They have 1-2 MB of L2 cache, as opposed to at most 256KB of cache on their standard processors. If you run something that routinely has cache misses, you may only be actually getting 10% perfomance out of your CPU. Xeons don't miss nearly as often. Of course, cache memory is very expensive (especially L1), and can drive up the price a lot. Xeons also give some performance benifits in SMP (as they were designed for it, rather than just support it). 8-way SMP w/fast processors that have gobs of cache is very expensive, and people tend to put such beasts of machines to heavy work, like dishing up web pages to millions of people, rather than running the screen saver.
A grad student here at WUSTL just gave his master's thesis defence on optical interconnects. He compared the performance of using some very fancy (and risky) cache prefetching optimizations to using an optical interconnect between the CPU and the system memory. Essentially, he cut the effective lag of system memory to that of the L2 cache. Imagine having a 100% cache hit rate, w/out appreciably increasing the access time. Drool. That, and he also boosted the bandwidth to unbelievable speeds for chip to chip, and eliminated the crosstalk/RF problems (of course, what do you expect using fibre?). I just can't wait until the whole thing gets cheap enough to put inside my own box.
Well, here at WUSTL, we have one professor who supposedly does user interfaces full time (although his web page blows).
Also, there is a whole lab devoted to "visualization, which while their web page shows a bit of an emphasis towards video/multimedia, they do to a lot of work on data presentation and control layout.
I can't find any web resources for it, but there's a neat display on somebody's research into CHI (computer-human interaction) where they visualized the execution of a program very well, and then tied the visualization to execution control, such that you could very easily set optimization/execution priorities.
I suppose none of this is really straight GUI research, but more of CHI research with graphical focus.
Napster, for example, can get themselves out of hot water if they win this round with that defense, even if the misuse ends at a later date, because of double jeopardy. If they haul your ass to court for copyright infringement while misuse is going on, and you win (for that reason or another), then they can't try to get you again for the same thing when they get the right to enforce their copyright back.
But if you copy now (while misuse occurs), but then they only try to enforce when they have the right to do so, then you don't really have a leg to stand on.
If you can do them separately, it is just like a 41 bit key.
40 bit key = 2^40 trial guesses. Two 40 bit keys = 2 * 2^40 guesses = 2^41 guesses. One 80 bit key = 2^80 guesses.
With an 80 bit key, you have to get the whole key right to see if you've gotten it. You may guess the first half right, but not know because you didn't guess the second half right.
Now, if you encrypt something with one 40-bit key, and then encrypt that whole thing again with another 40-bit key, THAT takes 80 bits of work. But encrypting two different chunks of data with two different keys creates only double the work (add one bit).
But only on the day before it started. Plus, the registration fee was more than a bit steep. I'm not going to drive from St. Louis to bust $99 on a conference, plus hotel/food, on one day's notice.
I think that this shows two very important things to anybody hosting a show in the future:
1) People are cheap. 2) They don't go if they don't know.
Maybe if we're lucky they'll put on another show in a year, and run it well. It's not that there is no support for Linux in the midwest, but that we (still) haven't had a good opportunity to show our support.
Looks like they are just adding a L3 cache, and than putting ramdoubler into hardware.
Of course, compressing/decompressing data in hardware very quickly (nanoseconds) is a lot better than being forced to go to swap (microseconds to milliseconds). Still, modern processors tend to take very big performance hits whenever a little bit of lag is introduced. The people at IBM aren't idiots though, and I suppose that keeping the lag down is what the L3 cache is for.
But I have a right to open boxes in my possession. MS sold me the box. I own the box (although I do not own the copyright to the software). I also own the media the software is on. The EULA is saying "By executing rights that you have regardless of this license, you agree to the license."
The GPL, on the other hand, says, "By executing rights that you do not have without agreeing to this licence, you agree to the license." If a person distributes GPLed software without agreeing to the GPL, then nothing has granted them the right to distribute. And by default under copyright law, this is illegal. So, if you 'violate' the GPL, you are guilty of one of two things:
1) You broke a contract (the GPL) which you agreed to. You are busted.
or
2) You broke copyright law by distributing/modifying copyrighted material without the permission of the copyright holder (you don't have permission since you didn't agree to the GPL). You are busted.
Also, (IANAL) if you break a contract, then the other side has the option of denying you all of you rights under the contract and nullifying the contract, after collecting damages resulting from the violation. So, if you do #1 (which could be hard to prove that you did somewhere agree to it), the FSF could screw you under contract law, and then have another go under copyright law.
The GPL is really quite well written. There are a few things that are a bit vague, but all of the important stuff is clearly spelt out, with all of the bases covered.
I don't think that a contract (NDA) can prevent you from running to law enforcement about something. I do know that a contract can't require you to break the law.
Also, if MS distributed GPLed code to you under an NDA, then, as the copyright still belongs to the original author (not Microsoft), and the GPL provisions for granting a GPL licence to anybody who gets the code, then you have a licence, by the copyright owner, to redistribed the GPLed portions. Straight to the FSF with a note explaining the source if you wish. Of course, you may or may not be allowed to distribute MS's illegal yet NDAed derivative work (their contributions), as it is questionable if that code would be GPLed.
Also, if any GPLed code copyrighted by the US government (say some research group that GPLed and released something), and somebody violated the GPL on that software, then there are federal whistleblower laws granting all sorts of special immunity to parties reporting this to the gov't. Of course, these don't apply to software owned by the FSF.
The good part of Linux is the Unixisms. Linux is probably the closest there is to a standards-compliant system around (much better than MS at least).
And, not to get everybody mad at me, but the Linux TCP/IP stack, while quite good, is not the best. BSD has the best TCP/IP stack out there, and it also happens to be the one that Microsoft uses (or at least used to).
Slashdot Mirror
The economy is dependant on diesel. Gas is just the thing that get's individuals in their cars from place to place. Diesel is what they burn to ship frieght.
There are no electric or "alternative fuel" based forms of transportation that provide the thrust/weight ratio
Gasoline is too expensive to ship frieght. Gas engines are horribly inefficient compared to diesel. A truck driver with his 20-gear diesel engine gets terrible mileage. But that's because he's lugging along a huge amount of weight. If you used gasoline, nobody could afford to ship anything around. Do you think it's a coincidence that even the smallest commercial trucks burn diesel? BTW, diesel is also a lot cleaner (except for the particulates) than gasoline, as well.
Also, I very specifically pointed out that diesel prices would _drop_ if you cut gas consumption. Every gallon of gas burnt is a bit less petroleum available for diesel.
Yes, raising the price of diesel would do horrible things to the economy. But that is most definately NOT what I suggested.
A real performance car (one that's meant to go fast + handle well) gets much better mileage than any SUV. Some of them even get pretty good mileage. They're generally smaller than an ordinary car, and they are made from much lighter materials. A 250 hp engine is an engine that _can_ produce 250 hp. It's also perfectly capable of only produce 100 hp, or some lesser amount. An SUV, on the other hand, is very heavy, so it takes much more energy to get it going, and all of that energy is lost whenever you brake.
Read this month's Consumer Reports, for example (sorry, the link to the article is paid subscription only, try your local library). They're reviewing the Honda S2000, Toyota MR2, Toyota Celica, and Mitsubishi Eclipse. All of them get more than 20 mpg, and I think the Honda gets nearly 30. Compare that to an SUV's 10-15 mpg.
Yeah. The Prius is from Toyota. The Honda is called the Insight. They're both really cool though...
There's an old adage that in order to convince people to switch from an entrenched standard, you have to be 10x better. The infrastructure behind gasoline is extensive, and despite the technological deficiencies of gas, economically it is the cheapest way to get around.
The only way to make the alternatives that much better is to make gas worse.
Tax gas. Tax inefficient cars. Raise the pollution controlls on _gas_ powered vehicles through the roof.
You may think that this will hurt people and drive up prices. It may drive up the price of gasoline, and the price of driving around, but if you do it right, you can keep the cost of living about the same. Remember, the more expensive it is to drive around burning gasoline, the less gasoline will be burnt. The gas we burn, the less crude oil goes into its production. And the more crude we have, the cheaper we can make diesel, kerosene, plastics, etc. Artificially expensive gas means cheaper frieght charges (cheap diesel), cheap power (cheap crude/kerosene), and cheap consumer goods (plastics and other petrochemicals).
Of course, this would still look bad politically, but you can balance that out by putting all those tax revenues towards gas price relief for poor people, tax credits for efficient cars, etc. It would also (possibly) have the effect of breaking up OPEC. If demand falls, the marginal OPEC members (Veneualia (sp?) et. al.) will almost be forced to cheat on their quotas to make ends meet. And once enough of the small ones start cheating, the rest will follow suit, cutting the price of diesel/electicity/plastics/whatever even further.
If you are careful to balance the effects against each other, you can have your alternative fuels/low pollution without fscking everybody over.
especially with gas being as high as it is right now
The reason gas prices are so high is because people are buying gas-guzzling SUV's and driving up the demand for gasoline to insane levels, while OPEC has not increased production to match. If any chunk of the population switched to alternative fuels, the price of gas would drop through the floor. The lower demand would also severly hinder OPEC, and possible break the cartel, allowing the price of gas to fall further. But with gas at ultra-low prices, nobody in their right mind would want to pay for the (comparitivly) expensive alternatives.
Car companies will start making high-efficiency cars, since a fringe of the population (myself included) has grown large enough to make it profitable to satisfy the demand. Honda has that new car (the Prius?) that gets ~60-70 MPG, and Toyota is going to start shipping a similar car. The vast bulk of people (at least in the US), however, will still want their huge inefficient SUV's.
I belive a Ford exec said that the company would be overjoyed to stop manufacturing SUV's, but that as long as people demanded them, Ford had to supply them to stay afloat. The solution is in convincing John Q. Public that running an efficient, clean car (gasoline or otherwise), rather than his big, overpowered SUV, is what he wants to do.
Good luck.
...but if you are suggesting that RDRAM is better then SDRAM, and that the reviews in favor of SDRAM are 'bought', then you're wrong.
Well, maybe they're bought, but SDRAM has a much lower latency, and therefore works better with modern processors. RDRAM only gives benefit if you use it in a unified memory architecture, and that's only used for low-end PC's where the price of RDRAM makes it out of the question. On a high-end PC, where the extra cost could be justified, it may end up hurting performance a tad.
Best that I can tell, sendmail doesn't implement it. I might be horrible misreading the RFC, but it seems that EHLO will cause a supporting MTA to return a line with STARTTLS on it, and that STARTTLS is a valid imperitive on such MTA's.
I'm trying this on 8.9.3. I looked on sendmail.org, and couldn't find any reference to STARTTLS, or RFC 2487, so I don't think 8.10.* does either. If you have info on an official version of sendmail that supports this, I'd be very interested.
Now, if STARTTLS were supported on sendmail, then the main problem would be the key exchange mechanism. If it is supported on sendmail, then you have (with sendmail alone) a large chunk of the MTA's. But as I said, sendmail doesn't appear to support this.
use a client that connects to the addressee's mail server directly
I was sort of assuming that. I was fairly sure that most clients do that anyway, although I could easily be wrong. I've never been at a site that allowed mail to be sent in any other way, but I don't really have a large sample size.
It is perfectly true that even assuming that all communications are between your machine and the addressee's ISP, all the FBI needs is to get the ISP's private key. (Although as I mentioned elsewhere, Diffie-Hullman eliminates that somewhat). However, the point is to make semi-targeted automatic scanning infeasable.
True, but they would have to get it from the recipients ISP, not the senders, which is a lot more work.
I suppose a better system that RSA would be to use Diffie-Hullman, and don't log the exchange. No private key to give away. They still may be able to pull the unencrypted mail from a user's mail spool file, but that can be done on a per-individual basis.
My point isn't keeping the FBI from reading the mail of people they have a warrent to monitor. I don't want it to be technically feasible for them to monitor large numbers of people indescriminately.
If the FBI gets a warrent to put a Carnivore machine in my ISP's network, they get to read everything, including my mail which they do not have a specific warrent for. If they cannot just pull stuff indescriminately, they have to get a warrent for the particular individual that they want. No judge would issue a warrent for 'every mail spool on the server' (I hope), although the may (wrongly) issue a warrent to monitor a criminal's ISP. By reducing the feasability of a quasi-legal general tap, I protect my own liberties, while still allowing the FBI to monitor those people who really need it, in the eyes of a judge.
If sendmail supported these extentions, and the default behavior of the clients was to try to use STARTTLS, then, well, everything would be happy.
That is, postfix admits that it is a bit different than sendmail, and can cause problems (although minor and few). In any case, the effort spent into developing parallel projects would (IMHO) be better spent extending what is essentially _the_ SMTP program, sendmail. You would get 'automatic' deployment of secure SMTP, transparently to the end users, and almost transparently to the sysadmins (just upgrade sendmail, which is a good thing to do anyway).
PGP isn't a good solution because it requires too much work on the part of the mail senders/recipients. Postfix w/the TLS extension won't work for a related reason. It's too much to expect sysadmins all over the world to switch software, put work into learning it's quirks, and possibly loose functionality that was in sendmail.
One possibility would be extending sendmail. If sendmail.org added a secure version of the various protocols (using the (almost) newly expired RSA public-key system), it would be invisible to the user.
I suppose one could have SMTP report if it supports the new protocol, (SHLO to go along with EHLO/HELO ?) and if wherever the mail is being send does, you could use an extended set of commands to request a public key (KREQ ? ) from the server, send a session key (SKEY ), and encrypt the remainder of the session.
Since sendmail is nearly umbiquitous, they could define the protocol however they pleased, publish it as a RFC per the usual routes, and have a defacto standard. One could (should) do the same thing with http, IMHO. Of course that would be up to the WC3.
Unfortunatly encrypting the content of SMPT transfers/http doesn't protect against traffic analysis. Oh well...
It really wouldn't help the spammers. Spammers get by nowadays with people running out-of-date/insecure versions of programs like sendmail. It's already possible for a technically skilled spammer to send an essentialy unlimited quantity of spam anonymously. Until you lock down all of those idiots who never bothered turning off the unnecessary services, you're going to get spam. At least Fling has a valid alternative use.
In any case, it would be really easy to set up procmail to give special treatment to anything coming in from your Fling-ized mail daemon.
They have "not packaged for individual resale" stamped on them because they don't have all of the nutrition information and ingredients listed that they are required to have by the FDA.
Now, if a store owner pops open a bag of candy, and labels them all with the nutrition information, then it is perfectly legal for them to sell the bars. It isn't the company making the candy bars that is keeping them from reselling, but the FDA.
With the OEM software, however, it is Microsoft telling retailers that they don't really have the Right of First Sale that is traditionally (read, always was until this new-fangled computer stuff came along) applied to the tranfer of copyrighted works. Also, most European companies have very strict anti-bundling laws (usually as anti-trust laws), making the practice illegal/unenforcable. It won't be that OEM software will cost more, it's that it shouldn't have ever cost so little.
Besides, M$ has every reason to keep OEM software cheap, so that everybody installs their OS, and then later runs out and buys their applications. Of course, the anti-trust case in the US may change that.
The majority of a modern processors speed comes from massive pipelining and predictive techniques. While a high bandwidth data connection to system RAM helps some (RDRAM), what is really important is low latency.
When the processor executes all of its instructions and has to fetch the next set from system RAM, it 'stalls', and just sits there spinning it's gears until the RAM gets back to it. The same thing happens if the processor needs some data value from the RAM. While the system RAM may be very fast, it is very slow compared to the processor, and it can take up to a hundred clock cycles for the RAM to reply. That entire time, the processor is doing jack squat.
In order to keep the processor busy, modern processors have caches. The L1 cache is a (usually small) cache that lives on the same chunk of silicon as the processor. It is incredibly fast, and can be considered to have a latency of one clock cycle or less. Whenever the processor requests something (data or an instruction), it tries to fetch it from the L1 cache first. If it is there, all is happy. Otherwise, there is a cache miss, and the processor has to look elsewhere for the data. When it get said data, the L1 cache is also loaded with many nearby chunks of data, in the hopes that what the processor wants next will be nearby to what it wants now.
In the event of an L1 cache miss, the the L2 cache is checked. The L2 cache is not on the same silicon, but it is still inside the same package. The L2 cache is much larger than the L1 cache, but also much slower. It has a latency of around 2 to 10 clock cycles. Just like the L1 cache, when there is a miss, it fetches in more than what is needed.
If there is a L2 cache miss, then you may very rarely go to an L3 cache. Your system (probably) does not have an L3 cache. Next in line is therefore the system RAM. And, if you increadibly unlucky, what you need is not in the RAM, but has been swapped out, and you have to wait an eternity for it to be paged back in.
Given all of this, one can surmise that if you are going to make a processor perform better at the same clock rate, then you can:
1) Get more L1 cache.
2) Get more L2 cache.
3) Get more (or get a) L3 cache.
4) Get more system RAM.
Xeons perform so much better that the ordinary processors, especially if used in a multi-tasking intensive environment, because then have gobs of cache. They have 1-2 MB of L2 cache, as opposed to at most 256KB of cache on their standard processors. If you run something that routinely has cache misses, you may only be actually getting 10% perfomance out of your CPU. Xeons don't miss nearly as often. Of course, cache memory is very expensive (especially L1), and can drive up the price a lot. Xeons also give some performance benifits in SMP (as they were designed for it, rather than just support it). 8-way SMP w/fast processors that have gobs of cache is very expensive, and people tend to put such beasts of machines to heavy work, like dishing up web pages to millions of people, rather than running the screen saver.
A grad student here at WUSTL just gave his master's thesis defence on optical interconnects. He compared the performance of using some very fancy (and risky) cache prefetching optimizations to using an optical interconnect between the CPU and the system memory. Essentially, he cut the effective lag of system memory to that of the L2 cache. Imagine having a 100% cache hit rate, w/out appreciably increasing the access time. Drool. That, and he also boosted the bandwidth to unbelievable speeds for chip to chip, and eliminated the crosstalk/RF problems (of course, what do you expect using fibre?). I just can't wait until the whole thing gets cheap enough to put inside my own box.
Well, here at WUSTL, we have one professor who supposedly does user interfaces full time (although his web page blows).
Also, there is a whole lab devoted to "visualization, which while their web page shows a bit of an emphasis towards video/multimedia, they do to a lot of work on data presentation and control layout.
I can't find any web resources for it, but there's a neat display on somebody's research into CHI (computer-human interaction) where they visualized the execution of a program very well, and then tied the visualization to execution control, such that you could very easily set optimization/execution priorities.
I suppose none of this is really straight GUI research, but more of CHI research with graphical focus.
Maybe.
Napster, for example, can get themselves out of hot water if they win this round with that defense, even if the misuse ends at a later date, because of double jeopardy. If they haul your ass to court for copyright infringement while misuse is going on, and you win (for that reason or another), then they can't try to get you again for the same thing when they get the right to enforce their copyright back.
But if you copy now (while misuse occurs), but then they only try to enforce when they have the right to do so, then you don't really have a leg to stand on.
IANAL and all that, of course...
Encryption is useless for an application like this because at some level, we all need to hear the same pressure waves.
Ahh, but when they introduce their new DirectPlay format, and start piping the music straight to your brain, what are you gonna do then?
If you can do them separately, it is just like a 41 bit key.
40 bit key = 2^40 trial guesses.
Two 40 bit keys = 2 * 2^40 guesses = 2^41 guesses.
One 80 bit key = 2^80 guesses.
With an 80 bit key, you have to get the whole key right to see if you've gotten it. You may guess the first half right, but not know because you didn't guess the second half right.
Now, if you encrypt something with one 40-bit key, and then encrypt that whole thing again with another 40-bit key, THAT takes 80 bits of work. But encrypting two different chunks of data with two different keys creates only double the work (add one bit).
But only on the day before it started. Plus, the registration fee was more than a bit steep. I'm not going to drive from St. Louis to bust $99 on a conference, plus hotel/food, on one day's notice.
I think that this shows two very important things to anybody hosting a show in the future:
1) People are cheap.
2) They don't go if they don't know.
Maybe if we're lucky they'll put on another show in a year, and run it well. It's not that there is no support for Linux in the midwest, but that we (still) haven't had a good opportunity to show our support.
RDRAM goes (or at least was going) for $800 for a 128 MB stick.
Looks like they are just adding a L3 cache, and than putting ramdoubler into hardware.
Of course, compressing/decompressing data in hardware very quickly (nanoseconds) is a lot better than being forced to go to swap (microseconds to milliseconds). Still, modern processors tend to take very big performance hits whenever a little bit of lag is introduced. The people at IBM aren't idiots though, and I suppose that keeping the lag down is what the L3 cache is for.
But I have a right to open boxes in my possession.
MS sold me the box. I own the box (although I do not own the copyright to the software). I also own the media the software is on. The EULA is saying "By executing rights that you have regardless of this license, you agree to the license."
The GPL, on the other hand, says, "By executing rights that you do not have without agreeing to this licence, you agree to the license." If a person distributes GPLed software without agreeing to the GPL, then nothing has granted them the right to distribute. And by default under copyright law, this is illegal. So, if you 'violate' the GPL, you are guilty of one of two things:
1) You broke a contract (the GPL) which you agreed to. You are busted.
or
2) You broke copyright law by distributing/modifying copyrighted material without the permission of the copyright holder (you don't have permission since you didn't agree to the GPL). You are busted.
Also, (IANAL) if you break a contract, then the other side has the option of denying you all of you rights under the contract and nullifying the contract, after collecting damages resulting from the violation. So, if you do #1 (which could be hard to prove that you did somewhere agree to it), the FSF could screw you under contract law, and then have another go under copyright law.
The GPL is really quite well written. There are a few things that are a bit vague, but all of the important stuff is clearly spelt out, with all of the bases covered.
I don't think that a contract (NDA) can prevent you from running to law enforcement about something. I do know that a contract can't require you to break the law.
Also, if MS distributed GPLed code to you under an NDA, then, as the copyright still belongs to the original author (not Microsoft), and the GPL provisions for granting a GPL licence to anybody who gets the code, then you have a licence, by the copyright owner, to redistribed the GPLed portions. Straight to the FSF with a note explaining the source if you wish. Of course, you may or may not be allowed to distribute MS's illegal yet NDAed derivative work (their contributions), as it is questionable if that code would be GPLed.
Also, if any GPLed code copyrighted by the US government (say some research group that GPLed and released something), and somebody violated the GPL on that software, then there are federal whistleblower laws granting all sorts of special immunity to parties reporting this to the gov't. Of course, these don't apply to software owned by the FSF.
I don't know why I'm responding to this, but...
The good part of Linux is the Unixisms. Linux is probably the closest there is to a standards-compliant system around (much better than MS at least).
And, not to get everybody mad at me, but the Linux TCP/IP stack, while quite good, is not the best. BSD has the best TCP/IP stack out there, and it also happens to be the one that Microsoft uses (or at least used to).