- fl0ki parentIn fairness, it's one thing for an implementation like a building to be as over-enginereed as possible in its own right, but it's another when a standard has to ensure that multiple implementations can interoperate. I'm not saying FIPS-140 has only that kind of limitation (far from it), just that this isn't the best analogy.
- Putting aside that several of these were acquisitions, these are all great examples of things where Google introduced something for free because it would make the money through advertising, both directly and through ecosystem effects. Even the paid enterprise versions of these services were a tiny % of Google's overall gross revenue.
Prior to the push into Cloud computing, Ad revenue was well over 90% of all Google gross income, and Cloud was the first big way they diversified. GCP is definitely a credible competitor these days, but it did not devour AWS. Other commercial Google services didn't even become credible competitors, e.g. Google Stadia was a technically exceptional platform that got nowhere with customers.
The question now is whether Google carves out an edge in AI that makes it profitable overall, directly or strategically. Like many companies, there seems to be a presumption of potentially infinite upside, which is what it would take to justify the astronomical costs.
- I had an Oura Ring 4 for a few weeks, and it's one of the only tech gadgets I have ever returned. Thankfully it didn't swell and trap my finger, but it hit some kind of internal deadlock that didn't go away until the battery fully depleted over several days. The repeated-knock gesture to hard reset didn't work either. Best part is, my wife hit the exact same bug just a week later. I don't see myself buying a smart ring ever again.
- As someone who does not use Stage Manager, I don't find that the other ways macOS has become more like iOS were, to me, bad ways. The most notable changes I find were that the Settings app became far more organized and consistent, and the Control Center has tons of convenient shortcuts with a very high level of customization.
In fact, Control Center is currently less customizable than iOS because you've been able to fully rearrange the controls on iOS for an entire year now. If anything, it could stand to be more like iOS in that regard, though it's not a huge deal either way.
I don't particularly use widgets much either, but I never felt their inclusion was a net negative, they're just not as useful as other interfaces already available on macOS.
One thing I'll definitely cede though: having some "macOS" apps actually be iOS apps, like Home, is weird not just because the UI design is unusual but also because there's been no attempt to make standard desktop hotkeys work, not even Esc.
- Hello, I am the other person who liked Unity. Now that we have met, the prophecy is fulfilled.
Seriously though, the fact that macOS still doesn't have an option to fully extend the dock horizontally or vertically drives me nuts. If you auto hide the dock it loses half of its value, and if you don't hide the dock then you have dead gaps in the corners that serve no purpose.
- Shout out to Michael Larabel for performing this much testing for every chip and distro, this close to their release, and with this thorough presentation every single time.
I honestly don't know how he does it. It seems like more testing than can fit in real time, even when running tests of different machines in parallel. His tooling and workflow must be dialed in to levels I can't imagine and YouTubers appear to have yet to reach.
Michael, you are a gift to the industry, thank you for doing all of this so well that we can take it for granted, and thank you for continuing to do it even though many do take it for granted.
- The suckless.org initiative is a great example of this. Boasting about how certain software inherently sucks less because it has minimalist C code, rather than having defense-in-depth against security holes.
Newsflash, a few decades ago the majority of software was the minimalist C that they claim sucks less. There are many reasons we moved on from that world, security firmly among them.
- The show Vikings does feature a character with the similar name Athelstan [1], but he's a monk captured by the vikings, not a king who conquered the vikings.
- Sounds like you still have TouchID instead of FaceID. The pandemic was quite a wakeup call for this, with far more people wearing masks than gloves, people using FaceID were set back much more than people using TouchID.
Then Apple just made FaceID work even with masks. Now TouchID is further behind by still not working with gloves, while FaceID works in more situations than ever before. When you don't need to authorize a sensitive operation, just unlock, a paired Apple Watch can also be configured to unlock the iPhone.
- I'm finding it hard to believe that BlackRock doesn't understand Goodhart's Law. Surely they wouldn't be where they are without being able to rationally optimize for the objective of profit.
Presuming competence, it seems that one of the following must be true: either (1) external coercion plausibly threatened profits enough that a more controlled sacrifice of profit (call it a tribute or blood money) was objectively preferable, or (2) profit is no longer the objective.
One doesn't have to presume competence, but I don't know enough about BlackRock's leadership structure to meaningfully comment on that.
- Apple CarPlay may have given automakers just barely enough of an "out" that the pressure is reduced. The only time I use the system's own interface is to update its firmware once a year, and the only time those updates have noticeably mattered was to make my car compatible with CarPlay over USB Type-C.
Given this, it's surprising to me to see reluctance to adopting second-generation CarPlay, but someone who knows more about the tradeoffs can certainly account for that better than I can.
- This reminds me of a depressingly common mistake in web design that seems to affect almost every internet banking system and most government web sites. You know the one: having an "inbox" of automated messages with a number in the corner, which you slowly see tick up as you check the website a couple of times per year for a decade or two.
It's the most user-hostile web design imaginable, far beyond just being ugly or unclear, because it creates busywork or stress or both. It's effectively saying that you might have an actually important update to read, but you won't know that unless you sit down to read dozens of automated messages to sift through them; and if you don't have time or motivation to do that right now, you're left wondering if you're making a mistake that might cost you down the line, especially when it comes to many of the kinds of websites that choose to do this.
If you actually want a user to take action, you need to tell them that front-and-center in the first page after the user is authenticated, and design cues like size and color can help with that. A truly serious matter can put a modal in the flow. They have no problem doing this for the triviality of requiring you to change your password "for your security"[1], but a message about possible financial consequences is unread message #73.
[1] They had a breach they hope you don't know or care about.
- Even dealing with point of sale and customer support issues becomes a lot easier when they know you're a few taps on your phone away from reversing a transaction. Make it clear that it's something you're very comfortable with, routine even, not a bother at all, and almost like you're doing them a favor by handling it on your end. They won't see it that way, of course, but it gives you all the leverage in the negotiation without it getting ugly.
Try it next time someone says their point of sale policy only lets them offer you store credit or an exchange. Say, oh that's fine, my credit card lets me reverse the transaction if I couldn't resolve the matter with the store, so I'll just do that. The very next response will be a miraculous change in the store's policy.
- Fun fact: part of why TOML 1.1 has taken so long to land is because of open questions around unicode key normalization. That in itself sounds dry and boring, but the discussion threads are anything but.
https://github.com/toml-lang/toml/issues/994
https://github.com/toml-lang/toml/issues/966
- I inherited a project where a dozen different entity kinds were all given UUIDv4s. Users mostly see namespaced strings, but actually searching by those strings is janky and unreliable for other reasons (including the fact that they can change), so whenever I'm asked to debug something I insist on reducing to UUIDs first so at least we're definitely looking at the same entities.
I didn't like the UUIDs at first, but it ended up being an unexpected boon for generic code to use the same key type for different entity kinds. What was less of a boon was that the string identifiers also have to be unique, but can change at any time, and depend on three-level namespacing (yes really) so there's far more that has to be tracked and enforced. The names are very important for UI use cases, but can never be the way that records reference other records, because that would just make them much harder to change with confidence.
The essay seems to assume you'll have either unique natural keys or unique synthetic keys, but having now worked on a project that does both at the same time for many entities, I think it's a third option worthy of its own analysis. My experience was negative but I can't deny that the end result ticks a lot of functional boxes.
- > In a context world, you would use io.Writer/Reader or net.Conn to write small bits of data and check whether the context is cancelled in between 1KB writes (or whatever size).
That can still block pretty much indefinitely. Imagine you're a client reading from a server, but the server isn't in any hurry to send anything, and keepalives are keeping the TCP connection open, and no network blips occur for months, so your goroutine is blocked on that read for months.
The much simpler and more robust thing is to propagate context cancellation to socket close. The close will abort any blocked reads or writes.
e.g.
You'll still observe and return an error in the read/write call, and close is idempotent, so this doesn't take anything away from your existing logic and really just acts as a way to propagate cancellation.go func() { <-ctx.Done() _ = conn.Close() }()I don't know how well this works for other types of closeable reader/writer implementations. It may not even be thread-safe for some of them. But this worked great when I tried it for sockets.
> I typically just defer a function in the goroutine that either writes to an "IsDead" channel or sets a mutex-protected boolean
I try to just use `errgroup` whenever possible, even if no error can be returned. It's just the most fool-proof way I've found to make sure you return only when all nested goroutines are returned, and if you're consistent about it then this applies recursively too. It's a way to fake "structured concurrency" with quite readable code and very few downsides.