phlip9

I'm hoping we get there too with io_uring. It looks like the last few kernel release have made a lot of progress with zero-copy TCP rx/tx, though NIC support is limited and you need some finicky network iface setup to get the flow steering working

https://docs.kernel.org/networking/iou-zcrx.html

Benches look promising! My main concern is validating correctness; implementing good concurrency primitives is always challenging. Have you looked into testing against a purpose-built concurrency model checker like tokio-rs/loom [1] or awslabs/shuttle [2]? IMO that would go a long way towards building trust in this impl.

[1] https://github.com/tokio-rs/loom [2] https://github.com/awslabs/shuttle

Super cool project. Looks like the short-term target use-case is running a Linux-compatible OS in an Intel TDX guest VM with a significantly safer and smaller TCB. Makes sense. This way you also postpone a lot of the HW driver development drudgery and instead only target VM devices.

Exactly, it should use a separator. Consider a more realistic example, like http280 or h3443. Totally ambiguous.

Maintenance is much more practical when you use the versions upstream tests in their CI and not whatever mishmash of ancient/silently incompatible deps that each distro separately decides to combine together.

Can definitely recommend eza (prev. exa). I've used it as an ls replacement for a long time with zero problems. If anyone's using nix home-manager, here's my config for inspiration:

    programs.eza = {
      enable = true;

      # In list view, include a column with each file's git status.
      git = true;
    };

    programs.bash.shellAliases = {
      ks = "eza";
      sl = "eza";
      l = "eza";
      ls = "eza";
      ll = "eza -l";
      la = "eza -a";
      lt = "eza --tree";
      lla = "eza -la";
    };

Agreed. A while back I played around with fuzzcheck [1], which let's you write coverage-guided, structure-aware property tests, but the generation is smarter than just slamming a fuzzer's `&[u8]` input into `Arbitrary`. It also supports shrinking, which is nice. Don't know that I would recommend it though. It seemed difficult to write your own `Mutator`s. It also looks somewhat unmaintained nowadays, but I think the direction is worth exploring.

[1]: https://github.com/loiclec/fuzzcheck-rs/

Congrats on the release! I love the focus on devex w/ typescript and autocomplete. That's probably one of my biggest pain points with Nix -- writing any non-trivial package always requires a ripgrep adventure through nixpkgs. Finding the right poorly documented and poorly discoverable derivation attributes is always such a chore.

What are your plans for cross-compilation or heavy package customization? One of nixpkgs coolest party tricks imo is that you can just change the stdenv and get a musl static binary or cross-compiled binary.

Interesting thought. Maybe an LLM would build deeper insight with only one training language. On the other hand, the model might overfit with just one language -- maybe multilingual models generalize better?

I don't know much about the TKey, but it looks like they have some kind of remote attestation protocol available? (https://github.com/tillitis/tkey-verification/tree/main/cmd/...). That's usually how you avoid TOFU.

(1) the tillitis CA certifies your TKey device platform. You can now trust that it's running a specific firmware version with some platform pubkey.

(2) Your custom software is running and derives a keypair from it's derived secret + program binary hash.

(3) Somehow your custom software's pubkey gets locally certified by the platform's pubkey from (1). (not sure what this looks like w/ the TKey)

You now have a chain of trust from (1) the tillitis CA -> (3) the TKey device platform pubkey @ some specific firmware version -> (2) your custom software pubkey @ some specific version.

Now that we have a trusted pubkey for our service, I would open a secure channel to it via Noise IK or something (https://noiseexplorer.com/patterns/IK/). The TKey platform definitely looks a bit anemic so getting this working might be a challenge...

This looks pretty neat! I especially like how well it composes with other tools.

Wonder how well it compares with fastmod [0]? That's what I've been using for large scale codemods/refactors. ripgrep is ofc insanely fast so ripgrep+ren would probably fare favorably.

[0]: https://github.com/facebookincubator/fastmod/

sccache only caches if builds are run from the same absolute path, so indeed different home dirs won't work

They're listed separately as West Bank and Gaza Strip

A related example out in the wild:

Rust's `cargo bench` "winzorizes" the benchmark samples before computing summary statistics (incl. the mean).

https://github.com/rust-lang/rust/blob/master/library/test/s...

100% on board and super happy that `ring` is finally getting some love again (and funding!)

For context: the ring repo's been a bit inactive lately and the v0.17 release looked like it stalled out. Thankfully there's been a burst of activity in the past several weeks so I'm feeling a lot better.

As a serial tab hoarder, Vimium's SHIFT-T tab fuzzy search is what makes it manageable. : )

Yeah it's pretty awesome! I used GPT-4 last week to fix my corrupted SSD. Granted I already narrowed down the kernel logs to a few suspicious lines, but I just pasted those 10 lines in and asked for a fix. Pasting in GPT's arcane `fsck` incantations and boom -- fixed SSD. Saved me an hour or two of hassle reading man pages and stack overflow posts.

I think even heartbleed would be mitigated with (safe) Rust. IIRC heartbleed was caused by a missing bounds check, which allowed attackers to read past the message buffer and leak secrets from nearby memory. Safe Rust would just panic (crash) if you tried to slice past the end of the buffer.

Languages with first class effects, like koka[1], require you to declare up-front what side effects (sample randomness, do I/O, abort, etc...) your function might cause.

Then from another outer function, you can't call the effectful function unless the outer function also declares those same side-effects (or you provide handlers for them).

This way you can easily isolate non-determinism and I/O to the top-level part of your program, while keeping the interior business logic pure.

The "first-class effects" part is what lets you easily compose effects and inject custom handlers. Ideally in a way that's more ergonomic than juggling with Monad type system Jenga.

[1]: https://koka-lang.github.io/koka/doc/index.html

AdGuardHome is pretty great. Run it on my OpenWRT router and miss it every time I use my phone away from home : )

