Article URL: https://github.com/yanun0323/deepseek_ssd

Comments URL: https://news.ycombinator.com/item?id=49238558

Points: 2

# Comments: 0

Article URL: https://www.blocksandfiles.com/flash/2026/08/03/kioxias-nearly-faster-than-optane-ssd/5282259

Comments URL: https://news.ycombinator.com/item?id=49181295

Points: 3

# Comments: 0

Article URL: https://atticformac.com/

Comments URL: https://news.ycombinator.com/item?id=49162874

Points: 2

# Comments: 0

Article URL: https://bsid.io/writing/the-ssd-that-cried-etcd

Comments URL: https://news.ycombinator.com/item?id=49148513

Points: 14

# Comments: 6

Article URL: https://www.storagereview.com/news/kioxia-cm10-is-its-first-pcie-6-0-enterprise-ssd-aimed-at-nvidia-cmx-kv-cache

Comments URL: https://news.ycombinator.com/item?id=49128072

Points: 4

# Comments: 0

I've been building streaming inference kernels for Zonos, the open SSM-based (Mamba2) TTS model, on an A10G. This post is two hand-written CuTeDSL kernels in two regimes, and the contrast is the point.

The first is a skinny bf16 GEMV for the batch-1 decode projections. It beats cuBLAS by up to 1.36x, not because it's clever, but because cuBLAS pads the tiny M dimension out to a tensor-core GEMM tile and leaves memory bandwidth on the floor at exactly that shape. It's memory-bound, so I measured the actual achievable read bandwidth (520 GB/s, not the 600 GB/s spec) and tuned to that roofline.

The second is a from-scratch port of Mamba2's four-stage SSD chunked scan. It loses to Tri Dao's Triton by ~2x, and the gap widens with sequence length. Triton is nearly flat as the work grows 32x while mine climbs linearly, which is the signature of exposed per-chunk load latency that Triton's software pipelining hides and my single-buffered version doesn't.

The takeaway I keep coming back to: a hand kernel wins where the library is forced to generalize and loses where the library is already specialized for your exact problem. The whole skill is knowing which situation you're in before you spend the three weeks.

Also documented: a kernel that benchmarked at 50x the chip's memory bandwidth (a CUDA-graph stream-capture bug), and why a bit-accurate drop-in kernel still changes 4.6% of tokens in a 34-layer autoregressive model.

Writeup: https://kyrieblunders.bearblog.dev/the-kernels-that-were-the... Code and profiling docs: https://github.com/Vishal-Padia/Sonata

Happy to answer questions.

Comments URL: https://news.ycombinator.com/item?id=49113561

Points: 1

# Comments: 0

Kimi K3 has 2.78 trillion parameters and ships as 1.42 TB of weights. It clearly does not fit in the memory of a laptop. But K3 is a Mixture-of-Experts model. For each token, only a small fraction of its 896 experts per layer is activated. That changes the problem: the entire model does not need to be resident in RAM, as long as the weights required by each token can be reached quickly enough.

We built WASTE — the Weight-Aware Streaming Tensor Engine — to explore that idea.

WASTE keeps the dense, repeatedly used part of the model resident in memory, stores the routed experts in an NVMe-optimized container, and streams only the experts selected during inference. The remaining RAM is used as a bounded expert cache.

The current Kimi K3 container is 982 GiB. On a 64 GB MacBook Pro, WASTE runs the complete model at around 0.32–0.34 tokens per second, with a measured minimum memory requirement of approximately 29 GB at a 4K context.

That is obviously not interactive performance yet. But the result we found interesting is that it works at all: this is the full open-weights model, not a distillation, a pruned version, or a smaller model using the Kimi name.

The engine is written in C and has no BLAS, CUDA, ONNX, or Python dependency in the inference path. The same code can be used through the CLI, embedded as a library, or exposed through the included OpenAI-compatible server.

Correctness was the first constraint. Every layer was validated against a PyTorch reference, with final logits matching within 3.6e-06. The vision tower is supported as well and matches its reference within 2.3e-06.

The current bottleneck is understood: K3 needs roughly 17 GB of expert data per token, and more than half of the decode time is spent reading experts from disk. The engine is already operating close to the measured throughput limit of the laptop’s internal SSD. The next improvements therefore need to reduce the number of bytes read per token and increase useful expert reuse without pushing the operating system into paging.

K3 is deliberately the extreme case. The same engine runs Kimi-Linear 48B from a 19 GB container at 8.92 tokens per second with an 8 GB memory budget. The broader goal is to make models that are much larger than available RAM usable locally, without sending private data to an API and without requiring specialized accelerator hardware.

We have published the engine, container format, conversion tools, benchmarks, validation suite, and also the experiments that failed rather than quietly removing them.

Everything is fully open source. Feedback on the storage layout, quantization, caching strategy, direct I/O, portability, and potential optimizations would be very welcome. Contributions of any kind — code, benchmarks, testing on different hardware, documentation, bug reports, or new ideas — are more than appreciated.

