It wasn't until i read more that i realised this was about DNA alone. I have no doubt that othes did the same but didn't bother going deeper into it.

Including the people taking the survey, I suspect.

They're well defined now. AFAIK, they were nonstandard when initially proposed. Every time someone wants to deviate from accepted standards, there should be a darn good reason why, and I'm just not seeing any reasonable justification for creating a whole separate transport-layer protocol for something that basically behaves like a normal, connected stream.

And it isn't just explicit blocking that's a problem. Firewalls and NAT often make life miserable for users even when those firewalls aren't trying to block the VPNs. That's why as far as I'm concerned, if you're passing traffic, you should use TCP if you need the data to be robust and reliable, UDP if delayed delivery would make the data worthless, and ICMP for the usual network management purposes. IMO, everything else is anathema. :-)

My point was that there was no valid reason for each of these VPNs to each use its own transport-layer protocol. A normal, connected TCP socket would have done the job just as easily. Every time someone strays from the expectation that all packets are either TCP, UDP, or ICMP, it means every hardware-based firewall maker (and every software-based firewall IT person) has to do extra work to deal with it, and hardware that worked before suddenly doesn't work or (if you're lucky) requires firmware updates. The fact that using a different protocol makes it easier to block is just another in a long list of reasons why the proliferation of transport-layer protocols is a bad idea.

Okay, fair enough. I usually lump firewalls and routers in the same bucket, because outside of backbone hardware, most routers also act as firewalls. The point is that a lot of (badly designed) consumer routers (firewalls) do stupid things like routing only TCP and UDP, or treating those other protocols as "special" under the assumption that VPNs will always be used from the inside out, never from the outside in, resulting in all sorts of fun.

It doesn't help that most VPNs are so easy to detect and block at the IP header level. PPTP depends on the GRE IP protocol (47), and L2TP is usually tunneled over IPSec, which depends on the ESP IP protocol (50). By using different protocol numbers in the IP headers, the designers of these protocols made it mindlessly easy to block them, and made them harder to support, because routers have to explicitly know how to handle those nonstandard protocol numbers.

Nah, it's more like whining that Chryslers should be able to burn the same 87 octane gas as Fords without having to buy overpriced filler necks on license from GM. Or that GE lightbulbs should be allowed to work on ConEd electricity. Standards exist for a reason. Letting monopolists enforce their own whims without accomodating the competition is bad for everyone in the long run. Ask JP Morgan what happened to Standard Oil in the courts.

On the one hand, yes, on the other hand, no. Standards can only go so far. Suppose you design a laptop that has an innovative power storage system that can power it for a week, but in order to get the energy density high enough, you had to run the battery packs at 48VDC. Could you design it to be compatible with an existing 12–18V power supply? Sure. Would it be energy efficient? No.

The same goes for software. If you're designing a new OS, you could ostentibly add the necessary hooks to let it run Android apps, but your OS probably won't run them as efficiently, and you'd prefer folks to develop apps for your own native APIs anyway, because that results in a better, more consistent user experience.

There is no fundamental difference other than the webpages are standardized and the interface between apps and the OS is not standardized. They are fundamentally the same -- apps can be converted to websites and vice versa.

There is no fundamental difference between ice and steam other than the temperature. I don't recommend trying to walk on steam or clean your carpets with ice.

