The transcoding isn't just about bandwidth, it's about compatibility. I store most media in H.265 because that's the most space efficient, and most things can play it, but a decent number of devices still need H.264. I also have older content with DTS soundtracks, which isn't supported by a bunch of new devices.
Plex/Emby/Jellyfin will handle that compatibility by converting on the fly.
Plus, when using a Fire Stick, or Google TV Streamer, or old Chromecast it just isn't easy/possible to browse a SMB share.
Yeah I would definitely need to look into some kind of real time transcoding setup (jellyfin, etc) if I had a use case for remote watching of things on any other less-capable platforms, particularly that can't handle x265 or AV1 encoded things.
Right now if I'm not at home, and I'm watching something remotely that's served from a home fileserver, the only two client devices that I have in use are either my MacOS laptop (VLC), or a fairly recent Android phone with a file explorer app that supports sshfs mounts to open files (again VLC as the video player).
> Honestly, at this point, having natural disasters with destruction and death is probably the only way to make people care
We already have them. People just claim they're chance effects with no connection to climate change.
The problem with refuting it is that they are chance events, there's no way to definitively say "this was caused by climate change", because it's always possible it would have happened anyways. It's the upwards trend in frequency and severity that we can definitively point and say "that's caused by climate change", but that's too abstract for most people to understand.
At least for Waymo, the remote control is not nearly that direct. The human operators suggest a route through a confusing scene, but the self driving remains in control for executing that suggested route, and may reject it.
A remote operator driving directly, via a racing sim setup or an Xbox controller, just isn't safe. Too much latency, lack of visibility, and connection unreliability.
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.
Plex/Emby/Jellyfin will handle that compatibility by converting on the fly.
Plus, when using a Fire Stick, or Google TV Streamer, or old Chromecast it just isn't easy/possible to browse a SMB share.