Understanding those algorithms is still important, though, even if you're just using the available APIs. I know that depending on what framework I pick, the API's sort function will either be an implementation of quicksort, quicksort with an optimization to prevent worst case performance on presorted data, mergesort or (rarely) a handful of others. In many cases it is important to know which one is being used. Is resorting an already sorted list going to give me poor performance? Will elements that compare equal be maintained in order or would they be psuedorandomly transposed? If I know the details of common sorting algorithms I can tell this at a glance, and can easily remember which applies to which framework. If I don't know the details, I'll have to dig into documentation (or, quite frequently, stack overflow questions) to find the answers, which will take much longer.

And the other thing that CS teaches is that there are alternative approaches: why are you using a sort function, when you could be keeping your data in a tree structure instead?

Right. Local machine is the admin's desktop, running the X server, and the remote machine is the network server, running the X clients. I don't see the problem with this setup. It doesn't leave the server running X, and there's no security implications because you need to be able to connect to the server via ssh to get anything to work.

No. It degrades over time for entirely different reasons. But it *does* degrade over time. There's plenty of software I used to use which I now cannot for various reasons (e.g. contains known unpatched vulnerabilities; not compatible with modern hardware; suffers from Y2K-related bugs; depends on operating systems that contain known unpatched vulnerabilities; depends on operating systems that are not compatible with modern hardware). Were it open source, I doubt this would have happened.

The latest set of Microsoft security patches fix a vulnerability that could plausibly be exploited to remotely execute code and which has affected all versions of Internet Explorer since 6.0. This probably has significantly worse impact than Heartbleed did, and is such a regular occurrence that nobody has bothered pointing it out for special attention. Heartbleed was news simply because we expect open source to do better.

Heartbleed was a subtle bug that was fixed after 2 years and 1 month of being in the release branch of openssl. Looking at the "critical" and "important" bugs in the latest round of Windows patches, I see one that has been open since IE6 was released (13 years), one for windows 8 (21 months), OneNote 2007 SP3 (35 months), SQL Server 2008 SP3 (35 months), Windows 2003 (11 years) x2, SharePoint Server 2013 (18 months), and .NET Framework 2.0SP2 (5 years).

It looks to me like open source is working just fine here; Hearthbleed appears to have been fixed much faster than an average important security flaw in a closed source package.

Yes, but for some reason I find hard to fathom it attracts attention away from other products that would be just as good at fulfilling the same goals and *are* completely open. I have no doubt that if, say, Olimex's OLinuxIno sold in similar quantities to the RPi it would be available at about the same price, rather than a slightly higher for a much better board, as it is currently.

I'm personally a fan of Olimex's boards. They're open hardware, and tend to have superior boards to the RPi at only slightly higher prices. E.g. their entry level board (details here) is £28 versus about £20 for a RPi model A. It has a much faster processor (1GHz superscalar Cortex A8 vs 700MHz previous-generation single-dispatch ARM11, so probably about twice as fast), more GPIOs (74 pins vs RPi's 26), USB-OTG, audio-in, RTC, plus uses a processor that does not rely on an undocumented proprietary DSP to boot. And did I mention it's open hardware, so you could build your own if wanted to?

$6 is very high for renting a movie. I can rent a physical copy locally for $3-$5, depending on how new the title is, or I could get a netflix subscription for less than $10 per month (as I watch about 5-10 movies per month, this works out at $1-$2 each).

Nonsense. It might do so rarely, but there are many documented cases in military history of men being sentenced to 1,000 lashes or more and surviving. Permanent disablement was an expected outcome of such a sentence, but not usually death. In a recent case of a teenage girl sentenced to 100 lashes in the Maldives, Amnesty International described the likely outcome as "long-term psychological as well as physical scars". I would imagine they had an expert on the subject make this assessment.

I find my lack of mod points disturbing.

Yes. Most developers I've worked with pay an awful lot more attention to the code than to the documentation. It may not be desirable, but it's what happens in almost all cases. I know I'm guilty of it at times, even though I try not to be. If I see a problem with the code, I'll refactor it. Problems with documentation, (1) I'm less likely to notice them and (2) I'm less likely to actually fix them if I do notice them.

Who said anything is widespread? The disclosure being requested here affects less than 1% of the airbnb service providers in NY. If only 1% of them are "shady" you'd be highly unlikely to have seen them unless you used the service a lot.

Do you have a BluRay player? A DVB-based set-top box or a TV with integrated DVB decoder? Either of these would typically include a JVM.

When running on X11, Java's default UI is based on the motif toolkit, which is the same toolkit that CDE was based on, so the answer to your question is "indirectly".

You can also pass any object that happens to have attributes that have been coincidentally named the same but don't necessarily have the same semantics, and wait for the entire system to blow up (which it may or may not do in simple test cases, depending on how closely the semantics happen to match).

In reality, I don't find that unrelated classes tend to have methods or properties that share both a name and exactly the same semantic definition except where that similarity is intentional. When it is intentional, then usually the two classes will share an explicitly defined interface. On rare occasions they do not, it is trivial to write a wrapper for the objects, and the necessity of doing so is a good prompt to think about whether the definitions are in fact exactly the same.