It sounds like the author makes a blanket claim to avoid asynchronous functions, even when using an inherently asynchronous web framework (FastAPI), which would negate any FastAPI asynchronous concurrency gains.
Readit Newsjb_gericke commented on How to Run Python in Production ashishb.net/programming/p... · Posted by u/ashishb
jb_gericke commented on WASM will replace containers creston.blog/wasm-will-re... · Posted by u/hpincket
WASM solves a very different problem to Kubernetes, and you can happily run, scale and orchestrate WASM binaries on Kube.
jb_gericke commented on Dear friend, you have built a Kubernetes macchaffee.com/blog/2024/... · Posted by u/todsacerdoti
I don’t think scale is the only consideration for using Kubernetes. The ops overhead in managing traditional infrastructure, especially if you’re a large enterprise, drops massively if you really buy into cloud native. Kubernetes converges application orchestration, job scheduling, scaling, monitoring/observability, networking, load balancing, certificate management, storage management, compute provisioning - and more. In a typical enterprise, doing all this requires multiple teams. Changes are request driven and take forever. Operating systems need to be patched. This all happens after hours and costs time and money. When properly implemented and backed by the right level of stakeholder, I’ve seen orgs move to business day maintenance, while gaining the confidence to release during peak times. It’s not just about scale, it’s about converging traditional infra practices into a single, declarative and eventually consistent platform that handles it all for you.
Kubernetes is bad for running anything at all, including databases.
(K8s is second-system effect and job security for sysadmins. From a technical point of view it causes more problems than it solves.)
Can you qualify this statement? It’s 2024, Kubernetes is old tech and bullet proof at that.
Having watched the infrastructure side of things evolve from the late 90s/early 2000s, where every HP/IBM rackmount was a snowflake, configuration and releases were hand rolled and debugging server / OS / package dependency issues (not to mention scaling and managing load balancers) were exclusively manual to where we are today with Kubernetes, I would select Kube all day everyday. A consistent and now very stable substrate and API I can expect pretty much everywhere, which handles rollouts, resources, health checking/auto healing and scaling for me, and pretty much lets me sleep while infra is failing? Good luck debugging that hand rolled bash script to pull a container after whoever wrote it has left (and good luck scaling it).
jb_gericke commented on Apple cider vinegar for weight management nutrition.bmj.com/content... · Posted by u/jfoster
my reading is no change in mass but less fat, meaning gained muscle instead of muscle loss...
Which doesn’t really make sense, as drinking ACV alone will definitely not result in a body recomp/the addition of muscle (every meat head lifter, myself included, would be drinking a few bottles a day in that case).
jb_gericke commented on How Meta patches Linux at hyperscale thenewstack.io/how-meta-p... · Posted by u/elorant
"Draining and un-draining hosts is hard."
I'd stop right there and fix that, because that's a bullshit reason. Cycling hosts in and out of service is easy unless you're not doing things properly.
The Linux kernel is simply not designed to be live patched and it's a total hack to try to do it, it will never work 100% of the time, always be a source of uncertainty, and always be expensive in terms of engineering work. Disaster will always be looming.
By contrast, fixing their system for taking hosts in and out of service, so that it's extremely robust and reliable would likely pay big dividends in reliability.
My guess would be that this approach is papering over organizational dysfunction. One team can patch all the kernels but one team can't make all the hosts support proper cycling in and out of service. And no one cares to fix it because there's no real incentive to do so. Only cool hacks and new projects are properly rewarded.
Yeah, especially with containerisation and orchestration / Kubernetes, I get that perhaps not everything is viable to containerise, but in 2023 this feels archaic and like a lot of (potentially unnecessary) engineering work.
jb_gericke commented on I think GCP is better than AWS (2020) nandovillalba.medium.com/... · Posted by u/hui-zheng
I think this is an unfortunate conflation of free Gmail/etc. consumer products with GCP.
All of what you say is pretty accurate for free-tier Gmail/etc. No customer service, risk of an account getting blocked and nothing you can do, new apps not finding success and getting cancelled.
But none of it is the case with GCP. Customer service is great and you can reach real people easily, paid accounts aren't getting shut down without recourse unless you really are being abusive, and Google's not cancelling the services companies are paying for. (The same goes for the paid tier of Google Workspace.) It's a normal paid B2B relationship with all that usually entails.
It's unfortunate that people take their experiences and the stories they hear about the free consumer side, and extrapolate them to assume they're also true about the paid business side. It's understandable, but it's just not the case.
And neither GCP nor AWS is getting shut down. Even using the numbers you give, the answer is that the risk of either shutting down is zero for all intents and purposes. There's no reason to split hairs over which of two infinitesimally unlikely events is more likely, or use that as a justification for choosing one or the other.
We had our main GCP account suspended because we were running a Lightning node, and some Google automata flagged us as mining.
We couldn’t get hold of any actual person at Google, and were told by our Google reseller to buy a fairly expensive support package to have our issue expedited after raising multiple appeals/objections. Suffice it to say, we run out of AWS now. I’ve heard GCP support (in terms of reaching an actual human support person/engineer has only gotten worse since then, and our experience occurred a good few years back).
jb_gericke commented on Jupe: Off-grid shelters that pop up anywhere on Earth jupe.com/get-jupe... · Posted by u/pr337h4m
Watch the Jupe + YC CEOs video on the site and tell me it’s not a parody. Dude dressed like a guru talking about a glamping tent like it’s as ground breaking as a Tesla and will solve world housing. Wild.
I can see these popping up all over the show at Burning Man. Maybe the guru dude just knows his audience?
A lot of the world runs just find on Python (see Django), async is mature and stable.