The irony is that the SQLite developers get a support contract iff someone runs off the path in anger and finds an ancient bug. But perhaps that's part of what make it a quality team: devotion thriving without adverse incentives.
Tracking down the 16-year-old WAL-reset SQLite bug
51–60 of 263 posts
Re: Tracking down the 16-year-old WAL-reset SQLite bug
#52Similar bug to the one that plagued Codex until 3 months ago.
Do you happen to have a link?
Re: Tracking down the 16-year-old WAL-reset SQLite bug
#53Great writeup, and it was great to see them step in an pay the developers of SQLite to help them fix the bug. I get tired of corporations asking open source authors to fix problems that affect the corporation for free. And while I'm sure it was frustrating for folks to have these outages, I find such puzzles pretty fun to get to the bottom of.
Re: Tracking down the 16-year-old WAL-reset SQLite bug
#54SQLite: 92 million lines of tests Dijkstra: Tests can only prove the presence of bugs, never their absence!
Donald Knuth: Beware of bugs in the above code; I have only proved it correct, not tried it.
Re: Tracking down the 16-year-old WAL-reset SQLite bug
#55> We funded the open-source SQLite VFS shim that helped isolate the race condition almost immediately, and will help track down similar bugs in the future. Interesting example of a company funding open source - in this case paying for the development of a new and very specific debugging tool.
That's actually SQLite revenue model.
Re: Tracking down the 16-year-old WAL-reset SQLite bug
#56Earlier quoted context omitted.
Probably the most refreshing thing I've read in a while. Glad to support them moving forward if this is indeed their modus operandi.
Tailscale is the best. It's infinitely better than Hamachi, ZeroTier, etc. My only gripe is that they have some really weird SSO requirements like GitHub, etc. and then that provider becomes a permanent part of your identity.
Just FYI - with Tailscale you can switch SSO providers by putting in a support ticket. I did it last year and it was a breeze.
Re: Tracking down the 16-year-old WAL-reset SQLite bug
#57> We funded the open-source SQLite VFS shim that helped isolate the race condition almost immediately, and will help track down similar bugs in the future. Interesting example of a company funding open source - in this case paying for the development of a new and very specific debugging tool.
Reading the article, it sounds more like they funded this by buying a SQLite support contract, and the SQLite developers created this in the process of helping them track down the issue.
Re: Tracking down the 16-year-old WAL-reset SQLite bug
#58Such a good write up . Having explored a little bit of sqlite internals for a codecrafters challenge i was mildly happy i could follow along what was happening .
Re: Tracking down the 16-year-old WAL-reset SQLite bug
#59Earlier quoted context omitted.
Probably the most refreshing thing I've read in a while. Glad to support them moving forward if this is indeed their modus operandi.
Tailscale is the best. It's infinitely better than Hamachi, ZeroTier, etc. My only gripe is that they have some really weird SSO requirements like GitHub, etc. and then that provider becomes a permanent part of your identity.
I've been a fan of Tailscale since encountering it for the first time at a previous job at a small startup. Someone asked if anyone had a Linux machine when we were all testing out something, and I mentioned I had a personal Linux desktop but wasn't sure how to connect it to the VPN for access, and it turned out that the solution was just literally running two commands in the terminal after installing tailscale from the repos. Compared to my first job where connecting to the VPN from Linux required hours of mucking around with openswan (or was it strongswan? so many swans...) and trial and error with various config files, it was unfathomably straightforward.
Re: Tracking down the 16-year-old WAL-reset SQLite bug
#60Well written post, really enjoyed reading it. > A single Go process exclusively accesses that database, and serves the control plane for those tailnets. This single-writer design is exactly how SQLite is meant to be used. This line led me to believe that the writer and checkpointing logic lived on the same database connection, so I was curious to find out how the data race occurred. However, the bug details on the SQ…
[flagged]
[deleted]