bdash

Impressive work, Cameron! Hope you're doing well.

Sorry, I don't recall.

The code was added to the public WebKit source tree, but it wasn't written at the time. It was upstreamed from the internal fork of WebKit that Apple used for iOS.

It sounds like things turned out ok after all https://en.wikipedia.org/wiki/Mary_Wade

Awesome to see that you're doing well, Andreas!

Most VORs are being phased out as well, with only a minimum network left in place to support routing flights on instrument flight plans to airports with non-GPS approaches (i.e., ILS) in the event of a GPS outage.

[1]: https://www.aopa.org/advocacy/airports-and-airspace/navigati...

Per https://www.avweb.com/aviation-news/gami-awarded-long-awaite..., this new unleaded fuel is currently only approved for Cessna 172s with Lycoming engines, with expansion to more aircraft types coming next year.

It looks like the article attempts to embed images in different formats for different browsers, but the source images aren't of the image type they expect which results in broken images for some browsers.

    <picture>
        <source srcset="/img/r/p/500x600/8862.jpg.webp?v=1599098401" type="image/webp">
        <source srcset="/img/r/p/500x600/8862.jpg.avif?v=1599098401" type="image/avif">
        <source srcset="/img/r/p/500x600/8862.jpg?v=1599098401" type="image/jpeg">
        <img loading="lazy" src="/img/r/p/500x600/8862.jpg?v=1599098401" alt="Medieval Castle Latrine" class="in_text_image" width="500" height="375"/>
    </picture>

Firefox and Google Chrome both select the image with the image/webp content type, and those URLs do appear to be WebP images.

Safari selects the images with the image/jpeg content type, but those URLs appear to point to AVIF images (i.e., image data encoded using AV1 and stored in an HEIF container). AVIF is only supported by Google Chrome. This results in the images appearing as broken placeholders in Safari.

There's no direct connection to New Zealand. The founders visited New Zealand at some point, and brought back a stuffed kiwi toy for their child. When naming the company, it crossed their mind and so they went with it[1].

Their offices are in Mountain View. I used to live around the corner from them.

[1]: https://www.kiwico.com/blog/2011/06/09/why-the-name-kiwi-cra...

It reduces disk space.

Historically the dyld_shared_cache has been a pre-bound copy of most system libraries that is mapped into memory once and then shared across all processes. It was updated automatically by the system at various times, and if a given system library was determined to be newer then the dynamic linker would simply load it from disk. The result of this was that for most system libraries you ended up with two copies on disk: one at the normal location, and one within the shared cache. Now only the latter copy exists, and Apple ships it directly rather than creating it on each machine from the copy of the system libraries that they ship.

The Apple linker has used `tbd` files, a textual description of a dynamic library's interface, rather than actual dynamic libraries at link time for iOS for several years now. Prior to that it was using stub dylibs, which were essentially symbol-table-only dylib files.

Tie-downs at Palo Alto are more like ~$170/mo

FWIW, WebKit's complete history is available in its Subversion repository, all the way back to the initial commits in 2001 when they were importing KHTML and convincing it to compile without Qt. Granted, there was around two years after Safari's initial release where Apple simply published source code drops, but the full code history has been public (first in CVS, then in SVN) since mid-2005.

A student from University of Illinois at Urbana-Champaign wrote a paper on transparent pointer compression in their custom GCC backend back in 2005: https://llvm.org/pubs/2005-06-12-MSP-PointerComp.pdf. Their compiler backend went places, but I'm not sure if the optimization described in the paper ever made it into production.

It doesn't attempt to determine the size of the critical section, AFAIK. I think it's saying that sleeping immediately when failing to acquire the lock would significantly hurt small critical sections, and so instead they spin a few times to avoid punishing those scenarios.

No, a thread that fails to acquire the mutex sleeps until the thread that is releasing the mutex explicitly wakes it. On Linux this is achieved via FUTEX_WAIT / FUTEX_WAKE.

