delroth

> a non-issue at scale business-wise in modern data centers.

I've worked on similar stuff in the past at Google and you couldn't be more wrong. For example, if your CPU screwed up an AES calculation involved in wrapping an encryption key, you might end up with fairly large amounts of data that can't be decrypted anymore. Sometimes the failures are symmetric enough that the same machine might be able to decrypt the data it corrupted, which means a single machine might not be able to easily detect such problems.

We used to run extensive crypto self testing as part of the initialization of our KMS service for that reason.

Your obsession with how people decide to present themselves is what's creepy and weird.

And yet that's basically the same experience as in Zürich, Switzerland - a city where almost half of the inhabitants are immigrants.

The Swiss rail network is small but very dense, very punctual, and extremely well designed (the timetable is optimized countrywide across most public transit operators to allow for smooth transfers - it's very rare to require a transfer with more than 15min wait). And it shows in passenger-kilometers stats: about 20% as much as Germany, even though Switzerland is 10% the area and 10% the population of Germany (roughly).

Japan has many things going for it but also some notable issues. The various private operators can be confusing ("oh, your train doesn't leave from platform 4 in this building, it leaves from platform 4 in the Odakyu building"). There is virtually no transit available at night, even within the large metros. Once you leave the main lines the service frequency can be very spotty and the transfers very badly designed. No bike transport even on smaller regional trains (not counting "disassembled in a bike bag" as bike transport).

Usually you'd vary the concentration of boric acid being injected in the reactor's core instead, since that doesn't involve wear and tear on safety-critical elements of the reactor.

Nuclear reactors absolutely can vary their output to match demand, this is what France has been doing for 50+ years (and what Germany was doing before switching back to coal). It's not as reactive as coal/gas, but you can still vary within 30-100% of output power at a speed of 5% change per minute. Way more than enough to react to 1-day-ahead forecasted supply/demand, and way more than enough to react minute-by-minute if you've got a tiny bit of storage to stabilize the grid's frequency (e.g. pumped hydro).

You're just making stuff up at this point with no evidence or source. If the intention was to forbid dynamic fetching of declarativeNetRequest filter lists, Google could also just... not have dynamic filter lists.

> I think the article is talking specifically about downloading and running scripts for working around a particular site dynamically

The article specifically mentions "filter lists" being subject to review time.

> All updates, even to benign things like a filtering list, will need to happen through full extension updates through the Chrome Web Store.

> Is a filtering list update, which is essentially just a list of websites, really something that needs to be limited by the "no remotely hosted code" policy?

> So since all filter list updates now need to go through the Chrome Web Store, how long does a review take?

What about MV3 requires going through the Chrome Web Store to update block lists? A quick look at the declarativeNetRequest docs (https://developer.chrome.com/docs/extensions/reference/decla...) shows that there are indeed static rulesets which need to be declared in the extension's manifest, but also dynamic rulesets which can be updated via JavaScript (and so presumably can be fetched and updated dynamically). I can't seem to find any specific limitation of dynamic rulesets vs. static rulesets.

> Didn't France very recently have to shut down or limit a bunch of reactors due to <checks notes> the river water being too warm.

Because of environmental limits to protect the river ecosystems, not because of any safety or operational constraints. Many of these limits were set years ago, when the water temperature in rivers was lower, and haven't been increased since - leading to very tight margins. When the grid is stretched, the plant operators usually get a temporary authorization to exceed the environmental limits.

Every year this is big news for some reason, even though it amounts to a roughly 0.3% reduction of yearly electricity generation. It only impacts river cooled plants, and only those that don't also have a cooling tower.

> How do you know?

Because I read more than random out of context tweets as my source of information.

> Is there another email that mentions Omnibox?

Yes. It's linked in multiple places in this very HN thread. Page 4 in the original justice.gov PDF specifically mentions the experiment that was done as a result of that originally quoted "complaint" email, and says "start experiments to improve search ranking in the omnibox".

In context it's pretty obvious this is talking about omnibox suggestion rankings (which is also what changed and had the claimed "unwanted" impact), not search rankings.

Both dropped after very significant internal outcry, even though they'd have objectively been very profitable ventures for Google.

See https://github.com/AsahiLinux/docs/wiki/HW%3AUSB-PD - some of the USB-C ports respond to USB PD Vendor-Defined Messages to trigger a bunch of debug features, including rebooting the SoC or configuring one of the internal UARTs to output to two pins on the USB-C connector.

I'm not sure what you're trying to say, but "It is not trained on Gmail data." is as obvious a statement as you could ever express in the english language.

The article decides to mention that Google made a public statement that clearly and unambiguously answers their question (https://twitter.com/GoogleWorkspace/status/16382985371956019...) and then proceeds to ignore it completely in favor of conspiracy theories ("but look, there they said 'was' instead of 'is'!").

The law doesn't apply to connecting flights anyway.

No, France didn't ban short-haul flights. France banned 34 daily flights on 6 routes (ORY <-> {LYS, NTE, BOD}), and those flights were already not operating since 2020. No domestic flights from the largest airport was banned (CDG), no flights to/from MRS or RNS, etc.

This is because the law was pretty much designed to be useless. Flights are banned if you can make the trip by train within 2h30, with no changes, and with sufficient frequency and early/late enough trains to allow for an 8h day trip. Except that in the case of CDG they decided that it's not enough to be able to make the trip within 2h30 from Paris, you need to be able to do so from the TGV station at CDG airport. That's absurd, the vast majority of flights from CDG are from passengers in Paris, not passengers that start at CDG airport.

Because of that, CDG-BOD is still OK even though it's 2h05 by train from Paris. And CDG-LYS is also still allowed because they considered that there aren't early enough trains leaving from CDG airport currently.

It's basically just good PR with no teeth, and the journalists have been eating it up with zero fact checking.

> It's Asahi Lina who really did the kernel driver (building on Alyssa's reverse engineering work).

Mostly based on her own reverse engineering work actually (which was all livestreamed). Alyssa's work was on the shader ISA and what goes into the various command queues to get the GPU to do useful things, Lina's work was on the lower level aspects of how the queues even work, interactions with the firmware, power management, etc.

> Fukishima and Chernobyl are unlivable

Fukushima has barely any exclusion zone left, the last inhabited area was reopened around the beginning of last year.

As usual for ChatGPT this is full of mistakes and bad code. The buildPhase and installPhase it writes are completely unnecessary and worse than the default, the configurePhase might work in some cases but most likely won't, and it's unnecessary when instead autoreconfHook should be used, stdenv/autoconf should be taken as an argument for the function returning the derivation, autoconf should be a nativeBuildInput, make is already in stdenv, etc.

Looks like JMA says 9.0, USGS says 9.1. I don't really have enough expertise to know which number is more accurate, and I suspect it doesn't make a huge difference. It's in any case the highest magnitude earthquake ever recorded in Japan.

justin66: > Somehow France manages to get most of its electricity from nuclear reactors.

you: > Well, thats a good point: they don't.

The data I linked to you absolutely proves that they do, nuclear is the majority of electricity production in France even in its current production crisis state.

You are moving the goalposts in your reply, and I'm not interested in engaging any further given your dishonesty.

They absolutely do. Looking at November, https://www.rte-france.com/en/eco2mix/cross-border-electrici... will show you that Nov 19th was peak import with about 8GW net import at peak. On that day the French NPPs were on average producing 30GW of electricity out of a 55GW peak demand.

When looking at electricity imports/exports it's also important to remember that France is a pretty big interconnect between the UK, Spain, Italy, Switzerland, Belgium and Germany. A bunch of electricity might be imported in France just to resell it to Italy, which is notoriously lacking in electricity production.

> They did get unlucky with a 7.4 magnitude quake.

Magnitude 9.1, actually.

"broken", not really -- in practice anyone who cares about IPv6 connectivity does not use Cogent as their only upstream, or they learn very quickly that Cogent does not provide them with what they advertise. This might impact you if you're in the business of buying transit from a tier 1 provider, but that's virtually nobody.

(It's also far from the only issue you'll get as a Cogent customer, they're generally, uh, pretty shit.)

I have links to google.com/maps in my IRC logs dating back from June 2014, so this absolutely tracks.

I actually remember google.com/maps being launched at IO in 2014 -- the presentation had a broken link in it for the new version of Maps, and a few of us DoS SRE watching the livestream were able to hack together a config change in a few minutes to fix it without waiting for a urlmap push :)

> The change does have the effect of Google gaining more permissions (and subsequently more data)

There's a huge logic gap here. Obtaining more permissions doesn't at all imply obtaining more data when it's caused by an incidental change. Maybe the permissions aren't being used outside of the Maps context, or maybe it doesn't matter because the data was already be known.

How is this relevant to this article given that Firefox has never shipped JPEG XL support in a public build? Not even behind an experimental flag like Chrome did.

JPEG XL is based on Google's Pik, and several of the top contributors to libjxl are on Google's payroll: https://github.com/libjxl/libjxl/graphs/contributors

I can't seem to find the same search result with this query. In fact, searching for "google" "standard TCP" doesn't seem to find any such article (only Google's 2011 publication on TCP Fast-Open deployment, ironically), so it's going to be hard to find what you're talking about.

If you link to the article in question (and relevant quotes) I'm happy to try and clarify your misunderstanding.