Vi's key feature was composability (you could use same motions with any action), and Emac's key feature was plugins.
Today, Vim has plenty of plugins (I have 48 in my vimrc as of yesterday), and Emacs ... is just as (not) composable as it was before, AFAICT.
Vim won the way, but it became the enemy in the process.

Install apt-listchanges, and you can see the entire changelog.

I'm curious why you think that neither is better than the other.
I'm not familiar with Pascal, but as I understand it:
C strings are a series of characters, followed by a null terminator.
Pascal strings are a series of characters, prefixed by their length. If the implementation uses more than one word/byte to store the length, then you aren't limited to 255 characters.
Given how many security problems there have been in C programs due to incorrect handling of strings, the Pascal approach seems much safer (at the cost of a few additional bytes of memory per string, but I suspect each character is stored in its own word anyway for performance reasons).

The C++/D implementation seems to be the best so far though, since storing the length of the string with the pointer enables creation of substrings in constant time.

I'll second this. C# is a beautiful language with a terrible execution. Java is a terrible language with a much better execution (at least it has closures now...).

Having found myself in the same situation, you might want to take a look at D. It has very similar syntax to C#, but works just as well under Linux as Windows.

Being too configurable isn't a problem - needing to configure it is. Debian is about as configurable as Arch, but is significantly easier to use because it comes with a default configuration. You pick the most popular distro (Mint, according to distrowatch) and use whatever it comes with. Knowing how to customize it to suit you is something you learn over time, and is also completely unnecessary at the start of the learning curve.

The whole point of a distro is to make those choices for the user, while enabling varying degrees of customization. Choose the most popular distro, and you'll be fine.

I'm not the GP, but I thought I'd bite.
tldr; It's not perfect, but it's closer than you'd think.

DMD, LDC and GDC (the 3 most popular D compilers) work fine on x86 and x86_64.
LDC supports ARM and PowerPC with some issues. GDC apparently has better support for ARM

D has very good interop support for C and C++ libraries. There's a significant number of wrapper libraries in dub as well.
In general, C code can be used as is, while C++ libraries often need a wrapper to work around issues like templates.

Yes, C compilers exist for pretty much every architecture in existence, with C++ supported on most of them.
But this is a red herring, because the only instruction sets that really matter to someone in game development are x86, x86_64 and ARM. Whether or not you can compile your code for PIC is completely irrelevant. (That said, LDC uses LLVM for its backend, so it probably has the best chance of supporting unusual architectures.)

Backward compatibility is always an issue with any piece of software. That said, I think there's something to be said for handling breaking changes well as opposed to handling them poorly - anything which creates a rift in the community is obviously an example of the latter.
Python was an example of the that, since it wasn't possible to combine code from old and new versions. While D had a breaking change with D2, there is only one person I am aware of who is still using D1. The standard library from D1 (Tango) was ported to D2, and the syntactic changes were fairly minor and easily remedied.
It's also worth noting that the D1 branch of DMD is still maintained, should you actually need to compile D1 code.

Pretty much every language is going to accumulate cruft over time. Even if D accumulates it at the same rate C++ did, it's relative youth means that it will be much more pleasant to work with, since C++ will always have more. I think the only real way to completely remove all that cruft is to create an entirely new language - no one would have complained about Python 3 if it were marketed as a new language, rather than as a new version with breaking changes (Nimrod is an example of this). This is what D is to C++ - a language with equivalent power that wipes the slate clean.

To put it simply, Kolab is a FOSS equivalent to Exchange. On the client side you can use Roundcube (a web UI), KDE Kontact, or anything supporting the IMAP-based protocol. It also supports ActiveSync for use with Android.

I set up Kolab 3.2 on a Debian a while back because I wanted a centralised calendar, etc. that didn't require me to trust Google with my life. It's worked pretty well, apart from a few issues. Configuration is a little tricky, especially as SSL is not the default and there are three different places it needs to be enabled. There are some minor bugs and instabilities, though hopefully they have been fixed in 3.3. Synchronization between the roundcube and IMAP clients can also be a little unreliable.

