mxey

> If Rosetta2 goes away, Parallels support for x64 VMs likely goes away too.

Rosetta 2 never supported emulating a full VM, only individual applications.

Many container images are multi-arch, although probably not ones that are built in-house.

Apple Silicon is ARM64 which is supported by Linux and Docker.

Isn’t that part of Rosetta also used in their own Game Porting Toolkit?

It doesn’t say if that is going away. The message calls out another part as sticking around:

> Beyond this timeframe, we will keep a subset of Rosetta functionality aimed at supporting older unmaintained gaming titles, that rely on Intel-based frameworks.

Since the Linux version of Rosetta requires even less from the host OS, I would expect it to stay around even longer.

Yeah, this seems bad strategy for a company that wants to sell you on their PostgreSQL expertise.

The article mentions the new async IO in PostgreSQL v18 in the section on write tuning but it’s only relevant for reads.

You don’t even need driver support, you can use https://www.postgresql.org/docs/current/sql-do.html

I have started to use batching with the Go pgx driver for simple transactions of multiple inserts. Since a batch is automatically a transaction, it’s actually fewer lines of code.

The standard library html/template also has that in the form of blocks.

> Apple purposely make it so after 3 new versions of the OS you cannot upgrade the OS on the hardware any further.

A new major version of macOS comes out every year. The oldest Mac still supported by the upcoming macOS 26 is from 2019.

It’s slow because it forces a write to disk. I don’t think the syscall itself matters much.

You need write barriers for the ordering guarantees of a WAL. that’s why Apple uses barrier sync and not full sync. AFAIK other operating systems do not have this distinction.

It is not even relying on JIT, because that’s not allowed unless you are a browser engine and in the EU.

What do you mean by atomic deployment? There are no transactions in the Kubernetes API. Helm has to make one request for each object it creates or modifies, like any other client.

PostgreSQL does not have built-in clustering but Patroni does it automatically.

MySQL Group Replication isn‘t automatic in all cases, like starting after all nodes failed, and it has some limitations, but it is built-in.

Not saying that MongoDB ReplicaSet is bad, has been working very well for us AFAICT.

Did MongoDB have _proper_ replication 15 years ago?

Postgres defaults to preventing delete when foreign keys would be violated, not cascading.

Maybe you should read the various iterations of the design before you assume it dropped from the sky as-is.

That does not mean that generics were somehow forced in against the wishes of the Go Team. Their position has always been that they just need to find a good design.

Apple‘s password manager is available for Windows, although I don’t know if it supports passkeys.

Also, there are mechanisms to use a passkey from another device (over Bluetooth I think?)

Which non-Go people brought generics into Go?

Access on an empty slice would also panic because of out of bounds. So there’s no useful distinction there.

However, nil slices work just fine when calling append on them, while writing to a nil map in any way will panic.

But that will also not transfer over to the domain struct

At which point I loose all the benefits of lazy decoding that the accessor methods can provide, so I could just decode directly into a sensible struct, except you can’t with Protobuf.

Unless that literally prevents you from accessing other parts of the repository, that creates a big risk that you depend on something from another folder and are not triggering rebuilds when you should.

> A similar example is the iWork suite. It exists, but neither users nor Apple seem to care about it.

I would disagree on that, at least about Keynote. I’m not the only one who loves it.

Workflow becoming Shortcuts mostly as-is would be a counterexample.

> The need for PostgreSQL to modify all of a table’s indexes for each update has several performance implications. Obviously, this makes update queries slower because the system has to do more work.

You know, I was wondering something regarding this write amplification. It's true that MySQL doesn't need to update its indexes like that. However, MySQL replication relies on the binlog, where every change has to be written in addition to the database itself (InnoDB redo log and so on). So, it seems to me, MySQL, if used in a cluster, has a different kind of write amplification. One that PostgreSQL does not have, because it reuses its WAL for the replication.

In addition, on the receiving side, MySQL first writes the incoming binlog to the relay log. The relay log is then consumed by the applier threads, creating more InnoDB writes and (by default) more binlog.