Glass Panel Longevity

On Sat, 21 Oct 2006 09:26:37 +0200, Mxsmanic
wrote:

Sylvain writes:

you just made it clear that you do not understand how open
source development works.

I understand exactly how it works, and so does the market, which is
why safety-of-life software (and much other mission-critical software)
tends to be proprietary.

I know I shouldn't do this but... proprietary and safety-of-life
software are linked not because of safety but because of "for profit".
IE they are proprietary because they do not want others to know how
they are doing what they are doing.
Open source would mean providing the source code and they don't want
that. Hence the de compiling and reverse engineering clauses in the
license as well

The only thing difficult about de compiling or disassembling is the
size of the current state and next state arrays for today's
processors. In the days of the 6502 and straight C they were small,
compact, fast, and easy to write.
In the case of compilers and de compilers you only need to change the
two arrays to change languages or processors. Today the arrays for an
assembler/disassemble are huge. What's the size of the instruction set
for a late model Athlon or Pentium? The set for a 6502 or Z80 would
fit onto 4 sheets the size of a bingo card and by chance were referred
to as bingo cards.

Any good software engineer could write a disassembler and decompiler
to turn that proprietary software into readable code, (there's a bit
more to it that but I'll leave it there) BUT who'd want to. You'd then
have to sift through many thousands of lines of code. Any company that
did that would need a team to do the sifting and the feds tend to
frown on the whole process.

In my undergrad work I had to write a compiler in one term. In
graduate school the same class with the same book (different
university) was split between two terms (one of which was 500 level)
and was 8 credit hours instead of 4. They wouldn't let me take it
again :-))
Roger Halstead (K8RI & ARRL life member)
(N833R, S# CD-2 Worlds oldest Debonair)
www.rogerhalstead.com

On Fri, 20 Oct 2006 16:47:48 -0700, Sylvain wrote:

Grumman-581 wrote:

Unfortunately, some of the people making the decisions in these companies
don't necessarily see it that way...

so in short, the only reasonable long term stragegy would be to make
these things open source; I couldn't agree more, but how do you
go about achieving this? the manufacturer must either be coerced in
doing it (via regulations) or have a good incentive, i.e., a

Even if "open source" you have not addressed the hard ware you have in
hand issue. It would make it easier to replace with something more
modern, BUT what ever goes in would need to be certified. But for a
major piece of hard ware having a chip fail that is no longer
available...what do you do? Developing a replacement board, even if
you know the signal config into and out of the board, is going to be
expensive to the point of not being economically viable.

What would be nice would be some sort of standardization for the I/O
protocols instead of every one doing it "their own way". Of course I
think the same thing about the controls.

painfully obvious -- as in, that even the most bone-headed MBA
waiving PHB manager could understand -- evidence that it would
be in their best interest to open up at least the interface
specs. But considering what I have seen so far in the industry
I am not holding my breath...

--Sylvain
Roger Halstead (K8RI & ARRL life member)
(N833R, S# CD-2 Worlds oldest Debonair)
www.rogerhalstead.com

On Thu, 19 Oct 2006 12:58:12 -0500, "Barney Rubble"
wrote:

Don't forget the GPS-90, which no longer has updates from either Garmin or
Jepp, so the question is for both of them, the G1000 would be useless if
Jepp pull the plug. The price of keeping all this data up to date in these
modern machines is a very real hidden cost (XM, nav data etc).


I wouldn't call it hidden. It's right there just like a chart
subscription and it's in a propritary format so we can't download and
install the updated goverment information.


"john smith" wrote in message
...
The recent thread regarding the lack of parts for the Garmin 480 got me
to wondering just how long the G-1000's will "live"?
Steam gauges are forever, but integrated circuits are produced for a
given period, then production is ceased as newer chips come along.
Does Garmin mention anywhere how long they will support their products?
Their earliest GPS handhelds are coming up on 20 years.
We have seen Lowrence discontinue support for some of their products
that are less than 10 years old.

Roger Halstead (K8RI & ARRL life member)
(N833R, S# CD-2 Worlds oldest Debonair)
www.rogerhalstead.com

"Roger (K8RI)" wrote in message
...
DLLs work great and are easy to use but things can get interesting if
some one changes one as in an MS update:-)) They don't bother to
tell you what they changed in which module. They are both the strong
and weak points of the MS operating systems.

Yeah, you ask 'em about it and you get "nawh, nothing changed"... Once you
finally trace it down to something that is acting differently in their DLL,
you get a "oh, *that*... I forgot about that, but it *shouldn't* make a
difference"... If I'm writing an interface that is to be used by other
developers, especially if they are developing in a different language than I
am, I'll make it a DLL, but I'll also create a static library in case they
have the capability to link directly to it... Although they provide a lot of
flexibility and initially I like them, I've come to believe that they create
more headaches at a later date than they are often worth... When trying to
debug a user's problem at a later date, you need to determine if he is using
the same exact versions of all the DLLs that you used when you created the
system... More often than not, either he or a MS update changed something...

Man,it must be boring with programs that do the same thing every time.
Where's you sense of adventure. The thrill of hunting for side
effects that weren't there when you first debugged the program. Side
effects caused in some code written by some one else some where in a
library that may contain hundreds of thousands of lines of code.

I've been in this profession enough years that I don't get enjoyment ****ing
on an electrical fence multiple times... The new kids out there think that
they should use the latest thing that MS provides... They haven't been
around long enough to realize that if you insist on doing that, you will not
have a stable system... At the very least, you'll be always changing your
code to conform with the latest and (supposedly) greatest even if you luck
out and are not chasing bugs that the MS updates throw your way...

Third party DLLs *could* be written in such a manner that they would
not cause problems but that's not the case.

When I write DLLs, I always give a function that returns version information
associated with it just in case the file size doesn't change or someone
changes the date on the file... I also write my DLLs so that they do not
need to be registered... Same with my applications... My philosophy is that
the installation of an application should consist of dropping the
application's files into a particular directory and running it from there...
I especially don't like the MS idea of putting all the DLLs in the windows
directory... If you do it their way and two applications have DLLs by the
same name, you're likely to get screwed rather quickly... If you do it my
way, it's possible for multiple applications to have the same names for
their DLLs and more importantly, it's possible to have multiple versions of
the same application installed upon your machine...

Plus they would make certification almost impossible as the
program code can change without being checked against
certification. I wonder when you refer to the Y2K mess
if you might be referring to a very large drafting program
where the programmers rewrote some standard DLLs?
Update the OS, or DLL and the program would quit.
Put the original DLL back and strange things could start
happening to other stuff.

Nawh, most of the stuff was for in-house applications for the company for
which I was contracting to at that time... None of the applications were CAD
related... The problems that I'm referring to is related to when we knew
that a problem was going to develop... Originally, we knew that on 1/1/2000,
some systems were going to have a problem... The obvious fix for that is to
change it to a 4-digit year and we should be set for the next 8,000 years...
Yeah, it's not a permanent solution, but it's probably safe enough in that
it is rather unlikely that any program running today will still be running
in 8,000 years... Did we use this solution? No ****in' way... Instead, we
went with a date window approach so that if the 2-digit year is less than a
certain value, it refers to the 1900s and if it is greater than that value,
it refers to the 2000s... The problem arises in that there is no common
cutoff date between the various systems... For one system, a 2-digit year of
"30" might mean "1930", whereas for another system, it might mean "2030".. A
lot of these "fixes" were to 3rd party DLLs, so we might not even be sure of
when the cutoff date is going to be... Basically, we traded a known single
problem date for multiple future problem dates and we don't know when they
are either... Now, throw into this the fact that some of the DLLs are from
MS and they might get updated during various service packs and such and you
have a system where you cannot guarantee it will run as it did in your test
bed...

Then there was VB up through I believe version 5. Write a program,
compile it as stand alone so it contained all the necessary DLLs and
guess what. The DLL creation date was not the original creation date,
but the date the program was compiled. So installing that program
would (not could) result in newer DLLs being over written by older
DLLs with a newer creation date. Man but that one about drove me nuts
trying to sort out.

Yeah, VB was always good for decreasing your cranial hair count... I
remember in one of the versions how they changed the way that they passed
values to DLLs... That ****ed over my DLLs rather quickly... It took awhile
before I stumbled across a couple of lines in the manual about that
change...

What? You don't like "side effects" and here I thought they were a
feature and not a bug. :-)) No sense of adventure at all.

