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.

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.

Comments URL: https://news.ycombinator.com/item?id=48576333

Points: 2

# Comments: 0

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

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.

Comments URL: https://news.ycombinator.com/item?id=46556201

Points: 9

# Comments: 4

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.

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.

I'm curious if they have plans to improve edit prediction though. It's honestly kind of garbage compared to Cursor, and I don't think I'm being hyperbolic by calling it garbage. Most of the time it's suggestions aren't helpful, but the 10-20% of the time it is helpful is worth the cost of the subscription for me.

Any package version that didn't follow the x.y.z format was excluded, and any package that had less published versions than their largest version number was excluded (e.g. a package at version 1.123.0 should have at least 123 published versions)

I made a fairly significant (dumb) mistake in the logic for extracting valid semver versions. I was doing a falsy check, so if any of major/minor/patch in the version was a 0, the whole package was ignored.

The post has been updated to reflect this.

Comments URL: https://news.ycombinator.com/item?id=45245678

Points: 168

# Comments: 76

You're right though, the naming of the `filter` method is confusing. I need to split off the filtering and applying of operations into two separate methods. And probably provide an additional `query` method like you said which would do what `filter` is doing now. Appreciate the feedback!