No, disable potentially user-positive and potentially user-harmful features unless the user approves on a dialog containing suitably-scary text so they will stop and think about whether or not they trust this extension that they're giving control over and visibility into all of their browsing.

It's fine to actively prompt; no need to require users to go searching for the setting. But it's important to give users the control, so drive-by extension installs (like Superfish) don't assume it for them.

Actually, they recommend browsers disable those capabilities unless the user consents to enabling them.

Reading comprehension fail. The summary says:

I'd expect that most users who install ad blockers consent to having it modifying the browser environment.

You asked and I answered. FYI, I've been driving a Nissan LEAF for the last three years, in the mountains of Colorado and Utah. It gets cold here. Car works just fine.

There's absolutely no problem with charging an electric car outdoors in the rain.

They work just fine. Range suffers a bit because you use part of your charge for heating, but everything functions fine.

What is an NEV? I get the EV part, but not the N.

I can see you're a young'un. Borland didn't make "compilers for Windows shareware developers", Borland was the dominant maker of high-quality Pascal, C, and C++ development tools for the PC platform for many years, for DOS and Windows, especially DOS. Borland's overlay manager was fantastic and made large DOS programs (programs that used more than 640K) very easy. Microsoft eventually managed to shove them out, but Borland was by far the better tool set for years, and was the choice of many professional development shops. It's what the software companies I worked for in the early to mid-90s used.

I think what eventually did them in was their decision to try to offer a better Windows API than that mess that was MFC. Borland's Object Windows Library was orders of magnitude cleaner and better thought-out than MFC, but because they had to wait for each release of Windows before they could update it, it lagged behind MFC in functionality. Probably also because the OWL team took the time to think about how to do things right, rather than just slapping a thin pseudo-OO wrapper on the Win32 API, which was MFC's approach. So Windows devs learned that if you wanted to stay current, you needed to use MFC, hence you may as well use Microsoft's whole tool set, since you had to buy it all (several hundred dollars).

These day's Duff's Device is almost always premature optimization, because compilers will unroll most loops for you. You should only use it after profiling to prove that the loop is a hot spot, and after benchmarking to prove that it actually improves performance. Even then you should include both implementations, selecting one by #ifdef, so you can periodically re-test, because eventually a new platform or new compiler or something will result in it no longer making a difference, or even being more expensive, if the compiler is cleverer than you.

Depends on the sort of code. There is lots of code that needs to handle, for example, large classes of error codes, and for 50 codes there may be only two or three sensible ways to handle them. Being able to have big lists of cases that nearly all fall through is very nice then.

The solution to that sort of optimization is to delegate it to drivers. And providing and debugging drivers is a big part of what OEMs have to do (actually, the drivers are provided by the hardware vendors -- OEMs don't make the bits and pieces, they put them together -- but generally as source code and OEMs tweak and fix).

Your notion of "optimizing for the hardware" is something that isn't real. According to your theory, Linux also shouldn't perform well because it also is hardware-agnostic.

As for what OEMs have to do, a modern mobile device is immensely complex, consisting of dozens of processors, many on the SoC (system on a chip) but many not. All of them have to be configured, which is a complex and tedious operation, and easy to get wrong -- and every custom board requires a custom configuration. In addition, there are drivers for all of the bits and pieces that have to be assembled and tested together. Plus there's also typically a complex, multi-stage boot process that has to be orchestrated to bring up all the bits and pieces of the hardware in the right way and in the right order. And other stuff that I don't know about because I'm not a hardware systems guy.

Some of the above doesn't depend on the OS, and can be done before it's available. But much of it does depend on OS requirements and has to wait.

And then if the OEM decides to customize Android they have to do that, with whatever skin, and default apps they want, plus whatever changes they need deep in the system to support the hardware and their changes to the software. Finally there is lots and lots of testing, because such complex, custom devices always expose new interactions between components that have to be debugged and fixed. Oh, and lots of hardware testing as well, including endless burn-in tests to validate that the stuff not only works but that some subtle design flaw doesn't stop it from working.

And I'm sure there's still more that I don't know about at that level as well.

Then they have to run Google's compliance tests, to find out what they've broken with all of their changes, or what they missed in configuring their device for proper support (actually, this is something they do throughout, not at the end), and then go back and fix what's broken until it passes... or else negotiate with Google for waivers on things they think should be okay.

Then comes carrier validation and testing, more rounds of fixes, etc.

Little or none of this has anything to do with "optimization". That's mostly the compiler's job, and it does that job well.

Per Wikipedia, Microsoft licensed System 7 from AT&T and called it Xenix because AT&T wasn't licensing the UNIX name.

And I didn't "come at you". I thought the second sentence of my second paragraph made that clear. Sorry if it wasn't.

Er, nothing actually. TFA mentioned "Microsoft's take on Unix", which I took to mean NT's stab at POSIX support, or maybe something else equally ridiculous. Looking at the article again, it actually says "Xenix, Microsoft's take on Unix". Not being more than vaguely aware of Xenix, I didn't realize it was bought by Microsoft and I took that text as two separate items in the list (should have paid closer attention to commas vs semi-colons).

Indeed. There I claim selective memory, driven by the massive stain on the Unix world left by SCO's successor-in-ownership, The SCO Group.

I heard good things about Coherent back in the day, but never touched it.