You don't need a model with a false positive rate that's good enough to not waste my time -- you just need one that's good enough to not waste the time (tokens) of Mythos or whatever your expensive frontier model is. Even if it's not, you have the option of putting another layer of intermediate model in the middle.

To be clear, this isn't part of Magic Kingdom or one of the proper Disney theme parks. This is a shopping area, open to the public without admission.

For a closer scenario: the cruise ship docks at one of its stops for a day. The area around where the ship docks is owned by Royal Caribbean but open to the public. Most of the stores are privately owned and operated, leasing space from Royal Caribbean. One of those stores is a theater that runs a chainsaw juggling show. Royal Caribbean's website/app includes the full schedule of that theater and highlights that show as perfectly-safe-we-assure-you. Your dad attends that show and gets bisected.

The key point here, entirely not captured by your scenario: the theory making Disney plausibly liable is that Disney's own online services presented this restaurant and its menus which made the plaintiff believe that the restaurant was subject to Disney's allergy standards. It is not at all unreasonable to say that EULAs for those online services are relevant to this dispute.

The argument was not "they agreed to a EULA 5 years ago and therefore mandatory arbitration in all disputes with Disney".

This is a privately owned restaurant at a glorified shopping mall within the larger Walt Disney World resort. If you died due to a severe allergic reaction at a normal restaurant in a normal shopping mall in Florida the mall owners would generally not be liable unless there's something else going on.

The theory that Disney is liable here is more than anything based on the *restaurant featuring on their app.* The EULA for *that app* would certainly be relevant to this argument.

Now, the Disney lawyers also tried to argue that the Disney+ EULA would actually (at least plausibly) be relevant. That is more than a bit of a stretch, especially for a free trial from years ago, and I'd be surprised (but IANAL) if such a theory would actually hold up in court. Still, on a spectrum from "person died due to maintenance failure on a Magic Kingdom ride" to "person died from going to a restaurant featured on a Disney+ program", if you're arguing that the Disney+ EULA is relevant, this is a whole lot closer to the latter than the former.

On a related note, your program code is very likely (mostly) clean file backed pages.

Of course, in the modern era of SSDs this isn't as big of a problem, but in the late days of running serious systems with OS/programs on spinning rust I regularly saw full blown collapse this way, like processes getting stuck for tens of seconds as every process on the system was contending on a single disk pagefaulting as they execute code.

Like, last I looked the Linux kernel still had MFM/RLL support, although I'm not sure that's going to get included even as a module in a modern distro.

You presumably want them to run as any (non root) user. The capability you need for that, to impersonate arbitrary (non-root) users on the system, is pretty damn close to being root.

With that said, at least for C and C++, the behavior of (std::)atomic when dealing with interprocess interactions is slightly outside the scope of the standard, but in practice (and at least recommended by the C++ standard) (atomic_)is_lock_free() atomics are generally usable between processes.

While the advice is sound, this number isn't the right number for this argument.

That 10^15 number is for UREs, which aren't going to cause silent data corruption -- simple naive RAID style mirroring/parity will easily recover from a known error of this sort without any filesystem layer checksumming. The rates for silent errors, where the disk returns the wrong data that benefit from checksumming, are a couple of orders of magnitude lower.

With that said, I'm pretty sure it is a feature of the TCP stack only because the TCP stack is the layer they were trying to solve this problem at, and it isn't clear at all that "unacked data" is particularly better than a timer -- and of course if you actually do want to implement application layer Nagle directly, delayed acks mean that application level acking is a lot less likely to require an extra packet.

mv /bin/laden /dev/null

and then someone explained how that was broken: even if that succeeds, what you've done is to replace the device file /dev/null with the regular file that was previously at /bin/laden, and then whenever other things redirect their output to /dev/null they'll be overwriting this random file than having output be discarded immediately, which is moderately bad.

Your version will just fail (even assuming root) because mv won't let you replace a file with a directory.

