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