Re: How Ada could have prevented the Red Code distributed denial of

Re: How Ada could have prevented the Red Code distributed denial of

[Larry Kilgallen]

In article <3B698522.EEE2A1F9@silver.jhuapl.edu>, Scott Ingram <scott@silver.jhuapl.edu> writes:
> Beelsebob wrote:
>> 
>> [origional message]
>> 
>> So your point is that you can use a buggy microsoft implementation of
>> C++ to write a virus.
>> 
>> Now then let me see... oh yes, you can use Ada (not even a buggy
>> implementation of it) to cause the Arian 5 rocket to try and turn
>> round in mid flight, and disintegrate into many tinny little burrning
>> pieces.....
> 
> My point exactly.  Ada will do what you tell it to do:  including
> telling an Ariane 5 to fly like an Ariane 4, even though it can't
> possibly do that.

That has the advantage that at least you can blame the failure on
management :-)

Re: How Ada could have prevented the Red Code distributed denial of

[Ted Dennison]

In article <Pine.GSO.4.30.0108071538190.29788-100000@scully>, David Lee Lambert
says...
>
>On Mon, 6 Aug 2001, Ted Dennison wrote:
>
>> That's a bogus comparison. You are thinking of Java's propensity to create
>> interpreted code. That has nothing to do with Ada. (Although I suspect a Java
>> expert could probably accomplish it with JINI and a natively-targeted Java
>> compiler. Remember, "printf" actually has to stop and interpret the input 
..
>One could use puts() instead:

That's not the issue. My points were:
a) Java's bytecode interpretation speed issues have nothing whatsoever to do
with Ada, any more than they do C. I repeat, *nothing*.
b) If I took the most natural language Y "hello world", an expert in language X
can most likely construct a quicker version for language X (even when X=Java and
Y=C, I suspect).  If you can turn around and do the same thing with tuned C and
a dumb Java implementation, you only provide *more* evidence of this.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: How Ada could have prevented the Red Code distributed denial of

[Larry Kilgallen]

In article <GHpu7E.4np.1.spenarn@spenarnc.xs4all.nl>, albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
> In article <3B693DE4.C3B42E03@yahoo.com>,
> CBFalconer  <cbfalconer@worldnet.att.net> wrote:
>><SNIP>
>>
>>I think you will find that GNU Ada is written in GNU Ada.  I KNOW
>>that PascalP is written in Pascal.  Neither is totally bug free,
>>although at time of release they were IMHO free of *known*
>>undocumented bugs.
> 
> You mean *none* of the unknown bugs where documented?

No, I think the meaning is "None of the known bugs are undocumented".
There is an important distinction between "documented" and "fixed".
As the time for release approaches, it is often better to document
a bug than to fix it (depending on severity).  That which we change,
we break, and in the end game there may be insufficient testing for
side effects of the last few changes.

Re: How Ada could have prevented the Red Code distributed denial of

[Ted Dennison]

In article <3B71C74E.505A8753@globetrotter.qc.ca>, Chris Wolfe says...
>So why not compare _comparable_ things: like a C++ compiler and
>library designed with safety in mind against Ada. Rather than a

Because this thread is about OS's and the C++ dialects which they have been
implemented in, vs. (standard) Ada. Clearly your wonderful non-standard dialect
of C++ was not used either for the system software in question. Perhaps it would
have been an equally good idea to use it, but that's not what the thread is
about.

>So we do the Ada thing: throw away the flexibility of the
>language to force everyone to play safe. In case you missed it,
>most C++ compiler also provide support for inline assembler: A)
>if I need it, I can get it. B) if I don't need it, I can stick
>with the safer stuff. Ada has a very different philosophy.

That's a odd complaint. Ada's just as flexible as C. You just have to announce
to the compiler (and not so incidently, the human source code reader) when you
are doing something unsafe, but its not prevented. Also *every* Ada compiler (as
opposed to "most" C++ compilers) has support for inline assembler. Its actually
in the standard. The Ada philosopy is indeed quite different from C's but its
not quite what you seem to think it is.

>>   2. You now have to prove that your Class Posix is fault free
>>      before you put it on an aircraft or in a medical instrument.
>
>Duh, and this was somehow skipped when producing the Ada
>libraries? I somehow fail to believe that Ada circumvents bugs in
>the functions provided by my operating system.

He probably shouldn't have brought this up, as it confuses just about everyone
who isn't familiar with safety-critical software. Debugging software and proving
it correct are two *very* different things. There's a whole lot of theory behind
safety critical software and software correctness proofs that you really have to
study for a while to understand. Bringing it into a discussion with folks who
are unfamiliar with it is just going to cause a lot of confusion.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: How Ada could have prevented the Red Code distributed denial of

[Larry Kilgallen]

In article <Hoxc7.3953$NJ6.15706@www.newsranger.com>, Ted Dennison<dennison@telepath.com> writes:

> are doing something unsafe, but its not prevented. Also *every* Ada compiler (as
> opposed to "most" C++ compilers) has support for inline assembler. Its actually
> in the standard.

Certainly you don't mean 13.8(8), which says:

	An implementation is not required to provide package
	System.Machine_Code.

Re: How Ada could have prevented the Red Code distributed denial of

[Ted Dennison]

