No, it wasn't. If we go back to 3 and 4BSD, it was built with VAXes in mind; even if we only go back to {Free,Net}BSD (Open and DragonFly forked off from them), it was built with PeeCee's in mind.

And NeXTStEP/OS X were also originally designed for desktops.

Linux was also originally built with PeeCee's in mind.

So Windows, OS X, Linux, and *BSD were all originally built with personal computers in mind; all the power-saving stuff largely came later, as 1) notebook computers became more popular, 2) some of those OSes were taken into lower-power embedded systems, and 3) some of those OSes were taken into smaller mobile computers.

The young Alexander conquered India. Was he alone?

And then, because they didn't think about where the crust, basil, or anchovies came from, they get PC LOAD THIN rather than a pizza, and take the pizza printer out and smash it.

So, based on history, which ways of sorting such things out work better at preventing such things before people get sick or die?

Presumably you meant "very far right over recent decades" (see, for example, this Democratic president's 1949 State Of The Union speech).

Nope.

For one thing, Wireshark shouldn't be accessing the network interfaces, it should be asking the dumpcap program, which is one of the components of Wireshark, to do so. To quote Wireshark's README.packaging file:

WIRESHARK CONTAINS OVER TWO MILLION LINES OF SOURCE CODE. DO NOT RUN THEM AS ROOT.

For another thing, the README.packaging document (in the "Privileges" section, which contains that rather emphatic quote), and the CaptureSetup/CapturePrivileges page in the Wireshark Wiki, discuss ways in which you can avoid even running dumpcap as root - it may need additional privileges, but not full root privileges.

Nope. See the above documents and the main libpcap man page (following "Reading packets from a network interface may require that you have special privileges:"). That's what the ChmodBPF script installed by Wireshark on OS X does; see the "Under BSD (this includes Mac OS X)" section - it does the "some other way to make that happen at boot time".

Presumably he had to answer to the Coca-Cola company for that?

Newer versions of Qt support 64-bit programs, so they don't run atop Carbon.

Well, I looked it up, and there are no chmod or chown calls in the Wireshark source (trunk, 1.10, or 1.8), and there are no obvious pages found by Teh Google about this.

Citation (and, no, "look it up" isn't a citation, it's a trick used by people who don't actually have citations) or it didn't happen.

Fortunately, yes, you are wrong. Digia bought the business side of Qt from Nokia in 2012. The free-software side of Qt is the Qt Project.

It will make it an app that doesn't use X11 on OS X.

It won't make it an all-Cocoa app (although it will, modulo issues with QtMacExtras, use the native toolbar widget, at least, and, time permitting, it'll use the native file dialog sheets rather than the definitely-doesn't-look-like-OS-X Qt file dialog).

It won't be sufficient to make it an app following the OS X "one process for all open windows" model; that would require, for example, replacing all the static variables holding dissection state with per-open-file variables (doable, but a fair bit of work). Whether that will be done for 1.12 is another question.

Had the Guardian not complied, I suppose David Cameron's response would have been "I thought they were guilty, but when they refused to voluntarily cooperate with my national security adviser and cabinet secretary, I started to reconsider."

No? But if not, then he is just trying to rationalize some "damned if you do, damned if you don't" nonsense.

Presumably you either mean "the Linux kernels I've run on my machines are more stable than the Linux kernel running on that particular Android machine" or "KDE and the rest of the userland is less likely to provoke a kernel panic than the Android userland".

I don't know what you mean by "They are merging [their] software development kits", but, as far as I know, there are still separate iOS and OS X SDKs.

They might port the parts of Darwin not present in iOS to ARM (where "port" largely means "compile for and fix what, if anything, breaks"), and port the not-already-shared parts above Darwin (e.g., AppKit - Foundation is already shared), with the same meaning of "port", but that's not convergence.

...the result of which would be a Mac, running OS X (not iOS), with an ARM processor. Merging iOS and OS X has nothing to do with making an ARM-based Mac.

No, and not Shuttleworth, either, so his claim about what Apple will do is worth about as much as all the various random bloggers/columnists also saying "oh, yeah, iOS and OS X will become the same OS some day", i.e., it's worth nothing. Maybe they will, but there's no concrete evidence that they will.