If ever there is need for MISRA C then this is it!

In article <1177172189.846085.301370@y80g2000hsf.googlegroups.com>, 
larwe <zwsdotcom@gmail.com> writes
>On Apr 20, 10:33 am, Rob Horton <yahoo@mr_horton.com> wrote:
>> Just to make me feel even more insecure about 
>>flying.http://www.cashloopholes.co.uk/modules.php?name=Forums&file=view
>>topic...
>
>I call bullshit; complete, utter, unmitigated, no-excuses, no-holds-
>barred partially-digested plant matter liquid ordure gushing from the
>rectum of a male bovine directly into HTML format.
>
>I ask all the engineers here - what is easier to design? A multihead
>system that drives 400 or 500 screens directly from a single CPU box
>running multiple threads on a [plurality of] CPUs, or 500 single-head
>systems that run a single game OS, like a Nintendo Gameboy, and
>communicate the voice stuff for the phone over a local network?
>
>If you were designing the latter, why would you need to propagate a
>LOCAL game configuration parameter to all the units in the network?
>Why would this crash any of them?

As per the USS Yorktown?

>I'm utterly certain this story is a completely bogus fabrication which
>someone is trying desperately to promote into an urban legend.


I understand that they tried that tactic with the USS Yourktown too. 
However that did have several cases where one PC brought down the entire 
ship.

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

On Sat, 21 Apr 2007 23:28:50 +0100, Steve at fivetrees wrote:

> Nowadays, when I meet clients, I get them to concentrate on requirements 
> only (including cost/weight etc). I forbid them to think in terms of 
> implementation until after they've seen my proposal (which usually manages 
> to explain why the solution they were originally thinking of was a Really 
> Bad Idea).

Could you, please, give an example?

M.

"Marcin Wolcendorf" <wolcendo@friko2.onet.pl> wrote in message 
news:f0fokr$t5v$1@nemesis.news.tpi.pl...
> On Sat, 21 Apr 2007 23:28:50 +0100, Steve at fivetrees wrote:
>
>> Nowadays, when I meet clients, I get them to concentrate on requirements
>> only (including cost/weight etc). I forbid them to think in terms of
>> implementation until after they've seen my proposal (which usually 
>> manages
>> to explain why the solution they were originally thinking of was a Really
>> Bad Idea).
>
> Could you, please, give an example?

Sure. One that comes up fairly regularly these days is web-enabled gadgets. 
Nothing wrong with that, but when the application is mission-critical, is in 
charge of some heavy-duty equipment, and has a tiny TCP/IP implementation, 
one wants more security than these gadgets can provide. This is not often an 
area that clients know enough about...

Another one is basing an embedded product on Windows "because it's easier". 
Enough said ;).

Steve
http://www.fivetrees.com 

Hi,

On Sun, 22 Apr 2007 18:06:16 +0100, Steve at fivetrees wrote:

> "Marcin Wolcendorf" <wolcendo@friko2.onet.pl> wrote in message 
> news:f0fokr$t5v$1@nemesis.news.tpi.pl...
>> On Sat, 21 Apr 2007 23:28:50 +0100, Steve at fivetrees wrote:
>>
>>> Nowadays, when I meet clients, I get them to concentrate on requirements
>>> only (including cost/weight etc). I forbid them to think in terms of
>>> implementation until after they've seen my proposal
...
>> Could you, please, give an example?
> 
> Sure. One that comes up fairly regularly these days is web-enabled gadgets. 
> Nothing wrong with that, but when the application is mission-critical, is in 
> charge of some heavy-duty equipment, and has a tiny TCP/IP implementation, 
> one wants more security than these gadgets can provide. This is not often an 
> area that clients know enough about...
> 
> Another one is basing an embedded product on Windows "because it's easier". 
> Enough said ;).

So you actually make them let you do your job. How do they react? I mean- do
they try to interfere? Accept it? Try to pick up the subject anyway?


M.

"Marcin Wolcendorf" <wolcendo@friko2.onet.pl> wrote in message 
news:f0ggrg$a3v$1@nemesis.news.tpi.pl...
> Hi,
>
> On Sun, 22 Apr 2007 18:06:16 +0100, Steve at fivetrees wrote:
>
>> "Marcin Wolcendorf" <wolcendo@friko2.onet.pl> wrote in message
>> news:f0fokr$t5v$1@nemesis.news.tpi.pl...
>>> On Sat, 21 Apr 2007 23:28:50 +0100, Steve at fivetrees wrote:
>>>
>>>> Nowadays, when I meet clients, I get them to concentrate on 
>>>> requirements
>>>> only (including cost/weight etc). I forbid them to think in terms of
>>>> implementation until after they've seen my proposal
> ...
>>> Could you, please, give an example?
>>
>> Sure. One that comes up fairly regularly these days is web-enabled 
>> gadgets.
>> Nothing wrong with that, but when the application is mission-critical, is 
>> in
>> charge of some heavy-duty equipment, and has a tiny TCP/IP 
>> implementation,
>> one wants more security than these gadgets can provide. This is not often 
>> an
>> area that clients know enough about...
>>
>> Another one is basing an embedded product on Windows "because it's 
>> easier".
>> Enough said ;).
>
> So you actually make them let you do your job. How do they react? I mean- 
> do
> they try to interfere? Accept it? Try to pick up the subject anyway?