In article <c78BbJ9nURZD@eisner.encompasserve.org>, Larry Kilgallen says...
>
>In article <Hoxc7.3953$NJ6.15706@www.newsranger.com>, Ted Dennison<dennison@telepath.com> writes:
>
>> are doing something unsafe, but its not prevented. Also *every* Ada compiler (as
>> opposed to "most" C++ compilers) has support for inline assembler. Its actually
>> in the standard.
>
>Certainly you don't mean 13.8(8), which says:
>
>	An implementation is not required to provide package
>	System.Machine_Code.

Doh! You're right (and he didn't even include the "An implementation may place
restrictions on code_statements" part). So in fact, the situation is pretty much
the same as C++, except that there is a standard way to do it if it *is*
supported. Not that that matters much, since the machine code itself is hardly
going to be portable...

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: How Ada could have prevented the Red Code distributed denial of

[Ted Dennison]

In article <8766bxx9mu.fsf@deneb.enyo.de>, Florian Weimer says...
>
>Ted Dennison<dennison@telepath.com> writes:
>
>> Can it? In Ada at least, I understand that potentially dynamic-dispatching
>> operations are really tough to inline. I suppose there could be something I
>> don't know about C++ that gets rid of that issue. Is there?
>
>The standard C++ container library does not use dynamic dispatching
>for containers, it even suggests not to subclass them.  The container
>library isn't very OOP.

Perhaps, but that would give it the ability to be inlined. So there is a postive
to that.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: How Ada could have prevented the Red Code distributed denial of

[Martin Ambuhl]

Ted Dennison wrote:
> 
> In article <3B71C74E.505A8753@globetrotter.qc.ca>, Chris Wolfe says...
> >So why not compare _comparable_ things: like a C++ compiler and
> >library designed with safety in mind against Ada. Rather than a
> 
> Because this thread is about OS's and the C++ dialects which they have been
> implemented in, vs. (standard) Ada. Clearly your wonderful non-standard dialect
> of C++ was not used either for the system software in question. Perhaps it would
> have been an equally good idea to use it, but that's not what the thread is
> about.
> 
> >So we do the Ada thing: throw away the flexibility of the
> >language to force everyone to play safe. In case you missed it,
> >most C++ compiler also provide support for inline assembler: A)
> >if I need it, I can get it. B) if I don't need it, I can stick
> >with the safer stuff. Ada has a very different philosophy.
> 
> That's a odd complaint. Ada's just as flexible as C. You just have to announce
> to the compiler (and not so incidently, the human source code reader) when you
> are doing something unsafe, but its not prevented. Also *every* Ada compiler (as
> opposed to "most" C++ compilers) has support for inline assembler. Its actually
> in the standard. The Ada philosopy is indeed quite different from C's but its
> not quite what you seem to think it is.
> 
> >>   2. You now have to prove that your Class Posix is fault free
> >>      before you put it on an aircraft or in a medical instrument.
> >
> >Duh, and this was somehow skipped when producing the Ada
> >libraries? I somehow fail to believe that Ada circumvents bugs in
> >the functions provided by my operating system.
> 
> He probably shouldn't have brought this up, as it confuses just about everyone
> who isn't familiar with safety-critical software. Debugging software and proving
> it correct are two *very* different things. There's a whole lot of theory behind
> safety critical software and software correctness proofs that you really have to
> study for a while to understand. Bringing it into a discussion with folks who
> are unfamiliar with it is just going to cause a lot of confusion.
> 

Taking your pronouncements as Gospel, I have removed comp.lang.c from
the Followup-To: list.  I suggest you do the same.

Re: How Ada could have prevented the Red Code distributed denial of

[Ted Dennison]

In article <3B73378B.EF7E2C10@home.com>, Warren W. Gay VE3WWG says...
>
>Bart.Vanhauwaert@nowhere.be wrote:
>> Don't be silly. Nothing is perfect. Any serious decision is a
>> trade-off. 
>
>You are correct that there are trade-offs. I guess what annoys 
>me is just how low the standard is for "good enough" in so 
>many circles. Microsoft's being one of the most offensive.

As near as I can tell, they actually take software design theory *far* more
seriously at Microsoft that most folks give them credit for. I think the issue
here is that Microsoft happens to be the world's biggest believers in the
time-tested "Worse is Better" design philosophy. (see
http://www.ai.mit.edu/docs/articles/good-news/subsection3.2.1.html ). This is
great for Microsoft, but no so great for things that need to be carefully
designed in, like security and reliablity. But then, they are a publicly-traded
company, so "great for Microsoft" trumps all other considerations for them. :-)

A particularly relevent excerpt: 
---
A further benefit of the worse-is-better philosophy is that the programmer is
conditioned to sacrifice some safety, convenience, and hassle...
---

Note that in this particular context, "programmer"="user". (They were talking
about programming languages and OS calls.).

another relevant part:
--- 
The lesson to be learned from this is that it is often undesirable to go for the
right thing first. It is better to get half of the right thing available so that
it spreads like a virus. Once people are hooked on it, take the time to improve
it to 90% of the right thing.
----

Again, great for Microsoft, crappy for security.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: How Ada could have prevented the Red Code distributed denial of

[Warren W. Gay VE3WWG]

