The RFCs aren't going to tell you about robots.txt.
They won't tell you about many kinds of proxies, their purposes, their locations in the network, and their problems.
They won't tell you about cache implementations.
The won't tell you how real-world, current implementations differ from the RFCs.
They won't tell you how high-traffic web sites are implemented with load balancing, DNS hacks, and so on.
They won't tell you about the Web Cache Coordination Protocol (WCCP) or the Hyper Text Caching Protocol.
They won't tell you about Front Page server extensions and the Front Page RPC.
They won't tell you about commonly used web server log formats.
I could go on. But I suggest you read the bios of the authors to get some idea of the nature of the content of this book: all of them were employed by Inktomi at one point or anther, including the vice president of R&D at Inktomi, and they include graduates from MIT, UC Berkeley, UIUC, and other universities; some have PhDs. I think they are eminently qualified to write this book. And I think they provide a lot of insight into real-world issues and real-world implementations, not just of HTTP, but of the architecture of the WWW.
Yes, it is a very interesting legal situation. I guess it's not surprising they have hired the big guns like David Boies.
Presumably, timing is important. Caldera was originally a Linux company, not much different from Red Hat. But over the course of events, they negotiated to get ownership of the Unix IP. Now, I presume that if they act in a timely manner, they would be permitted by the courts to get their house in order with respect to IP issues. Therefore, they would be allowed to go ahead with lawsuits that seek to protect their Unix IP. But, if what they claim is true, then Linux is a mix of copyright and copyleft code. Obviously, copyright and copyleft are polar opposites. SCO cannot simply collect royalties from anyone using Linux, as that would be attempting to damage the copyleft of the GPL. I mean, it seems that in that case what we have is an IP no-man's land. SCO has no right to Linux, and the general public has no right to it. I can't see any alternative, then, to a painstaking process of separating copyright and copyleft code. (Okay, copyright is probably not the right term, because they are more likely to claim violation of trade secrets. But it's the same idea.)
So, what then of Caldera, the Linux company? Presumably, their license was similar to Red Hat's license, which disclaimed any indemnification for IP violations. In other words, Caldera was a service company, providing support contracts for Linux. So, maybe they would be free from lawsuits from their customers. However, they would be required to consider their customers as committing IP violations against the Unix IP. There is absolutely no way they could violate the GPL and grant any kind of waiver of royalties to customers who bought Caldera Linux.
In any case, we have to wonder what kind of due diligence the Caldera executives undertook before they acquired rights to the Unix IP. And does that due diligence, or lack thereof, affect their legal position. I mean, imagine if they knew that Linux contained violations of the Unix IP. If, at the same time, they were negotiating to acquire rights to the Unix IP, and they knew the requirements of the GPL on Linux, then they made a horrible business decision -- one that cannibalized their Linux business. I mean, what were they thinking?! That they would use the Unix IP to dominate the Linux market? That they didn't understand the GPL, which prohibits using IP to dominate copyleft software?
The way I feel right now, it's like that duck in the AFLAC commercial, which walks out of the barbershop shaking it's head and going "Aaaaahhh!"
Okay, maybe file system code? Maybe the journaling file system code from IBM? I'm just guessing here. We will have to find out when the case goes to court.
Is ext3 based on source code from IBM? I know there were several alternatives offered for a journaling file system. (SGI also made an offer of code, IIRC.)
One thing I hate about C++ is that you have so many C++ programmers who are preachy:
"Don't use malloc(). Always use new."
"Don't use stdio. Always use iostream."
"That code is not object-oriented." (And, of course, object-oriented is always the best. That's an axiom.)
"Don't use macros. Use inline functions."
"Don't use old-style casts. Use the new-style casts."
"Your code isn't very efficient." (C++ programmers seem to obsessed with efficiency.)
Back in the good old days of C, there was pretty much the one point of contention: "Don't use goto." C++ takes the never-ever-use-goto-no-sometimes-its-okay argument to a whole new level.
Of course, code reviews can get very personal. Everyone tries to be all object-orienteder-than-thou. Or maybe it's: "I use more C++ features than you." So then you find yourself wanting to use advanced C++ features so that you can impress your co-workers and be in that elite club, but your conscience tells you that if you do use all those advanced features, you will sacrifice portability, and you will produce code that requires a very advanced C++ programmer to maintain.
Then there are the compiler problems. As the parent post mentions, all compilers suck. And one of the biggest compiler problems is that the error messages are often inscrutable -- nobody knows what they mean! So, those error messages mean nothing except to tell you that your program won't compile. I mean, finding a bug in program code is one thing. Sometimes you can find the bug by stepping through code in the debugger. But when you can't even get the code to compile, that's frustrating in a different sort of way.
A co-worker of mine wrote a couple thousand lines of C++ code using GCC on Solaris. Later, we tried to compile the code using the Sun C++ compiler on the same machine. After a week of trying, we pretty much gave up. Such is the life of a C++ programmer.
The problem with spam is simple: the old rule that we should be forgiving about what we accept and strict about what we send.
We could wipe spam out, or at least render it controllable, if we simple required proper DNS entries (A, MX, PTR) and proper server configuration (HELO information, etc.)
Do you work for Microsoft?:-)
Seriously, at the FTC's spam forum last week (I was there), the representative from Microsoft was asked to discuss their talks with AOL and Yahoo about controlling the spam problem. (You remember the big splash they made about these companies agreeing to work together.) Anyway, the Microsoft Veep mentioned exactly this step as a first step. Also, these companies are likely to share information about subscriber sign-ups, in the hopes of preventing spammers from signing up for many accounts at a time, all for the purposes of sending spam. I'm not sure exactly how they would do this, but it is supposed to be like the way credit checks are done. I think they just check that a subscriber isn't using the same credit card number over and over again.
I was especially glad to hear that Microsoft favors incremental steps toward solving the problem, and verifying sending hosts with reverse DNS look-ups is just such an incremental step.
This is just a very large GIF. It's a single color, but is thousands of pixels on a side. In GIF form it compresses down to only a few kilobytes, but when your computer tries to uncompress it for display it balloons out to a whole bunch of megabytes. At the very least your system will take a long time to do the uncompression and display, during which time it will be unresponsive. Most likely your browser will run out of memory and fail to display the GIF, possibly exitting. Some people report that their computer actually reboots.
If your system is robust enough to actually display this text and not lock up, well, congratulations!
By the way, I had to write a custom program to produce a GIF this big. The standard GIF writers crapped out on sizes that could still be displayed.
My PC handles this page without a problem. It might cause problems on older PCs. Of course, you could always put more than one such GIF image on a page.
Didn't anyone read the article? There was no mention of an opt-in list or an opt-out list. There was the mention of a registry. There aren't a lot of details given, but we can make an educated guess as to what the ESPC has in mind.
First, here's the problem: spam filters block too much. Anyone who runs a mailing list knows how frustrating this can be. So, finally a group is stepping out with plans to find a solution to the problem.
And what is the solution? Create a registry that is a white list of responsible senders. Then the RBLs and other spam blockers can stop deleting legitimate messages from the authenticated senders on the white list (which they call the registry).
Look, I have no interest in getting regular updates from eBay or Amazon.com. But sometimes I like to get technical newletters from IBM, Sun, or other companies. And I want the filters to leave these messages alone -- stop deleting them.
So, in theory, I think this is a good idea. We would have to wait and see the details. Presumably it's easy to get kicked off the registry. But is it easy to get on it? Can a spammer get on the registry under one company name, get kicked off, then get back on under a new name? And do it several times a day? Will it be easy to spoof the mechanism that authenticates the entries in the registry? I don't see any real showstoppers.
This idea is not much different from a white list that you might use on your end system, except that this would be a white list that works for intermediate systems, like ISPs mail filters. It doesn't solve the spam problem. But it might just solve one part of the spam problem: collateral damage to innocent email.
One of the professors in the Department of Electrical Engineering at the University of Maryland put that question on an exam in a graduate course in information theory.
When I was at UM, the EE department had some of the most arrogant professors you can imagine. On many tests the high score was about 70, with the median score being in the 40s. (I attended the graduate school at UM.)
In case you were wondering, this is not a simple problem. The solution most definitely does not involve base 2 logarithms (even though superficial considerations from information theory might have you think that). And, yes, you are not told whether the different marble is heavier or lighter than the others. You have to figure that out by using the balance scale.
I disagree with much of your posting. I read almost the entire complaint filed by SCO, and I read the interview with the CEO.
First, the statements by Red Hat (maybe SUSE, too) are the statements prepared by lawyers that cover every possible situation that might have an impact on the value of an investment made in the company. You can be pretty sure there are also statements that "the company may never become profitable," and "key upper management could leave the company," and a whole host of other possibilities. The possibilities are limited only by the imagination of their lawyers. And the statements about IP probably fall into the category of boilerplate material. So, I don't put too much stock in Red Hat's statements about IP liability, even though McBride seems to. By mentioning Red Hat's statements about IP liability, I think he tips his hand a little. And, I definitely get the impression that SCO intends to eventually take on Red Hat, Suse, and any other company that they think they can collect royalties or damages from.
Second, while SCO may not be trying to destroy the Open Source community, there is no question that they feel threatened by Linux. This lawsuit is all about trying to fight that threat using whatever legal means they have. You can see this very clearly if you read the complaint. They mention in the complaint that IBM seeks to destroy the economic value of SCO's Unix IP. They mention that it cost over $1 billion to develop the Unix source code base. And, in the complaint, it's clear that they expect Linux to be the operating system for hobbyists, not servers used by businesses. So, while it may be true that they aren't trying to destroy the Open Source community, it is clear what they want: Run Linux at home where you do your hobby stuff. Or run it in your business and pay a royalty to SCO.
Third, you seem to think that/.ers are unjustified in their anger, at least until all the facts come out in the court proceedings. I will say that I am angry about the current situation, and I believe that with good reason. SCO's business model is failing, for legitimate reasons. Stay still too long, and you lose. The business environment changes. In this particular case, SCO apparently thinks the Unix IP that they own is a cash cow. I would argue that the Unix IP has run its course, and is now near the end of its economic lifetime. Unix was a very successful operating system, from an economic perspective. I'm sure the $1B spent in development has been returned many times over in revenue. But the software industry doesn't stand still. Linux has become a contender. Operating systems are becoming a commodity. Cash cow time is over. So, what offends me, is that SCO would try to stop all the clocks -- freeze time at, let's say, 1999. One thing is perfectly clear: SCO is not trying to compete fairly by introducing innovation or adapting their business model. It is trying to keep an outdated business model alive through litigation. And that disturbs me.
Perhaps you are referring to the "attitudes" of the person whose message you were responding to.
After reading the review (I have not read the book being reviewed), I think your concerns are unfounded. Or better yet, your concerns are the reverse of the concerns of the book's authors. As I understand it, from reading the review, the authors are concerned that those who understand cryptography from a theoretical point of view -- that is, the "academics" -- would be the ones to create ineffective cryptosystems. Your concern is that those who don't understand the theory would be the ones to create bad crypto systems. The goal of the book is to make implementors aware of issues that they wouldn't otherwise be aware of. Just an example: a core dump writes all of a process's memory image to a disk file, possibly exposing sensitive data such as private keys. How many academics, who know why AES is supposed to be secure, do you think understand about core dumps?
And that gets to the reason why I think your concerns are unfounded. As a protocol designer, I can take those academics at their word when they say that AES is considered secure. But as I design a protocol, there are many other things that I need to be aware of, like how a certificate can be spoofed, or how the million message attack can be used to guess the symmetric encryption key. The point of this book is to help protocol designers and implementors realize that the design and implementation of a secure protocol is serious business.
You don't really need something like sugarplum. Even if you can't run CGI scripts, you can embed email addresses on your web page. Make the mailto: URLs white text on a white background to hide them. That's just one idea. If you want more ideas on how to hide information in HTML text, just look at a few spam messages. You can learn a lot from the techniques spammers use. (White on white is one such technique. Spammers use it to add text in the hopes of fooling spam filters.)
It's really quite gratifying to know that you can turn spammers techniques back on them.
Obviously, Moore's Law will not hold for another 100 years. So, Paul's whole argument about wasting resources in order to make writing software easier might be an academic argument about programming languages 20, or maybe even 50, years from now. I certainly think that over the next 20 years, we will be getting used to the idea of wasting computing resources, and using the wasted resources very effectively. But then Moore's Law becomes invalid. Then what? Then, assuming that our craving for ever greater computing power continues, we start to go back the other direction. We start to try to get more done with fewer CPU cycles. So it would seem that the programming languages we use 100 years from now may not be as wasteful as Paul suggests.
I tend to think that Java is an evolutionary dead end, too, and I'll tell you why. It's too big. When I think of Java, I think of the language, plus the very large library. The library is away too big to "evolve." Therefore, when the next big thing in programming comes along, Java will not be able to adapt. This is probably more a matter of perception, I'll admit. But in the minds of many, Java will be tied to application servers, J2EE, etc. To me, that's starting to sound a lot more like COBOL. And even if it is just perceptions, perceptions can be hard to change when there's lots of hype out the Latest New Thing.
I recently saw a new kind of web bug in a spam email. It was a CSS style sheet that was retrieved from a CGI-like URL. I'm guessing that Mozilla doesn't even block this kind of web bug.
This is the lamest story I've ever heard on Slashdot. I almost left for good after reading this. If the next week's worth of news doesn't get any less lame, I probably will.
Slashdot, don't be fucking lame. This is news for *nerds*, not for simps and wannabees. XML too hard? Then you shouldn't be a programmer cause that's about as easy as it gets unless you're just a hobbyist.
Somehow, I think you don't understand what the story is about. Something can be easy, but for lazy programmers (and if you understand Larry Wall's Perl culture, then you know that laziness in a programmer is a virtue) it ought to be simpler so that we can enjoy our work more. There are some programming techniques that are just too repetitive, and doing them over and over and over can make a programmer go crazy, no matter how easy it is. Well, that's the way it is with XML. Sure, XML is as easy as it gets. But if you have write so much repetitive code, you look for ways to automate it all. A major point of Tim's complaint about XML is that apparently no one has done anything to make programming with XML less boring and repetitive.
Re:If they are reinventing SMTP, might as well...
on
IETF to Look at Spam
·
· Score: 1
I doubt that would happen. Base64 encoding is very efficient CPU-wise. But besides that point, base64-encoded content is very robust in an environment that is not friendly to binary content. The two big problems are (1) end-of-line characters and (2) NUL characters. As long as there is a difference between Windows and Unix systems, there will always be a problem with CR LF vs. LF. Make the conversion on an MP3 file, JPEG image, or what-have-you, and you corrupt the file. Allow message content to contain embedded NUL characters, and you break all kinds of text processing applications.
BTW, it's not just SMTP that has a problem with binary content. It's also POP3, IMAP4, and NNTP.
Yes, we should have an 8-bit clean email system. But 8-bit content is different from binary content. I can see everything eventually moving to 8-bit content, including unencoded UTF-8 text (which doesn't contain NUL characters). But base64 encoding for binary content will be with us for a long time to come, probably until Unix/Linux/C drops '\n' as the end-of-line sequence. And XML/SOAP may breath new life into base64 encoding.
Many spammers send just an image in an HTML email. In many cases the image is stored on a web server somewhere. Therefore, just a small message is sent, and the spammer pays for the cost of the web server that serves the image.
If we move to an IM2000-type mail system -- where the sender pays for the storage -- then that situation is not much different from the current situation where a spammer sends a link to an image. The difference is, that currently spammers use the technique to make it more difficult for spam filters to stop them. In an IM2000 mail system, spammers would have no choice.
If you use the default spam filter in Outlook, then of course it's not going to be effective. In Sending Spam 101 they teach would-be spammers to run their message through Outlook to make sure it gets past the default filter.
I know I'm a little sleepy today, but this article seems to just ramble on, with many "details" that are completely irrelevant to the theme of the article.
Is there no editor for that web site? It seems like the editing process should have cut that article down to one page.
No, I don't think that consumer electronics manufacturers will sell products that will only play music produced by big companies. So, your points don't apply. Unprotected MP3s will always play.
IIRC, the way SDMI was supposed to work was to have a robust watermark and a fragile watermark. If the robust watermark is present, then the fragile watermark must also be present, or the audio content will not play. The robust watermark is supposed to be very hard to remove -- for example, it is preserved if you hold a microphone to your speakers and record a pure analog signal.
So, a garage band could just create music files that don't have the robust watermark, and it will play on portable music players.
Wherever "open computing" survives will become the dominant cultural force of the next century.
We don't have enough information to know what Microsoft meant when they mentioned the end of open computing.
However, if you think about it just for a minute, you can figure it out. Here's a big hint: trusted computing.
I think they are just referring to the fact that the age of innocence is over. And, if that's what they are talking about, then they are absolutely right. Think about spam as just one example of the age of innocence being over.
Remember the age of innocence, when Usenet was actually useful and SMTP servers allowed relaying by default? Remember when you could put your real email address in your Usenet postings? Or when you could put it on a web page? Remember when a bunch of Netscape's employees had personal web pages sponsored by Netscape?
In short, think of "the end of open computing" to mean the "the end of open SMTP relays".
If I am right about this, then your point about "cultural hegemony over the whole world" is moot.
Talk to any sys admin who has been in the business for 15 years or more if they understand the "end of open computing".
Good point about a tragedy of the commons. The Internet was build with an idea of some degree of cooperation among the parties involved. So far, at least at the backbone service providers, it has worked out pretty well. But there are problems at the edge of the network -- specifically with cable modem access. I have a cable modem and don't see any problems with bandwidth hogs. I suppose if I started seeing bandwidth hogs, I would not be very happy. (I don't use any p2p applications.)
However... I don't think blocking ports is a good way to handle the situation. If it is just a small number of subscribers who are consuming too much bandwidth, then it seems like those subscribers could be dealt with on an individual basis. They should be sent a notice that because of the excessive bandwidth they use, that they will be charged a premium over and above their current subscription rate. Really, the solution to the file sharing systems like KaZaa is to make those who run the servers to pay for their use of bandwidth.
Now, I must say, I have a big problem with ISPs blocking ports. Why? Well, just imagine what it would be like if telephone companies started controlling what kind of communications could pass over the phone lines. When online services, including Internet access, started becoming popular, the telcos had real problems with the change in usage. Whereas calls used to average less than three minutes, they found that those who used online services were making calls that lasted much longer. It seems like they had every financial incentive to restrict modem calls. If they had, then it is doubtful that the Internet revolution of the 1990s would have ever happened.
The US came into its current position of power through historical accident.
No, you must give some credit to our founders and one of our greatest presidents, Abraham Lincoln. Certainly, the Civil War was a significant event in US history, and it would have been easy for Lincoln to capitulate on the issue of secession. If the result of that war had gone the other way, the U.S. may have found itself in the position of Europe, i.e. not united. The same is true for George Washington, who was the only man who could have made the 13 colonies into a nation. Sometimes I think we need to put credit where credit is due. At key times in our history there were leaders of great integrity who served to make our nation better.
Slashdot Mirror
The RFCs aren't going to tell you about robots.txt.
They won't tell you about many kinds of proxies, their purposes, their locations in the network, and their problems.
They won't tell you about cache implementations.
The won't tell you how real-world, current implementations differ from the RFCs.
They won't tell you how high-traffic web sites are implemented with load balancing, DNS hacks, and so on.
They won't tell you about the Web Cache Coordination Protocol (WCCP) or the Hyper Text Caching Protocol.
They won't tell you about Front Page server extensions and the Front Page RPC.
They won't tell you about commonly used web server log formats.
I could go on. But I suggest you read the bios of the authors to get some idea of the nature of the content of this book: all of them were employed by Inktomi at one point or anther, including the vice president of R&D at Inktomi, and they include graduates from MIT, UC Berkeley, UIUC, and other universities; some have PhDs. I think they are eminently qualified to write this book. And I think they provide a lot of insight into real-world issues and real-world implementations, not just of HTTP, but of the architecture of the WWW.
Presumably, timing is important. Caldera was originally a Linux company, not much different from Red Hat. But over the course of events, they negotiated to get ownership of the Unix IP. Now, I presume that if they act in a timely manner, they would be permitted by the courts to get their house in order with respect to IP issues. Therefore, they would be allowed to go ahead with lawsuits that seek to protect their Unix IP. But, if what they claim is true, then Linux is a mix of copyright and copyleft code. Obviously, copyright and copyleft are polar opposites. SCO cannot simply collect royalties from anyone using Linux, as that would be attempting to damage the copyleft of the GPL. I mean, it seems that in that case what we have is an IP no-man's land. SCO has no right to Linux, and the general public has no right to it. I can't see any alternative, then, to a painstaking process of separating copyright and copyleft code. (Okay, copyright is probably not the right term, because they are more likely to claim violation of trade secrets. But it's the same idea.)
So, what then of Caldera, the Linux company? Presumably, their license was similar to Red Hat's license, which disclaimed any indemnification for IP violations. In other words, Caldera was a service company, providing support contracts for Linux. So, maybe they would be free from lawsuits from their customers. However, they would be required to consider their customers as committing IP violations against the Unix IP. There is absolutely no way they could violate the GPL and grant any kind of waiver of royalties to customers who bought Caldera Linux.
In any case, we have to wonder what kind of due diligence the Caldera executives undertook before they acquired rights to the Unix IP. And does that due diligence, or lack thereof, affect their legal position. I mean, imagine if they knew that Linux contained violations of the Unix IP. If, at the same time, they were negotiating to acquire rights to the Unix IP, and they knew the requirements of the GPL on Linux, then they made a horrible business decision -- one that cannibalized their Linux business. I mean, what were they thinking?! That they would use the Unix IP to dominate the Linux market? That they didn't understand the GPL, which prohibits using IP to dominate copyleft software?
The way I feel right now, it's like that duck in the AFLAC commercial, which walks out of the barbershop shaking it's head and going "Aaaaahhh!"
Okay, maybe file system code? Maybe the journaling file system code from IBM? I'm just guessing here. We will have to find out when the case goes to court.
Is ext3 based on source code from IBM? I know there were several alternatives offered for a journaling file system. (SGI also made an offer of code, IIRC.)
Back in the good old days of C, there was pretty much the one point of contention: "Don't use goto." C++ takes the never-ever-use-goto-no-sometimes-its-okay argument to a whole new level.
Of course, code reviews can get very personal. Everyone tries to be all object-orienteder-than-thou. Or maybe it's: "I use more C++ features than you." So then you find yourself wanting to use advanced C++ features so that you can impress your co-workers and be in that elite club, but your conscience tells you that if you do use all those advanced features, you will sacrifice portability, and you will produce code that requires a very advanced C++ programmer to maintain.
Then there are the compiler problems. As the parent post mentions, all compilers suck. And one of the biggest compiler problems is that the error messages are often inscrutable -- nobody knows what they mean! So, those error messages mean nothing except to tell you that your program won't compile. I mean, finding a bug in program code is one thing. Sometimes you can find the bug by stepping through code in the debugger. But when you can't even get the code to compile, that's frustrating in a different sort of way.
A co-worker of mine wrote a couple thousand lines of C++ code using GCC on Solaris. Later, we tried to compile the code using the Sun C++ compiler on the same machine. After a week of trying, we pretty much gave up. Such is the life of a C++ programmer.
Do you work for Microsoft? :-)
Seriously, at the FTC's spam forum last week (I was there), the representative from Microsoft was asked to discuss their talks with AOL and Yahoo about controlling the spam problem. (You remember the big splash they made about these companies agreeing to work together.) Anyway, the Microsoft Veep mentioned exactly this step as a first step. Also, these companies are likely to share information about subscriber sign-ups, in the hopes of preventing spammers from signing up for many accounts at a time, all for the purposes of sending spam. I'm not sure exactly how they would do this, but it is supposed to be like the way credit checks are done. I think they just check that a subscriber isn't using the same credit card number over and over again.
I was especially glad to hear that Microsoft favors incremental steps toward solving the problem, and verifying sending hosts with reverse DNS look-ups is just such an incremental step.
My PC handles this page without a problem. It might cause problems on older PCs. Of course, you could always put more than one such GIF image on a page.
First, here's the problem: spam filters block too much. Anyone who runs a mailing list knows how frustrating this can be. So, finally a group is stepping out with plans to find a solution to the problem.
And what is the solution? Create a registry that is a white list of responsible senders. Then the RBLs and other spam blockers can stop deleting legitimate messages from the authenticated senders on the white list (which they call the registry).
Look, I have no interest in getting regular updates from eBay or Amazon.com. But sometimes I like to get technical newletters from IBM, Sun, or other companies. And I want the filters to leave these messages alone -- stop deleting them.
So, in theory, I think this is a good idea. We would have to wait and see the details. Presumably it's easy to get kicked off the registry. But is it easy to get on it? Can a spammer get on the registry under one company name, get kicked off, then get back on under a new name? And do it several times a day? Will it be easy to spoof the mechanism that authenticates the entries in the registry? I don't see any real showstoppers.
This idea is not much different from a white list that you might use on your end system, except that this would be a white list that works for intermediate systems, like ISPs mail filters. It doesn't solve the spam problem. But it might just solve one part of the spam problem: collateral damage to innocent email.
One of the professors in the Department of Electrical Engineering at the University of Maryland put that question on an exam in a graduate course in information theory.
When I was at UM, the EE department had some of the most arrogant professors you can imagine. On many tests the high score was about 70, with the median score being in the 40s. (I attended the graduate school at UM.)
In case you were wondering, this is not a simple problem. The solution most definitely does not involve base 2 logarithms (even though superficial considerations from information theory might have you think that). And, yes, you are not told whether the different marble is heavier or lighter than the others. You have to figure that out by using the balance scale.
First, the statements by Red Hat (maybe SUSE, too) are the statements prepared by lawyers that cover every possible situation that might have an impact on the value of an investment made in the company. You can be pretty sure there are also statements that "the company may never become profitable," and "key upper management could leave the company," and a whole host of other possibilities. The possibilities are limited only by the imagination of their lawyers. And the statements about IP probably fall into the category of boilerplate material. So, I don't put too much stock in Red Hat's statements about IP liability, even though McBride seems to. By mentioning Red Hat's statements about IP liability, I think he tips his hand a little. And, I definitely get the impression that SCO intends to eventually take on Red Hat, Suse, and any other company that they think they can collect royalties or damages from.
Second, while SCO may not be trying to destroy the Open Source community, there is no question that they feel threatened by Linux. This lawsuit is all about trying to fight that threat using whatever legal means they have. You can see this very clearly if you read the complaint. They mention in the complaint that IBM seeks to destroy the economic value of SCO's Unix IP. They mention that it cost over $1 billion to develop the Unix source code base. And, in the complaint, it's clear that they expect Linux to be the operating system for hobbyists, not servers used by businesses. So, while it may be true that they aren't trying to destroy the Open Source community, it is clear what they want: Run Linux at home where you do your hobby stuff. Or run it in your business and pay a royalty to SCO.
Third, you seem to think that /.ers are unjustified in their anger, at least until all the facts come out in the court proceedings. I will say that I am angry about the current situation, and I believe that with good reason. SCO's business model is failing, for legitimate reasons. Stay still too long, and you lose. The business environment changes. In this particular case, SCO apparently thinks the Unix IP that they own is a cash cow. I would argue that the Unix IP has run its course, and is now near the end of its economic lifetime. Unix was a very successful operating system, from an economic perspective. I'm sure the $1B spent in development has been returned many times over in revenue. But the software industry doesn't stand still. Linux has become a contender. Operating systems are becoming a commodity. Cash cow time is over. So, what offends me, is that SCO would try to stop all the clocks -- freeze time at, let's say, 1999. One thing is perfectly clear: SCO is not trying to compete fairly by introducing innovation or adapting their business model. It is trying to keep an outdated business model alive through litigation. And that disturbs me.
After reading the review (I have not read the book being reviewed), I think your concerns are unfounded. Or better yet, your concerns are the reverse of the concerns of the book's authors. As I understand it, from reading the review, the authors are concerned that those who understand cryptography from a theoretical point of view -- that is, the "academics" -- would be the ones to create ineffective cryptosystems. Your concern is that those who don't understand the theory would be the ones to create bad crypto systems. The goal of the book is to make implementors aware of issues that they wouldn't otherwise be aware of. Just an example: a core dump writes all of a process's memory image to a disk file, possibly exposing sensitive data such as private keys. How many academics, who know why AES is supposed to be secure, do you think understand about core dumps?
And that gets to the reason why I think your concerns are unfounded. As a protocol designer, I can take those academics at their word when they say that AES is considered secure. But as I design a protocol, there are many other things that I need to be aware of, like how a certificate can be spoofed, or how the million message attack can be used to guess the symmetric encryption key. The point of this book is to help protocol designers and implementors realize that the design and implementation of a secure protocol is serious business.
It's really quite gratifying to know that you can turn spammers techniques back on them.
Obviously, Moore's Law will not hold for another 100 years. So, Paul's whole argument about wasting resources in order to make writing software easier might be an academic argument about programming languages 20, or maybe even 50, years from now. I certainly think that over the next 20 years, we will be getting used to the idea of wasting computing resources, and using the wasted resources very effectively. But then Moore's Law becomes invalid. Then what? Then, assuming that our craving for ever greater computing power continues, we start to go back the other direction. We start to try to get more done with fewer CPU cycles. So it would seem that the programming languages we use 100 years from now may not be as wasteful as Paul suggests.
I tend to think that Java is an evolutionary dead end, too, and I'll tell you why. It's too big. When I think of Java, I think of the language, plus the very large library. The library is away too big to "evolve." Therefore, when the next big thing in programming comes along, Java will not be able to adapt. This is probably more a matter of perception, I'll admit. But in the minds of many, Java will be tied to application servers, J2EE, etc. To me, that's starting to sound a lot more like COBOL. And even if it is just perceptions, perceptions can be hard to change when there's lots of hype out the Latest New Thing.
j,o,e,@,a,o,l,.,c,o,m
<table><tr>
<td>j</td><td>o</td> <td>e</td><td>@</td> <td>a</td><td>o</td> <td>l</td><td>.</td> <td>c</td><td>o</td> <td>m</td>
</tr></table>
jo<!-- jabiuaiwoiuvklakj -->e@<!-- j89euB -->ao<!-- 88ba0s9 -->l.co<!-- a9aBVU9d0 -->m
Need more ideas? You'll get a lot more ideas from the spam emails in you get every day.
I recently saw a new kind of web bug in a spam email. It was a CSS style sheet that was retrieved from a CGI-like URL. I'm guessing that Mozilla doesn't even block this kind of web bug.
Slashdot, don't be fucking lame. This is news for *nerds*, not for simps and wannabees. XML too hard? Then you shouldn't be a programmer cause that's about as easy as it gets unless you're just a hobbyist.
Somehow, I think you don't understand what the story is about. Something can be easy, but for lazy programmers (and if you understand Larry Wall's Perl culture, then you know that laziness in a programmer is a virtue) it ought to be simpler so that we can enjoy our work more. There are some programming techniques that are just too repetitive, and doing them over and over and over can make a programmer go crazy, no matter how easy it is. Well, that's the way it is with XML. Sure, XML is as easy as it gets. But if you have write so much repetitive code, you look for ways to automate it all. A major point of Tim's complaint about XML is that apparently no one has done anything to make programming with XML less boring and repetitive.
BTW, it's not just SMTP that has a problem with binary content. It's also POP3, IMAP4, and NNTP.
Yes, we should have an 8-bit clean email system. But 8-bit content is different from binary content. I can see everything eventually moving to 8-bit content, including unencoded UTF-8 text (which doesn't contain NUL characters). But base64 encoding for binary content will be with us for a long time to come, probably until Unix/Linux/C drops '\n' as the end-of-line sequence. And XML/SOAP may breath new life into base64 encoding.
If we move to an IM2000-type mail system -- where the sender pays for the storage -- then that situation is not much different from the current situation where a spammer sends a link to an image. The difference is, that currently spammers use the technique to make it more difficult for spam filters to stop them. In an IM2000 mail system, spammers would have no choice.
If you use the default spam filter in Outlook, then of course it's not going to be effective. In Sending Spam 101 they teach would-be spammers to run their message through Outlook to make sure it gets past the default filter.
Is there no editor for that web site? It seems like the editing process should have cut that article down to one page.
IIRC, the way SDMI was supposed to work was to have a robust watermark and a fragile watermark. If the robust watermark is present, then the fragile watermark must also be present, or the audio content will not play. The robust watermark is supposed to be very hard to remove -- for example, it is preserved if you hold a microphone to your speakers and record a pure analog signal.
So, a garage band could just create music files that don't have the robust watermark, and it will play on portable music players.
We don't have enough information to know what Microsoft meant when they mentioned the end of open computing.
However, if you think about it just for a minute, you can figure it out. Here's a big hint: trusted computing.
I think they are just referring to the fact that the age of innocence is over. And, if that's what they are talking about, then they are absolutely right. Think about spam as just one example of the age of innocence being over.
Remember the age of innocence, when Usenet was actually useful and SMTP servers allowed relaying by default? Remember when you could put your real email address in your Usenet postings? Or when you could put it on a web page? Remember when a bunch of Netscape's employees had personal web pages sponsored by Netscape?
In short, think of "the end of open computing" to mean the "the end of open SMTP relays".
If I am right about this, then your point about "cultural hegemony over the whole world" is moot.
Talk to any sys admin who has been in the business for 15 years or more if they understand the "end of open computing".
Seriously, AOL is known to have problems with Windows XP.
However... I don't think blocking ports is a good way to handle the situation. If it is just a small number of subscribers who are consuming too much bandwidth, then it seems like those subscribers could be dealt with on an individual basis. They should be sent a notice that because of the excessive bandwidth they use, that they will be charged a premium over and above their current subscription rate. Really, the solution to the file sharing systems like KaZaa is to make those who run the servers to pay for their use of bandwidth.
Now, I must say, I have a big problem with ISPs blocking ports. Why? Well, just imagine what it would be like if telephone companies started controlling what kind of communications could pass over the phone lines. When online services, including Internet access, started becoming popular, the telcos had real problems with the change in usage. Whereas calls used to average less than three minutes, they found that those who used online services were making calls that lasted much longer. It seems like they had every financial incentive to restrict modem calls. If they had, then it is doubtful that the Internet revolution of the 1990s would have ever happened.
No, you must give some credit to our founders and one of our greatest presidents, Abraham Lincoln. Certainly, the Civil War was a significant event in US history, and it would have been easy for Lincoln to capitulate on the issue of secession. If the result of that war had gone the other way, the U.S. may have found itself in the position of Europe, i.e. not united. The same is true for George Washington, who was the only man who could have made the 13 colonies into a nation. Sometimes I think we need to put credit where credit is due. At key times in our history there were leaders of great integrity who served to make our nation better.