On 10/09/2012 09:51 AM, scott wrote:
>> I take it you don't subscript to "test-driven software development" as a
>> methodology either? ;-)
>
> Sure, do tests, but properly design the stuff first (including the
> tests). You shouldn't use testing as a substitute for good design.

Amen.

> You think the latest machines are more efficient and better at cleaning
> by magic?

No. I think they aren't any more efficient at all.

> You could use the same argument for car engines, just take the previous
> one, add a couple of trivial differences and test it. But again nobody
> would buy your new car because all your competitors would have spent the
> last 5 years designing a far more efficient engine (even if it looks the
> same from the outside).

Surely trying to tune an engine to get a few percent more efficiency out 
of it is vastly easier than INVENTING the internal combustion engine in 
the first place...

Post a reply to this message

>> You think the latest machines are more efficient and better at cleaning
>> by magic?
>
> No. I think they aren't any more efficient at all.

Why do you think that?

A quick google found this:

http://www.fsec.ucf.edu/en/publications/pdf/FSEC-CR-1772-08.pdf

"For instance, in 1993, the energy per cycle for
dishwashers averaged about 2.6 kWh/cycle along with a hot water use of 
about 10 gallons (38
liters). By 2004, with new energy standards (DOE, 2003) the numbers had 
fallen to about 1.8
kWh/cycle with typical water use of about 6 gallons (23 liters)."

How do you think they managed to do that and still clean the dishes? 
They certainly didn't just adjust the amount of water used.

> Surely trying to tune an engine to get a few percent more efficiency out
> of it is vastly easier than INVENTING the internal combustion engine in
> the first place...

Actually no. You try taking a device that has been under mass production 
for decades and the subject of continuous research. If you could get a 
few % more efficiency then you'd be able to ask for a very high salary 
from a lot of companies instantly :-)

Post a reply to this message

> On 07/09/2012 03:46 PM, scott wrote:
>> 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.
>
> I can imagine a lot of design work goes into a brand new product. But if
> you're making a dishwasher, you're not making a brand new product.
> You're making a product which is nearly identical to several hundred
> thousand existing products, but with one or two trivial differences.
> Most of the research has already been done. You just need to
> double-check that your new design doesn't contain any unexpected flaws.

Even changing a small mounting bracket requires lots of simulation 
(Google finite elements analysis* ) to make sure the bracket will not 
break after 3 months of use.

Even if a good deal of the research has been done, a change in 
regulations, or market conditions, can force a dish-washing machine 
maker to have to review the entire design.

Besides, there's lots of research that has to be redone because it was 
initially done by another company and you can't be sued for 
reverse-engineering their product, so if both use 1/8th inch mounting 
brackets, you need to be able to show a judge that you did do all the 
calculations necessary to determine that it was the proper thickness, 
ans that you didn't simply copy the other company's bracket.

* lots of math and programming in that field, for someone with an 
interest in those.  You may not know the first thing about strength of 
materials, or vibrations, but the engineers and physicists who do can't 
program their way out of a paper bag, so they need programmers and math 
is the common languages that these two groups speak.