Ted Dennison wrote:
> In article <3B73378B.EF7E2C10@home.com>, Warren W. Gay VE3WWG says...
> >Bart.Vanhauwaert@nowhere.be wrote:
> >> Don't be silly. Nothing is perfect. Any serious decision is a
> >> trade-off.
> >
> >You are correct that there are trade-offs. I guess what annoys
> >me is just how low the standard is for "good enough" in so
> >many circles. Microsoft's being one of the most offensive.
> 
> As near as I can tell, they actually take software design theory *far* more
> seriously at Microsoft that most folks give them credit for.

You may be right about this, but it's hard for us on the outside
to see much evidence of it ;-)

> I think the issue
> here is that Microsoft happens to be the world's biggest believers in the
> time-tested "Worse is Better" design philosophy. (see
> http://www.ai.mit.edu/docs/articles/good-news/subsection3.2.1.html ). This is
> great for Microsoft, but no so great for things that need to be carefully
> designed in, like security and reliablity. But then, they are a publicly-traded
> company, so "great for Microsoft" trumps all other considerations for them. :-)

Quite true. This is why they also don't give much consideration to fixing
problems on their platforms. They don't have to care, so it is easy for
them to say "just reinstall your software".  Instead, they'll offer some
small tweak in the next version (for you to buy), that somehow placates
the poor locked in customer..

> Again, great for Microsoft, crappy for security.

I think this is one _downfall_ that will eventually force them to put
more "quality" in. Before the Windows platform had TCP/IP access, this
was of no concern to them, and they pretty much could ignore security
(what a simple life it is, when we can do that on any platform ;-)

Now that M$ has to keep coming out with rapid patches to holes that 
keep being exploited, they may finally get to the point some day where
they may want to improve their image on this point, and treat security
with greater care.

But it is likely going to require more competition before they'll 
bring themselves to this point, so one keeps hoping that Apple 
will get their act together as competition. On the server side, I do
believe that they are feeling some pressure from Linux in this
regard, though Red Hat (by default) has been pretty lame in 
security, from what I can see.

In this vein, I'd love to see sendmail and bind/named done in 
Ada.  That would not solve all of the security issues, but at
least would eliminate most, if not all of the code exploit 
issues.
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: How Ada could have prevented the Red Code distributed denial of

[David Starner]

"Warren W. Gay VE3WWG" <ve3wwg@home.com> wrote in message
news:3B73FEA5.D4B46E89@home.com...
> In this vein, I'd love to see sendmail and bind/named done in
> Ada.  That would not solve all of the security issues, but at
> least would eliminate most, if not all of the code exploit
> issues.

I'd be more inclined to trust something battle-tested than something new,
even if the new program was written in Ada. For a lot of the stuff, Ada
would just turn a remote exploit into DOS (program failure by uncaught
exception), which is an improvement, but it's still a bug and a problem.

--
David Starner - dstarner98@aasaa.ofe.org
"The pig -- belongs -- to _all_ mankind!" - Invader Zim

Re: How Ada could have prevented the Red Code distributed denial of

[Warren W. Gay VE3WWG]

David Starner wrote:
> "Warren W. Gay VE3WWG" <ve3wwg@home.com> wrote in message
> news:3B73FEA5.D4B46E89@home.com...
> > In this vein, I'd love to see sendmail and bind/named done in
> > Ada.  That would not solve all of the security issues, but at
> > least would eliminate most, if not all of the code exploit
> > issues.
> 
> I'd be more inclined to trust something battle-tested than something new,
> even if the new program was written in Ada. For a lot of the stuff, Ada
> would just turn a remote exploit into DOS (program failure by uncaught
> exception), which is an improvement, but it's still a bug and a problem.

My concern David, is that for every bug fixed in the C/C++ versions of
these servers, how many more of the same are still unnoticed, and yet to
be exploited. I agree that a new untested version of the same servers
would bring out new problems initially. But it wasn't that long ago
that Bind 8 just came out, which IIRC, was "rewritten" anyway. My point
is that rewrites would have/will be - better in Ada. The current
state of the art seems to be to "battle-harden" the C/C++ exploits,
for the most part.

A newly written server done in Ada, would ramp up in security
quickly, and all of us could then focus on a smaller subset of the
remaining issues, IMHO.

-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: How Ada could have prevented the Red Code distributed denial of

[Warren W. Gay VE3WWG]

I just re-read what you wrote, and realized I misunderstood
the thrust of what you said.. so I'll re-reply, since I can't
retract the prior post.

David Starner wrote:
> 
> "Warren W. Gay VE3WWG" <ve3wwg@home.com> wrote in message
> news:3B73FEA5.D4B46E89@home.com...
> > In this vein, I'd love to see sendmail and bind/named done in
> > Ada.  That would not solve all of the security issues, but at
> > least would eliminate most, if not all of the code exploit
> > issues.
> 
> I'd be more inclined to trust something battle-tested than something new,
> even if the new program was written in Ada. For a lot of the stuff, Ada
> would just turn a remote exploit into DOS (program failure by uncaught
> exception), which is an improvement, but it's still a bug and a problem.

This indeed is an _improvement_, while a "bug and a problem". However,
I would much prefer this mode of operation, because this means that
the problem will get more immediate attention for a _fix_.

