 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Sure, there are autonomous machines all around us. I don't think that
> designing or programming them requires a vast amount of technical
> knowledge - just extensive testing and experimentation.
That's a very bad way to design products, it's expensive and time
consuming, and liable to create a product with lots of bugs you don't
find until they're out in the field. Far better to get people with vast
technical knowledge to properly design the product in the first place,
the actual product testing should just be a formality, not a tool to
find the best design.
But don't worry, you're not alone in underestimating the amount of
design work that goes into everyday products. Once you've been to a few
conferences on design and simulation software you realise that nothing
is just designed by trial and error. For example even the part of your
dishwasher that contains the salt to soften the water has been carefully
studied, designed and simulated to minimise salt use, pressure drop and
material costs. Certainly some person didn't just draw it out and say
"that'll work, let's test it" and then maybe make a couple of tweaks.
You wouldn't survive 5 minutes if your company worked like that.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 07 Sep 2012 11:24:02 +0100, Orchid Win7 v1 wrote:
>>>> crypto/security
>>>
>>> Seriously, almost *nobody* actually does that.
>>
>> Bullshit. I'm presently working with two teams that are knee-deep in
>> crypto and security work. Identity management, authentication, etc -
>> all use that extensively.
>
> You're telling me there are more than three people on Earth who actually
> design ciphers?
crypto/security isn't just about designing ciphers.
And I'm telling you that there are more than 3 people who work with crypto
and security.
>> Yes. See "Business Intelligence". Data-driven decision making is
>> something that a lot of businesses do, and they tend to be successful.
>
> I would have thought that querying the data to get the numbers you want
> is the /easy/ part. The hard part, surely, is figuring out what
> questions to ask in the first place. And that is out of my league.
Sometimes querying the data or figuring out what data you need is
actually fairly tricky, as is using the data that's available to try to
answer questions that are better answered with data that you don't have
and can't get.
>>>> robotics
>>>
>>> Is there any commercial application for that?
>>
>> Manufacturing uses robotics in a huge way.
>
> OK. But those robots already exist. Why would you ever need to design
> more?
Because not all the robots that are in use are optimum for the jobs they
do, additional manufacturing that currently is manual labour can be
automated - there are lots of applications still being developed.
Not all the robots that could ever be developed or could be useful have
been made yet. You /do/ realise this, don't you?
>>>> marketing
>>>
>>> There's technical expertise in that?
>>
>> Yes. Writing marketing copy that actually convinces technical people
>> requires technical expertise.
>
> You must be looking at very different "marketing copy" than the stuff
> I've seen.
Quite possibly. I've also been involved in creating some.
> Typically you get a picture of something expensive - a server, a disk
> enclosure, whatever - and a paragraph of fancy middle management
> power-word bullocks about how the company offer you "synergistic
> solutions" to "streamline" your operations and "leverage" legacy assets
> with their "revolutionary innovations" - hell no, I can't even type this
> stuff! >_<
That's "non-technical" marketing, designed to convince management types,
not marketing designed to convince technical types.
> In particular, such material is utterly devoid of even the slightest
> hint of technical detail. Lots of hand-waving about "total cost of
> ownership" and "return on investment" and so forth, but no technical
> specifications, and no prices.
You've never seen a technical specifications sheet - ever?
>>>> disaster response
>>>
>>> What kind of disaster response requires technical skill?
>>
>> Your data center has burned to the ground. Recover it.
>>
>> Yeah, that takes a lot of technical skill - and ability to use those
>> skills quickly to get the services running as soon as possible.
>
> Or rather, it requires technical skill to design the data center
> correctly in the first place. By the time a disaster actually occurs, it
> should be easy enough that a trained monkey could do the actual recovery
> part...
That's not actually how it works. I know from having worked on DR plans
for large and small companies.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 07 Sep 2012 11:36:35 +0100, Orchid Win7 v1 wrote:
> Again, "communications" could mean just about anything.
>
> If you mean the 3 people on Earth who design the protocol stacks...
> well,
> those have already been designed. And we already have the 3 people who
> design them.
:headdesk: :headdesk: :headdesk:
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2012-09-07 11:48, Jim Henderson a écrit :
> On Fri, 07 Sep 2012 11:24:02 +0100, Orchid Win7 v1 wrote:
>
>>>>> crypto/security
>>>>
>>>> Seriously, almost *nobody* actually does that.
>>>
>>> Bullshit. I'm presently working with two teams that are knee-deep in
>>> crypto and security work. Identity management, authentication, etc -
>>> all use that extensively.
>>
>> You're telling me there are more than three people on Earth who actually
>> design ciphers?
>
> crypto/security isn't just about designing ciphers.
>
> And I'm telling you that there are more than 3 people who work with crypto
> and security.
>
Who else besides Ron Rivest, Adi Shamir and Leonard Adleman?
;)
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2012-09-07 11:50, Jim Henderson a écrit :
> On Fri, 07 Sep 2012 11:36:35 +0100, Orchid Win7 v1 wrote:
>
>> Again, "communications" could mean just about anything.
>>
>> If you mean the 3 people on Earth who design the protocol stacks...
>> well,
>> those have already been designed. And we already have the 3 people who
>> design them.
>
> :headdesk: :headdesk: :headdesk:
>
> Jim
>
Indeed. Johnathan Postel's been dead a while. This means there's an
opening for Andy.
;)
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 07/09/2012 12:51 PM, Orchid Win7 v1 wrote:
> Those seem to me like the sort of things that get worked out, once and
> for all, and then maybe changed perhaps twice per decade. Not the sort
> of thing you hire a full time employee for.
The company I'm working for ATM makes about 50 F1 racing engines a year
all of them different. The BOM for each engine may change a dozen times
during the production process.
So, there are more things in heaven and earth than in your philosophy,
Andrew. ;-)
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 07 Sep 2012 13:41:17 -0400, Francois Labreque wrote:
> Le 2012-09-07 11:50, Jim Henderson a écrit :
>> On Fri, 07 Sep 2012 11:36:35 +0100, Orchid Win7 v1 wrote:
>>
>>> Again, "communications" could mean just about anything.
>>>
>>> If you mean the 3 people on Earth who design the protocol stacks...
>>> well,
>>> those have already been designed. And we already have the 3 people who
>>> design them.
>>
>> :headdesk: :headdesk: :headdesk:
>>
>> Jim
>>
>>
> Indeed. Johnathan Postel's been dead a while. This means there's an
> opening for Andy.
>
> ;)
LOL
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 07 Sep 2012 13:40:13 -0400, Francois Labreque wrote:
> Le 2012-09-07 11:48, Jim Henderson a écrit :
>> On Fri, 07 Sep 2012 11:24:02 +0100, Orchid Win7 v1 wrote:
>>
>>>>>> crypto/security
>>>>>
>>>>> Seriously, almost *nobody* actually does that.
>>>>
>>>> Bullshit. I'm presently working with two teams that are knee-deep in
>>>> crypto and security work. Identity management, authentication, etc -
>>>> all use that extensively.
>>>
>>> You're telling me there are more than three people on Earth who
>>> actually design ciphers?
>>
>> crypto/security isn't just about designing ciphers.
>>
>> And I'm telling you that there are more than 3 people who work with
>> crypto and security.
>>
>>
> Who else besides Ron Rivest, Adi Shamir and Leonard Adleman?
>
> ;)
Well, you and I both know that there's more than just RSA when it comes
to encryption.
And that crypto algorithm research also includes testing - practically
and mathematically - the strength of the existing algorithms and
techniques for breaking the algorithms. This would include research into
prime number determination as well as looking for other weaknesses in the
algorithms.
And the design of better algorithms, hardware acceleration, and so on.
Then there's the application of crypto to applications, data storage, and
so on.
But of course, you and I don't look at it as "simple".
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Em 07/09/2012 08:24, scott escreveu:
>>> Manufacturing uses robotics in a huge way.
>>
>> OK. But those robots already exist. Why would you ever need to design
>> more?
>
> Competition. If you don't design new robots that are faster, more
> accurate, more versatile and cheaper than your previous generation, your
> customers will buy their robots from someone who has designed new ones.
at least until robots do the design of faster and better robots. Then
no one will do any more shopping.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis <nam### [at] gmail com> wrote:
> Em 07/09/2012 08:24, scott escreveu:
> >>> Manufacturing uses robotics in a huge way.
> >>
> >> OK. But those robots already exist. Why would you ever need to design
> >> more?
> >
> > Competition. If you don't design new robots that are faster, more
> > accurate, more versatile and cheaper than your previous generation, your
> > customers will buy their robots from someone who has designed new ones.
>
> at least until robots do the design of faster and better robots. Then
> no one will do any more shopping.
So the Robot Apocalypse ends suddenly when they all decide it would be more fun
to just go shopping?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
