On 08/04/2011 11:59 AM, Jim Holsenback wrote:
> On 08/04/2011 09:22 AM, Invisible wrote:
>> The programmer didn't read the documentation for the tools and libraries
>> he's using. (He probably wouldn't understand it anyway!) As such, the
>> software actually /depends on/ all the undocumented, undefined or just
>> plain erroneous behaviour of the compiler, the runtime and the libraries.
>
> Sounds a bit like the early days of squashfs (re: my previous post on
> the topic) ... I never could get the tools to compile correctly for what
> can only be some of the very issue's that you've raised.

clarification ... don't want the squashfs folks thinking some povray 
weenie was slamming the project, so I'll add that my comments relate to 
the many lzma variants out there, all aimed at getting just a little 
more blood out of the turnip (1% or 2% better compression) ... I mean 
maybe a good idea when RAM was more expensive. Now a days that's just an 
exercise in futility ;-)

Post a reply to this message

On 4-8-2011 17:18, Invisible wrote:
> On 04/08/2011 03:48 PM, andrel wrote:
>> That is sort of the software engineer's view. You can describe DNA as if
>> it is a program, but that misses most of the details.
>
> If you read most books about it, they will tell you that "hey, DNA has
> these 4 letters, and they go in groups of 3, and this table here shows
> you for every 3-letter word which animo acid it selects, and that's how
> you make proteins!"
>
> Which is basically true. But this isn't something some engineer
> designed. This is a crazy-ass thing that happened by accident! Suffice
> to say, it's way more complicated than that.

You need for instance the proteins of a living cell to do the 
transcription.

>
> You know the bit I said about compiled code being modified at runtime?
> It turns out that by attaching (or not attaching) various molecules to a
> DNA chain, you can activate or deactivate various genes. So DNA isn't
> just the program. In some sense it's also part of the cell state or
> "memory". Sometimes I wonder whether a "naked" copy of a given animal's
> genome would actually function at all; even at conception, there are
> probably markers turning genes on or off, to set the program in motion
> from the correct start point.

You can not boot a cell from scratch. 
http://www.ted.com/talks/lang/eng/craig_venter_unveils_synthetic_life.html

> Then there are the knots and tangles in DNA or RNA that affect the way
> it is processed. For example, human mRNA with a certain type of knot in
> it causes certain amino acids to have selenium added to them after
> transcription. So the whole "codons code amino acids" is a vast
> simplification.
>
> Let us not even get into the fact that many proteins are modified after
> being constructed, some fold up as they are transcribed (so trying to
> simulate folding of the complete, finished protein is a doomed
> endeavour), one require "chaperone" proteins to guide their folding in
> the correct direction, many proteins are synthesized inactive and have
> to be "activated" before they will do anything. Recent research even
> suggests that "cellular crowding" may be important for some protein
> activities.
>
> http://en.wikipedia.org/wiki/Cellular_crowding
>
> On top of all that, it turns out that RNA itself can be both a data
> carrier like DNA *and* a catalyst like proteins. Wrap your head around
> that one!

The mechanism that reads the code is a set of RNA molecules

>> Sometimes I wish I was 18 again today, so I could absorb enough facts
>> about how cells and organisms work to help advance the field. I am now
>> too old to understand a large enough portion to have any significant
>> contribution :(
>>
>> Yet, I still try to keep up with the field as much as I can, if only to
>> be able to understand the guys and gals further up the corridor.
>
> The more I find out, the more fascinating it all becomes. And the more
> frustrating that you can't see this stuff in action for yourself.
> (Unless your a subject area expert.)

I seem to remember you turned down an opportunity to work in my lab.

>> I do know that if I had to create life I would have done it more logical
>> and maintainable. But, that would probably not have survived for more
>> than a few generations.
>
> Computer programs generally have the property that any tiny alteration
> to them or any tiny fault in the hardware running them causes
> catastrophic failure. Living organisms are remarkably devoid of such a
> problem...
>
>
>
> Did you hear the one about the guy who tried to "evolve" an oscillator
> circuit in his lab? Used some kind of genetic algorithm to take randomly
> generated circuits and gradually modify them and keep the ones that
> acted most like an oscillator.
>
> When the guy analysed the "winning" design, it looked absolutely nothing
> like an oscillator. And yet it worked perfectly. Baffled, the guy took
> it to a friend's lab, whereupon it utterly stopped working. Now both of
> them are *really* puzzled.
>
> Long story short, it turns out it wasn't an oscillator at all. It was a
> radio receiver. It was picking up some kind of radio interference from
> some equipment in the guy's lab, which wasn't present in the other lab.
> So much for adapting to your environment, eh?

I know similar stories, yes.

-- 
Apparently you can afford your own dictator for less than 10 cents per 
citizen per day.

Post a reply to this message

On 8/4/2011 8:32, Invisible wrote:
>> In contrast with distributing it to the customer, we were
>> instead actually editing the production copy while the system was live.
>
> Yes, I was afraid of that.

But it was under version control!  Everyone checked it out of the repository 
onto the same shared network drive that production was running off of.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

On 8/4/2011 8:47, Jim Holsenback wrote:
> lzma variants out there, all aimed at getting just a little more blood

There's a reason people still use the ZIP format and not 101 other formats 
that compress better.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

On 8/4/2011 6:02 AM, Invisible wrote:
> On 04/08/2011 01:53 PM, Le_Forgeron wrote:
>> It's even worse than that: each customer not only get a full different
>> program, but installed it (with variations) on billions of computers
>> (most cells get a full copy, initially).
>>
>> As cells divide, each copy mutates and get truncated or duplicated code.
>> Statically, it's the same program... in theory. In practice, the
>> survival is only based on the ability of the new program to still
>> duplicate the cell.
>
> As best as I can tell, mutations are actually very rare events. There
> are specific mechanisms which exist expressly to detect and correct such
> defects. That includes DNA repair mechanisms, automated destruction of
> misfolded proteins, and extracellular signals used to program mutated
> cells to shut down and die.
>
> Cancer happens when these mechanisms fail to correct a mutation /and/
> that mutation happens to be do to with growth processes. Observe that
> cancer is quite rare. (E.g., it's not like 50% of people get cancer or
> anything like that.)
>
> So it's not like every single cell in your body has a completely
> different copy of your genome. Actually the differences are tiny, if
> existent at all. The major place where these mutations become
> significant is during reproduction, where the entire organism passes
> through a single genome copy. If /that/ gets changed, it's probably
> permanent.
You are assuming that all of the code is run, in all copies. That isn't 
true though. To use your program analogy, every copy may have accounting 
functions, but only 10 of the customers are using it. Or, worse, the 
"code" that gets mangled is in the initialization code, so it effects 
each "new" unit that goes online, but the machine someone accidentally 
enclosed behind a wall, and has thus been running for years as a server, 
isn't effected, since it never has to run the initial code that does the 
first "setup", it simply reads that data in again, when/if it has to 
restart. Like a liver cell that produces liver cells fine, but has major 
errors in code related to forming something else specific, like lungs, 
or something general, like initial signaling that determines symmetry in 
the organism. Neither of which is needed, in a liver cell.

Post a reply to this message

On 04/08/2011 05:14 PM, Darren New wrote:

> There's a reason people still use the ZIP format and not 101 other
> formats that compress better.

I believe it's called "compatibility".

/Everything/ understands the Zip format, even if it /is/ sucky (for more 
reasons than just the compression ratios).

Post a reply to this message

Le 2011/08/09 05:03, Invisible a écrit :
> On 04/08/2011 05:14 PM, Darren New wrote:
>
>> There's a reason people still use the ZIP format and not 101 other
>> formats that compress better.
>
> I believe it's called "compatibility".
>
> /Everything/ understands the Zip format, even if it /is/ sucky (for more
> reasons than just the compression ratios).

Also, there are just so many various archives and packages that are 
realy ZIPs with a special extention...
I just can't count them all, as I regularly stumble across new "formats" 
that are just renamed ZIPs.

Post a reply to this message

On 8/4/2011 7:22 AM, Invisible wrote:
> Imagine the unimaginable: Try to picture the worst possible software
> codebase. The kind of thing that only exists in your most darkest
> nightmares, the ones where you wake up screaming. The sort of code that
> sends people stark raving mad.
>

Welcome to my world ;)

