I know very little of this but it seems like not all things kratom are affected.

> This temporary scheduling action does not apply to botanical kratom products that contain naturally occurring 7-OH below the specified threshold. Instead, it targets synthesized products and those containing elevated concentrations of 7-OH as outlined in the temporary scheduling order. DEA believes these substances pose an imminent threat to public safety given their effects are highly unpredictable.

According to the ROI (https://www.federalregister.gov/documents/2026/07/06/2026-13...), the threshold isn't yet fixed but the suggested value would be 1 milligram or 5% of the dry-mass. Doses sold are in grams so this would ban kratom.

Paragraph A,not paragraph B applies to actual kratom leaf.

> Any botanical material of the plant Mitragyna speciosa, also known as kratom, and contains more than 0.050 percentage of 7-hydroxymitragynine on a dry weight basis

Indeed, thanks for catching that. No maximum for an actual kratom leaf but leafs cannot be too potent, right?

I'd been hoping for G4 to be added so I could play around with it. Pretty much spent all of last week doing so. I thought something was short-circuiting due to the speed of response, I'd never seen a model operate that fast.

https://inference-docs.cerebras.ai/models/gemma-4-31b

The graph has Gemini 3.5 Flash matching Sonnet 4.6, losing to Opus 4.8, and slightly behind GPT-5.5 by 0.3 points... That's not that much of a hands-down loss for Gemini for this specific workload benchmark.

The methodology used:

https://deepmind.google/models/evals-methodology/gemini-3-5-...

Methodology: All Gemini scores are pass @1 except where otherwise noted. "Single attempt" settings allow no majority voting or parallel test-time compute. All of the results are all run with the Gemini API for the model-id gemini-3.5-flash with default sampling settings unless indicated otherwise below. To reduce variance, we average over multiple trials for smaller benchmarks.

All the results for non-Gemini models are sourced from providers' self reported numbers unless otherwise mentioned below. For Claude Opus 4.7 , Sonnet 4.6, and GPT-5.5 we default to reporting maximum thinking/reasoning settings available, but when reported results are not available we use best available reasoning results.

You may need to have certain directories be excluded depending on the programs you use. For example, the default Chrome profile location is within ~/.config, which includes cache data that can be multiple gigabytes in size.

Ouch. It doesn't respect `$XDG_CACHE_HOME`?

Browsers are some of the most annoyingly configured applications out there.

That's what .gitignore is for ;)

This sounds... not possible for the core problem of how Python handles dependency resolution during the life of an application? How are you setting things up so that the following scenario is valid?

    program
    ├── dependency_a
    │   └── dependency_c (1.0.0)
    └── dependency_b
        └── dependency_c (2.0.0)

Otherwise, you've created a magic layer hack to enable multi-version dependency chains in a mono-version dependency chain language.

I'll try to get around to a Show HN some time for it, but it's essentially as sibling reply states.

Python's import system is extensible: https://docs.python.org/3/reference/import.html#import-hooks It might be possible to create a custom finder that will return 1.0.0 when running "import dependency_c" in dependency_a but 2.0.0 for the same import statement in dependency_b. You'll need to work around the module cache in sys.modules, though. And good luck trying this on a package that also hooks the import system...

Yep that's pretty much how I do it, along with RPyC[0] for connection.

[0] https://rpyc.readthedocs.io/en/latest/

I do not know if there's any overlap between these teams, but it seems like Anthropic itself is fairly invested in the Rust ecosystem.

They recently proposed some of their internal tools to be the official Rust implementation[0] of Connect RPC[1]. As a protobuf based library set, this includes a new Rust-based protobuf compiler, Buffa[2].

[0]: https://github.com/orgs/connectrpc/discussions/7#discussionc...

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

[2]: https://github.com/anthropics/buffa

My understanding of Backblaze Computer Backup is it is not a general purpose, network accessible filesystem.[0] If you want to use another tool to backup specific files, you'd use their B2 object storage platform.[1] It has an S3 compatible API you can interact with, Computer Backup does not.

But generally speaking, I'd agree with your sentiment.

[0]: https://www.backblaze.com/computer-backup/docs/supported-bac...

[1]: https://www.backblaze.com/docs/cloud-storage-about-backblaze...

> The claude sandbox is a good idea, but to be effective it would need to be implemented at a very low level and enforced on all programs that claude launches.

I feel like an integration with bubblewrap, the sandboxing tech behind Flatpak, could be useful here. Have all executed commands wrapped with a BW context to prevent and constrain access.

https://github.com/containers/bubblewrap

Bubblewrap is exactly what the Claude sandbox uses.

> These restrictions are enforced at the OS level (Seatbelt on macOS, bubblewrap on Linux), so they apply to all subprocess commands, including tools like kubectl, terraform, and npm, not just Claude’s file tools.

https://code.claude.com/docs/en/sandboxing

Oh wow I'd have expected them to vibe-code it themselves. Props to them, bubblewrap is really solid, despite all my issues with the things built on top of it, what, Flatpak with its infinite xdg portals, all for some reason built on D-Bus, which extremely unluckily became the primary (and only really viable) IPC protocol on Linux, bwrap still makes a great foundation, never had a problem with it in particular. I tend to use it a bunch with NixOS and I often see Steam invoking it to support all of its runtimes. It's containers but actually good.

The more you know, thanks for the information!

I'm looking at building a new system, and was waiting to see what happens with this chip and Intel's Arc Pro B70 card. I can't find ECC UDIMMs of 64GB per-stick to make 128GB, but I can put together two solo UDIMMs of 32GB or 48GB for $800 and $1000 per stick respectively.

I really want to see what enabling the L3 cache options in the BIOS do from a NUMA standpoint. I have some projects I want to work on where being able to even just simulate NUMA subdivisions would be highly useful.

I was surprised to find that ECC modules available were 24 or 48, so 128GB with 2 sticks was impossible.

While I was aiming at 128, I settled for 96GB, because any more than 2 sticks means a sharp drop in RAM clocks this generation.

> Having used `jq` and `yq`

If you don't mind me asking, which yq? There's a Go variant and a Python pass-through variant, the latter also including xq and tomlq.

Indeed, thanks for spotting that, as I myself remember discovering there's at least two. Thing is, I had learned and started with Mike Farah's `yq`, not the pass-through-to-`jq` variant written in Python that's often more easily (read: system package manager) available. Both semantics and syntax are a bit different between the two.

A bit of a fun fact: there's a quote by Farah where he said that the language and semantics of the tool he was writing, didn't really "click in" until he was well into writing it :-) I myself have been on occasion pulling my hair out trying to wield `yq`'s language, there's some inconsistencies here and there which I think are related to the novel nature of the language (not novel to everyone but it's uncommon even for those well versed with e.g. SQL). `jq` suffers from similar woes, but to a lesser degree.