I'm sure you're trolling, but just in case you're not. X11 was designed to solve the problem of how to interconnect a screen on machine to a server, because when it was designed the model was very much big multi-user servers and research on how to migrate from dumb text terminals to dumb graphics terminals.

The result is a well designed stream-oriented protocol, designed such that high-latency links wouldn't cause a bad user experience. That stream protocol doesn't need to run over a network - it can operate just as easily over a UNIX pipe and in fact, that's how almost every distro has it set up nowadays by default. It could just as easily run over a serial line.

Since local machines became more powerful (a trend that started in the 90s), it's often now the case that the multi-user server and the X display are been run on the same machine and various optional extensions have been introduced to support sharing data through shared memory.

However, even though the approach taken by Windows is to lump everything together in one monolithic block, that doesn't mean it's the right way to go. If you actually look at how a modern GPU is designed, the model is actually far closer to X than it is the Windows API. You put commands into a FIFO command buffer and at some point later the GPU executes them, and you want to minimise the synchronisation points between the CPU and GPU because this always requires one waiting for the other. This is exactly analagous to how X commands are put into a serial stream and executed some point later. You'd notice, if you actually looked into it, that even GL is designed this way.

The X model makes sense. The GL model makes sense. Tightly coupled frameworks don't because they're inherently limited to current technology. See how Windows has migrated from GDI through the various versions of DirectX until it's finally closer to the GL model. The model SGI introduced 20 years ago and has been little changed since.

It's not a niche feature. Just because you don't need it, it doesn't mean that millions of others don't.

Even on my home network I use X11 between machines every single day. It's the simplest solution to an awful lot of problems when you're using more than one machine and it generally works much better for interactive use than remote desktop or VNC on a local network.

So, you want X11 then? *sigh*

I loved my Palmpilots - I still own two even now, but their real problem from a programmer's perspective was the overly restrictive 64KB model and having to use a database for all storage. That meant everything had to be especially written for the palmpilot and it was difficult to include support in a cross-platform programs. Not impossible, but it felt like it was Palm or everything else at times. As the devices got better and better, the tiny memory restrictions just got more ridiculous.

Also, there was some developer support issues - for instance, I remember at the time when people wanted to create pdb files offline and the official response was "we don't know what the pdb format is because the MS runtime handles that" was just ridiculous. Obviously, it was possible to reverse engineer the format, but a company not having documentation on its one and only file format isn't great.

That said, the API was well thought out and nice to use. Just different to everything else.

Also, people don't google when they are taking drugs and not suffering side effects, people google multiple times with different queries when they do &c, so there's little in the way of accuracy in the numbers of people affected in each case.

The only sensible way to interpret the numbers provided is "for the symptoms found b y this approach for a given drug, there's a 20% chance the symptom isn't in fact caused by this drug at all." Which makes it pretty useless for determining symtpoms that are hard to detect.

I actually think the article fails, because it's based on a tautological assumption.

But, you don't know this until you've learned to code. So, it's clearly something that if you try coding, you'll ever realise it's something you're passionate about wanting to know more about until you're good at it or that it's something you hate with a passion.

In my case, there are probably lots of things that I'd be passionate about if I did them. I can certainly think of a few jobs in different areas I'd really enjoy doing. However, I've had the opportunity to try coding from an early age, enjoyed it and stuck with it.

None of that is a reason why people who don't yet know how to code should take it up as a profession. Perhaps they'd find carpentry just as rewarding if they tried it. Or writing books. Or any of a number of things. What should be said, however, is if you get the chance you should try it and it's OK to hate it.

All other things aside, pointing out that programming often pays well (as well as often requiring long hours) isn't a bad thing. It encourages people to try it. I know someone from who decided they wanted to be a dentist at age 12, simply because he'd heard it was a well paying job. It might not be the best reason, but it got him into the profession.

But certainly, if coding was on a school curriculum, more people would try it earlier on, just as people are exposed to woodwork and story writing at school. This appears to be code.org's objective, and it seems like a good one as long as they're not advocating make coding mandatory even when you realise it's not something you enjoy or have an innate skill for.

Thanks for the link to the data, that's useful stuff! :)
IMO, the original article was badly worded... I interpreted "come January" as "sales up to the start of January", i.e. from launch until the end of December.
Mind you, I still think it's too soon to start comparing sales figures. Many people I've spoken to, including a lot who own Wiis, haven't even heard of the Wii U yet, so possibly the biggest problem is that Nintendo's advertising to date hasn't been successful enough.

There's also the case that it's isn't Cisco's responsibility to ensure it's buyers aren't buying something they don't need. From TFA:

Maybe a moral responsibility, but certain not a legal one. They proposed a solution that'd perform the task required, the customer said "yes, we want that" and handed over the money. If they're not prepared to do due diligence, that's not Cisco's fault unless Cisco had been commissioned to make a report to evaluate exactly what was required to equip each site for the cheapest price possible. The article suggests that it was more like "we have x sites that need routers, some as big as y" and Cisco sold them x routers capable of doing y.

Also, TFA is incredibly biased. Take for instance:

Sounds great on face value. Until just a couple of sentences later...

So, even though by their own admission, the 360 sold a third of the units the Wii U did, they still trumpet that it outsold the Wii U.

And let's not forget the PS3 here. That too had a slow start, yet now its worldwide sales are comparable to the 360's. It's simply too soon to tell how successful the Wii U is going to be.

And I bet she was singing this to herself as she did so....

There are several problems here that could have led to his predicament.

Firstly, he filed an overly narrow patent - the charging a battery application is an obvious extension to his original design that he should either have generalised his patent application slightly or field another patent for charging a battery via a wind up device. Whether the company he worked with came up with the later invention or another company did, he still wouldn't have made money from the second invention, because he didn't patent it.

The second problem is that it sounds as if he negotiated a bad business deal. If his original product sold millions, then a relatively low-per unit royalty should have easily cleared all his debts. I suspect he sold the idea for this product to the company as a one off so that he could carry on inventing, keeping those ideas to himself. In this case, the company has no obligation to him and they would logically do R&D to see what else they could develop. Had he negotiated differently, he could have been an employee of the company, carrying out further R&D and being named on the patents. Obviously, he made the gamble and chose wrongly on this occasion.

I feel for the guy, but it sounds like he didn't pay enough attention to the business side or had too much optimism for his future inventing potential. He should probably have involved a patent lawyer earlier on in the process. Perhaps even as a inventor and not a salesman himself, he should have hired someone to pitch the product to investors to get the best deal. But either way, knowing how to capitalise on an invention is just as important as the invention itself. It's never enough to just file a patent and hope the money rolls in.

To me, 270 mile range sounds fantastic (my car only gets 210 miles to a tank). I know charging points aren't yet as ubiquitous as fuel stations and that's the point of these tests, but seriously 270 mile range is more than enough for most people to do 95% of their regular driving without even considering range.

For a nice example of this being done by humans, see Ken Shirriff's decoding of the 8085 instruction decode logic.

I think part of the problem is that a lot of inventions are really just the next logical step from current systems, and especially when you have a lot of independent groups working in similar areas, the chance of inventing something truly unique is quite low. One of the problems with the patent system, I think, is that it affords the first "inventor" an enormous advantage over everyone else who might also come up with the same idea independently.

I'm not saying there aren't often genuine inventions and patent worthy things, but a lot of stuff that is just an iteration beyond what went before isn't really an invention...

Personally, I hate it when someone touches my screen and leaving behind smeary fingerprints when they're trying to point to something. It can only get worse If they actually get to control my system by doing that...

That said, there are occasions when it'd be handy, but it's not something I'd want the majority of the time.