If anyone has any questions about it, I'll be happy to answer them.

KDE Kontact is probably the best FOSS alternative to Outlook - it has email, calendar, contacts, todo lists, RSS feeds, newsgroups, etc.
There's a bunch of free alternatives to Exchange as well, though I'm less familiar with those.

I disagree. D has feature parity with C++, but is significantly simpler and easier to learn. (This is supported by the fact that their eponymous books, The C++ Programming Language and the D Programming Language, are 1368 and 460 pages respectively.)
C++'s complexity arises from a combination of legacy features and inconsistency.
For example, it has two different kinds of enums - plain/C-style enums and enum classes. Enum classes were created because adding scoping to existing enums would have been a breaking change.
Inconsistency can be seen in things like the runtime initialization rules, where the contents of int x[10]; is uninitialized, but the contents of vector y(10) are initialized to zero.
Essentially, poor decisions were made in the long history of C++, and while it's easy to say that hindsight is 20-20, the reality is that those bad decisions are constraining the direction the language is taking and increasing its complexity.

There is an excellent talk here by Scott Meyers discussing how inconsistent C++ is. These inconsistencies are responsible for the vast majority of the unnecessary complexity in the language.

'The C++ Programming Language' refers to plain enums, enum classes, and unnamed enums. Unnamed enums are just anonymous plain enums stored as integers though, so it's arguable whether or not they count a third type or not.

What's not to love about a language with 3 different types of enums?

Agreed. But SSL is about encryption - authentication is merely an optional extra (if it weren't, self-signed certs wouldn't even be an option).
No intelligent person trusts the majority of websites, but they may still have valid reasons for not wanting their browsing habits eavesdropped upon.

That depends on your priorities - on whether authentication or privacy is more important to you. Quite frankly, I find it hard to understand how encryption without authentication is worse than no authentication at all.

Frankly, this is a usability problem. A user should not receive dire warnings for a self-signed cert; they should get some indication that it's inferior to a trusted cert, but that's it. (I like the red-yellow-green approach Chrome takes with the address bar.)
Dire warnings should be reserved for when a website's cert changes significantly, because that's the best indicator of malicious activity. Using them for self-signed certs just raises the false positive rate.

Cheap is relative. But more importantly, consider the implications of this. The web is slowly moving towards deprecating the use of unencrypted HTTP. Sure, it won't happen immediately, but it's going to happen sooner or later, especially given the way the IETF responded to the Snowden leaks. Meanwhile, CAs stand poised to charge an annual fee to anyone who doesn't want their site to be decorated by scary warnings. Stuff like this centralizes the internet and makes it more fragile and prone to interference by a single party. We need to be looking at more decentralized options, and making self-signed certs a viable choice is a good start to that.

So far all Google has said is that they will boost sites which use HTTPS - as far as I can tell, they haven't said anything about requiring the use of a trusted CA.
Self-signed certs are free, and just as (if not more) effective than the paid ones if your goal is to prevent eavesdropping and not to verify the identity of an unknown server. (Known servers can be reasonably expected to use the same certificate as last time, or at least the same CA).

Given that the centralised CA model seems to have largely failed, not to mention how likely it is that this is being driven by the Snowden revelations, I wouldn't be surprised if this was the approach Google took.

My understanding is that Python's two biggest issues are a lack of static typing (justifiable, but annoying) and the ability to use arbitrary objects as dictionaries. The latter causes significant issues when trying to optimize code, because something as simple as reading a value from a property becomes a hashtable lookup.

I don't believe C# will ever flourish outside of Windows, unless Microsoft starts supporting it on non-Windows platforms. Mono has had a lukewarm reception, and in my experience isn't as solid/reliable as .NET.

D on the otherhand, has similar syntax and is much more portable. I can easily see it overtaking C# if it gets some proper corporate support behind it...