To some extent, the same DOS aspects apply to C/C++ code (aborts). 
Where there is no "signal", it either "corrupts", "ignores" or runs
"exploit code". But raising exceptions in Ada will hopefully provide 
notice before your system is exploited.

That is my primary reason for wishing.
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: How Ada could have prevented the Red Code distributed denial of

[cppwiz]

[Note: headers have been trimmed]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:Hoxc7.3953$NJ6.15706@www.newsranger.com...
> In article <3B71C74E.505A8753@globetrotter.qc.ca>, Chris Wolfe says...

<deleted>

> That's a odd complaint. Ada's just as flexible as C. You just have to
announce
> to the compiler (and not so incidently, the human source code reader) when
you
> are doing something unsafe, but its not prevented. Also *every* Ada
compiler (as
> opposed to "most" C++ compilers) has support for inline assembler. Its
actually
> in the standard...

The C++ standard guarantees that there is at least a platform in place for
inline assembler.
I don't see how its realistically possible to make a promise stronger than
that.

Unless I missed something, the Ada standard provides a similar guarantee for
inline assembler.

In both cases, the implementation can conform to the standard by providing
no inline assembler functionality.

Re: How Ada could have prevented the Red Code distributed denial of

[Stanley R. Allen]

Ted Dennison wrote:

> *every* Ada compiler (as
> opposed to "most" C++ compilers) has support for inline assembler. Its actually
> in the standard.

Ada does have a standard for inline assembler language (package System.Machine_Code).
But it is one of those features which, according to the standard, is not required
to be implemented for a 'conforming' implementation of Ada.  See

http://www.adahome.com/rm95/rm9x-01-01-03.html   (paragraph 10)
http://www.adahome.com/rm95/rm9x-13-08.html      (paragraph 8)

--
Stanley Allen
mailto:Stanley_R_Allen-NR@Raytheon.com

Re: How Ada could have prevented the Red Code distributed denial of

[Ted Dennison]

In article <3B7C79FA.89E62321@globetrotter.qc.ca>, Chris Wolfe says...
>On the basis of that tirade Natural, Positive, String and virtually
>every other useful object provided by Ada is not the Ada language. If
>it's required by the standard, it's part of the language.

First off, I agree totally with the intent of your objection. STL is in the
standard reference manual, and can thus be counted on to be part of any
conformant compiler as much as "int" can. Unfortunately, you can't count on any
one C++ compiler actually being conformant, like you can with Ada, but that's
another flamewar...

But I should point out that there is a very real difference between the language
defined types (numbers, records, arrays, etc), and stuff in libraries in an
annex somewhere. The stl is *built on* C++, rather than being an integral part
of it. Unless your compiler writers were *very* clever, that's going to cause
some overhead. Either way, you've still got that temptingly terse unsafe
language-defined array support enshrined in the standard, begging to be
(ab)used.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: How Ada could have prevented the Red Code distributed denial of

[Chris Wolfe]

Ted Dennison wrote:
[snip]
> But I should point out that there is a very real difference between the language
> defined types (numbers, records, arrays, etc), and stuff in libraries in an
> annex somewhere. The stl is *built on* C++, rather than being an integral part
> of it. Unless your compiler writers were *very* clever, that's going to cause
> some overhead.

If it's in the standard, it's an integral part. Either the STL is
part of the C++ language, or the Predefined Language Environment is
not part of Ada. Excluding both would be pretty stupid, so I shall
continue ignoring that "definition".

I doesn't takes a genius to produce special cases where common STL
calls are treated as language elements. Once the compiler writer
decides to build it in, it's mostly identifying which calls the
compiler can't inline automatically, plus grunt-work. I am assuming
that Ada compilers support at least parts of the Predefined Language
Environment in this form (notice: from an annex).

> Either way, you've still got that temptingly terse unsafe
> language-defined array support enshrined in the standard, begging to be
> (ab)used.

I don't believe anyone claimed safe programming in C++ was for the
forgetful or the clueless. There are languages better suited for
those folks, and Ada does not really qualify either.

Anyway, unless someone has something interesting to contribute I'm
going to go back to ignoring this thread. Hopefully until it dies...

Chris

Re: How Ada could have prevented the Red Code distributed denial of

[Ted Dennison]

In article <3B83F498.E0F6C582@timesys.com>, Adam Fineman says...
>
>Ted Dennison wrote:
>> Well, the software in question was the marine (engine) control system. It had
>> nothing to do with the weapon systems. I suppose you could get rammed...
>> 
>I'm in need of clarification.  Are you saying that a US Naval vessel's
>engine control system was running under Windows NT?

That was the idea. Scared yet? Well, then realise this was back in the days of
Windows NT 3.51, if I remember correctly. Also realise that Navy software is
expected to run proplerly for *decades* without maintanence upgrades like home
users are accustomed to. If you change something as significant as an OS, you
have to retest and recertify the whole system, which is incredibly expensive,
and thus not undertaken lightly.

I was particularly amused at part of one of the articles where they said the
vendor essentially blamed the problem on the Navy using an obsolete version of
their software. Perhaps home users have become resigned to being talked to that
way. But you simply do *not* go telling the Navy that all that softaware they
paid you millions to develop was really buggy crap, and thus they should pay you
again for an "upgrade".