The reality is that the layout system and DOM programming interfaces available for web programming are positively primitive compared with app programming. (I'm deliberately ignoring WebGL for the moment, which though powerful, is low-level enough that it isn't practical except for games, and still isn't broadly available.) And networking is even more limited (same-origin restrictions) without cooperation from every destination site.

So in theory, yes, but in practice, not even close. And the fact that even relatively straightforward stuff like HTML editing isn't fully standardized (or, frankly, fully working) across major browsers should give you serious pause when considering standardizing anything as complex as a full-blown collection of application APIs across multiple platforms.

OS companies go to great lengths to create system APIs that are incompatible with other OSes to prevent developers from developing platform-independent apps.

Uh... no. OS companies build their systems using entirely different programming languages, for philosophical reasons that diverged decades back. Because of that difference, they create system APIs that are incompatible with other OSes because it would not be feasible to create APIs that aren't. Additionally, there are a number of fundamental differences between the two platforms (including their security model) that require platform-specific handling. Those differences have nothing to do with wanting to be incompatible, and everything to do with designing APIs to meet their specific goals and ideals.

In fact, platform vendors have gone to a great deal of effort to reduce portability problems. That's why both Android and iOS support cross-platform APIs such as POSIX and OpenGL ES. By taking advantage of those technologies, developers can write much of their code in a platform-independent way (with lots of caveats, of course).

Sounds like a buying opportunity... for put options....

But where he is being completely batshit illogical is where he argues that once app platforms are common carriers, the users must give equal treatment to the platforms rather than the other way around. To use the previous example, it would be as if the government mandated that if you offered to ship something via UPS, you must also offer to ship it via FedEx. Such a mandate has never happened, and probably never will.

Not offer to ship it. Ship it. With physical products, the analogy can't really work, but the closest equivalent would be mandating that companies take bids when working government contracts....

Either way, though, the idea is absurd for several reasons: platforms can't easily be compatible with one another, you can't realistically expect companies to design software for platforms that they're unfamiliar with, and there's not even a guarantee that it would be possible for a company like Apple to port their software to Blackberry, because the OS may lack required functionality under the hood. Add to that the risk of giving anyone who creates a platform with ten users the right to demand that Apple port iMessage to their token platform, and you can see how such a law would quickly spiral out of control.

What the Blackberry CEO should really be asking for is a law mandating that all protocols and exchange formats be open (with reasonable documentation) and free of any patent encumbrances that are fundamental to any implementation of the protocol. Such a law would ensure that Blackberry could freely implement iMessage compatibility themselves. And the right way to argue for such a law is twofold:

• Communications technologies must be standard if you want people to communicate with one another. It's harmful to the consumer when a text message either costs money or doesn't, depending on what phone the other person happens to use. After all, the recipient's hardware platform could change at any time. And it is doubly problematic when you factor in protocols like FaceTime, where you have to run entirely different apps and contact the other user in entirely different ways depending on what kind of phone the other person is using (e.g. Skype if the other person is running Android).
• Protocols and file formats contain copyrighted material created by users. To the extent that those protocols and file formats are controlled solely by a single company, they have the effect of taking the users' creations and locking them up. If that company goes out of business, the users' creative works could be permanently lost.

The extent to which the second argument applies depends to some degree on the ephemerality of the communication, of course.

As a happy side effect, such a law would have the benefit of putting an end to patents on technologies like GSM, CDMA, LTE, etc. for the same reasons.

Sorry. I can't take any solution that runs on PHP seriously. Especially one with such a history of horrid bugs and remote exploits.

If you're talking about WordPress, then I would agree. It has a long history of security problems, mainly because it was written in an era when PHP was too popular for its own good.

Anyone suggesting PHP as a solution is quite obviously a moron.

The problem isn't PHP. The problem is PHP coders. When PHP was in its heyday, it made basic website CGI coding simple enough to attract a lot of coders who didn't have much experience. A lot of PHP code was written during that period. The result is that a lot of PHP software (much of which is still in common use) was written by people with minimal programming experience.

To make matters worse, the initial MySQL API in PHP was disastrous. (That's not PHP's fault, mind you; the same API was used in C and every other language at the time.) Most PHP software out there was written before the modern, parameterized syntax became available, so statistically speaking, the overwhelming majority of PHP code that uses MySQL probably contains security holes.

If you take a group of people who have solid programming backgrounds today, give them a two-week training course on PHP, then spend another two weeks on PHP-specific security and design issues, and insist that they use parameterized queries exclusively, you'll end up with good software. Unfortunately, this approach precludes the use of any software currently available unless you're willing to spend the time to do a detailed security audit.

Oh, yeah. I forgot to mention that those pixel counts were for adult-size heads. Scale accordingly for younger kids. :-)

I've done just that - only from the back row. You can easily attach teleconverters if you want zoom ...

Okay, six pixels was an exaggeration—in a small hall, by my math (based on photos I've taken with other cameras), an 8MP iPhone would yield faces ranging from 26 to 50 pixels tall. With a 6D, a full-pixel crop at 40mm isn't great, but it is usable for people near the front of the stage By the time you get down to a 10MP APS-C sensor, it is barely usable for people at the front of the stage, and is useless for people near the back. Scale that down to 8 MP and it won't be. Add in the extra noise from a tiny sensor, and it wouldn't even be close to usable.

And there's also the shutter speed problem. By my math, if I'd used an iPhone to shoot photos of a stage last week instead of my 6D, at the iPhone's maximum usable ISO, I'd have been limited to a 1/50th of a second shutter speed, which without optical IS is way too slow for my taste.

Once you start adding teleconverters, yes, a phone can be a serviceable tool, albeit with a long list of caveats—the inability to quickly change the zoom length (AFAIK, they're all prime teleconverters, not true zooms), manual focus, fragility, focal plane inconsistency because of mount flex, and so on—none of which are show-stoppers, but all of which lead to significantly diminished "keeper rates". It's the difference between 20% of your shots being keepers and 95% of them being keepers. Mind you, I enjoy playing with manual focus primes every so often, but I'd never use one as my main lens. It's just too much work for the reward you get.

... and frankly lots of people are willing to use digital zoom also.

Don't get me started on digital zooms. You might as well just crop the photo afterwards; you'll get the same result, but you might actually get other interesting stuff in the photo if you don't use one. :-)

It doesn't matter how good the sensor, camera, or lens are really - because the entire non-smartphone camera market is shrinking rapidly.

I think you're misinterpreting the numbers. The market at the low end is contracting because cell phones are cutting into it. The market at the high end is contracting because neither Canon nor Nikon is really innovating much. If each generation has only small, incremental improvements, people are going to upgrade their gear less and less frequently.

Nobody is replacing their DSLRs with cell phones, within some small epsilon. At best, cell phones can replace DSLRs for outdoor portrait photography, when you're within a few feet from the subject. On the opposite extreme, if you try to use a cell phone to take photos of your kid's stage play, you'll annoy everyone by standing up in the front row, and you'll still only get shots with blown-out faces that are six pixels by six pixels in size and so severely smeared by motion blur that nobody would be recognizable even if you could fix those first three problems.... All the while, the parent with the real camera might be taking amazing close-ups with a 300mm (or longer) lens on a full-frame camera from the back of the auditorium.

Of course, half the time, the parent with the real camera has a lens that's too short to be usable and hasn't learned enough about the camera to avoid getting blown-out shots. Unfortunately, some of those folks get discouraged and never upgrade their gear. Fortunately, there's a steady supply of people who can't be bothered to learn the basics, so them getting discouraged isn't a big problem market-wise. :-)