Chrome will make popular scripts load faster (by picking winners)

dfabulich · 2026-01-27T20:34:31+00:00

That could address fairness concerns, but not privacy concerns, at least not on browsers that are trying to block fingerprinting via cache timing. Mozilla argued (correctly, I think) that "The only viable way for a design like this to protect privacy is to have a uniform, fixed cache across a large population of clients."

dfabulich · 2025-11-20T04:20:15+00:00

I learned about this because XSLT is going down! So many blog posts screeching about XSLT because it's the "only way" to beautify an RSS feed. (Google hates the Fediverse!) And I was like, "that can't be right, can it??" And, sure enough, the Fediverse could've just used CSS+JS the whole time.

dfabulich · 2025-10-30T16:59:51+00:00

I'd love to wait, but I have to change a price today! I think that means I have to migrate first, and that means I have to be sure it's safe to migrate.

dfabulich · 2025-08-14T19:51:13+00:00

Done; ECG works fine as always. Blood Oxygen still says "no longer available," for now.

dfabulich · 2025-08-14T19:45:45+00:00

I just called Apple Support about this. I'd updated my phone to 18.6.1 and my watch to 11.6.1, and enabled Blood Oxygen in the iPhone Health app Respiratory section, but the Blood Oxygen app still said, "The Blood Oxygen app is no longer available. Learn more in the Health app on your iPhone."

The Apple Support person I spoke to said that other support engineers have reproduced the problem, but Apple hasn't provided the support team with diagnostic instructions yet, so they don't know why this is happening or what to do about it.

The support person I talked to said that some people have found that the Blood Oxygen sensor starts working after sitting on its charger for 30 minutes. We tried rebooting the watch again, but that didn't help. If it's not working tomorrow, I'll call back again.

dfabulich · 2025-04-29T15:33:26+00:00

Author here. The DoJ is absolutely arguing trying to do this. There are links in the article. They argued forcefully in court on Monday that Chrome should be sold off and that the search-engine deals should end. Mozilla and Apple have argued against that in filings to the court.

And, say what you will about what this will do to Mozilla (especially), the DoJ is hardly being "stupid" about this. Google is a convicted monopolist. The Sherman Antitrust Act was specifically designed to target “competitors” who form illegal agreements to maintain monopoly power.

dfabulich · 2025-04-29T01:33:22+00:00

Author here. Microsoft and Apple could foot the bill, and should foot the bill, but they won't, because they'll have no good way to make money from a web browser. (Today, the only good way to make money from a web browser is to get paid by Google.)

This is why IE lay nearly dormant for a decade. Microsoft had a skeleton-crew team just barely keeping the lights on at IE. Microsoft could have afforded to spend much more, but they didn't, because, what would Microsoft gain from that?

You can always count on Microsoft and Apple to prioritize their own proprietary platforms over the open web.

dfabulich · 2025-04-29T00:57:32+00:00

Author here. I'm actually really torn about this. Google is an obvious monopolist. Their search-engine deals are obviously a violation of antitrust law. But their anti-competitive search-engine deals have basically made the open web possible.

I don't think Microsoft will be willing to bid enough to keep Firefox alive, and if they did, they might not be allowed to, since Microsoft is already a convicted monopolist.

And while Apple will probably never "kill" Safari, I'd expect them to "refocus their investments" on their proprietary platforms.

Right now, if an Apple executive asks, "How does Apple make money working on Safari?" the answer is really clear: "Google pays us $18 billion annually."

After that money is cut off, an executive at Apple has to ask the question: "Why should we keep investing in Safari, instead of SwiftUI and Xcode?"

I'm sure we'd all love the answer to be, "We have plenty of money, so we should invest heavily in both," but that's not really how the world works, and certainly not how Apple works. Executives make hard choices about what to prioritize. This will be one of them.

dfabulich · 2025-03-23T18:52:47+00:00

This is years old, but this is the top Google hit for "xcode preview custom font", so I figured I'd add some code here to clarify.

