I swear I've seen these "[Latest macOS release] does not appear in UNIX certification site" threads every year since the release of Big Sur in 2020.
It takes several months for the certification to appear on the site. What would be newsworthy is if we see a release next year without this release getting certification.
Even then, visual diffs were pretty flakey for web development, because one's OS and browser choice would slightly alter the exact pixels blitted to the screen. At least this was the case for the tests that would simply match pixels instead of computing a sort of visual hash.
It's also partly why some people preferred snapshot tests that compared the DOM tree instead, though that was brittle in other ways (e.g. tests would break if an application's frontend used a major UI library and an update to the library permuted the order of classes in some part of the HTML).
For web UI tests this is mainly solved, at least when using Playwright. It allows setting thresholds, percentages and some other config items to allow some small differences in pixels. https://playwright.dev/docs/test-snapshots#options
That's an attempt at mitigation, but most definitely not solved.
It still causes both false positives and false negatives through that. The only true "solution" is to make sure generation always happens on the same platform as your ci... And various mitigation strategies around that (eg fall back to structure tests on other platforms vs actual visual diffs in ci
Also not unique to playwright. Been available basically everywhere since the start
In my case, I am double-taxed (both Japan and US side) on capital gains. Tax treaties reduce, but not eliminate, the extent of double-taxation.
Many US-based brokers do not allow Americans abroad to purchase mutual funds, so VFIAX is not a choice for me.
Maybe I can go with eMAXIS Slim All Country... Oh, but that is a PFIC under IRS rules and I'd be taxed on unrealized capital gains. So I guess no Japan-equivalents of VT for me. That's fine, I guess I'll just buy VT in my US-based brokerage account; but now I'm in a suboptimal spot with respect to monthly contributions, calculating JPY-denominated income tax on dividends, etc.
I even made an implicit assumption when I said "calculating JPY-denominated income tax on dividends". That assumes your tax status is permanent resident. If your tax status is non-permanent resident, then a decent financial advisor will recognize that only the extent of income remitted to Japan gets taxed, so VT distributing at all isn't an issue (until 5 years later). What should you do before the 5 year threshold is hit? etc. etc.
But yes, if you're born in America and plan to stay within the same state for the rest of your life, then a 100% automated setup that simply deposits $1,000/mo into VFIAX is probably fine. (But keep in mind, to most non-Americans, VOO is not really diversified compared to funds like VT).
Otherwise, there is value in consulting someone (or something) that regularly handles taxes and financial planning.
Full agreement. I'm double-taxed in Germany and the US. I don't have a residency in the US (so I cannot vote but still get taxed, nice!) so I'm completely unable to buy VFIAX or any other fund from the US. I cannot but them over an EU brokerage, either, because US ETF and its ilk violate European transparency laws. I can buy EU-domiciled funds, but those are treated as PFIC in the US with prohibitive taxation. I relegated myself to an old-school dividend growth investment scheme and it's financially working out much better than I anticipated but still, I'd like to have a core of a stupid ACWI tracker.
> I relegated myself to an old-school dividend growth investment scheme and it's financially working out much better than I anticipated but still, I'd like to have a core of a stupid ACWI tracker.
roughly same approach in Canada, for the same reasons.
if you look up most of the dividend aristocrat funds they'll give a breakdown of holdings... so duplicate those in roughly the same ratio (to the best you can) and call it a day
GP's point is about "sending tokens to someone else's computer" versus "keeping the tokens locally". I think model capabilities are secondary.
In May of this year, I was running qwen3.6:35b-a3b on my MacBook (bought in 2024). Obviously not as fast as, say, running a model on Cerebras, but a year ago it wasn't really feasible to have a local model running on my 2024 laptop with vision support. (Concretely, I was passing apartment diagram pictures to Qwen and making it compare different apartments for which ones would feel the most spacious while optimizing for initial moving costs and other factors.)
This was back in May and I wouldn't be surprised if there have been significant improvements since then.
Overall, I think it's fair to compare a workflow like "use llama.cpp locally to upload some pictures and ask questions" to "open the ChatGPT app, upload pictures from your phone, and ask questions". Sure, you can't run a model like GPT-5.4 locally, but the model is mostly an implementation detail here. What a user will care about is: "when I go with the llama.cpp option, am I getting useful information from my conversations?"
Wouldn't the better comparison still be against an AI provider with better privacy controls, especially if that's what someone cares about (even if they don't care about whether they're comparing a 35 billion param model vs a x trillion param model)?
Users generally have no way to verify that a third-party provider, even if they advertise themselves as privacy-focused, will adhere to their own terms. This is similar to the issue of privacy-focused VPN providers that claim to not log user activity (and then end up leaking user activity). You can get proof of ~P, but rarely proof of P, and often times the proof of ~P is due to police raids, data breaches, etc., not something of the provider's volition.
What you can possibly audit is probably data sovereignty. For instance, I would not be surprised if Mistral's customers demand concrete evidence that their data is held within the European Union. But that is a distinct issue from training on input tokens.
It looks close to the kind of documentation artifacts GPT 5.6 Sol would generate for me.
That style is still rare enough that I prefer it over OP's "we installed shadcn + Tailwind and look like every seed-stage startup SaaS from 2024" style.
Finally got rid of Webpack in 2022, and now I'll be able to get rid of Babel, too.
It's a bit mesmerizing to think that Vite at the time was still "that newish tool the Vue folk use", and now it's pretty much the standard bundler for web frontend. Also the easiest one to configure and use (in my experience).
Similarly, I'm glad I don't have to deal with karma, jest, etc. anymore.
I really haven't invested heavily in understanding new tooling, but I did try to move to TS 7.0 and found that a lot of the tooling actually relies on parsing TS not just stripping the types. And the only tool that can do that reliably is `tsc`.
I even had to revert from TS 7.0 (the go rewrite) to 6, because 7 doesn't support plugins and code analysis stuff (which I guess are js) in the way the tooling requires.
In Japan, the identity verification is quite strict to subscribe to a voice/text capable phone line. Still yet to get robocalls or spam texts. I'm sure they exist, but despite handing out my phone number to city hall and countless private businesses, I have yet to receive one.
On the other hand, enabling my Verizon eSIM is a surefire way to receive hourly "Potential Spam" calls, despite giving nobody outside of direct family my US phone number. Thankfully, I've convinced enough of my family to use Signal and we call/text through there instead.
Nowadays, I only turn on the Verizon line if I have to receive an SMS one-time code or call my broker.
Don't think the U.S. will ever solve this problem; people will just say something about privacy, the country's "too big" to combat spam at scale, etc. It's also too easy to get a phone number anonymously. A frequent phenomenon I've witnessed is that when someone blocks a phone number, the same caller contacts them again from a different number with the same area code.
That would surprise me. I don't recall having to change my iPhone's region after moving to Japan. Transport IC cards in Apple Pay have "just worked".
I am vaguely aware that some phone manufacturers silently remove certain NFC hardware (or disable some driver) in order to avoid paying Sony patent fees. Apple doesn't seem to do that, though.
It takes several months for the certification to appear on the site. What would be newsworthy is if we see a release next year without this release getting certification.
reply