anderskaseorg

FFT is O(n log n), not O(n). The better O(n) algorithms are the likes of Deriche, Vliet–Young–Verbeek, or Alvarez–Mazorra.

You have ignored the much larger space and time cost of constructing the range minimum query tree in the first place. Furthermore, nobody would arbitrarily cut off a problem at “billions” and then consider O(√billions) or O(∜billions) to be “effectively O(1)”: a theoretician would complain that O() by definition measures the limiting behavior as the problem size tends to ∞, an engineer would complain that 65536 or 256 is very a important factor in practice, and both types are better served by leaving O(√n) or O(∜n) as-is instead of trying to hand-wave it away.

The “next level” button takes you to the next level even if you haven’t solved that level’s prerequisites.

Right, the public was able to spend manual effort hand-auditing one specific tarball after it had already been singled out as suspicious for other reasons. In order for verification to effectively increase supply chain security, it needs to become uniformly standardized, fully automated, and ubiquitous. That’s the ultimate goal of the provenance attestation mechanisms that would be defeated by indirection through private repositories.

If you want to require extra maintainer intervention for releases, there are better mechanisms available for that, such as workflow_dispatch.

There is a well-defined reload point—it’s the `subsecond::call` wrapper around `tick()`. But the hypothetical design that you seem to have in mind where this doesn’t exist would not have a well-defined reload point, so it would need to be able to preempt your program anywhere.

Layout changes are supported for structs that don’t persist across the well-defined reload point.

Of course (but that’s not relevant to the original scenario, where the programmer is hypothetically not aware that the read lock is still being held, let alone that they could manually upgrade it after changing to a different lock library).

Yes, allowing this to execute would be very unsound:

    let lock = RwLock::new(Box::new(111));
    let r: &i32 = &**lock.read().unwrap(); // points to 111
    *lock.write().unwrap() = Box::new(222); // allocates a new Box and deallocates 111
    println!("{}", *r); // use after free

Clippy already has an error for this pattern with Mutex. It should be trivial to extend it to cover RwLock.

    error: calling `Mutex::lock` inside the scope of another `Mutex::lock` causes a deadlock
      --> src/main.rs:5:5
       |
    5  |       if let Some(num) = *map.lock().unwrap() {
       |       ^                   --- this Mutex will remain locked for the entire `if let`-block...
       |  _____|
       | |
    6  | |         eprintln!("There's a number in there: {num}");
    7  | |     } else {
    8  | |         let mut lock2 = map.lock().unwrap();
       | |                         --- ... and is tried to lock again here, which will always deadlock.
    9  | |         *lock2 = Some(5);
    10 | |         eprintln!("There will now be a number {lock2:?}");
    11 | |     }
       | |_____^
       |
       = help: move the lock call outside of the `if let ...` expression
       = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#if_let_mutex
       = note: `#[deny(clippy::if_let_mutex)]` on by default

There are plenty of systems that sacrifice consistency even while the network is fully connected, in the name of performance—for example, DNS, or any system with a caching proxy server.

You’re certainly allowed to make the client a more active participant in your consensus protocol, but then it needs to play by the same rules if you want the system to have guarantees. For example, you need to handle network partitions between clients and some servers, and you need to be able to reconcile multiple reads from servers that might have seen different sets of writes. The CAP theorem still applies to the system as a whole.