387 karma · joined January 31, 2021
It seems like people keep comparing gas to “regular” electric stoves, which are definitely inferior in many ways. The biggest issue is they’re very inefficient, and take forever to heat anything.
The stuff that actually is CPU-bound often ends up being written in an appropriate language, or uses C extensions (e.g. ML and data science libraries for Python).
I’ve been on the fence about migrating off Gmail, but after reading threads like this, I put a contingency plan in place. Backups of my Google account are done hourly, and I have a custom domain/workspace account so I can move the domain elsewhere if needed.
Leaf blowers I’m afraid are here to stay, but the electric ones make a less annoying sound at least.
I’m actually having trouble finding a source on the exact rules of the ban, but there are old news articles suggesting that after-market alarms with motion activation were the focus: https://www.qgazette.com/articles/car-alarm-sales-banned-by-...
I ended up getting an iPad Air with the pencil, and one of those matte screen protectors. The OS may be locked down, but I can still choose from a wide variety of note apps/clouds (currently use GoodNotes), and security is obviously top notch.
Having worked with large footprints on both OpenStack and AWS, it’s also clear that there are just inherent difficulties with running your own hardware, especially in your own data center. Even if you make the investment in a good infra team, it’s cost prohibitive to get anywhere near the experience of something like EC2 in terms of hardware availability and hourly billing. Not to mention they’re literally inventing their own hardware for things like high-performance storage and ARM servers.
As someone who’s been hiring for both sides, I see this reflected in candidates more and more. The good devs rarely know ops, and the good ops rarely code well. For our “platform” teams, we end up just hiring good devs and teaching them ops. I think the people that are really good at both often end up working at the actual cloud providers or DevOps startups.
Edit: as the sibling comment mentions, that’s part of what Ractor is trying to solve.
* Run a bunch of background workers (Sidekiq/Resque), and queue up a job for each item you want processed in parallel.
* Provide relatively granular HTTP APIs, and have your JS frontend call them in parallel with AJAX, instead of having the server handle concurrency.
I think this is just the nature of Ruby being widely used for web apps where performance isn’t a big concern. That said, I’d love to see Ractor catch on, since it’s a pattern built into the language everyone could standardize on.
It has its upsides if you put in the work. I’ve given up and opted for mid-range non-stick (coated steel and/or copper, not anodized aluminum) or high end stainless.
I wonder if you turned off the “online” search results and routing if it would shut off data collection, or if you’d have to physically cut off the cell connection.
A lot of medium/large shops build their own deployment and BaaS platforms on top of Kubernetes/Terraform/AWS. You just don’t hear about them as much because they often aren’t provided as a service externally, and aren’t open sourced. (I work with and on such platforms)
The mistake I see people often make is assuming it’s worth using such complex tools directly with a small project. People like the flexibility but don’t understand cost to build/maintain it.