Not even within a VM? OS X hosts those just fine...

If they want to arrange their own blackjack and hookers, they're free to do so. It's Open Source.

I really doubt that that's it. I think you've let the tinfoil slip over your eyes a bit too far, and you've lost sight of reality there.

That's not special to the USA. I have some numbers set to auto-block with very good reason. It's significantly less annoying in Europe though, as the caller pays the cost of the call (except in exceptional circumstances, which robocalls don't count as).

That's what the FCC needs to crack down on. The easiest way would probably to have a rule change that makes the phone companies part liable for any court-imposed liabilities arising from private actions over robocalls where those robocalls come from a spoofed number. That'll encourage the phone companies to sort out the problem very rapidly indeed, perhaps by making it significantly more difficult for phone users to supply the phone number in the first place. I know this will be inconvenient for some PBX operators, but mechanisms that are too easy to abuse need revision anyway.

That isn't really true. There are specific rights that you can't give up. You can't, for example, submit to assault except in limited circumstances (e.g. surgery). But, in general, you can contract away all sorts of rights. Lots of contracts require disputes to be settled by arbitration, for example, which forces you to vie up your right to go to court. Such contracts are, in general, valid and enforced.

Some people do not live near a Fry's.

Google's current effort is nothing like the Star Trek Universal Translator, and it is exceedingly unlikely that anything ever will be. The STUT is supposed to be able to translate languages that it has not been programmed to translate and has never been exposed to before. Existing translators, including Google's, can only work with languages that they already know.

Nothing much ensures that the data is complete or correct now either, other than peer review over a long period of time by people who are wholly unconnected with the original work (and its funding). In fact, in some sciences you're not going to get complete data in a public venue anyway (some sciences work with data that in raw form can identify individual people; think medical research). Correctness is hard to evaluate; what does it even mean for raw data in the first place?

But keeping versioned data does help with some types of analysis, such as working out whether a scientist's hypothesis was reasonable based on what data was available at the time, and whether that hypothesis still holds water or when it ceased to be good. It also makes it much easier to detect fraud, and you can use all the sorts of concepts developed for distributed source code management to make it all more comprehensible.

Don't think "wikipedia for scientific data", think "github for scientific data". That's a much better model.

As opposed to what? Saving state by tattooing it on a hairy fairy's derriere? If you're saving state, so that you can shut down an IDE and start it up again in the sam place, it's going to be saved to disk somewhere, and the chance that it's going to be in a file when its going to disk is enormously high. (Technically you could also store it in a DB that is written to a raw partition, but I'm not aware of anyone mad enough to use a full installation of Oracle on dedicated storage devices just to save the state of their IDE...)

Am I right in saying that the marks of a message passing solution are that it can handle "calls" of arbitrary methods and that the class/object itself can control what happens in that case?

That's largely a crock of shit and C++ programmers are just kidding themselves. The only two paradigms that C++ really implements are OO (for structural organisation) and imperative (for operation description). It's not functional in any meaningful way (it's possible to pretend, but it feels very strange if you do) and declarative programming is rather different. The only declarative language that most programmers normally encounter is SQL.

My point was that there's no real reason why OO can't be used with functional programming, or declarative programming. It just tends to be paired up with imperative programming for historical reasons.

I forgot the term. Oh well.

That's because most OO languages are also procedural programming languages (for historical reasons). OO is principally about how to organise data and the operations on it, which is orthogonal to whether the operations are sequences of commands or composite functions to be applied.

And the problem with OpenSSL is that they start out from the position "this is complicated" and then go straight to "so Joe Working Programmer should deal with all the complexity themselves" without properly spelling this out in very clear letters in a large font. That's abysmally awful. It leaves people exposed to trouble without them realising that this so.

If you're introducing strange hacks, it's probably a sign that the design of some of the rest of the code (being charitable here!) is wrong in the first place. Writing the code to be more portable, to use fewer quirks (ideally none), that's the way to go. Yes, it can make things long-winded, but it's worth it.

A good start is to have some sort of test suite. When implementing a spec, TDD is very much the way to go. You should also try to make sure you've got tests for all the failure modes that you expect (including all the ones in the spec). Yes, that can be devilishly hard. Do it anyway.

That's the important part. Don't start mucking around with low-level assembly for things until you've proven that you've got a problem and that the fix you're proposing to work on is worthwhile. (Where a library gets very widely distributed, such as a basic math library, it may well become worthwhile very quickly. Most code doesn't get anything like that level of distribution.)