Beside, best techs from other countries are already in demand at home, no need for them to move. "The best" is not someone US would get from H1B visa program.

Reality check: tech companies hire all sorts of people in all sorts of places for all sorts of reasons.

Back in 2006 I got a job with Google SRE (at the age of 22) and they gave me a choice of locations. I chose California. But it was 2006 and the economy was booming, and that year they hit the H1B visa cap. I wasn't considered important enough to use up one of the last H1Bs they had (fair enough), so ended up moving to Switzerland instead. Over the following years I was promoted several times, invented a major new spam filtering technology they now use on all their biggest products, and earned a hell of a lot of money. Which I spent in Switzerland. I left in January to form my own company, although Google wanted me to stay.

Had I obtained an H1B, I would probably have done substantially similar things in the USA, but thanks to attitudes like yours that wasn't possible. I'm not complaining though. Having spent plenty of time in the Valley I came to appreciate my luck in not ending up there. Why would I want to live in a suburban desert like the bay area, or San Francisco where it seems the local population viscerally hates tech workers, when I can live ten minutes walk from a lake so clean people swim in it every day during summer and the local population still thinks Google is cool?

Looking back, I got lucky that I was denied an H1B. But economically speaking that was Switzerland's gain and America's loss.

If you RTFA you'll see that Lewman has zero evidence for this assertion. The headline paints it as a statement of fact but in reality all Lewman knows is there are people who appear to be reading the source code and reporting bugs anonymously. That's it. They could be NSA/GCHQ moles. Or, more likely, they could be anonymity fans who like security audit work. They really have no idea.

Part of this is the much-hated reference requirement -- all facts in a Wikipedia page must have an external source to back them up. This rule alone causes a huge amount of strife among those who don't understand

It causes a huge amount of strife because it's yet another policy that's easily manipulated by people with no common sense.

For a long time the article on Bitcoin stated outright that it was a ponzi scheme, despite that Wikipedia's own article on Ponzi schemes had a list of requirements which Bitcoin obviously did not meet. Attempting to get this fixed was a kafkaesque nightmare due to someone camping on the page and immediately reverting any change that removed or even just qualified this statement. The reason: the statement had "citations" which turned out to be (a) someone's blog, and (b) an article in The Register, that well known bastion of reasoned and careful analysis.

Wikipedia is a project that manages to work in spite of the absurd management and crazy policies, because the idea of a global encyclopedia is such a compelling one. But it badly, badly, badly needs to be forked by people who find a way to run it better.

That's easy to fix. If a cell has not just the existing error correction codes but also digital ones as well, then mutagenic substances (of which there are a lot) and telemere shortening can be fixed. Well, once we've figured out how to modify the DNA in-situ. Nanotech should have that sorted soonish.

The existing error correction is neither very good nor very reliable. This is a good thing, because it allows evolution. You don't want good error correction between generations. You just want it in a single person over their lifespan, and you want it restricted so that it doesn't clash with retrotranspons and other similar mechanisms. So, basically, one whole inter-gene gap/one whole gene protected by one code. Doable. You still need cell death - intercept the signal and use a guaranteed method.

Here, in the year Lemon Meringue, we decided to solve the problem once and for all.

Instead of trying to kill cancer, we hijack its techniques. We start by having nanocomputers in the vaccuelles of each brain cell. These keep a continuous backup copy of the state of the brain up to death. Cancers disable the hard limit on cell duplication that cannot otherwise be avoided. By using the techniques of cell-devouring microphages, the cancer "consumes" the old cells and replaces them with new ones. They can't spread anywhere else, because that's how the cancer is designed to spread. Once the body has been fully replaced, the cancer is disabled. The brain is then programmed by the nanocomputers and the remaining cells are specialized by means of chemical signal.

This does result in oddly-shaped livers and three-handed software developers, but so far this has boosted productivity.

The free market didn't provide alternatives. The free market created Microsoft and the other monopolies. Adam Smith warned against a free market.

The majority do not create alternatives, either. The majority like things to not change. The familiar will always better the superior in the marketplace.

Alternatives are created by small groups of people being disreputable, commercially unproductive and at total odds with the consumer. These alternatives will typically take 7-14 years to develop. Adoption will typically reach peak after another 7-14 years. By the 30th year after first concept, the idea will be "obvious" and its destiny an "inevitable consequence" of how things are done.

In reality, it takes exceptional courage and a total disregard for "how things are done". 7-14 years with guaranteed losses is not how the marketplace works. Even thinking along those lines is often met with derision and calls of "Socialism!" by the market. No, real inventors are the enemy of the free market.

If you want a Linux desktop, you must forgo all dreams of wealth. You must subject yourself to the abject poverty that is the lot of an inventor in a market economy, or move to somewhere that supports the real achievers.

