I pay gasoline taxes that go to road infrastructure even when I use the gasoline in my lawnmower or snowmobile or to soak engine parts. I pay school taxes even though I homeschool my kids.
There is a fundamental difference to me here. You pay those taxes to PUBLIC institutions for PUBLIC infrastructure, not to give away to corporations that can't figure out how to make money. You actually do use the public roads and highways. You could use the public schools, but elected not to. Everyone else benefits from those taxes you pay, by traveling on those roads, and by improved delivery of items they purchase (if no other way). Usually the people using the service are those that are taxed. Society benefits from public education, as do you, even if you don't use that service. How does society benefit from paying off the RIAA and MPAA?
As a point of reference, I buy CDs from local bands direct from the band when they perform. The band gets the entire amount I pay, less their production costs, thus getting not only what a record label would pay them, but also what the record label would keep. This is a model that may not make them rich, but does give back to the people who count, those who actually make the music. This kind of model, on a larger scale, is what will get us better quality music, not paying the RIAA and MPAA.
I find myself siding with Linus on this one. It comes down to the fact that this is a restriction on the machine (hardware or firmware), not the software (the Linux kernel), so nothing in the licensing of the software can be at issue.
The problem is that part of the GPL3 is trying to use the license for the software (GPL3), to control the license for the machine as well. Those two items are very separate. That kind of usage of the GPL would be, as some people might say, be a very viral license, not at all the spirit the GPL has held in the past.
Having said that, I still say I would be very unlikely to buy the machine, and if everyone else feels that way, the company will go out of business.
We soon find that the hardware will only work with firmware which has been digitally signed by the vendor. Also, although the source code is available (as required by GPL2) it is useless when run on hardware that doesn't have the right keys embeded in it.
You are reading this the wrong way. The manufacturer can't keep you from running the code somewhere else, you have the source. The manufacturer can keep you from running other code on the machine he sold you, which will refuse to load the unsigned (or improperly signed) code. As long as you know that up front, if you don't like those conditions, don't buy the machine.
But in this case this is why IBM is handing over millions of lines of AIX code. SCO doesn't have it, and cannot prove that any of it is in Linux unless they have it. If they can find AIX code sitting in Linux, then at least part of their claims are more likely to be upheld.
I think maybe one point was missed in your analysis, they already had every released version of AIX. This time around is all of the unreleased versions that never actually went out to the world.
This is about their notion that UNIX code mutated while being developed as part of AIX, changing into something that went into the Linux code base, even though the original code may never have ended up in Linux in an identifiable form.
That said, if they couldn't find any code in the released versions to point to, looking at all of this additional code and documents (assuming they actually will look at them) is not likely to return any new information.
As to the license question, you are frequently bound by agreements your employer makes, although not normally on your own time. If you don't like it, you can leave, or take them to court over it.
Regardless of the legal issues, it appears that Larry probably felt that what he was doing was not in the spirit of the license, and Linus felt it not in the best interest of the developer community.
In the end Tridge stood by his legal rights, continuing to examine the wire protocol, and Larry exercised his right to determine how BK could be used. Linus stood in the middle, lost out in the process, and wasn't terribly happy about it.
The story here is Larry's perception of what Tridge was doing, the actions he took as a result of that, and how Linus viewed the whole thing.
I don't think that matters. OSDL has a BK license. As Tridge was employed by OSDL, it appears Larry (and possibly Linus) thought he was bound by their license terms. Tridge didn't feel that way. Because it was Larry's license, he got to interpret it as applying to Tridge's work. End of story.
Perhaps the reason Linus took the point of view he did had something to do with licensing? The same with Larry?
The agreement for the free version of bitkeeper had a clause saying you couldn't work on a another code management system, basically you couldn't use the free version and also try to make something to compete with bitkeeper. I'm sure the license agreement on the commercial version of bitkeeper also has a clause stipulating that you can't reverse engineer it without voiding your license (things like that are standard in licenses).
I see it as Linus saying that, under one of those agreements, Tridgell should have not been doing reverse engineering. He would have been breaking the spirit of those agreements, even if he wasn't breaking them legally by a technicality (OSDL had the license, not him directly).
Writing software for a living, I have sympathies with both sides, and some understanding of their positions. On the whole though, I agree with Linus, since the Linux team is going to be hurt by this event, which didn't need to happen. They will scramble and come up with something else that works for them, but it didn't need to happen this way.
As I understand it, having a secure, critical, national defense system, hooked to the internet, will get you fired, if not thrown in prison.
Just how are these evil open source coders going to gain access to the system? Will they be in the control center (the only place with access to it) with a computer that is attached to the system in front of them, and no one watching to see that they do nothing out of place?
Pure FUD. Only sligthly better than SCO, mainly because they haven't ranted enough about it in the press yet to let everyone see how off base it is.
Mandrake is using the standard kernel support for NTFS, which doesn't use any Microsoft code. This means you have limited write support (at least potentially, normally it is set up as read only), but excellent read support.
I think we should get something clear. I know some people have gone overboard in reaction to his decision about KDE in UserLinux, but this particular decision is the reason I have written.
I am a long time KDE user, and found his reasons for dismissing KDE very thin. They came across to me (and evidently many others) more like a re-hash of the old QT/GTK wars than a valid technical reason for making the decision. If he wants to make the personal choice of selecting Gnome for UserLinux, just say so. He will lose some users over this issue, and that is his choice. Evidently there are some users he is not willing to lose, as they are paying customers. That is his choice as well.
My choice is which distro to use, and it will be one that is willing to support KDE.
Please don't go around making generic statements (I know others have been making them as well) about why some of us object to making a technical decision based on non-technical reasoning.
I like Linux because of the license. I use it because it is better/more stable/doesn't catch the latest virus!
In terms of the companies using Gnome, just look at your list again. Sun - Now there is a company that can pick winning user interfaces (is CDE ugly or what). UserLinux - In spite of what they say, it is a religious issue with them. RedHat - One of more of the primary Gnome developers works for them, don't you think that has some effect. IBM sells (among others) Suse linux, which has long been a KDE supporter.
Commercial software developers, the only ones that need to pay to use QT to develop software, care about profits, not developer toolkit cost. If it makes them more money, it is an investment, not an expense. What do you care about them, since you aren't going to buy their software anyway, as you feel the license is more important than the functionality of the software. You won't like their license, you aren't their customer, and they will make their choices for their own reasons.
If you want to see a good looking, easy to use, smooth running application, look at K3b. It looks better than any Windows based CD burning software, better than any GTK based CD burning software, and it is free (as in freedom) software written for KDE. I guess they wanted to release free software, so they picked the license they wanted, and got to use the QT toolkit for free (as in beer and freedom).
P.S. I'm a long time Mandrake Linux user, and KDE user, so I'm not unprejudiced here. I also develop software for a living, and know how I look at tools.
Just because I didn't have the time while at work to write a long reply is no reason to jump all over my case.
rpmdrake will resolve all of the dependencies needed during the install of a piece of software. If it needs to install something else to make the package you want work, it tells you, and takes care of installing the other package(s) after you tell it to do so. It will not uninstall everything needed only by the package you are uninstalling, which is a design decision on the authors part, they felt it was not necessarily a safe thing.
It will take care of downloading packages automatically, although you do need to define sources it can use to locate those packages.
As long as the authors of the packages (well really the packagers, not necessarily the authors) configure the RPM with the correct dependencies, everything can go very smoothly.
Have you ever tried apt? I hear it works very well also. If all you ever used was RPM, or some other tool that doesn't take care of resolving the items needed for the package you are trying to install to work, then you are right, those RPM solutions suck.
Try using the right tools, and everything works nicely. rpmdrake calls urpmi, a command line tool that actually takes care of all the details, and which you don't have to see if you are averse to command line tools. urpmi in turn uses RPM to perform the actual low level RPM operations.
If you never tried Mandrake, and you have an issue with other distributions that use the RPM format to distribute packages, then I suggest you really give it a chance.
I am not a Mandrake employee or developer, although I do participate in their cooker development list, and contribute to the testing effort.
Hold on a minute. It's the developers who want to write commercial applications that have to pay for licenses. End users do not have a license fee! Why would you as an end user care about it.
If you are buying a commercial application you are paying for developer hours, developer training, management, marketing, support, and distribution. I'll bet that the tool set the developers use is barely detectable in that mix. Let's say an application takes 1 man year to develop. That's 2000 hours, at $50 per hour (a rediculously low number, especially when you consider employee benefits - more like $75 to $100/hr), doesn't that add up to $100,000. Most real commercial applications are much larger than that (3+ man years). The advertising costs for a product are probably a bigger part of the budget than than the tools.
Having a good, well supported, well documented, easy to use tool set is far more important, given the hourly development costs, than the costs of tools (like Qt) could ever be.
That is why more commercial applications are being developed in Qt/KDE than Gnome, except by companies that have a vested interest in Gnome.
This is a bad example to use when talking about forking a project. Apache 2.0 was a new version (read upgrade), not a fork, more like an IIS 3 to IIS 4 upgrade on Windows. Yes, it costs money to evaluate the upgrade, and to perform the upgrade. This is not a fork though.
The counter argument about forking being harmful to customers of the project, is that when the fork happens, it is because some people don't like the direction of the current project. As a customer of the project, if you do like the current direction, then keep using that side of the fork. Nothing went away. Unless that side of the project dies off, you have no problem. No one makes you change what you are using. Where is the cost in that?
He was talking about a pre-release test kernel (read ALPHA or maybe BETA release). You expect it to be broken part of the time. If you aren't ready to deal with that, you wait for a the final release. A distribution, as you pointed out, is a different thing.
I haven't had any trouble with my USB mouse or keyboard through the whole 2.6.0-test series. A difference in chip sets is probably to blame, and they will fix it if he works with them.
No. They're making a case that the whole management structure of Linux is flawed, since the project manager can't even determine that the work people under him submit is their own work.
All they are stating is the obvious. What they don't say is that this is true for all projects, not just open source ones. Violations of someone else's IP are simple easier to find in Linux (and other open source projects), because the source code is there for anyone to see.
If a closed source company, say Microsoft or SCO, just to give examples of closed source companies, was guilty of violating the IP of another company, how would anyone know? Only people within that company would see the source code, and if they were honest people, they probably wouldn't expect a developer to cheat in this way. Truthfully, it might be almost impossible for them to detect it, especially if the source of his stolen code was not publically available. It is the nature of development to expect developers to do the work you pay them for (or they agree to do for free), rather than to expect them to cheat.
If you want to see an example of this type of breaking of trust in another field, look no further than the recent newspaper debacle in New York. The paper trusted a writer to do his job, and he chose to invent material.
In the open source software world people generally earn their reputations by actually accomplishing something. Their reputation is totally based on the trust and belief of others in what they do. What they do is very public, and very open to scrutiny, unlike much work done within closed source companies.
SCO is trying to tarnish the image of open source software by throwing rocks at it. As the saying goes, people in glass houses shouldn't throw rocks.
NASA doesn't use Intel 8080 processors in the shuttles. The computers they use were developed for the Apollo program, way before the Intel 8080 existed. They use them because they are simple enough to have provably correct operation, something not true for most processors. This is a quality that must be designed for in the processor, and is more difficult to achieve as the processor becomes more complex. Code quality has nothing to do with the decision. Their code is all assembler by the way, so your code quality is very high, and very expensive.
Inpedendent studies show that in fact 73 percent of all "OOP" code is just imperative with C++ class bloat added. You mean it was crappy, non object oriented code, written by bad programmers! What a shocking notion! Anyone can write bad code in any language, it hardly takes any skill at all, which is the problem, lack of skill.
And the faster CPUs gave rise to the OOP paradigm. OOP is simply a codification of what programmers were already doing, it is neither a magic bullet, or a terrible evil.
I guess that means most of the Java programmers out there are busy doing development for money, especially J2EE development.
There are projects out there, just take a look on Sourceforge, but most of them are written to solve problems that Java developers have, not your average user.
In the Windows world, most inexperienced developers use something like VB, which is easy to write flashy, shallow applications in.
On Linux, where most of the Free Software developers hang out, many people have problems with the fact that Java is not Free (as in freedom) Software, although it is free (as in no money). For that reason, some developers refuse to work with it, just like some people refuse to use binary drivers from NVIDIA (or some other company).
The free implementations of Java are generally not up to the level of the ones from Sun or IBM, either in performance, or in language compliance. This may change in the future, since Sun appears to be moderating their attitude about Free Software implementations of Java.
Legally speaking, it doesn't make much difference if you decide to take responsibility or not. The real answer is people go where the money is, so normally a company will be named in a lawsuit, perhaps with the individuals who wrote the software. Since no one pays for me to have huge liability insurance coverage, which they do with a P.E., then no one is likely to be interested in me in legal terms.
From another point of view, engineering is the art (I say art because part of it is an art) of juggling conflicting requirements to a successful compromise. You could build a bridge 20 times as strong as it needs to be. No one wants to pay for that much overdesign, so you have to compromise by making the bridge less strong. If you compromise too much, it falls down. If you don't compromise enough, it never gets built. There are always conflicting requirements in any engineering project. Making the correct compromises is what engineering is about. An airplane that is too heavy to fly is not a useful thing to build, but one that is not strong enough is deadly.
In all cases, you should do the best possible work. Much of the software that is currently running is more complex than anything people have ever done before. The only software I know of that is warranted to be correct is that used by systems like the shuttle control computers. Part of the way they assure correct operation is to make it relatively simple, and spend more time testing it than any other customer is willing to pay for.
Your examples don't work, because they miss the point. The equivalent of a P.E. would be something like an MD, or like passing your bar exam in the law field. You are not a Doctor until you complete things beyond your degree, and you are not a lawyer until you pass things beyone your degree, but then your degree doesn't say that you are. It implies something beyond your degree. Almost no Engineers have P.E. licenses, because it is not applicable to the part of the Engineering field they chose to follow.
The standard practice in the parts of Engineering where a P.E. is required is to have a P.E. on staff, who has liability insurance paid for by the company, to review and sign off on all design related documents. In those companies, having a P.E. makes you able to progress up in the company to a higher position, but the majority of the staff will not have a P.E. License. in those companies, there is no dispute about who is an Engineer, everyone with an Engineering degree is an Engineer.
Just because Software is not a fully developed branch of Engineering, you can't say that one of the people practicing it is not an Engineer. Most people in the Software field are not Software Engineers, they have a degree in Computer Science, which is a more theoretical field, a bit like having a degree in physics. Understanding physics does not mean you are qualified to design buildings, even though the design of buildings is based on physics. A Software Engineering degree is very specific, and there aren't many programs that support that degree program yet.
I can assure you, based on friends I have who do have a P.E., they consider people with Engineering Degrees to be Engineers. None of them look down on those of us who didn't get a P.E., since they respect the degree that we have. Most of them became P.E.s because they felt there might be some benefit to their career if they did. Most of them haven't used their P.E., unless they worked for someone like Black & Veatch, where they do Civil Engineering work.
Lets get some facts correct. In most of the US, you are an engineer if you study engineering in college, be it electrical, mechanical, etc. To manage projects in civil engineering you have to be a licensed Professional Engineer (P.E.). That means you have several years of experience, have passed thorough testing, and have references from established P.E.s that say you are not only qualified technically, but ethically, to recieve the title.
Texas, unlike the rest of the US, says that the title Engineer is the equivalent of the P.E., which it is not. This is an error on the part of lawmakers in Texas, who should act to bring their definition of Engineer into line with the rest of the country.
I have a B.S.E.E. which is an Electrical Engineering degree. It is recognised throughout the country, and one would expect through much of the world, what this represents. If I had a P.E., it would not necessarily mean that I was the person you would want to design a bridge, or a building, but would mean that I would send you to someone who could, rather than do a bad job for you.
Since I have a degree, which I earned, that includes the title Engineer, I find it offensive that Texas would refuse me the right to use that title. Requiring a P.E. for some activities is perfectly understandable, but there are many Engineers who do not have a P.E., who still deserve to be able to use the title they earned.
Having said that, I find the MSCE, and similar titles to be offensive. They didn't earn the right to use the title Engineer, which implies an educational background well beyond what is required to pass the MSCE technical exam. Microsoft can't declare someone an Engineer, but passing through an accredited Engineering program is college is an entirely different thing.
The question though is when is a kernel ready to be used? The answer has to be when it is tested thoroughly. As long as that happens, so what if it's not the "official" kernel?
I know for a fact that Mandrake used this version because it supported hardware they needed to support, and it fixed some issues that were present in the 2.4.20 stable kernel. Either they had to maintain their own patches to deal with those issues, or they had to use the kernel version that fixed them. They can't say it works on their machine, they need to make it work on the greatest number of machines possible. Since they have to deal with customers who have problems with their product, their kernel is probably much better tested than the official one, because it costs them money if it is broken.
Slashdot Mirror
I pay gasoline taxes that go to road infrastructure even when I use the gasoline in my lawnmower or snowmobile or to soak engine parts. I pay school taxes even though I homeschool my kids.
There is a fundamental difference to me here. You pay those taxes to PUBLIC institutions for PUBLIC infrastructure, not to give away to corporations that can't figure out how to make money. You actually do use the public roads and highways. You could use the public schools, but elected not to. Everyone else benefits from those taxes you pay, by traveling on those roads, and by improved delivery of items they purchase (if no other way). Usually the people using the service are those that are taxed. Society benefits from public education, as do you, even if you don't use that service. How does society benefit from paying off the RIAA and MPAA?
As a point of reference, I buy CDs from local bands direct from the band when they perform. The band gets the entire amount I pay, less their production costs, thus getting not only what a record label would pay them, but also what the record label would keep. This is a model that may not make them rich, but does give back to the people who count, those who actually make the music. This kind of model, on a larger scale, is what will get us better quality music, not paying the RIAA and MPAA.
I find myself siding with Linus on this one. It comes down to the fact that this is a restriction on the machine (hardware or firmware), not the software (the Linux kernel), so nothing in the licensing of the software can be at issue.
The problem is that part of the GPL3 is trying to use the license for the software (GPL3), to control the license for the machine as well. Those two items are very separate. That kind of usage of the GPL would be, as some people might say, be a very viral license, not at all the spirit the GPL has held in the past.
Having said that, I still say I would be very unlikely to buy the machine, and if everyone else feels that way, the company will go out of business.
We soon find that the hardware will only work with firmware which has been digitally signed by the vendor. Also, although the source code is available (as required by GPL2) it is useless when run on hardware that doesn't have the right keys embeded in it.
You are reading this the wrong way. The manufacturer can't keep you from running the code somewhere else, you have the source. The manufacturer can keep you from running other code on the machine he sold you, which will refuse to load the unsigned (or improperly signed) code. As long as you know that up front, if you don't like those conditions, don't buy the machine.
I think maybe one point was missed in your analysis, they already had every released version of AIX. This time around is all of the unreleased versions that never actually went out to the world.
This is about their notion that UNIX code mutated while being developed as part of AIX, changing into something that went into the Linux code base, even though the original code may never have ended up in Linux in an identifiable form.
That said, if they couldn't find any code in the released versions to point to, looking at all of this additional code and documents (assuming they actually will look at them) is not likely to return any new information.
As to the license question, you are frequently bound by agreements your employer makes, although not normally on your own time. If you don't like it, you can leave, or take them to court over it.
Regardless of the legal issues, it appears that Larry probably felt that what he was doing was not in the spirit of the license, and Linus felt it not in the best interest of the developer community.
In the end Tridge stood by his legal rights, continuing to examine the wire protocol, and Larry exercised his right to determine how BK could be used. Linus stood in the middle, lost out in the process, and wasn't terribly happy about it.
The story here is Larry's perception of what Tridge was doing, the actions he took as a result of that, and how Linus viewed the whole thing.
I don't think that matters. OSDL has a BK license. As Tridge was employed by OSDL, it appears Larry (and possibly Linus) thought he was bound by their license terms. Tridge didn't feel that way. Because it was Larry's license, he got to interpret it as applying to Tridge's work. End of story.
Perhaps the reason Linus took the point of view he did had something to do with licensing? The same with Larry?
The agreement for the free version of bitkeeper had a clause saying you couldn't work on a another code management system, basically you couldn't use the free version and also try to make something to compete with bitkeeper. I'm sure the license agreement on the commercial version of bitkeeper also has a clause stipulating that you can't reverse engineer it without voiding your license (things like that are standard in licenses).
I see it as Linus saying that, under one of those agreements, Tridgell should have not been doing reverse engineering. He would have been breaking the spirit of those agreements, even if he wasn't breaking them legally by a technicality (OSDL had the license, not him directly).
Writing software for a living, I have sympathies with both sides, and some understanding of their positions. On the whole though, I agree with Linus, since the Linux team is going to be hurt by this event, which didn't need to happen. They will scramble and come up with something else that works for them, but it didn't need to happen this way.
As I understand it, having a secure, critical, national defense system, hooked to the internet, will get you fired, if not thrown in prison.
Just how are these evil open source coders going to gain access to the system? Will they be in the control center (the only place with access to it) with a computer that is attached to the system in front of them, and no one watching to see that they do nothing out of place?
Pure FUD. Only sligthly better than SCO, mainly because they haven't ranted enough about it in the press yet to let everyone see how off base it is.
Mandrake is using the standard kernel support for NTFS, which doesn't use any Microsoft code. This means you have limited write support (at least potentially, normally it is set up as read only), but excellent read support.
I think we should get something clear. I know some people have gone overboard in reaction to his decision about KDE in UserLinux, but this particular decision is the reason I have written.
I am a long time KDE user, and found his reasons for dismissing KDE very thin. They came across to me (and evidently many others) more like a re-hash of the old QT/GTK wars than a valid technical reason for making the decision. If he wants to make the personal choice of selecting Gnome for UserLinux, just say so. He will lose some users over this issue, and that is his choice. Evidently there are some users he is not willing to lose, as they are paying customers. That is his choice as well.
My choice is which distro to use, and it will be one that is willing to support KDE.
Please don't go around making generic statements (I know others have been making them as well) about why some of us object to making a technical decision based on non-technical reasoning.
Install the kernel source.
I like Linux because of the license. I use it because it is better/more stable/doesn't catch the latest virus!
In terms of the companies using Gnome, just look at your list again. Sun - Now there is a company that can pick winning user interfaces (is CDE ugly or what). UserLinux - In spite of what they say, it is a religious issue with them. RedHat - One of more of the primary Gnome developers works for them, don't you think that has some effect. IBM sells (among others) Suse linux, which has long been a KDE supporter.
Commercial software developers, the only ones that need to pay to use QT to develop software, care about profits, not developer toolkit cost. If it makes them more money, it is an investment, not an expense. What do you care about them, since you aren't going to buy their software anyway, as you feel the license is more important than the functionality of the software. You won't like their license, you aren't their customer, and they will make their choices for their own reasons.
If you want to see a good looking, easy to use, smooth running application, look at K3b. It looks better than any Windows based CD burning software, better than any GTK based CD burning software, and it is free (as in freedom) software written for KDE. I guess they wanted to release free software, so they picked the license they wanted, and got to use the QT toolkit for free (as in beer and freedom).
P.S. I'm a long time Mandrake Linux user, and KDE user, so I'm not unprejudiced here. I also develop software for a living, and know how I look at tools.
Just because I didn't have the time while at work to write a long reply is no reason to jump all over my case.
rpmdrake will resolve all of the dependencies needed during the install of a piece of software. If it needs to install something else to make the package you want work, it tells you, and takes care of installing the other package(s) after you tell it to do so. It will not uninstall everything needed only by the package you are uninstalling, which is a design decision on the authors part, they felt it was not necessarily a safe thing.
It will take care of downloading packages automatically, although you do need to define sources it can use to locate those packages.
As long as the authors of the packages (well really the packagers, not necessarily the authors) configure the RPM with the correct dependencies, everything can go very smoothly.
Have you ever tried apt? I hear it works very well also. If all you ever used was RPM, or some other tool that doesn't take care of resolving the items needed for the package you are trying to install to work, then you are right, those RPM solutions suck.
Try using the right tools, and everything works nicely. rpmdrake calls urpmi, a command line tool that actually takes care of all the details, and which you don't have to see if you are averse to command line tools. urpmi in turn uses RPM to perform the actual low level RPM operations.
If you never tried Mandrake, and you have an issue with other distributions that use the RPM format to distribute packages, then I suggest you really give it a chance.
I am not a Mandrake employee or developer, although I do participate in their cooker development list, and contribute to the testing effort.
Paul
Mandrake Linux - the program is rpmdrake.
Hold on a minute. It's the developers who want to write commercial applications that have to pay for licenses. End users do not have a license fee! Why would you as an end user care about it.
If you are buying a commercial application you are paying for developer hours, developer training, management, marketing, support, and distribution. I'll bet that the tool set the developers use is barely detectable in that mix. Let's say an application takes 1 man year to develop. That's 2000 hours, at $50 per hour (a rediculously low number, especially when you consider employee benefits - more like $75 to $100/hr), doesn't that add up to $100,000. Most real commercial applications are much larger than that (3+ man years). The advertising costs for a product are probably a bigger part of the budget than than the tools.
Having a good, well supported, well documented, easy to use tool set is far more important, given the hourly development costs, than the costs of tools (like Qt) could ever be.
That is why more commercial applications are being developed in Qt/KDE than Gnome, except by companies that have a vested interest in Gnome.
This is a bad example to use when talking about forking a project. Apache 2.0 was a new version (read upgrade), not a fork, more like an IIS 3 to IIS 4 upgrade on Windows. Yes, it costs money to evaluate the upgrade, and to perform the upgrade. This is not a fork though.
The counter argument about forking being harmful to customers of the project, is that when the fork happens, it is because some people don't like the direction of the current project. As a customer of the project, if you do like the current direction, then keep using that side of the fork. Nothing went away. Unless that side of the project dies off, you have no problem. No one makes you change what you are using. Where is the cost in that?
He was talking about a pre-release test kernel (read ALPHA or maybe BETA release). You expect it to be broken part of the time. If you aren't ready to deal with that, you wait for a the final release. A distribution, as you pointed out, is a different thing.
I haven't had any trouble with my USB mouse or keyboard through the whole 2.6.0-test series. A difference in chip sets is probably to blame, and they will fix it if he works with them.
No. They're making a case that the whole management structure of Linux is flawed, since the project manager can't even determine that the work people under him submit is their own work.
All they are stating is the obvious. What they don't say is that this is true for all projects, not just open source ones. Violations of someone else's IP are simple easier to find in Linux (and other open source projects), because the source code is there for anyone to see.
If a closed source company, say Microsoft or SCO, just to give examples of closed source companies, was guilty of violating the IP of another company, how would anyone know? Only people within that company would see the source code, and if they were honest people, they probably wouldn't expect a developer to cheat in this way. Truthfully, it might be almost impossible for them to detect it, especially if the source of his stolen code was not publically available. It is the nature of development to expect developers to do the work you pay them for (or they agree to do for free), rather than to expect them to cheat.
If you want to see an example of this type of breaking of trust in another field, look no further than the recent newspaper debacle in New York. The paper trusted a writer to do his job, and he chose to invent material.
In the open source software world people generally earn their reputations by actually accomplishing something. Their reputation is totally based on the trust and belief of others in what they do. What they do is very public, and very open to scrutiny, unlike much work done within closed source companies.
SCO is trying to tarnish the image of open source software by throwing rocks at it. As the saying goes, people in glass houses shouldn't throw rocks.
NASA doesn't use Intel 8080 processors in the shuttles. The computers they use were developed for the Apollo program, way before the Intel 8080 existed. They use them because they are simple enough to have provably correct operation, something not true for most processors. This is a quality that must be designed for in the processor, and is more difficult to achieve as the processor becomes more complex. Code quality has nothing to do with the decision. Their code is all assembler by the way, so your code quality is very high, and very expensive.
Inpedendent studies show that in fact 73 percent of all "OOP" code is just imperative with C++ class bloat added.
You mean it was crappy, non object oriented code, written by bad programmers! What a shocking notion! Anyone can write bad code in any language, it hardly takes any skill at all, which is the problem, lack of skill.
And the faster CPUs gave rise to the OOP paradigm.
OOP is simply a codification of what programmers were already doing, it is neither a magic bullet, or a terrible evil.
This is more the "smoke and mirrors" part of the campaign. You know, the movie version of shock and awe, all special effects, but no substance.
I guess that means most of the Java programmers out there are busy doing development for money, especially J2EE development.
There are projects out there, just take a look on Sourceforge, but most of them are written to solve problems that Java developers have, not your average user.
In the Windows world, most inexperienced developers use something like VB, which is easy to write flashy, shallow applications in.
On Linux, where most of the Free Software developers hang out, many people have problems with the fact that Java is not Free (as in freedom) Software, although it is free (as in no money). For that reason, some developers refuse to work with it, just like some people refuse to use binary drivers from NVIDIA (or some other company).
The free implementations of Java are generally not up to the level of the ones from Sun or IBM, either in performance, or in language compliance. This may change in the future, since Sun appears to be moderating their attitude about Free Software implementations of Java.
Legally speaking, it doesn't make much difference if you decide to take responsibility or not. The real answer is people go where the money is, so normally a company will be named in a lawsuit, perhaps with the individuals who wrote the software. Since no one pays for me to have huge liability insurance coverage, which they do with a P.E., then no one is likely to be interested in me in legal terms.
From another point of view, engineering is the art (I say art because part of it is an art) of juggling conflicting requirements to a successful compromise. You could build a bridge 20 times as strong as it needs to be. No one wants to pay for that much overdesign, so you have to compromise by making the bridge less strong. If you compromise too much, it falls down. If you don't compromise enough, it never gets built. There are always conflicting requirements in any engineering project. Making the correct compromises is what engineering is about. An airplane that is too heavy to fly is not a useful thing to build, but one that is not strong enough is deadly.
In all cases, you should do the best possible work. Much of the software that is currently running is more complex than anything people have ever done before. The only software I know of that is warranted to be correct is that used by systems like the shuttle control computers. Part of the way they assure correct operation is to make it relatively simple, and spend more time testing it than any other customer is willing to pay for.
Your examples don't work, because they miss the point. The equivalent of a P.E. would be something like an MD, or like passing your bar exam in the law field. You are not a Doctor until you complete things beyond your degree, and you are not a lawyer until you pass things beyone your degree, but then your degree doesn't say that you are. It implies something beyond your degree. Almost no Engineers have P.E. licenses, because it is not applicable to the part of the Engineering field they chose to follow.
The standard practice in the parts of Engineering where a P.E. is required is to have a P.E. on staff, who has liability insurance paid for by the company, to review and sign off on all design related documents. In those companies, having a P.E. makes you able to progress up in the company to a higher position, but the majority of the staff will not have a P.E. License. in those companies, there is no dispute about who is an Engineer, everyone with an Engineering degree is an Engineer.
Just because Software is not a fully developed branch of Engineering, you can't say that one of the people practicing it is not an Engineer. Most people in the Software field are not Software Engineers, they have a degree in Computer Science, which is a more theoretical field, a bit like having a degree in physics. Understanding physics does not mean you are qualified to design buildings, even though the design of buildings is based on physics. A Software Engineering degree is very specific, and there aren't many programs that support that degree program yet.
I can assure you, based on friends I have who do have a P.E., they consider people with Engineering Degrees to be Engineers. None of them look down on those of us who didn't get a P.E., since they respect the degree that we have. Most of them became P.E.s because they felt there might be some benefit to their career if they did. Most of them haven't used their P.E., unless they worked for someone like Black & Veatch, where they do Civil Engineering work.
Lets get some facts correct. In most of the US, you are an engineer if you study engineering in college, be it electrical, mechanical, etc. To manage projects in civil engineering you have to be a licensed Professional Engineer (P.E.). That means you have several years of experience, have passed thorough testing, and have references from established P.E.s that say you are not only qualified technically, but ethically, to recieve the title.
Texas, unlike the rest of the US, says that the title Engineer is the equivalent of the P.E., which it is not. This is an error on the part of lawmakers in Texas, who should act to bring their definition of Engineer into line with the rest of the country.
I have a B.S.E.E. which is an Electrical Engineering degree. It is recognised throughout the country, and one would expect through much of the world, what this represents. If I had a P.E., it would not necessarily mean that I was the person you would want to design a bridge, or a building, but would mean that I would send you to someone who could, rather than do a bad job for you.
Since I have a degree, which I earned, that includes the title Engineer, I find it offensive that Texas would refuse me the right to use that title. Requiring a P.E. for some activities is perfectly understandable, but there are many Engineers who do not have a P.E., who still deserve to be able to use the title they earned.
Having said that, I find the MSCE, and similar titles to be offensive. They didn't earn the right to use the title Engineer, which implies an educational background well beyond what is required to pass the MSCE technical exam. Microsoft can't declare someone an Engineer, but passing through an accredited Engineering program is college is an entirely different thing.
The question though is when is a kernel ready to be used? The answer has to be when it is tested thoroughly. As long as that happens, so what if it's not the "official" kernel?
I know for a fact that Mandrake used this version because it supported hardware they needed to support, and it fixed some issues that were present in the 2.4.20 stable kernel. Either they had to maintain their own patches to deal with those issues, or they had to use the kernel version that fixed them. They can't say it works on their machine, they need to make it work on the greatest number of machines possible. Since they have to deal with customers who have problems with their product, their kernel is probably much better tested than the official one, because it costs them money if it is broken.