I'll second this. I got a paid subscription to them after the picked up a kernel performance regression bug that no one else had noticed. They also regularly do file system benchmarks, which are really useful if you're interested in that.

C# is now 14 years old - I highly doubt it can be considered fly-by-night at this point. Not to mention Swift doesn't even achieve feature parity with it - it lacks C#'s variant generics and list comprehensions (which seem to be combined with lazy evaluation and called LINQ in C#).

My underlying point is, why create a new language? It's justifiable if you're actually trying to add new features or paradigms (e.g. Rust was created so that memory safety could be enforced at compile-time), but otherwise it's just change for the sake of change. It would make more sense to adopt the syntax of an existing language (e.g. Java, C#, C++, etc.) so as to leverage existing users of those languages, rather than requiring them to relearn the semantics. If you need to replace Objective-C, why create a whole new language when there are plenty of perfectly good ones already?

Quite frankly, it looks like a poor man's C#, with some Haskellisms (tuples, -> syntax) thrown in for good measure. I'm sure it's better than Objective C, but it's nowhere near competitive with any of the other recent languages. e.g. Rust*

* I think Rust is a long way from perfect and has a myopic focus on low-level coding where manual memory management matters, but at least they're doing something interesting.

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.