466 karma · joined January 24, 2013
https://www.newyorker.com/culture/culture-desk/the-curse-of-...
You all would probably find the "QuickIA Software Support" section interesting, they go through a few issues you run into when you have incompatible micro architectures running in a single system. It also might help illuminate where Intel's head was at during the early research phase of creating a heterogeneous processor.
Facebook sent a notification later to them that the account was not impersonating anyone, no action would be taken, and there was no way to appeal.
Interestingly, messenger did splat a bunch of pretty good warnings on top of the DM they sent me: https://i.imgur.com/gigUA7G.png
I worked at a company that did this and it was a massive headache, every time I wanted to set up a new VM things would fail until I remembered I had to install their CA. I was an intern at the time, and they gave me some work that required an app that I couldn't configure to use their CA for the life of me. After a lot of failed troubleshooting I and ended up just running a SSH server on my home PC and creating a SOCKS proxy through that.
I think I have a lot more to learn about DNS...
[0] https://github.com/axboe/liburing/issues/26#issuecomment-738...
> [re: implementing getaddrinfo] It's not planned because it's not a single operation but a complex beast reading files, exchanging messages, etc. IMHO, as it's not a single operation it fundamentally doesn't fit liburing, but implementing under some framework on-top would be more viable.
DNS seems like it perfectly fits the model of "give me a buffer (to hold the resolved IP), and I will wake you up when it's filled". Maybe io_uring (/ IOCP?) already can support this, and these articles are just mistaken about the current (or soon-to-be) state-of-the-art? Or is there some fundamental reason about DNS that make writing a non-blocking resolver very very difficult?
It's just very odd to me that userspace apps are creating their own blocking thread pools just to run DNS stuff, when they can do seemingly everything else with just a single thread if they wanted to.
(edited a few times, sorry if I caught someone who was mid-reply)
Except that DNS apparently still blocks[0], so usually things farm DNS requests off to their own blocking thread pools (the author ends up disabling DNS just so they can "prove" everything works with just a single thread)
What's so fundamentally difficult about writing an async/non-blocking DNS resolver? Is it just a lack of a real need for it?
[0] (quote: People have been trying to build asynchronous DNS resolvers for decades without success. Can it be done? Yes. Has it been done? No. ) https://gist.github.com/djspiewak/46b543800958cf61af6efa8e07...