namjh

Tangential: I like the approach about constraining supported models and utilizing more performance from the constraint. Actually I was doing a same approach for the same model Qwen3.8 27B, but apparently inco.ai did much better job: https://github.com/cr0sh/qw

Something off in my mind: how did the agent access to Tor network if the traffic outgoing was monitored and intercepted to only allow read-only access to web(I assume this is an MITM L7 proxy that only allows GET methods and specific hosts) ? Did the sandbox dev forgot to block HTTP CONNECT that is used to reach Tor Entry Guards?

OpenRouter is great business I agree, but I'm not still convinced how the integrity of providers' models is ensured. In other words, can't the provider serve DSv4 flash advertising it as DSv4 Pro?

I'm aware that OpenRouter checks response quality onboarding, and does further checks occasionally, but I'm concerned that it's basically a cat-and-a-mouse problem between the scammers and the detectors. For example, there could be a signal that a specific pattern of requests are from OpenRouter's quality testing bots. Or, they can just route 1% of requests to an inferior model and benefit a small gain, hoping it fits into the statistically allowed margin.

Nice article, and I'd like to mention an additional topic that would give the readers some impression:

Fiat-Shamir transformation. The interactive process between the prover and verifier can be transformed into a non-interactive one with a hash function(modeled as a random oracle). This improves the "user experience" as the entire proving process can be done in a single turn. The idea is to feed the problem itself into the hash function and let it generate randomness that was originally given by the verifier.

In that way the autoregressive nature of LLM won't let itself "plan" to reason with the intended budget. It doesn't "look ahead".

I don't use Claude for my daily work anymore(due to OAuth restrictions on third party agents), but one theory I saw in another community why Opus 5 is so bad even though benchmark scores were good, is that Anthropic's internal usage pattern is to let Fable to spawn and manage swarms of Opus subagents. This pattern won't penalize that Opus is not well aligned for direct human coworking on posttraining. The worse part is, this makes Fable the user's best default choice for every jobs even if they don't have unlimited credits like Anthropic employees do.

As a South Korean I'm lowkey surprised that most reactions posted here is describing the detention experience to be some kind of human rights abuse. Most Koreans debating on Internet demand severe punishment so criminals be afraid of getting jailed. I know this is a very questionable strategy, but afaik this is the most dominant public sentiment over this topic.

Yes we do have[^1] but unfortunately it looks like not checking the integrity, just reachability.

[1]: https://downdetectorsdowndetectorsdowndetector.com/

Amazed that Safari does not support WebGPU even with the latest release. Opened Chrome and it works. Very cool demo!

> Consequently, this also means you cannot define two error variants from the same source type. Considering you are performing some I/O operations, you won't know whether an error is generated in the write path or the read path. This is also an important reason we don't use thiserror: the context is blurred in type.

This is true only if you add #[from] attribute to a variant. Implementing std::convert::From is completely optional. Personally I don't prefer it too as it ambiguates the context. I only use it for "trivially" wrapped errors like eyre::Report.

Anyone who needs to handle FFI in Rust, should read the FFI chapter in Rustonomicon: https://doc.rust-lang.org/nomicon/ffi.html

Unsafe Rust is indeed very hard to write correctly. Rustonomicon is a good start to learn unsafe Rust.

There was an NFT section in the claim form so certainly they are aware of but I'm not sure it's still open

Big kudos to Rust compiler devs about their sophisticated type system and its kind (and highly intelligent) help messages. A little concern is that AFAIK its complexity in type systems and other static analysis things require deep domain knowledge, so in a far, far future there may be a lack of "core" engineers comparing to a demand much increased at that point. This kind of change looks like already requiring deep understanding of both Rust's type system and internal compiler structure to implement.

That's because the code triggering compilation error is using reference. If you use Rc or Arc (which pays runtime cost) there should be no lifetime at all.

Albeit I admit there somewhat exists a community sentiment like "if you use Rust, you should maximize its zero cost abstraction feature so lifetime is good and generics good", and my (minor) opinion is that, it's not always true to all users of Rust.

And the clumsy Arc<Mutex<Something<TheOtherThing>>> makes users feel bad about using runtime cost paid types. Maybe we should introduce easy Rust dialect which transpiles into Rc/Clone everywhere but I doubt it's trivial to transpile.

IMHO the mentioned examples of complexity like multiple type variables and lifetimes with bounds are for who "really" wants compile-time contracts. These are mostly opt-in so higher level use cases(like writing backend business logics) should not care about that, just wrapping everything with Boxes and Arcs.

Of course Rust is not perfect; there is some 'leakages' of low level aspects to high level like async caveats(recursion, pinning, etc.). I'm not sure how these can be avoided. Maybe just trial-and-errors for all..?

Do we have a better method of verifying compilation output than just re-executing the compiler with same source, than comparing the output? TEE attestation could be a thing(albeit it could be a "trusted" third party which occasionally be broken).

Albeit 1.6PB/day may be somewhat exaggerated, comparing Binance to Ethereum needs much more consideration including:

- Ethereum's transaction throughput is normally 12~20tx/sec so there cannot be a "high-frequency trades" on Ethereum smart contracts with naive contract interaction(it will cost enormous fees). There are scaling concept like "layer-2" or "layer-3", but they still cannot beat highly optimized centralized server applications. Decentralized exchanges have different schemes to centralized ones to reduce txs to discover the price(keyword: AMM, "automated market maker")

- The transactions per sec metrics are just recording "confirmed" txs by the blockchain, and many "retail-squeezing" trading txs (called MEV, maximal value extraction) are competing behind the blockchain and only one tx is chosen by the blockchain, which will rebate most profits to the blockchain validator(which is analogous to the HFTs on the centralized exchanges).

- The blog post's argument would count all logs of intermediate hops, like L7/L4 proxy and matching engine and so on, and Ethereum's full node storage is only a single component which is almost like a non-parallelized matching engine. Maybe we should also count logs of public RPC nodes of Ethereum? (Also many txs are not gossiped to the public mempool so these are hard to count)

Interesting project and kind of tangential topic, will JIT compilers still be widely adopted given they are considered a critical attack vector when it misbehaves? I wonder if there is an effort to formally verify its safety or do a complete redesign to ensure it.

Great work! I really enjoyed the interactivity. Actually I already was aware of the concept of zero-knowledge proof from the wonderful article by ZCash(which is a privacy-oriented cryptocurrency) core developer Matthew Green, worth to check it out: https://blog.cryptographyengineering.com/2014/11/27/zero-kno...

My two cents of the ZKP illustration is that directly using hashes are more likely to convince "computer-friendly" people to introduce the commitment scheme.

In reality, the entire map should be sent first to the verifier (with colors hid behind the post-it) so if it was a bogus randomly colored map, you may find two adjacent points having same color if you try extremely many(think hundreds or thousands in the website's case) times. If you sufficiently try many times and fail to find the adjacent points, you will convince that the prover have the map which is correctly 3-colored.

Note that the entire map is sent again, shuffled its color each time after you choose the two points.

Am I the only one just seeing a blank page? Proxying via archive.is did not help.

Edit: after some googling I found https://lists.freebsd.org/archives/freebsd-hackers/2024-Janu... but I couldn't read the whole thread at once

> The problem is that in the ecosystem we are building the prevailing assumption is that anything async must also be Send, which means we end up using Send primitives even in non-Send contexts, which is always a waste.

Honestly I don't think every user want top notch throughput when writing asynchronous Rust applications. Most users would just want the correctness of the Rust type system, and its "lightweight" runtime characteristics compared to CPython, Node.js etc., which can provide fairly good performance.

The thing is, using Arc in single threaded runtime does not greatly harm performance. If it matters, you should be handling 1M+ rps per core and using multithreaded runtime because it scales better, which benefits from using threadsafe primitives.

> Making things thread safe for runtime-agnostic utilities like WebSocket is yet another price we pay for making everything multi-threaded by default. The standard way of doing what I'm doing in my code above would be to spawn one of the loops on a separate background task, which could land on a separate thread, meaning we must do all that synchronization to manage reading and writing to a socket from different threads for no good reason.

Why so? Libraries like quinn[1] define "no IO" crate to define runtime-agnostic protocol implementation. In this way we won't suffer by forcing ourselves using synchronization primitives.

Also, IMO it's relatively easy to use Send-bounded future in non-Send(i.o.w. single-threaded) runtime environment, but it's almost impossible to do opposite. Ecosystem users can freely use single threaded async runtime, but ecosystem providers should not. If you want every users to only use single threaded runtime, it's a major loss for the Rust ecosystem.

Typechecked Send/Sync bounds are one of the holy grails that Rust provides. Albeit it's overkill to use multithreaded async runtimes for most users, we should not abandon them because it opens an opportunity for high-end users who might seek Rust for their high-performance backends.

[1]: https://github.com/quinn-rs/quinn

Might be related: https://arxiv.org/abs/2211.16421 It's a paper about directly learning via JPEG encodings which works well with visusal transformers' patch mechanism.

When I was a newbie for Rust, I was encouraged to use CLion with the Rust plugin. What's the difference between CLion + Rust and IDEA + Rust?

Wow, if I were you, I would never think of analyzing the rustc source code. Great job!