Microsoft seems to have taken the other track now. They are still bringing the Windows experience to the tablet, but they've revamped the windows experience to be the kind that works well on touchscreens, some say to the detriment of the mouse and keyboard crowd.

What's annoying is the perception that salad is the only kind of food that qualifies as healthy.

At McDonalds, this is probably an accurate perception, and only if you skip (or go very light on) the dressing. Even their yoghurt is questionable.

Growing up in the 90s and early 2000s, I saw Tablet Computer prototypes come up every couple of years. Sometimes they would even make it to market, where they hit with a resounding thud thanks to their horrible clunky OS choices, lack of applications, and hardware limitations. Apple tinkered with the iPad for years before finally releasing it, waiting until the infrastructure grew up to make the device practical. They actually worked on the iPad before the iPhone.

Technologies that had to mature before the tablet computers became practical:

• Wifi networking.
• Capacitive Touchscreens -- Most early designs used a stylus, which sucks, and had poor resolution to boot
• Low power but still acceptably fast processors -- A huge sticking point, lots of early tablets had extremely poor battery life on top of being slow
• A touch enabled OS -- WinCE is terrible to use with a finger, and really pretty bad with a stylus. Symbian was never great. PalmOS was too narrowly focused on Palm pilots
• Battery capacity -- Battery technology has come a long way in the past 15 years. Early attempts would use NiCad batteries, which just aren't good enough, especially with the relatively high energy consumption figures from the old chips.

Apple didn't have a smash hit with the iPad because they were the first to the market. They won because they tinkered and waited until the technology was ready, then came out with a solid finished well integrated product instead of some halfassed "laptop without a keyboard running a cut down version of Windows".

But if the Luddites start-off by demanding building restrictions before others can move-in

That's apparently not how it's working out, though. Those moving in have money, and it costs $500,000 to build a single 800 square foot unit. Guess who gets the unit?

Because, as TFA points out, the problems San Francisco has are entirely self-inflicted. It's amusing to see karma on such a large scale.

There's that rational, open-minded tolerance San Francisco's known for.

If Theo had a more constructive outlook, this would go a lot different and we'd all benefit.

Instead of screaming vitriol at someone's app architecture inadvertently defeating his platform-specific feature, he should be asking why they felt the need to go with that architecture (hint: it was a perfectly reasonable need), and perhaps if he can do something to make integrating his security feature easier for that type of architecture.

Like you say, freelists are an extremely common design choice when performance is critical. This security feature could be hugely beneficial to many apps that use them (like, say, Apache HTTPd). Instead you've got the too-common case of an unbending programmer mad at someone for having needs other than his own.

People who don't use goto for error handling in C more often than not either have incorrect error handling or way too much error-prone duplication of resource cleanup code. It makes sense to very strictly warn newbies away from goto, much in the same sense that you warn them from multithreading. You don't want them used as a universal hammer for every nail in the code. At some point though, people need to jump off the bandwagon and learn to respect, not fear, these things that actually have some very compelling uses.

So instead of nameing version after a year (2000, 2003, 2008.....), they finally lost track of good version number. Some users barely are aware they are running an OS. And now it has gone so bad that even /. editors fail to keep track of version numbers of the most used OS in the world.

It's the first computer many people had access to, and especially the first computer they could actually program themselves. In an era where PCs cost thousands of dollars, a C64 cost only a couple hundred. Parents could afford them and the default shell was a BASIC prompt. Plus, it had built-in hardware to support making games (sound chip, sprite generator, joystick port) which made interesting to the kids first learning how to program on it.

translates to:

file= open(firstavailablefile());
sleep(disksize(firstavailablefile()) / 1000);
read(file, memory, disksize(firstavailablefile()));

If you love them, get them all backed up on to a HDD ASAP, and make sure your HDD is backed up regularly as well. You can fit an insane number of C64 floppies on a modern HDD, so keeping the images around won't take much space at all. The only way to really preserve data long term is to maintain it by bringing it with you as you upgrade.

Unless a programmer is working for a very large company, there's a good chance they're in pretty direct contact with their users.

Throwing someone into contact with users doesn't help someone become good at UX. Just look at the multitude of Open Source projects -- most of them interact directly with users and still end up with pretty atrocious UX that is designed based on the programmer's workflow and how easy it is to implement.

Every time I hear this from a developer, I cringe. Good UX is a choice. You can train in it, but until you really alter your mindset towards user interaction and embrace it, your projects will suffer. It's so easy, too: