delroth

That's entirely untrue. Nuclear power plant designs used in France (and I think Germany?) participate in load following and can do so between 30-100% capacity at around 5%/min.

https://en.wikipedia.org/wiki/Nuclear_power_in_France#Operat...

https://en.wikipedia.org/wiki/Load_following_power_plant#Pre...

Do you have any example of situations where Google have "locked [anyone] out of [their] digital identity" for ad fraud?

As far as I can tell, this blog post is only mentioning the company's Android developer account being disabled. It in fact shows evidence that other access to the account is still available (e.g. screenshots from the account security checkup tool, which wouldn't be accessible if the whole account was disabled). This does seem limited in scale.

(Disclaimer: I work at Google, but not on anything related to this.)

We have a privacy policy which describes what we collect in a bit more details, see https://dolphin-emu.org/docs/privacy/

https://github.com/dolphin-emu/dolphin/blob/master/Source/Co... is the actual code which collects most of the information. We do multiple things to avoid being able to track user activity too much -- for example, while every instance of Dolphin has a unique ID so we can do things like unique counts, events that happen within a play session are associated to truncated_hash(unique ID + game ID) and not directly with the unique ID. This means that we can only correlate events from the same user playing the same game, but not* two events from one user playing different games.

* Our implementation is a bit weak given that the set of all gameids is small and enumerable. We could probably do better there.

We introduced some opt-in telemetry in dolphin-emu.org several years ago. I remember several times we discovered things we would likely have completely missed otherwise:

- We found out by looking at the distribution of software version that we had a strong holdout on one specific revision. It turns out we had a regression in a niche feature which was very important to a sub-community of our users, and users were basically telling each other to just use that old version. No bug report was filed until we found out via analytics and asked.

- We have a "game quirks" mechanism where the emulator reports weird edge cases that happen very rarely. Current list: https://github.com/dolphin-emu/dolphin/blob/master/Source/Co..., example usage: https://github.com/dolphin-emu/dolphin/blob/ffdc8538a162b1ca... . We used this to find games that use currently unimplemented or stubbed features.

- The list of popular games being played on the emulator was extremely surprising because it turns out there's a huge disconnect in what most NA/EU players are playing and what JP players are playing. This led to us adding a bunch of new games to the list we regularly test for performance and stability regressions. Would you have guessed that Inazuma Eleven GO: Strikers 2013 is in the top10 of emulated games on Dolphin?

> I'm still puzzled: Ampere list show at least 16 SKUs, imagine dealing with 16 different fabs, circuits, packages, specs, sales.

That's probably not what's happening though -- more likely, this is 1-4 different chips with aggressive yield management and some cores being fused off for the most entry level SKUs.

Pretty much all local city transport networks in Europe offer yearly subscriptions. If you just need that, that's already an option.

I'm not sure when you last tested, but my Synapse instance (v1.42) is currently using around 180MB RSS. I'm on a few rooms with 500+ users and multiple with 50+ users.

> > 125 Mbps? > 10 TB / 1 month.

That's ~32Mbps.

I still work at Google and I've also heard all of these stories. I have heard of multiple people transferring to other parts of the company or quitting because getting any kind of remote work arrangement while working under Urs was near impossible.

I still work at Google and can confirm that. From everything I've heard, Urs has strongly opposed remote work for years, causing multiple talented and senior people to quit.

> And if you look at their one line change commits, they do seem to be valid

By construction, yes. You're only looking at their commits that were merged into Linus's tree.

Not necessarily. Usually these very small cores end up being more architecture specific binaries than a stage0 consisting of gcc + some other core packages. A good illustration of this is that Guix's work on bootstrap seed reduction has been so far mostly applied to i686/amd64 and not even other architectures they support (at least, not fully).

This smaller bootstrap seed thing is a different problem from reproducible builds. nixpkgs does still have a pretty big initial TCB (aka. stage0) compared to Guix. But as far as I can tell NixOS has the upper hand in terms of how much can be built reproducibly (aka. the output hash matches across separate builds).

Did you mean A350 rather than A380?

