HackerLangs
トップ新着トレンドコメント過去質問紹介求人

tarruda

2,943 カルマ登録 13 年前
[ my public key: https://keybase.io/tarruda; my proof: https://keybase.io/tarruda/sigs/LfzoAvuAtqMKfg4heD0NRvBBrY8p1U4AFdWg_LGswnQ ]

投稿

Step 3.7 Flash

static.stepfun.com
48 ポイント·投稿者 tarruda·先月·16 コメント

Show HN: An in-browser, Unix emulator powered by libghostty-vt

tarruda.github.io
2 ポイント·投稿者 tarruda·2 か月前·0 コメント

コメント

tarruda
·9 時間前·議論
> It would be fundamentally wrong for you to ask what's the value of solving the Erdős–Hajnal conjecture; the value is that it's solved.

I suspect the value is in showing the potential that LLMs have in developing new breakthroughs.
tarruda
·15 時間前·議論
Assuming steady 1 tok/second generation (which seems to be the case for M5 Max macbook), wait 1 day for a 86400 token response. In some configurations it can be as slow as 0.1 tok/s, so be prepared to wait for 10 days.
tarruda
·昨日·議論
Recently tried the pelican test on GPT-OSS which was probably one of the best local models of 2025. So cool to see how models have improved in the SVG pelican!
tarruda
·昨日·議論
> given they are pretty close in size

One thing that might not be obvious about about DSV4 is how much innovation the Deepseek team implemented in its architecture. When llama.cpp fully supports its lightning indexer, the full 1M context will only require about 6G of RAM. So even though they are similar in size, I believe Deepseek will be much more efficient in that regard.

> I wonder if Hy3 can compete there

Highly depends on how well Hy3 is resilient to quantization. DSV4 is useful even at 2-bit quants.
tarruda
·15 日前·議論
Hopefully this distillation will lead Alibaba to release more powerful open weights LLMs, contributing to the democratization of AI.
tarruda
·17 日前·議論
Vibe thinker also beats Opus 4.5
tarruda
·18 日前·議論
If your framework desktop is the 128G Strix Halo, I recommend giving Qwen 3.5 122B-A10B a shot.

This Q5_K_M quant should be near lossless and fit with full 256K context in about 100GB of RAM: https://huggingface.co/AesSedai/Qwen3.5-122B-A10B-GGUF
tarruda
·21 日前·議論
I don't feel like AI coding has ruined my skills, and I could go back to manual coding any time.

However, I cannot build a good mental model of a software component that I didn't write myself, and that can affect future maintenance if that component is not properly decoupled from the rest of the system.
tarruda
·26 日前·議論
What I find fascinating is the idea that there might be a set of "secret" tweaks that when applied to those weights (or even smaller models) could result in an intelligence simulation that could vastly surpass even something like Fable.
tarruda
·先月·議論
Not as much as Qwen, since apparently 3.6 35B surpassed Opus 4.7 https://x.com/simonw/status/2044830134885306701
tarruda
·先月·議論
I don't think there's any incentive for Nvidia to make this a Windows-only device, so most likely it will be fully supported on Linux, just like their GPUs are.
tarruda
·先月·議論
> This also means that, according to our plans, Zig will have to propagate "stackless-ness" upwards in the call chain while analyzing the code (thus making Future.await not special per-se).

Very interesting, will be following Zig development more closely. Thanks for sharing!
tarruda
·先月·議論
> there's an accepted proposal to bring them back, in which case any function that calls await, or that otherwise has a suspension point, would have to be transformed into a stackless coroutine by the compiler, yes. The plan is for that to happen transparently without requiring an `async` annotation in the function signature, like we already did in the past.

If the compiler will treat functions that call a library function (Future.await) as special and change how the call site is compiled, why not just have an `await` keyword that when present will convert it into a state machine that can be suspended/resumed?

In other words: What is gained by not having a keyword that changes how a function is emitted if the compiler will change it anyway based on detection of a library call?
tarruda
·先月·議論
Fixed it. thanks!
tarruda
·先月·議論
> especially with the new IO mechanism which allows supper efficient code that looks good whether it's implemented single-threaded, multi-threaded or just via an event loop!

I had some trouble understanding how the async/await mechanism works:

  var foo_future = io.async(foo, .{args});
  defer if (foo_future.cancel(io)) |resource| resource.deinit() else |_| {}

  var bar_future = io.async(bar, .{args});
  defer if (bar_future.cancel(io)) |resource| resource.deinit() else |_| {}

  const foo_result = try foo_future.await(io);
  const bar_result = try bar_future.await(io);
My assumption is that calling io.async using an event loop implementation of IO, it will internally start a "task" (or whatever it should be called) and that the future is a handle to it. So far so good.

The part that I don't understand is what happens when you call future.await(io). Will the IO implementation somehow suspend the current function and resume once the future is resolved? If so, does that mean that every function in zig is a stackless coroutine?
tarruda
·先月·議論
The official Q4_K_S gguf is quite good and has very good 35 tps generation on a M1 mac studio. Should be much faster on recent Macs, especially M5.
tarruda
·先月·議論
> One of the most prominent improvements in Opus 4.8 is its honesty.

Does that mean it no longer deletes or changes tests to make it pass?
tarruda
·2 か月前·議論
> safer bet as a dependency.

The recent 1 million line vibe coded PR suggests it is not so reliable as a dependency.
tarruda
·2 か月前·議論
> That's impressive getting a 397B down to <110GB

It is higher than 110GB. MacOS allows up to 125G of the RAM to be shared with GPU, so it is certainly less than that!

> HF link is broken though!

Doesn't seem broken to me, but you should be able to search for tarruda/Qwen3.5-397B-A17B-GGUF on huggingface.
tarruda
·2 か月前·議論
> I'm questioning ROI

If by ROI you mean saving more money than using paid APIs, then I don't think it is worth it. All you gain is full sovereignty over your AI usage.