Better use GPG instead. PGP (post v2.6.2, at least) uses RSA libraries, and probably also escrows keys with the government. GPG, on the other hand, is completely open source. It's also completely compatible with PGP.
It seems that too many people watch X-Files, and are starting to confuse fact and fiction. This seems like a paraphrasing of the Echelon story run here about 1 1/2 weeks ago. That story, too, seemed design to confuse fact and fiction (very few verfiable sources were cited).
The hardware and man hours required for this level of communications monitoring is simply too great. Besides, too many people would know about this if this were true. The secret would have gotten out long ago, and with many more verifiable sources.
Ever think that Intel & Microsoft made it through clever, strategic, and downright dirty business tactics? If Intel had illegally obtained secrets from competitors, don't you think their chips would be at least as fast as their competitors? Don't you think that you, too, could do pull some pretty brutish moves if you had $20 billion cash-on-hand to use as investment capital?
Look, maybe I'm wrong. Maybe there is a huge conspiracy. However, I usually tend to believe that the simplest explanation is also usually the correct one.
I'm not trying to say that the US gov't doesn't have the ability to track any given piece of e-mail, or that they can't crack any widely used encryption scheme, or that they can't monitor any given phone conversation in most parts of the world. I'm just saying that they don't monitor *every* e-mail and/or http: request. They can't crack *every* encrypted message. They can't monitor *every* phone call simultaneously. There's simply too much to do for that to be possible. And, while the US does have some interesting technologies in its military and intelligence wings, these technologies are orders of magnitude better than what ordinary individuals and companies have access to.
Ever wonder why the F-117 (the "stealth fighter") is composed of flat panels, all at odd angles? For purposes of stealth aircraft, corners are bad ju-ju. Yet the F-117 has tons of them. The reason is that the plane was designed in the early 70s, using commonly available technology during that time (not alien tech, as some suggest). They couldn't model curved surfaces on the supercomputers of their day! If they had access to some superior, ultra-fast technology, the F-117 would have looked more similar to the B-2. This isn't intended as definative proof that the US doesn't have such wonderous computing & networking tech. It is merely intended to show that the US gov't, too, proceeds at the same pace as the rest of the world, albeit with a quarter step head start. The tech required to do these sorts of things is simply too great--and I therefore reject these stories as X-Files inspired paranoia (and I hope that I am correct;-).
Sound intensity levels == volume, not sound pressure. If a transducer is a point source (conventional speakers simulate point sources), then sound intensity is roughly equivalent to sound pressure. However, with complex combinations of tranducers, you can have high sound intensity levels with low sound pressure levels (and vice-versa). We measure sound pressure levels only because it is easy to measure (simply measure pressure, and compare it to some reference). I believe that sound intensity levels require directional arrays of tranducers to measure, and are typically only measured when environmental regulations require them.
If you remain unconvinced, go check out your local environmental laws regarding sound pollution. They have separate requirements for sound pressure levels and sound intensity levels.
You don't have to go to this extreme to get bass response from electrostats. Just take a look at Stax headphones to see this (www.headphone.com).
Electrostats are essentially full-range speakers. However, at lower frequencies (wavelengths > 1/2 width of speaker baffle), the front wave cancels with the back wave. This is the reason that most speakers come in boxes. However, a box loads an electrostat too much, damping the motion of the diaphram.
Basically, you simply need to isolate the back wave from the front wave. This can be done by mounting a small electrostat in a big flat panel. I've often thought about building some electrostats to mount between studs in a wall. This ought to provide enough isolation to allow electrostats to produce 20Hz sound.
HP recenetly split up the company into a computer company and a test equipment company. The computer company is still called 'HP'. I forget what the test equipment company is called. It seems that your advice was already taken!
Both are good RAD languages, but Java is OO
on
JAVA vs. The World
·
· Score: 1
IMHO, VB & Java are both about equivalent in terms of rapid development.
Java, however, is object oriented. In general, I would say this gives Java a *huge* leg up. However, if your developers are not familiar with OO technologies, I would suspect this would be a disadvantage rather than an advantage. OO technologies make large-scale app design *much* easier, if and only if the OO design is done well. Java makes OO design much easier than it is in C++, but OO design still requires skill.
That said, I have found that interpreted Java (which you should never have to use) runs about 1/100th the speed of compiled native code. JIT (Just-In-Time) compilers run about 1/20th to 1/10th the speed of compiled native code. HotSpot, the dynamic optimizing JIT that Sun will soon release, is hailed as the Holy Grail for Java, in that it is *supposed* to provide something like 1/2 to 1.1 times (yes, faster) the speed of native code. In my experience with pre-release versions, it quite simply doesn't cut the mustard.
Based on my experience with Java (my company sells an SDK for doing high-level 2D & 3D graphics), the main slowdown in JIT'ed Java code is that array boundaries are still checked for every array access. I have seen tests where they turn off array bounds checking in the JVM, and the machine runs about 10x faster. However, the type of code I write & maintain do tend to have tons of array accesses in them, so your mileage may vary.
All told, I think Java is an absolutely superb language. However, the speed sucks. Furthermore, the compilers available for Java still don't support Swing and/or AWT, the GUI interfaces for Java. As such, they are really only useful for server code, not client code.
1) US companies can *import* strong crypto all day long
2) US companies can own (at least part of, maybe more) foreign companies that do strong crypto, and then distribute that software (Sun owns a Russsian strong crypto company that does this).
3) US citizens are barred from working for a foreign employer while working on strong crypto.
4) Strong crypto code, in printed form, falls under free speech laws, and can be exported from the US.
5) Code, in software form, falls under munitions laws, and cannot be exported from the US.
6) American citizens cannot even program in features that allow others to (easily) put in strong crypto. You can't write a mail client that includes a call to a.dll or.so, and then publish that others can replace the.dll or.so with one that encrypts messages on send, for instance. I don't know how sendmail gets around this--maybe noone at the US Bureau of Tobacco & Firearms has taken a close enough look.
7) Most of the (US owned) patents covering strong cryptography have either already expired, or will expire this year and next year. Meanwhile the US government prevents the US-based owners of the patents from making money outside the US.
You know, a Java chip would have to be able to handle new instructions as new instructions are added to the JVM spec. Other than this, I don't see that the life cycle of general purpose CPUs would be long enough to warrent upgrading the ability of upgrading the instruction set. Making the chip be able to emulate other chips would be nice. However, I think you'd run into so many other problems relating to software support of hardware subsystems (are a Mac, PC, & alpha all going to be able to use the *exact* same video card?).
I dunno. I think that this thing would primarily be useful in laptops (low power consumption) and embedded Java chips. The way Java is being utilized on servers & n-tier systems, I can see where they'd be able to get away with charging big $$$ fo this chip, at least until there is viable competition.
The variable costs of production (manufacturing the chip, which could be cheap) does not equal the total costs of production. Some fixed costs come into play (R&D, for instance).
It might be cheap to *make*, but they still have to recoup those R&D costs. Of course, if Transmeta turns out several 10s of millions of these, then their fixed costs become negligible.
The long awaited integration of TV sets and computers is coming. However, it won't be all the new features you'll get that will drive the change. It will be cost.
Have any of you looked at the cost of HDTV tuners? In addition to an HDTV-capable TV set, you have to buy a ~$1500 converter! Well, now you'll be able to get it for under $300. And a line doubler, to boot! Stand-alone line doublers cost $2000 by themselves.
Now, if only they'd start making 60" monitors with 1280x1024 resolution (or maybe 1600x1024 for movies!), I'd be happy. Of course, this is coming, too. Just wait until it's cheaper to put 8 million transistors into an LCD than it is to grind optics for a TV. Yes, cheap, large screens integrated to computers are on their way!
I see a lot of FUD about speaker technology in the replies to this post. For the record:
-Planer speakers were developed *before* cone-driven speakers. The original amplified sound transducer is an electrostatic speaker. It dates back to something like 1917
-This technology is, indeed, new. It works by setting up complex interference patterns between multiple transducers placed on a stretched membrane. By contrast, magnaplaner, electrostatic, and ribbon speakers all apply a uniform force over the entire membrane. The advantage of NXT's approach is that problems with bass cancellation from the back wave and the front wave are compensated for by the complex interference patterns. To demonstrate this, move your hand through a bathtub full of water. If you move it swiftly, you get waves in the water. If you move it slowly, the water from the front side of your hand moves around your hand to the back side before any waves can be set up. Move both your hands slowly through the water, spaced apart by some distance, and you will get waves. Basically, if the wavelength at a given frequency is less that 1/2 the width and/or height of the transducer, it will "beam" forward. If it is greater than 1/2 the width and/or height, it will eminate radially from the tranducer, allowing the front wave to travel around the speaker and cancel with the back wave. This is why most "traditional" planer speakers (electrostatics & magneplaners) are mounted in large panels (in the case of electrostatics, the speakers *are* the large panels). It also explains why electrostatics (with the exception of Quad ESL speakers) "beam", as the high frequencies eminate from the *entire* surface, where the waves don't eminate radially (Quads filter the high frequencies, and transmit them through a very small area at the center of the speaker). This is why most electrostats "beam", providing only a single listener with the rich, accurate sound for which they are famous. BTW, you can get much the same effect by using cone drivers mounted in a baffle that is not enclosed (no box). It is not intrinsic to the transducer technology; it is intrinsic to the baffle technology.
-NXT's technology supposedly can produce deep base with a small panel, due to the interference of the waves from the multiple transducers. They shouldn't be limited by speaker size the same way as other planer speakers.
-NXT's work is *new*, and extremely mathematically complex. In fact, the mathematics are so complex that they can only be performed on high-powered computers that have been available in recent years. We can model point sources very well when looking at wave interactions. Planer sources must be modeled using techniques similar to Finite Element Modelling. FEM has been the single biggest market for Cray's supercomputers over the past 20 years--and simulations still can take weeks with today's massively parallel computers. NXT's technology came out of military research used to cancel sound waves inside a cockpit without using headphones, according to NXT. Quite frankly, I believe that this technology came out of military research aimed at cancelling jet engine and helicoptor rotor noise *outside* the aircraft, so as to create sonically stealthy aircraft. This, however, is pure speculation (anyone have access to Jane's? maybe they elucidate the matter).
-This technology is still young. These speakers are a first pass at implementing the technology in a commercial product. I suspect that future iterations will get much better, particularly at producing deep bass.
-This is the same technology that was talked about in a previous slashdot article, about producing sound from plexiglass windows. In fact, some of the technologies that have been discussed are: producing sound from the front of a TV picture tube, producing sound from the roof on a domed stadium, producing sound from panels that fold out from a laptop, and producing sound from the walls of a home. There is no theoretical limit to the size of the tranducer (no "beaming" effects at high frequencies, as with other planer speakers).
In short, this technology is neat stuff. If you're not convinced about the quality of sound from planar speakers, don't judge them from thes $99 speakers. Instead, go down to a high-end audio store and give a listen to some Martin Logans (electrostatic), Quads (electrostatic), Magnepans (quasi-magneplaner), or Apogees (true magneplaner). The sound is really quite stunning. Furthermore, I believe that when this technology is mature, the sound produced by NXT drivers will be absolutely exquisite, packaged in an uncumbersome form factor, and rather inexpensive. In many ways, this may be the Holy Grail of speaker technologies.
If you violate a contract that you agree to, you can be sued. A simple check of the CVS tree would indicate which user(s) checked in code in violation of the MS license agreement.
If you aren't in the US, but you sign the agreement, you are still liable (unless the terms of the agreement violate the laws of your local country). However, pursuing such lawsuits can be extremely difficult.
You're right to say that it can be hard to surpress code that has been open sourced. However, distribution of such code is also against the law. Microsoft, with its armada of lawyers, would undoubtedly sue any of the larger FTP sites that distribute illegally obtained code (code that violates their copyright and/or their license agreement).
As long as Microsoft did not *copy* lines from WINE's code, then they can look at WINE's code all day long, without repurcussions. The source code license for WINE, as with most "open source" efforts, is very liberal in this area.
All I'm saying is, "Be careful". If you want to develop for WINE, don't look at *any* of the MS code. People like Phil Zimmerman, author of PGP, know very well what it is like to live in the wrath of never-ending lawsuits (others, outside the US, allegedly distributed copyrighted code that he used in early versions of PGP).
If you violate a contract that you agree to, you can be sued. A simple check of the CVS tree would indicate which user(s) checked in code in violation of the MS license agreement.
If you aren't in the US, but you sign the agreement, you are still liable (unless the terms of the agreement violate the laws of your local country). However, pursuing such lawsuits can be extremely difficult.
You're right to say that it can be hard to surpress code that has been open sourced. However, distribution of such code is also against the law. Microsoft, with its armada of lawyers, would undoubtedly sue any of the larger FTP sites that distribute illegally obtained code (code that violates their copyright and/or their license agreement).
As long as Microsoft did not *copy* lines from WINE's code, then they can look at WINE's code all day long, without repurcussions. The source code license for WINE, as with most "open source" efforts, is very liberal in this area.
All I'm saying is, "Be careful". If you want to develop for WINE, don't look at *any* of the MS code. People like Phil Zimmerman, author of PGP, know very well what it is like to live in the wrath of never-ending lawsuits (others, outside the US, allegedly distributed copyrighted code that he used in early versions of PGP).
This depends on the country. In the US, the loser of a lawsuit does not have to pay the winner's legal fees, unless it is part of punitive damages as part of a frivelous lawsuit.
It all depends on the license the person agrees to in order to look at the code. US contract law states that, unless a clause specifically violates an existing law, anything that a person signs in a contract is contractually valid. That person can, in turn, be sued if he or she violates the terms in the contract.
It really has nothing to do with intellectual property law. IP law covers such things as copyrights, trademarks, and patents.
Ever called that Z28 a Delco/Z28? I didn't think so. Yet, without those Delco parts that GM puts in there, it won't run. In fact, those Delco parts are the foundation of what makes the car run. The name "Z28" is just that--a name.
Linux would not work without the GNU foundation. Like it or not, the community that uses Linux has named it "Linux", not "GNU/Linux". This decision did not come from Linus, but from the community (Linus himself claims to be a little embarrased that a facsimilie of his name was used to describe the OS). Besides, like "Z28", "Linux" is just a name. It is not an attempt to describe all that goes into it.
Yes, it's true. The WINE developers would be forced *not* to look at the code. However, I think you have it backwards when you say "it's a LOT harder to prove you didn't peak at the code". In the USA, this burdon is placed on the accusor, not on the accused.
That said, there's nothing that prevents the Micros~1 layers from filing lawsuit after lawsuit, until the WINE developers finally give up for lack of funds for their defense.
If you want to develop for WINE, make absolutely sure you never look at the Windows code...
Boy, it appears as though this author has never programmed in Java before. If you need multiple inheritance, your design is flawed. If you need templates, look at the Generic Java page:
http://wwwipd.ira.uka.de/~pizza/gj/
Templates save some time typing, but that's about it.
Templates and multiple inheritance can be implemented well. However, using these usually ends up in difficult to read, and thus difficult to maintain, code.
A computer language should be set up to facilitate writing code. If "arbitrary" rules are set up within the language such that the resulting code can be written quicker, and is easier to maintain, then that language is not necessarily inferior.
When it comes down to it, all a language needs are basic boolean and arithmetic operators, jumps (gotos, loops, etc), and conditionals (if/then). I believe this was even logically proven (my computer logic courses are too distant now). Java allows for all these. Thus, literally any program that can be written, can be written in a language that supports these features.
That said, I recommend that this author try programming something non-trivial in Java. I have. I've written about 30,000 lines of Java code, as part of a project that sits at about 120,000 lines of code. Java has made this project go several times faster than it would have had it been developed in C++. Some of this is due to the Java architecture. A lot of it has to do with the rich set of built-in packages. Porting is as simple as copying the post-compiled code from machine to machine (it didn't use to be that way, but Java has improved since then).
All I'm saying is that you shouldn't harsh on Java without giving it a chance. Otherwise, you're simply spreading FUD. This is no different than the Micros~1 weenies saying that Linux sucks, since Linux has no support.
Why use Java? Because most people I know are about 4-5x more productive when programming in Java, relative to C++. It's a better designed language.
Yes, it falls down on speed issues. That will change, though.
This is too good to be true.
on
Java for EGCS
·
· Score: 1
Unfortunately, there is no AWT support for GJC. Without AWT support, there surely won't be any GTK AWT plaf (pluggable look and feel).
This is a nice solution for server-side java. However, for client-side java, we're still stuck with slow, JIT compiled (or, worse, interpreted) Java.
Anyone know if this circumvents Java's array bounds checking? I suspect it doesn't. When using a good JIT, this is the biggest impediment to fast Java (at least with my code).
Hey, Java is a great programming language. However, until you can turn of bounds checking, and compile code with a GUI, it will remain slow.
You can see anything that is under patent. Patents enforce open publication of inventions. They merely require that any production other than for personal use require a license from the patent holder.
If specs for DVD & TV tuners were all patented, then I imagine we'd see drivers almost overnight. Instead, they are treated as Trade Secrets, kind of like the formula for Coca Cola. These restrict sharing much more than patents do.
My father-in-law was thinking about buying one because he lives in very rural America. He wanted to be able to go into town, buy 10 or 20 divx movies, then watch them at his leisure. There are no video stores where he lives, so he felt this was a decent compromise.
I told him that www.reel.com rents movies by mail. He bought a DVD.
However, this is one case where a divx *might* be useful.
Slashdot Mirror
Yes. They're going to kill me. Now I'm worried!
Oh, and all Christians, save the politians, are Good!
Oooh. Now I'm quaking in my boots.
Ellis, you need to stop watching the X-Files and start reading few more newspapers.
Better use GPG instead. PGP (post v2.6.2, at least) uses RSA libraries, and probably also escrows keys with the government. GPG, on the other hand, is completely open source. It's also completely compatible with PGP.
It seems that too many people watch X-Files, and are starting to confuse fact and fiction. This seems like a paraphrasing of the Echelon story run here about 1 1/2 weeks ago. That story, too, seemed design to confuse fact and fiction (very few verfiable sources were cited).
;-).
The hardware and man hours required for this level of communications monitoring is simply too great. Besides, too many people would know about this if this were true. The secret would have gotten out long ago, and with many more verifiable sources.
Ever think that Intel & Microsoft made it through clever, strategic, and downright dirty business tactics? If Intel had illegally obtained secrets from competitors, don't you think their chips would be at least as fast as their competitors? Don't you think that you, too, could do pull some pretty brutish moves if you had $20 billion cash-on-hand to use as investment capital?
Look, maybe I'm wrong. Maybe there is a huge conspiracy. However, I usually tend to believe that the simplest explanation is also usually the correct one.
I'm not trying to say that the US gov't doesn't have the ability to track any given piece of e-mail, or that they can't crack any widely used encryption scheme, or that they can't monitor any given phone conversation in most parts of the world. I'm just saying that they don't monitor *every* e-mail and/or http: request. They can't crack *every* encrypted message. They can't monitor *every* phone call simultaneously. There's simply too much to do for that to be possible. And, while the US does have some interesting technologies in its military and intelligence wings, these technologies are orders of magnitude better than what ordinary individuals and companies have access to.
Ever wonder why the F-117 (the "stealth fighter") is composed of flat panels, all at odd angles? For purposes of stealth aircraft, corners are bad ju-ju. Yet the F-117 has tons of them. The reason is that the plane was designed in the early 70s, using commonly available technology during that time (not alien tech, as some suggest). They couldn't model curved surfaces on the supercomputers of their day! If they had access to some superior, ultra-fast technology, the F-117 would have looked more similar to the B-2. This isn't intended as definative proof that the US doesn't have such wonderous computing & networking tech. It is merely intended to show that the US gov't, too, proceeds at the same pace as the rest of the world, albeit with a quarter step head start. The tech required to do these sorts of things is simply too great--and I therefore reject these stories as X-Files inspired paranoia (and I hope that I am correct
Hasn't the US designed and used chemical and biological weapons?
Iran is not the same Iran from 1980. Things have changed. US export restrictions against Iran are stupid. As are US export restrictions against Cuba.
-an American citizen that lived in Iran for 4 years
Well, this speaker advertisement is full of feces. However, you are wrong when you say that sound pressure levels == volume.
l #levels
Check out: http://newport.pmel.noaa.gov/whales/acoustics.htm
Sound intensity levels == volume, not sound pressure. If a transducer is a point source (conventional speakers simulate point sources), then sound intensity is roughly equivalent to sound pressure. However, with complex combinations of tranducers, you can have high sound intensity levels with low sound pressure levels (and vice-versa). We measure sound pressure levels only because it is easy to measure (simply measure pressure, and compare it to some reference). I believe that sound intensity levels require directional arrays of tranducers to measure, and are typically only measured when environmental regulations require them.
If you remain unconvinced, go check out your local environmental laws regarding sound pollution. They have separate requirements for sound pressure levels and sound intensity levels.
I've got a fetish for electrostatic speakers.
You don't have to go to this extreme to get bass response from electrostats. Just take a look at Stax headphones to see this (www.headphone.com).
Electrostats are essentially full-range speakers. However, at lower frequencies (wavelengths > 1/2 width of speaker baffle), the front wave cancels with the back wave. This is the reason that most speakers come in boxes. However, a box loads an electrostat too much, damping the motion of the diaphram.
Basically, you simply need to isolate the back wave from the front wave. This can be done by mounting a small electrostat in a big flat panel. I've often thought about building some electrostats to mount between studs in a wall. This ought to provide enough isolation to allow electrostats to produce 20Hz sound.
HP recenetly split up the company into a computer company and a test equipment company. The computer company is still called 'HP'. I forget what the test equipment company is called. It seems that your advice was already taken!
IMHO, VB & Java are both about equivalent in terms of rapid development.
Java, however, is object oriented. In general, I would say this gives Java a *huge* leg up. However, if your developers are not familiar with OO technologies, I would suspect this would be a disadvantage rather than an advantage. OO technologies make large-scale app design *much* easier, if and only if the OO design is done well. Java makes OO design much easier than it is in C++, but OO design still requires skill.
That said, I have found that interpreted Java (which you should never have to use) runs about 1/100th the speed of compiled native code. JIT (Just-In-Time) compilers run about 1/20th to 1/10th the speed of compiled native code. HotSpot, the dynamic optimizing JIT that Sun will soon release, is hailed as the Holy Grail for Java, in that it is *supposed* to provide something like 1/2 to 1.1 times (yes, faster) the speed of native code. In my experience with pre-release versions, it quite simply doesn't cut the mustard.
Based on my experience with Java (my company sells an SDK for doing high-level 2D & 3D graphics), the main slowdown in JIT'ed Java code is that array boundaries are still checked for every array access. I have seen tests where they turn off array bounds checking in the JVM, and the machine runs about 10x faster. However, the type of code I write & maintain do tend to have tons of array accesses in them, so your mileage may vary.
All told, I think Java is an absolutely superb language. However, the speed sucks. Furthermore, the compilers available for Java still don't support Swing and/or AWT, the GUI interfaces for Java. As such, they are really only useful for server code, not client code.
Some interesting things:
.dll or .so, and then publish that others can replace the .dll or .so with one that encrypts messages on send, for instance. I don't know how sendmail gets around this--maybe noone at the US Bureau of Tobacco & Firearms has taken a close enough look.
1) US companies can *import* strong crypto all day long
2) US companies can own (at least part of, maybe more) foreign companies that do strong crypto, and then distribute that software (Sun owns a Russsian strong crypto company that does this).
3) US citizens are barred from working for a foreign employer while working on strong crypto.
4) Strong crypto code, in printed form, falls under free speech laws, and can be exported from the US.
5) Code, in software form, falls under munitions laws, and cannot be exported from the US.
6) American citizens cannot even program in features that allow others to (easily) put in strong crypto. You can't write a mail client that includes a call to a
7) Most of the (US owned) patents covering strong cryptography have either already expired, or will expire this year and next year. Meanwhile the US government prevents the US-based owners of the patents from making money outside the US.
You know, a Java chip would have to be able to handle new instructions as new instructions are added to the JVM spec. Other than this, I don't see that the life cycle of general purpose CPUs would be long enough to warrent upgrading the ability of upgrading the instruction set.
Making the chip be able to emulate other chips would be nice. However, I think you'd run into so many other problems relating to software support of hardware subsystems (are a Mac, PC, & alpha all going to be able to use the *exact* same video card?).
I dunno. I think that this thing would primarily be useful in laptops (low power consumption) and embedded Java chips. The way Java is being utilized on servers & n-tier systems, I can see where they'd be able to get away with charging big $$$ fo this chip, at least until there is viable competition.
I think you hit it on the head.
The variable costs of production (manufacturing the chip, which could be cheap) does not equal the total costs of production. Some fixed costs come into play (R&D, for instance).
It might be cheap to *make*, but they still have to recoup those R&D costs. Of course, if Transmeta turns out several 10s of millions of these, then their fixed costs become negligible.
The long awaited integration of TV sets and computers is coming. However, it won't be all the new features you'll get that will drive the change. It will be cost.
Have any of you looked at the cost of HDTV tuners? In addition to an HDTV-capable TV set, you have to buy a ~$1500 converter! Well, now you'll be able to get it for under $300. And a line doubler, to boot! Stand-alone line doublers cost $2000 by themselves.
Now, if only they'd start making 60" monitors with 1280x1024 resolution (or maybe 1600x1024 for movies!), I'd be happy. Of course, this is coming, too. Just wait until it's cheaper to put 8 million transistors into an LCD than it is to grind optics for a TV. Yes, cheap, large screens integrated to computers are on their way!
NXT's speakers can supposedly be placed next to a wall.
I see a lot of FUD about speaker technology in the replies to this post. For the record:
-Planer speakers were developed *before* cone-driven speakers. The original amplified sound transducer is an electrostatic speaker. It dates back to something like 1917
-This technology is, indeed, new. It works by setting up complex interference patterns between multiple transducers placed on a stretched membrane. By contrast, magnaplaner, electrostatic, and ribbon speakers all apply a uniform force over the entire membrane. The advantage of NXT's approach is that problems with bass cancellation from the back wave and the front wave are compensated for by the complex interference patterns. To demonstrate this, move your hand through a bathtub full of water. If you move it swiftly, you get waves in the water. If you move it slowly, the water from the front side of your hand moves around your hand to the back side before any waves can be set up. Move both your hands slowly through the water, spaced apart by some distance, and you will get waves. Basically, if the wavelength at a given frequency is less that 1/2 the width and/or height of the transducer, it will "beam" forward. If it is greater than 1/2 the width and/or height, it will eminate radially from the tranducer, allowing the front wave to travel around the speaker and cancel with the back wave. This is why most "traditional" planer speakers (electrostatics & magneplaners) are mounted in large panels (in the case of electrostatics, the speakers *are* the large panels). It also explains why electrostatics (with the exception of Quad ESL speakers) "beam", as the high frequencies eminate from the *entire* surface, where the waves don't eminate radially (Quads filter the high frequencies, and transmit them through a very small area at the center of the speaker). This is why most electrostats "beam", providing only a single listener with the rich, accurate sound for which they are famous. BTW, you can get much the same effect by using cone drivers mounted in a baffle that is not enclosed (no box). It is not intrinsic to the transducer technology; it is intrinsic to the baffle technology.
-NXT's technology supposedly can produce deep base with a small panel, due to the interference of the waves from the multiple transducers. They shouldn't be limited by speaker size the same way as other planer speakers.
-NXT's work is *new*, and extremely mathematically complex. In fact, the mathematics are so complex that they can only be performed on high-powered computers that have been available in recent years. We can model point sources very well when looking at wave interactions. Planer sources must be modeled using techniques similar to Finite Element Modelling. FEM has been the single biggest market for Cray's supercomputers over the past 20 years--and simulations still can take weeks with today's massively parallel computers. NXT's technology came out of military research used to cancel sound waves inside a cockpit without using headphones, according to NXT. Quite frankly, I believe that this technology came out of military research aimed at cancelling jet engine and helicoptor rotor noise *outside* the aircraft, so as to create sonically stealthy aircraft. This, however, is pure speculation (anyone have access to Jane's? maybe they elucidate the matter).
-This technology is still young. These speakers are a first pass at implementing the technology in a commercial product. I suspect that future iterations will get much better, particularly at producing deep bass.
-This is the same technology that was talked about in a previous slashdot article, about producing sound from plexiglass windows. In fact, some of the technologies that have been discussed are: producing sound from the front of a TV picture tube, producing sound from the roof on a domed stadium, producing sound from panels that fold out from a laptop, and producing sound from the walls of a home. There is no theoretical limit to the size of the tranducer (no "beaming" effects at high frequencies, as with other planer speakers).
In short, this technology is neat stuff. If you're not convinced about the quality of sound from planar speakers, don't judge them from thes $99 speakers. Instead, go down to a high-end audio store and give a listen to some Martin Logans (electrostatic), Quads (electrostatic), Magnepans (quasi-magneplaner), or Apogees (true magneplaner). The sound is really quite stunning. Furthermore, I believe that when this technology is mature, the sound produced by NXT drivers will be absolutely exquisite, packaged in an uncumbersome form factor, and rather inexpensive. In many ways, this may be the Holy Grail of speaker technologies.
If you violate a contract that you agree to, you can be sued. A simple check of the CVS tree would indicate which user(s) checked in code in violation of the MS license agreement.
If you aren't in the US, but you sign the agreement, you are still liable (unless the terms of the agreement violate the laws of your local country). However, pursuing such lawsuits can be extremely difficult.
You're right to say that it can be hard to surpress code that has been open sourced. However, distribution of such code is also against the law. Microsoft, with its armada of lawyers, would undoubtedly sue any of the larger FTP sites that distribute illegally obtained code (code that violates their copyright and/or their license agreement).
As long as Microsoft did not *copy* lines from WINE's code, then they can look at WINE's code all day long, without repurcussions. The source code license for WINE, as with most "open source" efforts, is very liberal in this area.
All I'm saying is, "Be careful". If you want to develop for WINE, don't look at *any* of the MS code. People like Phil Zimmerman, author of PGP, know very well what it is like to live in the wrath of never-ending lawsuits (others, outside the US, allegedly distributed copyrighted code that he used in early versions of PGP).
If you violate a contract that you agree to, you can be sued. A simple check of the CVS tree would indicate which user(s) checked in code in violation of the MS license agreement.
If you aren't in the US, but you sign the agreement, you are still liable (unless the terms of the agreement violate the laws of your local country). However, pursuing such lawsuits can be extremely difficult.
You're right to say that it can be hard to surpress code that has been open sourced. However, distribution of such code is also against the law. Microsoft, with its armada of lawyers, would undoubtedly sue any of the larger FTP sites that distribute illegally obtained code (code that violates their copyright and/or their license agreement).
As long as Microsoft did not *copy* lines from WINE's code, then they can look at WINE's code all day long, without repurcussions. The source code license for WINE, as with most "open source" efforts, is very liberal in this area.
All I'm saying is, "Be careful". If you want to develop for WINE, don't look at *any* of the MS code. People like Phil Zimmerman, author of PGP, know very well what it is like to live in the wrath of never-ending lawsuits (others, outside the US, allegedly distributed copyrighted code that he used in early versions of PGP).
-dan
This depends on the country. In the US, the loser of a lawsuit does not have to pay the winner's legal fees, unless it is part of punitive damages as part of a frivelous lawsuit.
In short, in the US, the loser does *not* pay.
It all depends on the license the person agrees to in order to look at the code. US contract law states that, unless a clause specifically violates an existing law, anything that a person signs in a contract is contractually valid. That person can, in turn, be sued if he or she violates the terms in the contract.
It really has nothing to do with intellectual property law. IP law covers such things as copyrights, trademarks, and patents.
Ever called that Z28 a Delco/Z28? I didn't think so. Yet, without those Delco parts that GM puts in there, it won't run. In fact, those Delco parts are the foundation of what makes the car run. The name "Z28" is just that--a name.
Linux would not work without the GNU foundation. Like it or not, the community that uses Linux has named it "Linux", not "GNU/Linux". This decision did not come from Linus, but from the community (Linus himself claims to be a little embarrased that a facsimilie of his name was used to describe the OS). Besides, like "Z28", "Linux" is just a name. It is not an attempt to describe all that goes into it.
Yes, it's true. The WINE developers would be forced *not* to look at the code. However, I think you have it backwards when you say "it's a LOT harder to prove you didn't peak at the code". In the USA, this burdon is placed on the accusor, not on the accused.
That said, there's nothing that prevents the Micros~1 layers from filing lawsuit after lawsuit, until the WINE developers finally give up for lack of funds for their defense.
If you want to develop for WINE, make absolutely sure you never look at the Windows code...
Boy, it appears as though this author has never programmed in Java before. If you need multiple inheritance, your design is flawed. If you need templates, look at the Generic Java page:
http://wwwipd.ira.uka.de/~pizza/gj/
Templates save some time typing, but that's about it.
Templates and multiple inheritance can be implemented well. However, using these usually ends up in difficult to read, and thus difficult to maintain, code.
A computer language should be set up to facilitate writing code. If "arbitrary" rules are set up within the language such that the resulting code can be written quicker, and is easier to maintain, then that language is not necessarily inferior.
When it comes down to it, all a language needs are basic boolean and arithmetic operators, jumps (gotos, loops, etc), and conditionals (if/then). I believe this was even logically proven (my computer logic courses are too distant now). Java allows for all these. Thus, literally any program that can be written, can be written in a language that supports these features.
That said, I recommend that this author try programming something non-trivial in Java. I have. I've written about 30,000 lines of Java code, as part of a project that sits at about 120,000 lines of code. Java has made this project go several times faster than it would have had it been developed in C++. Some of this is due to the Java architecture. A lot of it has to do with the rich set of built-in packages. Porting is as simple as copying the post-compiled code from machine to machine (it didn't use to be that way, but Java has improved since then).
All I'm saying is that you shouldn't harsh on Java without giving it a chance. Otherwise, you're simply spreading FUD. This is no different than the Micros~1 weenies saying that Linux sucks, since Linux has no support.
Why use Java? Because most people I know are about 4-5x more productive when programming in Java, relative to C++. It's a better designed language.
Yes, it falls down on speed issues. That will change, though.
Unfortunately, there is no AWT support for GJC. Without AWT support, there surely won't be any GTK AWT plaf (pluggable look and feel).
This is a nice solution for server-side java. However, for client-side java, we're still stuck with slow, JIT compiled (or, worse, interpreted) Java.
Anyone know if this circumvents Java's array bounds checking? I suspect it doesn't. When using a good JIT, this is the biggest impediment to fast Java (at least with my code).
Hey, Java is a great programming language. However, until you can turn of bounds checking, and compile code with a GUI, it will remain slow.
W
You can see anything that is under patent. Patents enforce open publication of inventions. They merely require that any production other than for personal use require a license from the patent holder.
If specs for DVD & TV tuners were all patented, then I imagine we'd see drivers almost overnight. Instead, they are treated as Trade Secrets, kind of like the formula for Coca Cola. These restrict sharing much more than patents do.
This is not a defense of Divx, but...
My father-in-law was thinking about buying one because he lives in very rural America. He wanted to be able to go into town, buy 10 or 20 divx movies, then watch them at his leisure. There are no video stores where he lives, so he felt this was a decent compromise.
I told him that www.reel.com rents movies by mail. He bought a DVD.
However, this is one case where a divx *might* be useful.
-dan