The iPhone is designed to be a good smartphone, not a good NAS. It is silly to expect anyone to compromise the design of a mass market product to support some esoteric MacGyvering entirely unrelated to the original product.
Should we all expect Toyota to design their ECUs to be used as a NAS?
It's not about "design", because the iPhone is perfectly capable of running arbitrary code, it just refuses to do so if you're not Apple.
The situation is such that the legal owner of the device has less power over it, post-sale, than the company that made it.
That reason alone, the imbalance of power, should be enough to support abolishing those restrictions, preferably by law.
To be clear: this is something that should be beyond market forces, and it should apply to anything that is sold to consumers and can run code. The end goal should be that no user remain less powerful, in terms of code execution and access to content, than the manufacturer.
> It's not about "design", because the iPhone is perfectly capable of running arbitrary code
It is a very intentional UX choice to mitigate malware for users who do not know how to evaluate the legitimacy of software on their own. And studies show that this is a very effective policy, both perceived (e.g. marketing) and real (actual breach statistics).
You can mitigate malware while still allowing for the same level of end-user control as the manufacturer. Look at Windows itself! People getting infected on up-to-date installations is a rarity nowadays, all without draconian lockdown policies.
A NAS is just an example, here's a better one; I love to use my old phones as wall mounted displays and controls for home assistant, or as remote music players plugged in to some speakers that I can hook into in music assistant. Some of my old phones are more than capable of this hardware wise but are locked to older versions of android and can't run anything built for a newer version, so they end up as ewaste intstead.
I think my next phone is going to be a fairphone or something for this reason.
None of those are even remotely reasonable enough to be a higher priority design criteria than preventing little old ladies from unknowingly installing malware.
You can do this but you have to remove the battery and hook up the circuitry to external power. This practically turns the phone into a glorified SBC. It may still be worth it since there's more of a mass market for phones than SBCs (and phones come with lots of extra hardware components that can be useful) but it's not that huge of a win.
Of course Apple doesn’t want people to use their device in a way that’s not how they designed it. They’re very anal about the user experience, they don’t want kids to install ArchLinux on their grandparents iPhones, and have the grandparents complain that their phone is shit. I get that.
Conveniently, the way they designed the phone allows them to charge 30% of every transaction that happens on the device…
But that’s beyond the point. The point is that the iphone is a capable device, that probably can run macos, and it’s a waste that we’re not allowed to.
I'm all for antitrust action against the financial trap that is the app store. But as someone who designs products, I think it's absolutely asinine to require security flaws in a product's primary design to support an untended repurposing.
I guess I don’t see how allowing some phone owners to root their devices introduces security flaws for those who don’t. Maybe there’s something I’m missing here.
$189 billion of USDA's $213 billion budget is the Food and Nutrition Service. They're administering SNAP, WIC, school lunch programs, etc. These jobs are policy, distributing money, coordination with state programs, etc.
There's a different answer "why" to each of these programs' origin stories, but in general, they were a response to issues that previously existed and weren't being addressed. e.g. the school lunch program was created because we don't expect children to skip meals at school due to their parents inability to provide for them. And it was done nationally because many states failed to solve the issue themselves.
The small percentage of USDA employees that are in the DC area are mostly administering policy related things which absolutely make sense to be in that area.
I didn't know that, Sorry about that, but is there no way to make CDP debugger less detectable. Seems doable to me but maybe there's a catch if its not already done by somebody maybe?
The existing ultras are two max dies connected together with TSMC’s CoWoS-S interposer. But as I understand the interposer can have yield issues, so yes — you put two together, but it’s not quite as easy as snapping together legos.
Should we all expect Toyota to design their ECUs to be used as a NAS?
reply