Nah at a small scale it's totally fine, and IME pretty pain-free after you've got it running. The biggest pain points are A) It's slow, B) between auth, storage, and CI runners, you have a lot of unavoidable configuration to do, and C) it has a lot of different features so the docs are MASSIVE.
14 incidents in February! It's February 9th! Glad to see the latest great savior phase of the AI industrial complex [1] is going just as well as all the others!
An interesting thing I notice now is that people do not like companies that only post about outages if half the world have them ... and also not companies that also post about "minor issues", e.g.:
> During this time, workflows experienced an average delay of 49 seconds, and 4.7% of workflow runs failed to start within 5 minutes.
That's for sure not perfect, but there was also a 95% chance that if you have re-run the job, it will run and not fail to start. Another one is about notificatiosn being late. I'm sure all others do have similar issues people notice, but nobody writes about them. So a simple "to many incidents" does bot make the stats bad - only an unstable service the service.
Right? At least on HN, there's a critical mass of people loudly ignoring this these days, but no one has explained to me how replacing formal language with an english-language-specialized chatbot - or even multiple independent chatbots (aka "an agent") - is good tradeoff to make.
It's "good" from the standpoint of business achieving their objectives more quickly. That may not be what we think of as objectively good in some higher sense, but it's what matters most in terms of what actually happens in the world.
I'm confused, wouldn't this be just using the power of the government to enforce short-sighted, tech-hostile regulations like "datacenters should not poison people"?
Yup. When building "upcycled" PCs out of used second-to-last-gen components, I learned very quickly to only ever use brand-new, high quality PSUs ... the alternative is insanity
My anecdotal experience over the last 15 years of personal PCs.
I've had one case of Corsair memory which went faulty after a year (was replaced without question by the supplier) and around 3 PSU failures.
However, on the 3 times I've done upgrades (typically motherboard + RAM + CPU) in that time I've been able to keep my existing PSU without stability issues.
So I wouldn't say it's "insanity" to keep your current PSU when upgrading, but based on your experience if I had stability issues it may be the first thing I test.
Yea, I've ran bunch of office PC's with nearly 20 year old components 24/7 without any stability issues (acting space heaters doing CPU intensive tasks in winter).
No need to replace a quality PSU until you start having issues.
Nowadays there's a lot of FUTON bias in research. There's so much power in just hitting the streets or reaching out to your circle.
For the most part, you care the most about your circle, so if that isn't representative of the whole of society, it sounds like somebody else's problem. Who said all research needed to be perfect.
So, am I right in assuming that ESP32, being simple and slow, isn't going to have cache lines or anything, and would just need 1-2 cycles to access its RAM? In which case a pointer-chasing dynamic language like python wouldn't have all of the typical performance penalties from constant cache misses?
EDIT: upon further research, I think the above assumptions are more or less all wrong, starting with the "simple" part. To start with, they're Harvard-architecture-ish with separate memory pathways - and caches - for data and instructions, so off the bat they have more heterogeneity than your modern general purpose CPUs. Also there seems to be a very wide variety of memory mappings, buses, and caching systems within ESP32 "family". [1]
reply