Software vs. Hardware. The Harsh Truth

naebad wrote:
> Technology _is_ knowledge. - only half true. Saying is much easier than
> the doing! (as a Taiwanese engineer once told me).There are lots of
> academics out there than know teh theory backwards but could not build
> anything.Knowing the theory of how a rocket balances is relatively easy
> - getting it to work is quite another matter!

Why can technicians implement things those academics can't? Knowledge.

I know where to mine wolframite and how to smelt it, and 16th-century 
miners knew how to get it (I don't). Together, we could have gotten 
tungsten (and thorium likewise). Contemporary glassblowers were easily 
up to the task of assembling and evacuating vacuum tubes, and even 
ancient Babylonians made batteries. I know how to draw and insulate wire 
with the tools they had. Capacitors and inductors are simple, resistors 
only a little harder.

Actually, that's frightening. What do we already have the tools to do 
that we don't know yet?

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

naebad wrote:
> Technology _is_ knowledge. - only half true. Saying is much easier than
> the doing! (as a Taiwanese engineer once told me).There are lots of
> academics out there than know teh theory backwards but could not build
> anything.Knowing the theory of how a rocket balances is relatively easy
> - getting it to work is quite another matter!

Maybe, but getting a rocket to work without knowing the
theory behind is stupid and crazy.

It could be that who knows (only) the theory has an easy
job, but who doesn't know the theory should not have a job.

bye,

-- 

piergiorgio

On Mon, 24 Oct 2005 15:45:44 -0400, Jerry Avins wrote:
> Actually, that's frightening. What do we already have the tools to do 
> that we don't know yet?

Don't worry.  The singularity is coming from one direction, but we can
hear the Butlerian Jihad'ists rattling their sabres in at least two other
directions. Think I'll get ready to take up painting or long-distance
sailing...

-- 
Andrew

"Piergiorgio Sartor" <piergiorgio.sartor@nexgo.REMOVETHIS.de> wrote in
message news:6sqv23-p0i.ln1@lazy.lzy...
> naebad wrote:
> > Technology _is_ knowledge. - only half true. Saying is much easier than
> > the doing! (as a Taiwanese engineer once told me).There are lots of
> > academics out there than know teh theory backwards but could not build
> > anything.Knowing the theory of how a rocket balances is relatively easy
> > - getting it to work is quite another matter!
>
> Maybe, but getting a rocket to work without knowing the
> theory behind is stupid and crazy.
>
> It could be that who knows (only) the theory has an easy
> job, but who doesn't know the theory should not have a job.
>
> bye,
>
> --
>
> piergiorgio

I think there is the theory and then there is the real theory which isn't
published! This is the stuff that companies keep out of books. I still don't
know how a frequency hopping radio gets phase lock without a pilot carrier -
but they exist and nobody will tell me.Let's face it - most of the good
stuff is not published.

McC

Look at any book on control systems and you will see the trouble. Lots
of theory that is useless or irrelevant whilst the good stuff is either
missing or its importance under-emphasised. Only in one text book have
I ever seen a discussion on what limits bandwidth in most
electro-mechantical control-systems  ie the structural
resonance(s).Most real engineers know this but the books leave it
out.Why? Because academics copy from one book into another. So there is
knowledge missing that is crucial.So i wonder, what defines the
limiting factor on bandwidth for a rocket control-system?


Naebad

naebad wrote:

> Technology _is_ knowledge. - only half true. Saying is much easier than
> the doing! (as a Taiwanese engineer once told me).There are lots of
> academics out there than know teh theory backwards but could not build
> anything.Knowing the theory of how a rocket balances is relatively easy
> - getting it to work is quite another matter!
> 
> Naebad
> 
Well, that's 'cause they don't know the theory _frontwards_!

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

naebad wrote:

> Look at any book on control systems and you will see the trouble. Lots
> of theory that is useless or irrelevant whilst the good stuff is either
> missing or its importance under-emphasised. Only in one text book have
> I ever seen a discussion on what limits bandwidth in most
> electro-mechantical control-systems  ie the structural
> resonance(s).Most real engineers know this but the books leave it
> out.Why? Because academics copy from one book into another. So there is
> knowledge missing that is crucial.So i wonder, what defines the
> limiting factor on bandwidth for a rocket control-system?
> 
Thats because they're theory books, not books on practice.  You could 
condemn the universities for not teaching much practical stuff, but most 
of the "practical" stuff that I would have been taught is now obsolete, 
and I'm not even close to retirement age.  What I learned that was 
useful was the basic stuff that'll never change even when we're not 
using electrons any more, and how to leverage that basic knowledge into 
something that's useful _now_.

Many high-performance electro-mechanical systems have bandwidths limited 
by resonances, yes, but I've probably worked on as many as have 
performance limitations imposed by geartrain characteristics or the 
available actuator power -- and in both cases you can't even speak 
sensibly of the link between "bandwidth" and "performance" because they 
were operating in nonlinear regions.

I suspect that much of the limitations on a rocket control system have 
more to do with actuator saturation or with the need to avoid breaking 
the rocket than with bandwidth -- but I've never tried controlling one, 
so I couldn't say.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Tim Wescott wrote:
> Thats because they're theory books, not books on practice.  You could
> condemn the universities for not teaching much practical stuff, but most
> of the "practical" stuff that I would have been taught is now obsolete,
> and I'm not even close to retirement age.

> What I learned that was
> useful was the basic stuff that'll never change even when we're not
> using electrons any more, and how to leverage that basic knowledge into
> something that's useful _now_.

Photonics will replace electronics eventually. Hope they use 400 nm
lasers.

kyle wrote:

> HW:  Pentium floating point bug.
> Resolution:  Buy a new chip

Patches were developed quickly.  Don't think people bought new chips
(except as an excuse to upgrade) intel gave them out.

> SW:  Security hole in IE
> Resolution:  Patch

Better resolution: buy a new chip (with Harvard architecture)

cs_posting@hotmail.com wrote:
> kyle wrote:
> 
> 
>>HW:  Pentium floating point bug.
>>Resolution:  Buy a new chip
> 
> 
> Patches were developed quickly.  Don't think people bought new chips
> (except as an excuse to upgrade) intel gave them out.
> 
> 
>>SW:  Security hole in IE
>>Resolution:  Patch
> 
> 
> Better resolution: buy a new chip (with Harvard architecture)

Another solution: use a two-stack language, one for return addresses, 
one for passing data. (Forth is inherently that way and C can run that 
way too.) Then you can never execute rogue code via stack-frame overrun.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������