zaarn

I highly doubt it's an SQLite bug, considering how thoroughly they test their code to behave correctly as long as their assumptions are filled. And those assumptions are clearly violated when SQLite runs on ZFS with sync=disabled (since writes may not be written to disk despite fsync).

I wouldn't recommend SQLite on ZFS (or in general for other reasons), for the precise reason that it either lags or is unsafe.

I've encountered this bug both on illumos, specifically OpenIndiana, and Linux (Arch Linux).

I've not observed other databases locking up on ZFS, Postgres and MySQL both function just fine, without needing to modify any settings.

As noted in a sibling comment, this causes corruption on power failure.

Disabling sync corrupts SQLite databases on powerloss, I've personally experienced this following disabling sync because it causes SQLite to hang.

You cannot have SQLite keep your data and run well on ZFS unless you make a zvol and format it as btrfs or ext4 so they solve the problem for you.

SQLite on ZFS needs the Fsync behaviour to be off, otherwise SQLite will randomly hang the application as the fsync will wait for the txg to commit. This can take a minute or two, in my experience.

Btrfs is a better choice for SQLite.

ZFS isn’t viable for SQLite unless you turn off fsync’s in ZFS, because otherwise you will have the same experience I had for years; SQLite may randomly hang for up to a few minutes with no visible cause, if there isn’t sufficient write txg’s to fill up in the background. If your app depends on SQLite, it’ll randomly die.

Btrfs is a better choice for sqlite, haven’t seen that issue there.

The output power of a rocket is different than a blow torch. The sound pressure alone is near or above atmospheric pressure. That concrete is being exposed to vacuum and more than 1atm pressure fairly rapidly. The heat on top of that and if the concrete has any moisture, the water inside is going to rapidly sublimate and condense several times a second. That is on top of the concrete being slammed into by an entire atmosphere of pressure in the meanwhile.

There is a reason that NASA dumps a few million liters of water under their rockets.

You're still referring to two distinct properties with Angular Moment being one and Spin being the other. Because a black hole can in fact orbit things and that would give it angular momentum. The spin value is merely how fast it rotates around an axis (which you can define but that's just an observational data point) and is unrelated to the external movement in spacetime.

The commenters is probably using ChatGPT to compose the reply, it's notorious for mathematical mistakes.

Spin and Angular momentum are two very different things. Angular momentum measures the velocity of a black hole in, eg, an orbit. Spin measures the rotation of a black hole against it's rest frame.

These are independent quantities.

There is a cheap and even for current humanity achievable way to rotate a black hole; change your frame of reference. That is not only true for angular momentum but linear momentum and position. Those are entirely dependent on the observer and their frame of reference. Spin, magnetic charge and mass are not.

Two black holes who differ only by their position, linear and/or angular momentum but are equal in all other parameters are not distinguishable from simply seeing the same black hole twice from a different perspective.

Two black holes who differ in any of the three properties of mass, spin or magnetic charge are distinguishable by those properties (but even that is arguable to some extend).

edit: The rent prices of a planet don't matter since frame of reference is an actual term here, there is no frame of reference more valid than any other for determining the linear or angular velocity or the position of a black hole.

The spin axis isn't a valuable reference since it depends on your frame of reference, which is a concept that gets rather ambiguous as you get close to a black hole anyway.

Plus you can just "rotate" a black hole to get it to have the same spin axis as another black hole. You can't "rotate" or "translate" a black hole in space to make the other three numbers change. Those require ingesting matter or emitting hawking radiation and that is the only thing that changes those properties.

Maybe uutils could have a build feature that specifically turns off the prefix matching and will break stuff but allows using newer and more useful flags in exchange. I've VERY rarely seen prefix-matched flags being used so I'd wager a distro could be fine deploying it that way.

Ie, setup the features "gnu-compatible-opt-matching" and ship it by default, then gate the extra features behind not turning on that feature.

That would be true of any software system we put into an airplane, yet we have deployed software into airplanes.

If your AI has linear / continuous output, testing it should be no different than any other software.