Hacker News: psarna

New comment by psarna in "Chatto is now open source"

psarna — Wed, 08 Jul 2026 18:58:24 +0000

single executable with its own frontend is the way; I followed the pattern with https://worb.cloud . Nice for users but also extremely easy to have a short debugging feedback loop

Worb: Local open-source wandb-compatible server

psarna — Thu, 26 Feb 2026 14:43:59 +0000

Article URL: https://worb.cloud

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

Points: 1

# Comments: 0

Fuss: OverlayFS Without Mounting

psarna — Mon, 23 Feb 2026 18:59:39 +0000

Article URL: https://writethat.blog/fuss.html

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

Points: 3

# Comments: 0

Look Ma, No FUSE

psarna — Mon, 23 Feb 2026 16:07:40 +0000

Article URL: https://writethat.blog/lookma.html

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

Points: 2

# Comments: 0

New comment by psarna in "The Unix Pipe Card Game"

psarna — Tue, 20 Jan 2026 18:29:29 +0000

related: https://printed.games/gates/

Ice Ring: Free Printable Board Game

psarna — Sun, 28 Dec 2025 19:44:18 +0000

Article URL: https://printed.games/icering/

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

Points: 2

# Comments: 0

Gates: Printable card game with logic gates

psarna — Thu, 25 Dec 2025 20:28:27 +0000

Article URL: https://printed.games/gates/

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

Points: 3

# Comments: 0

Registry You Can Actually Query

psarna — Fri, 19 Dec 2025 13:24:38 +0000

Article URL: https://writethat.blog/reg.html

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

Points: 2

# Comments: 0

Thinning Layers

psarna — Wed, 26 Nov 2025 13:10:07 +0000

Article URL: https://writethat.blog/layers.html

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

Points: 3

# Comments: 0

Free open-source eBook: Database Performance at Scale

psarna — Wed, 04 Oct 2023 14:57:07 +0000

Article URL: https://www.scylladb.com/2023/10/02/introducing-database-performance-at-scale-a-free-open-source-book/

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

Points: 1

# Comments: 0

Free Book: Database Performance at Scale

psarna — Thu, 14 Sep 2023 12:41:03 +0000

Article URL: https://github.com/Apress/db-performance-at-scale

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

Points: 3

# Comments: 0

Database Performance at Scale

psarna — Fri, 08 Sep 2023 15:50:55 +0000

Article URL: https://link.springer.com/book/10.1007/978-1-4842-9711-7

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

Points: 2

# Comments: 0

Open-source disposable email service

psarna — Fri, 12 May 2023 19:13:06 +0000

Article URL: https://sorry.idont.date/

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

Points: 190

# Comments: 66

New comment by psarna in "SQLite-based databases on the Postgres protocol"

psarna — Wed, 25 Jan 2023 16:11:50 +0000

First of all, let me start by reiterating the first sentence from the bottomless repo - it's work in heavy progress (and we'll move it under the sqld/ repo soon, to keep everything in one place). Now, answers:

> - Looks like bottomless does automatic restoring of the database? Litestream seems to avoid this, I assume because of concerns about accidentally creating multiple writers on a rolling-deploy (or similar mistake). Any concerns about this possible footgun?

It's a valid concern, but what always happens on boot is starting a new generation (a generation is basically a snapshot of the main file + its continuously replicated WAL), distinguished by a uuid v7, the timestamped one. So even if a collision happens, it would be recoverable - e.g. one of the stray generations should be deleted.

> - Bottomless is a sqlite extension, not a separate process? Pros and cons compared to litestream?

The only con I see is that a bug in the extension could interfere with the database. As for pros: way less maintenance work, because everything is already embedded, we're also hooked into the database via a virtual WAL interface (libSQL-only), so we have full control over when to replicate, without having to observe the .wal file and reason about it from a separate process.

> - Similar questions for sqld. How does sqld handle the lifecycle of deploys and multiple readers/writers talking to the database? Anything a new user should be concerned about?

There are going to be multiple flavors of sqld, but the rough idea would be to trust the users to only launch a single primary. In the current state of the code, replicas contact the primary in order to register themselves, so the model is centralized. Once we build something on top of a consensus algorithm, leader election will be pushed to the algorithm itself.

Compare Rust crate stats from crates.io

psarna — Thu, 27 Jan 2022 16:30:06 +0000

Article URL: https://compare-crates.sarna.dev/?crate1=tokio&crate2=futures

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

Points: 1

# Comments: 0

Crate comparator: compare stats from crates.io

psarna — Thu, 27 Jan 2022 11:01:42 +0000

Article URL: https://compare-crates.sarna.dev/?crate1=futures&crate2=tokio

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

Points: 1

# Comments: 0

New comment by psarna in "Async Rust in Practice: Performance, Pitfalls, Profiling"

psarna — Thu, 20 Jan 2022 02:55:53 +0000

In case somebody stumbles upon this old thread, here's the recording of the meetup: https://youtu.be/pgzjPeIQ3Us

New comment by psarna in "Async Rust in Practice: Performance, Pitfalls, Profiling"

psarna — Sat, 15 Jan 2022 16:33:29 +0000

maybe_yield may or may not be the right solution here, but I think it may be useful in general - e.g. when you have long I/O-less computations. In such a case, I'd like to be able to say "yield here if my budget is drained, but continue otherwise and don't put my task at the end of the queue". Although for that the only thing I really need is a way to peek at your budget - with that, open-coding maybe_yield is trivial

New comment by psarna in "Async Rust in Practice: Performance, Pitfalls, Profiling"

psarna — Thu, 13 Jan 2022 16:59:32 +0000

Now that I think of it, it would probably be beneficial even outside of the unconstrained scope, especially for long computations. When iterating over millions of elements, it would be great to have a mechanism for maybe yielding if we're past the budget, but we don't really want to force-yield on every X iterations and put the task at the back of the queue. If the maybe_yield API is potentially controversial, a sufficient building block would be a function that allows peeking into the state of your budget - and then, if you're out of it, you just explicitly call yield_now().

New comment by psarna in "Async Rust in Practice: Performance, Pitfalls, Profiling"

psarna — Thu, 13 Jan 2022 05:28:05 +0000

wrt. preemption - in Seastar we have maybe_yield(), which gives up the cpu, but only if the task quota (more or less a semantic equivalent for Tokio's budget) has passed. Wouldn't it make sense to have a similar capability in Tokio? Then, if somebody is not a big fan of the default preemption, they could run their tasks under tokio::task::unconstrained and only check the budget in very specific, explicitly chosen places - where they call maybe_yield(). That could of course also be open-coded by trying to implement maybe_yield on top of yield_now and some time measurements, but since the whole budgeting code is already there... Do you think it's feasible?