My Mac is currently using 9GB of RAM including 6.5GB of cached files with Safari and a few other apps opened. They likely forgot to subtract the cache from the used memory.

This is still the right advice for libraries. For security it doesn’t matter a whole lot anymore as package managers can force the transitive dependencies version, but it allows for much better transitive dependency de duplication.

For non-libraries it doesn’t matter as the exact versions get pinned in the package-lock.

How is it not the default in npm?

On the one hand the acquisition of GitHub may have caused the availability to be worse.

On the other hand, the 100.00% availability before the acquisition looks suspicious, wondering if it's not just the status page being better updated.

(I'm aware of the recent availability problems with GitHub, but on the graph the problems start in 2020 and don't seem to worsen significantly)

I'm using it in my projects with no issues.

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

Points: 4

# Comments: 0

My example (and the c10k problem) is 10k concurrent connections, not 10k concurrent requests.

> 2. It's not 10GB of RAM anyway, it's 10GB of address space. It still only gets faulted into real RAM when it gets used.

Yes, and that's both memory and cpu usage that isn't needed when using a better concurrency model. That's why no high-performance server software use a huge amount of threads, and many use the reactor pattern.

Because if you use one thread for each of your 10,000 idle sockets you will use 10GB to do nothing.

So you'll want to use a better architecture such as a thread pool.

And if you want your better architecture to be generic and ergonomic, you'll end up with async or green threads.

Asking a more junior developer or someone who "show little interest in learning" to discuss their approach with you before they've spent too much time on the problem, especially if you expect them to take the wrong approach seems like the right way to do things.

Throwing out a PR of someone who doesn't expect it would be quite unpleasant, especially coming from someone more senior.

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

Points: 2

# Comments: 0

With pnpm, you can also use trustPolicy: no-downgrade, which prevents installing packages whose trust level has decreased since older releases (e.g. if a release was published with the npm cli after a previous release was published with the github OIDC flow).

Another one is to not run post-install scripts (which is the default with pnpm and configurable with npm).

These would catch most of the compromised packages, as most of them are published outside of the normal release workflow with stolen credentials, and are run from post-install scripts

Because we want to be sure that the checks have passed, and that they have passed in a clean environment.

Contributors can, in addition, use git hooks, or run tests in watch mode, or use their IDE.

Also it's annoying to have slow git hooks if you commit often.

Unless things have improved it's also hideously slow, like trivial queries on a small table taking tens of milliseconds. Though I guess that if the alternative is google sheets that's not really a concern.

Worker threads can be more convenient than FFI, as you don't need to compile anything, you can reuse the main application's functions, etc.