MBlume (u/MBlume) - Readit News

MBlume commented on Tom Lehrer has died nytimes.com/2025/07/27/ar... · Posted by u/detaro

nmca · 5 months ago

I feel the AI safety community has not made enough of Lehrer’s masterpiece on the topic:

https://youtu.be/frAEmhqdLFs?si=DYsY5Juco-kJ5eWD

MBlume · 5 months ago

I assure you we sing it sometimes!

MBlume commented on Ocarina of Time Randomizer ootrandomizer.com/... · Posted by u/nickswalker

favorited · 6 months ago

I'm glad to hear that Wind Waker HD has fan support like this. It was always a bummer to me that the best versions of Wind Waker and Skyward Sword were trapped on the Wii U, given the incredible preservation that Dolphin provides for their original versions.

Edit: I own a Wii U, I'm not trying to be a hater. For years, it really was the ultimate Zelda box.

MBlume · 6 months ago

> given the incredible preservation that Dolphin provides for their original versions.

Does cemu not provide comparable preservation for the HD versions? I played through both WW:HD and TP:HD on my Steam Deck using cemu and found it a great experience.

MBlume commented on Amazon to display tariff costs for consumers punchbowl.news/article/te... · Posted by u/donohoe

MBlume · 8 months ago

Trump will certainly consider this provocation, so perhaps the news here is that Amazon considered this worth it, even given the inevitable retaliation.

MBlume commented on The optimised version of 7-Zip can't be built from source pileofhacks.dev/post/the-... · Posted by u/todsacerdoti

nixosbestos · a year ago

You can't build modern Rust without a rustc binary... Does that mean it "can't be built from source"?

MBlume · a year ago

I would be shocked if the rust documentation didn't explain very clearly how to bootstrap rustc starting from gcc

MBlume commented on Dockworkers at ports from Maine to Texas go on strike apnews.com/article/port-s... · Posted by u/mikeocool

jsiepkes · a year ago

> The union wants a complete ban on automation.

I understand that in a negotiation you always "over ask" so you have room to compromise and you have bargaining chips. But this just sounds absurd.

MBlume · a year ago

The strike emphasizes the importance of automation. We should be prioritizing the investments that will allow us to fire as many of them as possible as soon as possible.

MBlume commented on ts-blank-space is a fast type-stripping compiler bloomberg.github.io/ts-bl... · Posted by u/joatmon-snoo

MBlume · a year ago

I'm a little confused about when I'd use this, if I'm quickly iterating on code as I develop it, probably I also want to know whether it type checks, right?

MBlume commented on Git-absorb: Git commit –fixup, but automatic github.com/tummychow/git-... · Posted by u/striking

MBlume · a year ago

I've been using this workflow with hg and it's great, happy to see a git port

MBlume commented on Debugging a memory leak in a Clojure service charanvasu.com/posts/debu... · Posted by u/whiteros_e

MBlume · a year ago

The article makes it sound like the system was using eval (probably on a per-request basis, not just on start-up), and also like ceasing to use eval was pretty trivial once they realized eval was the problem. I'd be curious why they were using eval and what they were able to do instead.

MBlume commented on Reformatting 100k Files at Google in 2011 laurent.le-brun.eu/blog/t... · Posted by u/laurentlb

aiuto · 2 years ago

I want to start by saying that I do not want to diminish or disparage the work that Russ, Rob, Laurent, and others have done. It has made the Google code base better. That is an inarguable fact. Nor do I want to pick on buildifier or gofmt or any other tool as a singleton problem. I'll talk about buildifier because that is what I personally fight with. Others may have different demons. (YDMV - "your daemon may vary". I'm taking the authorship of that one now, in case it ever takes off).

But back to the point... formatting rules without firm, incredibly strict enforcement ends up being a tax on the janitors - the people who clean the code base and do large scale changes. That makes me sad. These are the people who care a great deal about code health, and their work is hindered by the lint checks that we have imposed.

Let me give an example.

I'm trying to eliminate a constraint in the build system. It's a "small" large change - only O(30K) instances. (Yeah, Google scale is different). I have an incredible wealth of tools available to me to automate the process. For the benefit of the Googlers, I can identify Blaze targets to change, use buildozer to fix them, and ship off CLs to review. But the changes I want to make are often ones which should be reviewed by the code owners, and not globally approved. So possibly O(10K) individuals might be involved in reviews.

Let's explore the problem. First, shouts to y2mango for bringing up incremental formatters. This should be the default for all tools. And another to flymasterv for raising the question of "why not just format as each person touches a BUILD file". Here's the situation.

1. buildozer is really good at rewriting BUILD files syntactically correctly. 2. It has an unfortunate side effect of not being incremental. It calls buildifier to rewrite the entire file. 3. We update the formatting rules to make them stricter over time. That means that a "correct" BUILD file on January 1, might require changes on March 1. 4. Buildifier findings are advisory, rather than mandatory. 5. No team is staffed with repeating the monumental work this post started with.

The reality on the ground is that little touched BUILD files become stale, and would require a formatting update over time. It is actually worse than that, because many teams take the path of ignoring buildifier warnings and committing their working code anyway. Without continual BUILD file reformatting there is a lot of stale floating around. [Root cause: We could fix this by promoting people for doing that repeat work. But we don't. We promote for the initial sprint.]

And then a janitor comes along.

I use bulldozer to fix a problem. It reformats an ancient BUILD file completely (not incremental). I send it to the code owner. They see changes far beyond my 2 line fix. They reject it, or ask for a change to only the two lines that actually mattered. Sure. I can hand build the change once or twice. But not for a few hundred, or thousands files. So.... I have to hack up an incremental format. Or, it turns out that users are very happy if I don't bother with formatting at all, and just change single lines. It's not that any individual is right or wrong. It is that they all have a choice and a preference and Google created a policy that allowed individual teams to have a choice of strict compliance or not. That is the failure.

If you are going to have a policy about code formatting: - make it hard mandatory for everything except a "break glass" situation - if the policy can evolve, staff a team with enforcing it globally

The fact that Google, as a company, does not reward this behavior does not take away from any individual's accomplishments. This post may sound grumpy to an outsider, but I am constantly amazed at the tools I have available to fix things on an enormous scale. The friction is usually only where we have good intentions, without the policy teeth to enforce alignment with the intentions. That's a management problem, not a technical one.

MBlume · 2 years ago

Seems like the solution here is to set up buildifier so that it can send out robot CLs on an ongoing basis.