haikuginger

Your script has what looks to be a pretty big inefficiency here[1] that's slowing it down. Looping over a set kills the constant-time presence-checking that you get from using that data structure; it will likely be much faster to do something like this:

    tags = list(set(descr.split()) & categories)

The following would also work:

    tags = [x for x in descr.split() if x in categories]

[1]https://gist.github.com/28mm/9820bd8b6eb27555efe9d6f46dd95a8...

Mom rule == "If you can't say anything nice, don't say anything at all"?

You can also choose to pass the FE exam to qualify for the patent bar; most states require a BS in engineering to take the FE exam, but not all, and an FE pass in a state that doesn't still qualifies.

I've rented cars with CarPlay before; I find that the ideal way to go about it is to do a location search as I'm walking to the car and start navigation; once I plug in the phone and enter CarPlay, it picks up seamlessly onscreen.

If that's the case, it looks like the chip has a surprisingly modern feature set. For example, based on this article[1], the RSC on which the RAD6000 was based had an on-chip memory controller in 1992.

It also had a branch predictor, however, this line is notable:

> Note that the RSC never speculatively executes prefetched instructions.

This means that the branch predictor only did fetch/decode, and so the chip would not have been susceptible to Spectre, as the pipeline would have been flushed and the correct instructions reloaded as soon as the condition evaluated false, before the branch would have been actually executed.

[1]https://web.archive.org/web/20131004213712/http://zmoore.net...

The article linked to a set of posix-spawn benchmarks[1] that seemed to indicate that while fork/exec time scaled linearly with resident memory on Linux, it did not scale at all on macOS.

First of all, I was somewhat confused by that due to the availability of copy-on-write; I wouldn't have expected fork/exec time to scale up that way.

Second, I was surprised that there wasn't an attempt to explain the behavior difference between the two systems. Can someone familiar with either or both point towards an explanation for why that's the case? It seems very odd.

[1]https://github.com/rtomayko/posix-spawn#benchmarks

To clarify, the parent poster isn't affected by the gambler's fallacy; rather, they're pointing out that it's common practice for any accidents involving spacecraft to be thoroughly scrutinized to ensure that the failure mode is completely understood and can be avoided in the future.

That's not accurate; first generation MacBook Pros used 32-bit Core Duo processors as well, as did almost all the early-2006 models; the exception being the lowest-end Mac Mini, which had a single-core 32-bit Core Solo. 32-vs-64-bit was never used for price differentiation within a lineup; Intel's 64-bit chips just weren't ready in time.

Late-2006 models, including the first-generation Mac Pro, moved from the 32-bit Yonah Core Duo/Core Solo architecture to the 64-bit Conroe Core 2 Duo.

The stat you cite is actually 1979, but if you look at the income proportions[1] at that time relative to current by-quintile income proportions, the growth in taxation of the top quintile between 1979 and 2005 is slightly greater than linear with that income growth.

[1] https://www.census.gov/data/tables/time-series/demo/income-p...

> If at all possible, buy a car without any computer more powerful than the ECU and just use your phone or a tablet or an aftermarket “””smart””” interface.

That's rather the point of CarPlay. It takes the "smarts" out of the car and essentially lets your phone use the car - its touchscreen, its speakers, even its GPS receiver - as a massive peripheral device.

The truly offensive aspect of this is that the CarPlay standard is effectively fixed. There is no further maintenance or code required. BMW doesn't need to write a software update for the next version of iOS because CarPlay doesn't care about anything at that layer. All it cares about are audio and video streams to be presented and inputs to be received.

You have to have a (free) developer account.

Looks like Safari is blocking the CORS request to reddit.com.

Quick explanation of the groundwork for this piece:

Typical DSLR shutters are focal-plane shutters, which mean they open and close directly above the image sensor. They are mechanically primed, and when triggered, the "first curtain" opens across the sensor, followed by the second curtain after a brief delay corresponding to the relevant exposure time.

In the case of very fast shutter speeds (depending on the camera, typically 1/250s or faster), the second curtain begins its traversal of the sensor before the first curtain is fully open. This means that every portion of the sensor is exposed for the appropriate amount of time, but that not every portion of the sensor is exposed at the exact same time. This is due to mechanical limitations, and is hard to get around.

In general, this isn't an issue. However, flashes and studio strobes are of a very short duration - often 1/10000th of a second or less. In the case of a focal plane shutter, this can mean that not the entire sensor will be exposed to the flash's light, causing a stripe in the final image.