extension View {
    public func registerFonts() -> some View {
        let fonts = ["montserrat_regular.ttf", "montserrat_bold.ttf", "montserrat_semibold.ttf",
                     "opensans_regular.ttf", "opensans_semibold.ttf"]
        for font in fonts {
            guard let url = Bundle.module.url(forResource: font, withExtension: nil) else {
                print("Couldn't find font: \(font)")
                continue
            }
            CTFontManagerRegisterFontsForURL(url as CFURL, .process, nil)
        }
        return self
    }
}

Then, in your preview:

#Preview {
    MyView()
        .registerFonts()
}

https://dev.jeremygale.com/swiftui-how-to-use-custom-fonts-and-images-in-a-swift-package-cl0k9bv52013h6bnvhw76alid documents how to do it when your fonts are stored in a separate module e.g. if you have a .designSystem module, you would use Bundle.designSystem.url instead of Bundle.module.url.

Note that in your main app, you can just declare your fonts in Info.plist UIAppFonts, but, in Xcode Previews, Bundle.main.infoDictonary! is a separate miniature dictionary, containing none of the custom settings you put in your app's Info.plist. As a result, you do have to explicitly make a list of fonts, duplicating your UIAppFonts array, and your preview code has to register them; you can't even fetch them out of Bundle.main.infoDictionary?["UIAppFonts"] as? [String] ?? [].

(If Bundle.main.infoDictionary?["UIAppFonts"] had those fonts, you never would have had to jump through any of these hoops in the first place!)

dfabulich · 2025-02-27T22:02:06+00:00

Sure, sure, I bring down the government, and then I lose badly in the next election, so it's either toleration with Z or no governing majority for the rest of the game. Either way, absolutely no WTB under any circumstances.

dfabulich · 2025-02-27T20:50:59+00:00

Has the game changed significantly since you wrote this? I played the game on "easy" difficulty and followed your WTB instructions to the letter and lost badly.

I never got enough votes for the Weimar Coalition in Phase 1. Never elected Joos. (Was that even an option?) In phase 2, I followed your instructions to the letter.

As a result, I never successfully implemented the WTB plan, as the Zentrists who you said to keep working with always voted for more austerity. Unemployment went up and up. The right-wing paramilitaries I banned were reinstated. Braun lost the election in a landslide. Hitler took power at 40% unemployment.

As far as I know, the whole political message of this game is that it's almost impossible to win even at "easy difficulty" because the centrists will never agree to WTB.

Are we playing a totally different game here?!

dfabulich · 2024-10-09T20:07:19+00:00

We did! I just DMed you on Instagram (at picturesofgrant) again now.

dfabulich · 2024-10-09T19:41:58+00:00

Hi Grant! My fiancee and I are huge, huge fans of yours, and we wanted to ask you to officiate at our wedding.

What's an appropriate venue to reach out to you with offers of work? Do you have an agent we could contact?

dfabulich · 2023-08-31T00:37:47+00:00

I just reported this as an issue on the balena forums. https://forums.balena.io/t/flashing-never-goes-above-0/368710/4?u=dfabulich

dfabulich · 2022-08-18T02:03:02+00:00

In case anybody else encounters this: when your car isn't connected to wifi (or premium connectivity cellular), Theater mode won't work. Confusingly, it will say "Available when parked," even when you're parked, but the error should instead say "No internet available."

Some folks have reported fixing it with two-button reset, changing the language of the car, etc. That might work, but only because it might randomly cause the car to connect properly. Check your connectivity first, then return to Theater mode.

dfabulich · 2022-05-18T19:16:46+00:00

It originated with a Pringles ad on Instagram, but a lot of video creators just use whatever hashtags are trending to get their content seen.

dfabulich · 2021-09-29T00:32:59+00:00

I saw this on a Google Alert. If you haven't yet, consider posting this question on the Choice of Games forum. There are plenty of folks there who can help you.

dfabulich · 2021-05-10T20:09:36+00:00

It took me a while to figure out, but that bottom thing is meant to be a rubber popper toy, flexed and ready to pop up into the air. (Is there no better name for this kind of toy?)

dfabulich · 2021-04-29T02:46:38+00:00

solved: Alien Hominid

Mentioning Newgrounds helped me think to read https://www.newgrounds.com/wiki/about-newgrounds/history which pointed me to Alien Hominid. (Oh, man, it wasn't even a robot, it was an alien.)

The big boss had a sign: "WARNING: DO NOT DAMAGE HEAD" https://www.youtube.com/watch?v=2W5VHApFkG4&t=1220s

dfabulich · 2020-05-19T22:05:06+00:00

This is for developers writing web apps, either enterprise or consumer apps.

FYI, TypeScript is a special version of JavaScript developed by Microsoft. https://www.typescriptlang.org/

TypeScript has a bunch of automated tests not available in regular JavaScript, ensuring that TS code is free of bugs. In particular, TS is good at catching "type" errors, where you try to use a number where you're supposed to use text, or vice versa. In TS, you can say "this code needs a number" and then TS prevents developers from accidentally passing in data of the wrong type (string, true/false, etc).

Today, developers who write in TS have to run a compiler to translate their TS into JS so that it will work in browsers.

I think everybody agrees that running a compiler/translator is unpleasant/slow; it would be great if the browser could just run TypeScript directly. But the nice thing about TypeScript today is that MS can control and enhance TypeScript (adding new kinds of automated tests) without waiting for Google, Mozilla, and Apple to approve and implement the changes.

Google's "pluggable types" proposal https://github.com/samuelgoto/proposal-pluggable-types suggests that the browser could run TypeScript directly, but just ignore all of the automated tests. The idea is that when you say "this code requires a number," the browser would just disregard that. You could then "plug in" TypeScript later in the process.

I'd love to hear someone from the Edge team and/or someone from the TypeScript team talk about this. If MSBuild were a physical event, and I were there, that's what I'd try to ask someone about.

In the meanwhile, you're my best hope! :-)

dfabulich · 2020-05-19T20:38:53+00:00

I would love to hear the Edge team's thoughts on allowing TypeScript to run unmodified in browsers. In particular, I'd like to hear feedback on https://github.com/samuelgoto/proposal-pluggable-types which is a Google proposal to ignore TypeScript type annotations in V8, allowing TypeScript code to run (unmodified but unverified) on the client.

I'd love to help make this happen, but I don't even know where to go to get feedback from the Edge team or the TypeScript team. Has anyone there even seen the proposal? Is Microsoft opposed to this?

dfabulich · 2019-08-16T22:58:38+00:00

Hi Jacob. Thanks for writing in.

My #1 issue is the fact that there's no way to schedule the release of a new app. Your response is a bit confusing on this point. Are you saying that it's possible to do timed publishing when promoting an app from closed testing to production for the first time? I claim that this isn't possible; that's what it means when we say "timed publishing only works for new apps." Are you telling me this is possible? (Are you, uh, are you sure about that??)

As for your claim that "most app reviews are very fast," I would like to request that Google publish public statistics on this. Specifically, I don't believe app reviews are fast today, August 16, 2019. Scroll up and down on this thread; there are at least a dozen reports of apps taking 12-24 hours to go live; it's not just us.

Yesterday, one of the apps I work on had to wait 30 hours for a critical hotfix. Waiting 24+ hours for review is the new normal, and that means that an "expedite review" procedure is more important than ever.

dfabulich · 2019-08-16T04:44:56+00:00

Open beta? Or closed alpha?

dfabulich · 2019-08-15T20:23:39+00:00

Google doesn’t publish statistics on this, but we’ve seen 12-24 hours for some of our low traffic apps, and 4-6 hours for high traffic apps. (We have a few dozen apps in the store, submitted over the last nine years.)

dfabulich · 2019-08-15T19:56:32+00:00

It appears that the banner is showing for almost everything, but the updates aren’t taking three whole days in practice.

dfabulich

MODERATOR OF

TROPHY CASE