But we also want devices that are thin and lightweight. Watertight battery compartments are super easy (barely an inconvenience) if you "just" make the device thicker and heavier.
I remember early cell phones (not smart phones, mind you) having weeks of standby time, or something like 20 hours of talk time. These had replaceable batteries. I don't recall people carrying spare batteries being a thing..?
Standby times were indeed great in those days because those phones weren’t doing very much when they were idle. (Weeks may be an exaggeration, though!)
You might also be misremembering talk times, unless you had a phone with an exceptionally large battery.
A typical device like the Nokia 3210 had 3-4 hours talk time, which is far less than modern smartphones.
Some of my early phones had spare batteries. They most certainly did NOT have weeks of standby time or 20 hours of talk time. We are talking late 90's.
Later, as phones and batteries got better, the spare batteries became unnecessary. They still degraded fast enough that there was a market for replacement batteries and they could indeed easily be replaced. We are talking things like the Nokia 3310.
Even later, the need for user replaceable batteries pretty much disappeared.
HP makes them, so does Dell. They cost a bit extra, but essentially the whole Federal government runs on nothing else.
The difference between EU and US is that it's possible to make all components in the US, using US equipment, and so some companies do because it commands a pretty decent premium. It's not even that hard since most components (e.g. reference motherboard designs) are still designed and actually built in the US. China still really mostly does what you might politely call "commercializes US tech". And let's not discuss too deeply if they correctly pay licensing for all the components they make, because nobody enjoys that discussion.
And yep, as you might expect, only Intel chips, no Nvidia cards ... and that's not the end of the limitations. The previous version had no USB-C monitor support, never mind one USB-C cable to multiple monitors, but last year intel really pushed a bit harder. But even this year, I'd hope you're not going to be trying to use these machines for gaming.
The EU can't even make a modern motherboard's USB port chip.
Oh and yes, there are cracks in the US version too. The phones used, for example, are iPhones. Radio designed in South Korea ...
I'm rather curious where in the US HP and Dell source, let's say, their displays?
And while many (but certainly not all) of the other components could be made in the US, it's expensive and capacity is limited. So even the likes of HP and Dell have most of it done in Asia. Even Intel chips generally pass through Asia for assembly and testing, and their modern CPU tiles are likely to include TSMC-fabricated components.
All this is to say: the US is not tech independent (unless ancient tech counts). No single country is.
Though if you're just trying to say that the EU is significantly more tech-dependent than the US then I agree of course.
The most technologically critical component of ASML's EUV lithography machines (the EUV light source) is designed, developed, and manufactured in California by Cymer.
> forces the Dutch government to put export controls on some of their machines
That's because the critical EUV light source technology is developed in California by a US-based subsidiary of ASML. The US and EU have mutual interest in protecting the technology and machines. If export control agreements were not in place then ASML would have never been permitted to acquire Cymer. And if they are not enforced then the US would almost certainly require ASML to sell Cymer back to US ownership, TikTok-style.
> Is that an easy mistake to make and a hard one to recover from, in your experience?
If you're alone in a codebase? Probably not.
In a company with many contributors of varying degrees of competence (from your new grad to your incompetent senior staff), yes.
In large repositories, without extremely diligent reviewers, it's impossible to prevent developers from creating the most convoluted anti-patterny spaghetti code, that will get copy/pasted ad nauseam across your codebase.
Terraform as a tool and HCL as a programming language leave a lot to be desire (in hindsight only, because, let's be honest, it's been a boon for automation), but their constrained nature makes it easier to reign in the zealous junior developer who just discovered OOP and insists on trying it everywhere...
Let my geriatric self rephrase this for you and make the point more obvious: "[...] who just discovered [insert latest design pattern trend of your choice] and insists on trying it everywhere"
Isn't that largely nationalism and pressuring companies to use (initially) mediocre local tech solutions though? Once the market is there, quality catches up rapidly.
GUI apps are good for discoverability. They generally are not optimized for rapid use by power users though. That's of course not an inherent limitation of GUI apps, it's just that dominant paradigms hardly seem to consider power users.
I'm still annoyed and baffled by the fact that Ubuntu had searchable application menus 10 years ago, which were awesome and worked for just about any program, and then dropped them when they abandoned Unity. And neither KDE not Gnome thought to bring them back. In stead, many apps have since dropped application menus entirely, in favour of... some mishmash of icons and ad hoc menu buttons?
Also, even in the post-LLM era, building a decent GUI app is a lot more work than building a decent terminal app.
Another factor is the lack of a good cross-platform GUI toolkit (by which I mean one that (a) doesn't feel out-of-place and jarring on any platform and (b) doesn't turn a 50K app into a 1GB download.)
Between that and the level of complexity of modern GUI toolkits - and the size of their dependency trees - distribution of a GUI app is a much bigger headache than distributing a terminal app.
That hasn't been true for a while, it's easily the best of the bunch at this point. It's also always been trivial to change, which can't be said of the others.
On Smartcards yes, maybe Android, but certainly not on iPhones. On iOS, it's only been possible to implement alternatives to Apple Pay since 17.4 (2024), and only in Europe (EEA).
But they already had their own solutions that worked just fine. I can't see how switching to integrate a new system instead would save on dev costs. There surely must be some other reason?
reply