No, Google didn't have this issue, because unlike pretty much all other search engines on the market Google isn't a frontend to Bing (well, I guess there are also a few frontends to Yandex, but they're more rare).

Context: Mark Kettenis has been porting OpenBSD to the M1 SoC, and is probably the only current user of that code.

The sad answer is that they can't be bothered to meet the quality standards expected for upstream kernel code. Easier to just throw garbage in a tarball and ship privesc vulnerabilities to millions of users.

"Displaying documents" and "displaying editable documents" are two completely different beasts. The web browser has never dealt well with displaying editable documents, the closest standard that exists is contentEditable and pretty much everyone agrees that it sucks and is not fit for complex use cases.

If jefftk wanted to stop working on ads, he could transfer within weeks to any of hundreds of open positions on Google's internal recruitment platform, keeping the same compensation, benefits, etc. It's stupidly easy (doesn't even require your current manager's approval!) and the only "cost" is usually that it can set you back slightly in your career due to abandoning your current projects and having to ramp up on new stuff.

So no, "because of the salary" doesn't explain any of it, and you should read the blog post before posting insulting comments like these.

Zanzibar has been in use for way more than 3 years. I used to work in the SRE team supporting it 7 years ago, and it already had significant users back then.

Zanzibar is an authorization system, not an authentication system.

I haven't heard about a global opt-out in the browser, but I haven't really looked for that info either. I think I've heard Chrome allows extensions to "easily" hook document.interestCohort and return any value the user wants (including random values). The standard also mentions "The user agent should offer a dedicated permission setting for the user to disallow sites from being included for interest cohort calculations." but that's only for blocking specific sites from contributing to cohort computations, not for disabling globally.

It doesn't seem to be defined in the standard, but it's partially documented in Chromium's docs how they determine what is an ad resource:

https://chromium.googlesource.com/chromium/src/+/master/docs...

https://chromium.googlesource.com/chromium/src.git/+/master/...

https://chromium.googlesource.com/chromium/src.git/+/master/...

This seems to indicate the authoritative source of truth is EasyList. On my current machine, the list seems to be stored in "~/.config/google-chrome/Subresource Filter/Unindexed\ Rules/9.22.0" and should be easily inspectable.

I don't know if I've missed some documentation pointers related to this.

It's not 4% improvement for the wine use case, it's 4% improvement in existing synthetic benchmarks for the futex syscall. And a 21% regression in performance in another synthetic benchmark.

It's likely the wine WMO implementation is getting a much more significant increase in performance than 4%, but the patch description doesn't provide numbers.

> if there are ads resources in the page

Please read the full comment (or preferably, the standard) before spreading FUD.

> The fact that all websites are included by default, and it's up to the individual website to opt out of inclusion, makes me squirm.

That's not the case, contrary to what Hacker News wants you to think with this massive opt-out campaign. FLoC cohort computation is only planned to include websites that themselves request cohort information. Unless your page calls document.interestCohort, it is not included in cohort computation [1]. The opt-out header does nothing unless you use FLoC.

There is an exception to this made for the pilot phase (aka. right now), where in order to bootstrap the system Google is extending cohort computation to include "all websites that show ads" [2]. My guess is that this is necessary so that early testers get useful data. This is not something that seems to be planned past the pilot. The standard also restricts this to only "while 3rd party cookies are still a thing".

Disclaimer: I work for Google, but not on advertising or Chrome. This is all from public information I researched in my own time.

[1] https://wicg.github.io/floc/#compute-eligibility §7.1.1 "By default, a page is eligible for the interest cohort computation if the interestCohort() API is used in the page."

[2] https://wicg.github.io/floc/#adoption-phase §7.1.4 "at the adoption phase, the page can be eligible to be included in the interest cohort computation if there are ads resources in the page, OR if the API is used."

Looking at the SM64 video, he: 1. misrepresents the work from the SM64 decomp project (some of the decomp developers even commented in the video comments); 2. misreads and/or misunderstands the toolchain errata, what he describes in his audio track doesn't match at all what he shows on screen. But there isn't much of a claim to debunk, because it's all hypothesis that "Nintendo wouldn't make such a basic mistake, it's deliberate".

Anyone who has experience working on emulation and reverse engineering of Nintendo games can tell you that Nintendo keeps doing basic technical mistakes when shipping production games. Dolphin's wiki has a whole category for "games that shipped with debug symbols". Pikmin has a freakin' mostly-working PC port of an early version of the game on the GameCube disc. There's also no evidence that other N64 launch titles had the same idiosyncrasy of compiling in -O0, and the whole SDK is compiled in -O2 as he even mentions in his video. How does that fit with the "early toolchain" line of reasoning?

TL;DR: Actually forgetting to build with optimizations enabled is completely in line with what emulation developers and game reverse engineers have seen from Nintendo in the past 20 years. MVG just states his own theory as fact, without the Nintendo console hacking / RE / emulation experience, and with very little evidence which doesn't even match his own claims.

EDIT: See also [1] hidden in the 2nd page of YT comments on that SM64 video, from someone who was involved with the SM64 decompilation project.

[1] https://imgur.com/XZ45IZH

MVG regularly gets key technical information wrong and barely cites any sources, so I'd take this with a grain of salt.

Example: he claimed in [1] that a Nintendo leak contained "the entire source code of IOS" (IOS being the Wii operating system) and "the Verilog for the entire Nintendo Wii". Both of these claims are completely wrong and have been refuted by both console hackers and emulator developers for the Wii. I told MVG on Twitter, he replied saying approx. "oh it's not my fault I just read what was written online and haven't looked at the details myself" [2]. To this day the video is still up, there is no errata either in the description or in comments. This is not the only example, just the freshest one in mind and one I was directly involved with.

[1] https://www.youtube.com/watch?v=n8G7eq0GlQs [2] https://twitter.com/ModernVintageG/status/125820871313715200...

You're making a distinction between "packagers" and "users" which does not exist. Packagers are advanced users that take the initiative to improve their distro when they find software they want to use and that isn't integrated in their distro.

> Let the new complicated juggernaut software be deployed and configured by the users, according to developers' instructions, using whatever modern mechanism they prefer

I'm not sure what "they" refers to here (developers or users). The existence of packagers is proof that some subset of users "prefer" that software "be deployed and configured" via distro package managers.

> I think people just want the same iPhone they have now, with additional "repairale" property. That is not going to happen. The repairable iPhone will be thicker and less elegant than the non-repairable iPhone (compare iPhone to Fiarphone). And suddenly people are not buying it anymore.

You're going from one extreme to the other. You could for example require Apple to provide access to their spare parts supply chain (replacement batteries, screens, maybe some key ICs that regularly fail, etc.) to independent repair shops. This would greatly increase the repairability and decrease electronics waste. Right now, many repairs aren't possible simply because you can't find parts, or because customs will block your parts from entering the US, or even because Apple has decided that only they can have the tools to pair a new home button with your current device.