russellthehippo

6 ms·

1.
by russellthehippo 1mo ago
Pretty cool apps! One thing i'd love to see for both is a historical view of the data - how do things change over time? Where is today relative the past five years for a given place? ten years? etc.
2.
by russellthehippo 2mo ago
Precisely this. Incredibly annoying headline
3.
by russellthehippo 2mo ago
Failures to allow faster generation/hookup rollout have suppressed supply increase relative to demand increase
4.
by russellthehippo 2mo ago
"VMs but it's on Hetzner so it's equally fast and 10x cheaper!" Hell yeah I also wanted to build this, good luck mate
5.
by russellthehippo 3mo ago
The key parts of this is how not vibecoded it is. Feels like a model of how you should do software with AI. Now that we can easily set up property testing, fuzzing, etc. there's almost no reason not to.
6.
by russellthehippo 3mo ago
"Welcome to the agentic substrate" YAAS (yet another agentic substrate)
7.
by russellthehippo 3mo ago
There were real geographic and social tradeoffs to having status and power.
8.
by russellthehippo 4mo ago
Hi HN, I made this. My brother wanted to use per-tenant SQLite at his startup, but really likes Electric’s Shape model for Postgres. So I got curious to see if the same idea was feasible for SQLite. Electrolite is “Electric-style Shapes, bu
9.
Show HN: Electrolite – embeddable ElectricSQL-style sync for SQLite(github.com)
1 points by russellthehippo 4mo ago|1 comments
10.
by russellthehippo 5mo ago
I'm finding in practice in using this process that you're right - it just doesn't work, even for one dev (usually). ha. But, the process of forcing plans to verify intent has worked pretty well! specifically the process of re
11.
by russellthehippo 5mo ago
Appreciated your input on the original thread as well. Maybe I should note this recommendation in the docs or something.
12.
by russellthehippo 5mo ago
Author here. Yeah doesn’t depend on the underlying db if it speaks SQLite.
13.
by russellthehippo 5mo ago
Yup
14.
by russellthehippo 5mo ago
Respectfully (thanks haha) - yeah probably right. Original intent was to use inotify type thing but i avoided per-platform differences at the outset. this was definitely a for fun project that blew up unintentionally and am working to harde
15.
by russellthehippo 5mo ago
Author here - previously posted here: https://news.ycombinator.com/item?id=47874647 Key difference vs SQL polling is that we’re touching metadata instead of data pages. I have work in process to make this work without any p
16.
by russellthehippo 5mo ago
Reading the capacity crunch idea made me a little more empathetic to their issues - 30x in one year is a lot when you're starting from a high baseline. Now that being said...I'd really appreciate more availability.
17.
by russellthehippo 5mo ago
Reporting back again. It seems I was actually right the first time - the C API's SQLITE_FCNTL_DATA_VERSION doesn't work cross connection. It is cached on each read - but if there aren't any reads (i.e. just polling SQLITE_FCN
18.
by russellthehippo 5mo ago
I've added examples for many ORMs and web frameworks to the docs. See here: https://honker.dev/guides/orm/#sqlalchemy--sqlmodel
19.
by russellthehippo 5mo ago
Reporting back. This appears to be a bug in my original test the code of which sadly I did not commit anywhere. I went back to regenerate these tests and proved the opposite - the C API is better than PRAGMA and works across connections. I
20.
by russellthehippo 5mo ago
Ha. Great callout. Will inspect further
21.
by russellthehippo 5mo ago
Will do
22.
Intent-Driven Development(russellromney.com)
1 points by russellthehippo 5mo ago|0 comments
23.
by russellthehippo 5mo ago
link for all others - this commenter fixed a bug in core Postgres that fixed a scaling issue in actual listen/notify https://www.recall.ai/blog/postgres-listen-notify-does-not-s...
24.
by russellthehippo 5mo ago
writes and claim/ack flow. really depends on your journal mode and synchrnous mode as well. notifs are extremely cheap, either in the old stat(2) mode or the new PRAGMA page_version (see my update on feeback comment). Some other commen
25.
by russellthehippo 5mo ago
[Response to feedback] Thanks all for your feedback, responses, and discussion. I've done a PR here taking your suggestions into account: https://github.com/russellromney/honker/pulls/1 The PR implements
26.
by russellthehippo 5mo ago
Wow, yeah. You call it “optimizing for understanding.” I’ve been thinking about a very similar problem as “optimizing for execution of intent.” My version is roughly: if execution and verification are getting cheap, but taste, design, inten
27.
by russellthehippo 5mo ago
I just tested this out. PRAGMA data_version uses a shared counter that any connection can use while the C API appears to use a per-connection counter that does not see other connections' commits.
28.
by russellthehippo 5mo ago
If this has been fixed somewhere or there is a better alternative I'd love to use that over polling. Current plan is to move to polling data version for speed + occasional stat for safety. Getting rid of polling was my original goal bu
29.
by russellthehippo 5mo ago
Wow, thanks for the great feedback. I actually looked at fstat, but the "check for deletions" piece, given I'm polling at 1kHZ, was the reason I decided not to use it. Older hardware actually made this a big issue but it&#x27
30.
by russellthehippo 5mo ago
Damn it was real the whole time. I found Opus 4.7 to holistically underperform 4.6, and especially in how much wordiness there is. It's harder to work with so I just switched back to 4.6 + Kimi K2.6. Now GPT 5.5 is here and it's b

More ›