111–118 of 118 posts
We used CGI to add support for extensions in Disco ( https://disco.cloud/ ). It's so simple and it can run anything, and it was also relatively easy to have the CGI script run inside a Docker container provided by the extension. In other words, it's so flexible that it means the extension developers would be able to use any language they want and wouldn't have to learn much about Disco. I would probably not push to u…
Earlier quoted context omitted.
Busybox runs MMU-less and has ash built in. It also has a web server! It can be a little chonky but you can remove unneeded components. Things like wireless routers and other devices that have a decent amount of storage are a good platform for it
Yeah, a lot of wireless routers would have no trouble. A lot of them do in fact have MMUs. I wonder if you could get Busybox running on an ESP32? Probably not most 8051s, though, or AVR8s.
The other option seems to be Apache NuttX as an RTOS (runs on all ESP32), and then Busybox w/hush or Toybox w/toysh. The more shell features you need, the more space it's gonna take, but technically 64 kB flash is possible.
Earlier quoted context omitted.
Yeah, a lot of wireless routers would have no trouble. A lot of them do in fact have MMUs. I wonder if you could get Busybox running on an ESP32? Probably not most 8051s, though, or AVR8s.
Looks like the ESP32-S3 model works with modern Linux (it's so bloated compared to the old 2.0/2.2/2.4 branches...) The other option seems to be Apache NuttX as an RTOS (runs on all ESP32), and then Busybox w/hush or Toybox w/toysh. The more shell features you need, the more space it's gonna take, but technically 64 kB flash is possible.
One reason to use CGI is legacy systems. A large, complex, and important system that I inherited was still using CGI (and it worked, because a rare "10x genuinely more productive" developer built it). Many years later, to reduce peak resource usage, and speed up a few things, I made an almost drop-in replacement library, to permit it to also run with SCGI (and back out easily to CGI if there was a problem in producti…
One reason to use CGI is legacy systems. A large, complex, and important system that I inherited was still using CGI (and it worked, because a rare "10x genuinely more productive" developer built it). Many years later, to reduce peak resource usage, and speed up a few things, I made an almost drop-in replacement library, to permit it to also run with SCGI (and back out easily to CGI if there was a problem in producti…
Earlier quoted context omitted.
This is great, thanks for digging it up! It does support the thesis that Amazon was attempting to prevent customers from realizing that what they were offering was basically CGI on a big load-balanced server farm, by claiming that it was something radically new that you couldn't get before, but their value proposition is still just the value proposition of shared CGI hosting. On a big load-balanced server farm. Which…
> It does support the thesis that Amazon was attempting to prevent customers from realizing that what they were offering was basically CGI on a big load-balanced server farm, by claiming that it was something radically new that you couldn't get before, but their value proposition is still just the value proposition of shared CGI hosting. On a big load-balanced server farm. Which, to be perfectly fair, probably was bi…
Yup. That's right. The removal of the server from your application is the selling point. As you subtly hint at, exposing the application as a "function" is a clever API design to facilitate that, but I'm sure you could imagine other ways to achieve the same. It is the "serverless" part that is significant.
HTTP servers, while simple to implement in terms of basic function, aren't easy to design well. There are a lot of more complex considerations, like around security and scaling, which are easy to screw up if you don't have a good handle on what you are doing. All alleviated by just letting someone else, who specializes in it, write the server code for you. If you take the server out of your application, making it "serverless", it becomes much more difficult (I really want to say impossible, but abstractions always leak eventually) to screw that end up.
Which is a very compelling business case, allowing businesses to hire people who aren't experts (read: cheaper) in the intricacies of low level technical details that are outside of their core business logic. That's the selling feature, just like you (and Amazon) say.
Glad we got away from that bizarre definition thinking that "serverless" somehow takes physical hardware out of the picture. Maybe it has also taken on that meaning (as nonsensical as that idea is) through the twisting in the popularity wind – definitions are most definitely influenced by time — but it certainly didn't originate in that vein.
I’m interested why Rust and C have similarly bad tail latencies but Go doesn’t.
sqlite resolves lock contention between processes with exponential backoff. When the WAL reaches 4MB it stops all writes while it gets compacted into the database. Once the compaction is over all the waiting processes probably have retry intervals in the hundred millisecond range, and as they exit they are immediately replaced with new processes with shorter initial retry intervals. I don't know enough queuing theory…