If you think non-compete with Microsoft is tough, imagine non-compete with IBM (and of course any affiliates;-)! The company I worked for was bought out by IBM and one of these lovely non-competes floated my way.
I feel for people in this situation. Big IP based companies have a vested interest in having as wide a non-compete agreement as possible. There is also a strong disincentive for them to motive the legal terms of the agreement just because one person won't sign them (the legal bills for having to go over modifications alone are horrendous). My non-compete finally did get modified (by myself) but only after I was told by several company officers and lawyers that, "it couldn't be modified in any way."
Now, from what I was told by my own legal counsel, non-compete which are overly broad are tough to enforce, because they cannot be used to prevent people from finding gainful employment. Also, if you can demonstrate that you signed the agreement under duress (i.e. "We will fire you if you don't sign it.") they are not legally enforce it. So there are ways to get around them.
So, more than likely, there WAS something fishy about what this company was doing, otherwise Microsoft wouldn't have been able to excert this kind of leverage on them.
21264's are currently available at 700MHz. We don't know what speed the IA64's are going to be going at (600MHz is at best an educated guess). Even if 600MHz does prove to be true, the IA64 architecture has unique benefits when it comes to doing lots of 64-bit integer math on large data sets. Intel actually has a paper on Itanium's capabilities for SSL encryption/decryption. You'll note that they're quoting performance for a 660MHz Itanium, which suggests they think that's a reasonable target.
Anyway, you'll notice in the document that the 21264 and 21364 both only have a single pipeline for 64-bit integer multiplies, while the Itaniam has a dual pipeline. Now, there are differences in the pipelines, but that suggests that an Alpha would have to be going at 2x the clock of it's Itanium competitor in order to match it's performance. Intel's own analysis suggests a 21264 takes 1,800 cycles to do what the Itanium does in 1,220. So based on that, the Alpha would have to be going at roughly 150% the clock of the IA64 to match it's performance.
We also have no idea what the price point would be for Itanium vs. Alpha. Certainly, the 21264 is one of the more expensive CPU's on the market, but I'm sure Itanium won't be cheap either. It seems likely though that Itanium will be fairly competitive with the 21264 on price.
All this is just speculation, but it does suggest that it's reasonable to at least allow for the possibility that the Itanium chip would actually be the best CPU out there (when it's released) for doing large amounts of 64-bit Integer math. If you're suggesting otherwise, you're either revealing insider information, or you think you know more than you do.
I disagree here. It is conceivable that IA-64 will do 64-bit integer arithmetic at speeds equal or exceeding an Alpha (most 64-bit integer math work can take advantage of all the IU's in the EPIC architecture). It is also conceivable that the IA-64 will be competitively priced with an Alpha. In such circumstances I'd be inclined to say IA-64 would be pretty good bang for the buck.
I got my SO an iBook (with wireless LAN) for Christmas. She's pretty happy with it, but I've been considering putting Linux on it. She's used Linux on my computer without much difficulty, so I'm not so concerned about usability issues, but I am concerned about hardware issues, and of course the ability to dual boot. I checked out LinuxPPC's site, and dual boot seems like a manageable issue, but I was wondering if you could comment on iBook hardware support.
If you're doing mostly 64-bit integer math, you'll wan't an ISA that supports operations on 64-bit integers. Standard PPC and x86 chips do not have that (IBM has some 64-bit PPC chips/systems out there).
I think you'll find Alpha will kick butt, with Sparc being another potential contender (probably too pricy for the net benefit).
I'd say he'd definitely be better off with a chip which can do 64-bit integer arithmetic (assuming his comments about 64-bit integers are correct) in a single cycle. That means basically Alpha, Sparc, and MIPS (there are loads of other options, but these are the closes to commidity chips, and I use that term loosely;-). Bang for the buck wise, I'd say Alpha is probably the best of those three.
Things may change fairly quickly with the release of Intel's IA64 platform however. Whatever it's shortcomings, I bet it'll kick but in 64-bit integer arithmetic.
Well, C and C++ don't have automatic memory management, so you need something like reference counting.
Believe me, I'm well aware of the pros and cons of various stategies for managing memory. I'm just saying that the "breakthrough" these guys have come up with, isn't a breakthrough.
I can't believe these guys have gotten very far with their code. Otherwise, they'd realize a few things:
1) This document could be used to describe Win32, NeXTStep, BeOS, etc. (except without the B.S. about not having a kernel).
2) API's are not necessarily procedural as they describe. Certainly BeOS is a good example of this, as are the standard Java libraries.
3) OO languages do not "translate" down to procedural code. They can and do compile down to binaries, depending on the implementation. Binaries, btw, are written in the CPU's native instruction set, and there is basically no other way to do it (besides using an interpreter which is -gasp- written in binary). I can only imagine these guys are talking about the Cfront compiler which implemented the original C++, or the various freeware Eiffel and Sather compilers I've seen. Certainly there are other ways to go.
4) They are essentially saying that reference counting is better than automatic memory management. Certainly that is debatable, but guess what? Most OS API's are C or C++, so they already do reference counting to manage their objects. This is not a revolutionary concept.
5) This is an "operating system", but it relies on something else to provide hardware abstraction. Guess what, it's NOT an operating system then.
6) This project does what Taligent, Java, Oberon, Smalltalk, Inferno, etc. have either tried or succeeded in doing. Revolutionary? I don't think so.
But finally, by FAR the clearest indicator that this thing is not going to make it is that they don't have a very clear set of requirements. If you look at their "Goals", they are entirely "OS designer-centric" rather than based on some final result that the end user of the system is going to get. This is a clear sign that this is just an academic exercise with no real purpose. They don't even make a clear case for the problem that's out there which they are trying to solve.
Most RAID controllers will give you a battery backed-up write-back RAM cache. Depending on how you configure it, it will say that a write is committed as soon as it's in RAM. This accomplishes the same net effect without requiring all this modification of the OS.
Of course, lots of people don't like to configure their RAID controllers this way, because there is no redundancy for data in RAM, not to mention that the risk of failure is still higher than with a hard disk.
I hate to say it, but that article seems like it was written by someone who has not been out in the real world.
You have to have a fair degree of experience understanding programming before you start tackling an OS.
I'd start the guy off perhaps with a good teaching programming language, like Smalltalk or Python.
The best way to learn programming is by either reading the code of other's or doing it yourself.
Operating system design is actually NOT that cutting edge (at least compared to nanotechnology).
If you want to get him started in learning about how OS's work, I'd suggest Tanenbaum's work (despite his differences with Linus), particularly Distributed Operating Systems and it's predecessor, Modern Operating Systems.
If you want a cutting edge field that will lead naturally to nanotechnology, I'd suggest molecular biology and genetics.
While there are supposed to be fewer interfaces in a microkernel, it tends to require a great deal of sophistication to understand how to use them correctly.
Even if an interface isn't in the kernel, it still has to be somewhere. Getting it out of the kernel doesn't improve security in any way. If you need to talk to the filesystem, you still can misunderstand the filesystem's interface regardless of whether it's in the kernel or not.
In multi-server microkernel systems (such as HURD), you have additional complexity (and therefore security problems) with the interactions between the different servers that make up the operating system. You have to allow for each of the servers to be replaced with something which behaves entirely different (although hopefully fulfills the interface contracts... IF they are understood...;-). So, you make the problem worse rather than better.
First off, most security holes that I hear about tend NOT to be in the OS kernel's themselves, but rather userland software. The assumption that having more or less code running in the kernel changes security in any kind of a significant way is incorrect.
Secondly, pay attention to what Theo is saying: most security problems come from incorrect use of interfaces. In the microkernel world, you may indeed have fewer interfaces to the kernel, but understanding how to use those interfaces can be an extremely daunting tasks (just ask anyone who's hacked on Mach before). Furthermore, you still need interfaces to all the userland code that's running on top of the kernel (i.e., if you need to interface with the filesystem, it doesn't matter whether it's in the kernel or not, you can still get the interface wrong and thereby create a security problem). In HURD, for example, the interfaces and interdependancies between modules are MORE complex, particularly given that you have to allow for an infinite number of implementations of said interfaces.
Re:I have a question...
on
New Crypto-OS
·
· Score: 1
That's like saying that you should ban cars because bank robbers use them to escape persecution.
I think it's a fair principle that government should only invade an individual's privacy in the event that they have reason to believe it will yield proof of a crime. It does not make sense for the government to invade 100% of the population's privacy in order to prevent crimes committed by less than 0.1% of the population.
One way to prevent crime would be to have the government keep everyone's money and to have all transactions of said money be cleared by some agency (of course, this assumes somehow this agency is immune to corruption). This would actually eliminate a wide variety of crimes. Of course, you won't see a lot of people arguing for that!
While that is a fine solution (and I believe that's essentially a part of all the wireless protocols which are currently firing IP packets around), there are some obvious reasons why you'd like to deal with packet loss at the IP level. In particular, as you move to IPv6 you have lots of ways of managing packet flow at the IP level, and if your are also doing it at a lower level you end up with a lot of redundancy.
All these things were dealt with in the book, and admittedly could have be clarified better in the movie.
The weirding way was a Bene Gesserit skill, that was not allowed to be taught outside of their order. Jessica and Paul broke the rules.
Therefore it was not available to the Emporer.
The Emporer's troops are pretty good, although their presence on the planet is a limited deployment. Most of the troops are Harkonnen.
Due to the prevalent use of sheilds in the galaxy, the "best" weapons are actually not that handy against a raging horde of unshielded Fremen
Use of the weirding way is limited to specific contexts, and as I recall was mostly handy in one-on-one hand to hand combat.
The Guild controls all the "space ships" and are explicitly limited in their military capabilities. Beyond that, they're pretty worried about Paul destroying all the spice on the planet.
On some other points: in the book as I recall the Fremen were able to use the worms for a more significant tactical advantage. However, the worms could not actually invade the place grounds, as they were built on rock. The emporer's men were indeed shooting at the incomming Fremen, but their weapons DO have limited range (because projectiles have to be slow enough to enter a shield). Additionally, the worms provide pretty good protection against ranged attacks. Even if air strikes WERE available to the defending troops, it's VERY hard to call an air strike on a quickly advancing set of troops.
I agree all of this could have been made more clear in the series, but it's tough to fit in all kinds of military strategizing into a fast action sequence on TV. If you want a clearer picture, read the book.
David Lynch might be an impressive film maker, but I think it's fair to say the Dune movie he made butchered much of Herbert's great work. Lynch turned the story into his own unique style of story (which is very different from Herbert's). It might have been a good movie, but it lacked a great deal of the sophistication of the original story. I for one much prefered the mini-series, and that's probably partially because it's a medium that's better suited to the story.
As far as the special effects go... well, there were somethings which were better in the movie, but I wouldn't attribute this at all to David Lynch. That's the special effects department (and what I know of David Lynch suggests he had little involvement with that), and it's proof positive that low-budget digital effects (as are required for TV mini-series) are not always a replacement for traditional high-budget special effects that are done in movies. Having a bigger budget (remember to adjust for 16 years of inflation;-) really can ehlp.
As for Kyle MacLachlan's work in the movie... I don't know. I thought Kyle just plain didn't GET the role. It could be he was limited by the script. Either way, I think this was not one of his better performances, and I think it is arguable that the guy in the mini-series did a better job.
I read the article, and I assume the people who wrote it know more than I, but it seems odd to me that TCP would have so much trouble with wireless. Yes, wireless tends to lose more packets from data corruption, but I'd have thought this would be a common problem even over wires back in the days when TCP/IP was being developed.
The Olympics has become a sick distorted representation of what it once was. The money in it, from coporate sponsors has corrupted it's perspective to the point where it's more about promoting sponsors than atheletism (and atheletes).
I thought maybe the web would fix this to a degree by bypassing much of the sponsorship. Instead, the IOC has made a move which will surely push the Olympics in the direction of irrelevance. Sooner or later the corporate sponsors will see the ratings plunge and react accordingly. More importantly though, this is a powerful demonstration to anyone who might be interested in the Olympics just how central sponsors are to the Olympics.
I'm sorry, but I don't get what you're saying here. Yes, in C++ the the language enforces the calls of constructors and destructors to the super class. What does that matter? (Indeed, C++ destructors are very different from Java's finalizers.) All I was saying is that Java requires that in invoke the contstructor of your super class in the base class, so it's logical you have to invoke the finalize() method.
Now, I actually do understand the underlying principles that are making this all necessary, but I presume that to for anyone that does finalize() is far from a mystery. So, I'm trying to point out that even at a surface level it makes sense.
I'm really sorry that I brought the world to an end by not spelling comparable correctly for you. You must have been on the Internet for a whole 60 seconds before reading my post if that's the first time you hit upon someone who made a little spelling mistake.
I'm not a JSP monkey (I'd been doing Java development before JSP was even developed), and the specific case I was talking about was for a performance test at the JPL. I rewrote a Java math library that someone had converted from C. It was 20 times slower than the C code (mostly because it WAS a direct translation). I rewrote it (and yes, this required coming up with my own algorithms in some cases) and ended up with something that was almost as fast as the original C code. Said code was also significantly faster than a Java wrapper around the original C code (there's enough overhead in JNI that it doesn't necessarily provide a performance increase).
FYI, the reason all the commerical app servers have optional native layers (aside from the fact that it's part of the standard) is to allow capabilities you won't find inside the Java environment. Sometimes it's handy beause these additional capabilities signifcantly improve performance (say if you want to do shared memory for IPC). Sometimes it's handy because there'd be no other way to access these capabilities (say you want to use DirectPlay on Windows). But believe me, 99% of the code people write for their J2EE server is not native. That 99% runs plenty fast already.
In the speed department, I've written Java code that was 0-10% the speed of comperable C code. In the memory department, it depends on the size of the app. If the app is big enough the footprint of the JVM becomes negligable.
JNI is a pretty good and easy way to hook in the C code. IIOP is a pretty good way (notice I didn't use easy;-) to hook into C++. I'd argue that even in the C++ world, IIOP is about the easist way for C++ code compiled with one compiler can hook into C++ code compiled with another compiler, so you can't blame Java for that.
Slashdot Mirror
If you think non-compete with Microsoft is tough, imagine non-compete with IBM (and of course any affiliates ;-)! The company I worked for was bought out by IBM and one of these lovely non-competes floated my way.
I feel for people in this situation. Big IP based companies have a vested interest in having as wide a non-compete agreement as possible. There is also a strong disincentive for them to motive the legal terms of the agreement just because one person won't sign them (the legal bills for having to go over modifications alone are horrendous). My non-compete finally did get modified (by myself) but only after I was told by several company officers and lawyers that, "it couldn't be modified in any way."
Now, from what I was told by my own legal counsel, non-compete which are overly broad are tough to enforce, because they cannot be used to prevent people from finding gainful employment. Also, if you can demonstrate that you signed the agreement under duress (i.e. "We will fire you if you don't sign it.") they are not legally enforce it. So there are ways to get around them.
So, more than likely, there WAS something fishy about what this company was doing, otherwise Microsoft wouldn't have been able to excert this kind of leverage on them.
I could be mistaken, but I believe the specs for Ethernet-USB adaptors are pretty well defined.
21264's are currently available at 700MHz. We don't know what speed the IA64's are going to be going at (600MHz is at best an educated guess). Even if 600MHz does prove to be true, the IA64 architecture has unique benefits when it comes to doing lots of 64-bit integer math on large data sets. Intel actually has a paper on Itanium's capabilities for SSL encryption/decryption. You'll note that they're quoting performance for a 660MHz Itanium, which suggests they think that's a reasonable target.
Anyway, you'll notice in the document that the 21264 and 21364 both only have a single pipeline for 64-bit integer multiplies, while the Itaniam has a dual pipeline. Now, there are differences in the pipelines, but that suggests that an Alpha would have to be going at 2x the clock of it's Itanium competitor in order to match it's performance. Intel's own analysis suggests a 21264 takes 1,800 cycles to do what the Itanium does in 1,220. So based on that, the Alpha would have to be going at roughly 150% the clock of the IA64 to match it's performance.
We also have no idea what the price point would be for Itanium vs. Alpha. Certainly, the 21264 is one of the more expensive CPU's on the market, but I'm sure Itanium won't be cheap either. It seems likely though that Itanium will be fairly competitive with the 21264 on price.
All this is just speculation, but it does suggest that it's reasonable to at least allow for the possibility that the Itanium chip would actually be the best CPU out there (when it's released) for doing large amounts of 64-bit Integer math. If you're suggesting otherwise, you're either revealing insider information, or you think you know more than you do.
I disagree here. It is conceivable that IA-64 will do 64-bit integer arithmetic at speeds equal or exceeding an Alpha (most 64-bit integer math work can take advantage of all the IU's in the EPIC architecture). It is also conceivable that the IA-64 will be competitively priced with an Alpha. In such circumstances I'd be inclined to say IA-64 would be pretty good bang for the buck.
I got my SO an iBook (with wireless LAN) for Christmas. She's pretty happy with it, but I've been considering putting Linux on it. She's used Linux on my computer without much difficulty, so I'm not so concerned about usability issues, but I am concerned about hardware issues, and of course the ability to dual boot. I checked out LinuxPPC's site, and dual boot seems like a manageable issue, but I was wondering if you could comment on iBook hardware support.
If you're doing mostly 64-bit integer math, you'll wan't an ISA that supports operations on 64-bit integers. Standard PPC and x86 chips do not have that (IBM has some 64-bit PPC chips/systems out there).
I think you'll find Alpha will kick butt, with Sparc being another potential contender (probably too pricy for the net benefit).
I'd say he'd definitely be better off with a chip which can do 64-bit integer arithmetic (assuming his comments about 64-bit integers are correct) in a single cycle. That means basically Alpha, Sparc, and MIPS (there are loads of other options, but these are the closes to commidity chips, and I use that term loosely ;-). Bang for the buck wise, I'd say Alpha is probably the best of those three.
Things may change fairly quickly with the release of Intel's IA64 platform however. Whatever it's shortcomings, I bet it'll kick but in 64-bit integer arithmetic.
Well, C and C++ don't have automatic memory management, so you need something like reference counting.
Believe me, I'm well aware of the pros and cons of various stategies for managing memory. I'm just saying that the "breakthrough" these guys have come up with, isn't a breakthrough.
I can't believe these guys have gotten very far with their code. Otherwise, they'd realize a few things:
1) This document could be used to describe Win32, NeXTStep, BeOS, etc. (except without the B.S. about not having a kernel).
2) API's are not necessarily procedural as they describe. Certainly BeOS is a good example of this, as are the standard Java libraries.
3) OO languages do not "translate" down to procedural code. They can and do compile down to binaries, depending on the implementation. Binaries, btw, are written in the CPU's native instruction set, and there is basically no other way to do it (besides using an interpreter which is -gasp- written in binary). I can only imagine these guys are talking about the Cfront compiler which implemented the original C++, or the various freeware Eiffel and Sather compilers I've seen. Certainly there are other ways to go.
4) They are essentially saying that reference counting is better than automatic memory management. Certainly that is debatable, but guess what? Most OS API's are C or C++, so they already do reference counting to manage their objects. This is not a revolutionary concept.
5) This is an "operating system", but it relies on something else to provide hardware abstraction. Guess what, it's NOT an operating system then.
6) This project does what Taligent, Java, Oberon, Smalltalk, Inferno, etc. have either tried or succeeded in doing. Revolutionary? I don't think so.
But finally, by FAR the clearest indicator that this thing is not going to make it is that they don't have a very clear set of requirements. If you look at their "Goals", they are entirely "OS designer-centric" rather than based on some final result that the end user of the system is going to get. This is a clear sign that this is just an academic exercise with no real purpose. They don't even make a clear case for the problem that's out there which they are trying to solve.
Most RAID controllers will give you a battery backed-up write-back RAM cache. Depending on how you configure it, it will say that a write is committed as soon as it's in RAM. This accomplishes the same net effect without requiring all this modification of the OS.
Of course, lots of people don't like to configure their RAID controllers this way, because there is no redundancy for data in RAM, not to mention that the risk of failure is still higher than with a hard disk.
I hate to say it, but that article seems like it was written by someone who has not been out in the real world.
Some say application, others say operating system. I'd say it's arguably an elisp development toolkit. ;-)
If you want a cutting edge field that will lead naturally to nanotechnology, I'd suggest molecular biology and genetics.
First off, most security holes that I hear about tend NOT to be in the OS kernel's themselves, but rather userland software. The assumption that having more or less code running in the kernel changes security in any kind of a significant way is incorrect.
Secondly, pay attention to what Theo is saying: most security problems come from incorrect use of interfaces. In the microkernel world, you may indeed have fewer interfaces to the kernel, but understanding how to use those interfaces can be an extremely daunting tasks (just ask anyone who's hacked on Mach before). Furthermore, you still need interfaces to all the userland code that's running on top of the kernel (i.e., if you need to interface with the filesystem, it doesn't matter whether it's in the kernel or not, you can still get the interface wrong and thereby create a security problem). In HURD, for example, the interfaces and interdependancies between modules are MORE complex, particularly given that you have to allow for an infinite number of implementations of said interfaces.
That's like saying that you should ban cars because bank robbers use them to escape persecution.
I think it's a fair principle that government should only invade an individual's privacy in the event that they have reason to believe it will yield proof of a crime. It does not make sense for the government to invade 100% of the population's privacy in order to prevent crimes committed by less than 0.1% of the population.
One way to prevent crime would be to have the government keep everyone's money and to have all transactions of said money be cleared by some agency (of course, this assumes somehow this agency is immune to corruption). This would actually eliminate a wide variety of crimes. Of course, you won't see a lot of people arguing for that!
While that is a fine solution (and I believe that's essentially a part of all the wireless protocols which are currently firing IP packets around), there are some obvious reasons why you'd like to deal with packet loss at the IP level. In particular, as you move to IPv6 you have lots of ways of managing packet flow at the IP level, and if your are also doing it at a lower level you end up with a lot of redundancy.
All these things were dealt with in the book, and admittedly could have be clarified better in the movie.
On some other points: in the book as I recall the Fremen were able to use the worms for a more significant tactical advantage. However, the worms could not actually invade the place grounds, as they were built on rock. The emporer's men were indeed shooting at the incomming Fremen, but their weapons DO have limited range (because projectiles have to be slow enough to enter a shield). Additionally, the worms provide pretty good protection against ranged attacks. Even if air strikes WERE available to the defending troops, it's VERY hard to call an air strike on a quickly advancing set of troops.
I agree all of this could have been made more clear in the series, but it's tough to fit in all kinds of military strategizing into a fast action sequence on TV. If you want a clearer picture, read the book.
David Lynch might be an impressive film maker, but I think it's fair to say the Dune movie he made butchered much of Herbert's great work. Lynch turned the story into his own unique style of story (which is very different from Herbert's). It might have been a good movie, but it lacked a great deal of the sophistication of the original story. I for one much prefered the mini-series, and that's probably partially because it's a medium that's better suited to the story.
;-) really can ehlp.
As far as the special effects go... well, there were somethings which were better in the movie, but I wouldn't attribute this at all to David Lynch. That's the special effects department (and what I know of David Lynch suggests he had little involvement with that), and it's proof positive that low-budget digital effects (as are required for TV mini-series) are not always a replacement for traditional high-budget special effects that are done in movies. Having a bigger budget (remember to adjust for 16 years of inflation
As for Kyle MacLachlan's work in the movie... I don't know. I thought Kyle just plain didn't GET the role. It could be he was limited by the script. Either way, I think this was not one of his better performances, and I think it is arguable that the guy in the mini-series did a better job.
I read the article, and I assume the people who wrote it know more than I, but it seems odd to me that TCP would have so much trouble with wireless. Yes, wireless tends to lose more packets from data corruption, but I'd have thought this would be a common problem even over wires back in the days when TCP/IP was being developed.
Does anyone else see the humor in APL being used to do work on "natural languages"? ;-)
Of course, depending on how you look at it, APL is significantly more straightforward and natural than English.
The Olympics has become a sick distorted representation of what it once was. The money in it, from coporate sponsors has corrupted it's perspective to the point where it's more about promoting sponsors than atheletism (and atheletes).
I thought maybe the web would fix this to a degree by bypassing much of the sponsorship. Instead, the IOC has made a move which will surely push the Olympics in the direction of irrelevance. Sooner or later the corporate sponsors will see the ratings plunge and react accordingly. More importantly though, this is a powerful demonstration to anyone who might be interested in the Olympics just how central sponsors are to the Olympics.
I'm sorry, but I don't get what you're saying here. Yes, in C++ the the language enforces the calls of constructors and destructors to the super class. What does that matter? (Indeed, C++ destructors are very different from Java's finalizers.) All I was saying is that Java requires that in invoke the contstructor of your super class in the base class, so it's logical you have to invoke the finalize() method.
Now, I actually do understand the underlying principles that are making this all necessary, but I presume that to for anyone that does finalize() is far from a mystery. So, I'm trying to point out that even at a surface level it makes sense.
I'm really sorry that I brought the world to an end by not spelling comparable correctly for you. You must have been on the Internet for a whole 60 seconds before reading my post if that's the first time you hit upon someone who made a little spelling mistake.
I'm not a JSP monkey (I'd been doing Java development before JSP was even developed), and the specific case I was talking about was for a performance test at the JPL. I rewrote a Java math library that someone had converted from C. It was 20 times slower than the C code (mostly because it WAS a direct translation). I rewrote it (and yes, this required coming up with my own algorithms in some cases) and ended up with something that was almost as fast as the original C code. Said code was also significantly faster than a Java wrapper around the original C code (there's enough overhead in JNI that it doesn't necessarily provide a performance increase).
FYI, the reason all the commerical app servers have optional native layers (aside from the fact that it's part of the standard) is to allow capabilities you won't find inside the Java environment. Sometimes it's handy beause these additional capabilities signifcantly improve performance (say if you want to do shared memory for IPC). Sometimes it's handy because there'd be no other way to access these capabilities (say you want to use DirectPlay on Windows). But believe me, 99% of the code people write for their J2EE server is not native. That 99% runs plenty fast already.
Ooops. I meant 0-10% slower than comperable C code.
In the speed department, I've written Java code that was 0-10% the speed of comperable C code. In the memory department, it depends on the size of the app. If the app is big enough the footprint of the JVM becomes negligable.
;-) to hook into C++. I'd argue that even in the C++ world, IIOP is about the easist way for C++ code compiled with one compiler can hook into C++ code compiled with another compiler, so you can't blame Java for that.
JNI is a pretty good and easy way to hook in the C code. IIOP is a pretty good way (notice I didn't use easy