I call it expectation management. At the initial planning meetings, I make 
it clear that we must separate requirements (including cost, of course) from 
implementation. I also invite - separately - their thoughts on 
implementation. I then generate a proposal that enumerates several 
implementations, with their pros and cons (including costs again), and 
invite them to decide. If their original idea is a bad one, it's clear why. 
So, it's ultimately their call. It's my job to make their decision informed.

Steve
http://www.fivetrees.com

"larwe" <zwsdotcom@gmail.com> wrote in message 
news:1177172189.846085.301370@y80g2000hsf.googlegroups.com...
> On Apr 20, 10:33 am, Rob Horton <yahoo@mr_horton.com> wrote:
>> Just to make me feel even more insecure about 
>> flying.http://www.cashloopholes.co.uk/modules.php?name=Forums&file=viewtopic...
>
> I call bullshit; complete, utter, unmitigated, no-excuses, no-holds-
> barred partially-digested plant matter liquid ordure gushing from the
> rectum of a male bovine directly into HTML format.
>
> I ask all the engineers here - what is easier to design? A multihead
> system that drives 400 or 500 screens directly from a single CPU box
> running multiple threads on a [plurality of] CPUs, or 500 single-head
> systems that run a single game OS, like a Nintendo Gameboy, and
> communicate the voice stuff for the phone over a local network?
>
> If you were designing the latter, why would you need to propagate a
> LOCAL game configuration parameter to all the units in the network?
> Why would this crash any of them?
>
> I'm utterly certain this story is a completely bogus fabrication which
> someone is trying desperately to promote into an urban legend.

<devil's advocate>
The bad parameter may have caused a write to an area outside the bounds 
of the array which _could_ have found its way into a more important 
message that was to propegate the network, like a reset command or 
something.
</devil's advocate>
However, it doesn't seem all that likely and the OPs link has now died 
too. Still, full marks for effort though. 

In article <1177315475.23758.0@proxy01.news.clara.net>, Tom Lucas 
<news@REMOVE_tlcs_THIS_dot_TO_fsnet_REPLY_dot_co.uk> writes
>"larwe" <zwsdotcom@gmail.com> wrote in message
>news:1177172189.846085.301370@y80g2000hsf.googlegroups.com...
>> On Apr 20, 10:33 am, Rob Horton <yahoo@mr_horton.com> wrote:
>>> Just to make me feel even more insecure about
>>> 
>>>flying.http://www.cashloopholes.co.uk/modules.php?name=Forums&file=vie
>>>wtopic...
>>
>> I call bullshit; complete, utter, unmitigated, no-excuses, no-holds-
>> barred partially-digested plant matter liquid ordure gushing from the
>> rectum of a male bovine directly into HTML format.
>>
>> I ask all the engineers here - what is easier to design? A multihead
>> system that drives 400 or 500 screens directly from a single CPU box
>> running multiple threads on a [plurality of] CPUs, or 500 single-head
>> systems that run a single game OS, like a Nintendo Gameboy, and
>> communicate the voice stuff for the phone over a local network?
>>
>> If you were designing the latter, why would you need to propagate a
>> LOCAL game configuration parameter to all the units in the network?
>> Why would this crash any of them?
>>
>> I'm utterly certain this story is a completely bogus fabrication which
>> someone is trying desperately to promote into an urban legend.
>
><devil's advocate>
>The bad parameter may have caused a write to an area outside the bounds
>of the array which _could_ have found its way into a more important
>message that was to propegate the network, like a reset command or
>something.
></devil's advocate>
>However, it doesn't seem all that likely and the OPs link has now died
>too. Still, full marks for effort though.

Not likely but it happened several times with the USS Yorktown...... 
Brought to a complete halt and had to be towed back to port several 
times.


-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

On Sun, 22 Apr 2007 22:41:30 +0100, Steve at fivetrees wrote:

> "Marcin Wolcendorf" <wolcendo@friko2.onet.pl> wrote in message 
> news:f0ggrg$a3v$1@nemesis.news.tpi.pl...
...
>> So you actually make them let you do your job. How do they react? I mean- 
>> do
>> they try to interfere? Accept it? Try to pick up the subject anyway?
> 
> I call it expectation management. At the initial planning meetings, I make 
> it clear that we must separate requirements (including cost, of course) from 
> implementation. I also invite - separately - their thoughts on 
> implementation. I then generate a proposal that enumerates several 
> implementations, with their pros and cons (including costs again), and 
> invite them to decide. If their original idea is a bad one, it's clear why. 
> So, it's ultimately their call. It's my job to make their decision
> informed.

Thanks. 

M.