Yep, no sense of adventure... Hell, I even don't like writing the same code
twice and carry around common libraries that I've written over the years
from project to project so I don't have to waste time doing the exact same
thing again... I believe in having a single set of code that can compile on
every platform upon which the application needs to run... I don't like
having to make the same change in multiple sets of source code... Yeah, I
guess I'm just lazy... grin

"Grumman-581" wrote

Yeah, VB was always good for decreasing your cranial hair count

What is the VB program to which you are talking about?

Head slap to follow, most likely! g
--
Jim in NC

"Grumman-581" writes:

I've been in this profession enough years that I don't get enjoyment ****ing
on an electrical fence multiple times... The new kids out there think that
they should use the latest thing that MS provides... They haven't been
around long enough to realize that if you insist on doing that, you will not
have a stable system... At the very least, you'll be always changing your
code to conform with the latest and (supposedly) greatest even if you luck
out and are not chasing bugs that the MS updates throw your way...

Yes. Now multiply this by 1000 and apply it to aviation.

Problems with a desktop PC are an inconvenience. Problems with
avionics can be a deathtrap.

And unfortunately, the people building some of the latter systems have
a culture derived from the former, and that's a very bad thing.

--
Transpose mxsmanic and gmail to reach me by e-mail.

Roger (K8RI) writes:

