I have verified that Requests, which uses us, appears to have its own handling, back at least to requests 2.0 (released in 2013) that prevents this when used directly as an abstraction layer on top of urllib3.

The largest consumer application of this is DRM - modern UHD Blu-Ray playback on a PC requires a fully SGX-enabled backend; the negotiation to obtain playback keys and the decryption of the on-disc content is done in the SGX enclave.

Yes. Every Python object is held by the interpreter as a pointer to a PyObject struct on the (C) heap.

Essentially, almost all digital cameras today use a planar CMOS sensor with alternating RGB-sensitive pixels, arrayed like so:

    RGRGRGRG
    GBGBGBGB
    RGRGRGRG
    GBGBGBGB

In other words, "the luma information we gather for a given color on a pixel of that color is immediately relevant to the effective pixel composed by it and its adjacent neighbors at each of its four corners". In this 8x8 Bayer pattern pixel grid with 64 real pixels, we get 49 effective chroma pixels; one for each intersection of 4 physical pixels.

In comparison, here's the pattern for "Quad Bayer":

    RRGGRRGG
    RRGGRRGG
    GGBBGGBB
    GGBBGGBB

In comparison, as far as I can tell, a single "effective pixel" (one with information on all three channels) using the Quad Bayer pattern has to be made up of data from nine individual pixels. Additionally, when an effective pixel is centered on an actual pixel with either red or blue filters, that color is relatively dominant in the pixels considered - it'll be equally weighted with the green channel, and the opposing color will only make up 1/9 of the total signal composing that effective pixel. Effective pixels centered on green pixels will give equal weight to red and blue, with slightly over 5/9 of the weight given to the green channel.

Granted, the sensor should still be able to produce a full 48MP of luma resolution, but chroma detail will be much more "smeared" because of the wide area that has to be considered to get a full color pixel, and the more substantial overlap of that full color pixel with other full color pixels. Color accuracy will likely also be lower, because in effective pixels centered on red and blue pixels, only a single pixel of the opposing color will be used, which means that any noise in that channel will have an outsized impact on the overall color.

What this boils down to is that, when used as a 48MP sensor, this sensor will have entirely different imaging characteristics than a traditional Bayer imager, and that those characteristics will be highly dependent on how the output of this sensor is processed - which will be interesting in a world full of software highly optimized to demosaic Bayer-pattern images.

What's slightly more interesting is the high-sensitivity 12MP mode. Essentially, it's an attempt to reduce the impact of random noise in the image by adding together four pixels of each channel to produce a "superpixel" less impacted by noise overall. These superpixels can then be processed in a standard Bayer pattern as a 12MP effective image.

Thinking about it overall, though, I become more and more confused. In both of these modes, this pattern doesn't give us anything, really, that we can't already do using a Bayer filter.

Let B represent a sensor using a standard Bayer filter pattern, and let Q represent a sensor using this "Quad Bayer" pattern, where each of these patterns have a red pixel in the top-left corner.

Let any given effective pixel be represented by a 3-tuple of the form (R, G, B), where R, G, and B are the number of physical pixels sensitive to each of the red, green, and blue channels which compose that effective pixel.

Let f(p, w, h, s, i) be a function returning a two-dimensional matrix of all the effective pixels produced by a matrix of physical RGB pixels, laid out in pattern p, with actual pixel width and height w and h, where an effective pixel measures s actual pixels horizontally and vertically, and where an offset of i actual pixels in either vertical or horizontal directions produces the "next" pixel in that direction.

Thus, our standard Bayer pattern produces the following:

    f(B, 4, 4, 2, 1) =>
    (
        ((1,2,1),(1,2,1),(1,2,1)),
        ((1,2,1),(1,2,1),(1,2,1)),
        ((1,2,1),(1,2,1),(1,2,1))
    )

    f(Q, 4, 4, 3, 1) =>
    (
        ((4,4,1),(2,5,2)),
        ((2,5,2),(1,4,4))
    )

You can also see that each effective pixel is composed of a larger number of physical pixels - there's a tradeoff there, in that this means that overall, noise should have a smaller impact on the value of a given pixel, but there's a loss of resolution because those pixels are spread over a wider area.

This raises the question, "what if we do a 9-pixel effective pixel on a standard Bayer pattern?" Well, we get this:

    f(B, 4, 4, 3, 1) =>
    (
        ((4,4,1),(2,5,2)),
        ((2,5,2),(1,4,4))
    )

What if we do the high-sensitivity superpixel sampling? For the Quad Bayer pattern, it looks like this:

    f(Q, 8, 8, 4, 2) =>
    (
        ((4,8,4),(4,8,4),(4,8,4)),
        ((4,8,4),(4,8,4),(4,8,4)),
        ((4,8,4),(4,8,4),(4,8,4))
    )

    f(B, 8, 8, 4, 2) =>
    (
        ((4,8,4),(4,8,4),(4,8,4)),
        ((4,8,4),(4,8,4),(4,8,4)),
        ((4,8,4),(4,8,4),(4,8,4))
    )

Of course, there is the possibility that all else is not equal. Having multiple adjacent pixels of the same color could enable consolidating the signals of those pixels together earlier on in the image processing pipeline into an actual lower-resolution standard-Bayer signal. That could actually have real benefits if that early-stage signal combination results in a greater signal amplitude that drowns out noise.

Basically, this has all been kind of stream-of-consciousness and much longer than I originally planned, but here's the Cliff Notes from what I can tell.

In comparison to a Bayer sensor of the same pixel resolution...

Pros:

- (If implemented to take advantage, possibly) Ability to act as unified large pixels, increasing SNR at lower resolution settings

Cons:

- Less-fine maximum chroma resolution when all pixels are active

In contrast, if you had put an open source license on it, then anyone would be well within their rights (assuming the license allows it) to compile and release a version to whatever app store they want.

Of course, most actual counterexamples to net neutrality are seen as positives (free Netflix or Hulu with usage not counted towards a data cap) rather than negatives, so it might not work out.

EDIT: Looking at some stuff, it seems like Netflix might "trust" a first-party browser to select the highest-quality stream that it has hardware video decode support for. In comparison, it sounds like there are extensions that enable 1080p in Chrome by pushing it into the list of playlist options, but it can cause a serious performance hit by decoding on the CPU.

This is already the case for AVC/HEVC on mobile devices where storage and power considerations overwhelm the possible quality and coding efficiency advances that could be available from a highly-intensive, highly-tunable CPU-based encode.

In comparison, if you look at digital cinema, video is dumped as raw, unencoded pixels onto high-speed, high-power SSDs without any compression; this way, the original image can be manipulated losslessly before going through an intensive encode process for an optimal quality/space balance for end-user media delivery.

See? I can speculate baselessly too.

Additionally, the macOS Messages app is way more capable than most people realize. Of course it supports iMessage, but it also supports sending native SMSs when used with a paired iPhone, either via relay or through WiFi calling with a supported carrier. It also has Hangouts chat support AFAICT, and support for any other (standardized, decentralized) XMPP/Jabber server.

And the majority of the other applications come preinstalled, but can just be deleted.

I am a bit intrigued about the way it's separated from the "nature" of the underlying Object though - in Python, we'd have a single canonical interface to the data, bound to the class in which the data was instantiated. Here, in ES6, it seems like the data might be attached to a base Object, and you could use that Object with any number of different proxies to provide polymorphic behavior.

Overall, these seem like very different philosophies of object-oriented programming. Which I guess makes sense given how the languages have evolved over time.

[0] https://docs.python.org/3/howto/descriptor.html

EDIT: Or, for that matter, trusting the compiler to inline small-enough function calls?