I understand the motivation. I'm just not discussing the parts where I agree with you. :)

I just took issue with your original statement where you envisioned the open gate array dominating the low end market based on price.

1. Cut out those which don't have best $/transistor process nodes (~32 nm -- ~14 nm depending on who you ask).
2. Cut out the memory fabs, their processes aren't suitable for general purpose logic.
3. Dig in and notice cases like CNSE which is actually GF.
The remaining list is those 3 plus Intel.

Optimization per fab is a bloody understatement. To have something that is even close to competitive in performance/power/area you need to a) custom design your gate array to each process b) characterize the resulting chip from each process so the EDA tools can produce something close to a good solution.

I fully appreciate you need the FP part in FPGA. What I was trying to say is that those users who don't need the FP part are already helping drive the FPGA prices down for high volume applications.

I don't think there's an open source FPGA design can bring much margin for improvement in pricing.
Keep in mind is that the FPGA manufacturers already have a type of competition: beyond a certain point, it's cheaper to roll out your own ASIC.
This already constrains the volume and price on their low end offerings.

You're also being quite naive about competition between "cheap" manufacturers, when applied to semiconductors.
First challenge is that lowest cost/transistor is provided by relatively modern processes (eg, 32-22 nm) and your fab options are few and the same as Xilinx/Altera's: TSMC, Samsung or GF.
Second challenge is that it takes a considerable ammount of effort/time/money to move a design between different manufacturers (and the more optimized, the worse).

It's not a totally of a different problem than faced by developers of open source compilers and graphic drivers: any given model is only in the market for a short while, much less than FPGAs.
And while CPUs are usually* replaced by 100% backward compatible models, new GPUs aren't usually backward compatible.
* Except when the entire instruction set architecture dies away.

The trick is, of course, to reuse as much of the code as possible to support different architectures.

Same thing is appliable to FPGAs and ASIC development. And people are actually doing it.
A couple of interesting projects:
http://code.google.com/p/vtr-verilog-to-routing/
http://www.clifford.at/yosys/
http://opencircuitdesign.com/qflow/

It's not yet Verilog to bitstream but some of the technically harder parts are getting done.

Err..
First, the Concorde cruised at Mach 2.0 without reheat. On the Concorde, reheat only added some 20% (IIRC) to the thrust was used mainly to accelerate to cruise speed.

Secondly, to design a more powerful/fuel efficient engine without reheat, you need to handle higher flows, temperatures and pressure.
Reheat is a "cheap and easy" way to work around this issue, although at the expense of fuel efficiency.

That said, using more advanced materials which can handle higher temperature and pressures to build more powerful and efficient engines is the normal business in jet engines.
Using modern materials and designs, one could surely design a high/medium bypass turbofan that is quite more efficient than Concorde's turbojets.

Listening to music is highly emotional and subjective.
Claiming that vinyl, somehow, allows for a better one that CD is not subjective.
Knowledge of human hearing, audio signals all point to one thing, confirmed by blind tests: if you take a vinyl and properly record into a CD-R, or FLAC, people can't tell the difference.

AFAIK, nobody has bothered to do a "proper" blind test of a vinyl vs something else.
Some of us have done is casually: rip a vinyl to FLAC and it still sounds the same.

In my experience, people who are willing to understand the meaning of a double blind test don't need it to know CD is a better format than vinyl.
As for the others, there isn't any amount of double blind testing which will reach them.

WARNING: a lot of vinyl editions of a given album DO sound better (to my ears) than the CD edition of the same album because they have a different masterization, The CD editions often have their dynamic range brick walled into oblivion, while the vinyl edition hasn't. Which is absolutely infuriating, as the CD has a larger dynamic range.

Some proper blind tests have been done of CD vs SACD/DVDA: "Audibility of a CD-Standard A/D/A Loop Inserted into High-Resolution Audio Playback".
Summary: sound engineers, music students and the likes of which can't tell the difference between SACD/DVD-A and the same reduced to CD quality.

Legislation requires you to have insurance because, if you want to drive a car and incur in the risk of damages to third parties, society needs to ensure you (via your insurance) can bear (part of) the cost of reparations, instead of leaving it all on victims and the state.

Insurance is a free, competitive market.
If it's not, your regulatory agencies are not doing their job.

Insurance companies adjust the fees based on what they perceive it's the risk you will cause/be involved in an accident but also on the amount of expense they can incur.
If the Ferrari is driving people commercially, it spends more time on the road than your average private car and is thus more likely to cause/be involved in an accident than a Kia which is only used to commute from home to work.
Also, if the Ferrari is damaged in an accident caused by the Kia, which happens to have the same insurance company, the insurance company will have to pay more than if two Kias had collided.
It's the insurance's company prerogative to charge you more for spending more time on the road and bringing a more expensive car to the road.
The insurance company may also have figured out Ferrari drivers are more likely to cause accidents.

You may not like this situation, but the Kia owner does. If you don't like, find another insurance company. Or buy a Kia and stop driving for Uber.
 

