The problem with Apple's execution of Liquid Glass is that the intended audience isn't the iOS user, it's the onlooker watching the iOS user (FOMO). That was an effective strategy when iPhone popularity was growing rapidly. Now that we're in a plateau of market saturation (post-peak Apple), anything directed at the onlooker which detracts for the actual user will hurt their bottom line.
How would this work? The only place I've ever heard of liquid glass is from iPhone users complaining about it incessantly and tutorials on how to turn it off or diminish it. What would I fear missing out on?
Interesting read. I had the Abit BP6 and it was a killer in performance/price. The problem I had with it wasn't the capacitors but rather that the PCB itself was a bit thin to support 2x CPUs/fans.
Another cool thing was that the BP6 supported Ultra DMA/66 (aka ATA/66) and it did so by adding a second controller so you had twice as many buses. Looking a pic of it now, it really was a Franken-machine with AGP, PCI, ISA busses too.
Yeah that line gave me a twitch. Reading on though it's more about the resulting coherence and correctness rather than like the Ralph Waldo Emerson quote: "A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines."
I agree. It's only the foolish consistency that's problematic. A sensible consistency does, as you say, provide a coherence. William James, who overlapped Emerson, has a lot to say about positive habits.
I would hope that a large successful online retailer got that way by factoring their implementation so that many aspects can be dealt with mostly as a configuration matter. This is mistaking quantity for difficulty. First of all, separate the domains fulfillment doesn't care about pricing, but they do care about grouping items in a shipment so they should already have had grouping rules, so apply the 'do not ship this item alone' rule, etc. The other pattern to apply repeatedly here is to separate the decision-making from effecting a change, i.e. separation of policy from mechanism. So you can have a library of mechanisms (e.g. add item to order at checkout) vs the policies which decide who, which item, and what to charge. If you don't conflate all these separate concerns as a single 'thing' to begin with, then none of the individual things is complicated, just has to be the right things in the right places.
This thought processes does use some knowledge of online retail but not really that much. It's mostly patterns of system decomposition and good engineering.
Edit: the point of the article itself stands, if the codebase is in no shape to have these free samples built as I described then my input is useless, other than to consider working toward that architectural goal.
It is though, responsibility goes up to the CEO, and I don't think he was ever accused of having any taste. It was a long time coming but it has come to fruition. Apple today has no taste, no restraint. They're not far behind MS jamming ads & AI places they shouldn't be.
The day that I need to update to macOS 26 for continued security patches is the last day I'll choose to run macOS. I'm pretty much all on Linux for non-work stuff anyway with an old Windows 'gaming' PC that only runs a 10 year old game.
> update to macOS 26 for continued security patches
Are you certain that is not already the case? Or do we still truly believe Apple has the capacity, resources and motivation to care about two version of their operating system at one time?
I would definitely use an LLM, to see what the suggested options do and tweak them.
Using a different package name could be helpful. I searched for ezff docs and found a completely different Python library. Also ez-ffmpeg turns up a Rust lib which looks great if calling from Rust.
reply