I think we need to recognize that MP3 is an established and important technology for digital music. [...] and in this case we have to settle for MP3 with the knowledge that it is truly the appropriate tool for the job at hand.
You are misdiagnosing the problem and that's bad because it won't let us avoid this problem in the future.
MP3 is an aging and mediocre music compression standard. There is nothing essential or noteworthy about it. It caught on because people incorrectly believed it was free. Had people thought through the patent issues from the start, online music could have evolved some other, open standard.
The implication therefore is not to accept patented standards like GIF or MP3 as necessary evils, but for people working on cutting edge technologies (and those are usually people in the academic and open source world) to build their systems around unencumbered standards from the start.
And the same things apply to users. Don't use MP3 or ASP or MS Word or whatever just because you think it's cool. Think about the consequences of what happens if everybody does what you do. If you help a company unnecessarily establish a proprietary standard, you will pay for that many times over in the long run. So, think about the consequences of your actions, even if in the short term something may seem expedient.
Am I going to sympathize with pay-for proprietary developer who has to pay for Qt/Embedded? Hell no!
The problem isn't having to pay for Qt, the problem is that Troll Tech is using various strategies to try and limit competition, from other commercial toolkits as well as free tollkits. Being forced to use Qt is no better than being forced to use MFC.
It already did catch on. So I guess Linux is harmed, and it will only be a matter of time before it joins *BSD in Dying.
Qt is not essential for Linux because we have Gtk+ and lots of other toolkits. If KDE and Qt ever were to win the competition for the Linux desktop, then Linux would be in trouble. As long as they are a sideshow, they don't matter much either way.
And you're saying your iPaq is more responsive with X11 than without?
The iPaq with X11 is more responsive than PocketPC on the identical hardware, and it is also more responsive than the Zaurus running on comparable hardare.
Huh? What handheld does Trolltech sell that they would even be in a position to replace the "standard" Linux windowing system?
Troll Tech has managed to get Qt/Embedded onto the Sharp Zaurus. I'm sure that involved loss leaders, just like getting Qt into KDE.
Second, go try programming a Win32 GUI application without spending any money. If you find a way, please let me know, because I can't think of any.
Well, then you can't have looked very hard. wxWindows, FLTK, and Tcl/Tk are free, and I have used all of them porting applications to Windows. You can use gcc or several other free compilers for programming. There is, of course, also Java and a number of other languages and non-C++-based toolkits.
Go price out competitive crossplatform application frameworks of equal quality.
I have, since before Qt was around. Qt's price and license would have been justified in the 1980's. Today, it isn't--if it weren't for the initial QPL gimmick and the KDE licensing confusion, Qt would never have made it.
It still accounts for a very significant fraction. Like it or not, KDE has caught on.
KDE mostly duplicates what other desktops provide as well. There are no KDE applications that are essential to anything.
Have you ever tried to fit X11 into a handheld then had it be responsive afterwards?
Yup. That's why I use on iPaq. In fact, I have used X11 on machines that are much less powerful than the iPaq.
Which of Trolltech's competitors does not use a framebuffer? What handheld had an X11 system to begin with so that Trolltech could "replace" it?
Troll Tech "replaced" the standard Linux windowing system, X11, with their system, excluding all other toolkits but theirs.
If you're selling proprietary software, then you have to treat Qt/Embeddedlike any other commercial toolkit, and pay for it.
People don't have to pay for developing for Win32, OSX, or Palm. They can use the native APIs freely, or they can use any of a number of cross-platform libraries. Qt is expensive.
But what's worse is that Qt/Embedded restricts choice--whether I want to pay for it or not, I already have applications using other toolkits that work perfectly fine on handhelds. Why would I want to pay off Troll Tech for the privilege of then having to spend even more money to port them?
Hate to break the news to you, but it already did catch on. It's called KDE. I understand it's wildly popular.
Qt still accounts for only a small fraction of Linux GUI applications.
What do you mean integrate X11 more smoothly into OSX?
X11 doesn't come preinstalled on OSX machines, making it difficult to distribute end-user applications. Also, the way X11 is implemented on OSX is unnecessarily inefficient, XDarwin is unnecessarily large, and window management has some rough edges.
You "doubt Apple will succeed with this"? Do you say this because... no GPL apps work with the Quartz GUI?
No. I just think that Quartz and Cocoa are dead in the long run as APIs: nobody needs another proprietary GUI, and Apple doesn't have the market share to force the issue. Most people will be creating Apple applications through Java, various X11 compatibility hacks, various Win32 compatibility hacks, or cross-platform toolkits.
Apple may, of course, still keep Quartz and Cocoa at the core of their system, but that's more of a liability than an advantage.
Yes, I am sure. I have run X11 on 20MHz desktop machines with 4Mbytes of RAM and it worked fine. It runs fine on the Agenda VR. It runs fine on the iPaq using Handhelds Linux. There is even a pure Java implementation that weighs in at around 200kbytes of code.
There is nothing "cumbersome" or "awkward" about X11. It's a window system that keeps applications safe from one another and works with a large number of different toolkits and programming languages. It is highly scalable and can be implemented with almost no memory other than a screen buffer, up to workstations with gigabytes of memory to spare for graphics. Network transparency, pluggable input methods, and a host of other features are icing on the cake.
Qt/Embedded is a bulky and messy design in comparison, largely restricted to a single toolkit, defined in terms of APIs rather than protocols, much more limited in functionality, and more limited in the range of programming languages it can support.
There is plenty wrong with X11--after all, the design is nearly two decades old. But none of the current crop of competitors come even close to improving on it, and certainly not Qt/Embedded.
I doubt it will harm Linux if QT catches on on the desktop.
It would, because it would relegate non-Qt applications to second-rate status: KDE and Qt really don't work as well with non-Qt applications as other X11 desktops. Also, a lot of the vociferous complaints about X11 performance are really the fault of Qt's X11 backend, not X11.
It already has for me since KDE happens to be based on it.
Sure, there are lots of KDE users because KDE is a good desktop. That doesn't mean that using it is good for open source in the long run.
In any case, the situation on the desktop isn't as grave as on handhelds. Qt and non-Qt applications can live side-by-side thanks to the careful design and maturity of X11, even if Qt and KDE make this work less than perfectly. But on handhelds, Qt/Embedded just takes over--there is no way of running X11 applications side-by-side with Qt/Embedded applications.
So where in the GPL does it mention anything about ISOs?
Where did I say that SuSE was "required" to distribute ISOs? I didn't accuse SuSE (or Apple or Troll Tech) of a GPL violation, I merely pointed out that I believe that their policies are bad for open source if they succeed.
How do you come to the conclusion that simple framebuffer access is less efficient than X11? Do you even know how these things work?
Yes, I do. More importantly, I have used X11 on platforms less powerful than what Qt/Embedded requires. There is no technical or efficiency reason for Qt/Embedded--X11 has a longer and better history of running efficiently on embedded devices than Qt/Embedded.
Your monopoly accusation is also preposterous. All of Trolltech's competitors are using the framebuffer as well.
iPaq Linux and most embedded UNIX GUI apps use X11.
That's not what I call a monopoly.
You need to read more carefully: I said Troll Tech has tried to monopolize the market for Linux-based handhelds. They will probably not succeed in the long run because their strategy makes no sense for anybody than themselves: they don't offer anything lots of other toolkits don't offer as well, but Qt/Embedded is considerably more limiting than an X11-based solution. Unfortunately, Troll Tech will do a lot of damage in the process by making platforms like the Zaurus less attractive for commercial development.
Trolltech, in using the GPL, are encouraging more free software.
Linux has become successful because it is a reasonable platform for both free and commercial software and allows people to publish software for it under a wide variety of licenses. Without the ability to create commercial software for Linux without having to pay some sort of tax to one company, Linux would have been a flop. Just because something is, or forces something else to be, GPL doesn't make it good for open source software.
Troll Tech wants to be the gatekeeper and toll taker for commercial applications on Linux. Why should we give a single company that kind of control over GUI applications on Linux?
If you do want to make commercial software, Trolltech's prices are very cheap, especially considering how quickly you can write apps in Qt.
Yeah, right, that's what people say about Windows as well. And with Windows, people don't even have to pay Microsoft to develop commercial apps.
I think the comparison is absolutely silly. Not only does RedHat sponsor a lot of GPL'ed projects, they actually make their ISO images and distribution available for download. I have seen no evidence that RedHat has done anything to threaten open source software.
Here are the companies I'd rather worry about:
SuSE does not make available their distribution as ISOs (do they make their installation and maintenance tools available under the GPL?), although at least you can download the FTP tree.
Troll Tech has tried to monopolize the market for Linux based handhelds by replacing X11 with a framebuffer-based system (which is less efficient to boot). Authors of GPL'ed software using Troll Tech's system are OK, but other kinds of free software, or commercial developers, need to pay more than they would for GUI development on just about any other platform. If Qt/Embedded catches on widely, you can kiss handheld Linux as an affordable commercial platform goodbye. And if Qt catches on on the desktop, it will harm Linux as well.
Apple tries to move developers to a proprietary windowing system, incompatible with open source applications. At least, unlike Troll Tech, you can develop commercial GUI apps for Apple without paying anybody an arm and a leg. I doubt Apple will succeed with this--if they did, it would be bad for open source. More likely, however, they'll just be shooting themselves in the foot, until finally someone integrates X11 into OSX more smoothly than XDarwin.
But the solution is simple: if you don't like what a company is doing, promote and use something different. I wouldn't use Qt or Apple's proprietary windowing system even if I liked their design.
Even if DNA analysis were completely reliable in theory (which it isn't), clerical and experimental error would likely result in a significant rate of false positives. In fact, the procedures used in crime labs seem to be much less strict than those used in scientific labs, and scientific labs are known to make quite a few mistakes.
So, if you put tens of thousands of innocent people into a database and match DNA from random crimes against it, you will fish out innocent people. That's why you should only compare DNA of people who are already suspects on other grounds against crime DNA.
Just do what Microsoft and everybody else is doing: promise the sky, make it flashy, and make some simple programs really easy. By the time your customers figure out that they are hooked on another complex, proprietary library/system that really doesn't work any better than anything else, you have them already hooked.
In different words, as a developer, I view "developer programs" with great suspicion. I don't want to be hooked to some company's product. If you deliver a good implementation of a public standard, I may recommend licensing it for our products. If it's some proprietary tool or non-standard API, forget it.
Perl seems to have been accreting features at a very fast pace since Perl4, and Perl6 doesn't seem to slow that down. Is there ever going to be a significant reduction in features? Perl at this point looks so huge and daunting that I really can't recommend it to newcomers as a scripting language anymore.
Microsoft cites the same statistics when the wind blows their way.
And it is meaningful when a large site that parks domains decides that IIS doesn't fit the bill.
Mac OS X has its rough spots, too. For example, there are no devices for multimedia I/O (you have to use some really messy Carbon APIs). OS X natively supports a much more narrow range of GUI toolkits. OS X's display system is rather slow compared to X11, and X11, while usable, is no speed daemon on it either. OS X has far fewer drivers and kernel extensions than Linux. OS X doesn't even have a journalling file system. And, perhaps most importantly, a lot of free software has not been ported to it. Software installation and upgrading is also much more painful on OS X than on Debian Linux.
Linux core usage is in Internet servers, compute servers, engineering and scientific applications, embedded systems, and systems research. OS X just isn't quite a replacement for those--not quite as functional, not quite as efficient, not quite as cost effective. And OS X's greatest assets--its style, its ease of use for inexperienced users, don't matter as much in those applications.
Where OS X may appeal to Linux users is as a second machine, to replace that Windows machine they use for MS Word. But the sensible main target for OS X advertising is still Windows users.
The dirty secret of big databases is that most people don't know how to program them, how to configure them, and don't need most of the features. And even if they get everything right, they still end up with a very costly and complex solution, a solution that likely doesn't perform very well and needs a special DBA to keep it all running. That's why MySQL is successful.
"Flamebait"? Come on, contribute something constructive. Heise's applications of the SPEC benchmarks show that G4's are not performing much faster than a Pentium at similar clock speed. If you believe that those benchmarks are wrong, describe your reasoning. So far, I have not seen a single criticism of Heise's benchmarks that would alter those conclusions.
Well, the real question is why Apple doesn't submit SPEC benchmarks on well-defined configurations. Instead, they just keep people in the dark and rely on marketing for claims of "supercomputer performance".
Why does the Apple world keep spinning in its own little universe when it comes to benchmarks? We have the SPEC benchmarks, industry-standard benchmarks that are acceptable for a wide variety of processors and applications. It's not only Intel and AMD that compare their processors with it, it's all the RISC manufacturers as well. In fact, SPEC started before Pentium architectures even appeared on the scene. SPEC isn't perfect--no benchmark ever is--but people have a reasonably good idea of how to interpret them.
The only major manufacturer that seems to be missing official SPEC results is Apple. Instead, we get bogus and irreproducible benchmarks like Photoshop and Bryce, both from Apple and from benchmark sites like these.
Why? Is Apple afraid of backing up their claims of "supercomputer performance" with actual facts? Inofficial SPEC benchmarks have shown the G4 not to be all that much faster than a Pentium with similar clock speed.
The founder of Infoseek has been off on this loony scheme for a while. You can find more information here. He has probably been able to sweet-talk his way into more government support; he already had contacts with the FBI. Never mind that there is no published, peer reviewed scientific evidence that this works.
Note that the problem isn't necesssarily with the "brain wave measurements" themselves--it's plausible that you might be able to determine familiarity of a picture from such measurements to some degree of reliability. The problem is that it is completely unclear how reliable any such measurement would be for finding actual terrorists. For example, after you have seen a set of images once during one screening, you will remember them. Next time, they will be familiar (people remember even images that they have seen very briefly basically forever).
Any scheme for identifying terrorists has to have a very low false positive rate because the consequences of misidentification are so serious. Establishing a low false positive rate requires not only extensive testing, but also just a lot of experience with a new technology.
See, the problem with things like these is not that they might work, the problem is that they probably don't work. And because they don't work, a lot of people will get hassled and bothered that really have done nothing wrong.
This kind of voodoo isn't new to the legal system: fingerprints, graphology, fiber analysis, and lie detectors are all suspicious to some degree because they have not been evaluated with the kind of scientific rigor that is necessary. Similarly, DNA tests, where we have a good scientific basis for knowing how reliable they are, are often not carried out with scientific rigor by forensic labs (e.g., the DNA tests during OJ's trial were ridiculously sloppy).
But, you see, the people we elect as our representatives usually are lawyers and administrators, and they have no clue about truth or evidence. When some previously successful entrepreneur, or someone with a big name, or someone who can talk fancy, tells them something, they believe it and pay lots of money for it. Scientists and engineers to them are just more talking heads who can't be very smart because otherwise they wouldn't be satisfied with being scientists and engineers.
J2ME, J2SE and J2EE are very well defined in public specifications.
They are neither "very well defined", nor are the specifications "public" in a sense particularly useful for open source implementations, nor do those define anything that could be considered a "core feature set".
These are backed by comprehensive conformance test suites, the use of which was a significant source of revenue for Sun, and which they are now offering to open source developments to under their "Scholarship Fund" [sun.com].
This is yet another indication that Sun is even more of a control freak than Microsoft, and it makes Java an unattractive target for open source efforts.
Besides, as a Java developer, I don't give a damn about Sun's conformance tests. If an open source implementation attempts full conformance with, say, J2SE, then the conformance tests consist of the programs end users like myself run on both platforms. Conformance with Sun's test suite is neither necessary nor sufficient.
National ID cards should actually have less information on them than current driver's licenses: they should have name, ID number, photo, and, possibly, some secure, one-way biometric identifier (i.e., an identifier that can't easily be used to fake the biometric signal). It might make sense to put a bit on there that indicates whether the person is permitted to work in the US and whether the person is a US citizen.
There should be no information on a national ID card about medical history, organ donation, marital status, driving history, or anything else. All information should be human readable, and there should be no writable content. Anybody with a right to know should keep their own database of such information and should be required to comply with strict privacy regulations.
Unfortunately, the hysteria about national ID cards on the one hand, and the incompetent efforts at designing them on the other hand, just keep degrading our privacy. Foes of national ID cards condemn us to continued reliance of indentification methods that both expose too much personal information (driver's license, social security) and are unreliable and highly susceptible to identity theft. And the folks now influential in the federal government seem to think that a national ID card system should satisfy every pipe dream of a neo-fascist world view in which the state controls and knows everything.
We need a solid national ID system, and we need strong privacy legislation. Anything less than both of those condemns Americans to continued invasions of privacy from crooks, companies, and the government.
There are a bunch of open projects that implement bits and pieces of the Java platform. But that's not the same as implementing Java, and there is no standard or agreement on what constitutes an implementation of a core Java feature set.
As for GCJ, I have my doubts it is, or will ever become, a replacement for Sun Java. What makes Java do really well in practice is the good JIT that comes with Sun's implementation. The existence of such a JIT lets Java get by without a lot of the declarations that exist in C++ and still perform very well. GCJ's approach to compiling Java just isn't all that competitive with that.
One used to be able to say that the US reserved privacy protections, due process, and the rule of law for its own citizens, while blatantly disregarding them for foreigners. But these days, the US increasingly ignores such niceties for everybody, nondiscriminatorily.
Let's hope that other nations will help reign in the US law enforcement and legal system, for the benefit of everybody in the world.
Slashdot Mirror
You are misdiagnosing the problem and that's bad because it won't let us avoid this problem in the future.
MP3 is an aging and mediocre music compression standard. There is nothing essential or noteworthy about it. It caught on because people incorrectly believed it was free. Had people thought through the patent issues from the start, online music could have evolved some other, open standard.
The implication therefore is not to accept patented standards like GIF or MP3 as necessary evils, but for people working on cutting edge technologies (and those are usually people in the academic and open source world) to build their systems around unencumbered standards from the start.
And the same things apply to users. Don't use MP3 or ASP or MS Word or whatever just because you think it's cool. Think about the consequences of what happens if everybody does what you do. If you help a company unnecessarily establish a proprietary standard, you will pay for that many times over in the long run. So, think about the consequences of your actions, even if in the short term something may seem expedient.
The problem isn't having to pay for Qt, the problem is that Troll Tech is using various strategies to try and limit competition, from other commercial toolkits as well as free tollkits. Being forced to use Qt is no better than being forced to use MFC.
It already did catch on. So I guess Linux is harmed, and it will only be a matter of time before it joins *BSD in Dying.
Qt is not essential for Linux because we have Gtk+ and lots of other toolkits. If KDE and Qt ever were to win the competition for the Linux desktop, then Linux would be in trouble. As long as they are a sideshow, they don't matter much either way.
The iPaq with X11 is more responsive than PocketPC on the identical hardware, and it is also more responsive than the Zaurus running on comparable hardare.
Huh? What handheld does Trolltech sell that they would even be in a position to replace the "standard" Linux windowing system?
Troll Tech has managed to get Qt/Embedded onto the Sharp Zaurus. I'm sure that involved loss leaders, just like getting Qt into KDE.
Second, go try programming a Win32 GUI application without spending any money. If you find a way, please let me know, because I can't think of any.
Well, then you can't have looked very hard. wxWindows, FLTK, and Tcl/Tk are free, and I have used all of them porting applications to Windows. You can use gcc or several other free compilers for programming. There is, of course, also Java and a number of other languages and non-C++-based toolkits.
Go price out competitive crossplatform application frameworks of equal quality.
I have, since before Qt was around. Qt's price and license would have been justified in the 1980's. Today, it isn't--if it weren't for the initial QPL gimmick and the KDE licensing confusion, Qt would never have made it.
It still accounts for a very significant fraction. Like it or not, KDE has caught on.
KDE mostly duplicates what other desktops provide as well. There are no KDE applications that are essential to anything.
Yup. That's why I use on iPaq. In fact, I have used X11 on machines that are much less powerful than the iPaq.
Which of Trolltech's competitors does not use a framebuffer? What handheld had an X11 system to begin with so that Trolltech could "replace" it?
Troll Tech "replaced" the standard Linux windowing system, X11, with their system, excluding all other toolkits but theirs.
If you're selling proprietary software, then you have to treat Qt/Embeddedlike any other commercial toolkit, and pay for it.
People don't have to pay for developing for Win32, OSX, or Palm. They can use the native APIs freely, or they can use any of a number of cross-platform libraries. Qt is expensive.
But what's worse is that Qt/Embedded restricts choice--whether I want to pay for it or not, I already have applications using other toolkits that work perfectly fine on handhelds. Why would I want to pay off Troll Tech for the privilege of then having to spend even more money to port them?
Hate to break the news to you, but it already did catch on. It's called KDE. I understand it's wildly popular.
Qt still accounts for only a small fraction of Linux GUI applications.
X11 doesn't come preinstalled on OSX machines, making it difficult to distribute end-user applications. Also, the way X11 is implemented on OSX is unnecessarily inefficient, XDarwin is unnecessarily large, and window management has some rough edges.
You "doubt Apple will succeed with this"? Do you say this because... no GPL apps work with the Quartz GUI?
No. I just think that Quartz and Cocoa are dead in the long run as APIs: nobody needs another proprietary GUI, and Apple doesn't have the market share to force the issue. Most people will be creating Apple applications through Java, various X11 compatibility hacks, various Win32 compatibility hacks, or cross-platform toolkits.
Apple may, of course, still keep Quartz and Cocoa at the core of their system, but that's more of a liability than an advantage.
There is nothing "cumbersome" or "awkward" about X11. It's a window system that keeps applications safe from one another and works with a large number of different toolkits and programming languages. It is highly scalable and can be implemented with almost no memory other than a screen buffer, up to workstations with gigabytes of memory to spare for graphics. Network transparency, pluggable input methods, and a host of other features are icing on the cake.
Qt/Embedded is a bulky and messy design in comparison, largely restricted to a single toolkit, defined in terms of APIs rather than protocols, much more limited in functionality, and more limited in the range of programming languages it can support.
There is plenty wrong with X11--after all, the design is nearly two decades old. But none of the current crop of competitors come even close to improving on it, and certainly not Qt/Embedded.
It would, because it would relegate non-Qt applications to second-rate status: KDE and Qt really don't work as well with non-Qt applications as other X11 desktops. Also, a lot of the vociferous complaints about X11 performance are really the fault of Qt's X11 backend, not X11.
It already has for me since KDE happens to be based on it.
Sure, there are lots of KDE users because KDE is a good desktop. That doesn't mean that using it is good for open source in the long run.
In any case, the situation on the desktop isn't as grave as on handhelds. Qt and non-Qt applications can live side-by-side thanks to the careful design and maturity of X11, even if Qt and KDE make this work less than perfectly. But on handhelds, Qt/Embedded just takes over--there is no way of running X11 applications side-by-side with Qt/Embedded applications.
Where did I say that SuSE was "required" to distribute ISOs? I didn't accuse SuSE (or Apple or Troll Tech) of a GPL violation, I merely pointed out that I believe that their policies are bad for open source if they succeed.
How do you come to the conclusion that simple framebuffer access is less efficient than X11? Do you even know how these things work?
Yes, I do. More importantly, I have used X11 on platforms less powerful than what Qt/Embedded requires. There is no technical or efficiency reason for Qt/Embedded--X11 has a longer and better history of running efficiently on embedded devices than Qt/Embedded.
Your monopoly accusation is also preposterous. All of Trolltech's competitors are using the framebuffer as well.
iPaq Linux and most embedded UNIX GUI apps use X11.
That's not what I call a monopoly.
You need to read more carefully: I said Troll Tech has tried to monopolize the market for Linux-based handhelds. They will probably not succeed in the long run because their strategy makes no sense for anybody than themselves: they don't offer anything lots of other toolkits don't offer as well, but Qt/Embedded is considerably more limiting than an X11-based solution. Unfortunately, Troll Tech will do a lot of damage in the process by making platforms like the Zaurus less attractive for commercial development.
Trolltech, in using the GPL, are encouraging more free software.
Linux has become successful because it is a reasonable platform for both free and commercial software and allows people to publish software for it under a wide variety of licenses. Without the ability to create commercial software for Linux without having to pay some sort of tax to one company, Linux would have been a flop. Just because something is, or forces something else to be, GPL doesn't make it good for open source software.
Troll Tech wants to be the gatekeeper and toll taker for commercial applications on Linux. Why should we give a single company that kind of control over GUI applications on Linux?
If you do want to make commercial software, Trolltech's prices are very cheap, especially considering how quickly you can write apps in Qt.
Yeah, right, that's what people say about Windows as well. And with Windows, people don't even have to pay Microsoft to develop commercial apps.
Here are the companies I'd rather worry about:
But the solution is simple: if you don't like what a company is doing, promote and use something different. I wouldn't use Qt or Apple's proprietary windowing system even if I liked their design.
So, if you put tens of thousands of innocent people into a database and match DNA from random crimes against it, you will fish out innocent people. That's why you should only compare DNA of people who are already suspects on other grounds against crime DNA.
In different words, as a developer, I view "developer programs" with great suspicion. I don't want to be hooked to some company's product. If you deliver a good implementation of a public standard, I may recommend licensing it for our products. If it's some proprietary tool or non-standard API, forget it.
Perl seems to have been accreting features at a very fast pace since Perl4, and Perl6 doesn't seem to slow that down. Is there ever going to be a significant reduction in features? Perl at this point looks so huge and daunting that I really can't recommend it to newcomers as a scripting language anymore.
Microsoft cites the same statistics when the wind blows their way. And it is meaningful when a large site that parks domains decides that IIS doesn't fit the bill.
Linux core usage is in Internet servers, compute servers, engineering and scientific applications, embedded systems, and systems research. OS X just isn't quite a replacement for those--not quite as functional, not quite as efficient, not quite as cost effective. And OS X's greatest assets--its style, its ease of use for inexperienced users, don't matter as much in those applications.
Where OS X may appeal to Linux users is as a second machine, to replace that Windows machine they use for MS Word. But the sensible main target for OS X advertising is still Windows users.
The dirty secret of big databases is that most people don't know how to program them, how to configure them, and don't need most of the features. And even if they get everything right, they still end up with a very costly and complex solution, a solution that likely doesn't perform very well and needs a special DBA to keep it all running. That's why MySQL is successful.
"Flamebait"? Come on, contribute something constructive. Heise's applications of the SPEC benchmarks show that G4's are not performing much faster than a Pentium at similar clock speed. If you believe that those benchmarks are wrong, describe your reasoning. So far, I have not seen a single criticism of Heise's benchmarks that would alter those conclusions.
By "MHz myth", you must be referring to the fact that G4's are not performing much faster than a Pentium of similar clock speed.
Apple makes nice machines and software, but they really do need to get their act together on performance.
Well, the real question is why Apple doesn't submit SPEC benchmarks on well-defined configurations. Instead, they just keep people in the dark and rely on marketing for claims of "supercomputer performance".
The only major manufacturer that seems to be missing official SPEC results is Apple. Instead, we get bogus and irreproducible benchmarks like Photoshop and Bryce, both from Apple and from benchmark sites like these.
Why? Is Apple afraid of backing up their claims of "supercomputer performance" with actual facts? Inofficial SPEC benchmarks have shown the G4 not to be all that much faster than a Pentium with similar clock speed.
Note that the problem isn't necesssarily with the "brain wave measurements" themselves--it's plausible that you might be able to determine familiarity of a picture from such measurements to some degree of reliability. The problem is that it is completely unclear how reliable any such measurement would be for finding actual terrorists. For example, after you have seen a set of images once during one screening, you will remember them. Next time, they will be familiar (people remember even images that they have seen very briefly basically forever).
Any scheme for identifying terrorists has to have a very low false positive rate because the consequences of misidentification are so serious. Establishing a low false positive rate requires not only extensive testing, but also just a lot of experience with a new technology.
This kind of voodoo isn't new to the legal system: fingerprints, graphology, fiber analysis, and lie detectors are all suspicious to some degree because they have not been evaluated with the kind of scientific rigor that is necessary. Similarly, DNA tests, where we have a good scientific basis for knowing how reliable they are, are often not carried out with scientific rigor by forensic labs (e.g., the DNA tests during OJ's trial were ridiculously sloppy).
But, you see, the people we elect as our representatives usually are lawyers and administrators, and they have no clue about truth or evidence. When some previously successful entrepreneur, or someone with a big name, or someone who can talk fancy, tells them something, they believe it and pay lots of money for it. Scientists and engineers to them are just more talking heads who can't be very smart because otherwise they wouldn't be satisfied with being scientists and engineers.
They are neither "very well defined", nor are the specifications "public" in a sense particularly useful for open source implementations, nor do those define anything that could be considered a "core feature set".
These are backed by comprehensive conformance test suites, the use of which was a significant source of revenue for Sun, and which they are now offering to open source developments to under their "Scholarship Fund" [sun.com].
This is yet another indication that Sun is even more of a control freak than Microsoft, and it makes Java an unattractive target for open source efforts.
Besides, as a Java developer, I don't give a damn about Sun's conformance tests. If an open source implementation attempts full conformance with, say, J2SE, then the conformance tests consist of the programs end users like myself run on both platforms. Conformance with Sun's test suite is neither necessary nor sufficient.
There should be no information on a national ID card about medical history, organ donation, marital status, driving history, or anything else. All information should be human readable, and there should be no writable content. Anybody with a right to know should keep their own database of such information and should be required to comply with strict privacy regulations.
Unfortunately, the hysteria about national ID cards on the one hand, and the incompetent efforts at designing them on the other hand, just keep degrading our privacy. Foes of national ID cards condemn us to continued reliance of indentification methods that both expose too much personal information (driver's license, social security) and are unreliable and highly susceptible to identity theft. And the folks now influential in the federal government seem to think that a national ID card system should satisfy every pipe dream of a neo-fascist world view in which the state controls and knows everything.
We need a solid national ID system, and we need strong privacy legislation. Anything less than both of those condemns Americans to continued invasions of privacy from crooks, companies, and the government.
As for GCJ, I have my doubts it is, or will ever become, a replacement for Sun Java. What makes Java do really well in practice is the good JIT that comes with Sun's implementation. The existence of such a JIT lets Java get by without a lot of the declarations that exist in C++ and still perform very well. GCJ's approach to compiling Java just isn't all that competitive with that.
Let's hope that other nations will help reign in the US law enforcement and legal system, for the benefit of everybody in the world.