skavi

no profile record

comments

قبل 23 يومًاdiscuss

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

قبل 30 يومًاdiscuss

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-...

الشهر الماضيdiscuss

This is discussed in the post.

قبل شهرينdiscuss

see Windows Subsystem for Linux and Windows Subsystem for Android.

قبل شهرينdiscuss

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

قبل 3 أشهرdiscuss

(2017)

قبل 3 أشهرdiscuss

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

قبل 3 أشهرdiscuss

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

قبل 3 أشهرdiscuss

i’ll take 3. we can be boring together

قبل 3 أشهرdiscuss

doesn’t really feel like that much tbh

قبل 3 أشهرdiscuss

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 أشهرdiscuss

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 أشهرdiscuss

Their suggestion is also zero runtime cost.

قبل 4 أشهرdiscuss

wonder whether this will impact their funny little functional language.

قبل 4 أشهرdiscuss

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

قبل 4 أشهرdiscuss

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 أشهرdiscuss

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 أشهرdiscuss

nope.

قبل 4 أشهرdiscuss

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 أشهرdiscuss

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.