I know I shouldn't do this but... proprietary and safety-of-life
software are linked not because of safety but because of "for profit".

They are also linked because of accountability and stability issues.
One reason people buy proprietary products is that the manufacturer
can be held accountable and is unlikely to have multiple,
uncontrolled, unverified versions floating around. The greater the
potential liability or revenue loss for the vendor, the more stable
and reliable the proprietary product will be.

In open source, there is neither accountability nor stability, and
there is no profit motive, either. This militates against the kind of
security that safety-of-life applications require.

--
Transpose mxsmanic and gmail to reach me by e-mail.

In article ,
"Morgans" wrote:

Yeah, VB was always good for decreasing your cranial hair count

What is the VB program to which you are talking about?

Probably visual basic


Head slap to follow, most likely! g

......

--
Bob Noel
Looking for a sig the
lawyers will hate

On Sun, 22 Oct 2006 04:56:34 -0400, Bob Noel
wrote:

In article ,
"Morgans" wrote:

Yeah, VB was always good for decreasing your cranial hair count

What is the VB program to which you are talking about?

Probably visual basic

Yup!

I don't remember if they changed with version 5 or after version 5,
but prior to the change compiling a stand alone program some times
brought along some surprising and unwanted side effects. More than
once I had to copy the offending DLL into the directory with the VB
program and then restore the original DLL in the windows directory. It
was a royal PITA.

As a side note, you could start with about 37K of source code which is
what the greeters program ran for the EAA. That compiled into about 7
megs due to the DLLs




Head slap to follow, most likely! g

.....
Roger Halstead (K8RI & ARRL life member)
(N833R, S# CD-2 Worlds oldest Debonair)
www.rogerhalstead.com

Morgans wrote:
What is the VB program to which you are talking about?

At that time, it was in-house developed security administration
software... The real work was done in 'C' (i.e. the various daemons,
services, and DLLs, and the gee-whiz user interfaces were in VB... It
allowed us to utilize developers who could paint pretty pictures ...
uhhh ... user interfaces ... but who were not really competent in the
technical matters of communicating with remote machines, much less the
security aspects of each of the different platforms... I gave the VB
developers a nice library interface that made adding a new system pretty
much cookie cutter for them and they put the bells and whistles in it to
make it look fancy for the users...