In my view, patents provide a valuable service in our society, protecting people who create value from those who would steal it.
No, in your view, patents provide a way to make money. If you were really interested in protecting those who create value, you'd be focusing your efforts elsewhere. No value was created by the filing of the patents that you are now trying to "enforce". The real value was created by the architects of HTTP, SSL and HTML, as well as the multitudes of programmers and web designers who actually put in the work to make the World Wide Web what it is today. What did your client contribute to this edifice? Nothing, and you know it - if not now, then soon, when you're sued into oblivion. Live by the sword, die by the sword. Perhaps you should take up something easier, like selling Amway products?
I can't imagine this technique ultimately being implemented using only a single nanopore through which all 23 chromosomes have to be squeezed, one after the other. My guess is that a relatively large collection of nanopores would operate in parallel, as you suggested, on chromosome fragments, and the data collected would still have to be assembled into a complete genome sequence. Not unlike the shotgun sequencing technique, as someone else pointed out. With shotgun sequencing, the genome is blasted into fragments (one way of blasting it apart is to sonicate a solution of DNA, which gives a distribution of fragment sizes up to a couple of kilobases IIRC), and the fragments are sequenced by sequencing machines. The sequenced fragments are reassembled into a complete genomic sequence by a computer program which exploits redundancy in the fragments (many fragments overlap, as the original sonicated solution of DNA contains a large number of copies of the strand being sequenced). The sequence obtained from running this program is thus a "best guess", with some (hopefully small) probability of error. A good reassembly algorithm would exploit every possible aspect of the distribution of fragment sizes; e.g. certain shotgun techniques create a bimodal fragment size distribution, and the bigger fragments are "stitched together" using the smaller ones where necessary.
Anyway, I see two issues. One, what size DNA strand can be sequenced using a nanopore without breaking? Two, how many nanopores can be made to operate simultaneously? With 100 nanopores operating in parallel on 10-kilobase DNA fragments at 10 seconds per nanopore per fragment, you're getting 10 kilobases per second, or a billion bases every three hours. At these speeds, the real limiting factor is probably going to be something other than raw sequencing speed. I think it's a very exciting technology.
Oh hey, thanks. I forgot about > et al. I wasn't trying to be rude. I wanted to give an example of "I am a dick" programming style, which you can do really well in Perl. If I ever ran across code like this in a professional setting, I would laugh my ass off, then go yell at the author. Anyway, my real point is that if you can solve that problem in so little space in Perl, that's kind of interesting. To me, at least.
Perl can definitely look strange, but you learn over time just how much is possible with the top row of your keyboard, and in how little space it can be done. If you want an example of *readable* Perl code, check http://daveb.net/Code/Perl/phonecode.html. It's not as difficult as it seems. Eventually, you will cackle with glee while you hold down the shift key and bang away at that top row: @#$(&^@)#$&%_. Learn Perl. Love Perl. Be Perl. Then go on and learn something else.
I claim that the end result of your work is something which could have been done in Perl with an equivalent amount of effort by programmers as proficient in that language as you are in Lisp. The design would have been totally different, of course, but it would do the same thing. To me it sounds like you're saying, "I had to do it this way in Lisp, and there was no other way to do it in a different language which would not have been excessively difficult to implement.". Do you realize how sweeping of a claim that is? Is your expertise in Perl sufficient to allow you to make that claim?
Hell if I'm going to criticize Lisp, I think it's a really nice language. My point is that a programming language is only useful to *most* people inasmuch as it permits them to solve a problem with a minimum of hassle. Lisp programmers seem to view the language as an end in itself, perhaps because of the self-selecting nature of that group - I would argue that a disproportionate fraction of serious Lisp programmers are more interested in problems for which Lisp is the most natural fit.
My point is that there are entire classes of problems for which other languages are best suited - not always because of the innate superiority of the language in one respect or another. Fortran, LAPACK, yes. It is the best choice for complex and time consuming numerical computation. I mentioned CPAN because it is a mind-bogglingly extensive resource for programmers who don't wish to reinvent the wheel. You may sniff at Perl for various reasons, and that is fine, but the bottom line is because of its module system and the extensive community which has contributed to that system, there is an enormous variety of problems which I can solve in Perl much faster than you can solve in Lisp. That is Perl's strong point, and it makes Perl a much better choice than Lisp in those situations.
You seem to interpret my remarks as criticisms of Lisp, the language. They are not. There has to be a language with such naked clarity, and Lisp's unique features exist because of that clarity. I respect that. But that doesn't mean I'm going to use Lisp if someone tells me I have to design an algorithm to compute three dimensional wind fields from radar data at regular, closely spaced intervals. It doesn't mean I'll use Lisp to parse an XML document when ten lines of Perl will do the trick. And it doesn't mean I'd use Lisp to implement a web server which has to support 10,000 concurrent clients on a system with limited resources. There are many situations one encounters in the real world where the best tool for the job is not Lisp. So what?
First, don't ever say things like, "For most problems". As soon as you say that you betray your inexperience. Second, wipe that semen off of your copy of SICP and go look at CPAN for a while, or browse the man pages for LAPACK, or download the source code to the FreeBSD kernel. Third, wait until you've developed a 20,000 line application from scratch in at least three languages before talking smack about one over the others. When you get to that point, you'll understand what you think you understand right now.
I gather from your comments that you are a rabid fan of Lisp. Good for you. Nevertheless, you've missed my point. My point is that for fast, efficient development of an application like the Yahoo store builder, you sure as hell don't need a language which permits the definition of new syntactic forms. For God's sake man, come back down to earth! Most web programming is child's play, and the main problem is not the insufficient capabilities of the languages used, it's the pathetic incompetence of the average web developer, especially in the early phases of application development, which matter the most. Software of any significance must be designed before it is written, and most web developers simply do not have experience with this. Unfortunately, that is the *real* reason why web applications are so frequently mangled beyond the point of maintainability as they evolve in capability over time - the accumulation of hacks and partial rewrites eventually turns the thing into an unintelligible mess which nobody can decipher save for the one or two poor souls who are unfortunate enough to have been there almost since the beginning, and they probably think that their ability to understand the pile of garbage makes them programming gurus. I also claim that this is the *real* reason Graham et al were able to move faster than their competition - better design, not a better language. Look, Lisp is a great programming language and I'm really happy for you that you love it so much, but you have got to understand that the difference between a master of a language working in his element and the typical programmer far, far outweighs the differences between the various programming languages used in web development. Didn't you ever read "The Mythical Man-Month"?
This function is hardly likely to blow out the stack, as it does not even compile. Perhaps you meant:
unsigned long factorial ( unsigned long x )
{
return (x>2)?x*factorial(x-1):2;
}
Besides, on a 32 bit machine the unsigned long will overflow when x > 13. You won't get a stack overflow until hundreds of thousands of levels of recursion for a function this simple. By that time, the result will be over 1 million digits long and would require a 5 million bit wide unsigned long data type. I don't see that happening anytime soon.
There's nothing wrong with having a favorite programming language, but why do people so often have to claim that their personal favorite is objectively superior to all other languages? Does it ever occur to these people that a large part of the reason they feel this way may have something to do with the fact that they USE this language more than the others, and are hence more competent at programming it than they are at the others (or vice versa)? And that this fact inevitably makes it impossible for them to have an unbiased view of the programming language landscape?
That prejudice alone is perhaps forgivable, but the logic used to support the claim - in particular, the reference to their use of Lisp macros - is laughable. Paraphrasing: "We used macros for 20-25% of our code, and Lisp macros are hard to write and can do things you can't easily do in other languages. ERGO, 20-25% of our application did things other languages can't do and was thus beyond the capability of our competitors to implement.". "I encourage you to follow that thread", the author exhorts. Sure, I'll follow that thread. I'll follow that thread right to where it ends in a frayed, tattered mess at the foot of a giant billboard that says, "Hey guess what? It's an online store builder, and that ain't rocket science. Calm down and save the Aikido speech for the choir, because they'll listen and nobody else will.". The real reason these guys did well is simply that they were good, fast programmers and their competitors were not. It has nothing to do with Lisp. Had they been faced with a team of Perl hackers of equivalent skill to their Lisp mastery, things would have been more interesting.
The average programmer is a disorganized egomaniac
on
"Extreme" Programming
·
· Score: 1
And I would guess that the main benefit of Extreme Programming is that it helps correct these tendencies. I think almost anything would be better than just letting individual programmers go off on their own and try and "get the job done". What ends up happening is:
Not enough time is spent designing. The result is a messy piece of crap which has been partially rewritten many times in a haphazard way which renders the code utterly incomprehensible to anyone but the author.
Not enough time is spent redesigning. Sometimes the requirements change in mid-project for reasons beyond the programmer's control, and part or all of the project has to be redone. This is one of the many ways that superfluous code which has NO PURPOSE ends up lying around in a completed project. Removing superfluous code can be a thankless task, and the average programmer doesn't see the point. The average programmer just wants to crank out code, and then brag about how good a programmer (s)he is. With nobody around to ask "why is this piece of code there, what does it do?", there's really not much incentive to clean anything up.
Code is poorly documented. A solo author rarely needs to put comments in code to understand what it does, because (s)he wrote it in the first place. Nobody's asking, either - people just want to know if the project is finished. The end result? 4,000 lines of code and 6 lines of comments. Six months later, not a single person will understand how the hell it works.
Programmers become egomaniacs. They crank out code all day, then go to Slashdot and follow all the links to those gooey stories about how great programmers are and how in demand they are and how the good ones are really hard to find. They figure they must be one of the good ones. They start to get cocky and maybe even post on Slashdot saying how great and smart they are, how they're such good coders, how they're light years better than everyone around them. The end result? Someone who writes crappy code, but thinks (s)he's a badass hacker straight out of the "Code Rush" Netscape documentary or something. It happens all the time. This would be harmless except for the fact that it makes these coders unwilling to accept criticism from coworkers, because they feel that they are without peer in the organization, and hence that their work should be beyond reproach.
I'm amazed every time I read someone posting on Slashdot about what an awesome coder they are. To me, this invariably means the poster is insecure and needs to brag on Slashdot to shore up his ego. The best programmers I've met never brag about themselves. Their work speaks for itself. It is clean and elegant. It's not full of 800 line functions with no comments. It's modularized in a way which makes sense, and is documented thoroughly - to the tune of one line of comments per 2 or 3 lines of code. And it's formatted in an aesthetically pleasing manner which makes it easier to read and understand. The braggarts, on the other hand, usually come on strong in the beginning so they can make a big impression on you (and at first this works pretty well), then gradually you learn that they're full of shit.
Extreme Programming might help reduce the jackass ratio, and I think that's a good thing. The exact methodology isn't so important; what matters is that programmers are being taught to work together and create software someone else can develop and maintain. Yes, there are lone wolf badasses out there who can put us all to shame. But you're probably not one of them - and if you're one of those people who brags on Slashdot about how great you are, then you're definitely not one of them.
I have had DSL through PacBell for most of the past year. By sheer luck, when I moved to San Francisco I picked a location which happened to be about 2 blocks from a phone office. When the guy came by to check my line for my maximum download rate, he said "8.3 Megabits per second". Pacbell doesn't let you get away with that kind of speed but they do give you 6 Mb/s if you pay some extra. So naturally I paid extra. It's worth it sometimes, although not as often as you might think. Not long ago I downloaded a 288 MB file (Oracle 8i for Linux) in about 3.5 minutes. That was cool, but most of the time my download speed is limited by the other end of the pipe.
A friend of mine who works in the ADSL group at Texas Instruments told me that the falloff in bandwidth with distance from the phone office is actually pretty negligible until you get to about 2 km. After that you start losing bandwidth due to signal attenuation (AC conductivity of copper goes as 1/f^2 where f is the frequency of the alternating current, and ADSL uses frequencies up to at least 1 MHz IIRC). The point is, if you live within a mile of the phone office, life is great. If you live within 3 miles, life is tolerable. If you live farther away than that, then you should move or figure out some other broadband solution.
I noticed that the study did not mention anything about the connection speed of the various peers. I wonder if those with narrowband (i.e. dialup) access might be less likely to share files than those with broadband access.
After all, one has to wonder: would Napster have gained so much popularity were it not for the high-speed connections enjoyed by many college students these days? Without so much broadband in universities, who would want their uplink saturated by strangers? On the other hand, when you have a T1 in your dorm room, you might not even notice a few people grabbing files from you at any given time.
So, I would be interested to see how much of a correlation there is between one's willingness to share files and one's bandwidth to do so.
This is an exciting technology, but there are some unfortunate tradeoffs which have to be made when trying to achieve ultra-broadband wireless in not-so-thin air.
Bit rate is proportional to bandwidth times the logarithm of the signal-to-noise ratio. To maximize bandwidth, you go up to higher and higher transmission frequencies. To maximize signal to noise ratio, you step up the transmission power. But in a wireless laser network, both of these steps have their disadvantages.
The first problem is essentially that the higher frequencies (e.g. infrared, which is on the order of microns, as opposed to microwave, which is on the order of centimeters) are more susceptible to various scattering phenomena. The most frequently mentioned is, of course, fog, dust, smog, etc. These scatterers are far to small to have any significant effect on, for example, cellular communications (transmitted signal has a wavelength of tens of centimeters, not microns), but they are excellent scatterers in smaller wavelengths. In addition, the atmosphere itself scatters visible light more and more effectively as you go to higher and higher frequencies, reaching a maximum somewhere in the ultraviolet. This is due to the electronic properties of diatomic nitrogen and oxygen and cannot be avoided. (As a side note, it is also why the sky is blue and sunsets are red). So, one cannot step around the fog problem by going to even higher frequencies. I believe, but am not certain, that fiberless lasers still operate in the IR.
The second problem, of course, is that stepping up the power output of the transmitter is expensive. A tenfold increase in bandwidth requires a thousandfold increase in signal to noise ratio. To see why this is so, imagine that with a given signal to noise ratio, you can resolve 16 signal strengths with a bit error rate of less than, say, 10^-8. This means that you can transmit 4 bits of information per symbol. To get twice as many bits per symbol, or double the bit rate, you need to be able to resolve 256 signal strengths - i.e. square your signal to noise ratio. To get 12 (three times as many) bits per symbol, you need to cube your S/N, and so on. Essentially, you have to double your S/N for each additional bit per symbol you wish to be able to resolve at a certain bit error rate. Hence the need for enormously increased power to achieve relatively modest increases in bandwidth.
So, with these constraints in mind, it will be interesting to see what optimum is achieved by TeraBeam et al, and how resilient their systems turn out to be.
Dave Bailey
Re:Please, no more articles about benchmarks
on
Java Rocks On Linux
·
· Score: 1
Yes, it is interpreted. The JVM is an interpreter. Your confusion probably results from the fact that Java code is said to be "compiled" (e.g. javac foo.java => foo.class). But the Java "compiler" is not a compiler in the same sense as a C, C++, or Fortran compiler. The Java "compiler" simply takes the text file you give it and outputs a binary file which is then *interpreted* by the JVM.
This is why they call it a "virtual machine". The JVM is the "target architecture" for "compiled" Java code. It has its own binary-coded instruction set, and Java "compilers" simply produce output for that instruction set. The JVM takes instructions for its "architecture" and *interprets* them to the native architecture (e.g. Intel/x86, Sun/Sparc, etc). It does not matter that you think you've "compiled" your Java code by typing a command which reads a text file and generates a binary file. The binary file still has to be interpreted by the JVM.
I can only assume that you did not know this, Anonymous Coward. Does this help clue you in?
Dave Bailey
Please, no more articles about benchmarks
on
Java Rocks On Linux
·
· Score: 2
Benchmarks are hardly "stuff that matters". Benchmarking Java is a waste of time and I do not understand why this is considered news. Is it really such a big deal that Java is faster than it used to be? Java has been fast enough for web applications for a long time (all it has to do is be more or less equivalent to Perl, which isn't such a big deal considering that both are interpreted languages). People who decide to use Java don't do so because it's fast. They do so because they like Java, for whatever reason.
I am tired of benchmarks. I am tired of hearing about MySQL vs Postgres, Apache vs IIS, etc. That
sort of benchmarking is not worthy of discussion and Slashdot should understand this by now. Hey. If Ingo Molnar writes a kernel-space web server which will be available in upcoming Linux distributions, that's interesting and that's news. But please. Please. PLEASE stop with all of these useless benchmarks. All they do is provoke people and lead to endless arguments about nothing at all.
Slashdot Mirror
In my view, patents provide a valuable service in our society, protecting people who create value from those who would steal it.
No, in your view, patents provide a way to make money. If you were really interested in protecting those who create value, you'd be focusing your efforts elsewhere. No value was created by the filing of the patents that you are now trying to "enforce". The real value was created by the architects of HTTP, SSL and HTML, as well as the multitudes of programmers and web designers who actually put in the work to make the World Wide Web what it is today. What did your client contribute to this edifice? Nothing, and you know it - if not now, then soon, when you're sued into oblivion. Live by the sword, die by the sword. Perhaps you should take up something easier, like selling Amway products?
Anyway, I see two issues. One, what size DNA strand can be sequenced using a nanopore without breaking? Two, how many nanopores can be made to operate simultaneously? With 100 nanopores operating in parallel on 10-kilobase DNA fragments at 10 seconds per nanopore per fragment, you're getting 10 kilobases per second, or a billion bases every three hours. At these speeds, the real limiting factor is probably going to be something other than raw sequencing speed. I think it's a very exciting technology.
Let's see your C.V.
Sorry, I'm a jackass. I thought your post was a response to mine. Ignore that.
Oh hey, thanks. I forgot about > et al. I wasn't trying to be rude. I wanted to give an example of "I am a dick" programming style, which you can do really well in Perl. If I ever ran across code like this in a professional setting, I would laugh my ass off, then go yell at the author. Anyway, my real point is that if you can solve that problem in so little space in Perl, that's kind of interesting. To me, at least.
Perl can definitely look strange, but you learn over time just how much is possible with the top row of your keyboard, and in how little space it can be done. If you want an example of *readable* Perl code, check http://daveb.net/Code/Perl/phonecode.html. It's not as difficult as it seems. Eventually, you will cackle with glee while you hold down the shift key and bang away at that top row: @#$(&^@)#$&%_. Learn Perl. Love Perl. Be Perl. Then go on and learn something else.
I claim that the end result of your work is something which could have been done in Perl with an equivalent amount of effort by programmers as proficient in that language as you are in Lisp. The design would have been totally different, of course, but it would do the same thing. To me it sounds like you're saying, "I had to do it this way in Lisp, and there was no other way to do it in a different language which would not have been excessively difficult to implement.". Do you realize how sweeping of a claim that is? Is your expertise in Perl sufficient to allow you to make that claim?
My point is that there are entire classes of problems for which other languages are best suited - not always because of the innate superiority of the language in one respect or another. Fortran, LAPACK, yes. It is the best choice for complex and time consuming numerical computation. I mentioned CPAN because it is a mind-bogglingly extensive resource for programmers who don't wish to reinvent the wheel. You may sniff at Perl for various reasons, and that is fine, but the bottom line is because of its module system and the extensive community which has contributed to that system, there is an enormous variety of problems which I can solve in Perl much faster than you can solve in Lisp. That is Perl's strong point, and it makes Perl a much better choice than Lisp in those situations.
You seem to interpret my remarks as criticisms of Lisp, the language. They are not. There has to be a language with such naked clarity, and Lisp's unique features exist because of that clarity. I respect that. But that doesn't mean I'm going to use Lisp if someone tells me I have to design an algorithm to compute three dimensional wind fields from radar data at regular, closely spaced intervals. It doesn't mean I'll use Lisp to parse an XML document when ten lines of Perl will do the trick. And it doesn't mean I'd use Lisp to implement a web server which has to support 10,000 concurrent clients on a system with limited resources. There are many situations one encounters in the real world where the best tool for the job is not Lisp. So what?
How's that for a labor-saving device?
First, don't ever say things like, "For most problems". As soon as you say that you betray your inexperience. Second, wipe that semen off of your copy of SICP and go look at CPAN for a while, or browse the man pages for LAPACK, or download the source code to the FreeBSD kernel. Third, wait until you've developed a 20,000 line application from scratch in at least three languages before talking smack about one over the others. When you get to that point, you'll understand what you think you understand right now.
I gather from your comments that you are a rabid fan of Lisp. Good for you. Nevertheless, you've missed my point. My point is that for fast, efficient development of an application like the Yahoo store builder, you sure as hell don't need a language which permits the definition of new syntactic forms. For God's sake man, come back down to earth! Most web programming is child's play, and the main problem is not the insufficient capabilities of the languages used, it's the pathetic incompetence of the average web developer, especially in the early phases of application development, which matter the most. Software of any significance must be designed before it is written, and most web developers simply do not have experience with this. Unfortunately, that is the *real* reason why web applications are so frequently mangled beyond the point of maintainability as they evolve in capability over time - the accumulation of hacks and partial rewrites eventually turns the thing into an unintelligible mess which nobody can decipher save for the one or two poor souls who are unfortunate enough to have been there almost since the beginning, and they probably think that their ability to understand the pile of garbage makes them programming gurus. I also claim that this is the *real* reason Graham et al were able to move faster than their competition - better design, not a better language. Look, Lisp is a great programming language and I'm really happy for you that you love it so much, but you have got to understand that the difference between a master of a language working in his element and the typical programmer far, far outweighs the differences between the various programming languages used in web development. Didn't you ever read "The Mythical Man-Month"?
unsigned long factorial ( unsigned long x )
{
return (x>2)?x*factorial(x-1):2;
}
Besides, on a 32 bit machine the unsigned long will overflow when x > 13. You won't get a stack overflow until hundreds of thousands of levels of recursion for a function this simple. By that time, the result will be over 1 million digits long and would require a 5 million bit wide unsigned long data type. I don't see that happening anytime soon.
That prejudice alone is perhaps forgivable, but the logic used to support the claim - in particular, the reference to their use of Lisp macros - is laughable. Paraphrasing: "We used macros for 20-25% of our code, and Lisp macros are hard to write and can do things you can't easily do in other languages. ERGO, 20-25% of our application did things other languages can't do and was thus beyond the capability of our competitors to implement.". "I encourage you to follow that thread", the author exhorts. Sure, I'll follow that thread. I'll follow that thread right to where it ends in a frayed, tattered mess at the foot of a giant billboard that says, "Hey guess what? It's an online store builder, and that ain't rocket science. Calm down and save the Aikido speech for the choir, because they'll listen and nobody else will.". The real reason these guys did well is simply that they were good, fast programmers and their competitors were not. It has nothing to do with Lisp. Had they been faced with a team of Perl hackers of equivalent skill to their Lisp mastery, things would have been more interesting.
I'm amazed every time I read someone posting on Slashdot about what an awesome coder they are. To me, this invariably means the poster is insecure and needs to brag on Slashdot to shore up his ego. The best programmers I've met never brag about themselves. Their work speaks for itself. It is clean and elegant. It's not full of 800 line functions with no comments. It's modularized in a way which makes sense, and is documented thoroughly - to the tune of one line of comments per 2 or 3 lines of code. And it's formatted in an aesthetically pleasing manner which makes it easier to read and understand. The braggarts, on the other hand, usually come on strong in the beginning so they can make a big impression on you (and at first this works pretty well), then gradually you learn that they're full of shit.
Extreme Programming might help reduce the jackass ratio, and I think that's a good thing. The exact methodology isn't so important; what matters is that programmers are being taught to work together and create software someone else can develop and maintain. Yes, there are lone wolf badasses out there who can put us all to shame. But you're probably not one of them - and if you're one of those people who brags on Slashdot about how great you are, then you're definitely not one of them.
A friend of mine who works in the ADSL group at Texas Instruments told me that the falloff in bandwidth with distance from the phone office is actually pretty negligible until you get to about 2 km. After that you start losing bandwidth due to signal attenuation (AC conductivity of copper goes as 1/f^2 where f is the frequency of the alternating current, and ADSL uses frequencies up to at least 1 MHz IIRC). The point is, if you live within a mile of the phone office, life is great. If you live within 3 miles, life is tolerable. If you live farther away than that, then you should move or figure out some other broadband solution.
Dave Bailey
After all, one has to wonder: would Napster have gained so much popularity were it not for the high-speed connections enjoyed by many college students these days? Without so much broadband in universities, who would want their uplink saturated by strangers? On the other hand, when you have a T1 in your dorm room, you might not even notice a few people grabbing files from you at any given time.
So, I would be interested to see how much of a correlation there is between one's willingness to share files and one's bandwidth to do so.
Dave Bailey
Bit rate is proportional to bandwidth times the logarithm of the signal-to-noise ratio. To maximize bandwidth, you go up to higher and higher transmission frequencies. To maximize signal to noise ratio, you step up the transmission power. But in a wireless laser network, both of these steps have their disadvantages.
The first problem is essentially that the higher frequencies (e.g. infrared, which is on the order of microns, as opposed to microwave, which is on the order of centimeters) are more susceptible to various scattering phenomena. The most frequently mentioned is, of course, fog, dust, smog, etc. These scatterers are far to small to have any significant effect on, for example, cellular communications (transmitted signal has a wavelength of tens of centimeters, not microns), but they are excellent scatterers in smaller wavelengths. In addition, the atmosphere itself scatters visible light more and more effectively as you go to higher and higher frequencies, reaching a maximum somewhere in the ultraviolet. This is due to the electronic properties of diatomic nitrogen and oxygen and cannot be avoided. (As a side note, it is also why the sky is blue and sunsets are red). So, one cannot step around the fog problem by going to even higher frequencies. I believe, but am not certain, that fiberless lasers still operate in the IR.
The second problem, of course, is that stepping up the power output of the transmitter is expensive. A tenfold increase in bandwidth requires a thousandfold increase in signal to noise ratio. To see why this is so, imagine that with a given signal to noise ratio, you can resolve 16 signal strengths with a bit error rate of less than, say, 10^-8. This means that you can transmit 4 bits of information per symbol. To get twice as many bits per symbol, or double the bit rate, you need to be able to resolve 256 signal strengths - i.e. square your signal to noise ratio. To get 12 (three times as many) bits per symbol, you need to cube your S/N, and so on. Essentially, you have to double your S/N for each additional bit per symbol you wish to be able to resolve at a certain bit error rate. Hence the need for enormously increased power to achieve relatively modest increases in bandwidth.
So, with these constraints in mind, it will be interesting to see what optimum is achieved by TeraBeam et al, and how resilient their systems turn out to be.
Dave Bailey
This is why they call it a "virtual machine". The JVM is the "target architecture" for "compiled" Java code. It has its own binary-coded instruction set, and Java "compilers" simply produce output for that instruction set. The JVM takes instructions for its "architecture" and *interprets* them to the native architecture (e.g. Intel/x86, Sun/Sparc, etc). It does not matter that you think you've "compiled" your Java code by typing a command which reads a text file and generates a binary file. The binary file still has to be interpreted by the JVM.
I can only assume that you did not know this, Anonymous Coward. Does this help clue you in?
Dave Bailey
I am tired of benchmarks. I am tired of hearing about MySQL vs Postgres, Apache vs IIS, etc. That sort of benchmarking is not worthy of discussion and Slashdot should understand this by now. Hey. If Ingo Molnar writes a kernel-space web server which will be available in upcoming Linux distributions, that's interesting and that's news. But please. Please. PLEASE stop with all of these useless benchmarks. All they do is provoke people and lead to endless arguments about nothing at all.
Dave Bailey