When Google offered me a job, I could not believe how little they wanted to pay me. 67% of what I was making at a megabank

Er, you could probably replace "Google" in that sentence with any company. You're comparing your salary to one at a fucking bank, companies so famous for absurd compensation packages that it triggered street protests ....

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.

A union is most beneficial when workers are easily replaceable -- because if management can replace worker A with worker B without a lot of overhead, management can (and usually will) use that to drive salaries down, approaching the lowest salary that they can find at least one worker to accept.

The trick in programming is to make sure you are not so easily replaceable -- if the company knows that it would take 6-12 months to get a new hire up to your level of productivity, they will not be so quick to "value engineer" your salary and benefits. Then you don't really need a union to stand up for you, because you have leverage to stand up for yourself. (The right way to do this is to know the company's software inside and out; the wrong way would be to make the software so convoluted that only you can understand it... ;))

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.

Well, arguing with you makes no sense.

First it is not a drug but a kind of "gene therapy" (actually it is not, but it is much closer than a 'drug')

The human body is not a cell nucleus. For example, if this drug triggers an allergy response, then you have both harm and the destruction of the drug before it can do something useful.

Good point, now you made perfectly clear why the treatment we are talking about: is not a drug.
And you emphasize that you are not interested in science, otherwise you would not write such nonsense.

Hint: reading up about how this stuff works is less then 8h, you can read every day 1h and after a week you perhaps know more than me about DNA/RNA, mRNA, siRMA etc.

But unless you invest at least some basic "reading up" you simply don't qualify for topics like this.

For example, if this drug triggers an allergy response how should an siRNA particle trigger an allergic response? Hu? Science Fiction? Note: it is not a drug, regardless how retarded you like to define it.

Just because two organisms have something in common with respect to this drug doesn't mean that their differences won't matter.
It is not a 'drug'.
It is a short 20 - 25 bases long RNA strand. (You know what DNA and RNA is?)
That works exactly the same in every life form based on cells with a nucleus. No idea how the exact english name for it is, as I don't know the proper spelling of the german/latin word and can mot google it. Something like Eukariots.

So: there are no differences that 'could matter'. Can be easy read up and googled, but as we saw in the other discussion, you are definitely not a science guy.

And what happens to the mind of the body you are transfering into?