I don't know what happened to this technology after that highly publicised
blowout. I suspect that at most it only got deployed on some of the newer
cruisers, and the Destroyers are all still using the reliably designed
Ada/Unix/CMS-2 stuff.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: How Ada could have prevented the Red Code distributed denial of

[Ted Dennison]

In article <3B83F9D6.73CB3E02@west.raytheon.com>, Jerry Petrey <"jdpetrey
says...
>I think you covered it pretty well, Ted.  We had a very good
>implementation of the engine controller in Ada but the management was so poor >that they allowed it to be re-written (after I left) in C or C++ from what 
>I've heard - to be more 'politically correct'.  That was their downfall.

Well, bad management is everyone's downfall unfortunately. I think Jerry's
referring to another R&D engine controller, not the ones on the actual
production destroyers (at least I hope he is). The manager in charge of that was
just about the worst kind you can have: the idiot who thinks he is a genius. An
idiot manager who knows he's an idiot and sticks to leading and listening can
actually be quite good, but this other kind just destroys everything he touches.


I can remember the IM (idiot manager) informing a visiting prospective customer
that we were porting that perfectly working engine controller to C++ from Ada.
When the customer incredulously asked why we'd do such a useless thing, IM told
him essentialy that he, the customer, would refuse to buy it no matter how good
the specs, if it were coded in Ada internally rather than the current hot new
language. I'm guessing IM truly believed this. Apparently the prospective
customer was not horribly impressed with IM's sensitivity to his heretofore
undiscovered coding language "hipness" desire for his engine controllers,
because he never did buy anything from us. :-)

