But then you risk tariff policy changing, and suddenly you're undercut by foreign factories again, and you lose all your investment in the American factory. It still needs certainty that the tariffs are staying.
The uncertainty only works to return manufacturing where America is cost-competitive without tariffs, and that's a tiny slice of manufacturing.
> I guess I was assuming almost $20k a year back then would have been livable back then, like it was for much of the US excluding a handful of cities like NYC or SF at the time.
You're excluding the reasonable comparables. London is the UK's equivalent of NYC or SF.
They're a pharmacy, they get directly reimbursed by customer's drug insurance plans and only charge customers for the uninsured amount. They need to submit prescriptions to insurance, and find out how much insurance is covering, before filling prescriptions.
You are mistakening medical insurance with computer/cyber insurance.
The post above you is talking about having manual communication with the provincial and federal medical insurance (Canada has national insurance) to confirm customers have the appropriate insurance ready so they can dispense pills, medication, and medical equipment, which is life critical equipment and supplies for many of their customers, without access to computers (which is doable if they had the procedures ready)
It’s to do with business continuity of the pharmacy’s work, nothing to do with breach.
> it won't (logistically can't) work when you have literally run out.
While I believe you're correct for the iPhone, that it won't work, it's actually not as impossible as you suggest. The NFC-capable BlackBerrys that supported the very early tap-to-pay with a phone had the concept of a default card, which could be programmed onto the secure element and would work even if the phone was totally dead (even if the battery was removed). The NFC field was enough power to boot up the secure element, just like it's enough power to run the chip in your bank card when you tap it.
Later phones dropped this support, as it took a bunch of engineering effort and customers largely didn't care. But if customers ever start demanding it, so they can totally stop carrying a bank/credit card, it is possible.
I suspect that the tiny amount of power you can vampire to make NFC work (which is why your contactless bank cards work as you explained) isn't enough for even the basic features we now expect from a smart phone as payment device.
So you'd have to message this very carefully, on top of the engineering effort, and my guess is that in reality "Reserve power" is always enough. If your phone "died" (screen turned off for lack of power) at the party, you have several hours after that when it can still do enough NFC to get on the bus home.
A lot of my friends get anxious at like 10%. Sure, at that point you should probably stop playing Candy Crush, but you're a long way from not being able to tap in to your train home if you stop. Power Reserve seems like a sensible choice to make you stop using the last dregs for frivolities.
We might see this again, as the Pixel 8 Pro has a system like this for UWB so your phone can be located by the Find My Device network after its power is drained.
> Why are you including only US airlines for comparing a plane model's safety? That seems very convenient
737 MAXs are not identical worldwide. There's a number of optional add-ons, which even discount US airlines will pay for, but emerging market discount airlines will not.
Specifically for the 737 MAX crashes, it was from a faulty AoA sensor. Neither of the crashed planes had the AoA disagree alert option, but all US airlines paid extra for it. It's not something you're supposed to need, hence being an optional extra, but for obvious reasons budgets aren't as tight at North American airlines as discount airlines in emerging markets.
This isn't to say we're guaranteed that an AoA disagree alert would have avoided the problem, it was undeniably a faulty design, but it probably provides an additional layer of safety. There's a reason that when the MAX returned to service it became standard equipment for all MAXs sold.
So, it's not entirely correct to totally exclude planes from other countries. But there is a fair point in putting more weight on similarly configured planes.
A company reckless enough to make "no single point a failure" a pay-for optional feature is not a company whose planes I would like to fly on, regardless of where the company operating the plane is registered.
Not trying to defend Boeing overall here, but showing an explicit indication of an AoA sensor disagreement wouldn't magically have averted the two 737 MAX crashes. The basic cause of the crashes (apart from Boeing's dumb design decisions) was the pilots' failure to correctly execute the runaway stabilizer trim recovery procedure. Given that 737 MAX pilots didn't receive any training on MCAS, it's unlikely that the warning light would have greatly influenced their response to the situation.
I actually specifically mentioned airlines operating in the U.S., which includes international flights operated by foreign airlines. But yes, you get to the heart of the matter. The U.S. in general expends more time and effort on safety: higher-spec airplanes, more crew hours and training, better maintenance, etc.
It doesn’t feel relevant to most people on this site to include airlines operating on a shoestring budget in Southeast Asia or Africa in the statistics. It also doesn’t feel fair to manufacturers to penalize them for operators that barely maintain their planes, overfly inexperienced pilots, and that lack basic safety regulation.
> Chrome/Chromium was developed for quite a while using Webkit. Chromium was created in 2008 and only after Google had already captured a third of the browser market share (according to Statista) did they fork it (April 2013).
I think you missed the point, there's two forks in the history of Blink (Chromium). Yes, Blink is a fork of WebKit, but WebKit is a fork of KHTML. So it's not like it originated at Apple either, it originated at KDE.
I did not miss the point, I just don't see why it's relevant. This isn't a thread about Apple's products and their success. The fact that Apple started from KHTML is not really relevant. However, it's clear that at the beginning Google was very dependent on Webkit and Apple, and there's a good reason why it took them five years of gaining development expertise and market share before forking Webkit.
I've already stated that Chrome's success is not just because that it was forked from Webkit (e.g. v8, and other things that people mentioned here as well), but it was a huge jumpstart for them, and it would've taken them much longer to get a leading browser without it. e.g. Microsoft basically gave up on developing their own engine after failing with IE and the original Edge - and are now also based on Chromium.
Chrome is (IMO) much better than Safari, Maps is (IMO) a great product, Youtube is a a huge success and much bigger than it was when they bought it (homegrown Google Video failed), Android was also essentially an acquihire, as others have mentioned (using a lot of Google's resources) and is hugely successful. It doesn't change the fact that most existing Google products today are acquisitions that they improved, and not home-grown products from the "20% do your own thing" era - which is what the original comment talked about.
The point is that they're not really comparable. Mint/Ubuntu/etc all ship the same Linux kernel, that's why they're called distros. They're different distributions (distros) of the same software (Linux kernel, etc).
The different BSDs aren't distros, they are different kernels that are developed in parallel. Obviously there's shared history there, and some shared userspace, but FreeBSD and OpenBSD aren't just two different BSD distros of largely the same software.
Reminds me of the skydiver who dropped his camera and you can watch it spin and eventually land in a pigpond where a pig investigates it. It’s on YouTube.
SpaceX has a median turnaround time between landing and re-launch of about 8 weeks, with some as low as 3 weeks. That includes time for returning the landing platform to port, unloading, payload integration of the new payload, etc, so refurbishment is some fraction of that.
There's no way they're stripping the whole thing down and replacing 30% of parts in that short of a timeframe. Especially given they do it in Florida, and don't bring them back to the factory. So it's hard to say for sure, but the time can give us some sense of what they must be doing.
Right, those were two extreme ends of a spectrum I presented, both of which are obviously not true. What I don't know is where on the spectrum their savings are.
It’s hard to compare because the rocket is designed to be reusable, but as someone that is both a fan of launch of vehicles and in/adjacent to the industry: 30-85%, and I’d bet it’s the high end. Falcon 9 is a really, really big deal in launch capability and affordability.