The problem is corruption. OSDL were working on a Linux desktop environment, but a key (financial) figure in the organization worked hard to kill off success and left around the time the unit went bankrupt. Several organizations they've been linked to have either gone belly up or have suffered catastrophic failure.

I won't name names, no point. What is the point is that such people exist in the Linux community at all, parasites that destroy good engineering and good work for some personal benefit of their own.

X is not great, but it's just a specification. People have developed Postscript-based GUIs using it. It's merely an API that you can implement as you like (someone ported it to Java) and extend as you like (Sun did that all the time). The reference implementation is just that. Interoperability of just that set of functions used by Glib/Gtk and Qt would give you almost all the key software.

Alternatively, write a GUI that has a port of those three libraries. You could use Berlin as a starting point, or build off Linux framebuffers, or perhaps use SDL, or write something unique. If it supports software needing those libraries, then almost everything in actual use will be usable and almost everything written around X in the future will also be usable. If what you write is better than X, people will switch.

Binary drivers exist and are loadable so long as they are properly versioned.

Block drivers can always use FUSE.

Automatic builders can recompile a shim layer with new kernels (or even the git tree version), automatic test harnesses or a repurposed Linux Test Project can validate the shim. You don't need to validate the driver for everykernel, if it's totally isolated from the OS and worked before then it'll remain working.

Automated distributors can then place the binaries in a corporate yum/apt repository.

What has an ABI got to do with it? Only gets in the way of writing clean code.

The commands to the bus don't change.
The commands sent to the hardware don't change.
The internal logic won't change.

That leaves the specific hooks to the OS and the externally visible structures.

Nobody is insane enough to use globals directly and structures are subject to change without notice. So external stuff will already be isolated.

If the hardware is available for any two of HyperTransport, PCI Express 2.x, VME/VXI or one of the low-power busses used on mobile hand-warmers, err, smart devices, then the actual calls to the bus hardware will be compartmentalized or go through an OS-based abstraction layer.

So 95% of a well-written driver is OS-agnostic and the remaining 5% is already is isolated.

So either drivers are very badly written (which is a crime against sanity) or the hardware vendor could place the OS-dependent code in its own DLL at bugger-all cost to them. Since the OS-dependent code has nothing trade secret in it, they can publish the source for the shim at no risk. Since the shim isn't the driver, there's no implication of support for OS' they don't know or understand. It's not their problem what the shim is used for.

Everyone's happy. Well, happier. The companies don't get harassed, the Linux users get their drivers, Microsoft gets fewer complaints about badly-written drivers killing their software. It's not open, it's not supported, but it's good enough.

The rotting out of Verizon's wires is much more likely to push people to non-Verizon services given how little of the US FIOS covers.

For me all it did was cause me to drop Verizon completely and switch to T Mobile.

Kraft is a large company, but it has DOZENS of equal sized or larger competitors in the markets it serves. For example in the beverages segment Snapple is bigger than they are. In cheese Mondelez is three times bigger. And so on.

Unilever is hardly a food company at all. It sells 10 times more personal care products (soap etc) than it does food.

Don't confuse diversification with market share. Two very different things.

Your outdated "value-adding" "service provding" skills are so 20th century. 21st century careerism is about networking. Networking. Networking. Netowrking.

Look at item number one on TFAs list.

1. Take names. ...

In five to 10 years, that will all be different and the person who you ignored because they were boring and couldn't help you will be the person who could have won you an important opportunity.

Network! Impress people! Dress right! Booze people up! This is how successful companies are made. You will not attract the rright venture capital with your simple abilities. Most companies won't even use those anyway.

2. Problem solving. .....

Problem solving is essentially the same thing you learned in abstract in seventh or eighth grade or whenever you learned simple algebra.

See! Look at this! The people this guy is writing for don't even know how to solve problems. They just code stuff nobody really needs -- and they're still successful! You think your ability to analyse and abstract is something all the cool kids will pay for? Think again. Your geek/nerd/hipster/bro-grammer cred wil matter far more.

6. Work more than 40 hours per week.

Profession? You think programming is a profession. Get back on that hamster wheel and like it code monkey. And get some hair dye. First sign of a grey hair or stress line from yellow packs like you and we sack you and hire a fresh young grad to suck into a husk.

5. Think in terms of a career, not a series of jobs.

Translation: "You can either join the fed-money, app-cloud bullshit wagon, or you can learn to love foodstamp lines. Either way, it'll still be a superior outcome to any science-fiction fantasy you imagined programmers were capable of making in a rational universe. The Market wants fart-buttons, not robots, so drink the kool-aid or join the lowest caste of contract workers you, you, you..... Loser."

No wonder so many programmers go into management.