Java, the software developed by Sun Microsystems in the mid-1990s as a
universal operating system for Internet applications, gave NASA a low-cost
and easy-to-use option for running Spirit, the robotic rover that rolled
onto the planet's surface on Thursday in search of signs of water and life. http://news.com.com/2100-1007_3-5142...l?tag=nefd_top
l8r, Mike N. Christoff
Jul 17 '05
198  17424 
Ashlie Benjamin Hocking wrote: Richard Maine <no****@see.signature> writes:
If you are sufficiently clueless, you can manage to express that
cluelessness in any language.
I think this is a quote worthy of a .sig file. (I'm assuming this is a
Richard Maine original?)
It bears a relation to "Real Programmers can write Fortran in any
language", but I hesitate to call it a "corollary".
[ dodges ]
--
Toon Moene - mailto:to**@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://gcc.gnu.org/fortran/ (under construction)
"Michael N. Christoff" <mc********@sympatico.caREMOVETHIS> wrote in message news:<ZC*******************@news20.bellglobal.com> ... Java, the software developed by Sun Microsystems in the mid-1990s as a
universal operating system for Internet applications, gave NASA a low-cost
and easy-to-use option for running Spirit, the robotic rover that rolled
onto the planet's surface on Thursday in search of signs of water and life.
http://news.com.com/2100-1007_3-5142...l?tag=nefd_top
Mike, I have no facts to support this, but my guess is that that the
PR blurb you post is little more than a bit of marketing spin whose
quotes are being read out of context by a few Java enthusiasts.
First of all, obviously Java is not an operating system. It's an
application programming language or tool targeted to the production of
Internet (particularly browser applications). You also cannot
implement a true operating system using Java as your programming
language. If you doubt this, I'll hand you an 80586 chip with 128-Megs
of online memory and chuckle as you try!)
Java is absolutely useless except when running on a platform already
equipped with an operating system, and many layers of data
communications and application programs, where the top levels include
an operating TCP/IP stack and browser software.
Almost certainly the OS within the rover is a highly optimized
real-time kernel likely programmed in assembler, C, C++ or some other
system implementation langage. (Perhaps even Ada, although that would
be a long-shot.) Java is certainly not a member of this tight-knit
club of system implementation languages, and I simply cannot picture
anyone even attempting to implement a real-time OS using it. Java is
not running the Rover, its real-time operating system is.
My guess is that when you get details of the facts supporting this PR
release, you'll learn that certain Java apps form a portion of the
man-machine interface design employed for the entry of command
sequences here on earth, since Java is capable of simpllifying the
design of this type of software over what could otherwise be
programmed using xlib, C, C++ or even (gasp) assembly language, since
the programming of a control entry MMI is today not exactly rocket
science (no pun intended). (Heck, you could probably even use Visual
Basic for the purpose, if really desperate! Back in the early days of
surveilance satellites, we even programmed the ground based command
interpreters for the K-series birds using Fortran, and they were both
trivial to program and functioned perfectly.)
Also, at last count the foundations of the Internet rested heavily on
C/C++/Assembler implementations running on Unix platforms, however
this may or may not have changed over the years. (At last count, the
thousands of different routines supporting operation of the Internet
involved the use of nearly as many different programming tools...since
so long as they all result in the production of really tight, robust,
executable machine code, the choice of programming language really
doesn't matter.)
When a firm intentionally confuses application programming tools such
as Java with real-time OS implementation methodoloy, in my mind they
both risk and deserve justifiable ridicule. I don't believe that Sun
intended to create such confusion in their publicity release, however
a few Java enthusiasts do seem bent on misrepresentation of Java's
capabilities, potentially at Sun's credibility expense.
Harry C.
"Michael N. Christoff" <mc********@sympatico.caREMOVETHIS> wrote in message news:<ZC*******************@news20.bellglobal.com> ... Java, the software developed by Sun Microsystems in the mid-1990s as a
universal operating system for Internet applications, gave NASA a low-cost
and easy-to-use option for running Spirit, the robotic rover that rolled
onto the planet's surface on Thursday in search of signs of water and life.
http://news.com.com/2100-1007_3-5142...l?tag=nefd_top
Mike, I have no facts to support this, but my guess is that that the
PR blurb you post is little more than a bit of marketing spin whose
quotes are being read out of context by a few Java enthusiasts.
First of all, obviously Java is not an operating system. It's an
application programming language or tool targeted to the production of
Internet (particularly browser applications). You also cannot
implement a true operating system using Java as your programming
language. If you doubt this, I'll hand you an 80586 chip with 128-Megs
of online memory and chuckle as you try!)
Java is absolutely useless except when running on a platform already
equipped with an operating system, and many layers of data
communications and application programs, where the top levels include
an operating TCP/IP stack and browser software.
Almost certainly the OS within the rover is a highly optimized
real-time kernel likely programmed in assembler, C, C++ or some other
system implementation langage. (Perhaps even Ada, although that would
be a long-shot.) Java is certainly not a member of this tight-knit
club of system implementation languages, and I simply cannot picture
anyone even attempting to implement a real-time OS using it. Java is
not running the Rover, its real-time operating system is.
My guess is that when you get details of the facts supporting this PR
release, you'll learn that certain Java apps form a portion of the
man-machine interface design employed for the entry of command
sequences here on earth, since Java is capable of simpllifying the
design of this type of software over what could otherwise be
programmed using xlib, C, C++ or even (gasp) assembly language, since
the programming of a control entry MMI is today not exactly rocket
science (no pun intended). (Heck, you could probably even use Visual
Basic for the purpose, if really desperate! Back in the early days of
surveilance satellites, we even programmed the ground based command
interpreters for the K-series birds using Fortran, and they were both
trivial to program and functioned perfectly.)
Also, at last count the foundations of the Internet rested heavily on
C/C++/Assembler implementations running on Unix platforms, however
this may or may not have changed over the years. (At last count, the
thousands of different routines supporting operation of the Internet
involved the use of nearly as many different programming tools...since
so long as they all result in the production of really tight, robust,
executable machine code, the choice of programming language really
doesn't matter.)
When a firm intentionally confuses application programming tools such
as Java with real-time OS implementation methodoloy, in my mind they
both risk and deserve justifiable ridicule. I don't believe that Sun
intended to create such confusion in their publicity release, however
a few Java enthusiasts do seem bent on misrepresentation of Java's
capabilities, potentially at Sun's credibility expense.
Harry C.
mitch <realtime@-no-spam-acm.org> wrote in message news:<10*************@corp.supernews.com>... Read the article carefully. Java is being used to create 3D views of
terrain, and for command and control functions, ON EARTH. The last
paragraph correctly states that Wind River Systems made the embedded
software in the Spirit and Opportunity rovers. They run applications
created by JPL which execute on the VxWorks real-time operating system
(RTOS). I know this because a little of my work is in that RTOS - I
worked for Wind River until recently.
If you want more info on VxWorks, see the web site: www.windriver.com
The VxWorks RTOS also ran the Mars Lander and is in many other active
NASA probes like Stardust.
--mitch
Now that I can believe! :-)
I'm still supporting embedded 8051 packages running on the original
Franklin RTOS, nearly all embedded control systems using the Intel
80X86 family now run VxWorks, with the exception of the 80186. Wind
River is certainly doing something right.
Their VxWorks RTOS package is really slick...I know this because I was
once comissioned to write a RTOS OS for the 80186 similar to VxWorks
(which doesn't support the 80186 in order to provide support for a
legacy PLC controller design. Sadly, the firm quickly lost interest
and cancelled the funding 3-months into the project, just when I was
begining to become really good at rewriting VxWorks 80386 OS code into
80186 code! :-)
I never found out if the mission was scrubbed because of an internal
marketing decision, or because Wind River and its attorneys got wind
(no pun inteded) of the project.
What do/did you think of "Tornado"? Seemed to me that it was equally
as bad as "Starteam", and the neither of these two CM systems came
close to equaling the features provided by the old Unix PWB (for you
newbies, PWB "Programmers Workbench", arguably the original software
configuration management tool).
Harry C.
mitch <realtime@-no-spam-acm.org> wrote in message news:<10*************@corp.supernews.com>... Read the article carefully. Java is being used to create 3D views of
terrain, and for command and control functions, ON EARTH. The last
paragraph correctly states that Wind River Systems made the embedded
software in the Spirit and Opportunity rovers. They run applications
created by JPL which execute on the VxWorks real-time operating system
(RTOS). I know this because a little of my work is in that RTOS - I
worked for Wind River until recently.
If you want more info on VxWorks, see the web site: www.windriver.com
The VxWorks RTOS also ran the Mars Lander and is in many other active
NASA probes like Stardust.
--mitch
Now that I can believe! :-)
I'm still supporting embedded 8051 packages running on the original
Franklin RTOS, nearly all embedded control systems using the Intel
80X86 family now run VxWorks, with the exception of the 80186. Wind
River is certainly doing something right.
Their VxWorks RTOS package is really slick...I know this because I was
once comissioned to write a RTOS OS for the 80186 similar to VxWorks
(which doesn't support the 80186 in order to provide support for a
legacy PLC controller design. Sadly, the firm quickly lost interest
and cancelled the funding 3-months into the project, just when I was
begining to become really good at rewriting VxWorks 80386 OS code into
80186 code! :-)
I never found out if the mission was scrubbed because of an internal
marketing decision, or because Wind River and its attorneys got wind
(no pun inteded) of the project.
What do/did you think of "Tornado"? Seemed to me that it was equally
as bad as "Starteam", and the neither of these two CM systems came
close to equaling the features provided by the old Unix PWB (for you
newbies, PWB "Programmers Workbench", arguably the original software
configuration management tool).
Harry C.
Richard Maine <no****@see.signature> wrote in message news:<m3************@altair.dfrc.nasa.gov>... Jan C. Vorbrüggen <jv**********@mediasec.de> writes:
For any modern compiler of a 3GL language, not compiling with (the equivalent
of) -fast is grossly negligent.
A few years ago, I was asked to help with improving the performance of
a major production code here. The author of the code didn't even
know how to turn on the optimizer. I mean turning on the optimizer
at all, even with a simple -O, much less experimenting with the other
settings. I was a bit shocked that they felt the need to call for
help and hadn't even tried that. This was from a supposedly
professional full-time programmer and was in a code that had gone
through all the formal development process (for what little that
was actually worth :-() and was in production use.
If he was dealing with embedded software, the original designer may
have had good reason not to turn on the optimizer.
In embedded software, we frequently write to memory addresses that are
in turn mapped to hardware control registers. Early optimizer design
was frequently done by software folk not familiar with this practices,
often optimizing out writes to address that they didn't see being
later read.
IIRC, Microsoft's "MASM" was an assembler whose optimization exhibited
this defect. Today, no many people use MASM, so I don't know if the
flaw was ever corrected. As a result, many embedded software/firmware
designers today still operate with the optimizer turned off for
"safety", and prefer to optimize their own code.
Franklin's 8051 development suite initially exhibied the same problem,
but given that their target market was entired embedded software
designers, the problem was corrected by the 2nd release of the
product.
It was a Fortran code, but the major problems didn't have much to
do with the language. If you are sufficiently clueless, you can
manage to express that cluelessness in any language.
Amen to that statement, and suggest that it be etched it in stone.
A skilled programmer can even write in GWBASIC and produce fantastic
results through the clever use of (IIRC) PUT and POKE commands, which
allow the insertion of machine language instructions in the GWBASIC or
the Atari BASIC command stream. (I wonder how many of today's
programmers would be resouceful enough to use of such extreme
techniques to achieve their goals? Heck, for that matter how many have
ever even directly used machine code?)
Harry C.
Richard Maine <no****@see.signature> wrote in message news:<m3************@altair.dfrc.nasa.gov>... Jan C. Vorbrüggen <jv**********@mediasec.de> writes:
For any modern compiler of a 3GL language, not compiling with (the equivalent
of) -fast is grossly negligent.
A few years ago, I was asked to help with improving the performance of
a major production code here. The author of the code didn't even
know how to turn on the optimizer. I mean turning on the optimizer
at all, even with a simple -O, much less experimenting with the other
settings. I was a bit shocked that they felt the need to call for
help and hadn't even tried that. This was from a supposedly
professional full-time programmer and was in a code that had gone
through all the formal development process (for what little that
was actually worth :-() and was in production use.
If he was dealing with embedded software, the original designer may
have had good reason not to turn on the optimizer.
In embedded software, we frequently write to memory addresses that are
in turn mapped to hardware control registers. Early optimizer design
was frequently done by software folk not familiar with this practices,
often optimizing out writes to address that they didn't see being
later read.
IIRC, Microsoft's "MASM" was an assembler whose optimization exhibited
this defect. Today, no many people use MASM, so I don't know if the
flaw was ever corrected. As a result, many embedded software/firmware
designers today still operate with the optimizer turned off for
"safety", and prefer to optimize their own code.
Franklin's 8051 development suite initially exhibied the same problem,
but given that their target market was entired embedded software
designers, the problem was corrected by the 2nd release of the
product.
It was a Fortran code, but the major problems didn't have much to
do with the language. If you are sufficiently clueless, you can
manage to express that cluelessness in any language.
Amen to that statement, and suggest that it be etched it in stone.
A skilled programmer can even write in GWBASIC and produce fantastic
results through the clever use of (IIRC) PUT and POKE commands, which
allow the insertion of machine language instructions in the GWBASIC or
the Atari BASIC command stream. (I wonder how many of today's
programmers would be resouceful enough to use of such extreme
techniques to achieve their goals? Heck, for that matter how many have
ever even directly used machine code?)
Harry C.
On 21 Jan 2004 14:06:56 -0800, hh****@yahoo.com (Harry Conover) wrote: "Michael N. Christoff" <mc********@sympatico.caREMOVETHIS> wrote in message news:<ZC*******************@news20.bellglobal.com> ... Java, the software developed by Sun Microsystems in the mid-1990s as a
universal operating system for Internet applications, gave NASA a low-cost
and easy-to-use option for running Spirit, the robotic rover that rolled
onto the planet's surface on Thursday in search of signs of water and life.
http://news.com.com/2100-1007_3-5142...l?tag=nefd_top
Mike, I have no facts to support this, but my guess is that that the
PR blurb you post is little more than a bit of marketing spin whose
quotes are being read out of context by a few Java enthusiasts.
You're about four days late with this observation ;-) Folks who
actually read the referenced article, "Java runs remote-controlled
Mars rover", learned that while a Java program "runs" a simulated
rover, here on earth, and is a very useful tool for mission planning,
it does not run *on* the rover, or directly control it. Read the
article.
You can get the software at http://mars.telascience.org/
--
Al Balmer
Balmer Consulting re************************@att.net
On 21 Jan 2004 14:06:56 -0800, hh****@yahoo.com (Harry Conover) wrote: "Michael N. Christoff" <mc********@sympatico.caREMOVETHIS> wrote in message news:<ZC*******************@news20.bellglobal.com> ... Java, the software developed by Sun Microsystems in the mid-1990s as a
universal operating system for Internet applications, gave NASA a low-cost
and easy-to-use option for running Spirit, the robotic rover that rolled
onto the planet's surface on Thursday in search of signs of water and life.
http://news.com.com/2100-1007_3-5142...l?tag=nefd_top
Mike, I have no facts to support this, but my guess is that that the
PR blurb you post is little more than a bit of marketing spin whose
quotes are being read out of context by a few Java enthusiasts.
You're about four days late with this observation ;-) Folks who
actually read the referenced article, "Java runs remote-controlled
Mars rover", learned that while a Java program "runs" a simulated
rover, here on earth, and is a very useful tool for mission planning,
it does not run *on* the rover, or directly control it. Read the
article.
You can get the software at http://mars.telascience.org/
--
Al Balmer
Balmer Consulting re************************@att.net
On 21 Jan 2004 14:59:32 -0800, hh****@yahoo.com (Harry Conover) wrote: A skilled programmer can even write in GWBASIC and produce fantastic
results through the clever use of (IIRC) PUT and POKE commands, which
allow the insertion of machine language instructions in the GWBASIC or
the Atari BASIC command stream. (I wonder how many of today's
programmers would be resouceful enough to use of such extreme
techniques to achieve their goals?
Programmers tend to be as resourceful as necessary, to the detriment
of the remainder of the code's life cycle.. Fortunately, such
techniques are usually not necessary on today's programming platforms.
Unfortunately, some programmers use them anyway.
Heck, for that matter how many have
ever even directly used machine code?)
Rarely needed, even in my day. Assembler language is much preferable,
and lots of people still use it. Direct use of machine code is (was)
sometimes useful for debugging and patching.
--
Al Balmer
Balmer Consulting re************************@att.net
On 21 Jan 2004 14:59:32 -0800, hh****@yahoo.com (Harry Conover) wrote: A skilled programmer can even write in GWBASIC and produce fantastic
results through the clever use of (IIRC) PUT and POKE commands, which
allow the insertion of machine language instructions in the GWBASIC or
the Atari BASIC command stream. (I wonder how many of today's
programmers would be resouceful enough to use of such extreme
techniques to achieve their goals?
Programmers tend to be as resourceful as necessary, to the detriment
of the remainder of the code's life cycle.. Fortunately, such
techniques are usually not necessary on today's programming platforms.
Unfortunately, some programmers use them anyway.
Heck, for that matter how many have
ever even directly used machine code?)
Rarely needed, even in my day. Assembler language is much preferable,
and lots of people still use it. Direct use of machine code is (was)
sometimes useful for debugging and patching.
--
Al Balmer
Balmer Consulting re************************@att.net
In article <40***************@Sonnack.com>, Ch***@Sonnack.com says... One reason they make a diff on large aircraft is the proportional
difference in increasing the wing area of an already large wing.
Keep in mind that ALL aircraft land with flaps.
That's simply not true. Not only do some airplane designs simply not
have flaps, but accomplished pilots practice flapless landings in
case of a system failure.
Numerous early Piper aircraft had no flaps at all, and flew very
well. Same is true for quite a few other designs.
Even exotic special purpose modern aircraft, such as the Extra 300
series have no flaps.
--
Randy Howard
2reply remove FOOBAR
In article <40***************@Sonnack.com>, Ch***@Sonnack.com says... One reason they make a diff on large aircraft is the proportional
difference in increasing the wing area of an already large wing.
Keep in mind that ALL aircraft land with flaps.
That's simply not true. Not only do some airplane designs simply not
have flaps, but accomplished pilots practice flapless landings in
case of a system failure.
Numerous early Piper aircraft had no flaps at all, and flew very
well. Same is true for quite a few other designs.
Even exotic special purpose modern aircraft, such as the Extra 300
series have no flaps.
--
Randy Howard
2reply remove FOOBAR
"Harry Conover" <hh****@yahoo.com> wrote in message
news:7c**************************@posting.google.c om... "Michael N. Christoff" <mc********@sympatico.caREMOVETHIS> wrote in
message news:<ZC*******************@news20.bellglobal.com> ... Java, the software developed by Sun Microsystems in the mid-1990s as a
universal operating system for Internet applications, gave NASA a
low-cost and easy-to-use option for running Spirit, the robotic rover that rolled
onto the planet's surface on Thursday in search of signs of water and
life.
http://news.com.com/2100-1007_3-5142...l?tag=nefd_top
Mike, I have no facts to support this, but my guess is that that the
PR blurb you post is little more than a bit of marketing spin whose
quotes are being read out of context by a few Java enthusiasts.
First of all, obviously Java is not an operating system. It's an
application programming language or tool targeted to the production of
Internet (particularly browser applications). You also cannot
implement a true operating system using Java as your programming
language. If you doubt this, I'll hand you an 80586 chip with 128-Megs
of online memory and chuckle as you try!)
Java is absolutely useless except when running on a platform already
equipped with an operating system, and many layers of data
communications and application programs, where the top levels include
an operating TCP/IP stack and browser software.
Almost certainly the OS within the rover is a highly optimized
real-time kernel likely programmed in assembler, C, C++ or some other
system implementation langage. (Perhaps even Ada, although that would
be a long-shot.) Java is certainly not a member of this tight-knit
club of system implementation languages, and I simply cannot picture
anyone even attempting to implement a real-time OS using it. Java is
not running the Rover, its real-time operating system is.
My guess is that when you get details of the facts supporting this PR
release, you'll learn that certain Java apps form a portion of the
man-machine interface design employed for the entry of command
sequences here on earth, since Java is capable of simpllifying the
design of this type of software over what could otherwise be
programmed using xlib, C, C++ or even (gasp) assembly language, since
the programming of a control entry MMI is today not exactly rocket
science (no pun intended). (Heck, you could probably even use Visual
Basic for the purpose, if really desperate! Back in the early days of
surveilance satellites, we even programmed the ground based command
interpreters for the K-series birds using Fortran, and they were both
trivial to program and functioned perfectly.)
Also, at last count the foundations of the Internet rested heavily on
C/C++/Assembler implementations running on Unix platforms, however
this may or may not have changed over the years. (At last count, the
thousands of different routines supporting operation of the Internet
involved the use of nearly as many different programming tools...since
so long as they all result in the production of really tight, robust,
executable machine code, the choice of programming language really
doesn't matter.)
When a firm intentionally confuses application programming tools such
as Java with real-time OS implementation methodoloy, in my mind they
both risk and deserve justifiable ridicule. I don't believe that Sun
intended to create such confusion in their publicity release, however
a few Java enthusiasts do seem bent on misrepresentation of Java's
capabilities, potentially at Sun's credibility expense.
a) the article never said that Java was on the rover itself. b) Java is
more than a language, it is a platform. c) the fact that Java needs an
underlying OS has never been disputed by anyone. The idea is for Java to be
portable to other _already developed_ platforms. It would not be very
portable if you had to dual boot into a Java OS to run Java apps. d) There
is no reason to believe a real time system cannot be virtual machine based.
It is technicaly feasible and all the benefits of seperating code from
hardware/OS are just as relevant on embedded systems as they are on
desktops. Just look at cell phones. (note: many many people laughed at the
idea that something as small as a cell-phone could run any VM-based
language. Java on top of VM on top of embedded OS seemed way too bulky to
ever be practical. But Moore's law apparently does not apply only to
desktops, but even embedded devices). Will a real-time Java have all the
features of regular Java? Doubtful. ie: automatic garbage collection may
not be possible.
l8r, Mike N. Christoff
"Harry Conover" <hh****@yahoo.com> wrote in message
news:7c**************************@posting.google.c om... "Michael N. Christoff" <mc********@sympatico.caREMOVETHIS> wrote in
message news:<ZC*******************@news20.bellglobal.com> ... Java, the software developed by Sun Microsystems in the mid-1990s as a
universal operating system for Internet applications, gave NASA a
low-cost and easy-to-use option for running Spirit, the robotic rover that rolled
onto the planet's surface on Thursday in search of signs of water and
life.
http://news.com.com/2100-1007_3-5142...l?tag=nefd_top
Mike, I have no facts to support this, but my guess is that that the
PR blurb you post is little more than a bit of marketing spin whose
quotes are being read out of context by a few Java enthusiasts.
First of all, obviously Java is not an operating system. It's an
application programming language or tool targeted to the production of
Internet (particularly browser applications). You also cannot
implement a true operating system using Java as your programming
language. If you doubt this, I'll hand you an 80586 chip with 128-Megs
of online memory and chuckle as you try!)
Java is absolutely useless except when running on a platform already
equipped with an operating system, and many layers of data
communications and application programs, where the top levels include
an operating TCP/IP stack and browser software.
Almost certainly the OS within the rover is a highly optimized
real-time kernel likely programmed in assembler, C, C++ or some other
system implementation langage. (Perhaps even Ada, although that would
be a long-shot.) Java is certainly not a member of this tight-knit
club of system implementation languages, and I simply cannot picture
anyone even attempting to implement a real-time OS using it. Java is
not running the Rover, its real-time operating system is.
My guess is that when you get details of the facts supporting this PR
release, you'll learn that certain Java apps form a portion of the
man-machine interface design employed for the entry of command
sequences here on earth, since Java is capable of simpllifying the
design of this type of software over what could otherwise be
programmed using xlib, C, C++ or even (gasp) assembly language, since
the programming of a control entry MMI is today not exactly rocket
science (no pun intended). (Heck, you could probably even use Visual
Basic for the purpose, if really desperate! Back in the early days of
surveilance satellites, we even programmed the ground based command
interpreters for the K-series birds using Fortran, and they were both
trivial to program and functioned perfectly.)
Also, at last count the foundations of the Internet rested heavily on
C/C++/Assembler implementations running on Unix platforms, however
this may or may not have changed over the years. (At last count, the
thousands of different routines supporting operation of the Internet
involved the use of nearly as many different programming tools...since
so long as they all result in the production of really tight, robust,
executable machine code, the choice of programming language really
doesn't matter.)
When a firm intentionally confuses application programming tools such
as Java with real-time OS implementation methodoloy, in my mind they
both risk and deserve justifiable ridicule. I don't believe that Sun
intended to create such confusion in their publicity release, however
a few Java enthusiasts do seem bent on misrepresentation of Java's
capabilities, potentially at Sun's credibility expense.
a) the article never said that Java was on the rover itself. b) Java is
more than a language, it is a platform. c) the fact that Java needs an
underlying OS has never been disputed by anyone. The idea is for Java to be
portable to other _already developed_ platforms. It would not be very
portable if you had to dual boot into a Java OS to run Java apps. d) There
is no reason to believe a real time system cannot be virtual machine based.
It is technicaly feasible and all the benefits of seperating code from
hardware/OS are just as relevant on embedded systems as they are on
desktops. Just look at cell phones. (note: many many people laughed at the
idea that something as small as a cell-phone could run any VM-based
language. Java on top of VM on top of embedded OS seemed way too bulky to
ever be practical. But Moore's law apparently does not apply only to
desktops, but even embedded devices). Will a real-time Java have all the
features of regular Java? Doubtful. ie: automatic garbage collection may
not be possible.
l8r, Mike N. Christoff Java is certainly not a member of this tight-knit
club of system implementation languages, and I simply cannot picture
anyone even attempting to implement a real-time OS using it.
As I mentioned, you would not implement the OS in Java, but would implement
a VM for the OS that allows one to run Java code with deterministic time
contraints on operations.
I posted this already in another thread.
Jim Sculley wrote:
<quote>
In any event this entire discussion has ignored the Realtime
Specification for Java, implementations of which are being used in
mission critical apps, such as control systems for a future Mars rover: http://www.opengroup.org/rtforum/upl...den_Gate_May01
-v05.pdf
Jim S.
</quote>
l8r, Mike N. Christoff Java is certainly not a member of this tight-knit
club of system implementation languages, and I simply cannot picture
anyone even attempting to implement a real-time OS using it.
As I mentioned, you would not implement the OS in Java, but would implement
a VM for the OS that allows one to run Java code with deterministic time
contraints on operations.
I posted this already in another thread.
Jim Sculley wrote:
<quote>
In any event this entire discussion has ignored the Realtime
Specification for Java, implementations of which are being used in
mission critical apps, such as control systems for a future Mars rover: http://www.opengroup.org/rtforum/upl...den_Gate_May01
-v05.pdf
Jim S.
</quote>
l8r, Mike N. Christoff
Harry Conover wrote: You also cannot
implement a true operating system using Java as your programming
language. If you doubt this, I'll hand you an 80586 chip with 128-Megs
of online memory and chuckle as you try!)
Send them over. I could do with the chip (and the RAM). Feel free to
chuckle, whilst I fetch my screwdriver. :-)
--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Harry Conover wrote: You also cannot
implement a true operating system using Java as your programming
language. If you doubt this, I'll hand you an 80586 chip with 128-Megs
of online memory and chuckle as you try!)
Send them over. I could do with the chip (and the RAM). Feel free to
chuckle, whilst I fetch my screwdriver. :-)
--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
> In embedded software, we frequently write to memory addresses that are in turn mapped to hardware control registers. Early optimizer design
was frequently done by software folk not familiar with this practices,
often optimizing out writes to address that they didn't see being
later read.
...which is the correct thing to do, IMO. If you want such dead stores or
loads to happen in any case, you need to tell the compiler the changed
semantics of that value in any case. In fact, on a modern processor, even
if the compiler did not optimize the memory operation away, it is quite
likely it wouldn't happen at all or in time.
Crippling the optimizer is the wrong solution to this problem.
Jan
> In embedded software, we frequently write to memory addresses that are in turn mapped to hardware control registers. Early optimizer design
was frequently done by software folk not familiar with this practices,
often optimizing out writes to address that they didn't see being
later read.
...which is the correct thing to do, IMO. If you want such dead stores or
loads to happen in any case, you need to tell the compiler the changed
semantics of that value in any case. In fact, on a modern processor, even
if the compiler did not optimize the memory operation away, it is quite
likely it wouldn't happen at all or in time.
Crippling the optimizer is the wrong solution to this problem.
Jan
> d) There is no reason to believe a real time system cannot be virtual machine based. It is technicaly feasible and all the benefits of seperating
code from hardware/OS are just as relevant on embedded systems as they are
on desktops. Just look at cell phones.
Or, indeed, some smart cards (for instance, from GEMplus or axalto).
Their advantage is that you need to certify the JVM only once as to its
sandbox guarantees, and can then put new applications on the card and
certify them without regard to what else is running on the card, while the
current practice would require a re-certification of all the software on
the card as a whole. Megabucks saved.
Jan
> d) There is no reason to believe a real time system cannot be virtual machine based. It is technicaly feasible and all the benefits of seperating
code from hardware/OS are just as relevant on embedded systems as they are
on desktops. Just look at cell phones.
Or, indeed, some smart cards (for instance, from GEMplus or axalto).
Their advantage is that you need to certify the JVM only once as to its
sandbox guarantees, and can then put new applications on the card and
certify them without regard to what else is running on the card, while the
current practice would require a re-certification of all the software on
the card as a whole. Megabucks saved.
Jan
)> In embedded software, we frequently write to memory addresses that are
)> in turn mapped to hardware control registers. Early optimizer design
)> was frequently done by software folk not familiar with this practices,
)> often optimizing out writes to address that they didn't see being
)> later read.
Jan wrote:
) ..which is the correct thing to do, IMO. If you want such dead stores or
) loads to happen in any case, you need to tell the compiler the changed
) semantics of that value in any case. In fact, on a modern processor, even
) if the compiler did not optimize the memory operation away, it is quite
) likely it wouldn't happen at all or in time.
)
) Crippling the optimizer is the wrong solution to this problem.
Correct me if I'm wrong, but isn't it true that most compilers have some
kind of flag (like volatile) to indicate that such writes are not to be
optimized away ? And if not, that would be the way to go, wouldn't it ?
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
)> In embedded software, we frequently write to memory addresses that are
)> in turn mapped to hardware control registers. Early optimizer design
)> was frequently done by software folk not familiar with this practices,
)> often optimizing out writes to address that they didn't see being
)> later read.
Jan wrote:
) ..which is the correct thing to do, IMO. If you want such dead stores or
) loads to happen in any case, you need to tell the compiler the changed
) semantics of that value in any case. In fact, on a modern processor, even
) if the compiler did not optimize the memory operation away, it is quite
) likely it wouldn't happen at all or in time.
)
) Crippling the optimizer is the wrong solution to this problem.
Correct me if I'm wrong, but isn't it true that most compilers have some
kind of flag (like volatile) to indicate that such writes are not to be
optimized away ? And if not, that would be the way to go, wouldn't it ?
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
<reply satirical_mode="on">
Actually, the use of Java on the Mars rover is quite brilliant because of
Java's write once run anywhere model.
This means that NASA can re-license the code to run forklifts, golf
carts,wheelchairs, or any conveyance that could have its own on board
JVM.
Just think of how all that extra licensing revenue will enable us to meet
the President's goal of landing the Democratic candidate for President on
the moon before the election and returning him within four years. More or
less.
Unless the rover was developed under the GPL?
</reply>
Actually, academic debate aside, the success of the rover so far is a
welcome shot in the arm for the space program, especially after the
shuttle tragedy and previous Mars mission failures. In the cold harsh
light of the pragmatic dawn, if the rover works to spec, then using java
was a good decision, if not, then it was a poor decision. To quote the
scribe: all else is commentary.
--
..................................................
99 percent of lawyers give the rest a bad name.
Rod Davison - Critical Knowledge Systems Inc.
<reply satirical_mode="on">
Actually, the use of Java on the Mars rover is quite brilliant because of
Java's write once run anywhere model.
This means that NASA can re-license the code to run forklifts, golf
carts,wheelchairs, or any conveyance that could have its own on board
JVM.
Just think of how all that extra licensing revenue will enable us to meet
the President's goal of landing the Democratic candidate for President on
the moon before the election and returning him within four years. More or
less.
Unless the rover was developed under the GPL?
</reply>
Actually, academic debate aside, the success of the rover so far is a
welcome shot in the arm for the space program, especially after the
shuttle tragedy and previous Mars mission failures. In the cold harsh
light of the pragmatic dawn, if the rover works to spec, then using java
was a good decision, if not, then it was a poor decision. To quote the
scribe: all else is commentary.
--
..................................................
99 percent of lawyers give the rest a bad name.
Rod Davison - Critical Knowledge Systems Inc.
hh****@yahoo.com (Harry Conover) writes: First of all, obviously Java is not an operating system. It's an
application programming language or tool targeted to the production of
Internet (particularly browser applications). You also cannot
implement a true operating system using Java as your programming
language. If you doubt this, I'll hand you an 80586 chip with 128-Megs
of online memory and chuckle as you try!)
A logical conclusion from this statement is that you can't write a "true"
(wonder what that means?) operating system in Lisp. Oops. Symbolics.
Hint: when you're doing that, you add a few well chosen extensions which
you use in the appropriate places.
--
David Gay dg**@acm.org hh****@yahoo.com (Harry Conover) writes: First of all, obviously Java is not an operating system. It's an
application programming language or tool targeted to the production of
Internet (particularly browser applications). You also cannot
implement a true operating system using Java as your programming
language. If you doubt this, I'll hand you an 80586 chip with 128-Megs
of online memory and chuckle as you try!)
A logical conclusion from this statement is that you can't write a "true"
(wonder what that means?) operating system in Lisp. Oops. Symbolics.
Hint: when you're doing that, you add a few well chosen extensions which
you use in the appropriate places.
--
David Gay dg**@acm.org
Jan C. Vorbrüggen <jv**********@mediasec.de> wrote in message news:<40***************@mediasec.de>...
Sorry Jan, I couldn't locate the original source of the text you
quoted and to which I am responding. d) There is no reason to believe a real time system cannot be virtual
machine based. It is technicaly feasible and all the benefits of seperating
code from hardware/OS are just as relevant on embedded systems as they are
on desktops. Just look at cell phones.
I believe that accuracy of this statement depends entirely on the
degree of reaction latency that can be tollerated in the real time
system. Even at today's fantastic execution rates, critical real-time
must occur within only a few machine execution cycles.
The execution latency penalty imposed by my concept of a virtual
machine will, at least in my mind, knock it from consideration for
anything approaching that which is normally required for critical
real-time performance. Here often anything greater than a few
processor instruction cycle latency leads to a non-recoverable error
situation.
This is precisely why interrupt level service routines, fast device
drivers, and similar time-critical operations are generally
implemented in assembly or other low-level code optimized to minimize
the number and duration of required machine instruction executions.
With today's focus on high-level programming languages and software
implemented virtual machines, many people lose sight of the very
fundamental differences that exist between software that simply
executes quickly and real-time system software where interrupt level
response processing must be assured to be alway less than some
critical latency limit. Couple this with the fact that in most
real-time control and operating systems, these latency requirements
are often only a few microseconds and the need for very tightly coded
software becomes obvious.
For an example of real-time OS design, compare the kernel
implementation in something like Wind River's VxWorks RTOS vs. that of
a non-real-time OS such as early Unix or Microsoft Windows.
Particularly note the fact the the task scheduler in a real-time OS of
any reasonable complexity will be both dynamic priority weighted and
perform pre-emptive scheduling because you can't have a slow process
(like I/O) hogging the system and locking out tasks that need to
execute in milliseconds or microseconds.
The above and other considerations in real-time are what cause me to
believe that the utility of a virtual machine so very unrealistic for
RTOS use.
Harry C.
Jan C. Vorbrüggen <jv**********@mediasec.de> wrote in message news:<40***************@mediasec.de>...
Sorry Jan, I couldn't locate the original source of the text you
quoted and to which I am responding. d) There is no reason to believe a real time system cannot be virtual
machine based. It is technicaly feasible and all the benefits of seperating
code from hardware/OS are just as relevant on embedded systems as they are
on desktops. Just look at cell phones.
I believe that accuracy of this statement depends entirely on the
degree of reaction latency that can be tollerated in the real time
system. Even at today's fantastic execution rates, critical real-time
must occur within only a few machine execution cycles.
The execution latency penalty imposed by my concept of a virtual
machine will, at least in my mind, knock it from consideration for
anything approaching that which is normally required for critical
real-time performance. Here often anything greater than a few
processor instruction cycle latency leads to a non-recoverable error
situation.
This is precisely why interrupt level service routines, fast device
drivers, and similar time-critical operations are generally
implemented in assembly or other low-level code optimized to minimize
the number and duration of required machine instruction executions.
With today's focus on high-level programming languages and software
implemented virtual machines, many people lose sight of the very
fundamental differences that exist between software that simply
executes quickly and real-time system software where interrupt level
response processing must be assured to be alway less than some
critical latency limit. Couple this with the fact that in most
real-time control and operating systems, these latency requirements
are often only a few microseconds and the need for very tightly coded
software becomes obvious.
For an example of real-time OS design, compare the kernel
implementation in something like Wind River's VxWorks RTOS vs. that of
a non-real-time OS such as early Unix or Microsoft Windows.
Particularly note the fact the the task scheduler in a real-time OS of
any reasonable complexity will be both dynamic priority weighted and
perform pre-emptive scheduling because you can't have a slow process
(like I/O) hogging the system and locking out tasks that need to
execute in milliseconds or microseconds.
The above and other considerations in real-time are what cause me to
believe that the utility of a virtual machine so very unrealistic for
RTOS use.
Harry C.
"Harry Conover" <hh****@yahoo.com> wrote in message
news:7c**************************@posting.google.c om... Jan C. Vorbrüggen <jv**********@mediasec.de> wrote in message
news:<40***************@mediasec.de>...
Sorry Jan, I couldn't locate the original source of the text you
quoted and to which I am responding.
d) There is no reason to believe a real time system cannot be virtual
machine based. It is technicaly feasible and all the benefits of
seperating code from hardware/OS are just as relevant on embedded systems as they
are on desktops. Just look at cell phones.
I believe that accuracy of this statement depends entirely on the
degree of reaction latency that can be tollerated in the real time
system. Even at today's fantastic execution rates, critical real-time
must occur within only a few machine execution cycles.
The execution latency penalty imposed by my concept of a virtual
machine will, at least in my mind, knock it from consideration for
anything approaching that which is normally required for critical
real-time performance. Here often anything greater than a few
processor instruction cycle latency leads to a non-recoverable error
situation.
This is precisely why interrupt level service routines, fast device
drivers, and similar time-critical operations are generally
implemented in assembly or other low-level code optimized to minimize
the number and duration of required machine instruction executions.
With today's focus on high-level programming languages and software
implemented virtual machines, many people lose sight of the very
fundamental differences that exist between software that simply
executes quickly and real-time system software where interrupt level
response processing must be assured to be alway less than some
critical latency limit. Couple this with the fact that in most
real-time control and operating systems, these latency requirements
are often only a few microseconds and the need for very tightly coded
software becomes obvious.
For an example of real-time OS design, compare the kernel
implementation in something like Wind River's VxWorks RTOS vs. that of
a non-real-time OS such as early Unix or Microsoft Windows.
Particularly note the fact the the task scheduler in a real-time OS of
any reasonable complexity will be both dynamic priority weighted and
perform pre-emptive scheduling because you can't have a slow process
(like I/O) hogging the system and locking out tasks that need to
execute in milliseconds or microseconds.
The above and other considerations in real-time are what cause me to
believe that the utility of a virtual machine so very unrealistic for
RTOS use.
If you're interested into getting to the bottom of this, I'd suggest you
peruse the real time specification for java. That and other related
information can be found here. http://www.rtj.org/
I'm sure it could address your questions better than I ever could. I'd be
interested to hear your comments.
l8r, Mike N. Christoff
"Harry Conover" <hh****@yahoo.com> wrote in message
news:7c**************************@posting.google.c om... Jan C. Vorbrüggen <jv**********@mediasec.de> wrote in message
news:<40***************@mediasec.de>...
Sorry Jan, I couldn't locate the original source of the text you
quoted and to which I am responding.
d) There is no reason to believe a real time system cannot be virtual
machine based. It is technicaly feasible and all the benefits of
seperating code from hardware/OS are just as relevant on embedded systems as they
are on desktops. Just look at cell phones.
I believe that accuracy of this statement depends entirely on the
degree of reaction latency that can be tollerated in the real time
system. Even at today's fantastic execution rates, critical real-time
must occur within only a few machine execution cycles.
The execution latency penalty imposed by my concept of a virtual
machine will, at least in my mind, knock it from consideration for
anything approaching that which is normally required for critical
real-time performance. Here often anything greater than a few
processor instruction cycle latency leads to a non-recoverable error
situation.
This is precisely why interrupt level service routines, fast device
drivers, and similar time-critical operations are generally
implemented in assembly or other low-level code optimized to minimize
the number and duration of required machine instruction executions.
With today's focus on high-level programming languages and software
implemented virtual machines, many people lose sight of the very
fundamental differences that exist between software that simply
executes quickly and real-time system software where interrupt level
response processing must be assured to be alway less than some
critical latency limit. Couple this with the fact that in most
real-time control and operating systems, these latency requirements
are often only a few microseconds and the need for very tightly coded
software becomes obvious.
For an example of real-time OS design, compare the kernel
implementation in something like Wind River's VxWorks RTOS vs. that of
a non-real-time OS such as early Unix or Microsoft Windows.
Particularly note the fact the the task scheduler in a real-time OS of
any reasonable complexity will be both dynamic priority weighted and
perform pre-emptive scheduling because you can't have a slow process
(like I/O) hogging the system and locking out tasks that need to
execute in milliseconds or microseconds.
The above and other considerations in real-time are what cause me to
believe that the utility of a virtual machine so very unrealistic for
RTOS use.
If you're interested into getting to the bottom of this, I'd suggest you
peruse the real time specification for java. That and other related
information can be found here. http://www.rtj.org/
I'm sure it could address your questions better than I ever could. I'd be
interested to hear your comments.
l8r, Mike N. Christoff
"This is a serious problem. This is an extremely serious anomaly," said Pete
Theisinger Spirit project manager.
"There is no single fault that explains all the observables."
"...but Spirit was only transmitting "pseudo-noise", a random series of
zeroes and ones in binary code and not anything the scientists could
decipher." http://news.bbc.co.uk/1/hi/sci/tech/3421071.stm
l8r, Mike N. Christoff
"This is a serious problem. This is an extremely serious anomaly," said Pete
Theisinger Spirit project manager.
"There is no single fault that explains all the observables."
"...but Spirit was only transmitting "pseudo-noise", a random series of
zeroes and ones in binary code and not anything the scientists could
decipher." http://news.bbc.co.uk/1/hi/sci/tech/3421071.stm
l8r, Mike N. Christoff
"Michael N. Christoff" <mc********@sympatico.caREMOVETHIS> wrote in message <news:LJ********************@news20.bellglobal.com >... "This is a serious problem. This is an extremely serious anomaly," said Pete
Theisinger Spirit project manager.
"There is no single fault that explains all the observables."
"...but Spirit was only transmitting "pseudo-noise", a random series of
zeroes and ones in binary code and not anything the scientists could
decipher."
http://news.bbc.co.uk/1/hi/sci/tech/3421071.stm
Are they sure it's not just Sun's JVM taking a break to do a GC?
--
Joe Foster <mailto:jlfoster%40znet.com> "Regged" again? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!
"Michael N. Christoff" <mc********@sympatico.caREMOVETHIS> wrote in message <news:LJ********************@news20.bellglobal.com >... "This is a serious problem. This is an extremely serious anomaly," said Pete
Theisinger Spirit project manager.
"There is no single fault that explains all the observables."
"...but Spirit was only transmitting "pseudo-noise", a random series of
zeroes and ones in binary code and not anything the scientists could
decipher."
http://news.bbc.co.uk/1/hi/sci/tech/3421071.stm
Are they sure it's not just Sun's JVM taking a break to do a GC?
--
Joe Foster <mailto:jlfoster%40znet.com> "Regged" again? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!
"Joe "Nuke Me Xemu" Foster" <jo*@bftsi0.UUCP> wrote in message
news:10**************@news-1.nethere.net... "Michael N. Christoff" <mc********@sympatico.caREMOVETHIS> wrote in
message <news:LJ********************@news20.bellglobal.com >... "This is a serious problem. This is an extremely serious anomaly," said
Pete Theisinger Spirit project manager.
"There is no single fault that explains all the observables."
"...but Spirit was only transmitting "pseudo-noise", a random series of
zeroes and ones in binary code and not anything the scientists could
decipher."
http://news.bbc.co.uk/1/hi/sci/tech/3421071.stm
Are they sure it's not just Sun's JVM taking a break to do a GC?
If they were using standard Java (ie: not a real-time version) that would
not be beyond the realm of possibility. Hopefully its something just as
recoverable. (Note: I'm pretty certain Java is not actually running on
the rover itself).
l8r, Mike N. Christoff
"Joe "Nuke Me Xemu" Foster" <jo*@bftsi0.UUCP> wrote in message
news:10**************@news-1.nethere.net... "Michael N. Christoff" <mc********@sympatico.caREMOVETHIS> wrote in
message <news:LJ********************@news20.bellglobal.com >... "This is a serious problem. This is an extremely serious anomaly," said
Pete Theisinger Spirit project manager.
"There is no single fault that explains all the observables."
"...but Spirit was only transmitting "pseudo-noise", a random series of
zeroes and ones in binary code and not anything the scientists could
decipher."
http://news.bbc.co.uk/1/hi/sci/tech/3421071.stm
Are they sure it's not just Sun's JVM taking a break to do a GC?
If they were using standard Java (ie: not a real-time version) that would
not be beyond the realm of possibility. Hopefully its something just as
recoverable. (Note: I'm pretty certain Java is not actually running on
the rover itself).
l8r, Mike N. Christoff
"Joe "Nuke Me Xemu" Foster" <jo*@bftsi0.UUCP> wrote in message
news:10**************@news-1.nethere.net...
| "Michael N. Christoff" <mc********@sympatico.caREMOVETHIS> wrote in
message <news:LJ********************@news20.bellglobal.com >...
|
| > "This is a serious problem. This is an extremely serious anomaly," said
Pete
| > Theisinger Spirit project manager.
| > "There is no single fault that explains all the observables."
| >
| > "...but Spirit was only transmitting "pseudo-noise", a random series of
| > zeroes and ones in binary code and not anything the scientists could
| > decipher."
| >
| >
| > http://news.bbc.co.uk/1/hi/sci/tech/3421071.stm
|
| Are they sure it's not just Sun's JVM taking a break to do a GC?
Unless, of course, the software was written
in something like C++ (as has been suggested[?],
and is more likely).
In that case, would it be more likely caused by,
"dangling pointers to objects in deleted heaps"
perhaps? ;-)
--
Andrew Thompson
* http://www.PhySci.org/ PhySci software suite
* http://www.1point1C.org/ 1.1C - Superluminal!
* http://www.AThompson.info/andrew/ personal site
"Joe "Nuke Me Xemu" Foster" <jo*@bftsi0.UUCP> wrote in message
news:10**************@news-1.nethere.net...
| "Michael N. Christoff" <mc********@sympatico.caREMOVETHIS> wrote in
message <news:LJ********************@news20.bellglobal.com >...
|
| > "This is a serious problem. This is an extremely serious anomaly," said
Pete
| > Theisinger Spirit project manager.
| > "There is no single fault that explains all the observables."
| >
| > "...but Spirit was only transmitting "pseudo-noise", a random series of
| > zeroes and ones in binary code and not anything the scientists could
| > decipher."
| >
| >
| > http://news.bbc.co.uk/1/hi/sci/tech/3421071.stm
|
| Are they sure it's not just Sun's JVM taking a break to do a GC?
Unless, of course, the software was written
in something like C++ (as has been suggested[?],
and is more likely).
In that case, would it be more likely caused by,
"dangling pointers to objects in deleted heaps"
perhaps? ;-)
--
Andrew Thompson
* http://www.PhySci.org/ PhySci software suite
* http://www.1point1C.org/ 1.1C - Superluminal!
* http://www.AThompson.info/andrew/ personal site
"Michael N. Christoff" wrote:
"This is a serious problem. This is an extremely serious anomaly," said Pete
Theisinger Spirit project manager.
"There is no single fault that explains all the observables."
"...but Spirit was only transmitting "pseudo-noise", a random series of
zeroes and ones in binary code and not anything the scientists could
decipher."
http://news.bbc.co.uk/1/hi/sci/tech/3421071.stm
NASA is renowned for its antenna failures - the Hubble space
telescope, Ulysses at Jupiter, and now their little radio-controlled
go-cart on Mars.
Uncle Al eagerly anticipates a Hummer-2 advert beginning with the $240
million pigmy brain fart that couldn't call home. Anticipating that
its working life would be less than 90 days because of dust
accumulating on its solar panels is also precious. Hey NASA, "blow
job."
One presumes the same engineering glitch is in the other rover.
--
Uncle Al http://www.mazepath.com/uncleal/
(Toxic URL! Unsafe for children and most mammals)
"Quis custodiet ipsos custodes?" The Net!
"Michael N. Christoff" wrote:
"This is a serious problem. This is an extremely serious anomaly," said Pete
Theisinger Spirit project manager.
"There is no single fault that explains all the observables."
"...but Spirit was only transmitting "pseudo-noise", a random series of
zeroes and ones in binary code and not anything the scientists could
decipher."
http://news.bbc.co.uk/1/hi/sci/tech/3421071.stm
NASA is renowned for its antenna failures - the Hubble space
telescope, Ulysses at Jupiter, and now their little radio-controlled
go-cart on Mars.
Uncle Al eagerly anticipates a Hummer-2 advert beginning with the $240
million pigmy brain fart that couldn't call home. Anticipating that
its working life would be less than 90 days because of dust
accumulating on its solar panels is also precious. Hey NASA, "blow
job."
One presumes the same engineering glitch is in the other rover.
--
Uncle Al http://www.mazepath.com/uncleal/
(Toxic URL! Unsafe for children and most mammals)
"Quis custodiet ipsos custodes?" The Net!
"Andrew Thompson" <an******@bigNOSPAMpond.com> wrote in message <news:TV******************@news-server.bigpond.net.au..>. "Joe "Nuke Me Xemu" Foster" <jo*@bftsi0.UUCP> wrote in message
news:10**************@news-1.nethere.net...
| Are they sure it's not just Sun's JVM taking a break to do a GC?
Unless, of course, the software was written
in something like C++ (as has been suggested[?],
and is more likely).
There are go-to-lunch slow garbage collectors for C++ too, such as
the "managed C++" abomination Microslop is trying to shove through
the ECMA. Apparently nothing is safe from the "embrace and extend"
standards pollution and proprietarization strategy.
In that case, would it be more likely caused by,
"dangling pointers to objects in deleted heaps"
perhaps? ;-)
That can happen when some chimp-coder can't quite comprehend RAII.
Another common fudgeup is to throw an exception from a destructor.
--
Joe Foster <mailto:jlfoster%40znet.com> "Regged" again? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!
"Andrew Thompson" <an******@bigNOSPAMpond.com> wrote in message <news:TV******************@news-server.bigpond.net.au..>. "Joe "Nuke Me Xemu" Foster" <jo*@bftsi0.UUCP> wrote in message
news:10**************@news-1.nethere.net...
| Are they sure it's not just Sun's JVM taking a break to do a GC?
Unless, of course, the software was written
in something like C++ (as has been suggested[?],
and is more likely).
There are go-to-lunch slow garbage collectors for C++ too, such as
the "managed C++" abomination Microslop is trying to shove through
the ECMA. Apparently nothing is safe from the "embrace and extend"
standards pollution and proprietarization strategy.
In that case, would it be more likely caused by,
"dangling pointers to objects in deleted heaps"
perhaps? ;-)
That can happen when some chimp-coder can't quite comprehend RAII.
Another common fudgeup is to throw an exception from a destructor.
--
Joe Foster <mailto:jlfoster%40znet.com> "Regged" again? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!
"Joe "Nuke Me Xemu" Foster" <jo*@bftsi0.UUCP> wrote in message
| "Andrew Thompson" <an******@bigNOSPAMpond.com> wrote in message
| > "Joe "Nuke Me Xemu" Foster" <jo*@bftsi0.UUCP> wrote in message
|
| > | Are they sure it's not just Sun's JVM taking a break to do a GC?
| >
| > Unless, of course, the software was written
| > in something like C++ (as has been suggested[?],
| > and is more likely).
|
| There are go-to-lunch slow garbage collectors for C++ too, such as
| the "managed C++" abomination Microslop..
LOL - love that one Joe, I'll have to
add it to my list of MafiaSoft, M$,
Windoze and MicroBastard* ..
* Has a particularly Australian flavor.
Aussies enjoy that the second word
does not even derive from a word
that starts with the same/similar
letter. ;-)
--
Andrew Thompson
* http://www.PhySci.org/ PhySci software suite
* http://www.1point1C.org/ 1.1C - Superluminal!
* http://www.AThompson.info/andrew/ personal site
"Joe "Nuke Me Xemu" Foster" <jo*@bftsi0.UUCP> wrote in message
| "Andrew Thompson" <an******@bigNOSPAMpond.com> wrote in message
| > "Joe "Nuke Me Xemu" Foster" <jo*@bftsi0.UUCP> wrote in message
|
| > | Are they sure it's not just Sun's JVM taking a break to do a GC?
| >
| > Unless, of course, the software was written
| > in something like C++ (as has been suggested[?],
| > and is more likely).
|
| There are go-to-lunch slow garbage collectors for C++ too, such as
| the "managed C++" abomination Microslop..
LOL - love that one Joe, I'll have to
add it to my list of MafiaSoft, M$,
Windoze and MicroBastard* ..
* Has a particularly Australian flavor.
Aussies enjoy that the second word
does not even derive from a word
that starts with the same/similar
letter. ;-)
--
Andrew Thompson
* http://www.PhySci.org/ PhySci software suite
* http://www.1point1C.org/ 1.1C - Superluminal!
* http://www.AThompson.info/andrew/ personal site
I think they should turn it off and turn it on again.
"Andrew Thompson" <an******@bigNOSPAMpond.com> wrote in message news:<TV******************@news-server.bigpond.net.au>... "Joe "Nuke Me Xemu" Foster" <jo*@bftsi0.UUCP> wrote in message
news:10**************@news-1.nethere.net...
| "Michael N. Christoff" <mc********@sympatico.caREMOVETHIS> wrote in
message <news:LJ********************@news20.bellglobal.com >...
|
| > "This is a serious problem. This is an extremely serious anomaly," said
Pete
| > Theisinger Spirit project manager.
| > "There is no single fault that explains all the observables."
| >
| > "...but Spirit was only transmitting "pseudo-noise", a random series of
| > zeroes and ones in binary code and not anything the scientists could
| > decipher."
| >
| >
| > http://news.bbc.co.uk/1/hi/sci/tech/3421071.stm
|
| Are they sure it's not just Sun's JVM taking a break to do a GC?
Unless, of course, the software was written
in something like C++ (as has been suggested[?],
and is more likely).
In that case, would it be more likely caused by,
"dangling pointers to objects in deleted heaps"
perhaps? ;-)
I think they should turn it off and turn it on again.
"Andrew Thompson" <an******@bigNOSPAMpond.com> wrote in message news:<TV******************@news-server.bigpond.net.au>... "Joe "Nuke Me Xemu" Foster" <jo*@bftsi0.UUCP> wrote in message
news:10**************@news-1.nethere.net...
| "Michael N. Christoff" <mc********@sympatico.caREMOVETHIS> wrote in
message <news:LJ********************@news20.bellglobal.com >...
|
| > "This is a serious problem. This is an extremely serious anomaly," said
Pete
| > Theisinger Spirit project manager.
| > "There is no single fault that explains all the observables."
| >
| > "...but Spirit was only transmitting "pseudo-noise", a random series of
| > zeroes and ones in binary code and not anything the scientists could
| > decipher."
| >
| >
| > http://news.bbc.co.uk/1/hi/sci/tech/3421071.stm
|
| Are they sure it's not just Sun's JVM taking a break to do a GC?
Unless, of course, the software was written
in something like C++ (as has been suggested[?],
and is more likely).
In that case, would it be more likely caused by,
"dangling pointers to objects in deleted heaps"
perhaps? ;-)
"Rick Osborn" <ri************@yahoo.com> wrote in message <news:27**************************@posting.google. com>... I think they should turn it off and turn it on again.
They need to reinstall Winblows...
--
Joe Foster <mailto:jlfoster%40znet.com> Sacrament R2-45 <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha! This discussion thread is closed Replies have been disabled for this discussion. Similar topics
33 posts
views
Thread by jacob navia |
last post: by
| | | | | | | | | | | | | | | | | | | |
