Tee hee. A while ago, one of the hacker sites had a competition to see who could hide a "backdoor" -- the idea was to take an image in a script compatible form (all the numbers were in text, rather than in binaries), black out a certain region (think redaction), and still have some way to have the redacted area be recoverable when the right inputs were given.

The catch? The code would be given a peer review, so you had to come up with something that would pass most attempts at oversight.

A lot of people tried to hide stuff in "error detection" routines.

The winning code had no bugs of any kind. It did perfect redaction of the specified area. No flaws, no errors, nothing to be spotted in code review.

Except for one oddball usage of fetching and writing individual characters -- getc() and putc(). The author explained that as an attempt to make sure that no matter what was in the input data, no matter how messed up the graphics were in an attempt to break the code, it would not have any overruns, no undefined behavior, etc.

Result? The "black" would be written out as "0", "00", or "000", depending on the light level of the source. For all three color channels.

Absolutely unnoticeable when viewed on a viewer. There was no hidden alpha channel, no slight alternation between black-0 and black-1, etc.

Yet you could still recover readable text, almost perfect pictures, etc.

Security hole back door? Very doable.

So, just as an example, ...

If I wanted to hide something in the linux code for random number generation, and it was obfuscated, not well discussed, not well documented, deliberately made hard to understand, etc., how long would it take before someone actually managed to decipher the whole thing, and realize that the whole kernel random number generator was bleep and needed to be replaced?

It has already happened. The linux kernel RNG was crud, and I really hope it has been replaced by now.

Hiding something in open source? Not impossible. The real question is: What is the backlash when it finally comes out in the public?

Well, Scooby and Shaggy won't eat haggis, so ...

What *was* wrong with backup exec? Why did I stop using it?

Well, first, I'm not sure that I have stopped using it. NtBackup, as seen in XP, looks frightfully like it. Fortunately (unfortunately?), it has not managed to make a good backup in years.

I currently use rsync with a bunch of args (including fake-super on the destination, and one to fake attributes in extended args) to an HFS, and then Time Machine that HFS.

Backup Exec had a bunch of problems. The two that I remember where:
1. Demonstrated failure to restore short names properly. This wasn't trivial or theoretical -- this *BIT* me, hard.
2. Absolutely no email support worth anything. Complaints may as well have gone to /dev/null. Not even a form letter acknowledging the submission, followed by a second form letter saying "The devs have looked into your issue and will address it in a future release."
3. The backup exec that I was using came with my cartridge tape drive system. It was a "free" edition, meaning that it was included in the price -- oh yea, back then it was seagate backup exec, and it was a seagate tape drive. One of those semi-random access (some seek time, but with 40 or 50 tracks, much less than the full backup size) streaming tapes.

4. No support for saving data except into single files, or multiple tapes. Once the tape drive was retired, could I use this to save to multiple DVD's? Nope. Incrementals were fine -- they'd fit on a single DVD. But the initial backup? Bleep.

Rsync and Time Machine probably lose the short file names.
The truth is, I haven't seen a single backup program that claims to keep those.
Heck, I haven't seen a backup program that claims to track hard links (need to check Time Machine ... how does it's heavy use of hard links affect user hard links?)

Time Machine, Apple OS.

So lets actually look at the question:

1. Developer has grown to love PHP.
2. Developer is adding active content for the first time.
3. Developer wants to get "the one right truth" before heavy development.

Conclusion: Developer has forgotten the very basic rule of coding: You will throw it away and recode it.

Repeat: You will throw it away and recode it.

If you ever forget that, you do not know how to code.

How do you write the best, high quality code? Answer: You understand the problem. How do you understand a problem? Answer: You write something that looked good initially, failed, and then understood why it failed.

My recommendation: Write a proof of concept -- a small scale demo, something a little more than a mock-up.

Learn from that, and then write the next version. This second version is first written in "english", or "file cards (*)", or "text files". Then it is re-written in some programming language.

This version is the first real version (you just thew away version zero). This is the version that you expect to work. And, in the process, you'll understand exactly what you are trying to do.

