Download & read the source. Or just read the documentation.
Comparator has the capability (-w) to ignore whitespace while generating the hash, while at the same time tracking the actual line numbers for purposes of merging and reporting. In my experience, most code-copiers are dumb and/or lazy -- to get past ESR's tool, the code-copier would have to (a) realize that they're violating a license, (b) not care, (c) be smart enough to realize that a pure cut-and-paste might get caught, and (d) energetic enough to munge up the code logic and variables. While I'm sure there are people like that, I would argue that most of them wouldn't be interested in contributing the result to the community, and the code wouldn't get past Linus if they did. The more logical case is some one/company who believe that they have a legitimate right to copy code from one kernel to another (BSD -> Linux / Linux -> SysV / SysV -> Linux) and thus not feeling the need to cover things up. Either of the SCO User Group examples would fit this category.
Keep in mind, this tool will not divine intent, or direction -- it's only going to give broad hints of where to look for possibly problematic code.
Face it. There is stolen code in Linux. How much and how severe the value of the theft is to be determined but that there was theft is almost certain.
No, no, no. Yes, things look bad (but we already know SCO loves to quote out of context). Yes, there is obviously code that is common between a version of Unix, and Linux, but the real questions become:
What is the origin/history/heritage of the code in question?
Who had the rights to the code in question?
How much of the code can actually be copyrighted?
Looking at the code snippet that SCO appears to be showing:/arch/ia64/sn/io/ate_utils.c and its associated CVS history it would appear that this code first appeared in the Linux kernel courtesy of SGI (or possibly HP), as part of the Itanium kernel port. SCO/Caldera participated in the Monterey project -- what were the contractual obligations on all of the parties, before and after the breakup? IE: Did the code get there legitimately?
Keep in mind that depending upon what court you're in, there are limits to how much of software can actually be protected by copyright. Most of the UNIX header files (and therefore parts of the functions that implement the APIs) can not be protected by copyright, since you have to publish them to use them, and a competing implementation has to implement the same APIs. This is where AT&T lost to BSDI, resulting in the freeing of *BSD. For that matter, comments aren't considered to be part of the code in certain jurisdictions.
Personally, I'm more interested in seeing what non-hardware-dependent code SCO is claiming copyright over. We already know that SCO is claiming some nebulous 'rights' to SMP and RCU code, but how much and where and why?
For any use on a submarine quite and reliable are the biggest concerns. You do have to wonder about what "images" they will be working on since most submarines running at working depth are "blind" as far as the visual sense in concerned. Makes me think they are using passive sonar to build a picture of their surroundings. The mind wobbles.
Congratulations... you figured it out! Now you understand why Linux and not Mac OS/X makes more sense for these boxen...
As you can imagine, there are a lot of details about this program that are not publicly releaseable, even if they aren't classified. You can find about more about ARCI via Google, but start with this PDF; it's mostly marketing pitch, but it does describe what we're doing.
Background:
Twenty-first century technological innovation demands that today's warfare systems become increasingly adaptable and upgradeable. Exploiting research and development to ensure U.S. forces maintain a decisive lead in technologies critical to military transformation, the use of Commercial-Off-The-Shelf (COTS)
equipment in the Acoustic Rapid COTS Insertion (ARCI) Program has demonstrated
the ability to restore a remarkable acoustic advantage to U.S. submarines. ARCI
demonstrated, through the use of COTS equipment, the ability to rapidly install a marked technological refresh in equipment at a lower cost.
In real-world exercises and operations, the ARCI submarine sonar system has
unequivocally demonstrated that U.S. submarines retain a clear acoustic advantage. Use of COTS equipment in ARCI has substantially reduced costs with significantly improved processing capability.
Description:
The ARCI program is a phased effort to provide the submarine force with a common sonar that is far more capable and flexible than earlier designs. An open-systems architecture (OSA) exploiting commercial processing development permits the use of complex algorithms that could not previously be accommodated. COTS based processors and OSA technology and systems allow onboard computing power to grow at nearly the same rate as commercial industry's. This facilitates regular updates to both software and hardware
with minimal impact on submarine scheduling.
Lockheed Martin Naval Electronics & Surveillance Systems (NE&SS)-Undersea
Systems is the lead contractor for the U.S. Navy's ARCI Program. This multi-phase development initiative provides for sonar systems upgrades on existing legacy submarine sonar systems including the SSN-688, SSN-688I, SSN-21, and SSBN-726 class submarines.
The ARCI Program features the installation of a common, cost-effective, more capable and flexible COTS-based open systems architecture.
Next Step:
Lockheed Martin is leading an effort to raise the reliability to guarantee operational effectiveness for predictable operating periods. Known as
Maintenance Free Operating Periods (MFOP), this concept will transform maintenance practices, supply support systems, training concepts, and further enhance operational performance while reducing life-cycle costs.
Features:
Enables U.S. undersea superiority as a result of the insertion of leading-edge technology into the Fleet
Dramatically improves towed array performance and enhances tactical control
Advances spherical, hull, and high frequency array processing and performance
Use of COTS with open systems architecture allows for continuous updates and reduces total ownership costs
I can offer some insights into the factors driving this particular decision:
Power / Size / Price - The Xserve computers are dual-processor 1.33GHz G4s, in a 1u form-factor. Compared to the equipment that these units are replacing, we're improving the MFLOP density for the equivalent space, while reducing the cost by a factor of 5 or more.
Compatability - The Xserves are a fraction of the COTS hardware that we're installing. Much of what we're doing is replacing HP servers with generic Linux servers (running Red Hat Linux). We chose Yellow Dog Linux for its compatibility with Red Hat Linux. Using OS/X wouldn't make sense since these servers are being using as compute engines in a cluster, not displays.
You have to keep in mind the physical environment of a submarine: there isn't a lot of space on a boat for active equipment, much less spares. Redundancy is a must, as is reliability.
You shot your counter-arguments in the foot as you uttered them:
Oh, so a plane doesn't need winds and wheels. Somebody tell Boeing.
As long as you insist that a reusable spaceship land like a plane, then sure, you'll probably want wheels and wings. On the other hand, if all you require is that it take off and land repeatedly and reliably, then wheels and wings aren't a requirement. The DC-X project worked; DC-Y would have worked except that it was cancelled because it didn't have wings... Remind me again -- what use are wings in a vacuum?
Newsflash, Shuttle is man-rated. Jeffrey Bell says Station is not.
Try reading what he wrote: He was referring to vehicles (ie, the Shuttle AND the OSP), not the Shuttle and the ISS. The Shuttle is already damn expensive, and if we can't cancel it because the so-called replacement (OSP) can't do the same things (ie: move cargo to LEO) then we have to keep flying shuttles until we run out, plus develop and run an expensive OSP program too. That might guarantee employment for astronauts and lots of NASA managers, but is that the best use of our money?
Bell may not have written what you want to hear, but that doesn't make his facts any less true. Don't get me wrong -- I want to see a reliable, reusable replacement for the shuttle program as much as anyone -- I'm just tired of seeing people die because of NASA's fscked up decision process.
I downloaded their paper, and on the last page it reads:
Major support for the Project on Scientific Knowledge and Public Policy is provided by the Common Benefit Trust, a fund established pursuant to a court order in the Silicone Gel Breast Implant Products Liability Litigation, with additional support from the Alice Hamilton Fund and the Baumann Foundation.
So, a fund created because of a lawsuit that was heavily influenced by junk science (according to the losers) is paying for a paper that recommends letting (more) junk science back into the courtroom? Your insurance premiums at work...
Transvirtual Technologies was founded to commercialize Kaffe, and for several years, Transvirtual drove the development and direction for Kaffe. Microsoft made a significant investment in Transvirtual (see the Wired article), after which I stopped paying attention to Kaffe, since all Microsoft was interested in was Java 1.1 compatibility.
Apparently in March, 2002, Tim Wilkinson (the original creator of Kaffe, and the one-time CEO of Transvirtual) was no longer associated with Transvirtual, and had turned over maintenance of Kaffe to Jim Pick (see announcement here). Transvirtual faded in July, 2002 (see note here), leaving Kaffe free to go its own way.
I've looked through the Kaffe.org website, and I can't tell what version of Java it supports. It looks like they've added some Java 1.2 support, but LOTS of work would need to be done to bring it up to Java 1.4, which is my development target these days.
Kaffe -- Stuck at Java 1.1, and owned by a company that's owned by
Micro$haft.
Blackdown -- Great JVM (I use it myself), but awkward to get & still not open source.
As for forking Java -- While this will depend greatly upon the license, I don't think it will be a problem for the same reason that forked versions of Apache aren't a problem: branding. You can't call something Apache without the permission of Apache. Everyone trusts the Apache brand, because the Apache developers worked very hard to make the Apache software reliable, dependable, and stable. Apache keeps control of the brand by making it easy to submit a patch -- and by having experienced developers approve patches before applying them. (They also keep control by encouraging people to build modules for significant functionality, and having a known procedure for accepting modules into the Apache source tree.)
Sun has established a similar brand for Java; all Sun has to do to control the Java brand is to make it easier to work with Sun than to fork. Thus Sun should extend the Java Developer Connection to support accepting patches from developers.
Sun should also make the JCK free to examine and distribute, but not free to modify -- but allow developers to submit patches to the JCK. Then let any Java implementation can call itself Java X if it passes the JCK for Java X. It's not as if there aren't plenty of commercial JVMs running around, each of them optimized for different environments. The vendors all have to pass the JCK to call their implementations Java; this would be no different.
Oddly enough, I do an awful lot of my own maintenance. I can't see paying a contractor to do work that I can do, and who I'd have to supervise directly in order to get the job done with the quality I want. Not to say I do everything -- I am more than happy to pay an electrical contractor to add new electrical circuits (putting new circuit breakers into a breaker box is not a job for amateurs), but I've done all of the phone and network wiring, and most of the electrical work. I've built new walls, installed doors, repaired and installed drywall, and installed linoleum flooring. And painting. Way too much painting, though my wife does the bulk of that.
The next major projects are redoing the kitchen (much of which will be contracted out because I don't have the time to do everything myself) and converting a storage room into a workroom for my wife (she makes glass beads & jewelry) complete with kiln.
Apartments and condos = residential construction, which, as I wrote, is still hot (primarily because of the record-low interest rates); people still need someplace to live. Most of the Chinatown construction/reconstruction is a result of the new convention center, and was planned and (mostly) financed back during the dot-com boom. I don't get over to Maryland very often, but in Virginia, commercial construction is at a standstill -- no one wants to build more new office buildings when there are dozens of new buildings standing empty.
As for economic recovery, there's still one more shoe waiting to drop: as soon as the economy starts to "recover", interest rates will start rising again, as the Fed increases the prime rate to combat inflation. Once that happens, the residential construction market is going to flatten out (and possibly tube), which will stifle the recovery for another 2-3 years.
Well, in this area (Washington DC metropolitan) depending upon the type of construction work you do, you can be just as screwed as the white-collar types. The late 90s saw a huge commercial construction boom, but with the current economic bust, there are huge buildings that either (a) have never been finished, (b) have never been occupied, or (c) are now standing empty because all of the tenents went bankrupt. That means no new commercial construction. In Loudoun county alone (home of AOL & MCI/Worldcom), 16% of the office space is empty, and if MCI/Worldcom is forced to close their offices here (more than one million square feet), that figure would double.
Residential construction is still hot, but "used" home sales are starting to outstrip new home sales, and new residential construction is moving farther away from the metro area, simply because most of the inner metro areas are already built to zoning capacity, and "smart growth" advocates (you know, the sorts who have a $1m+ house on 5+ acres of land, and want everyone else to live in apartments near metro stops) have squashed new local development.
From your comments it seems to me that you haven't done enough research. For starters, the GPL version of Red Hat (that you downloaded) is different from the products that Red Hat offers for sale (ie: Red Hat Linux 9 / Red Hat Linux 9 Professional / etcetera). In particular, purchasing a product from Red Hat entitles you to support for that product... not a lot of support for RHL 9, more support for RHL 9 Professional, and a lot more for RHES. All that Red Hat is doing here is identifying the level of support that you're entitled to receive for your payment, and informing you that if you want more support, you have to pay for it. BTW, you should check the EULA and GPL files in the top-level directory of the first disk.
Have you actually read the EULA at RedHat's website? All it says is that all of the software and data are covered by license agreements, and that if you want to use it / redistribute it, you should read the indvidual licenses. They also make clear that purchasing the product includes purchasing support, and that the support isn't transferable, even if the software is. IE: You have to follow the GPL for the GPL'd components, the LGPL for the LGPL'd components, etc. Not exactly an onerous requirement. You do follow the licenses for the software you download, right? After all, GCC doesn't require you to read the GPL on a website before you download it, but it applies to you all the same.
IANAL, but I've been studying EULA's for almost 25 years, and this one of the clearest and sanest licenses I've ever seen (the other good one was the Borland No-Nonsense License, not that Borland uses it anymore).
As for supporting the small business market... I've spent roughly half of my career supporting that market, and the customers in that market aren't going to buy RH Linux and expect support from Red Hat. Those customers are going to buy an application from a vertical application developer and buy support from the developer, be it deployed on Linux, Windows, OS/2, or Mac OSX. $300-$500/year is not enough money to adequately support teaching a Mom & Pop shop-owner how to backup their hard drives, so I'm not surprised that Red Hat isn't chasing that market.
In all of the talk about SCO showing their "proof", I seem to have missed any discussion of the chain of evidence that would actually substantiate this "proof". Think about it. Suppose you sign SCO's NDA and they show you two printouts, one labelled "SCO Unix" and one labelled "Linux", and they've carefully highlighted similar sets of code. In what way does that demonstrate the exhibit A actually came from SCO Unix, and exhibit B came from the Linux kernel tree?
In order to accept their exhibits, not only would I have to see them check their code out of their repository, I'd need to see the repository logs for how and when that code first got into that file in that repository. And keep in mind, someone with enough time and desire can fake a repository log, so I'd need to audit their repository looking at timestamps and comparing build results against delivered products (after all, who's to say that the file in question is even used by a build?). This will quickly devolve into an exercise in my-expert-says/your-expert-says.
At least with Linux, I (or anyone) can go to kernel.org and download subsequent snapshots until I come to a pair, one with and one without the code in question. This works because anyone can make a mirror of the kernel snapshots, and comparing your snapshot against my snapshot is straight-forward and proveable. Don't trust the kernel.org servers? Start picking up old CD-ROM Distribution sets and extract the kernel source.
Check again -- as of 6/5 2:00 AM EDT, it looks like the JBoss Group declared these guys to be non-persons. No pictures, no names, no mention whatsoever.
Re:Question about their threat to sue Linus Torval
on
SCO vs Linux.. Continued
·
· Score: 3, Funny
And unless enough people donate money, God is going to call Oral Roberts home.
If you look at Sun's press release about Red Hat you'll see that Red Hat will be including the JVM with their RH Enterprise Linux distributions... not with Red Hat Linux, and that Sun will only be supporting RH Enterprise Linux. Why? Because Sun still won't license the JVM for redistribution. I'm not saying that Sun is wrong here (it's their toy, they get to choose the license), but this is what has been slowing the acceptance of Java on Linux with many developers. (Except for corporate Java developers -- they love it, and thus, so do I.)
Sun's trying to balance control of Java against market acceptance, and Solaris against Linux. Sun obviously thinks that anyone who wants Java for Linux will go to the effort of downloading it from Sun, while at the same time they get to differentiate Solaris from Linux by including Java. On the other hand, Sun could hardly sell & support Linux on Sun servers without also including Java; this agreement gives them what they want without letting go of their (perceived) control of Java.
It goes fast? Let's say each coder costs $100,000 a very liberal estimate.
4 coders * $100,000 = $400,000
$2,000,000/$400,000 = 5 Years
That's a very long time to be guarenteed a job.
Obviously you've never actually hired anyone or run a company. I don't know about Canada, but in the US, you can figure the overhead on a position to be anywhere from 50% to 100% above and beyond the salary of the position. Consider the following factors:
Social Security (employer pays half, typically 7.5% of salary).
Health insurance (typically $3600 per employee).
Other benefits (matching 401k / pension / softdrinks / whatever).
Equipment (PC, mail servers, file servers, etc.)
Power, telephones, bandwidth, water, heat, etc.
Another problem with this type of payment is that typically the funds have to be spent within a specific time period, and any unspent funds have to be returned to DARPA...
You're missing the point. So Eclipse doesn't provide a Tomcat plugin; big deal. A number of other developers provide plugins to do almost anything you might want, most of them open source (though there are some commercial plugins.) Have a look at the SysDeo Tomcat Plugin before you pass judgement on Eclipse.
My only gripe with Eclipse plugins is that Eclipse doesn't have a central repository that uses their automatic install/update mechanism for plugins to save people from having to hunt for the plugins. Instead they've let the community pick up the slack -- so you sometimes have to hunt around looking for just the right plugin.
The Wizard of Speed and Time, Mike Jittlov's master work, is an excellent movie, and (sadly) completely self-referential. Mike made a movie about a SFX wizard named Mike Jittlov who's making a movie, but who gets screwed by his producer... and got screwed by his producer (who played the producer in the movie). There are lots of wonderful appearances by strange character actors and actresses, and even Angelique Pettyjohn, who some of you might remember as Shahna from the TOS episode "The Gamesters of Triskelion".
I will say, however, I have never seen a movie adaptation of an original book that was better than the book.
Either you've never seen Blade Runner, the Director's Cut, or you've never read Do Androids Dream of Electric Sheep. The movie was much better than the original book.
write once run everywhere NEVER meant on any VM. For a Java programmer the VM _is_ the platform. Once you get it running in the VM you get the ability to run on any platform the VM runs on. Java programmers know this. It is acceptable.
I'm a Java programmer, and have been programming for Java since Java 1.0.2. Up until a month ago, I'd have sworn you were right, but I've recently been bit HARD by JVM incompatibility. Our group has spent several years building a large, complex GUI application using Java. The original development was with Java 1.2, which then was updated to Java 1.3.1. (We'd actually prefer to use Java 1.4, but we haven't had time to fully certify the app for Java 1.4.) I'm the Lead Integration Engineer, and while Windows has been our primary development and testing platform, I've also been testing compatibility on Linux as well. Suffice to say, both of those platforms are very well supported by Sun, and very inter-compatible. A month ago we were given a requirement to support our application on Solaris -- should be a no-brainer, right? WRONG! It turns out that even though we were using only Sun's JVMs, and no IDE-specific libraries, our developers had inadvertently depended upon AWT capabilities that are only present with the Windows and Linux JVMs. Makes the whole thing look flipping ugly on Solaris. So now we're going back and putting in Solaris-only code to fix the things that should have been there in the JVM.
I'm not surprised that the Sun developers would feel that Solaris is not a priority platform for Sun, at least for AWT/Swing development. Sun doesn't market Solaris for office/desktop deployment. Developer workstations? Maybe, but their focus is really on selling big iron servers, not client hardware -- they ceded that market to Microsoft years ago.
Note that I ran the Java test using java -server Test.java; I found the server JVM to be faster for this code than the client JVM.
So on my systems, for this test program, unoptimized Java is faster than unoptimized C, optimized C is 2.5 times faster than optimized Java, and GCJ is too immature to bother with. This matches my experience (7+ years Java) and my expectations. If I need to do numerical computations, there are faster languages than Java. On the other hand, if I'm doing distributed applications, where network bandwidth and latency are apt to be factors, Java will be as fast as C, and much easier to code reliably, given the built-in support for threading. And on the gripping hand, since I'm more productive in Java than in C, and since Java doesn't have to be recompiled for every platform, Java is probably the better language -- for my purposes. You can use whatever you want to use.
Slashdot Mirror
Download & read the source. Or just read the documentation.
Comparator has the capability (-w) to ignore whitespace while generating the hash, while at the same time tracking the actual line numbers for purposes of merging and reporting. In my experience, most code-copiers are dumb and/or lazy -- to get past ESR's tool, the code-copier would have to (a) realize that they're violating a license, (b) not care, (c) be smart enough to realize that a pure cut-and-paste might get caught, and (d) energetic enough to munge up the code logic and variables. While I'm sure there are people like that, I would argue that most of them wouldn't be interested in contributing the result to the community, and the code wouldn't get past Linus if they did. The more logical case is some one/company who believe that they have a legitimate right to copy code from one kernel to another (BSD -> Linux / Linux -> SysV / SysV -> Linux) and thus not feeling the need to cover things up. Either of the SCO User Group examples would fit this category.
Keep in mind, this tool will not divine intent, or direction -- it's only going to give broad hints of where to look for possibly problematic code.
No, no, no. Yes, things look bad (but we already know SCO loves to quote out of context). Yes, there is obviously code that is common between a version of Unix, and Linux, but the real questions become:
Looking at the code snippet that SCO appears to be showing: /arch/ia64/sn/io/ate_utils.c and its associated CVS history it would appear that this code first appeared in the Linux kernel courtesy of SGI (or possibly HP), as part of the Itanium kernel port. SCO/Caldera participated in the Monterey project -- what were the contractual obligations on all of the parties, before and after the breakup? IE: Did the code get there legitimately?
Keep in mind that depending upon what court you're in, there are limits to how much of software can actually be protected by copyright. Most of the UNIX header files (and therefore parts of the functions that implement the APIs) can not be protected by copyright, since you have to publish them to use them, and a competing implementation has to implement the same APIs. This is where AT&T lost to BSDI, resulting in the freeing of *BSD. For that matter, comments aren't considered to be part of the code in certain jurisdictions.
Personally, I'm more interested in seeing what non-hardware-dependent code SCO is claiming copyright over. We already know that SCO is claiming some nebulous 'rights' to SMP and RCU code, but how much and where and why?
Congratulations ... you figured it out! Now you understand why Linux and not Mac OS/X makes more sense for these boxen...
Hint -- put the hardware in a sound-proof cabinet that's isolated with rubber shock mounts from the rest of the boat. No more noise problems.
Of course the major sound source on a boat is the reactor/propulsion system...
As you can imagine, there are a lot of details about this program that are not publicly releaseable, even if they aren't classified. You can find about more about ARCI via Google, but start with this PDF; it's mostly marketing pitch, but it does describe what we're doing.
I can offer some insights into the factors driving this particular decision:
You have to keep in mind the physical environment of a submarine: there isn't a lot of space on a boat for active equipment, much less spares. Redundancy is a must, as is reliability.
You shot your counter-arguments in the foot as you uttered them:
Oh, so a plane doesn't need winds and wheels. Somebody tell Boeing.As long as you insist that a reusable spaceship land like a plane, then sure, you'll probably want wheels and wings. On the other hand, if all you require is that it take off and land repeatedly and reliably, then wheels and wings aren't a requirement. The DC-X project worked; DC-Y would have worked except that it was cancelled because it didn't have wings... Remind me again -- what use are wings in a vacuum?
Newsflash, Shuttle is man-rated. Jeffrey Bell says Station is not.Try reading what he wrote: He was referring to vehicles (ie, the Shuttle AND the OSP), not the Shuttle and the ISS. The Shuttle is already damn expensive, and if we can't cancel it because the so-called replacement (OSP) can't do the same things (ie: move cargo to LEO) then we have to keep flying shuttles until we run out, plus develop and run an expensive OSP program too. That might guarantee employment for astronauts and lots of NASA managers, but is that the best use of our money?
Bell may not have written what you want to hear, but that doesn't make his facts any less true. Don't get me wrong -- I want to see a reliable, reusable replacement for the shuttle program as much as anyone -- I'm just tired of seeing people die because of NASA's fscked up decision process.
I downloaded their paper, and on the last page it reads:
So, a fund created because of a lawsuit that was heavily influenced by junk science (according to the losers) is paying for a paper that recommends letting (more) junk science back into the courtroom? Your insurance premiums at work...
Let's say my information was out of date.
Transvirtual Technologies was founded to commercialize Kaffe, and for several years, Transvirtual drove the development and direction for Kaffe. Microsoft made a significant investment in Transvirtual (see the Wired article), after which I stopped paying attention to Kaffe, since all Microsoft was interested in was Java 1.1 compatibility.
Apparently in March, 2002, Tim Wilkinson (the original creator of Kaffe, and the one-time CEO of Transvirtual) was no longer associated with Transvirtual, and had turned over maintenance of Kaffe to Jim Pick (see announcement here). Transvirtual faded in July, 2002 (see note here), leaving Kaffe free to go its own way.
I've looked through the Kaffe.org website, and I can't tell what version of Java it supports. It looks like they've added some Java 1.2 support, but LOTS of work would need to be done to bring it up to Java 1.4, which is my development target these days.
Kaffe -- Stuck at Java 1.1, and owned by a company that's owned by Micro$haft.
Blackdown -- Great JVM (I use it myself), but awkward to get & still not open source.
As for forking Java -- While this will depend greatly upon the license, I don't think it will be a problem for the same reason that forked versions of Apache aren't a problem: branding. You can't call something Apache without the permission of Apache. Everyone trusts the Apache brand, because the Apache developers worked very hard to make the Apache software reliable, dependable, and stable. Apache keeps control of the brand by making it easy to submit a patch -- and by having experienced developers approve patches before applying them. (They also keep control by encouraging people to build modules for significant functionality, and having a known procedure for accepting modules into the Apache source tree.)
Sun has established a similar brand for Java; all Sun has to do to control the Java brand is to make it easier to work with Sun than to fork. Thus Sun should extend the Java Developer Connection to support accepting patches from developers.
Sun should also make the JCK free to examine and distribute, but not free to modify -- but allow developers to submit patches to the JCK. Then let any Java implementation can call itself Java X if it passes the JCK for Java X. It's not as if there aren't plenty of commercial JVMs running around, each of them optimized for different environments. The vendors all have to pass the JCK to call their implementations Java; this would be no different.
Oddly enough, I do an awful lot of my own maintenance. I can't see paying a contractor to do work that I can do, and who I'd have to supervise directly in order to get the job done with the quality I want. Not to say I do everything -- I am more than happy to pay an electrical contractor to add new electrical circuits (putting new circuit breakers into a breaker box is not a job for amateurs), but I've done all of the phone and network wiring, and most of the electrical work. I've built new walls, installed doors, repaired and installed drywall, and installed linoleum flooring. And painting. Way too much painting, though my wife does the bulk of that.
The next major projects are redoing the kitchen (much of which will be contracted out because I don't have the time to do everything myself) and converting a storage room into a workroom for my wife (she makes glass beads & jewelry) complete with kiln.
Apartments and condos = residential construction, which, as I wrote, is still hot (primarily because of the record-low interest rates); people still need someplace to live. Most of the Chinatown construction/reconstruction is a result of the new convention center, and was planned and (mostly) financed back during the dot-com boom. I don't get over to Maryland very often, but in Virginia, commercial construction is at a standstill -- no one wants to build more new office buildings when there are dozens of new buildings standing empty.
As for economic recovery, there's still one more shoe waiting to drop: as soon as the economy starts to "recover", interest rates will start rising again, as the Fed increases the prime rate to combat inflation. Once that happens, the residential construction market is going to flatten out (and possibly tube), which will stifle the recovery for another 2-3 years.
Well, in this area (Washington DC metropolitan) depending upon the type of construction work you do, you can be just as screwed as the white-collar types. The late 90s saw a huge commercial construction boom, but with the current economic bust, there are huge buildings that either (a) have never been finished, (b) have never been occupied, or (c) are now standing empty because all of the tenents went bankrupt. That means no new commercial construction. In Loudoun county alone (home of AOL & MCI/Worldcom), 16% of the office space is empty, and if MCI/Worldcom is forced to close their offices here (more than one million square feet), that figure would double.
Residential construction is still hot, but "used" home sales are starting to outstrip new home sales, and new residential construction is moving farther away from the metro area, simply because most of the inner metro areas are already built to zoning capacity, and "smart growth" advocates (you know, the sorts who have a $1m+ house on 5+ acres of land, and want everyone else to live in apartments near metro stops) have squashed new local development.
I've got several possible contenders for this one:
I'll let you decide which was the oldest/slowest.
From your comments it seems to me that you haven't done enough research. For starters, the GPL version of Red Hat (that you downloaded) is different from the products that Red Hat offers for sale (ie: Red Hat Linux 9 / Red Hat Linux 9 Professional / etcetera). In particular, purchasing a product from Red Hat entitles you to support for that product ... not a lot of support for RHL 9, more support for RHL 9 Professional, and a lot more for RHES. All that Red Hat is doing here is identifying the level of support that you're entitled to receive for your payment, and informing you that if you want more support, you have to pay for it. BTW, you should check the EULA and GPL files in the top-level directory of the first disk.
Have you actually read the EULA at RedHat's website? All it says is that all of the software and data are covered by license agreements, and that if you want to use it / redistribute it, you should read the indvidual licenses. They also make clear that purchasing the product includes purchasing support, and that the support isn't transferable, even if the software is. IE: You have to follow the GPL for the GPL'd components, the LGPL for the LGPL'd components, etc. Not exactly an onerous requirement. You do follow the licenses for the software you download, right? After all, GCC doesn't require you to read the GPL on a website before you download it, but it applies to you all the same.
IANAL, but I've been studying EULA's for almost 25 years, and this one of the clearest and sanest licenses I've ever seen (the other good one was the Borland No-Nonsense License, not that Borland uses it anymore).
As for supporting the small business market ... I've spent roughly half of my career supporting that market, and the customers in that market aren't going to buy RH Linux and expect support from Red Hat. Those customers are going to buy an application from a vertical application developer and buy support from the developer, be it deployed on Linux, Windows, OS/2, or Mac OSX. $300-$500/year is not enough money to adequately support teaching a Mom & Pop shop-owner how to backup their hard drives, so I'm not surprised that Red Hat isn't chasing that market.
In all of the talk about SCO showing their "proof", I seem to have missed any discussion of the chain of evidence that would actually substantiate this "proof". Think about it. Suppose you sign SCO's NDA and they show you two printouts, one labelled "SCO Unix" and one labelled "Linux", and they've carefully highlighted similar sets of code. In what way does that demonstrate the exhibit A actually came from SCO Unix, and exhibit B came from the Linux kernel tree?
In order to accept their exhibits, not only would I have to see them check their code out of their repository, I'd need to see the repository logs for how and when that code first got into that file in that repository. And keep in mind, someone with enough time and desire can fake a repository log, so I'd need to audit their repository looking at timestamps and comparing build results against delivered products (after all, who's to say that the file in question is even used by a build?). This will quickly devolve into an exercise in my-expert-says/your-expert-says.
At least with Linux, I (or anyone) can go to kernel.org and download subsequent snapshots until I come to a pair, one with and one without the code in question. This works because anyone can make a mirror of the kernel snapshots, and comparing your snapshot against my snapshot is straight-forward and proveable. Don't trust the kernel.org servers? Start picking up old CD-ROM Distribution sets and extract the kernel source.
Check again -- as of 6/5 2:00 AM EDT, it looks like the JBoss Group declared these guys to be non-persons. No pictures, no names, no mention whatsoever.
And unless enough people donate money, God is going to call Oral Roberts home.
If you look at Sun's press release about Red Hat you'll see that Red Hat will be including the JVM with their RH Enterprise Linux distributions ... not with Red Hat Linux, and that Sun will only be supporting RH Enterprise Linux. Why? Because Sun still won't license the JVM for redistribution. I'm not saying that Sun is wrong here (it's their toy, they get to choose the license), but this is what has been slowing the acceptance of Java on Linux with many developers. (Except for corporate Java developers -- they love it, and thus, so do I.)
Sun's trying to balance control of Java against market acceptance, and Solaris against Linux. Sun obviously thinks that anyone who wants Java for Linux will go to the effort of downloading it from Sun, while at the same time they get to differentiate Solaris from Linux by including Java. On the other hand, Sun could hardly sell & support Linux on Sun servers without also including Java; this agreement gives them what they want without letting go of their (perceived) control of Java.
4 coders * $100,000 = $400,000
$2,000,000/$400,000 = 5 Years
That's a very long time to be guarenteed a job.
Obviously you've never actually hired anyone or run a company. I don't know about Canada, but in the US, you can figure the overhead on a position to be anywhere from 50% to 100% above and beyond the salary of the position. Consider the following factors:
Another problem with this type of payment is that typically the funds have to be spent within a specific time period, and any unspent funds have to be returned to DARPA...
You're missing the point. So Eclipse doesn't provide a Tomcat plugin; big deal. A number of other developers provide plugins to do almost anything you might want, most of them open source (though there are some commercial plugins.) Have a look at the SysDeo Tomcat Plugin before you pass judgement on Eclipse.
My only gripe with Eclipse plugins is that Eclipse doesn't have a central repository that uses their automatic install/update mechanism for plugins to save people from having to hunt for the plugins. Instead they've let the community pick up the slack -- so you sometimes have to hunt around looking for just the right plugin.
The Wizard of Speed and Time, Mike Jittlov's master work, is an excellent movie, and (sadly) completely self-referential. Mike made a movie about a SFX wizard named Mike Jittlov who's making a movie, but who gets screwed by his producer ... and got screwed by his producer (who played the producer in the movie). There are lots of wonderful appearances by strange character actors and actresses, and even Angelique Pettyjohn, who some of you might remember as Shahna from the TOS episode "The Gamesters of Triskelion".
Either you've never seen Blade Runner, the Director's Cut, or you've never read Do Androids Dream of Electric Sheep. The movie was much better than the original book.
I'm a Java programmer, and have been programming for Java since Java 1.0.2. Up until a month ago, I'd have sworn you were right, but I've recently been bit HARD by JVM incompatibility. Our group has spent several years building a large, complex GUI application using Java. The original development was with Java 1.2, which then was updated to Java 1.3.1. (We'd actually prefer to use Java 1.4, but we haven't had time to fully certify the app for Java 1.4.) I'm the Lead Integration Engineer, and while Windows has been our primary development and testing platform, I've also been testing compatibility on Linux as well. Suffice to say, both of those platforms are very well supported by Sun, and very inter-compatible. A month ago we were given a requirement to support our application on Solaris -- should be a no-brainer, right? WRONG! It turns out that even though we were using only Sun's JVMs, and no IDE-specific libraries, our developers had inadvertently depended upon AWT capabilities that are only present with the Windows and Linux JVMs. Makes the whole thing look flipping ugly on Solaris. So now we're going back and putting in Solaris-only code to fix the things that should have been there in the JVM.
I'm not surprised that the Sun developers would feel that Solaris is not a priority platform for Sun, at least for AWT/Swing development. Sun doesn't market Solaris for office/desktop deployment. Developer workstations? Maybe, but their focus is really on selling big iron servers, not client hardware -- they ceded that market to Microsoft years ago.
One other comment on your test: Using the optimizer (-O3) with GCC, your code effectively goes from:
To this:
So what you're showing is the efficiency of the GCC optimizer on an otherwise useless chunk of code. Hardly a fair test.
I ran your test on my PIII/600 and Athlon XP 1800, running RHL 8.0, Sun Java 1.4.1, and GNU Java 3.2. Here are my results:
Note that I ran the Java test using java -server Test.java; I found the server JVM to be faster for this code than the client JVM.
So on my systems, for this test program, unoptimized Java is faster than unoptimized C, optimized C is 2.5 times faster than optimized Java, and GCJ is too immature to bother with. This matches my experience (7+ years Java) and my expectations. If I need to do numerical computations, there are faster languages than Java. On the other hand, if I'm doing distributed applications, where network bandwidth and latency are apt to be factors, Java will be as fast as C, and much easier to code reliably, given the built-in support for threading. And on the gripping hand, since I'm more productive in Java than in C, and since Java doesn't have to be recompiled for every platform, Java is probably the better language -- for my purposes. You can use whatever you want to use.