Of course they could very well have switched the Navy production stuff too. The
pressure to use "commerical" technologies was quite intense there for a while.
While I was there they were resisting somewhat because their main contracting
agencies were (wisely) quite suspicious of that trend. The needs of most
commercial users and of a battlefield shipboard environment are just *too*
different (Can your PC sustain 100G's of shock and vibration?). But I don't know
what has happened since.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: How Ada could have prevented the Red Code distributed denial of

[Garry Hodgson]

Ted Dennison wrote:

> The manager in charge of that was
> just about the worst kind you can have: the idiot who thinks he is a genius. An
> idiot manager who knows he's an idiot and sticks to leading and listening can
> actually be quite good, but this other kind just destroys everything he touches.

i once had a conversation with a friend, and commented that i liked the
fact
that my boss had a good knowledge of software.  he replied that he had
the
next best thing:  his boss didn't know software, but knew that he didn't
know
software.

-- 
Garry Hodgson                   sometimes we ride on your horses
Senior Hacker                   sometimes we walk alone
Software Innovation Services    sometimes the songs that we hear
AT&T Labs                       are just songs of our own
garry@sage.att.com

Re: How Ada could have prevented the Red Code distributed denial of

[Adam Fineman]

Ted Dennison wrote:
> 
> In article <3B83F498.E0F6C582@timesys.com>, Adam Fineman says...
> >
> >Ted Dennison wrote:
> >> Well, the software in question was the marine (engine) control system. It had
> >> nothing to do with the weapon systems. I suppose you could get rammed...
> >>
> >I'm in need of clarification.  Are you saying that a US Naval vessel's
> >engine control system was running under Windows NT?
> 
> That was the idea. Scared yet? Well, then realise this was back in the days of
> Windows NT 3.51, if I remember correctly. Also realise that Navy software is
> expected to run proplerly for *decades* without maintanence upgrades like home
> users are accustomed to. If you change something as significant as an OS, you
> have to retest and recertify the whole system, which is incredibly expensive,
> and thus not undertaken lightly.
> 
> I was particularly amused at part of one of the articles where they said the
> vendor essentially blamed the problem on the Navy using an obsolete version of
> their software. Perhaps home users have become resigned to being talked to that
> way. But you simply do *not* go telling the Navy that all that softaware they
> paid you millions to develop was really buggy crap, and thus they should pay you
> again for an "upgrade".
> 
> I don't know what happened to this technology after that highly publicised
> blowout. I suspect that at most it only got deployed on some of the newer
> cruisers, and the Destroyers are all still using the reliably designed
> Ada/Unix/CMS-2 stuff.

I was in the Navy, and my second ship was the USS Gonzalez (DDG 66).  I
was a member of the commisioning crew, in fact.  I did not realize that
this had ever been tried (using a Windows box to interface with the
engines).  I read the article linked elsewhere in this thread, and was
floored.  The USS Yorktown going DIW (dead in the water) actually
happened while I was on the Gonzalez!

We also we experimenting with the "Smart Ship" initiative, but no
existing ship's systems were ever going to be interfacing with the LAN
or any general-purpose OS.  The plan, as I recall, was only to add new
monitoring systems that would be run over a dedicated LAN.  I don't
think that it was ever intended that a general-purpose OS of any kind
would be used to _control_ ship's systems, only to monitor them.  That
was the plan on my ship, anyway.

Using a general-purpose OS (even a "high-end" Unix) to control any type
of machine more complicated than a household appliance seems like a very
silly idea to me.

-- 
Adam Fineman
Software Engineer
QA Department
TimeSys Corporation

-- 
Opinions posted here are my own.  They do not necessarily reflect those
of the management or the other employees at TimeSys Corporation.

Re: How Ada could have prevented the Red Code distributed denial of

[Samuel T. Harris]

Garry Hodgson wrote:
> 
> Ted Dennison wrote:
> 
> > The manager in charge of that was
> > just about the worst kind you can have: the idiot who thinks he is a genius. An
> > idiot manager who knows he's an idiot and sticks to leading and listening can
> > actually be quite good, but this other kind just destroys everything he touches.
> 
> i once had a conversation with a friend, and commented that i liked the
> fact
> that my boss had a good knowledge of software.  he replied that he had
> the
> next best thing:  his boss didn't know software, but knew that he didn't
> know
> software.
> 

1. he who knows not and knows not that he knows not is a fool, shun him
2. he who knows not and knows that he knows not is ignorant, teach him
3. he who knows and knows not that he knows is asleep, wake him
4. he who knows and knows that he knows is wise, follow him

There is no reasoning with a fool, so don't bother trying.
If he who is asleep refuses to be awakened then reclassify as 1.
We'd all like to think we classify as 4 but actually most of us
are a 2 or 3 in most areas of our lives. It is nice when we
are occasionally recognized as a number 4 in some small area
of our lives but none of us can be all knowing all the time.
That is what makes living interesting.


-- 
Samuel T. Harris, Senior Software Engineer II
Raytheon, Aerospace Engineering Services
"If you can make it, We can fake it!"

Re: How Ada could have prevented the Red Code distributed denial of

[Richard Riehle]

Ted Dennison wrote:

> I can remember the IM (idiot manager) informing a visiting prospective customer
> that we were porting that perfectly working engine controller to C++ from Ada.
> When the customer incredulously asked why we'd do such a useless thing, IM told
> him essentialy that he, the customer, would refuse to buy it no matter how good
> the specs, if it were coded in Ada internally rather than the current hot new
> language.

There truly is no end to this kind of stupidity.   I regularly encounter people who
seriously believe they can acheive the same reliability in C++ that they can with Ada.
Sadly, even some really competent technical people accept this argument, for reasons
they know have nothing to do with technological excellence.   Over and over I hear
the story, "Well Ada is probably better, but C++ is just as good if we use it carefully,"
or "I can do just as well as C++ as with Ada, even though I'll admit Ada is a better
language."    It is quite frustrating.

On the positive side, some of those who have made the decision to migrate to C++
made that decision without fully understanding its implications.   Once they discover
how hideous C++ is, they back off and decide to use Java.  The thought of returning
to Ada is simply too repugnant to them.

Richard Riehle

Re: How Ada could have prevented the Red Code distributed denial of

[Ted Dennison]

In article <3B842DEA.E01CA1BE@timesys.com>, Adam Fineman says...
>I was in the Navy, and my second ship was the USS Gonzalez (DDG 66).  I
>was a member of the commisioning crew, in fact.  I did not realize that
>this had ever been tried (using a Windows box to interface with the
>engines).  I read the article linked elsewhere in this thread, and was
>floored.  The USS Yorktown going DIW (dead in the water) actually
>happened while I was on the Gonzalez!
..
>Using a general-purpose OS (even a "high-end" Unix) to control any type
>of machine more complicated than a household appliance seems like a very
>silly idea to me.

Well, if you had been on a the commisioning crew of a FLT-IIA ship (DDG 79 and
later, I believe), you would have been confronted with an engine controller
using Unix (HP/UX to be exact). There was also a redundant engine
monitor/controller running on NT 3.51 as an experiment, but as I said, it could
crash totally and not affect anything. I believe the Navy just wanted to try it
out shipboard to see how NT handled things. Both of these systems were of course
coded in Ada for extra reliability.

To give everyone else an idea of the lead times we are talking about here, I
think I finished up development on that system in '96, and the first ships with
them were commissoned last year. The sixth one won't be commissioned until 2003,
and there are currently plans for up to six more after that one. Who knows how
long they will be sailing after that. But during this whole time the Navy is
going to need copies of the OS and the ability to purchase spare motherboards,
etc. of 1995 vintage. Not many vendors keep the capability of making "obsolete"
parts for more that a couple of years. This is why many are a bit skeptical
about using commercial technology.

>We also we experimenting with the "Smart Ship" initiative, but no
>existing ship's systems were ever going to be interfacing with the LAN
>or any general-purpose OS.  The plan, as I recall, was only to add new
>monitoring systems that would be run over a dedicated LAN.  I don't

That my be a reference to my NT system. (Please don't tell the users it was me.
I did what I could, but, well, it was NT 3.51...)

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: How Ada could have prevented the Red Code distributed denial of

[Adam Fineman]

Ted Dennison wrote:
> 
> In article <3B842DEA.E01CA1BE@timesys.com>, Adam Fineman says...
> >I was in the Navy, and my second ship was the USS Gonzalez (DDG 66).  I
> >was a member of the commisioning crew, in fact.  I did not realize that
> >this had ever been tried (using a Windows box to interface with the
> >engines).  I read the article linked elsewhere in this thread, and was
> >floored.  The USS Yorktown going DIW (dead in the water) actually
> >happened while I was on the Gonzalez!
> ..
> >Using a general-purpose OS (even a "high-end" Unix) to control any type
> >of machine more complicated than a household appliance seems like a very
> >silly idea to me.
> 
> Well, if you had been on a the commisioning crew of a FLT-IIA ship (DDG 79 and
> later, I believe), you would have been confronted with an engine controller
> using Unix (HP/UX to be exact).

Sounds like a horribly bad idea to me.  I don't have any particular
complaints about HP/UX as a general-purpose operating system, but it is
_not_ a real time OS and should not be used to run the engines of a
warship.

> There was also a redundant engine
> monitor/controller running on NT 3.51 as an experiment, but as I said, it could
> crash totally and not affect anything. I believe the Navy just wanted to try it
> out shipboard to see how NT handled things. Both of these systems were of course
> coded in Ada for extra reliability.
> 
Even if a perfect program were written (in any language) and it ran as a
process in a non-real-time general-purpose OS, it would be a bad idea.

<snip>

-- 
Adam Fineman
Software Engineer
QA Department
TimeSys Corporation

-- 
Opinions posted here are my own.  They do not necessarily reflect those
of the management or the other employees at TimeSys Corporation.

Re: How Ada could have prevented the Red Code distributed denial of

[Gary Scott]

Hi,
Concurrent/Harris on the other hand has an excellent "real-time unix".

http://www.ccur.com

However, we've actually been successfully using Solaris in a real-time
environment for avionics models.

Adam Fineman wrote:
> 
> Ted Dennison wrote:
> >
> > In article <3B842DEA.E01CA1BE@timesys.com>, Adam Fineman says...
> > >I was in the Navy, and my second ship was the USS Gonzalez (DDG 66).  I
> > >was a member of the commisioning crew, in fact.  I did not realize that
> > >this had ever been tried (using a Windows box to interface with the
> > >engines).  I read the article linked elsewhere in this thread, and was
> > >floored.  The USS Yorktown going DIW (dead in the water) actually
> > >happened while I was on the Gonzalez!
> > ..
> > >Using a general-purpose OS (even a "high-end" Unix) to control any type
> > >of machine more complicated than a household appliance seems like a very
> > >silly idea to me.
> >
> > Well, if you had been on a the commisioning crew of a FLT-IIA ship (DDG 79 and
> > later, I believe), you would have been confronted with an engine controller
> > using Unix (HP/UX to be exact).
> 
> Sounds like a horribly bad idea to me.  I don't have any particular
> complaints about HP/UX as a general-purpose operating system, but it is
> _not_ a real time OS and should not be used to run the engines of a
> warship.
> 
> > There was also a redundant engine
> > monitor/controller running on NT 3.51 as an experiment, but as I said, it could
> > crash totally and not affect anything. I believe the Navy just wanted to try it
> > out shipboard to see how NT handled things. Both of these systems were of course
> > coded in Ada for extra reliability.
> >
> Even if a perfect program were written (in any language) and it ran as a
> process in a non-real-time general-purpose OS, it would be a bad idea.
> 
> <snip>
> 
> --
> Adam Fineman
> Software Engineer
> QA Department
> TimeSys Corporation
> 
> --
> Opinions posted here are my own.  They do not necessarily reflect those
> of the management or the other employees at TimeSys Corporation.

Re: How Ada could have prevented the Red Code distributed denial of

[Markus Mottl]

In comp.lang.functional Adam Fineman <adam.fineman@timesys.com> wrote:
> Sounds like a horribly bad idea to me.  I don't have any particular
> complaints about HP/UX as a general-purpose operating system, but it
> is _not_ a real time OS and should not be used to run the engines of
> a warship.

A real time OS makes guarantees about the maximum time it requires to
handle certain operations. This does not mean that a general-purpose
(non-real-time) OS is useless for real time tasks: it's all a matter of
latencies, probabilities and costs.

Given the probability distribution of the time the OS requires to handle
some critical request, you can very well compute how probable it is that
it will not be able to do so in time: just integrate the area below
the probability density function to the right of the maximum allowed
latency. Then multiply this probability with the costs of e.g. having
some warship dead in the water.

Add these costs to the price of buying an off-the-shelve general-purpose
OS and compare the result to the price of a real time OS for this
specific purpose. Voila, your decision criterion for when to buy what
kind of OS.

Of course, the probability density function and the costs of losing
a warship may be difficult to estimate, but I hope the Navy employs
competent managers + technical staff for that purpose.

Anyway, I don't know anything about the requirements of warship engines
so maybe our current general-purpose OSes are not good enough...

Regards,
Markus Mottl

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl

Re: How Ada could have prevented the Red Code distributed denial of

[Adam Fineman]

Markus Mottl wrote:
> 
> In comp.lang.functional Adam Fineman <adam.fineman@timesys.com> wrote:
> > Sounds like a horribly bad idea to me.  I don't have any particular
> > complaints about HP/UX as a general-purpose operating system, but it
> > is _not_ a real time OS and should not be used to run the engines of
> > a warship.
> 
> A real time OS makes guarantees about the maximum time it requires to
> handle certain operations. This does not mean that a general-purpose
> (non-real-time) OS is useless for real time tasks: 

IMO a non-real-time OS is useless for this particular real time task.

> it's all a matter of
> latencies, probabilities and costs.
> 
> Given the probability distribution of the time the OS requires to handle
> some critical request,

Given?  Who gave you that, exactly?  ;-)  The rest of the calculation
you describe is fairly trivial.  The only hard part what you assume to
be given....