Despite the vague claims in their blog, there is no evidence that Uber is providing valid insurance for their _UberPOP_ drivers in _Europe_, nor that it is ensuring they have one.
At least, the Frankfurt court found that they do not.

AFAIK, they do check that the UberBlack drivers have proper insurance.

Nobody was suggesting that the drone pilot was intentionally trying to hit the aircraft or that's it's easy to do so.
But if you have a drone in the general vicinity of an aircraft, there's a chance it will end up being sucked into the engine, smashing through the cockpit or something else with dangerous consequences.
And as you may or may not know, Murphy's law is a bitch.

Hundreds of aircraft get damaged each year by hitting birds. Some also get damaged by objects or animals in the runway.
And that is despite airports taking huge (and expensive) measures to minimize the problem.
These incidents cost a lot of money in repairs and, while most result in no harm, each represents added risk.

Having small RC aircraft flying around in the restricted airspace of an airport is an added risk for no good reason. People who operate these things should just be aware not to operate them near airports.

At this point, some people will somewhat rightfully complain.
What does the init system have to do with this? Why can't we do this with sysv init? And the answer is "technically, no reason".

It just so happens that the only piece of software that currently can do this job properly (systemd-logind) is part of the systemd project and has a dependency on systemd(-init).

But at the same time, that dependency exists simply because no other project implements the necessary features. Once someone creates a capable alternative, the dependency will tend to disapear.

And this is already happening: there is still no credible alternative to systemd-logind, but there is a credible alternative to run systemd-logind without using systemd as init.

Yes, Wayland will "need" systemd
Or more precisely, it needs something which does what systemd-logind does: manage the permissions of the hardware so that the compositor can use access them.

Quick history note:
Until not so long ago, the vast majority of LInux systems ran the Xserver as root, because it was the only (practical) way to have it access all the hardware it needs to (graphics, mouse, keyboard).
Only with systemd-logind it became practical to run the Xserver as $user.

Wayland needs the compositor, which runs as $user, to be able to access the hardware.

I use Linux on the desktop, for both personal and professional use.
For me, a functional system requires me to run hundreds of packages.
Several of them are large monolithic pieces of software for which I have no real alternative: the Linux kernel, the GNU libc, the X.org Xserver would be the best examples.
Yes, there are alternatives but I can't run all I want/need to with them.
systemd is a drop in the ocean.

Devuan is, quite honestly, the most irrelevant Debian derivative ever.
And the reason is simple: regarding Debian, this is a storm in a teacup, created by people whose notion of freedom is to force others to follow their opinion.
Debian has merely chosen to use systemd over SysV as default init. Debian has shipped alternative inits for ages and Debian has not put roadblocks in front of those who wish to put in effort to ensure Debian can be used without systemd as init.
There are people putting in work to ensure you can run Gnome without systemd for almost as long as Gnome has depended on systemd. And they haven't been complaining. There is no need to fork Debian to accommodate them.
As long as people are willing and able to do the work, you'll be able to replace systemd with something else with an "apt-get install sysvinit systemd-shim systemd-"

systemd is, first, a new init system for Linux, to replace sysv init.
Additionally, it brings a host of companion daemons: logging (journald), a session manager (logind) and a bunch of others.
systemd and it's companions offer a host of functionality and a number of software pieces are becoming to depend on it, to the point you "can't" run a fully functional Gnome3 without using systemd as init (it needs the session management functionally of logind, for example).
The major distributions have adopted systemd as default init system: Fedora, RHEL, SuSE, Debian and Arch. Ubuntu hasn't changed yet but they have announced they will follow Debian in the future.

There is a number of people who dislike it for many reasons, which are hard to summarize because many of the people dislike it for false reasons and only some actually make valid and constructive critiques.
Eg, many people claim it's monolithic. In fact, it's made of ~100 daemons and applications and the init process isn't that big. Much much smaller than the Linux kernel itself, which a big monolithic kernel.

Many peole dislike being "forced" to use because the major distributions are adopting it and major projects like Gnome are becoming dependent (with KDE talking about it too).

I use "" in "can't" and "forced" because it's not strictly true. While a lot of people whine and hate in slashdot, a small number of people have been putting their code where their mouth is and working on alternatives.
Eg, there's a systemd-shim package in Debian which actually allows you to run Gnome3 very nicely without using systemd as init, by providing the necessary systemd features.

You should dig a little deeper.

For the first link:
- The survey was made only among geo-scientists and engineers in the province of Alberta, Canada (where the oil industry is a major employer), it's a world wide survey of experts in climate.
- The actual results of the survey were "27.4% believe it is caused by primarily natural factors (natural variation, volcanoes, sunspots, lithosphere motions, etc.), 25.7% believe it is caused by primarily human factors (burning fossil fuels, changing land use, enhanced water evaporation due to irrigation), and 45.2% believe that climate change is caused by both human and natural factors".

Put simply, the article you linked in it outright lying.