> The nice thing about Apple Intelligence is that it has an easy to find off switch for customers who don't care for it.
Not even only that, but the setup wizard literally asks if you'd like it or not. You don't even have to specifically opt-out of it, because it's opt-in.
I checked out the linked GitHub repo https://github.com/ecosyste-ms/package-manager-resolvers and it appears to be just a README.md that collects summaries of different package managers? How do I know these weren't just LLM-generated?
I feel it's not that controversial to treat LLM output as unreliable without proper verification. So even if the output were accurate, if it's LLM-generated without proper verification I don't trust it.
I think I like the idea, but the structure of the code doesn't look the best. What most sticks out to me is the "Managers" directory. I've seen similar patterns before, even at my current place of work, but they seem to correlate with less experienced implementations. For instance, I clicked on one of them randomly and already found an issue: https://github.com/nook-browser/Nook/blob/09a4c6957a2e9fd7c5...
I guess `www.` (and only `www.`) is always special, and the only TLDs with two components are `"co.uk", "co.jp", "com.au", "co.nz", "com.br"`?
I don't know how critical this "Manager" is (what even is a "boost"?), but a web browser should absolutely have a proper list of TLDs!
> What most sticks out to me is the "Managers" directory. I've seen similar patterns before, even at my current place of work, but they seem to correlate with less experienced implementations
What is wrong with such structure? How would you structure this code? Genuinely asking
There are no peer-reviewed studies yet for me to corroborate this with, but I've seen this pattern primarily from a specific type of autistic, and it's similar to an actor pattern: a Manager is expected to entirely "manage" whatever feature it's concerned with. This is usually different from a simple module by not collecting related functionality regarding the feature, but rather trying to contain the entire feature itself.
This typically creates artifacts like each "Manager" owning too much of its implementation (not benefiting from or contributing to shared structures, such as a proper domain suffix list), inconsistency between different parts of the app (since different "Managers" don't necessarily share common patterns between them), and tons of hooks into random "Managers" all over the code.
To me, it feels a bit like an "emotionally driven" architecture, where the organization of the code is based on the list of features of the app, and not based on the implementation of those features. So rather than having, for example, a drag and drop component for the tabs to use, you would have, for example, a ReorderingTabsManager, and the implementation may behave differently than drag and drop in other places. So rather than factoring out code into modules for deduplication, you're making modules ("Managers") based on where they are in the product, and duplicating functionality across each module, to varying standards of completeness and/or quality.
Now I don't know if this project is quite that egregious, but it hopefully illustrates why I raise an eyebrow when I see a project architected this way.
Apple Silicon actually has microarchitectural quirks implementing certain x86-isms in hardware for Rosetta 2 to use. I doubt any other ARM SoC would do such a thing, so I doubt third-party translation will ever get quite as efficient.
You also lose the ability to pull over virtually anywhere and refill your tank in five minutes, as well as the maintenance benefits that come from a decades-old design versus whatever software horrors are lurking in your car.
To top that all off, in parts of CA electricity is now 50c/kWh, which makes it roughly equally expensive to charge an EV as it is to buy a tank of gas.
I love electric cars, but there is a gap between what they COULD be and what they are.
The only reason to think an ICE vehicle doesn't have software horrors is if the vehicle in question is itself decades old. Practically every software horror of an EV is going to be found in modern ICE vehicles as well. In fact some of them have more horrors than some EVs. Subscription seat warmers anyone?
Sometimes we need dates attached - by the numbers (1838 of current 3176) that's probably some 5 or 6 years before ChatGTP. Or 3 or 4 years after the Netflix challenge.
reply