> > No offense, but I would be extremely nervous placing a system into
> > based on hand-coded examples taken from a magazine.
> Basicly yes. But you are only nervous because you cannot make good
> programs your self! And if one is programming satellites he has to
> also his own programming skills!
If I'm hiring someone to develop software for me, I'm certainly not
going to trust their programming skills. Only the test results will
prove whether or not they can produce a system that works.
In my opinion, the converse is also true: trusting a person's
programming skills without proving them is a fools paradise.
> > In my opinion, your time would be better spent understanding,
> > developing, and testing your application software. Buy the parts
> > aren't directly relevant to your application (operating systems,
> > debugging tools, networking protocols, etc.) from reputable
> vendors with
> > measurable market shares.
> This sounds like this person is self making some commercial systems.
> would say that all the parts are very relevants to a system because
> in any part will usually hang the whole system! I am only refering
> to the
> many satellites that don't work after sending them! The problem is
> not being able to make good fail safe systems!
Read my signature: I'm not a commercial RTOS vendor. But I HAVE gotten
paid for the last five years or so to fix problems by people who said
"trust me, I know what I'm doing" but then failed to deliver.
One of these assignments was explicitly to fix problems in a
hand-written RTOS; several other assignments involved systems that
either needed an operating system and didn't have one, or had one and
didn't use it very well.
By the way, the systems I work on don't have the luxury of allowing
themselves to be crippled by a single point of failure.
> And when the code what one need to implement parallel threads is 30
> lines .. one cannot make so many bugs. One can use a full blown
> system with lot of code if one you wants. But I am sure that there
> also many more problems when learning and testing it.
Lots of the bugs I fix involve only one or two lines of code. I'd guess
that's pretty typical.
> > That's not to say that commercial operating systems are perfect.
> > However, they've got lots of people testing them (the users), so
> > more likely to be closer to perfect than something written by
> > whose career doesn't depend upon having a decent product, or has
> > prior experience with that type of application.
> Yes. Sure testing. But the bug reports that you send are just put
I find such a general statement completely ridiculous.
> The people making new and bigger systems are too busy to make more
> that they don't any more bother with that old system you are sending
> reports from. They don't have the time. And the new system will
> do everything in a different manner. Spending time in the old system
> only lost money. Because they will never get any more money from
> Better to make a completly new system and sell it to the user!!!!
> And that
> is only done by introducing some new properties (and bugs)!
This sounds a lot like "not invented here" syndrome. I don't know about
the kind of companies you deal with, but the ones I work with tend to be
more responsive than you describe, at least the ones that want to stay
> > At the end of the day, I've consistently found that I can buy
> > components and their related development and testing tools much
> > cheaply than I can develop, debug, and test them myself, despite
> > apparently high price tags.
> Nobody is asking here to get something cheap!
> > First: someday your satellite will head for orbit (I bet the date
> > already set), which leaves you a fixed amount of time to develop
> > application. Doesn't it make the most sense to spend the most
> > possible developing, refining, and testing the software directly
> > to your experiments? Buy the rest, because if you decide to build
> > yourself and get mired down to the point you miss your launch date
> > deliver a satellite that fails in orbit), you might as well not
> > started the project in the first place.
> It is no wonder if the satellite would stop working after sent .. if
> not spend any time developing, refining and testing it!!!! Testing
> is the
> most important part of the whole system! Make the system more simply
> if no time. But never stop testing it! What the use to send there
> that does not work (it is same as send a stone there). Better to
> change the
> launch date and send it later when sure that it works!
I don't do space work, but my impression is that it's not so easy to
change a launch date, especially when you're not the only payload.
Testing is NOT the most important part of the system. Rather, each
phase in the development cycle is equally important. Neglect one, and
it's possible that no amount of effort will help you recover in a later
Furthermore, just because a system passes its tests doesn't mean it
works, unless your tests are a complete simulation of the working
environment. I find that even in uncomplicated systems, this is
extremely difficult to achieve.
> > Second: if you do experience a failure in orbit, do you want to
> say it's
> > because you "copied some code [buggy] from a magazine" (or from
> Who is this person to tell what is buggy when he don't even know
> the system or code is about! Or do one have to say at a failure
> "made as
> some idiot wrote in a news group!"
My point is: "don't trust skills you don't have".
> I have seen so many buggy systems that I trust only my self in
> sections! The only problem is that commercial products tend to
> more on selling than making them debugged. When you once have the
> system and the people have your money. They care less about the bugs
> in that system. They try to make more code and properties in order
> sell it more. Nobody makes less in order to make it more ROBUST!
> Every new more line will introduce a new possibility to a bug.
There's that "not invented here" syndrome again. See my point.
> It is well known that programs that are good and programs that sell
> (bif market shares) are not in the same category. Making a program
> sell means that it needs to be more than the competitors program.
> that is when it gets bigger and bigger. And this is done so fast as
> to stay one step ahead all other programs. And when you make
> in a hurry you make bugs. And if the bugs don't show very soon ..
> who cares
> .. as long you have the money! Get the picture?
> I was only telling what I WOULD DO. This is because: What you have
> done and tested is much better than something somebody sometimes
> If you don't know very well who that one was/is and how it was done!
I disagree. Someone who's written several operating systems, maintained
a few commercial versions, and experimented with future versions is much
more qualified to develop and sell an operating system than someone who
hasn't. These qualifications will help assure that the product works.
Furthermore, if something works well, and people need it, then they'll
buy it. If it doesn't work, people won't buy it. So, market share is a
(partial) figure of merit for the quality of a software product.
If a vendor wants to keep that market share, they'll make sure the
product delivers what it promises. This doesn't always mean the
software gets bigger; it usually means it gets better.
> Something which has a big market share and plenty of kilo bytes is
> so often something which is robust and fail safe! Having tested
> some 20 years have seen this too often!
> "Sorry .. but that is the sad story with most commercial
> programs .. money, money, money!"
> P.S. Why not use several methods and some kind of a switch to change
> to an other implementation in case of problems? Or make a system
> can be downloaded when in orbit. In case of problems just send a new
> program. The basic code to implement the download mechanism should
> be very small and very well tested to avoid bugs in it. Some kind of
> a boot
> And there are plenty of material around about how to make failure
> systems. I would read some of these too.
Your P.S. fit in nicely with a thread that's been here recently, about
how deceptively difficult it is to make a truly fault-tolerant system.
It's definitely NOT easy (witness how few of them are around), and is
definitely not something somebody can just hack out.
William A. Gatliff
Cummins Engine Company, Inc.
PO Box 3005 MC 7003
Columbus, IN 47202