There have been various ways to compensate for this - for example, high-speed flash synchronization that fires the flash at lower power levels several times during the exposure such that each portion of the image sensor is properly exposed.

In earlier DSLRs (Nikon D50 and D70 models with the 6MP Sony CCD), a "digital shutter" was used, which allowed for native flash syncing at high speeds - the mechanical shutter only operated up to its "sync limit" of 1/250, and the digital shutter took over at speeds higher than that.

In comparison, leaf shutters always open fully, which means that there's a period where, if a flash is fired, the entirety of the sensor will be exposed evenly to that flash. Because of the very short duration of the flash, shutter speed does not affect how much of the flash's light falls on the sensor, and can be used to control for background light instead, as compared to aperture and ISO controls that would affect both background light and the impact of the flash's light in the overall image.

You could probably build a Tracery grammar that conveyed a certain set of semantic information with a large number of possible syntactic permutations.

It looks like this API in particular expects all requests to have a User-Agent header, and we don't set one by default. Setting any user agent appears to work; the issue isn't with the `Accept` header.

You can reproduce with curl with the following command:

    curl -v 'https://oneom.tk/data/config' -H 'Accept: application/json' -H 'User-Agent:'

That'll nullify the default curl user agent and should produce the same results you were seeing with urllib3.

urllib3 lead maintainer here. I wasn't able to reproduce your bug, at least with the main development branch, when I passed `Accept` as part of the `headers` dict. If you could file an issue with a reproduction case, I'd definitely appreciate it.

It looks like this:

https://i.imgur.com/6Zw2fyr_d.jpg?maxwidth=640&shape=thumb&f...

I'm not familiar with the current state of bigLITTLE, but at least initially, bigLITTLE clusters weren't capable of heterogeneous compute; you could shift between cache-coherent clusters (use either all four big cores or all four LITTLE cores) or have virtual cores, each made up of one big and one LITTLE core, with the kernel managing which physical core was actually executing threads assigned to the logical core.

My understanding of the A11 is that it's fully heterogeneous with the capability to run and assign code across any permutation of its physical cores.

Anandtech was lost years ago. It's been a ghost of itself since Anand and Brian went to work for Apple. Ian Cutress still writes good desktop CPU/architecture reviews, but editorial quality and consistency have gone way down, and most of the content that comes out of there just isn't up to par with the publication's formerly high standards.

Being able to unlock someone else's phone with a picture of their face has been a bug for the same length of time.

Huge in the Boston metro.

> Though a lot of the unpleasantness of using those machines was more from the extremely anemic GPU which has also improved considerably since then.

Specifically, the GMA950 that didn't have hardware video decode for H.264, which was already the mainstream choice for any Internet video. Combined with the anemic in-order Bonnell core, it was dead on arrival for most uses involving any sort of video. Some netbooks even came with a separate Broadcom PCIe card whose only purpose was hardware video decode.

The heartbreaking thing is that if you're willing to only target 2.7 on the Python 2 front, it's relatively trivial to write in Python 3 and have it be immediately compatible in Python 2 using from __future__ imports.

Also caused major issues for the rare users who had antivirus software installed.

Now I'm curious to see how different user agents would handle SSL validation for bit errors at different points in the process.

> Regarding 2.7.13 - you might find it surprising, but it's actually SLOWER than 2.7.2, there has been no speed improvements and quite a few speed decreases, so we decided to keep the faster one.

I don't find it that surprising, but do find it disappointing that you would run benchmarks against the current version, but not post them online for perusal, nor provide any sort of explanation for the use of the older version in head-to-head comparisons. For me, at least, it produces the impression that PyPy has something to hide, and I doubt I'm the only one.

As I do with every PyPy release, I would like to point out that the PyPy official benchmarks for comparison against CPython[0] continue to misleadingly compare their latest and greatest with CPython 2.7.2 (released in 2011), as opposed to the modern CPython 2.7.13 or 3.5.3 versions for which they target API compatibility.

[0]http://speed.pypy.org

Squashing not recommended.

Not via Bluetooth, but you can make calls via iCloud-paired iPhone, either using the phone as a relay, or using WiFi calling on supported carriers using a similar workflow.

Man, I remember using RawTherapee on Ubuntu Feisty Fawn back in '07. It's been a while.