> you can very well compute how probable it is that
> it will not be able to do so in time: just integrate the area below
> the probability density function to the right of the maximum allowed
> latency. Then multiply this probability with the costs of e.g. having
> some warship dead in the water.
> 
> Add these costs to the price of buying an off-the-shelve general-purpose
> OS and compare the result to the price of a real time OS for this
> specific purpose. Voila, your decision criterion for when to buy what
> kind of OS.
> 
> Of course, the probability density function and the costs of losing
> a warship may be difficult to estimate, but I hope the Navy employs
> competent managers + technical staff for that purpose.
> 
It really doesn't matter how competent the Navy's "managers & technical
staff" are; the probability density function you would require is not
determinable in the real world.  This probability density function _can_
be determined for a properly implemented real time system, but not for a
general-purpose OS in this situation.

The cost of a warship is easily determined.  For example, my ship had a
sticker price of about 900,000,000 USD.  Of course, one can't determine
the cost of the 330 odd crewmembers or the possibility of losing a war
because a ship goes DIW at the wrong moment.

Hard real time systems are used when the cost of a missed deadline is
prohibitive.  Controlling the engines of a warship certainly qualifies.

By the way, have you ever heard of the Mars Pathfinder mission?

- Adam

-- 
Adam Fineman
SQA Engineer
TimeSys Corporation
-- 
Opinions posted here are my own.

