skavi

no profile record

comments

23 gün öncediscuss

it would suck if Chinese tech advanced medical care faster or made it cheaper.

30 gün öncediscuss

On the earliest web archive snapshot I can find [0], I do not see any mention of the safeguard/sabotage under discussion [1].

And to be clear, this isn't the safeguard where the model is explicitly downgraded to Opus, but rather where the Fable/Mythos model's "effectiveness" is transparently "limited" via "prompt modification, steering vectors, or parameter-efficient fine-tuning (PEFT)".

[0]: https://web.archive.org/web/20260609173222/https://www.anthr...

[1]: https://simonwillison.net/2026/Jun/10/if-claude-fable-stops-...

geçen aydiscuss

This is discussed in the post.

2 ay öncediscuss

see Windows Subsystem for Linux and Windows Subsystem for Android.

2 ay öncediscuss

https://news.ycombinator.com/item?id=48029540

3 ay öncediscuss

(2017)

3 ay öncediscuss

i assume it does not have the same goals wrt hermeticity as nix?

3 ay öncediscuss

where does this fit in with make, just, nix (devshell, devenv, ...), direnv, etc.

3 ay öncediscuss

i’ll take 3. we can be boring together

3 ay öncediscuss

doesn’t really feel like that much tbh

3 ay öncediscuss

to preempt a discussion emerging based on the title alone, here’s their summary:

> While nuclear fusion power is often hailed as a future source of abundant, clean energy, current dominant fusion designs, magnetic and laser inertial, are unlikely to become competitive due to their expected low experience rates. Accordingly, policymakers should not rely on, or fund, fusion power as a core pillar of future clean energy systems unless designs with different characteristics are developed.

3 ay öncediscuss

this may have been what you were referring to with “ buggy GNOME extensions”, but in case it wasn’t:

https://tailscale.com/docs/features/client/linux-systray

4 ay öncediscuss

Their suggestion is also zero runtime cost.

4 ay öncediscuss

wonder whether this will impact their funny little functional language.

4 ay öncediscuss

what was the security situation of whatever is now being protected by the IOMMU before it was enabled by default?

4 ay öncediscuss

also:

1. tcmalloc is actually the only allocator I tested which was not using thread local caches. even glibc malloc has tcache.

2. async executors typically shouldn’t have tasks jumping willy nilly between threads. i see the issue u describe more often with the use of thread pools (like rayon or tokio’s spawn_blocking). i’d argue that the use of thread pools isn’t necessarily an inherent feature of async executors. certainly tokio relies on its threadpool for fs operations, but io-uring (for example) makes that mostly unnecessary.

4 ay öncediscuss

on the OS scheduler side, i'd imagine there's some stickiness that keeps tasks from jumping wildly between cores. like i'd expect migration to be modelled as a non zero cost. complete speculation though.

tokio scheduler side, the executor is thread per core and work stealing of in progress tasks shouldn't be happening too much.

for all thread pool threads or threads unaffiliated with the executor, see earlier speculation on OS scheduler behavior.

4 ay öncediscuss

nope.

4 ay öncediscuss

modern tcmalloc uses per CPU caches via rseq [0]. We use async rust with multithreaded tokio executors (sometimes multiple in the same application). so relatively high thread counts.

[0]: https://github.com/google/tcmalloc/blob/master/docs/design.m...

4 ay öncediscuss

We evaluated a few allocators for some of our Linux apps and found (modern) tcmalloc to consistently win in time and space. Our applications are primarily written in Rust and the allocators were linked in statically (except for glibc). Unfortunately I didn't capture much context on the allocation patterns. I think in general the apps allocate and deallocate at a higher rate than most Rust apps (or more than I'd like at least).

Our results from July 2025:

rows are <allocator>: <RSS>, <time spent for allocator operations>

  app1:
  glibc: 215,580 KB, 133 ms
  mimalloc 2.1.7: 144,092 KB, 91 ms
  mimalloc 2.2.4: 173,240 KB, 280 ms
  tcmalloc: 138,496 KB, 96 ms
  jemalloc: 147,408 KB, 92 ms

  app2, bench1
  glibc: 1,165,000 KB, 1.4 s
  mimalloc 2.1.7: 1,072,000 KB, 5.1 s
  mimalloc 2.2.4:
  tcmalloc: 1,023,000 KB, 530 ms

  app2, bench2
  glibc: 1,190,224 KB, 1.5 s
  mimalloc 2.1.7: 1,128,328 KB, 5.3 s
  mimalloc 2.2.4: 1,657,600 KB, 3.7 s
  tcmalloc: 1,045,968 KB, 640 ms
  jemalloc: 1,210,000 KB, 1.1 s

  app3
  glibc: 284,616 KB, 440 ms
  mimalloc 2.1.7: 246,216 KB, 250 ms
  mimalloc 2.2.4: 325,184 KB, 290 ms
  tcmalloc: 178,688 KB, 200 ms
  jemalloc: 264,688 KB, 230 ms

tcmalloc was from github.com/google/tcmalloc/tree/24b3f29.

i don't recall which jemalloc was tested.