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.

That much is clear but any remotely continuous AI model is very predictable.

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.

What does that question even mean?

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.

AI is entirely deterministic. ChatGPT and StableDiffusion and friends are fed endless amounts of random seeds along with every input to keep them from just saying always the same thing.

The tape under the turing machine is infinite, so it's certainly not limited to 47M states. The conjecture states that all machines that halt will do so within 47M states.

The Pi's will be using those 200Watts at near full tilt. The main use here would be larger computational tasks that you can easily split up among the blades. Or you run a very hardware-failure tolerant software service on top.

I can still get SQLite to trivially corrupt indexes and table data by running it on top of NFS and dropping the network. I wouldn't put much money on this statement on their website.

The 1U server is however likely to use more than 200 Watts of power that the 40 Blade 2U setup would use.

Everyone should make decisions for themselves, but recommendations from positions of privilege should be well thought out.

This won't work if the server is being blocked. My mobile ISP blocks incoming UDP traffic unless the phone establishes the "connection" first. Since change of the server's public IP means that "connection" is broken, all unrelated UDP packets never arrive.

Wireguard does not handle this transparently.

I have a static v6 IP on the WG server (home router, running OPNsense).

Excuse my snark, but not everyone has a static v6 IP. I don't.

One time setup on the server

Unless you happen to be behind a CGNAT or you're on a mobile network or or or or...

Installed just like any other distro package, plus one-time setup to generate the key and import it and the server's public key into systemd-networkd / NetworkManager.

And if that won't work you're gonna be stuck debugging the network setup. I certainly do always end up debugging the VPN network stack eventually.

You generate a key on each device and register the public key with the server. There's literally nothing else to it.

This won't scale to more than like 5 devices without being a major work item if a key was compromised or needs to be rotated (what if it turns out the RNG device was bad on your kernel at the time? Happened to SSH Keys on RPi's).

I set it up about two years ago and it's been working unchanged since.

Not everyone is that lucky.

If you consider the overdraft limit, yes.

That's roughly it, 1.5K euros is not a lot. If you simply lost your job and went on social benefits, you would get 500€ + Rent from the state, so I don't think for many there is a good reason to have a job paying that low. The inflation is also eating up the savings of many of the lower class, so they're also looking to earn more. The upper management class in germany is however frighteningly conservative about raising wages aggressively.