Flintstack › Mailing Lists
Mailing list archive
Two lists, both plain text, both the whole project. There is no forum and no chat; if a decision was made, it was made here.
The lists
- flint-dev - patches, bug threads, design argument. Subscribe by mailing dev@flintstack.dev with the word
subscribein the subject. - flint-announce - release notices only, a message every few months. Same address, subject
subscribe announce.
Recent threads
| Subject | Started by | Date | Replies |
|---|---|---|---|
| objs backend stalls on a mid-stream 503 | nmaas | 2026-10-03 | 6 |
| doctor: UTC vs local time for the clock offset | rwpark | 2026-10-01 | 4 |
| v0.11.3 released | kjell | 2026-09-28 | 2 |
| whole-label prune: are prefix matches ever wanted? | mtorres | 2026-09-17 | 9 |
| peer tier holds a dead socket for the full timeout | adensity | 2026-09-11 | 5 |
| RFC: a read-through cap for the objs tier | kjell | 2026-08-25 | 14 |
| stats labels vanish after seven days - bug or spec? | nmaas | 2026-08-18 | 7 |
| please add a Windows port (again) | drive-by | 2026-08-06 | 23 |
| freebsd target: who maintains it now? | portsmaint | 2026-07-30 | 3 |
| include_mtime bit me, can we warn louder | mtorres | 2026-07-12 | 8 |
| v0.11.0 released: peer backend | kjell | 2026-06-02 | 2 |
| constant-time token compare - worth it on a LAN? | adensity | 2026-05-20 | 11 |
Two messages worth keeping
From the read-through-cap thread, on why the obvious fix is the wrong one:
> On 2026-08-25, kjell wrote: > The objs tier re-fetches an object every time it misses locally. On a > fleet of ephemeral runners that is a lot of duplicate restores. Proposal: > a small read-through cap so the Nth runner in a wave reuses the (N-1)th. I like it, but the cap has to be bounded by wall time, not count. A wave of 200 runners that each wait on one slow restore is worse than 200 parallel restores. If the cap is "at most K in flight, drop the wait after T", fine. Otherwise we have reinvented a thundering-herd lock, and we spent two releases removing the last one of those from the store. -- adensity
And the perennial Windows thread, answered once more:
> On 2026-08-06, drive-by wrote: > Any chance of a Windows build? We run CI on Windows and would use this. Short answer, no, and it is not stubbornness. The store unlinks files that are still open, renames across the same filesystem atomically, and takes advisory locks that actually lock. The first of those has no Windows equivalent, so a port is a second storage layer, not a flag. A fork is welcome; patches that do not complicate the POSIX path are welcome too. The tracker item is #129 and it is marked won't-fix for that reason, not because nobody asked. -- kjell
Full archives are kept as mbox files in the tree under docs/lists/ and rebuilt into these pages on each release. Nothing here is served from a third party.
Last updated: 2026-10-03