Two issues: 1. If you're making this choice during an earthquake, "outside" is often not a grassy field but rather the fall zone for debris from whatever building you're exiting. 2. If the earthquake is big/strong enough that you're in any real danger of building level issues, the shaking will be strong enough that if you try to run for the outside you're very likely to just fall and injure yourself.

I have read many hundreds of books this way.

The problem with a tablet is that most tablets, especially the sort that are good for seeing entire as-printed pages at once, are too big for me to keep the entire screen in focus without wearing glasses. (with that said, foldables improve things here, since the aspect ratio bottleneck is typically width so being able to double the width on the fly makes such things more readable.

In the modern era, a lightly (or at least stably) loaded system lasting for hundreds or even thousands of days without crashing or needing a reboot should be a baseline unremarkable expectation -- but that implies that you don't need security updates, which means the system needs to not be exposed to the internet.

On the other hand, every time you do a software update you put the system in a weird spot that is potentially subtly different from where it would be on a fresh reboot, unless you restart all of userspace (at which point you might as well just reboot).

And of course FreeBSD hasn't implemented kernel live patching -- but then, that isn't a "long uptime" solution anyway, the point of live patching is to keep the system running safely until your next maintenance window.

Flex Alerts are CAISO and ultimately about grid stability. SmartRate/SmartDay are ultimately about marginal cost of production on PG&E. The two are certainly correlated -- at the very least, a Flex Alert day is almost guaranteed to be a SmartDay.

Notably, the SmartRate program is capped at 15 days per year, and in practice PG&E will keep a few in reserve for surprise late season events, but even if there are no Flex Alert days they're still going to be called on electricity-is-expensive-even-if-the-grid-is-stable days.

There is real cost savings here -- the RPi5 avoided the need for a buck circuit, and for that matter probably a dedicated PD controller chip.

In contrast, in the context of a "cheap vape pen" you have a battery which means you need to be able to convert to (and from!) battery voltage, so you need that conversion circuitry anyway.

With that said, DisplayPort Alternate Mode would be considerably more straightforward.

The point is that power dissipation in a cable is a function of the current going through it. The cable will get exactly as hot carrying 5 amps with a voltage of 5 volts as it will carrying 20 or 48.

(now, that is more *wasteful* -- you lose the same amount of power to heat carrying 25W at 5V5A as you do at 100W 20V5A, but that's 4x the relative waste in power)

> Many people just grab any usbc cable, and solder it directly to GPIO power pins.

You're not going to get *any* 5 amp mode out of a standard PD power supply unless the cable indicates it is 5 amp capable, which isn't going to happen unless that "any usbc cable" has the right emarker on it.

> limit for 5 volts is 3 amps.

There is no such limit.

What there is is two things: 1. There are a standard set of PDOs a standard "X watt" PD power supply is supposed to provide. 5V3A 9V3A 15V3A 20V5A, (then 28, 36, and 48 volts for EPR) with the highest one limited to the power limit of the supply. These only go up to 3 amps until you get to 20 volts. 2. Devices are supposed to support those standard PDOs.

Anything other than those standard PDOs is optional (at least before 3.2 which starts introducing AVS as a requirement at 27W+). 12V support is common, as for that matter is PPS support. 5A support below 20V in fixed PDOs is 100% allowed but is super rare.

(5A lower voltage PPS is a different story, but unfortunately the RPi5 doesn't know how to negotiate 5V PPS. That is a shame because it would 100x its power supply compatibility because most chargers targeting higher end Samsung phones support it.)

A power supply is 100% allowed to support 5V5A. It just isn't required to. It would have been 100% legitimate for the RPi5 to have a buck circuit to handle a standard 27W 9V3A power supply and then turn that buck off if the power supply and cable support 5V5A.

> Initial batches of Pi4 did not even had a resistor, to request 3.0 amps!

To be precise, it had *a* resistor (connected to the shorted together CC pins) when it was supposed to have one separate resistor for each pin, and that broke cables with emarkers.