Repo: https://github.com/sqliteai/waste

Comments URL: https://news.ycombinator.com/item?id=49098966

Points: 7

# Comments: 3

Hi HN,

I built a specialized inference engine for running 4-bit Gemma 4 26B-A4B-IT on any M-series Mac using about 2 GB of RAM. It is called TurboFieldfare and is written in Swift and Metal.

I have always adored on-device AI. It feels like magic that you can run a powerful NN on your Mac or iPhone. So I wanted to push the limits a bit and run a model whose weights don’t fit in memory.

The model’s 4-bit quantized weights occupy roughly 14 GB, which makes running it with conventional inference tools almost impossible on an 8 GB or even 16 GB Mac once the OS, applications, and KV cache are included.

The trick is to keep the shared part of the model and the KV cache in RAM, then stream only the routed experts needed for each token from SSD. An SSD is way slower than RAM, so the runtime uses a small expert cache and bounded parallel `pread`. While those reads are in flight, the GPU runs the shared part of the layer.

I ran more than 100 experiments. Most didn’t work. A few got me here. The experiments are described in the GitHub repo.

It currently generates 5–6 tok/s on an 8 GB M2 MacBook Air and 31–35 tok/s on an M5 MacBook Pro.

I also added an experimental OpenAI-compatible local server. It supports streaming and tool calls, and reuses one prompt prefix from the KV cache.

Try it! The Mac app is easy to install. On the first run, it will download 15 GB of weights from Hugging Face. The model is surprisingly capable.

I would love any kind of feedback!

Comments URL: https://news.ycombinator.com/item?id=49098510

Points: 918

# Comments: 345

Even though I'm a software engineer with long experience with serious projects, I'm become so disillusioned with the whole thing nowadays.

Forget the ridiculous AI hype, forget about the lack of ethics and a moral compass; What's getting to me right now is the unreliability of it all. It seems like everything is held together with duct tape, and the tape is falling off.

Just in the last few months, all these have happened:

- My Macbook Air M1 has been acting up, refusing to charge in a stable manner. The audio jack is dead because apparently it is linked to the charging circuit. The screen sometimes shows a tint on a whim. Now it is dead and not charging at all. Granted, it has otherwise been a fine machine so far, and I've knocked it over a few times, but still. Even my old trusty 2014 Macbook Pro is still going strong, and I've abused that one much more.

- I also can't use my old Macbook Pro well, because the replacement Transcend 256GB SSD I put in it around 2020 is now failing, causing the machine to unpredictably become very slow. Also, the HP business keyboard I bought some years ago is suddenly now emitting spurious key signals, which MacOS (curse its over-reliance on weird key combinations and gestures) is interpreting to do wild things, like repeatedly showing the desktop while I'm working, or zooming in and out repeatedly.

- I thought I could use my old iPad in the meantime, but it can't connect to the WiFi hotspot on my iPhone, only a normal WiFi. I thought WiFi was just WiFi?

- The Dell travel hub I bought a few years ago seems to not work on a whim when I try to use it to make an HDMI connection between my Macbook and my Samsung monitor. About 50% of the time, it simply does not work, no matter what I do. I tried using my Roku ox to cast my screen, but the Roku remote suddenly does not work. I also tried my old Apple TV; its remote was also not working properly. After somehow getting to work to connect to WiFi, the Apple TV also does not work, giving some cryptic error messages.

- A few days ago, my iPhone 12 mini simply refused to charge from my USB-C to lightning cable, no matter what I did, for hours. I borrowed a similar cable from a friend, it also did not work. So my phone died when I needed it. When I got home, I was able to charge with a USB-A to lightning cable.

- Whenever I plug in the external Crucial SSD I bought a few years ago and partitioned, it does not show up in Finder on macOS. I almost always have to go in the Disk Utility to mount the partitions.

- My Sony Bravia TV died suddenly after like 7 years. I took it to some repairers; they said the entire screen is kaput.

All these have happened in the last three months. At this point I'm ready to give up; I plan to be very minimalist with my tech purchases (including Apple stuff), only getting the minimal stuff I need mostly for work, and keeping in mind that most of what I buy is throwaway, likely to stop working in a few years at most, and when you least expect that.

Comments URL: https://news.ycombinator.com/item?id=49056900

Points: 6

# Comments: 12

If not, why not?

That way, people can choose whether they want to install various software betas based on how much SSD wear they are willing to accept.

And since this data would be made public and available in one place, software developers would be more careful about excessive logging in their betas.

Comments URL: https://news.ycombinator.com/item?id=49022990

Points: 31

# Comments: 30

So I've been getting into more systems programming. I would appreciate some feedback on this project. For context, I have a Legion Pro 5 16ARX8 with a 4-zone RGB keyboard. I have been running NixOS as my development OS on another SSD, and the RGBs lose all their settings when I switch over.

I found a project called https://github.com/4JX/L5P-Keyboard-RGB, and it worked. The thing is, I don't like how it opens a window to take effect. I don't want to remember my RGB control software exists at all. It should just work, and I think it should feel native. So this project takes the driver and lighting controls of that upstream project and puts all the logic inside a Rust daemon that can run at startup.