-- 
/*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

>>>> Right. And encryption/decryption algoritms sprout from trees?
>>>
>>> From what I've seen, there are, like, three academics globally who
>>> write the vast majority of this stuff. And there are already /way/ more
>>> ciphers in existence than anybody actually wants or needs.
>>
>> Ok. And no one ever needs to implement those algorithms?
>
> Well, that's true. I mean, it's not as if there are already thousands of
> proprietary and open-source libraries that implement both basic
> cryptographic primitives and entire protocols... Oh, wait.

Suuuure. The government, military and finance industries really love 
using open-source libraries to encrypt their confidential information.

And private industries really, absolutely, unequivocally love having to 
distribute their software for free because theses same open source 
libraries have licencing terms that prevent them from being used in 
commercial software!

-- 
/*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 10/09/2012 02:51 PM, Francois Labreque wrote:

>>>>> Right. And encryption/decryption algoritms sprout from trees?
>>>>
>>>> From what I've seen, there are, like, three academics globally who
>>>> write the vast majority of this stuff. And there are already /way/ more
>>>> ciphers in existence than anybody actually wants or needs.
>>>
>>> Ok. And no one ever needs to implement those algorithms?
>>
>> Well, that's true. I mean, it's not as if there are already thousands of
>> proprietary and open-source libraries that implement both basic
>> cryptographic primitives and entire protocols... Oh, wait.
>
> Suuuure. The government, military and finance industries really love
> using open-source libraries to encrypt their confidential information.
>
> And private industries really, absolutely, unequivocally love having to
> distribute their software for free because theses same open source
> libraries have licencing terms that prevent them from being used in
> commercial software!

Perhaps you missed the part where I said there are proprietary libraries 
for this as well?

Post a reply to this message

> On 10/09/2012 02:51 PM, Francois Labreque wrote:

>>>>>> Right. And encryption/decryption algoritms sprout from trees?
>>>>>
>>>>> From what I've seen, there are, like, three academics globally who
>>>>> write the vast majority of this stuff. And there are already /way/
>>>>> more
>>>>> ciphers in existence than anybody actually wants or needs.
>>>>
>>>> Ok. And no one ever needs to implement those algorithms?
>>>
>>> Well, that's true. I mean, it's not as if there are already thousands of
>>> proprietary and open-source libraries that implement both basic
>>> cryptographic primitives and entire protocols... Oh, wait.
>>
>> Suuuure. The government, military and finance industries really love
>> using open-source libraries to encrypt their confidential information.
>>
>> And private industries really, absolutely, unequivocally love having to
>> distribute their software for free because theses same open source
>> libraries have licencing terms that prevent them from being used in
>> commercial software!
>
> Perhaps you missed the part where I said there are proprietary libraries
> for this as well?

No I didn't.  I was addressing the open-source part of your comment.

As for proprietary libraries, you do realise that they need maintaining, 
being ported to new platforms, etc...


-- 
/*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

> As for proprietary libraries, you do realise that they need maintaining,
> being ported to new platforms, etc...

Large, complex applications need maintaining. A small single-function 
library that already works correctly? Why would it need any maintenance? 
As for porting, most of this stuff seems to be written in ANSI C, and 
it's pure algorithmic code. You would /think/ it's fairly portable...

Now, code to drive custom hardware implementations? That might be more 
tricky.

Post a reply to this message

>> As for proprietary libraries, you do realise that they need maintaining,
>> being ported to new platforms, etc...
>
> Large, complex applications need maintaining. A small single-function
> library that already works correctly? Why would it need any maintenance?
> As for porting, most of this stuff seems to be written in ANSI C, and
> it's pure algorithmic code. You would /think/ it's fairly portable...

Still, there's one guy or gal whose job description is to be in charge 
of it, just in case.  Now, said guy or gal, may be responsible for 
hundreds of these single-function libraries, but there still needs to be 
someone to wake up at 2am when a someone figures out how to read the 
encryption key in memory, or that you thought would be secure since you 
ROT-13ed it.  Twice.

>
> Now, code to drive custom hardware implementations? That might be more
> tricky.

There you go.

-- 
/*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

> Well, that's true. I mean, it's not as if there are already thousands of
> proprietary and open-source libraries that implement both basic
> cryptographic primitives and entire protocols... Oh, wait.

I wonder how many people were involved with defining the standard for eg 
the BluRay format? Seems like quite a lot of work heavily based around 
preventing people breaking the encryption, and recovering from the 
situation if someone does break it. I highly doubt they will just 
copy&paste that solution to the next generation format, so surely there 
are people actively working on this.

Then not to mention all the people working on writing players for 
BluRay, both for standalone hardware and software to run on computers 
and games consoles. I imagine you wouldn't be able to do that without a 
good understanding of how the algorithms work.

Or maybe you could work for Sony writing rootkits for their audio CDs 
:-) Or Sky to encrypt the TV signals from satellites (don't think that 
was written once and never changes), or banks or credit card companies, 
or ...

It seems like a pretty endless list to me of companies that would 
require programmers with a very good understanding of how to select and 
implement cryptographic techniques. Hey, even we have two software guys 
here implementing these things into RFID tags, and we make printers!

Post a reply to this message

On 11/09/2012 08:38 AM, scott wrote:
>> Well, that's true. I mean, it's not as if there are already thousands of
>> proprietary and open-source libraries that implement both basic
>> cryptographic primitives and entire protocols... Oh, wait.
>
> I wonder how many people were involved with defining the standard for eg
> the BluRay format? Seems like quite a lot of work heavily based around
> preventing people breaking the encryption, and recovering from the
> situation if someone does break it. I highly doubt they will just
> copy&paste that solution to the next generation format, so surely there
> are people actively working on this.

I'm sure the actual cryptographic primitives are well-known 
off-the-shelf models. The protocol by which they are combined into a 
complete system? Yeah, that's probably band new.

> Or maybe you could work for Sony writing rootkits for their audio CDs
> :-)

You realise that Sony BMG didn't actually /write/ that, right? They just 
/bought/ it from some crappy 3rd party company [who presumably has 
really good sales staff]. Probably sold it to some marketiod suit who 
doesn't understand the first thing about computers, claiming it was a 
magic bullet to completely solve all their problems for just $$$/month.

> It seems like a pretty endless list to me of companies that would
> require programmers with a very good understanding of how to select and
> implement cryptographic techniques. Hey, even we have two software guys
> here implementing these things into RFID tags, and we make printers!

Well, maybe. Also seems like they wouldn't need very many of these guys, 
and not very often.

Post a reply to this message