>
> Now imagine that instead of just /one/ broken upper-case function, there
> are /sixteen copies/ of this thing, all doing upper-case conversion on a
> different subset of the Latin and perhaps Greek alphabets. Twenty five
> different functions which all incorrectly percent-encode URLs in a
> different incorrect manner. Four copies of that weird function that you
> don't know what it does yet, all of them identical.

Seen that, too.

> Best of all, during the development process, the code has changes so
> many times that large parts of the codebase are actually DEAD CODE! Huge
> chunks of it are EVER ACTUALLY RUN. They used to be, but no longer are.
> Good luck figuring out which bits those are.

Been there...

>
> The code uses pointer arithmetic to access stuff, and as such depends on
> the exact ordering of stack frames, heap placement, malloc behaviour and
> God only knows what else. Compiled code is modified at runtime. Some of
> the machine opcodes are also data constants; if the compiler ever
> decided to move the code around, it would stop working.
>

I had a friend that did a lot of that.

>
> In case you haven't come across this scenario, let me spell out the dire
> consequences of this development pattern: EVERY SINGLE CUSTOMER has a
> completely unique, one-of-a-kind variant of the software. Each one has
> its own completely unique set of bugs. Each one has different functions
> with different names in different files to do the same job in slightly
> different ways.
>

Yep. been there, too. :)

> Are you trembling in catatonic hysteria yet? Then let me tell you the
> worst part: The software is /really really popular/. Sure, it doesn't
> actually /work/ very well, but it's a completely mission-critical part
> of every customer's infrastructure, and /must/ be supported. And the
> range of functionality it provides and the complexity of the workarounds
> the customers have invented to deal with it make replacing or rewriting
> it unthinkable.

Been there, too!

>
>
> OK, so that's pretty much the work Daily WTF nightmare imaginable. Of
> course, nobody /actually/ writes software like that, right?
>
> Right??
>

I think that's rather common in business. Often the only real 
requirement is "Just get it done!"

> In a sense, what scientists are trying to do is even /harder/ than
> figuring out what a really buggy program does. They're trying to figure
> out which customer got which copy of what software from whom at what
> point in time, and what modifications were done after that. In other
> words, track Mr Incompetent's movements and figure out the linage of all
> the different copies of the software. Jesus that's hard!

Well, someone  needs to just code up a decomipler, then, don't they?

-- 
~Mike

Post a reply to this message

On 12/08/2011 01:45 PM, Mike Raiford wrote:

> Well, someone needs to just code up a decomipler, then, don't they?

Yes, because once the machine code has been decompiled, solving the 
halting problem becomes much easier... ;-)

Post a reply to this message

On 8/9/2011 2:03, Invisible wrote:
> On 04/08/2011 05:14 PM, Darren New wrote:
>
>> There's a reason people still use the ZIP format and not 101 other
>> formats that compress better.
>
> I believe it's called "compatibility".

That's exactly the point. The original author of the zip format said "you 
may add any extensions and implement it all you want, as long as every zip 
program can unzip whatever files you create."  I.e., he used a gnu-like 
copyright license to insist that all zip programs interoperate.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message