So use a different GUI library. WPF is pretty bad even when compared to WinForms. The Qt libraries are cross-platform, have existing bindings for C#, and are an absolute pleasure to work with. IMO, they blow the pants of WPF.

The value in Microsoft open sourcing .NET isn't in running existing Windows programs under Linux - they probably wouldn't work without WINE anyway, due to P/Invoke calls or lazy programming like concatenating backslashes instead of using Path.Combine(). The value is in being able to use C# to write new, cross-platform programs. And while Mono did have implementations of them, they didn't necessarily work the same way. I gave up on it completely after a particularly annoying bug prevented .NET binaries from running as a less privileged user.

C# is an excellent language, and arguably the best-positioned language in its niche - C++ has too much cruft, Java is struggling to catch up (and seems to lack a decent GUI library), D's userbase and funding is close to non-existent, and Objective-C/Swift aren't used outside of Macs. All the other languages are too immature, or lack the requisite feature set, to be competitors.

FTFY.

(This is a direct reference to the "on a computer" patents, for the humour impaired.)

Why on earth would you want a 96-bit CPU? Even the current 64-bit ones can 'only' address 48-bits of memory (i.e. 281 TB).
And if you want it for a certain computationally expensive load, 128-bit would make more sense (or just doing the computation over 2 -bit words).

The main advantage of Github, etc. isn't the hosting - you can use any SSH-capable server for that. It's in the issue tracking and other built-in features.
That means it makes more sense to have your backup server pull updates from Github, since it can't provide that.

Of course, an even better approach would be to use an alternative like Gitorious (now Gitlab?) that allows you to host it yourself, so you don't lose access to anything if your primary hosting goes down...

The problem I see with this is that it would give corporations power over the employees they have educated. No business would pay to have an employee educated if there was a chance they'd leave immediately after, so they'd either require them to stay with the company for N years, or make the entire debt repayable the moment they quit.

There also seems to be the implicit assumption that there will be enough jobs available for the entire population. I don't know how true that will be in the future, or if it's even true now...

There's a difference between elapsed time locally and globally. Locally (i.e. on a single processor), you can have some meaningful concept of absolute time (i.e. whenever the timer interrupt fires). The moment you introduce a second processor, you run into issues where they can be ticking at different rates, and the non-trivial delay in communications between them means that you can't ever hope to synchronize them to the extent you can assume they are the same.

For most applications, you can get away with fairly large tolerances. e.g. wifi is probably fine with 1% variations in your concept of how long a second is. But that only works because you're using local elapsed time. If you need to compare timestamps from multiple nodes (global absolute time), you need to use approaches like vector clocks, because otherwise there's no meaningful way to reason about whether two events happened before each other.

tldr; protocols like wifi just need elapsed time to be roughly correct. Comparing timestamps between systems is much, much more complicated, and you can't even infer an ordering for the general case without casuality. (In that sense, there are a lot of parallels with relativity.)

I think is simultaneously the best thing and the second biggest issue[1] about Kolab - it's a very powerful piece of software targeted at sysadmins. You can setup some very complex, enterprise grade configurations with it, but to do that you need to be willing to muck around with postfix, etc. By that same note, you need to have at least basic familiarity with postfix, apache, cyrus, etc. to actually set it up in the first place, which sets the bar fairly high. (I think it took me a week of practicing in a VM before I was ready to do a proper deployment on my home server.)

[1] The biggest issue would be its general bugginess. e.g. This bug affects anyone with an apostrophe in their name, but went untouched for over a year, despite a patch being included in the original submission.

I've been using it for little over a year (for the same reason as you - didn't want to put too much info into Google), and would describe it as half-decent. I use it as a diary, essentially - schedule, calender, todo list, etc. I still use Gmail for actual email though, because unless you own the domain outright (i.e. not a subdomain) you can trigger false positives for spam on other servers that results in you mail being dropped.

Pros:
-open source
-free (gratis)
-works

Cons:
-pain to setup - the target audience is sysadmins, so you really need to practice doing it in a VM first (especially since doing a complete uninstall is non-trivial)
-buggy - every time I've upgraded to a new version, I've run into a significant bug. (Inability to handle apostrophes in names, buggy apache module that keeps crashing the server, etc.) You can usually fix it if you know PHP/Python, but it's still a pain that makes for a poor user experience. (I've submitted bug reports with patches for these, but not all of them have been merged.)

Basically, it does take a lot of effort to get it working (I have 500 lines of notes on it), but once you've done that it will keep working pretty reliably. The official client is KDE Kontact, which works great for me since I use Linux anyway. I can see it working out poorly if your OS is Windows though (KDE for Windows isn't stable yet). It syncs well with Android too. I generally prefer to enter important events, etc. in through the webui though, since I don't quite trust the other clients to sync them properly.

tldr; it's probably the most broken piece of software I've used under Linux, but it works well enough that I continue to do so. I wouldn't recommend it for anything important (e.g. actual business use), but it's fine for non-critical personal use.

Actually, it's an email server, except it's not just email - there's also contacts, calendars, to do lists, etc. It's basically a direct competitor to Microsoft Exchange, but with a FOSS stack. I have it installed on my home server, and it works pretty well.

According to their website (or at least, the Australian version), you get the choice of Win7 or Win8.

As for Linux support, it seems that the mouse buttons don't work. Apparently there's a patch for the kernel which will be included in the next release.

From a user's perspective, if a device doesn't work with Linux, the OS is broken, but if a device doesn't work with Windows, then the device is broken. It's not fair, but that's the reality we operate in.

I suspect you are the one in need of education. https://www.youtube.com/watch?...

Linus isn't going anywhere. The code of conflict basically says "Your code will be criticized, deal with it. If you're subject to personal attacks, here's where you can complain." Note that Linus' infamous rants have always been direct criticisms of the code, so he won't be affected by this. The code doesn't promise anything more than "[resolution] of the issue to the best of their ability".

That only works if they're the only developer in the project. The moment you have more than one, there needs to be communication between them. This is compounded by the fact that nobody writes perfect code, so eventually that good code does need to be revised, and an arsehole who refuses to recognize the validity of other perspectives is an obstacle to that, especially if the reason it needs to be revised is that there is a core design fault.

I used it for a bit a while ago (0.9). It's a pretty nice alternative to C, but needing to explicitly deal with object lifetimes made it a bit too painful to be used as a high level language, which is a little ironic given the significant influence of Haskell in its design. There are ref counted pointers, but last I checked the syntax for them was pretty clunky. (An earlier version used a dedicated operator for them, but that got obsoleted. It's a shame, since that would have made it more usable as a high level language, similar to D.)

Python has enums as of 3.4, though namedtuple._make() seems to resemble Haskell records more than a C-style enum.