Egalitarian PoW don’t work better on custom hardware.

I mean it could... Even for Egalitarian PoW. You'd have to make the ASIC specifically for the exact PoW you're trying to target, and you're going to end up with something pretty exotic that's going to be easy enough to invalidate by altering the PoW. But, you could...

Wouldn't make much sense if there are ASICs

Next in the repeat queue: I will not add scrolljacking to my website.

Interesting comments from lobste.rs IMHO:

1. 19 upvotes link

   Relevant issue: https://codeberg.org/ziglang/zig/issues/37402

   Pending PR: https://codeberg.org/ziglang/zig/pulls/37417

2. 6 upvotes link

   Hate to say it, but LLM code review certainly would have caught such an obvious "accidentally quadratic" bug.

   23 upvote response link

   And we would have missed the community showing up, and having fun working together on a fix.

   I think this is acceptable in a pre-1.0 language.

You're not going to be good at it, at first. It probably takes a good 6-12 months to do it all correctly and most developers don't actually learn how to do it all properly.

But here's my cheatsheet if you actually want to spend the time to get really good at code review. Save this comment so you can keep coming back to it.

First, you need to relearn the programming side, making code in a specific way that has the capacity to be reviewed correctly. Don't think about code made to accomplish a goal because you should already be able to do that. Instead make sure you understand what makes code easy to review by someone else.

Why: You may have been stuck in an environment where someone else was either fixing your mistakes for you (depriving you of your opportunity to get better at writing reviewable code), or you may have been in an environment where you were getting the wrong feedback.

How: Read this link: https://mtlynch.io/code-review-love, then read it again next week, and again the following week. Once you intuitively can make reviewable code, it'll be easier for you to teach others how to make reviewable code (which makes your reviews easier to perform correctly).

Second: Learn how to actually give feedback in a way that gets things fixed.

How: Read this: https://mtlynch.io/human-code-reviews-1/.

Third: Don't try to write or correct documentation before you understand the "Grand unified theory of documentation" Link: https://docs.divio.com/documentation-system/. TL;DR: Most programmers don't understand that there's actually four different types of documentation and assume that the kind that they right is what's actually needed.

That goes into technical writing, which is another skill you need to develop but makes projects better as a whole, which makes it easier to review code.

Fourth (bonus reading material): antirez (the guy who made redis) went through his whole project and did a kind of census/retrospective on all the comments inside. It sort of accidentally turned into a good practical advisory on writing comments that actually mean something. Link here: https://antirez.com/news/124

A critical 9.2 CVE

Video of PoC: https://mastodon.social/@Viss/117475758985207443

At least they've fixed the tabs.

I get around this by only using optimised SVGs then inlining them.

Maybe you want your wedding website to look different to other people’s?

Unless you're drawing a massive illustration or specifically going with a non-wedding themed wedding, there's only so many variations you're going to end up with.

Dude it’s 2026 not 2024. I know things are changing rapidly but that has been very obviously not true for at least 6 months.

Since this is such a cookie cutter argument, see last week's response about the same thing: https://programming.dev/post/57569685/26396986.

You’re going to be shocked.

I'm constantly shocked at the bad code I get from other using the latest models. See one of my parent comments in the same linked comment, each of the four projects came from people using the latest models.

Why would you not reuse event pages for the next event?

How many times are you getting married? 😄

Let me fix that for you: How many times are people getting married?

The answer: Lots.

There are already wedding websites out there, in every variation possible.

Why reinvent the wheel when we have so many wheels that they're treated as disposable?

I’d expect that the code would be almost exactly the same as other code that already exists, in which case, why not use that code?

Uhm, because it’s not the same? Why would I vibe code an app that’s almost exactly the same as an existing one?

Because a vibecoded app is going to be a ripoff of its training data anyway. LLMs can't produce creative or novel works, all they can do is stochastically regurgitate what they've already seen in their training data. So why deal with risk of injection attacks hidden in the training data when you can just use the original source instead?

There’s not really any such thing as a one off web page.

Of course there is. What an absurd thing to say. A very obvious example is event websites, e.g. for weddings.

Why would you not reuse event pages for the next event?

Maybe it depends on the language but I’ve recently vibe coded two tools in Rust and I’ve skimmed the code and it’s perfectly good Rust. I would accept it in a PR - even if I was being as picky as I’d really like to be in reviews. I don’t think that would have been the case 3 months ago though.

I'd expect that the code would be almost exactly the same as other code that already exists, in which case, why not use that code?

I too love filling my code with things that silently reduce my understanding improving my code using stochastic prediction models trained on tainted data filled with hidden injection prompt attacks AI