*bullshit*
It is that easy. Because some sane and nice people who care about not using systemd as pid1 have actually put in the work to do so.

systemd is only taking in everything as much as nobody is willing/able to provide comparable functionality.
Eg, there's no credible replacement for systemd-logind. ConsoleKit is unmaintained and less powerful. Developers of desktop environments and distributions want to take advantage of it's functionality and avoid the trouble of trying to get shit done using ConsoleKit.

But enterprising souls (ok, mainly from Ubuntu) have come up with enough functionality (cgmanager) to run systemd-logind without having to run systemd.

Then for f**ks sake, apt-get install something_else and stop bitching.

XFCE, LXDE, KDE, MATE, etc, etc, etc, are only a few apt-get commands away.Likewise, systemd (pid1) can be replaced by sysvinit (and systemd-shim if needed) with a few commands and one reboot.
NOBODY is putting roadblocks in the way of the Debian developers who are willing to put in the work to keep Debian as functional as possible without using systemd as init.

The entire Debian issue is a storm in a teacup, fueled by zealots to whom the mere presence of libsystemd in their hard drive is unacceptable and "freedom of choice" seems to mean that nobody should have the choice of using systemd.

You need to get out more.

Most servers run on Windows or Linux, mainly in the form of RHEL and SLES. Anything else tends to mean the hardware and software providers don't support you, which can be quite inconvenient.
Outside hobby servers, the number of servers using BSD or unsupported Linux distros (eg, I run Debian on personal systems) are a minority.

When dealing with systems with more custom hardware designs, things get varied. Cray XT6's compute nodes run a lightweight Linux installation, while IBM's BlueGene compute nodes run a custom OS with is only a few thousand lines of code.
But supercomputers we'd call clusters usually run RHEL or SLES or derivative with some add-ons. Comparing with BSDs is non-sense.

Among embedded systems with a multi-tasking memory protected OS, the most common sightings are QNX, VxWorks and Linux [full GNU/Linux, Android, WebOS, etc].
I can't recall the last time I saw a shipping product with NetBSD, actually. Despite it's fame for portability, NetBSD has been trailing Linux for a while and it lacks support for a number of modern embedded platforms. From the top of my head, there's no NetBSD support for AVR32, NIOS or Blaze architectures..
I don't think there's working support for FPGAs with embedded ARM CPUs either.

Someone has to design the integrated circuits that allow you to post on /.
Be thankful we exist and suffer for you.

To me, it looks like you're taking your hobby approach to work.

If you're using professional (lack of better word) proprietary applications from Xilinx, Cadence, Mentor, Oracle, Autodesk etc, in Linux you should do it on a supported operative system version: RHEL or SLES.
Of course, if you're running in Windows is fundamentally the same situation. Usually, application developers target and support only a few version version of Windows.
Eg, check https://www.cadence.com/rl/Resources/release_info/Supported_Platforms_Matrix.pdf

If you do that, it works relatively well -- no better, no worse than Windows.
If you go with anything else you're a) asking for trouble and b) their support won't even help you.
Even if you run CentOS, which is 99.99% compatible with RHEL, expect their support to refuse assistance until you migrate to RHEL.

Other than that, as your experience with Cadence shows, there is actually a large body of niche applications which is not available for Windows or where Windows is a second class citizen for the developers.
Another example from the top of my head is ROOT, the main data analysis framework used at CERN.It's mainly developed for Linux, including the graphical user interface parts which make the plots. OS X and Windows are second and third class citizens.

And their number seems to be increasing. For example, in the last few years Xilinx brought the Linux version of their tools to parity level with Windows (they're equally crappy now). And Altera brought their Linux tools from basic-and-expensive to almost parity with their Windows tools (there's a few glitches in the GUI).

The other poster was wrong: dmix runs in user space. Linux never had kernel space mixing/resampling, unless you patch it with OSSv4.
Which means your post is bullshit.

dmix doesn't run in kernel space, it runs in user space.
In an ugly way, by the way: the first application to load the dmix plugin forks() a process which run as the sound server.

That said, dmix was a very simple sound server that mostly did the job but PulseAudio does it better and also implements a long list of wanted features.

A modern 155 mm howitzer has an accurancy of about 50-200 meters at a 20 km range with standard shells.

Unless you load them with GPS guided shells (yes, they exist) at which point is becomes a few meters at 60 km range.

Despite FlyingGuy's somewhat US-sub fanboish tone (sorry!!), his fundamental proposition is correct.
Exercise after naval exercise has confirmed only one thing: even not-so-modern submarines are a nightmare for even the most modern surface fleets, as all the detection technologies have severe limitations.
Active sonar has limited range; passive sonar depends on the target's noise. Both are seriously affected by the noise environment and the ocean's thermal layers
Magnetic anomaly detection has very limited range and can be defeated/partially defeated by minimizing the use of ferromagnetic materials (such as Germany's U-212 class).
And they can attack a target without exposing their position too much. Launching a torpedo does no longer require you to yell the world "Here I am and this is my street number".
Modern torpedoes can quietly be launched and guided through an arbitrary path before before closing in on the target and being detected.
By the time a target detects a incoming torpedo, the launching sub can be somewhere in a few hundred of km of ocean, which already is a lot to canvas.

And the innovations mentioned in the article smell a lot like bullshit by the way. LED light of the submarine hull???

I've been using Debian unstable in my personal computers for years. Occasionally, something breaks.

But I prefer the long term support of Debian stable and CentOS for internet facing servers and lab workstations.
Here, it's important to be able to get security fixes without fear of breaking anything for years.

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.