Litestream author here. Yes, that's correct. LTX was the biggest hurdle to get over and was impossible to switch over incrementally. The storage layer change brings a lot of benefits and enables a lot of future work that we're really excited about.
Thanks to mtlynch and everyone else who has submitted bug reports. We're squashing issues and working to get everything stable as quickly as possible.
Yes but that’s the case for any DNS (which is why your ISP loves it when you use their DNS, for “marketing” data they sell to others). However, similar to pihole and adguard, you can turn off logging if you want.
>Say what you will about Uber, but no Uber driver has ever tried to lie and harass a passenger over whether or not the credit card machine is broken in an effort to cheat on their taxes.
This actually did happen to me. When I was in Hyderabad, I took an Uber from my company's office to the airport, and the driver said his phone died right after picking me up, so I had to pay cash.
I've had that happen a few times in Chicago. Worked out well for me, since I had the driver agree that I'd pay half the fare that was the upfront price. Then I reported the drivers for the scammers they are to Uber, and I got a refund of the price I never paid in the first place, plus credit. Love me some VC welfare.
Manning doesn't pay that much to first time authors, and it looks like it's the first book for the author, Garrison Hinson-Hasty.
My guess is it's about $2k upfront and the author owes it back if they don't deliver.
Teiva Harsanyi did a good writeup recently about working with Manning as a first-time author. He got $2k upfront and $2k after delivering the first 1/3rd.[0]
When I wrote Elm in Action for Manning, I talked with them explicitly about the language being pre-1.0 and what would happen if there were breaking changes. The short answer was that it was something they dealt with all the time; if there were small changes, we could issue errata online, and if there were sufficiently large changes, we could do a second edition.
I did get an advance but I don't remember a clause about having to return any of it if I didn't earn it out. (I did earn it out, but I don't remember any expectation that I'd have to give them money back if I hadn't.) Also my memory was that it was more than $2k but it was about 10 years ago so I might be misremembering!
>The DX for deploying SQLite apps to Fly.io is rough. I'm a few hours into trying to get a production Rails app booting, but running into issues getting the database to initialize, migrate, and become writable. The root of my problem was the eager loading of a gem I wrote, but there were several layers of runners above it that made it hard to diagnose.
What's the Fly.io issue here? Aren't the issues you're describing in Rails not Fly.io?
I run several Go apps in production on Fly.io[0, 1, 2] and I've never had an issue with the Fly.io + SQLite part of it.
SQLite + Litestream makes things slightly more complicated, but again, I've never had issues with Fly.io specifically making that harder. I use a custom launch script in my Dockerfile that starts litestream with the -exec flag to start my app as a child process.[3]
Yeah, I agree that's cleaner, but once you're dealing with multiple containers, it's a big step up in complexity, and you can't do the simple install on places like Fly.io and Lightsail.
>As a side note, you might consider revisiting your dockerfiles and skip litestream build steps, eg. in your final stage just add line like this:
I've heard a lot of people cite this case as proof that scraping is legal, but it seems like the decision kept going back and forth in appeals, and I never understood what precedent it set, if any, around the legality of scraping.
This one seems different from the (correct) ruling in favor in hiQ Labs, where the courts were quite clear that scraping the public Internet was completely legal.
This is a case of a company creating millions of fake user accounts, so they’re behind the login wall and not on the public side of the Internet anymore. At least, that’s how I’m reading this.
Very excited to see Fly restart development on Litestream after a 2ish year freeze!
I love Litestream and use it in every app I build now.
They advertise it as costing "pennies per day," but it's even less expensive than that. It obviously varies depending on how much storage you need, but I had a real app in production, and Litestream replication to S3 only cost me 2-3 cents ($0.02-$0.03) per month.[0]
>The only way to verify correctness is to change the production code in a way that should cause the test to fail, then watch it fail. In TDD this is done by writing the test before you write the code that would make it pass, then watch it fail. Only then are you allowed to write the code that makes it pass.
>Otherwise you have no proof the test can EVER fail - which means no proof it adds value to your codebase.
I agree that changing the production code to cause a failure can be helpful, but I think it's an overstatement to call it "the only way to verify correctness." When I optimize for simplicity, I rarely encounter tests that pass in situations I didn't expect.
Also, forcing tests to fail doesn't really scale. You can do it initially as you write a new function, but once you commit your changes, whatever you've learned from the exercise evaporates. If you change the function or any of its dependencies, presumably you're not going to repeat the exercise of forcing each assert to fail one-by-one. According to what you're saying, that means that there's no longer proof that the test can fail.
In your writeup, it seems like you're arguing that LLMs can't eliminate essential complexity, and I agree that they probably can't.
But I do think they can reduce essential complexity.
As a concrete example, here's me prompting Claude 4.1 Opus to define a domain-specific language for creating computer-generated paintings.[0] I just provided the requirements and left a lot of ambiguity in the specifics.
In that example, has LLM reduced essential complexity at all?
To me, the answer is clearly yes. It wrote a spec based on my requirements. I could potentially do better if I defined it from scratch, but if the LLM-generated spec is good enough, then it likely isn't worth the cost of me doing it myself for the marginal improvement in quality.
When LLMs first came out, I felt like I had no need for them because I think I can write code better than they can, and I enjoy writing code. But as I've started experimenting with them, I'm realizing that there are some problems that I can solve with software that I don't actually enjoy implementing and I don't care that much about specifying every aspect of my program's behavior, so LLMs fit well in those situations and eliminate essential complexity that would otherwise fall in my lap.
[0] https://fly.io/blog/litestream-v050-is-here/#the-ltx-file-fo...