From my testing, it's about 8x lighter than the original because the daemon is now decoupled from the GUI, so it uses way fewer resources and remains invisible. I also wanted it to feel native to Linux. I use GNOME, so I made a minimal GUI with GTK4/libadwaita. More GUI's can be made, however.

So the workflow now is to set up the daemon, open the GUI, adjust what you want, and close it. Simple. No RAM bloat or window that needs to stay open.

This project is new, so please feel free to open issues.

Comments URL: https://news.ycombinator.com/item?id=49011496

Points: 2

# Comments: 0

Hey we are Housecat.

I've spend the last 15 years building dev tools at Heroku, Convox (YC S15), and Segment. Dev tools have gotten insanely good over the decades, now we're working to level up productivity tools for everyday work.

Housecat is an email inbox running on an single-tenant agent computer with a durable workflow engine and connections to common tools for day-to-day work.

My primary workflow with the product is for customer support: get a support email, trigger a triage process, open a GitHub issue, spin up a coding agent to fix it, and update the customer along the way. All from the same UI and sandbox.

We've experimented with lots of different approaches to new workspace tools, and learned that many people still need a great GUI. We've landed on the email inbox as a very familiar and permanent surface and are building tools and automations directly inside it.

Under the hood every user gets their own single-tenant sandbox VM and persistent SSD on exe.dev.

User connections to Google, Slack, GitHub, etc. are managed in an external service so the VM and agent are subject to external governance and don’t have direct access to secrets.

Durable workflows are built on DBOS.dev. Running interactive and deterministic workflows directly inside an email couldn’t feel more different than chatting about emails in Claude.app.

The app is built on HTMX, Unix, Go, and SQLite. The app is source available to users and the Linux VM is fully open for a user and their agent to poke around.

You can try it out at https://home.housecat.com/beta. It requires a Google / Gmail connection for the email app, which you can revoke any time.

We'd love to share more and learn how the community here is managing email, agentic chat, and custom workflows for their work.

Comments URL: https://news.ycombinator.com/item?id=49006149

Points: 15

# Comments: 6

Article URL: https://hackaday.com/2026/07/20/old-ssds-find-new-life-as-game-cartridges/

Comments URL: https://news.ycombinator.com/item?id=48983190

Points: 2

# Comments: 0

I've tried pretty much every disk analysis tool (baobab, daisydisk, du), and found them to choke if

1. you create a lot of worktrees in your workflow

2. you use pnpm, uv, and Postgres 18 clone-based database branching

They all think I used 1T+ of my SSD that is only 500GB, because they don't know about APFS clones or hardlinks, they think my node_modules or venv in each worktree takes up 2GB, even though 30 of the worktrees are actually sharing the same 2GB of dependencies

du, honest supports both a web server mode that will serve up an interactive drill-down tree-view of your directories, as well as a CLI that outputs JSON for your LLMs

Comments URL: https://news.ycombinator.com/item?id=48958921

Points: 1

# Comments: 0

Article URL: https://mrzk.io/posts/qmlx-optimising-multiplexing-and-dogfood/

Comments URL: https://news.ycombinator.com/item?id=48957803

Points: 1

# Comments: 0

Article URL: https://github.com/andreaborio/ds4

Comments URL: https://news.ycombinator.com/item?id=48953349

Points: 24

# Comments: 4

For the past few years I've been building a huge NAS storage with over 1PB in size. As its growing over time, buying new drives is always a tedious process. It's hard to tell whether a drive is CMR or not. Some manufacturers are known for sneaking in SMR into their NAS line of disks. There's always multiple browser tabs open and very often they are in total disagreement.

So, first I built a table, which turned into this website. It fetches daily prices for all NAS disks from Amazon, and covers 8 different regions. It has price history, shows if a disk is a CMR or SMR, and its failure rates (I had to compile tons of raw data from Backblaze public Drive Stats).

It has both NAS hard drives and SSD, and you can see price per terabyte for each drive listed.

It is free and it needs no login. I worked hard to keep the data honest, so only new drives are listed and all scalpers and grey market was removed. The whole dataset is also available for free under CC BY 4.0 license on the Data page (Backblaze part is attributed as needed). It's also published on Github.

Your feedback is very welcome. If you notice anything missing or wrong, please let me know, and I'll fix it asap. Best features on the website were added because users asked for them, so any suggestions are welcome!

Comments URL: https://news.ycombinator.com/item?id=48830983

Points: 4

# Comments: 4

Article URL: https://ssd.jpl.nasa.gov/tools/sbdb_lookup.html#/?sstr=33434

Comments URL: https://news.ycombinator.com/item?id=48794720

Points: 3

# Comments: 0

Article URL: https://github.com/rexbrahh/icloud-guard/tree/main

Comments URL: https://news.ycombinator.com/item?id=48789777

Points: 4

# Comments: 1