haikuginger

Python urllib3 maintainer here. urllib3 made a change to be more RFC-compliant in December, and which fixed this issue, but that change has not been released yet. We are in the process of looking into that.

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 trust dynamic is the opposite of what you think - SGX doesn't enable an enclave that protects the machine owner from the code they execute; it enables an enclave that protects executed code from the machine owner.

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.

> So... Because lists are dynamically typed and heterogeneous, does that mean the underlying C is basically a contiguous segment of memory of python object references?

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

For fuck's sake, "being gay" isn't even one of those classes.

The CPU itself had plenty of thermal headroom, but was overdrawing the power system - which then thermally throttled itself way more aggressively and in a less-controlled manner. The update changes the curve to ensure that the CPU doesn't draw more power than the power system can handle for extended periods. The CPU will still downclock itself as needed if it experiences its own thermal overload.

I'm curious to see how the "Quad Bayer" mosaic works out. Other manufacturers have tried novel filter patterns before, but nothing so far has really been able to compete.

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

    RGRGRGRG
    GBGBGBGB
    RGRGRGRG
    GBGBGBGB

This pattern is not perfect, but is highly effective. Luma (color-independent) resolution is essentially equivalent to the actual number of pixels, while chroma (color-dependent) resolution is only slightly less - we essentially get one "real" point of color information at each intersection of four color pixels, because at each of those intersections we have one red, one blue, and two green pixels.

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

I'm concerned that chroma resolution and overall color accuracy will be much lower with this pattern. Essentially, with the original Bayer demosaicing, you only need to sample from the four color pixels adjacent to each corner in order to get a bit of the three channels, and the pattern gives equal weight to both red and blue, while providing extra accuracy in the green channel that human vision is most sensitive to.

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))
    )

The 9-pixel-effective-pixel Quad Bayer pattern produces this:

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

Note that there are fewer effective pixels for the same total number of pixels - that's okay, though, because the number of effective pixels approaches the number of total pixels as the sensor scales in the X and Y dimensions - this very small hypothetical sensor doesn't benefit from that scale yet.

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))
    )

Interestingly, while the exact arrangements of the different color channels within the effective pixels are different, the total number of pixels of each channel remains completely identical, meaning that any given effective pixel should have identical noise characteristics to the Quad Bayer pattern. In fact, it's arguable that the Bayer pattern is better, because the color physical pixels are more evenly distributed around the effective pixel.

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))
    )

And for the standard Bayer, like this:

    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))
    )

Again, sampling in a similar pattern gives the same overall result. So, all else being equal, I'm not sure it makes sense.

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

GP is saying that since there is no license, the code is copyrighted and there is no allowable use anyone could put it to. Therefore, since you own the copyright, and did not license the code to a third party, you could have the app using your code taken down from the App Store.

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.

Also, the Mac has a webcam instead of a nose hair viewer.

Having wireless providers who are able to provide landline-level speeds means that many markets will go from having one or maybe two real ISP options to having three or four. Competition means that if the benefits of net neutrality are desirable, customers will prefer an ISP (wireless or otherwise) that provides those benefits.

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.

I think it's much more arbitrary. Silverlight is on life support with support for EME/HTML5 video on most platforms, but Netflix has historically chosen to only support 1080p video on the first-party browser for any given OS (Chrome on ChromeOS, Safari on macOS, and IE/Edge on Windows).

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.

Hardware implementations of codecs can be made that perform encode at low power if a certain level of quality/efficiency can be given up.

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.

When I read this one obvious explanation would be that IQ tests are designed with biased assumptions based on the cultural environments in which they were designed, and that those biased assumptions become more and more foreign as more generations pass since the test was originally designed.

See? I can speculate baselessly too.

The way Oracle and VMWare bill is not bound by a technical limitation.

Plus, many of the integrated apps actually do support the platforms he's using - for example, Google syncing with the macOS Contacts, Calendar, and Reminders applications.

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.

Um. If you're setting an alarm in the built-in clock app, it definitely works when Do Not Disturb is turned on.

I believe the PC's point is that you're leaning on "never having heard" about Apple committing compatibility fixes before as justification for that not being something they would do, but prior to reading this article, you would have "never heard" about Apple applying compatibility hacks inside their own runtimes either.

This makes sense to me - it feels like an interface somewhere in the space of Python's properties (using the @property decorator), its descriptor protocol[0] with which properties are implemented, and its system of magic methods like __getattr__ and __getattribute__.

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

The three largest pools combined hold over 50% of the total hashing power, and all are based in China.

As a C novice, this makes me wonder - wouldn't templates/macros be able to serve a similar purpose to goto statements if the goal is to avoid nested calls but still share code?

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

One of the benefits of async code as compared to threading is a much easier to reason about data model. In comparison to threading, where shared data structures can change at any time, async code an be assured of data consistency within a given "block" of code - whether that block is defined by being within a single callback function or by being between `await`s in Python.

I wonder if it'd be possible to do automatic detection and removal of notebook lines via an FFT (frequency domain) transform.

This is on-point. Cultured gemstone-grade diamonds started becoming viable in the early '10s, and manufacturers were careful to provide better value than mined gemstones but not overly sell on it, instead stressing the ethical aspect of CVD/HPHT-treated stones. In addition, the process wasn't yet refined enough to undercut traditionally-mined diamonds by too much. If that changes, then the meaning of diamonds to the rich will as well.

The processing is key; the prime example for me is peach jam, where if you just chop the fruit up, you end up with peach suspended in mostly-clear gel. If, on the other hand, you blend the peach mixture, you end up with a delicious consistency that's flavorful all the way through and easy to spread.

Butter handling is key in my own chocolate chip cookies, I've found. Let it soften too much, or overbeat the batter, and you'll end up with Frisbees. Ideally you want to cream the butter and sugars until just combined; they'll get more thoroughly mixed as you add flour and other ingredients.

Look into a SiliconDust HDHomeRun Prime. CableCARD support, and compatible with a variety of DVR software backends.

It doesn't look like they considered substantial congestion for either 4G LTE or 5G, which should mean that while the specific bandwidth numbers may not hold up, the speed ratio should be comparable in production.

You can see that they evaluate LTE at 50Mbps, which is around what Verizon phones were getting when they first started going to market but before congestion and backhaul limitations were hit due to the number of LTE devices on the network.

Currently on LTE with AT&T, I can usually hit 10-20Mbps, so applying the 14x ratio, I'd expect to be able to get 100-300Mbps with 5G once congestion takes hold, which is quite sufficient.

On #2, Fn-up and Fn-down are respectively equivalent to page up and page down on the Mac (at an OS level).

To help with the perspective, the fine print states that they were making comparisons to comparable products that cost between $100,000 and $450,000.

Probably a bit of both. H.264 hardware encoding is generally available, but it's more used for real-time communication (Skype, etc) or places where software encoding isn't viable (mobile devices with power limitations) than for reference-quality encodes.

If you need to check against multiword tags, I'd suggest a utility function to expand a list of words into each possible one-or-more-word subset. Should still be substantially faster than the current state, and you can improve it even more by limiting it to phrases with no more words than the tag with the maximum number of words.

    def get_all_phrases(descr):
        words = descr.split()
        if len(words) == 1:
            return words
        phrases = []
        for i in range(2, len(words) + 1):
            phrases += get_phrases_of_len(i, words)
        return words + phrases

    def get_phrases_of_len(length, words):
        return [' '.join(words[i:i+length]) for i in range((len(words) - length) + 1)]