From the talk by Captain Al Haynes (http://clear-prop.org/aviation/haynes.html):

> We only gave them two minutes to line up for runway 22. They were all set up for runway 31. And when I told Kevin we saw this runway ahead of us, and that's where we were going to land, he had two minutes to get the equipment off the runway. They were actually positioned on that runway, and we could see them moving off that runway. That's the reason the video is no better than it was. With all the notice we had, everyone was set up for runway 31. The two hangars that are built right off to the left of runway 22 were built after the airport was closed, and you can't see the runway from the tower. And that's where the operator was. So he went clearing down the steps, and if you've ever tried to get down tower steps in a hurry, it's a long way down, and that's as far as he could get, before we got there.

Batteries not getting lighter with reduced charge is relevant in that it's not uncommon to trade reduced range for increased payload by carrying less gas. With batteries having a fixed weight, you don't have the ability to make that trade-off in an electric aircraft.

The recent Safari Technology Preview builds have support for the WebAuthn Specification, so it's clearly something they're actively working on.

What's more, the two airports are 17 miles apart only if you look at driving distance. It's more like 12 miles as the crow (or an airplane) flies.

The drone was reported over Teterboro at around 3,500ft. One of the ILS approaches into Newark[1] has Teterboro as an initial fix, with a minimum crossing altitude of 3,000ft. That puts the drone exactly where aircraft inbound on that approach will be.

[1]: https://aeronav.faa.gov/d-tpp/1901/00285IL22L.PDF

It looks like the link within the presentation to WebKit's issue tracking their implementation is incorrect. It links to https://bugs.webkit.org/show_bug.cgi?id=180731, which is about support for BigInt in the Web Inspector, when it should link to the issue tracking the entire feature at https://bugs.webkit.org/show_bug.cgi?id=179001.

If you're doing direct downloads then there's no reason to be building with bitcode enabled, and so the size increase should not affect you at all.

The size I'm referring to is shown in iTunes Connect, which is the administrative side of the App Store that the developer uses to manage their app releases. As far as I'm aware the size shown in the App Store's user-facing UI does reflect the size that will be downloaded by the device. I think it's possible to see this size in iTunes Connect, but since I don't myself have any apps in the App Store I can't easily verify this.

I'm not sure what you're asking here. Why would who do what?

The Apple bug report was filed by my colleague, JP, after we noticed that the built size of Realm's frameworks dramatically increased after updating to Xcode 8.3. We pay attention to the built size of our frameworks as we distribute precompiled versions of them (https://github.com/realm/realm-cocoa/releases), and a signifiant size increase inconveniences our users. We've not tested the impact of the size on an app installed via the App Store, but since the increase is limited to the bitcode portion of the binary we have no reason to think it will be affected.

I think the size iTune Connect reports includes bitcode, and isn't representative of the size of the app once it makes it to a user's device. The information in the original bug report you linked to clearly shows the size increase is limited to the bitcode portion of the binary.

Some people like to check in precompiled versions of their dependencies. Others like to distribute precompiled versions of their frameworks or libraries. Larger binaries aren't great for either of those cases.

Note that the size increase is in the _bitcode_ portion of the binary. This slice is stripped from the binary before it makes it to the user's device. This means the size increase is merely an inconvenience during the development process, and has no impact on the size of apps as users see them.

The Reddit comment at https://www.reddit.com/r/technology/comments/60ffl6/apple_pa... mentions the following:

> That 0$ is their NZ income tax. Obviously they pay all other taxes for their properties and employees. It is just that New Zealand and Australia have an income tax deal

>> Apple's New Zealand operations are wholly owned by an Australian parent and appear to be run from there. A tax treaty between the two countries sees dual claims on income tax default to where the company is controlled.

>> Russell, recently selected as the Labour Party candidate for the safe New Lynn electorate for September's general election, said Apple's tax arrangements were totally consistent with the law.

> So Apples NZ income tax is paid to Australia. All other NZ taxes are paid to NZ. Hilariously the tax rate in Australia is higher than in NZ

>> The accounts for Apple's New Zealand subsidiary disclose in notes that income tax is paid at 30% - the rate in Australia - not the 28% charged in New Zealand. This reference has been in every financial statement filed by Apple with the Companies Office since at least 2007.

It provides [1] as its source.

[1]: http://www.documentcloud.org/documents/3515916-Apple-2016.ht...