The process is no different for a desktop program, an HTML-output report generator, or an HTML/Javascript (with or without async) /CSS/Dom manipulation input and output program.

The goals of programming, of a functioning program, are something along these lines:

1. Work correctly.
2. Work as expected.
3. Work securely.
4. Work fast enough.

(you may switch the order of the last three.)

Ideally, you want:

5. Work quickly.
6. Work with few resources consumed.

Programmer time is a resource. Maintenance time is a resource. Disk space and CPU time are also resources.

Security may be a pain, or impossible, in languages like PHP. Even if your code is 100% perfect, if you are using frameworks, you may have pain. Remember: We just had recent disclosure that most web development systems used some type of hash on the input data as part of their function, said input data was 100% under attacker control, and attackers could do major hash table collision attacks with very little resources consumed, and no way for the developer to counter it.

You love PHP? Fine. Use that for your first trial. Don't fall in love with your first trial.

*: Programming by file cards: This is a way to identify your classes and objects / primary data structures and operations. Get a bunch of file cards -- either 3x5 or 4x6, primarily based on how small you can still write legibly. On each card, you identify one data structure or class, and the primary operations you think you want to perform. If those operations require the use of other data structures/classes, you identify what you want to do with/to those structures.

If a class's requirements -- including what other people want to do to it -- gets too big for your file card, break it up into parts.

Different take: Since the translations between reality and math destroy the assumptions, the conclusions that come out are completely unjustified.

For example, Micro economics has the assumption of perfect information. The translation into math basically treats information as another good, and you pay more for better information.

Never mind that this introduces a feedback term, which eliminates the solvability, and introduces chaotic behavior. It also assumes that the information is available to purchase at all; given that the current economic collapse is based on lack of information and outright lying/hiding/disguising information, that shows another problem.

Oh, and your Turing issues have another flaw. You assume that no computer can ever be made that is not within the Turing domain. That's a big assumption. Turing machines were all about showing what is common to all (then) current systems; it isn't clear that nothing can ever be made outside of that limit.

I beg to differ. The cat in my lap tells me that I'm supposed to pet it and type one handed. It is defining its own purpose

Job security: Look at some of the stuff on DailyWTF.com.

Imagine code that is doing license checks that just assumes that if it's 2012, then the license is invalid.

Imagine code that has a bunch of delay loops in it -- for (long x=0; x1000000; x++) or the equivalent -- and if the coders can't do anything else that week, they speed up the program.

Proper comments? Next thing you'll be saying, it's not enough to reverse engineer what NTFS is doing, Microsoft should explain WHY A instead of B so that people can actually re-implement it properly instead of having to guess and getting complaints from chkdsk or a slower drive.

Alright, lets see what OsX gave with upgrades.

10.5: Major new features in the Objective C language; major new features in the kernel and application kit. Best of breed backup system as an automatic default, as easy to use as "hook a drive up, and click the "yes" button that pops up".

Costs? Yea, parts of the 1.4 iLife broke, and didn't tell you. Photoshop elements 2 broke, (and it wasn't clear at first that it was the OS change that did it). EOF started the descent into oblivion.

10.6? Kept 10.5 support in Rosetta. Bunch of new things that are actually good.

10.7? Significant security pluses (encrypted disks, encrypted Time Machine). Major improvements for autosaving applications, full screen apps, etc. Major minuses in lots and lots of other areas. Major changes to user interface. Major problems with batteries on laptop upgrades. Elimination of Rosetta. And most people advising that if you don't need the few new good features of 10.7 to go back to 10.6. Oddly, no one is saying go back to 10.5.

10.7 will be the mac vista. 10.8 will be better. But with a new UI and user experience, it will be the windows 7 of macintosh.

So, gee, 10.6 is the XP, 10.5 was the earlier working 2K, and 10.4 was ... halfway between 98 and NT. 10.3 was 98, 10.2 was 95, and 10.1 was 3.11.

10.0 was just like 3 -- a shell on top of another system. :-)