I thought SSH only dealt with secure remote shells, while Kerberos provides a programmatic API.
Kerberos is used as an optional authentication component with various database vendors, transaction processors, etc. I've never seen mention of SSH as an option for any of the tools I've used.
Does anyone have examples of open and commercial source products that use SSH for centralized authentication the way Kerberos is?
If it took "thousands of hours" to develop the obvious, I shudder to think what their bottom line will be when they tackle something complex.
I fully agree with RMS -- these idiotic "patents" on the obvious have got to go. The patent office's approach of letting the courts settle the details does *not* work unless your sole purpose is to award all control to those with money to spend on lawyers -- money that would better be spent on developing the next technology advance.
I broke my wrist about 3 years ago, and though it healed pretty good, I've become much more sensitive to wrist-stress. In fact, I can't use a flat keyboard for more than about 30-60 minutes before I start cramping up. If I persist, within about 4-6 hours the pain is severe enough that I just can't type for a day or two.
The only thing that helped for me was a (shudder!) Microsoft Natural Keyboard -- I've worn out two so far. Unfortunately they're pretty much impossible to find anymore, and the key placement and cap size on the so-called Elite are too small for my hands, and the funky arrow key placement is just plain annoying. The really irritating thing is the Elite was supposedly designed to "save desk space", yet it's barely an inch narrower than the original!
I've tried a Micro Innovations as a replacement, but without the hump in the middle of the keyboard, it doesn't help nearly as much.
Someone at work has a Logitech keyboard that looks like it might be suitable -- I sure hope so 'cause my last functioning Natural is starting to feel kind of mushy, and I haven't been able to find any more Naturals in the past couple months to replace it.
Why all the keyboards? I learned to type on an old manual Underwood typewriter and never lost the habit of hammering the keys. The only keyboard I didn't burn out within two years was a genuine IBM AT keyboard. Pity you can't get an ergonomic/wave keyboard with the same build quality -- I'd gladly pay $200 for it if it felt good and lasted a few years!
My understanding is the RSA issue is primarily a legal one. There are stronger algorithms which were developed in western Canada and overseas in Ireland which aren't allowed to be used in software distributed in US/Canada.
If you try to download their encryption, you are directed to RSAs US-based website.
I've had no problems with JDBC or JFC using IBM JDK 1.1.8. I do cross-version tests using Borland's 1.1.6 on NT, IBM JDK 1.1.8 on NT, IBM JDK 1.1.8 on Linux, and had also been using a JavaSoft JDK 1.1.8 on NT. The 1.1.6 JDKs periodically behave oddly with JFC, but that isn't surprising as it's technically downlevel from what JFC requires (I was actually surprised it worked at all with 1.1.6.)
I have had a lot of problems with JFC under Gnome, but it works properly with KDE and fvwm2. I found issues with the Triteal CDE itself with my latest kernel upgrades, but that affected everything -- not just the JDKs.
The only "bug" I found with IBM's JDK is present on both the NT and Linux versions: it gave me warnings/errors on code that had been compiling clean for months. When I looked into the errors, I found out the IBM compilers were correct, and Sun's and Borland's hadn't been detecting and reporting the problem properly.
My only complaint with IBM JDK 1.1.8 for Linux is that it's performance is comparable to Borland's 1.1.6 on NT, taking about 3-4 times as long as their NT version to run the same application code. My guess is that the problem is my use of CPU-intensive long-running threads -- there might be an issue with the way threads are managed on Linux.
Speaking of CPU-intensive threads, I found I had to drop the thread priority to minimum in order to keep the GUI responsive under NT, but under Linux the GUI remains responsive even if I bump up the priority higher than default.
If this is a mission critical system, you should seriously consider putting together an RFQ that characterizes the application access, external interfaces, data volumes, and sketches out the major data domains. Choose the technology based on the application, rather than choosing the technology and trying to make the application fit.
No matter what you choose you will be spending a good chunk of money on hardware and maintenance staff. An good DBA with experience tuning the database you choose will be critical to success, as will an architect that can address the design issues *before* you invest in the development.
Most of my large RDBMS experience has been with Oracle 7.x and DB/2 on commercial SMP Unix systems. Both have performed quite well when properly tuned and administered. I've also used Sybase for mission-critical apps, but the ones I've worked on weren't that big (1-2GB total vs. a few hundred GB.) I do know of companies in the banking industry who use Sybase for large databases as, so I expect it could handle the load as well.
As others have pointed out, your key issues are likely to be backup and restore capabilities rather than a simple "which is better" issue.
I guess it's obvious that I wouldn't recommend an open source solution (Postgres, MySQL, et. al.) to a client in this situation. There are a lot of situations where I'd recommend open source, but large mission critical data repositories isn't one of them.
To me it's not an issue of whether an open source solution *could* handle the job -- it's that I don't have experience with deployments that *prove* it will work. I wouldn't consider products like MS SQL Server for the same reason.
Depends how you use it. Projects I work on are always cross-platform, usually some variant of Unix and NT. What we do is create an include file that lists the source files, a makefile for the Unix side, and a makefile.mak for the NT side. The top-level makefile has targets that invoke each of the subdirectory makes. The most likely thing to burn you is that it's natural to use the directory names of the sub-projects as the names of the top-level make targets, and that doesn't work (changing the source files always updates the timestamp of the directory, so M$ nmake doesn't chase down the sub-project build.)
On NT, create a top-level project using the existing makefile.mak, and sub-projects for the subdirectories. You can select your top-level project to build everything, or individual sub-projects as necessary.
Personally I just use MSVC for debugging -- I do the actual builds using command line windows and the MKS utilities. Setting up the whole project under MSVC and then trying to port to cross platform makefiles takes much more time than starting with your own makefiles and wrapping M$ project files around them -- the makefiles generated by MSVC have platform-specific directives and really don't look much like makefiles if you let MSVC manage them directly.
I gotta admit -- M$ IDE is far, far ahead of most Linux/Unix tools for debugging. Kind of irritates me that *nix platforms still haven't got such functionality unless you look at the multi-K$ price range, and even then only if you've got a truly obscene amount of memory so that the multiple debug and executable processes don't thrash themselves to death.
Yeah, yeah -- xdb, dbx, gdb, yada yada -- I've got several years experience with them, and only 2-3 years with MSVC, but it only took 6 months to convince me the M$ debug environment was a much cleaner solution. It gets really addictive to be able to step-trace through code as quick as you can hit the function keys, rather than waiting for the 0.5-2.0 second lag with the *nix debuggers, and I have found nothing under *nix that lets me set watch points over memory regions the way I can with MSVC (nothing else is anywhere near so handy for tracking down that rogue piece of code that's overwriting memory it shouldn't be touching!)
Big projects? Currently working on one that's well over 500K lines, expected to exceed 1M during the next year. No debug problems on NT or *nix so far, other than the ever increasing memory requirements during debugs -- and the ever decreasing screen space.
Try running on NT with 128M or more of memory. I've never found any development environment stable on Win95/98 -- it's a deployment platform, not a development platform. (Personally I just use it for videogames and refer to it as my Wintendo box.)
I've found JBuilder, VAJava, and the Symantec products to be equally stable under NT. The issues for choosing between them have more to do with your work style:
1. I'm not a Mac user, and don't care for the Symantec interface. Maybe there's no correlation between their Mac work and their interface, but I found their interface inconvenient. Other users with different habits will have the opposite opinion.
2. VAJava has it's good points, but when you're trying to modify a base class it's really irritating and time consuming to have it flag errors all over your class hierarchy when you modify a method or member, knowing ahead of time that those issues will crop up. It's nice to have them tracked, but it would be far more efficient if you could control when those evaluations are done. Once you've got a few hundred derived classes, you can end up waiting several minutes for VAJava to "save" changes to a method while it updates it's dependancy/error trees. If you're working with stable base classes (purchased?), this same "problem" becomes the biggest benefit of VAJava.
3. JBuilder walks a nice line between the information analysis of VAJava and traditional IDEs that just integrate "make" style tools with an editor, error highlighter, and source debugger.
Personally I prefer JBuilder, but that's not to say the other environments are "bad". They've all worked comfortably with project in the 80-100K line range, provided that they have enough memory.
I'm just hoping M$ doesn't leverage their investment to cancel the Linux port of JBuilder -- it's one of the few key products that force me to keep a WinNT box around (other than customer demands for WinXX development.)
I haven't tried the other distos (no time!), but I have not encountered the RPM problems dynamo describes for RedHat. I *did* have a similar problem installing an upgrading RedHat with a non-RPM installation of XFree86 (it didn't detect the non-RPM installation in/usr/local), but it was not that difficult to replace the RPM version with the one I wanted.
RPMs aren't magic, and they are *not* required for adding software to a RedHat box. But if you want to mix and match installation methods, you really need to know what your system is doing during those installations. Bypassing RPMs is like extracting an archive on WinXX instead of running the installer -- things get missed, but can be dealt with manually if you're patient enough and not afraid of the registry editor. (Of course with a Wintendo game system it's unstable no matter how you install the software, but that's an irrelevant rant...)
Stability? I don't know what people are complaining about. I haven't had any stability problems at all, just the occasional config error (always been my own fault.) After many years of working with production *nix systems, it's usually easy to tell whether I've encountered a stability problem or if I've just screwed something up. 99% of the time it's my fault, not the system's.
I'm quite certain I could screw up any distro by installing software in unexpected locations, forgetting a few symlinks, or otherwise botching the procedures. I don't try to blame the vendor for those problems -- if it worked out of the box and I broke it, there's no one to blame except the guy sitting in my chair.
Rather than argue about it, I just sent the following to MetroWerk's sales department:
I use RedHat 5.2 Linux and was going to buy a copy of CodeWarrior until you decided to *not* support other distributions. Other people I work with use Debian, Slackware, SuSE, and Caldera. There are other distros as well, but if you are going to participate in the kind of balkanization that cripples the major Unix platforms I feel I have no choice but to keep looking for another vendor's solution.
Should you decide to support (at least) the other major distributions I will reconsider my decision.
No, it's not the first time I've heard a critique of Java's speed, nor of the bugs with AWT/JFC.
I spent some time with Sun's 1.1.6 under NT and it did suck for performance. IBM VAJava 1.0 was even worse, though 1.1 fixed most of the problems. When I started using Borland's IDE, I found that the VM makes a huge difference in performance -- non-GUI code I'd been writing that took over 20 minutes to run under IBM and Sun ran in less than 3 minutes under Borland. We've also tested HotSpot, and found that it boosts performance even more.
The biggest problem under Linux is that compared to these tuned VM/JIT environments for *nix and NT, Blackstone's JDK absolutely sucks for performance. Given that slashdot is largely a Linux community, I'm not surprised people have serious performance issues, as most of their Java experience is likely to be with Blackstone.
I'm not knocking Blackstone, it's just hasn't been tuned as thoroughly and doesn't have a real JIT compiler.
Code style can make a huge difference with server-type code, particularly if you are getting a lot of implicit object construction with methods that create value wrappers rather than "caching" those wrappers with private members. It costs more memory, and occasionally increases code complexity (modifiers have to clear the "cache" member so that the accessor knows to recreate it with the new value). Some simple changes in your code along these lines can improve performance by an order of magnitude, though they are not obvious necessities.
My key point on performance is still that the cost reduction in development and maintenance more than covers the costs of extra hardware to deploy the software. This doesn't help the home computing and OSS developer's that aren't being paid for their work, but it's a huge factor in which language corporations use. I don't have actual statistics, but if you can save the cost of even one maintenance developer at $45K/year (or more) with Java, that buys some pretty serious hardware improvements. When you're talking apps that require a team of 50 for C/C++/??? and only 10-20 in Java, you are really talking about an awful lot of money that can be rolled into hardware. It may be cruel, but I think we're starting to see IS departments getting hit by the same cost improvements from computers that the support and operational staff did over the last 5-10 years.
Sun has not refused to open up Java. What they have done is recognized that the 5-10 year cycle for most standards body is too slow to be useful, and often results in standards that no one implements, like the full version of ANSI SQL. They also attempted to submit it as a standard, only to have the rules changed half way through the process. They have done a tremendous job of refereeing feedback from different application and tool developers, and integrating the most useful concepts in the development stream. Take a look at some of the submissions from the OMG for collections (which had a lot of SQL-specific baggage), then take a look at the JDK 1.2 implementation. Modulus' InterAgent technology submissions have had their impact on messaging, and I have no doubt that the clean breadth of JDBC was enhanced by suggestions from people who are fed up with the hassles of using tools like ODBC.
HP has not fractured Java -- yet. Personally I am far more concerned by the recent rulings in the American courts in Sun vs. Microsoft than I am about HP. As much as I like HP's hardware (and HP-UX), the only place I've ever seen software developed for their systems were for telecom companies and as data-capture managers on manufacturing floors.
IBM is only one of many players in the Java world. They rightly recognized that providing easy front-end access to their big iron was the best way to maintain and possibly grow the sales of mainframes and large AIX systems. If you think they just did it for publicity, you are sadly mistaken.
Red Hat, et al are only relevant if you think Java was created for the sole purpose of "killing" Microsoft. If that's all you see in Java, it's no wonder you think it's dead.
Slow. Buggy. Ugly. You must be playing devil's advocate, because you are the only person I have ever heard make such statements about Java. I work with broad-based teams with experience in C, C++, messaging systems, transaction processing, mainframes, yada, yada, yada -- every one of them was very quick to see the benefits of Java. The closest I've heard to your views were from a Smalltalk programmer who tells me that language has had Java's functionality for several years now.
As for the server side you can use C/C++ or whaterver else. But with C/C++ you need to rely on non-portable libraries to get threading support, and I can tell you from personal experience that there are some pretty serious compatibility issues with pthreads implementations from Sun, IBM, DEC/Compaq, HP, and Linux. Win32 is a completely different code branch. The development, testing, and maintenance costs of such software compared to the issues of "performance" with Java are more than adequate to cover the cost of massive 8- and 16-way SMP boxes which more than compensate for any performance differences.
The only issues I've encountered with write-once run-anywhere Java have been with the GUI, not with the code layers application servers get written in. The sole exception to that is JDBC which can be a dog if you don't have a backend database that will let you take advantage of durable SQL statements, or if you don't have a database/driver that supports multiple connection sessions from a single client process.
You are right about Java not being used to develop "applications" if you mean desktop automation tools (word processing, spreadsheets, etc.) But if you think those are the only "real" applications, I suggest you contact some people working with large systems such as those in the telecom, manufacturing, or other industries where a "small" application only deals with a couple hundred concurrent users. Desktop PCs and workstations are just the front end to that world, they don't define it.
Slashdot Mirror
I thought SSH only dealt with secure remote shells, while Kerberos provides a programmatic API.
Kerberos is used as an optional authentication component with various database vendors, transaction processors, etc. I've never seen mention of SSH as an option for any of the tools I've used.
Does anyone have examples of open and commercial source products that use SSH for centralized authentication the way Kerberos is?
If it took "thousands of hours" to develop the obvious, I shudder to think what their bottom line will be when they tackle something complex.
I fully agree with RMS -- these idiotic "patents" on the obvious have got to go. The patent office's approach of letting the courts settle the details does *not* work unless your sole purpose is to award all control to those with money to spend on lawyers -- money that would better be spent on developing the next technology advance.
I broke my wrist about 3 years ago, and though it healed pretty good, I've become much more sensitive to wrist-stress. In fact, I can't use a flat keyboard for more than about 30-60 minutes before I start cramping up. If I persist, within about 4-6 hours the pain is severe enough that I just can't type for a day or two.
The only thing that helped for me was a (shudder!) Microsoft Natural Keyboard -- I've worn out two so far. Unfortunately they're pretty much impossible to find anymore, and the key placement and cap size on the so-called Elite are too small for my hands, and the funky arrow key placement is just plain annoying. The really irritating thing is the Elite was supposedly designed to "save desk space", yet it's barely an inch narrower than the original!
I've tried a Micro Innovations as a replacement, but without the hump in the middle of the keyboard, it doesn't help nearly as much.
Someone at work has a Logitech keyboard that looks like it might be suitable -- I sure hope so 'cause my last functioning Natural is starting to feel kind of mushy, and I haven't been able to find any more Naturals in the past couple months to replace it.
Why all the keyboards? I learned to type on an old manual Underwood typewriter and never lost the habit of hammering the keys. The only keyboard I didn't burn out within two years was a genuine IBM AT keyboard. Pity you can't get an ergonomic/wave keyboard with the same build quality -- I'd gladly pay $200 for it if it felt good and lasted a few years!
My understanding is the RSA issue is primarily a legal one. There are stronger algorithms which were developed in western Canada and overseas in Ireland which aren't allowed to be used in software distributed in US/Canada.
If you try to download their encryption, you are directed to RSAs US-based website.
I've had no problems with JDBC or JFC using IBM JDK 1.1.8. I do cross-version tests using Borland's 1.1.6 on NT, IBM JDK 1.1.8 on NT, IBM JDK 1.1.8 on Linux, and had also been using a JavaSoft JDK 1.1.8 on NT. The 1.1.6 JDKs periodically behave oddly with JFC, but that isn't surprising as it's technically downlevel from what JFC requires (I was actually surprised it worked at all with 1.1.6.)
I have had a lot of problems with JFC under Gnome, but it works properly with KDE and fvwm2. I found issues with the Triteal CDE itself with my latest kernel upgrades, but that affected everything -- not just the JDKs.
The only "bug" I found with IBM's JDK is present on both the NT and Linux versions: it gave me warnings/errors on code that had been compiling clean for months. When I looked into the errors, I found out the IBM compilers were correct, and Sun's and Borland's hadn't been detecting and reporting the problem properly.
My only complaint with IBM JDK 1.1.8 for Linux is that it's performance is comparable to Borland's 1.1.6 on NT, taking about 3-4 times as long as their NT version to run the same application code. My guess is that the problem is my use of CPU-intensive long-running threads -- there might be an issue with the way threads are managed on Linux.
Speaking of CPU-intensive threads, I found I had to drop the thread priority to minimum in order to keep the GUI responsive under NT, but under Linux the GUI remains responsive even if I bump up the priority higher than default.
If this is a mission critical system, you should seriously consider putting together an RFQ that characterizes the application access, external interfaces, data volumes, and sketches out the major data domains. Choose the technology based on the application, rather than choosing the technology and trying to make the application fit.
No matter what you choose you will be spending a good chunk of money on hardware and maintenance staff. An good DBA with experience tuning the database you choose will be critical to success, as will an architect that can address the design issues *before* you invest in the development.
Most of my large RDBMS experience has been with Oracle 7.x and DB/2 on commercial SMP Unix systems. Both have performed quite well when properly tuned and administered. I've also used Sybase for mission-critical apps, but the ones I've worked on weren't that big (1-2GB total vs. a few hundred GB.) I do know of companies in the banking industry who use Sybase for large databases as, so I expect it could handle the load as well.
As others have pointed out, your key issues are likely to be backup and restore capabilities rather than a simple "which is better" issue.
I guess it's obvious that I wouldn't recommend an open source solution (Postgres, MySQL, et. al.) to a client in this situation. There are a lot of situations where I'd recommend open source, but large mission critical data repositories isn't one of them.
To me it's not an issue of whether an open source solution *could* handle the job -- it's that I don't have experience with deployments that *prove* it will work. I wouldn't consider products like MS SQL Server for the same reason.
Depends how you use it. Projects I work on are always cross-platform, usually some variant of Unix and NT. What we do is create an include file that lists the source files, a makefile for the Unix side, and a makefile.mak for the NT side. The top-level makefile has targets that invoke each of the subdirectory makes. The most likely thing to burn you is that it's natural to use the directory names of the sub-projects as the names of the top-level make targets, and that doesn't work (changing the source files always updates the timestamp of the directory, so M$ nmake doesn't chase down the sub-project build.)
On NT, create a top-level project using the existing makefile.mak, and sub-projects for the subdirectories. You can select your top-level project to build everything, or individual sub-projects as necessary.
Personally I just use MSVC for debugging -- I do the actual builds using command line windows and the MKS utilities. Setting up the whole project under MSVC and then trying to port to cross platform makefiles takes much more time than starting with your own makefiles and wrapping M$ project files around them -- the makefiles generated by MSVC have platform-specific directives and really don't look much like makefiles if you let MSVC manage them directly.
I gotta admit -- M$ IDE is far, far ahead of most Linux/Unix tools for debugging. Kind of irritates me that *nix platforms still haven't got such functionality unless you look at the multi-K$ price range, and even then only if you've got a truly obscene amount of memory so that the multiple debug and executable processes don't thrash themselves to death.
Yeah, yeah -- xdb, dbx, gdb, yada yada -- I've got several years experience with them, and only 2-3 years with MSVC, but it only took 6 months to convince me the M$ debug environment was a much cleaner solution. It gets really addictive to be able to step-trace through code as quick as you can hit the function keys, rather than waiting for the 0.5-2.0 second lag with the *nix debuggers, and I have found nothing under *nix that lets me set watch points over memory regions the way I can with MSVC (nothing else is anywhere near so handy for tracking down that rogue piece of code that's overwriting memory it shouldn't be touching!)
Big projects? Currently working on one that's well over 500K lines, expected to exceed 1M during the next year. No debug problems on NT or *nix so far, other than the ever increasing memory requirements during debugs -- and the ever decreasing screen space.
Try running on NT with 128M or more of memory. I've never found any development environment stable on Win95/98 -- it's a deployment platform, not a development platform. (Personally I just use it for videogames and refer to it as my Wintendo box.)
I've found JBuilder, VAJava, and the Symantec products to be equally stable under NT. The issues for choosing between them have more to do with your work style:
1. I'm not a Mac user, and don't care for the Symantec interface. Maybe there's no correlation between their Mac work and their interface, but I found their interface inconvenient. Other users with different habits will have the opposite opinion.
2. VAJava has it's good points, but when you're trying to modify a base class it's really irritating and time consuming to have it flag errors all over your class hierarchy when you modify a method or member, knowing ahead of time that those issues will crop up. It's nice to have them tracked, but it would be far more efficient if you could control when those evaluations are done. Once you've got a few hundred derived classes, you can end up waiting several minutes for VAJava to "save" changes to a method while it updates it's dependancy/error trees. If you're working with stable base classes (purchased?), this same "problem" becomes the biggest benefit of VAJava.
3. JBuilder walks a nice line between the information analysis of VAJava and traditional IDEs that just integrate "make" style tools with an editor, error highlighter, and source debugger.
Personally I prefer JBuilder, but that's not to say the other environments are "bad". They've all worked comfortably with project in the 80-100K line range, provided that they have enough memory.
I'm just hoping M$ doesn't leverage their investment to cancel the Linux port of JBuilder -- it's one of the few key products that force me to keep a WinNT box around (other than customer demands for WinXX development.)
I haven't tried the other distos (no time!), but I have not encountered the RPM problems dynamo describes for RedHat. I *did* have a similar problem installing an upgrading RedHat with a non-RPM installation of XFree86 (it didn't detect the non-RPM installation in /usr/local), but it was not that difficult to replace the RPM version with the one I wanted.
RPMs aren't magic, and they are *not* required for adding software to a RedHat box. But if you want to mix and match installation methods, you really need to know what your system is doing during those installations. Bypassing RPMs is like extracting an archive on WinXX instead of running the installer -- things get missed, but can be dealt with manually if you're patient enough and not afraid of the registry editor. (Of course with a Wintendo game system it's unstable no matter how you install the software, but that's an irrelevant rant...)
Stability? I don't know what people are complaining about. I haven't had any stability problems at all, just the occasional config error (always been my own fault.) After many years of working with production *nix systems, it's usually easy to tell whether I've encountered a stability problem or if I've just screwed something up. 99% of the time it's my fault, not the system's.
I'm quite certain I could screw up any distro by installing software in unexpected locations, forgetting a few symlinks, or otherwise botching the procedures. I don't try to blame the vendor for those problems -- if it worked out of the box and I broke it, there's no one to blame except the guy sitting in my chair.
Rather than argue about it, I just sent the following to MetroWerk's sales department:
I use RedHat 5.2 Linux and was going to buy a copy of CodeWarrior until you decided to *not* support other distributions. Other people I work with use Debian, Slackware, SuSE, and Caldera. There are other distros as well, but if you are going to participate in the kind of balkanization that cripples the major Unix platforms I feel I have no choice but to keep looking for another vendor's solution.
Should you decide to support (at least) the other major distributions I will reconsider my decision.
No, it's not the first time I've heard a critique of Java's speed, nor of the bugs with AWT/JFC.
I spent some time with Sun's 1.1.6 under NT and it did suck for performance. IBM VAJava 1.0 was even worse, though 1.1 fixed most of the problems. When I started using Borland's IDE, I found that the VM makes a huge difference in performance -- non-GUI code I'd been writing that took over 20 minutes to run under IBM and Sun ran in less than 3 minutes under Borland. We've also tested HotSpot, and found that it boosts performance even more.
The biggest problem under Linux is that compared to these tuned VM/JIT environments for *nix and NT, Blackstone's JDK absolutely sucks for performance. Given that slashdot is largely a Linux community, I'm not surprised people have serious performance issues, as most of their Java experience is likely to be with Blackstone.
I'm not knocking Blackstone, it's just hasn't been tuned as thoroughly and doesn't have a real JIT compiler.
Code style can make a huge difference with server-type code, particularly if you are getting a lot of implicit object construction with methods that create value wrappers rather than "caching" those wrappers with private members. It costs more memory, and occasionally increases code complexity (modifiers have to clear the "cache" member so that the accessor knows to recreate it with the new value). Some simple changes in your code along these lines can improve performance by an order of magnitude, though they are not obvious necessities.
My key point on performance is still that the cost reduction in development and maintenance more than covers the costs of extra hardware to deploy the software. This doesn't help the home computing and OSS developer's that aren't being paid for their work, but it's a huge factor in which language corporations use. I don't have actual statistics, but if you can save the cost of even one maintenance developer at $45K/year (or more) with Java, that buys some pretty serious hardware improvements. When you're talking apps that require a team of 50 for C/C++/??? and only 10-20 in Java, you are really talking about an awful lot of money that can be rolled into hardware. It may be cruel, but I think we're starting to see IS departments getting hit by the same cost improvements from computers that the support and operational staff did over the last 5-10 years.
Interesting opinions, but...
Sun has not refused to open up Java. What they have done is recognized that the 5-10 year cycle for most standards body is too slow to be useful, and often results in standards that no one implements, like the full version of ANSI SQL. They also attempted to submit it as a standard, only to have the rules changed half way through the process. They have done a tremendous job of refereeing feedback from different application and tool developers, and integrating the most useful concepts in the development stream. Take a look at some of the submissions from the OMG for collections (which had a lot of SQL-specific baggage), then take a look at the JDK 1.2 implementation. Modulus' InterAgent technology submissions have had their impact on messaging, and I have no doubt that the clean breadth of JDBC was enhanced by suggestions from people who are fed up with the hassles of using tools like ODBC.
HP has not fractured Java -- yet. Personally I am far more concerned by the recent rulings in the American courts in Sun vs. Microsoft than I am about HP. As much as I like HP's hardware (and HP-UX), the only place I've ever seen software developed for their systems were for telecom companies and as data-capture managers on manufacturing floors.
IBM is only one of many players in the Java world. They rightly recognized that providing easy front-end access to their big iron was the best way to maintain and possibly grow the sales of mainframes and large AIX systems. If you think they just did it for publicity, you are sadly mistaken.
Red Hat, et al are only relevant if you think Java was created for the sole purpose of "killing" Microsoft. If that's all you see in Java, it's no wonder you think it's dead.
Slow. Buggy. Ugly. You must be playing devil's advocate, because you are the only person I have ever heard make such statements about Java. I work with broad-based teams with experience in C, C++, messaging systems, transaction processing, mainframes, yada, yada, yada -- every one of them was very quick to see the benefits of Java. The closest I've heard to your views were from a Smalltalk programmer who tells me that language has had Java's functionality for several years now.
As for the server side you can use C/C++ or whaterver else. But with C/C++ you need to rely on non-portable libraries to get threading support, and I can tell you from personal experience that there are some pretty serious compatibility issues with pthreads implementations from Sun, IBM, DEC/Compaq, HP, and Linux. Win32 is a completely different code branch. The development, testing, and maintenance costs of such software compared to the issues of "performance" with Java are more than adequate to cover the cost of massive 8- and 16-way SMP boxes which more than compensate for any performance differences.
The only issues I've encountered with write-once run-anywhere Java have been with the GUI, not with the code layers application servers get written in. The sole exception to that is JDBC which can be a dog if you don't have a backend database that will let you take advantage of durable SQL statements, or if you don't have a database/driver that supports multiple connection sessions from a single client process.
You are right about Java not being used to develop "applications" if you mean desktop automation tools (word processing, spreadsheets, etc.) But if you think those are the only "real" applications, I suggest you contact some people working with large systems such as those in the telecom, manufacturing, or other industries where a "small" application only deals with a couple hundred concurrent users. Desktop PCs and workstations are just the front end to that world, they don't define it.