jbotdev

You would definitely have trouble on an 8-bit micro, but I wouldn’t expect to browse a “personal website” with one of those, which is what the article seems to focus on. Maybe a “personal HTTP API” at best.

Not sure I understand the concern about access from “modern embedded devices”. Something like a Raspberry Pi, or really anything with a decent ARM processor, can easily handle TLS.

Why is this such a problem in San Francisco, but not so much in other major cities like New York? It’s not like homelessness is exclusive to SF.

In the US it’s White for Neutral, Green for Ground, Black for Hot, Red also Hot (usually for the other hot/phase on 240v or three way lighting).

One consequence of this I haven’t seen mentioned yet: price matching at competing retailers may no longer work.

I often end up purchasing items at local stores, which tend to have higher prices, but happily price match to items “Shipped and Sold by Amazon”. I can see how it can be hard to abide by pricing from any random third-party seller, but evidently even the “Sold by Amazon” items were third-party anyway.

It seems like the main value-add of this project is building/packaging pretty much standard Ruby in a consistent way across many Linux distributions, which is something that’s been hard to come by. I would lean into that more than anything else.

Maybe I’m missing something, but it seems the only changes here over upstream are jamlloc and/or malloc_trim. I’m not as familiar with malloc_trim, but jemalloc is fairly trivial to setup without recompiling Ruby (using LD_PRELOAD), and there are even buildpacks for environments like Heroku. It seems like more time was spent on the marketing page than on the actual optimizations.