Telegram Group Search
Show HN: Zeekstd – Rust Implementation of the ZSTD Seekable Format (Score: 150+ in 23 hours)

Link: https://readhacker.news/s/6wbth
Comments: https://readhacker.news/c/6wbth

Hello,
I would like to share a Rust implementation of the Zstandard seekable format I've been working on.
Regular zstd compressed files consist of a single frame, meaning you have to start decompression at the beginning. The seekable format splits compressed data into a series of independent frames, each compressed individually, so that decompression of a section in the middle of an archive only requires zstd to decompress at most a frame's worth of extra data, instead of the entire archive.
I started working with the seekable format because I wanted to resume downloads of big zstd compressed files that are decompressed and written to disk on the fly. At first I created and used bindings to the C functions that are available upstream[1], however, I stumbled over the first segfault rather quickly (it's now fixed) and found out that the functions only allow basic things. After looking closer at the upstream implementation, I noticed that is uses functions of the core API that are now deprecated and it doesn't allow access to low-level (de)compression contexts. To me it looks like a PoC/demo implementation that isn't maintained the same way as the zstd core API, probably that's also the reason it's in the contrib directory.
My use-case seemed to require a complete rewrite of the seekable format, so I decided to implement it from scratch in Rust using bindings to the advanced zstd compression API, available from zstd 1.4.0.
The result is a single dependency library crate[2], and a CLI crate[3] for the seekable format that feels similar to the regular zstd tool.
Any feedback is highly appreciated!
[1]: https://github.com/facebook/zstd/tree/dev/contrib/seekable_f...
[2]: https://crates.io/crates/zeekstd
[3]: https://github.com/rorosen/zeekstd/tree/main/cli
Show HN: Chawan TUI web browser (🔥 Score: 153+ in 3 hours)

Link: https://readhacker.news/s/6we96
Comments: https://readhacker.news/c/6we96

A terminal-based web browser in Nim.[1] Has acceptable (YMMV) CSS
rendering, some JS support, and inline images (sixel/kitty). It can
also use various protocols other than http(s) such as (s)ftp, gopher,
gemini, ...
Chawan started out as a w3m clone, and the UI still resembles it.
However, the architecture has turned out quite different, with pages
loaded in separate processes, and protocol/file type handling separated
out into external binaries. An interesting result is that you can even
register decoders for custom inline image formats, although practical
use cases of this are rather minimal.
There is a gallery showcasing some websites being rendered here:
https://chawan.net/gallery/index.html
[1]: https://nim-lang.org
Show HN: Canine – A Heroku alternative built on Kubernetes (Score: 152+ in 7 hours)

Link: https://readhacker.news/s/6wdLr
Comments: https://readhacker.news/c/6wdLr

Hello HN!
I've been working on Canine for about a year now. It started when I was sick of paying the overhead of using stuff like Heroku, Render, Fly, etc to host some web apps that I've built. At one point I was paying over $400 a month for hosting these in the cloud. Last year I moved all my stuff to Hetzner.
For a 4GB machine, the cost of various providers:
Heroku = $260
Fly.io = $65
Render = $85
Hetzner = $4
(This problem gets a lot worse when you need > 4GB)
The only downside of using Hetzner is that there isn’t a super straightforward way to do stuff like:
- DNS management / SSL certificate management
- Team management
- Github integration
But I figured it should be easy to quickly build something like Heroku for my Hetzner instance. Turns out it was a bit harder than expected, but after a year, I’ve made some good progress
The best part of Canine, is that it also makes it trivial to host any helm chart, which is available for basically any open source project, so everything from databases (e.g. Postgres, Redis), to random stuff like torrent tracking servers, VPN’s endpoints, etc.
Open source: https://github.com/czhu12/canine
Cloud hosted version is: https://canine.sh
Occurences of swearing in the Linux kernel source code over time (❄️ Score: 150+ in 2 days)

Link: https://readhacker.news/s/6w8jg
Comments: https://readhacker.news/c/6w8jg
Show HN: I recreated 90s Mode X demoscene effects in JavaScript and Canvas (Score: 152+ in 10 hours)

Link: https://readhacker.news/s/6weU5
Comments: https://readhacker.news/c/6weU5

After 25 years of writing software, I was feeling nostalgic for the kinds of things that got me into programming in the first place: the old DOS demoscene. I spent a weekend seeing if I could recapture some of that INT 13H VGA magic using today's web tech, but with the old-school constraints of doing it from scratch.
The result is this portfolio of ten classic effects running in a single HTML file. It's all vanilla JavaScript writing to a <canvas> element, with no external libraries. It was a fun challenge to implement things like:
* The color palette cycling and smooth fading in the Plasma demo.
* The buffer-averaging algorithm for the Fire effect to make the flames feel more natural.
* The distance-based texture crossfading in the Tunnel to create the illusion of flying through different sections.
* A 2D scalar field for the Metaballs to calculate the surface normals for that classic blended, metallic look (I did the best I could with the given constraints).
It was a great exercise in getting back to first principles and a reminder of how much those early demo programmers could accomplish with so little. I hope it brings back some good memories for others who grew up with this stuff.
I'd love to hear about your favorite classic demos or if there are any other iconic effects you think would be a fun challenge to add.
Cheers!
2025/06/25 23:02:55
Back to Top
HTML Embed Code: