genshii

Glad to see Astro doing well here. It's by far my favorite way to build sites of all kinds, both content rich MPAs, and react heavy web apps.

What are you on about? You clearly don't like video games and think they're a waste of time, which is fine. Other people do like them and find them fulfilling for whatever reason, which is also fine.

Why are you trying so hard to "prove" that someone's hobby is a waste of time?

Maybe I just need to get over it, but this post reeks of Claude-isms and it immediately makes me stop caring about what the post has to say.

Obviously having an LLM write these kinds of things is the norm now, but what doesn't have to be the norm is the writing style. The way Claude (and other popular LLMs) write is so obnoxious and verbose. I think a simple pass of "make this more terse and to the point" would do wonders here.

Someone could come into this post and leave a comment saying they're a security researcher, that they audited the codebase, and include a summary of their findings. And that person could be lying.

I think saying that it contributes nothing because a) someone could do it themselves, b) the output might be slop, and/or c) they could be lying, is a bit silly. Those things apply to basically everything posted on the internet.

Whether an LLM security review is actually valuable is an entirely different discussion.

Astro is a meta-framework that allows you to plug in other web frameworks where you need it (React, Solid, etc). Although it would also be fair to consider Astro a sort of build tool / bundler.

Node is a runtime, not a framework.

So there's really only one framework here (Astro). Using other web frameworks within it is completely optional.

Just moved my astro project over to v7 and saterri the other day. Writing MDAST/HAST plugins is so much better/easier, so great job there :)

This is cool, but when the very first paragraph of the readme is clearly LLM generated, it makes me doubt the quality of the project.

Not a bug, the post 'A HN post with negative points – how?' is a link to this post.

But yeah it's a bit confusing for one HN post to take you to another HN post.

I've been presented with this thought experiment before and I always feel like I'm missing something when other people talk about it. Why would you ever take both boxes?

The premise is that the predictor is always right. So whether you take one or both boxes, the predictor would have predicted that choice. We know from the setup that if the predictor said you would take the one box, it will have a million dollars. Therefore, if you take the one box it will have a million dollars in it (because whatever you choose is what the predictor predicted).

As an aside, I think whatever this says about free will or if you're actually making a "choice" is irrelevant in regards to if the million dollars is in the box. The way I see both choices is this:

You "decide" to take both boxes -> the perfect predictor predicted this -> the opaque box has zero dollars -> you get a thousand dollars

You "decide" to take the opaque (one) box -> the perfect predictor predicted this -> the opaque box has a million dollars -> you get a million dollars

If you want to consider the version of this where the predictor is almost perfect instead of truly perfect, I don't think that changes anything. Say it's 99% accurate or even 90% accurate.

You take the opaque box -> the predictor has a 90% chance of predicting this -> it follows that there's a 90% chance that the box has a million dollars -> you have a 90% chance of getting a million dollars

Had you picked both boxes, you have a 90% chance of not getting the million.

Hi Jarred, thanks for all your work on Bun.

I know that one thing you guys are working on or are at least aware of is the size of single-file executables. From a technical perspective, is there a path forward on this?

I'm not familiar with Bun's internals, but in order to get the size down, it seems like you'd have to somehow split up/modularize Bun itself and potentially JavaScriptCore as well (not sure how big the latter is). That way only the things that are actually being used by the bundled code are included in the executable.

Is this even possible? Is the difficulty on the Bun/Zig side of things, or JSC, or something else? Seems like a very interesting (and very difficult) technical problem.

I used Proxmox for years to run a fairly comprehensive homelab, and a few months ago replaced the entire thing with Incus (on a debian host, haven't tried IncusOS yet). Incus is amazing and it makes so many things so much easier compared to Proxmox.

One thing in particular is permissions in unprivileged containers. In Proxmox, you have to do a bunch of somewhat confusing ID mapping. In Incus, it's as simple as setting "shift=true".

Also the profile system in Incus is really powerful and allowed me to deduplicate a ton of config.

Maybe it's just too early in the morning for me, but I genuinely can't tell if this is satire or not.