Todd Glassey <todd@lgt.com> writes:
Pardon the flame but I really have just about heard enough of this BS...
No one needs to listen to anything if they don't want to, Todd, but I think that some things need saying none the less. I think the old saying is: You can lead a horse to water, but you can't make him think, or something like that ...
This response came from Sun to Risks:
Date: Mon, 16 Oct 1995 21:22:40 -0700 From: Caveh.Jalali@eng.sun.com (Caveh Jalali) Subject: Re: Risks in Java
If we are going to "analyze" java security, let's keep in mind that there is an important distinction between the language (java) and the machinery which runs the java program.
Hmm, this is a very interesting prespective, coming from Sun Engineering as it were. The company that says that the Network is the machine, or somesuch. I always thought that security consisted of everything: hardware, software, and wetware. (Or it did the last time, I checked my handbook.) Admittedly this is a horrible inconvenience, especially when it comes to security.
Java is a general-purpose programming language along the lines of C/C++. So, there is no doubt that its expressive power overwhelms our theoretician's abilities to predict java-programs behavior -- this is where we start getting into the halting problem, computability and other black magic. Basically, i don't think we can "trust" programs written in any *useful* programming language.
Read: We can't trust Java programs.
This may well be true. But sloppy design, design which ignores the most basic difficulties cannot be brushed away by simply saying that "it exceeds theoretician's predictive abilitiies." That simply doesn't cut it. "Ignoring the obvious" is simply that. It's a planned process of "ignoring the obvious". One example of this that should serve as a useful case study is a recent problem which was brought to the Canadian public's attention just this week, on a program called the Fifth Estate. The CBC (Canadian Broadcasting Corporation) detailed a software code problem in one of AECL's (Atomic Energy of Canada Limited's) instruments which deliver penetrating radiation. The software which controlled the radiation dose, would periodically override the oncologist's calibration and deliver a radiation dose 100 times what was prescribed. This software "bug" literally killed wherever the machine was in use. A simple hardware solution engineered into the product as part of a redundancy check program would not only have saved many lives, but could have confirmed that there were serious code deficencies. A redundancy program which AECL did NOT have. Then again AECL did not consider that it had to mathematically prove it's code either. So I guess, they "ignored the obvious" not once, but twice. A simple lesson can be learned here, one which I believe is applicable to Java. If your parameters are going to be that you cannot trust your production code, then you MUST engineer on that basis, that the production will not be trustworthy, rather than simply crying like Chicken Little, that mission critical applications must simply "live with" engineered inferiority. Or alternatively, another lesson could be pulled out: To avoid this problem, ensure that your code is mathematically provable or utilize appropriate hardware overrides. Case study, #2: Netscape. During their code design, they assumed that all servers on a network were trustworthy and would continue to be trustworthy. They designed their product on that basis. In fact, over time the very opposite will be true. As an exploitation algorithm propogates, the significant percentage of servers which are NOT trustworthy will begin to grow exponentially. The true assumption which Netscape should have started with is a simple one, and is the only assumption that ANY production house can start with: that the network has a reliable transport mechanism, one which will route around damage. That's it. Any other assumptions are poor design and engineering and are demonstrative of a misunderstanding of the environmental conditions in which the engineered product is expected to perform.
Dr. Fred, you seem to spend a lot of engery slamming Java and HotJava. Are you unaware that the HotJava Platform is the first generation pass at an inline extensible GUI harness. Underline the total concept "extensible GUI harness". This includes a series of tool functions to *help* perform secure messeging (like those supplied iun Netscape 2.0/Java.), but because of the enormity of the task and the number of facets on the face of this gem it will be some time before the final versions of the first generation will be available.
I can't speak for "Dr. Fred", but I always worry when people start to refer to something as a "gem", and start talking about the "enormity of the task". Especially if an engineer starts talking in such lyrical, flowery prose. Enormous tasks always lead to complexity which can never be solved by simple linear thinking. And the engineer from Sun is right, that it will be some time before first generation products are available. (This will certainly be the case if "mathematical proofs" become mandatory as part of an ACT in Action plan. )
No one else had been working on this piece of technology before SMCC started their effort. From the word floating about the SMCC labs they didn't even know what they had.
So rather than slamming them, SMCC, or their PR folks for
Well, I'd rather that marketers stick to marketing AFTER a product development cycle is completed. Generally, you would think (hopefully) that people who are technologists, just *might* have a better knowledge of what they have, (or don't have) wouldn't you? Maybe?? Or maybe not ... After all you wouldn't want some kid, some little snotty brat, some kid who started playing around well over a decade ago -- when he was in his teens -- as a projadmin on one of Honeywell's Multiplexed Information and Computing Service beasts showing you up for your temerity? Or would you cry about the "kid" slamming you?
I hope that you understand my point?. The net/net is that OLTP needs to be scaleable to be a saleable commodity and without the ability to do "java-ish" like local applets... There is no clean way to do this,
Well if we're gonna bottom line it, and talk turkey, and leave Chicken Little back at the table, skewered as it were, I'll extend a helping hand. The net/net is really, really simple, a product that doesn't perform as advertised is not a saleable commodity. No one buys cars which don't start or cans that leak. Sure you can have a body by Pininfarina or one by Alcan but if the engineering isn't there under that beautiful skin then you don't have ANYTHING TO OFFER FOR VALUE.
As an aside - What blows my mind is the number of cycles people spend bitching and moaning about Java itself rather than working to create a better solution.
Well. It's just not my responsibility to create a solution. And I have a tendancy not to "bitch and moan". I might be one sarcastic castrating SOB, but bitchy and moany is not something I'm routinely accused of. I simply have a reputation for a degree of frankness. Nothing personal is meant by it. I'm actually a very nice person. Truly.;-I
I just want to say "Get a clue. Moan about something that is important and pertinent to the technologies at hand".
These comments are my own -
Appreciated. And I mean that with sincerity that your comments are appreciated. I understand that each person here DOES express their individual opinions. Sometimes some very strong opinions. Myself included. Generally, wallflowers will not find comfort on this list. We'll recommend that those people should stick to writing browser programs. Oops, scratch that last thought ...
Sincereley, Todd Glassey todd@lgt.com
Alice de 'nonymous ... ...just another one of those... P.S. This post is in the public domain. C. S. U. M. O. C. L. U. N. E.