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).
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.
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.
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.
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 entirely depends on what exactly you implement here, it's entirely possible to implement an AI with continuous & linear properties, meaning that you can extrapolate it's behaviour between a set of inputs with decent accuracy and it won't suddenly change it's behaviour between continuous & linear inputs.
But AI isn't different than existing software systems either. Both will take an input from reality and take actions upon it.
If for a given set of inputs there is a deterministic output, then the overall behaviour to a series of inputs is just as deterministic and predictable.
I'm not sure what you mean with "is not predictable" when you also admit that it's repeatable.
The pilots take off when they take off. If their take-off clearance isn't obviously time limited, they are certainly allowed to take their time. If they rush the take-off they might skip crucial items from their checklists in the haste, we learned that lesson the hard way already. Or what would have happened had the southwest jet had an issue on take off and had to reject? There is a number of reasons to reject a take off before decision speed that will take the plane down the rest of the runway on full brakes.