similar: you can do SIMD "within" a single integer type with some fun bit hacks.

ex: for an integer (u32, u64, u128), you can test "all at once" whether any byte == 0, or any nibble == 0, etc... like: [0]

    fn u32_any_byte_eqz(x: u32) -> bool {
        let t = x.wrapping_sub(0x0101_0101);
        let u = !x & 0x8080_8080;
        let v = t & u;
        v != 0
    }

which generates pretty compact assembly:

    example::u32_any_byte_eqz:
            lea     eax, [rdi - 16843009]
            andn    eax, edi, eax
            test    eax, -2139062144
            setne   al
            ret

even more powerful, you can test whether any byte `b` is in the range `m < b < n` "all at once", where `0 <= m <= 127` and `0 <= n <= 128`. [1]

    fn u32_has_byte_between(x: u32, m: u32, n: u32) -> bool {
     let mask = 0x0101_0101;
     let s = mask * 127;
     let y = mask * 128;
     let w = mask * (127 + n);
     let t = mask * (127 - m);
    
     let u = x & s;
     let z = (w - u) & (!x) & (u + t) & y;
    
     z != 0
    }

by changing the mask you can also select which bytes/nibbles you care about.

i've used these to pretty great effect when writing a montecarlo tree search. you just need some care to tightly bit-pack the core structs, then you're golden.

[0]: https://phlip9.com/notes/performance/bit%20hacks/#any-byte-0 [1]: https://phlip9.com/notes/performance/bit%20hacks/#any-byte-b...

Woah this looks cool! My current (clearly outdated) mental model requires fixed inputs for a zkp, e.g., some fixed view of the chain state, some encrypted inputs, etc... I'm curious to know more how Mina overcomes these limitations.

OTOH, secure enclaves like SGX are convenient since the overhead's not bad, you can run the enclave as a networked service, make HTTPS connections, sample randomness via RDRAND, etc...

Do you think zkapps might have similar capabilities in the future? I'm not sure the analogy works all that well in blockchain land, but perhaps more as a virtual software-only enclave or something?

It's not super clear to me how you would sample private randomness, or perform remote attestation, or prevent replay attacks without a remote trusted storage.

I also remember even the best proof systems seemed to have like 100x prover overhead on CPU + memory usage, but that was a few years ago. Have things gotten better recently?

Ahh thanks for the link and sorry for the snark; the finite universe optimization is cool! [0]

  # Why is CRLite able to compress so much data?
  
  Bloom filters are probabilistic data structures with an error rate due to data collisions. However, if you know the whole range of data that might be tested against the filter, you can compute all the false positives and build another layer to resolve those. Then you keep going until there are no more false positives. In practice, this happens in 25 to 30 layers, which results in substantial compression.

EDIT: Is there any risk of filter blow up (think 1000's of layers) if a CA did a mass revocation (maybe some root key leak)?

[0] https://github.com/mozilla/crlite/wiki#why-is-crlite-able-to...

I can't wait for some big site certs to false positive in a CRL bloom filter and cause a big outage : )

btw the example image (https://erock.imgs.sh/t/iceland) 404's :(

From the article, it looks like the syzkaller fuzzer integration was stale and not working, so there might still be some juice to squeeze if someone can get that running again : )

separate cache lines not pages :)

I was a bit disappointed with linearity in QTT as I couldn't figured out how to create a safe API around a resizable array.

The example given in the paper is a LinArray (https://github.com/idris-lang/Idris2/blob/main/libs/contrib/...). Unfortunately, as the community discovered, a user can "leak" a non-linear binding outside of the `newArray` constructor (which is what attempts to enforce linearity for all bindings). With multiple unrestricted handles, a user can accidentally double-free for instance. (https://github.com/idris-lang/Idris2/issues/613)

The fundamental issue in this case is that linearity in QTT is a property of the parameter bindings and _not_ the type itself, meaning we can't easily express linearity as a _global_ property of the type.

On the other hand, only affecting the parameter bindings makes it really easy to use runtime-erased/comptime stuff without reimplementing a bunch of common types as runtime- and comptime-only versions.

ATS chooses the other path and makes linearity and runtime-erasure a part of the type (not without paying a hefty syntactic cost however).

> RustBelt is a formal model of Rust’s type system, together with a soundness proof establishing memory and thread safety. [1]

[1] https://people.mpi-sws.org/~jung/thesis.html

Or spun differently, _I_ can run private, trusted code on an adversarial, remote EC2 instance without compromising my privacy and preventing the adversary (Amazon) from tampering with my secure execution.

At least in theory. IIRC, a number of side channel attacks are exploitable on Intel SGX, so the adversary could leak secrets but not tamper with execution.