> Then there's plenty examples where a direct English equivalent exists even if it's not a literal translation of the original: nachäffen (de) = na-apen (nl) = mimicking (en), but English lacks the animal connotation (Affe == aap == ape)
I pretty much understood that line right away... it's not that different from the code I'm used to reading and writing (embedded, low-level stuff), which just shows that even within C alone there can be a huge range of style from APL-terse to mind-numbingly-Enterprise-Java verbose.
Shortest explanation: The sensor exposure time register has a maximum value.
Next shortest: But it's actually in units of row readout time, on many sensors, which is also configurable, so the exposure time can be made longer at the cost of slower image readout. In normal operation, readout has to happen at 30fps at least, so extra code is needed to switch to slower readout for extended exposure values. This code then needs validation, the image processing tuning tables need to be updated and verified for the new long exposure durations, and any preview glitches, etc, from resetting base sensor configurations need to be addressed. So a lot of extra work, for a relatively niche feature on a smartphone.
Even longer: Many sensors also have an external shutter trigger signal pin, for unlimited exposure duration. But that needs to be wired to the CPU, and all the SW considerations above also apply.
To first order, long exposures are probably less power-hungry - much of the sensor power is burned in the image readout, and longer exposures mean you're reading images less often.
When collecting light, an image sensor pixel isn't really using up any active power (each pixel is basically a capacitor collecting electrons generated by light hitting the silicon).
I don't believe this is entirely correct. DSLR sensors get very hot during long exposures - to the point where excessively long exposures can introduce noise into the output from this heat. I don't see why this wouldn't apply even more so to phone sensors, with their incredibly high photosite density.
However really long exposures are going to suffer from star trail effects - the earth is rotating relative to the stars, so a long exposure changes stars from a point to a short line, which _usually_ isn't what you want. On a 35mm camera with a fairly wide lens you can get away with ~ 30s of exposure time.
On a pixel phone I think you'd be able to get away with ~ 3s exposure time, but as it's going to get pretty hot over this time I'm not sure how much extra image quality you'd actually end up with.
You can select a size for a given font by hovering over it to reveal the size slider and other options (desktop version at least), and then applying the size to all.
The font size slider is incredibly annoying. There should at least be a field to manually input a size as well. Having fonts jump from 8px - 22px with no space between is useless.
With a lot of relevant new content (references to Arduinos, etc), which is great since the last edition was from 1989.
And while the basics of transistors, etc, haven't changed since then, it's arguable that the kinds of circuits that are of most relevance may have changed. (A/D conversion, general interfacing with digital logic, things that didn't have simple IC solutions in 89, etc).
Lady ada did an interview with Paul Horowitz (One of the authors) a couple of days ago [0] where he goes into detail of how the book came about and what's new in the 3rd edition,..etc.
I highly recommend someone take this generous offer. The book is very dense, but only because it is so beautifully concise. And you'll go quite far into the 2nd ed. before running into any anachronisms.
I learned from the 1st edition in ca. 1983, and I think it is one of the best textbooks ever written in any subject. It didn't hurt that the person teaching from the book was one of my best teachers too.
In my opinion "the art of electronics" is more of a hands-on book, that explains things qualitatively, and in an unstructured way; and thus it is quite different from any scientific textbook.
Eh, I mildly disagree on web site review. Perhaps not GitHub's pull request/review model, but big projects like Android and Chromium do all their review on web interfaces.
Using Gerrit, which is an automated mimick of Linus' development model.
By the way, we've been succesfully using Gerrit on smaller-scale projects as well (around 8 change-requests / day) and don't even want to think about going back to pull-requests.
What you've said is essentially correct, but I'd like to make a minor correction: Chromium uses rietveld whereas Android (and some Chromium related projects) use gerrit. Rietveld and gerrit have similar workflows except that gerrit is more integrated with git (I think). Both are named after Gerrit Rietveld, a famous Dutch designer.
As a minor correction, the N5 front camera is a LIMITED, not a LEGACY device.
It doesn't quite do the per-frame synchronized controls required for FULL like the main back-facing camera, but otherwise offers manual control and high-speed output.
That's absolutely correct, thank you for the correction :)
It's still LIMITED on 5.1, however it's possible to control ISO, white balance, shutter speed, set a custom color space conversion matrix which allows a lot of cool things for a font camera.
Curiously, it looks like Google's AOSP music app requests READ_PHONE_STATE but unless I'm missing something they don't use it - relying entirely on focus loss instead. Granted, I'm not sure anything actually uses this code now...
Which doesn't really help the users stuck on Android versions that never get any update or bugfixes. In which case apps have to take the pragmatic route and just work around the issue. Even if that requires a scary permission.
No user would point to Google and say »VLC doesn't pause when the phone rings, fix the ringer, please.«. Rather they point to VLC and say »VLC doesn't pause when the phone rings, fix VLC please.«
Split your APK based on SDK version. Have different manifests with different permissions & code for the respective versions. The new Gradle toolchain makes all of that easy to do, but it is tough to maintain lots of version specific code long term.
Even here, english has the term 'aping': https://www.google.com/search?q=define%3Aaping, with the same meaning and retains the same animal connotation.