Re: How Ada could have prevented the Red Code distributed denial of

[Adam Fineman]

Gary Scott wrote:
> 
> Hi,
> Concurrent/Harris on the other hand has an excellent "real-time unix".
> 
As does my company. :-)  As do several others.

> However, we've actually been successfully using Solaris in a real-time
> environment for avionics models.
> 
I'm not sure I understand.  In what capacity have you been using Solaris
in a real-time environment?

-- 
Adam Fineman
Software Engineer
QA Department
TimeSys Corporation

-- 
Opinions posted here are my own.  They do not necessarily reflect those
of the management or the other employees at TimeSys Corporation.

Re: How Ada could have prevented the Red Code distributed denial of

[Ted Dennison]

In article <3B85294F.BB780B7F@timesys.com>, Adam Fineman says...
>
>Ted Dennison wrote:
>> later, I believe), you would have been confronted with an engine controller
>> using Unix (HP/UX to be exact).
>
>Sounds like a horribly bad idea to me.  I don't have any particular
>complaints about HP/UX as a general-purpose operating system, but it is
>_not_ a real time OS and should not be used to run the engines of a
>warship.

Well, I had a longstanding debate with a lot of those folks about whether it was
really "real-time" or not. Its certianly not "hard" real-time. Since the system
doesn't make any decisions w/o an operator, who desginates his decision via a
GUI action, the performance tolerances are rather loose by my standards.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: How Ada could have prevented the Red Code distributed denial of

[Tore Lund]

Markus Mottl wrote:
> 
> Add these costs to the price of buying an off-the-shelve general-purpose
> OS and compare the result to the price of a real time OS for this
> specific purpose. Voila, your decision criterion for when to buy what
> kind of OS.

QNX is real-time, off-the-shelf and general-purpose, as well as
POSIX-compliant.  (At least according to QNX blurb.)  Has anyone
considered QNX for use on warships...?
-- 
    Tore

RE: How Ada could have prevented the Red Code distributed denial of

[Beard, Frank]

LynxOS is real-time, off-the-shelf, general-purpose, and POSIX
compliant, as well.  We used it on space station, and it was 
pretty nice.  Tasks mapped to threads, etc.

It was faster on an IBM PS2 66 MHz than HP-UX BLS was on HP's
own 150 MHz MIPS processor.  And according to the HP reps HP's
real-time OS was a re-wrapped LynxOS, but I don't know if that's
still true.  We moved to NT before we ever got to try HP's
real-time OS.

Frank

-----Original Message-----
From: Tore Lund [mailto:tl001@online.no]
Sent: Thursday, August 23, 2001 5:22 PM
To: comp.lang.ada@ada.eu.org
Subject: Re: How Ada could have prevented the Red Code distributed
denial of


Markus Mottl wrote:
> 
> Add these costs to the price of buying an off-the-shelve general-purpose
> OS and compare the result to the price of a real time OS for this
> specific purpose. Voila, your decision criterion for when to buy what
> kind of OS.

QNX is real-time, off-the-shelf and general-purpose, as well as
POSIX-compliant.  (At least according to QNX blurb.)  Has anyone
considered QNX for use on warships...?
-- 
    Tore

_______________________________________________
comp.lang.ada mailing list
comp.lang.ada@ada.eu.org
http://ada.eu.org/mailman/listinfo/comp.lang.ada

Re: How Ada could have prevented the Red Code distributed denial of

[tmoran]

>On the positive side, some of those who have made the decision to migrate to C++
>made that decision without fully understanding its implications.   Once they discover
>how hideous C++ is, they back off and decide to use Java.  The thought of returning
>to Ada is simply too repugnant to them.
  It's one thing to announce there's an even better solution than the one
you originally proposed.  It's another to admit your original idea stunk.