KDE worked fine on 32-bit ARM, last I checked. If they're going through the effort to support a completely different architecture, I'm pretty sure they'll still support 32-bit x86.
Also, I'm not sure that PAE-support should even make a difference to anything running in userspace...

I just tested this with FTP and Audacity, and the files are copied to temporary directories before being opened in non-KDE apps. (Actually, they're copied for both, but to different directories for some reason...)
I'm using Sabayon with KDE 4.13.0 - you're either using an older, buggy version, or there's something wrong with your setup.

I'm not sure about Plasma-next, but I could comfortably run KDE 4.10 (or thereabouts) on a tiny little Tegra 2 clocked at 1 GHz with 1 GB of RAM and no hardware acceleration. Chrome ate more RAM than KDE ever did. I've also used KDE quite comfortable on a Pentium 4.

So if KDE doesn't run on your desktop, then I'll wager one of the following is the case:
-you have horribly broken graphics drivers. Try changing the compositing mode, graphic driver, etc.
-your PC is over a decade old
-you have stumbled across an extremely rare and specific bug in KDE

If you're using 4.13.0 (the first version with baloo), or about to upgrade, here are two things I learnt the hard way:

• When KNotes asks if you want to migrate your notes, say no. The migration process wipes them, and recovering them is non-trivial.
• If you have any virtual machines, make sure you've got limits.conf set to prevent baloo from eating all your RAM

Such is life on the bleeding edge...
But apart from that, Kmail/Kontact works great for me (especially with Kolab).

Most industrial machines are electrical; the kill switch is just a switch. Implementing something similar for an IC engine is probably considerably more complex.

They'd be a bit late.

It sounds more like an approximation. Given a failure rate of p and 2 (non-redundant) engines, the probability of system failure is 1 - (1 - p)^2 = 2*p - p^2. p > p^2, which means we can neglect the squared term, leaving just 2p.
It's not the sort of thing you'd do in a rigorous analysis without formally stating the justification, but it's exactly what I'd expect from a back of the envelope approximation or an informal explanation. Someone with a strong background in probability would probably do this sort of approximation almost subconciously.

The program will generate the same output yes, but the security implications are not the same.
This is actually tangentially related to heartbleed - if the memory had been zeroed when freed, the scope of the exploit would have been greatly reduced, as only currently allocated blocks would have been vulnerable. Furthermore, the most common reason for using custom mallocs in security-critical applications is to do exactly that - to zero all memory immediately upon freeing.

Zeroing memory like this is a common practice in such cases.

This is completely incorrect. Until it is freed (or realloc'ed), the address returned by malloc will point to the same data, regardless of whether it is in the L1 cache, RAM, or paged to disk. Were this not the case, each program would need to implement its own MMU.

Now, what is true is that additional copies of the data could be made, but you'd need to have escalated to root to access anything in a pagefile (at which point your system is completely compromised anyway), and I'm not even sure if direct access to L1 cache is possible.

The longer the data remains in memory, the wider the window to read it via some other exploit. (Also, anything running as root could potentially access it.) This is precisely what happened with Heartbleed.

People change fonts when the defaults don't suit them, and there is no one choice that will suit everyone. The logical conclusion of this is that you need to have some method by which people can change the setting, or your software will not be suitable for a significant number of people.

Sane defaults do not remove the need for configuration. Look at KDE - their defaults are perfectly fine for most people, but Plasma is /way/ more configurable than Gnome 3. This one-size-fits-all attitude is the primary reason people have responded poorly to Gnome 3.

False dichotomy much? Changing the font size should be a trivial task doable in under 5 minutes (including the time taken to Google it).
Furthermore, has it not occurred to you that people who use computers as extensions of themselves are actually the majority of Linux users? Minor changes that make our tools easier or more efficient to use are the norm for us. If we weren't interested in changing our tools, we wouldn't have installed Linux in the first place.
It's all well and good to target other demographics, but if you alienate your userbase and focus on a minority, then it should hardly be surprising when your users (and their funding) disappear.

I disagree. Spending hours tweaking conf files was the norm back in the 90s out of necessity, but the idea of customizing your tools to suit yourself is not specific to that era. I'm young enough to not remember most of the 90s and have used Linux for less than a decade, but I often spend time customizing my setup to suit myself better.

If they were using a custom malloc, then they should have been memset (or similar) to zero the blocks when debugging. That way, use-after-frees still manifest as crashes when testing (it could be disabled in release builds to improve performance).
I'm in no way an experienced C programmer, but if I were reimplementing something as core as malloc/free I would include a ton of sanity checks and safeguards to make sure that, at least on debug builds, this sort of bug was obvious.

There is also a third option: manual memory management with compile-time guarantees of safety. You get the performance of manual memory management without the risks, and the code ends up being more concise because heap allocation is implemented as a syntax feature. Rust is the most well known example of this.

Speaking as someone who has worked with both C++11 and C#, C# is a much nicer language. C++11 improves things somewhat, but it's an old language and the cruft shows. The obvious example is generics: C#'s generics are quite straightforward to use, support constraints (base classes of type parameters), and can even be annotated to handle inheritance correctly. C++'s templates are notorious for their poor usability, to the extent that even Stroustrup recognizes that they fall short. A future version of C++ is supposed to implement Concepts, which provide the ability to add arbitrary constraints to type parameters (but not by using inheritance*, for some reason.)

It's quite telling that even though I've been using Linux as my primary OS for a few years now, I still haven't found a language that's as pleasant to use on it as C# was under Windows. (Qt is much nicer than the .NET Framework though.)

*To be fair, inheritance has the problem that once a class is written, you can no longer add base classes to it. But this is not insurpassable; C# supports extension methods that could be used to fix this in a manner similar to Haskell's type classes.

It's funny you mention this, given that just a few days ago I struggled and eventually gave up on getting my laptop to pair with a Bluetooth ODB adapter that had previously paired with a different laptop. (In the end I gave up, took it apart, and soldered some wires directly to the serial interface inside it, as I had a USB UART adapter on hand).

The problem was that the device kept disconnecting after I connected to it, and there was nothing I could do to convince it otherwise. The more complex a technology is, the harder it is to get the interface right. This goes doubly when you have an embedded system without a second, more powerful interface (compare this to how Linux supplements the GUI with a terminal). Wearable devices take this to an extreme; the interface is more limited than that of a phone, so it's even harder to get right.

The same could be said about elegant code. :P