Tax dollars paying for software should be released under a BSD or public domain type license.
I'd prefer that my tax dollars be spent in a way that is going to solve the problem most cost effectively. There are many cases where that might involve using GPL software for all or a portion of a particular need. If my tax dollars have to be spent then I expect them to go as far as possible. Paying hundreds of thousands of dollars for something that could be had virtually for free is NOT an efficient way to spend my tax dollars.
I have nothing against BSD style licenses or other non-GPL licenses. However, I don't see what avoiding GPL software non-discriminately does for anyone? And I don't care one bit about the business that was outcompeted by GPL software. If they have a problem then they should create a product that is worth what they are charging for it. Like I said before, commercial software can and will beat out OSS in terms of cost/performance under certain circumstances. GPL makes them fight harder to do that, and the extra competition is good for everyone.
Competition is good. I believe in free markets and I think free software has a compelling argument in such an environment. Namely, "Can it do what we need it to do without a lot of extra overhead given that it will cost us less up front and give us more flexibility in the long run." Smart proponents of OSS take this approach when comparing open source tools to their commercial competitors.
Unfortunately, the recommendations of Intellect appear to go to far. Saying that GPL should be avoided is undefensible. Saying that it should be weighed against commercial software to determine what the most effective solution is for a given situation is a better position. The fact of the matter is that OSS doesn't always come out ahead in side-by-side comparisons.
IMO, this just seems like lashback against the kind of move that other governments are making in saying that OSS should be PREFERRED over commercial software. As a proponent of OSS I am perfectly happy to compete on a level playing field. Shift too far one way or the other and the system starts to break.
I almost posted that IBM should just give in and buy SCO in an earlier one of these threads, but then I thought about it a little more...
SCO is sending all these letters to corporate Linux users saying, "Stay away from Linux, because it violates our IP." If IBM buys SCO and open sources Unix it might prevent any further legal action, but it also might appear to lend some credibility to SCO's claims. Thus IBM is a hero to the average Linux geek, but the corporate world still sees the community as a bunch of thieves who got bailed out by the deep pockets of IBM.
Therefore, let this go to court and let IBM's lawyers prove that SCO is full of it to begin with. That way the Linux community is vindicated and the only people who look like they've done anything wrong are SCO.
JBoss is still around and will be for a long time. What is interesting about this is not the impact on the JBoss app server (virtually zero, IMO) but the impact on the JBoss Group's attempt to turn their skills into a money making enterprise. Open source works, we know that, but what is interesting is that so many novel attempts have been made to turn open source into a way to make money and most seem to dismally fail. This is yet another example of that.
Everyone lost.
We could have ALL (minus 1) had the benefit of this software for free.
The very first person would have to purchase it, but then could freely redistribute to the world.
I hope this is not the argument that is used in court, because I think it misrepresents the intent of the GPL. Claiming that everyone in the community was damaged because they didn't get the benefit of this software without paying for it sounds a lot like the viral GPL that Microsoft warned about.
I think the more relevant point is that by using other people's work as the basis of their software they entered into a contract which said that others could do the same. They have an obligation under that contract to make their work available for others to learn from, adapt, and improve upon.
The intention of the GPL is not, IMO, to allow consumers to have access to other people's work for free. "Free as in beer" access to software is a natural consequence of the GPL that we sometimes benefit from. It is not a requirement nor is it the intent.
...we also lost the ability to improve the software.
Anyone who wanted a feature that was not added lost out.
That's the relevent point! Take that one to court but leave the first part about everyone getting it for free (As in beer) out.
The concerns of the thousands of Americans whose livelihoods depend on intellectual property protection are not being fully debated or addressed
What about the concerns of millions of Americans whose livelihoods depend on free access to technology? Open source software creates jobs, because it creates the opportunity for someone with an idea to build a business without having to have hundreds of thousands of dollars to invest in software. For instance, I have started a software development business that I would not have been able to afford to start without free software:
My server is a dual PIII running Gentoo Linux (savings: Windows 2000 Advanced Server $999)
I use JBoss 3.2 and Tomcat 4.1.24 for my J2EE applications (savings: Weblogic $90,000)
Emacs for code development, Dia for modeling, Ant for code generation, compilation, and deployment (savings: JBuilder Enterprise $3,500)
CVS for source control and change management (Savings: Starteam, couldn't find a price but I know it's in the thousands)
MySQL database server (savings: Oracle 9i $40,000)
I am sure I could come up with a couple hundred thousand more if I really thought about it. The point is that I don't have the money for any of that. If things go well I plan to hire several developers over the next year or two. That's as many as ten jobs that wouldn't exist if it weren't for free software.
Seriously, the argument that free software is "A threat to America's innovation and security," makes about as much sense as the one that says that giving rich people a tax break will lead to more jobs. They neglect to mention that the vast majority of the jobs are with large companies that already pay almost zero taxes. Most of the tax cut goes to rich people who will stow it away so that they are richer rather than companies with any significant number of jobs or middleclass taxpayers who do the bulk of the consuming that drives the economy.
What these people need to do is get a clue. The record companies are going to go out of business if they keep doing things the way they have always done them. Since when is it good business to whine and moan until someone legislates away our freedom rather than innovating and coming up with a viable new way to make money? The reality is that these businesses have to change their way of thinking or they will die. The only real question is how much pain can they put the rest of us through before they do finally die. Can they successfully destroy the American way of life first? They're trying.
As a software geek I have one question about Opera 7: Did they improve the W3C DOM support which has been lacking in prior versions? I am mostly a back end Java programmer, but occasionally I am asked to write web pages and Opera compatibility is often a problem with DHTML because they support a relatively small subset of W3C DOM and lie about browser versions in the HTTP headers.
Excellent post, I agreed with everything you said. Although I would add that a lot has been done to improve synchronization and garbage collection in 1.4.x and the article might have taken that for granted.
Some bigger issues for server-side design: be careful... how you use persistence (such as JDO).
I have spent many many hours optimizing crappy persistence code. It has been my experience that JDBC code is the biggest source of performance problems on most Java projects. However, the amount of time I spend fixing performance problems in JDBC code has dropped to almost zero since I have been using JDO. There are really only a couple of rules to follow with JDO:
Do non-transactional reads whenever possible.
Perform writes asynchronously whenever possible.
When using JDO with J2EE wrap the JDO code in a session facade (Or message facade) and use container managed transactions.
Other than that it has been my experience that JDO code performs very well and has very few opportunities for mishaps.
Java isn't slow. In fact, for comparable tasks it is similar in speed to C/C++. A good C/C++ programmer can increase the speed of his code beyond what Java is capable of with intelligent use of inline assembly. A bad C/C++ programmer can create code that is significantly slower than the equivalent Java code by doing stupid things that aren't even possible in Java.
There are two areas where Java performance historically lags. The first is GUI applications. The desire to be portable coupled with the complexity of the native windowing toolkits on popular OSes has led to a lot of bloat in the Java GUI toolkits. This seems to be improving all of the time, but none of the existing GUI toolkits are equal to a native application in performance.
The second historically bad area for Java performance is in the browser. In the early days of Java applets were seen as a way to do new things in the browser that had never been done before. Unfortunately, the stuff was buggy, the browsers lacked consistent support, and load times were often unacceptable. Since then technologies like JNLP have improved network load time and browser compatibility has improved (Both with and without Sun's plugin.) However, there is still some slow, buggy applet code out there, and there is some stiff competition from the likes of Flash.
I am a J2EE developer, and none of this particularly matters to me. I don't write GUIs or applets when I can avoid it. To be honest, if I had to write a GUI I'd need a real good reason not to write it in C. And, I'd prefer to keep as much of my web code server side as I can and use Javascript for anything that absolutely has to be on the client side.
I write enterprise applications, and Java is great for what I do. Load time doesn't matter much, because the server stays up with the app running all of the time. Memory footprint isn't much of an issue either, because I usually have dedicated hardware (However there are Java tools and APIs specifically designed for keeping a tiny memory footprint if that is what floats your boat.) What does matter is that Java provides a great set of APIs for doing things like distributed transaction management; interacting with a variety of databases, naming services, and other application resources; and object persistence. What also matters is that performance can be made to be consistent through a wide range of loads. I don't so much care how long it takes for one client to interact with my system, so long as the time for that one client is reasonable and the time for many, many simultaneous clients is also reasonable. That level of scalability is easy to achieve with J2EE. I don't know of any other platform I would say this about. I also care about security. Java makes decent security easy and great security possible. I don't know of any other platform where an acceptable level of security can be achieved without putting a lot of thought into it. Finally, I care that I can write pure object-oriented designs in Java without getting caught in a lot of murky areas of the language. Not that there aren't any murky areas to Java (every language has them,) but with Java it is relatively easy to keep the messy stuff out of my domain model and use all of the hallmarks of good OO design like patterns and layers.
To sum up: Java isn't slow. C/C++ is better than Java for GUIs. Java is great for certain tasks like writing enterprise software. If I could use any language I wanted it would be Perl, but it doesn't always make sense to do so. Sometimes it makes the most sense to use C/C++ and other times it makes the most sense to use Java.
This is not news. Cars are specifically engineered so that certain systems are "maintenance parts" and fail at predictable intervals. This is so that they will fail predictably rather than catestrophically when not properly maintained, or so the theory goes. The fact is that cars still fail catestrophically, and "maintenance parts" are just another way for the car manufacturer to gouge the consumer. Particularly when many maintenance parts are expensive, take a lot of labor to replace, and are manufactured through exclusive partnerships with parts companies. In addition, the engineering practice is to reduce the cost of maintenance parts as much as possible while keeping the life of the parts regular and predictable. This is not a savings that is passed on to the consumer.
It's a sad day when companies start to believe that suing for IPR is a better business model than providing quality products and services.
Thanks RIAA, MPAA, SCO, we'll all be joining you in hell soon.
Actually for those of us who use the open source tool XDoclet metadata is not new, it just wasn't a language feature before. In fact the syntax with the '@' symbol is clearly like XDoclet and Middlegen and the stated purpose is the same - to allow declarative programming without the need for several source files containing interfaces required by the specs, etc.
When compiled pre-increment takes one less instruction that post-increment. This is true in pretty much any language, the reason having to do with the fact that in post increment we have to care about the value before the increment as well as the value after, where as in pre-increment we can discard the value before the increment.
Depending on how the compiler is implemented this really might not matter at all, but it is a good habit to prefer pre-increment. Plus, since good programming style in any language wants you to avoid side-effects pre or post increment should be semantically equivalent in your code. i.e.
this: ++c;
is slightly better than this: c++;
but if we never do this crap: a = ++b - c--;
then we don't have to worry about it.
Sun's strongest market is in the mid to high end server space. The most important innovations they have made there in the past couple years include:
1) NFS and NIS+
2) x86 Solaris
These are excellent technologies and should be applauded. However, they effectively give Sun's customers an elegant and relatively painless way out. Using Sun's own technology a company which was previously dependent on Solaris and SPARC hardware can switch to commodity hardware and linux first on the desktop, then on the low to mid end server, and finally on the high end by replacing SMP SPARC systems with Linux clusters.
Java is not going anywhere, but it also fails to make Sun any real money. And, despite some of the silly bickering between Sun and Microsoft over Java, Java actually makes money for Microsoft. A lot of Java development happens with Windows both on the desktop and the server, and Java's vendor independent persistence technology makes Microsoft SQL Server as attractive a platform as any other (Microsoft caters to this by providing free JDBC drivers while at the same time maintaining vendor lock-in for.NET persistence.)
Perhaps they didn't go after SuSE because they are partners along with TurboLinux in the United Linux thingy... and they all want Redhat to join in the worst kind of way. Seriously, IBM represents a big market share in the proprietary Unix space, and that is what SCO is gunning for. If they can get IBM in trouble for contributing to a technology from which they also benefit (Linux) then that is just a bonus.
Slashdot Mirror
I'd prefer that my tax dollars be spent in a way that is going to solve the problem most cost effectively. There are many cases where that might involve using GPL software for all or a portion of a particular need. If my tax dollars have to be spent then I expect them to go as far as possible. Paying hundreds of thousands of dollars for something that could be had virtually for free is NOT an efficient way to spend my tax dollars.
I have nothing against BSD style licenses or other non-GPL licenses. However, I don't see what avoiding GPL software non-discriminately does for anyone? And I don't care one bit about the business that was outcompeted by GPL software. If they have a problem then they should create a product that is worth what they are charging for it. Like I said before, commercial software can and will beat out OSS in terms of cost/performance under certain circumstances. GPL makes them fight harder to do that, and the extra competition is good for everyone.
Unfortunately, the recommendations of Intellect appear to go to far. Saying that GPL should be avoided is undefensible. Saying that it should be weighed against commercial software to determine what the most effective solution is for a given situation is a better position. The fact of the matter is that OSS doesn't always come out ahead in side-by-side comparisons.
IMO, this just seems like lashback against the kind of move that other governments are making in saying that OSS should be PREFERRED over commercial software. As a proponent of OSS I am perfectly happy to compete on a level playing field. Shift too far one way or the other and the system starts to break.
I almost posted that IBM should just give in and buy SCO in an earlier one of these threads, but then I thought about it a little more...
SCO is sending all these letters to corporate Linux users saying, "Stay away from Linux, because it violates our IP." If IBM buys SCO and open sources Unix it might prevent any further legal action, but it also might appear to lend some credibility to SCO's claims. Thus IBM is a hero to the average Linux geek, but the corporate world still sees the community as a bunch of thieves who got bailed out by the deep pockets of IBM.
Therefore, let this go to court and let IBM's lawyers prove that SCO is full of it to begin with. That way the Linux community is vindicated and the only people who look like they've done anything wrong are SCO.
JBoss is still around and will be for a long time. What is interesting about this is not the impact on the JBoss app server (virtually zero, IMO) but the impact on the JBoss Group's attempt to turn their skills into a money making enterprise. Open source works, we know that, but what is interesting is that so many novel attempts have been made to turn open source into a way to make money and most seem to dismally fail. This is yet another example of that.
I never thought it was possible for a tech company to become so loathesome so quickly. Microsoft is finally dethroned; there is a new emperor of evil!
The interval is not major. The fourth note of a major scale is the Lydian mode whose corresponding chord is major.
We are dangerously off topic and unquestionably going to hell.
Since F# is the major fourth of C# major, I predict that G# will become the next dominant language.
I hope this is not the argument that is used in court, because I think it misrepresents the intent of the GPL. Claiming that everyone in the community was damaged because they didn't get the benefit of this software without paying for it sounds a lot like the viral GPL that Microsoft warned about.
I think the more relevant point is that by using other people's work as the basis of their software they entered into a contract which said that others could do the same. They have an obligation under that contract to make their work available for others to learn from, adapt, and improve upon.
The intention of the GPL is not, IMO, to allow consumers to have access to other people's work for free. "Free as in beer" access to software is a natural consequence of the GPL that we sometimes benefit from. It is not a requirement nor is it the intent.
That's the relevent point! Take that one to court but leave the first part about everyone getting it for free (As in beer) out.
From the article:
What about the concerns of millions of Americans whose livelihoods depend on free access to technology? Open source software creates jobs, because it creates the opportunity for someone with an idea to build a business without having to have hundreds of thousands of dollars to invest in software. For instance, I have started a software development business that I would not have been able to afford to start without free software:
I am sure I could come up with a couple hundred thousand more if I really thought about it. The point is that I don't have the money for any of that. If things go well I plan to hire several developers over the next year or two. That's as many as ten jobs that wouldn't exist if it weren't for free software.
Seriously, the argument that free software is "A threat to America's innovation and security," makes about as much sense as the one that says that giving rich people a tax break will lead to more jobs. They neglect to mention that the vast majority of the jobs are with large companies that already pay almost zero taxes. Most of the tax cut goes to rich people who will stow it away so that they are richer rather than companies with any significant number of jobs or middleclass taxpayers who do the bulk of the consuming that drives the economy.
What these people need to do is get a clue. The record companies are going to go out of business if they keep doing things the way they have always done them. Since when is it good business to whine and moan until someone legislates away our freedom rather than innovating and coming up with a viable new way to make money? The reality is that these businesses have to change their way of thinking or they will die. The only real question is how much pain can they put the rest of us through before they do finally die. Can they successfully destroy the American way of life first? They're trying.
Looks like the support has improved but there are still some areas that need work.
As a software geek I have one question about Opera 7: Did they improve the W3C DOM support which has been lacking in prior versions? I am mostly a back end Java programmer, but occasionally I am asked to write web pages and Opera compatibility is often a problem with DHTML because they support a relatively small subset of W3C DOM and lie about browser versions in the HTTP headers.
Excellent post, I agreed with everything you said. Although I would add that a lot has been done to improve synchronization and garbage collection in 1.4.x and the article might have taken that for granted.
I have spent many many hours optimizing crappy persistence code. It has been my experience that JDBC code is the biggest source of performance problems on most Java projects. However, the amount of time I spend fixing performance problems in JDBC code has dropped to almost zero since I have been using JDO. There are really only a couple of rules to follow with JDO:
- Do non-transactional reads whenever possible.
- Perform writes asynchronously whenever possible.
- When using JDO with J2EE wrap the JDO code in a session facade (Or message facade) and use container managed transactions.
Other than that it has been my experience that JDO code performs very well and has very few opportunities for mishaps.Java isn't slow. In fact, for comparable tasks it is similar in speed to C/C++. A good C/C++ programmer can increase the speed of his code beyond what Java is capable of with intelligent use of inline assembly. A bad C/C++ programmer can create code that is significantly slower than the equivalent Java code by doing stupid things that aren't even possible in Java.
There are two areas where Java performance historically lags. The first is GUI applications. The desire to be portable coupled with the complexity of the native windowing toolkits on popular OSes has led to a lot of bloat in the Java GUI toolkits. This seems to be improving all of the time, but none of the existing GUI toolkits are equal to a native application in performance.
The second historically bad area for Java performance is in the browser. In the early days of Java applets were seen as a way to do new things in the browser that had never been done before. Unfortunately, the stuff was buggy, the browsers lacked consistent support, and load times were often unacceptable. Since then technologies like JNLP have improved network load time and browser compatibility has improved (Both with and without Sun's plugin.) However, there is still some slow, buggy applet code out there, and there is some stiff competition from the likes of Flash.
I am a J2EE developer, and none of this particularly matters to me. I don't write GUIs or applets when I can avoid it. To be honest, if I had to write a GUI I'd need a real good reason not to write it in C. And, I'd prefer to keep as much of my web code server side as I can and use Javascript for anything that absolutely has to be on the client side.
I write enterprise applications, and Java is great for what I do. Load time doesn't matter much, because the server stays up with the app running all of the time. Memory footprint isn't much of an issue either, because I usually have dedicated hardware (However there are Java tools and APIs specifically designed for keeping a tiny memory footprint if that is what floats your boat.) What does matter is that Java provides a great set of APIs for doing things like distributed transaction management; interacting with a variety of databases, naming services, and other application resources; and object persistence. What also matters is that performance can be made to be consistent through a wide range of loads. I don't so much care how long it takes for one client to interact with my system, so long as the time for that one client is reasonable and the time for many, many simultaneous clients is also reasonable. That level of scalability is easy to achieve with J2EE. I don't know of any other platform I would say this about. I also care about security. Java makes decent security easy and great security possible. I don't know of any other platform where an acceptable level of security can be achieved without putting a lot of thought into it. Finally, I care that I can write pure object-oriented designs in Java without getting caught in a lot of murky areas of the language. Not that there aren't any murky areas to Java (every language has them,) but with Java it is relatively easy to keep the messy stuff out of my domain model and use all of the hallmarks of good OO design like patterns and layers.
To sum up: Java isn't slow. C/C++ is better than Java for GUIs. Java is great for certain tasks like writing enterprise software. If I could use any language I wanted it would be Perl, but it doesn't always make sense to do so. Sometimes it makes the most sense to use C/C++ and other times it makes the most sense to use Java.
This is not news. Cars are specifically engineered so that certain systems are "maintenance parts" and fail at predictable intervals. This is so that they will fail predictably rather than catestrophically when not properly maintained, or so the theory goes. The fact is that cars still fail catestrophically, and "maintenance parts" are just another way for the car manufacturer to gouge the consumer. Particularly when many maintenance parts are expensive, take a lot of labor to replace, and are manufactured through exclusive partnerships with parts companies. In addition, the engineering practice is to reduce the cost of maintenance parts as much as possible while keeping the life of the parts regular and predictable. This is not a savings that is passed on to the consumer.
It's a sad day when companies start to believe that suing for IPR is a better business model than providing quality products and services. Thanks RIAA, MPAA, SCO, we'll all be joining you in hell soon.
That is part of what is great about open source. What greater compliment than to have your code stolen by the owners of the language?
Actually for those of us who use the open source tool XDoclet metadata is not new, it just wasn't a language feature before. In fact the syntax with the '@' symbol is clearly like XDoclet and Middlegen and the stated purpose is the same - to allow declarative programming without the need for several source files containing interfaces required by the specs, etc.
When compiled pre-increment takes one less instruction that post-increment. This is true in pretty much any language, the reason having to do with the fact that in post increment we have to care about the value before the increment as well as the value after, where as in pre-increment we can discard the value before the increment.
Depending on how the compiler is implemented this really might not matter at all, but it is a good habit to prefer pre-increment. Plus, since good programming style in any language wants you to avoid side-effects pre or post increment should be semantically equivalent in your code. i.e.
this: ++c;
is slightly better than this: c++;
but if we never do this crap: a = ++b - c--;
then we don't have to worry about it.
He's a security expert... so ssh
Sun's strongest market is in the mid to high end server space. The most important innovations they have made there in the past couple years include: 1) NFS and NIS+ 2) x86 Solaris These are excellent technologies and should be applauded. However, they effectively give Sun's customers an elegant and relatively painless way out. Using Sun's own technology a company which was previously dependent on Solaris and SPARC hardware can switch to commodity hardware and linux first on the desktop, then on the low to mid end server, and finally on the high end by replacing SMP SPARC systems with Linux clusters. Java is not going anywhere, but it also fails to make Sun any real money. And, despite some of the silly bickering between Sun and Microsoft over Java, Java actually makes money for Microsoft. A lot of Java development happens with Windows both on the desktop and the server, and Java's vendor independent persistence technology makes Microsoft SQL Server as attractive a platform as any other (Microsoft caters to this by providing free JDBC drivers while at the same time maintaining vendor lock-in for .NET persistence.)
Perhaps they didn't go after SuSE because they are partners along with TurboLinux in the United Linux thingy... and they all want Redhat to join in the worst kind of way. Seriously, IBM represents a big market share in the proprietary Unix space, and that is what SCO is gunning for. If they can get IBM in trouble for contributing to a technology from which they also benefit (Linux) then that is just a bonus.