Just keep going until you get to VOOM, that will fix it.
2,816 karma · joined April 7, 2016
Looks like they didn’t meet the minimum crew requirement on this one.
Hostile operating systems. Take the effort to switch to Linux.
Undocumented hardware, well there is far more open source hardware out there today and back in the day it was fun to reverse engineer hardware, now we just expect it to be open because we couldn’t be bothered to put in the effort anymore.
Effort gives me agency. I really like learning new things and so agentic LLMs don’t make me feel hopeless.
Ahem, ASML, who makes the manufacturing equipment for TSMC is a Dutch company, not a US one.
This is so good.
In less than 7.5 million years please. https://simple.wikipedia.org/wiki/42_(answer)
They did test with UV light. The sun is broadband (it will have both blue light and uv light) so it works to a degree. The insight is that uv generates some new yellow coloured compounds and only using blue light prevents this.
1. Allowing user initiated early retry exit. Nothing is stopping some other developer from wrapping your function-with-retries in their own retry-able function. And then another developer even further removed from the details to wrap that one again. Now you have n pow 3 retries and you have services timing out after an hour instead of milliseconds or seconds. Remember that your function-with-retries can just look like a slower flakey function to them. Perhaps exposing the retry variables in the api is the answer, perhaps not.
2. Code readability and debug-ability. Wrapping a piece of work in a function pointer and giving it a generic name like “action” increases cognitive load and makes the codebase slower to read. This is especially true if the contents of the action is so far up the boilerplate chain that the developer has already forgotten what it does. This is a part of the codebase that will be read to troubleshoot the failure so it helps if it is self describing.
3. In my experience, retries are often added when the failure mode is not well understood or as a quick hack to get things over the line. However, we sometimes cannot control what we call so they are an also valid mechanism to use under certain circumstances.
On the pcb front, I dread going through those final steps in the pcb ordering process. No matter how many parts I preorder, there is always something that is unavailable. So much churn in component availability.
My point is that the basket that eggs are put in is not always clear in hindsight. I wasn’t even aware that Mastercard and visa shared fraud alerts and that they were automatically linked.
The author’s article is not about backups, it’s about accountability.
https://doc.rust-lang.org/edition-guide/editions/index.html
Rust has a 6 week release cycle and a big complaint is that the language isn’t changing quickly enough so there is pushback from both ends to take into account here. My take is that there are only hard problems still to be solved given that that they need to be solved in a zero cost way.
The audio codec on ble is more modern too.
> “You can't even hear a ok quality music further than 20 metres away” That smells like the SBC codec running on Bluetooth classic to me. Very different tech.
Sounds like a simple ozone generator to me. Since the pandemic these devices are very cheap too.
Well it’s actually 16.66 ms (1000 / 60). You can’t round up. A render loop that takes just a fraction more than the absolute minimum above would neck down to 30fps.
I don’t understand why mosquitos can develop resistance to chemicals but not a fungal infection, regardless of the delivery method. Can Raymond shed some light on this?
I stand to be corrected but I believe that this is design choice of the Tokio async runtime and not a Rust design choice. For example, the Embassy async runtime does not have this bound but then you have to handle pinning yourself. Also, the static bound is supposed to lower the complexity cost, not raise it.