n_e

the funniest part of these AI detectors is that if I were to upload any of einstin's paper's they will all be flagged as AI-written.

Have you tried doing that or even read the article?

The article says that their detector flags 0.4% of pre-AI papers as AI-written.

If I paste the first page from this paper (https://www.fourmilab.ch/etexts/einstein/specrel/specrel.pdf) in https://unslop.run/app, I get a 0% chance that it was AI-written.

There is general agreement among participants that he has engaged in off-wiki canvassing and is not here to constructively build the encyclopedia. There is also a significant concern shared by many editors that his actions constitute calls for outing.

You have web workers, and for shared memory and synchronisation respectively SharedArrayBuffer and the Atomics namespace.

Interestingly, despite the QUERY request being safe, the RFC says it's subject to preflight requests:

A QUERY request from user agents implementing Cross-Origin Resource Sharing (CORS) will require a "preflight" request, as QUERY does not belong to the set of CORS-safelisted methods (see [FETCH]).

As a user, I like when things appear to sync instantly and perfectly, such as in Google Docs.

As a developer, I hated the article and many of the comments I read thus far because:

- Having clients and a server properly sync and not lose data in the event of a network failure amounts to having a consistent distributed system which is not easy to do, and the commenters don't seem to have understood that

- I hate having written a long document and then losing it because the sync code is buggy, so the previous point becomes even more important.

So reading many of the things here has been mildly infuriating.

That being said, none of these people are likely affiliated with Linear, and given the overall quality of the product I'm pretty sure it works properly.

Unfortunately it's not limited to the trendy topics. For example there is a huge amount of factually wrong comments on the topic of npm vulnerabilities. I'm sure it's the same on topics I know less about.

The app would look up in both databases. If it exists in any, there would be a session.

And if you find the session with differing values in both databases, how do you know which one is up-to-date?

You need an algorithm to pick which data is right, such as electing a master instance.

And that brings us back to the original discussion: to manage sessions (unlike caches) in a highly available way, you need to setup HA (or reimplement it, which obviously is a bad idea). You can't read round robin from multiple non-HA instances.

Redis is used for plenty of things, not just memory caches.

For example if you use it for session storage, you can't have your application read from a random instance that may or may not contain the session.

Yes (assuming they're doing frontend dev and including the resources from the page). The code is fetched and executed from the browser, so It'll have to escape the browser sandbox to do something nefarious.

It works when the phone is in landscape mode.

I think the idea is that a site has no use for the status and address bars in portrait mode since the areas are already filled with controls.

It runs code that Node et al can't run

What kind of code can't node run?

The problem with crappy frontend code is not only the maintenance. It's that stuff such as responsive design, accessibility or cross-browser compatibility that work nearly for free with elegant code won't work at all.

Made me wonder why the packages even need build scripts

As the name implies it's for building stuff. Most (all?) packages that use C++ FFI with node-gyp need it. A popular package that needs it is re2.

Many newer packages bundle prebuilt native code as transitive dependencies, so build scripts are less needed than before.

The figure is likely wrong.

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.

it used to be that projects that pinned deps were called out as being less secure due to not being able to receive updates without a publish.

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.

Yes, you can lock deps in NPM/Cargo/etc. but that's not the default. It is the default in Go.

How is it not the default in npm?

I'm not sure what to make of the graph.

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)

Why not use swarm? On a single node it isn't really more complicated than compose, and you get scaling and rolling deployments.

enums and decorators mainly. There are also subtleties such as having the ts file extension in imports. Also imports aren't transpiled in cjs so you need to need es modules.

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

The reply looks like it was written by an LLM. Not that this excuses anything.

The explanation is at the end of the article: another GoDaddy customer asked for the transfer of a similar-looking domain name, and they transferred the wrong domain.

1.On a system that is handling 10k concurrent requests, the 10GB of RAM is going to be a fraction of what is installed.

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.

Why is reserving a megabyte of stack space "expensive"?

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.

I'm not sure what approach you're suggesting?

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.

Anyone know of a better way to protect yourself than setting a min release age on npm/pnpm/yarn/bun/uv (and anything else that supports it)?

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

Why waste a round trip, build time, loss of flow and CI machine queue wait time when you can catch things early?

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.

I haven't checked, but it would be surprising that the min-release-age applies to npm audit and equivalent commands

Cloud sql lowest tier is pennies a day

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.

I process TB-size ndjson files. I want to use jq to do some simple transformations between stages of the processing pipeline (e.g. rename a field), but it so slow that I write a single-use node or rust script instead.

but so could FFI calls to another language for the CPU bound work

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.