It's a mistranslation, the original quote is "Une enquête en recherche des causes de la mort est ouverte afin de déterminer l’origine du décès, aucun élément suspect n’ayant été découvert sur place par les services primo-intervenants. Les investigations sont en cours", which translates to "no suspicious element was found", not "no suspect was found"

Thanks for clarifying

> 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.

Even the translated version of the field equations paper has a 1% match only. Which I expected to be a tiny bit higher but still near 0.

> 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.

Exactly. Nothing stops your writing a high-performance parallel database in TypeScript today. Given that runtimes and tooling are actually pretty good, I think TypeScript is actually a fine choice of language for the task.

The only thing you can't do with JS today is share a heap across threads. You have SharedArrayBuffer. You have atomics. You don't need a shared address space.

There's a high performance database called "PostgreSQL" you may have heard about. It doesn't use threads. It uses separate processes and shared memory: just like standard JavaScript, with its service workers and SharedArrayBuffer.

If not sharing an address space is good enough for PostgreSQL, it's good enough for your TypeScript database.

The problem with shared-everything, unmarked, preemptive-parallel concurrency is that 90% of the time it gets used by people who don't know they shouldn't.

SharedArrayBuffer gives you a byte array, and asks you to re-implement the entire JavaScript universe on top of that. String -> use TextEncoder to copy in / out of a byte buffer. Object/class? Sure, devise your own protocol to serialize + copy instances in/out of a byte array. Even basic arithmetic operations on a TypedArray over a SharedArrayBuffer is slow AF in v8 compared to a "native" JS Array<number> for small-medium integers, because our current JIT compilers can jit the fuck out of regular arrays but struggle with TypedArray stuff. It's so sad.

> Even basic arithmetic operations on a TypedArray over a SharedArrayBuffer is slow AF in v8 compared to a "native" JS Array<number> for small-medium integers, because our current JIT compilers can jit the fuck out of regular arrays but struggle with TypedArray stuff. It's so sad.

Yeah, that sucks, but at least it's just an implementation problem. Java's analogous ByteBuffer methods have been fast compiler intrinsics for a long time, so there's an existence proof of this stuff done right.

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]).

That paragraph merely describes how existing browsers behave, it doesn't specify how future browsers must behave. After all, a HTTP RFC isn't really the right place to specify browser specific behavior like CORS, that belongs in a W3C/WHATWG specification.

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.

Which is to say: in case of partition, it loses data.

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.

I think there are also people who understand the technology but overestimate potential impact. I remember someone at the Apple Vision Pro announcement arguing that this would be one of Apple’s biggest products and everyone would want them for taking photos and videos of their kids birthdays and such because it would be so much more natural than pulling out a camera and they just couldn’t be talked out of it.

Sometimes a technology can be really cool and never catch on. Sometimes a technology can be really popular anbd even world changing and never make much if any money.

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.

This case is exactly what he talks about. To get HA just setup more than one redis cache - or rebuild the session if it was lost in the redis cache.

It’s not. Imagine a web app that stores your user information in a session store, mapped by your cookie-provided session ID. Your web app searches redis 1 for the session id, but since that key is on redis 2, the lookup fails and the application thinks there is no such session, and rejects the request.

Now you could solve this specific case by sharding by prefix, or by querying all instances, but then you still do not have high availability: if the instance a specific session is on is down, these users cannot authenticate. At that point you’re better off with a single instance.

But that is his point. If you cannot find the session id in redis, you login again. If your Redis server crash, you start a new one and everyone just login again. No data is lost.

Sure the data is lost. A session commonly holds arbitrary state, and even if it’s just the login information. This is ridiculous.

No two processes can guarantee data consistency unless using shared memory with some kind of locking on update. And given two servers don't share memory, two processes running on these servers can not guarantee consistency either.

To put the simple terms... App writes to node-A, node-A (/process on node-A) crashes before change is synced from node-A to node-B, data is lost.

This is true for redis and true for postgresql/ mysql or any similar database. Difference between redis and a "database" is that database protects against this problem by writing change to durable storage before telling app that write is successful. Redis

So if one wants to have a consistent session storage, one should use a proper database or use AOF redis persistense with single node (https://chatgpt.com/s/t_6a24ab818e2881918db959cec8d8cc2d)

First up, if I wanted to talk to a machine, I would've asked one myself.

Then, I don't understand your point really: Yes, the CAP theorem is a thing. There are compromise solutions available however to enable highly available data storage. Some of them for Redis too, but they are more complicated than those for other database engines. Which is the point of this discussion.

Point is... with AOF and RDB enabled, and wait command used in sane manner, one can get reasonable consistency with a significant speed tradeoff and increase in application complexity. So if consistent cache is needed, one can have that with some compromises, but then probably one could use a database straight away.

Again: Redis is a database, not just a cache - it doesn’t care if you store ephemeral cache artifacts or customer records within it. Redis doesn’t pose any constraints on the type of data. Inversely, you can use Postgres as a semi or fully consistent cache.

And yes, what you’re saying is technically correct, even a well-tuned single node doesn’t solve the availability problem: if it goes down, you have an outage. To avoid that, you need multiple instances to provide the same data, avoiding downtime if one of the nodes breaks eventually.

If redis is a database, then by

> doesn’t pose any constraints on the type of data.

logic, raw disk is also a database. One just need to add block level replication to other nodes to build a replicated/ HA database.

We may not agree, but anything not providing transactions across logically related multiple data read/ update operations is not a database.

> multiple instances to provide the same data

is easy and done by a bunch of software out there, but

> multiple instances to provide the same data on non-shared memory computers, with consistency

is a really hard problem, and no one has been able to solve it yet without introducing other problems to be considered (giving up on fast performance being one of the most visible one) by architects/ developers.

Obviously these are application decisions.

You, obviously, don't commit important data only to a session that you can loose, if the application does not allow it.

We use redis as infrastructure. To route events and as a cache.

For us redis could go down and we would merely see a degradation of our service with no data loss.

I recommend using redis like that. And then use a database that supports transactions for real data problems.

But we are different. And that's OK.

This discussion is a bit weird. We started off from, Redis should have better availability guarantees. Specifically to avoid the degradation of service you described.

But that requires running on multiple instances, which in turn requires to share the data across all replicas.

If you consider it important, you have to store it in a real database. No buts. If you don't consider it important, sharded redis works fine.

Redis is a real database. If I wasn’t convinced it could retain data I hand it, I wouldn’t use it in the first place.

Just because it works for your use case right now doesn’t mean there isn’t room for improvements to support others too.

> Redis is a real database

No, redis is a memory cache, with some ACID like features bolt on.

Even real databases have hard time maintaining consistency across nodes. CAP is a real constraint.

> Redis is a real database.

Oh good, then you don't need to do any of the stuff that you suggested to do

These two concerns are not mutually exclusive, the kind of database or data stored within it doesn't give any availability guarantees on its own. Even a single Postgres instance, which I suppose fits your understanding of a real database, is a single point of failure and not a highly available setup: If your database server goes down, clients get errors and the database is thus unavailable.

I don't think you understand what HA means.

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

Thisnis strictly different from partitioning which I think you are mixing it up with.

Paritioning is for performance not HA

> 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.

Yes, you are pointing out exactly how HA is difficult.

There is a whole slew of downstream things you need to take into consideration.

and as you've just confirmed... there is a need for good HA support in Redis. Which was the entire premise of this thread.

That’s the precise point I’m making

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.