Readit News logoReadit News
agolliver commented on Understanding Rust futures by going way too deep   fasterthanli.me/articles/... · Posted by u/tempodox
agolliver · 4 years ago
Not sure a better place to ask this, but we're getting to the point in most OSs where basically anything you want can finally be done truly async (non-blocking).

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...

agolliver · 4 years ago
I have found this comment on liburing[0] which clarifies some things for me. So is it because something like getaddrinfo is not just a simple operation, but a hodgepodge of stuff like "first try nscd, then read resolv.conf, then make a bunch of requests using one of many different protocols"?

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.

agolliver commented on Understanding Rust futures by going way too deep   fasterthanli.me/articles/... · Posted by u/tempodox
otabdeveloper4 · 4 years ago
On the OS level there is no difference between "sync" and "async". They become different in programming language runtimes.
agolliver · 4 years ago
There is a difference between blocking and non-blocking, which is what I am asking about. Language runtimes apparently cannot provide non-blocking DNS (as evidenced by this article, and the other one I linked which was on HN a week or so ago).

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)

agolliver commented on Understanding Rust futures by going way too deep   fasterthanli.me/articles/... · Posted by u/tempodox
agolliver · 4 years ago
Not sure a better place to ask this, but we're getting to the point in most OSs where basically anything you want can finally be done truly async (non-blocking).

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...

aarongolliver commented on How You Wound Up Playing ‘The Oregon Trail’ in Computer Class (2016)   smithsonianmag.com/innova... · Posted by u/NotSwift
cout · 4 years ago
Do you have any recommendations for a game for children who cannot yet read? My 3yo loves Putt Putt (we play the Steam version) because the car talks to him. But in the early 80s computers did not yet have speech synthesis or enough storage for audio. I would love for him to enjoy Oregon Trail some day, but I don't think he's ready for it. Did MECC make any games targeted at younger children?
aarongolliver · 4 years ago
I don't think Pajama Sam requires reading, I definitely played it before I could read at least, and probably around the same age as when I was playing putt putt.

Deleted Comment

aarongolliver commented on Dead Startup Toys   deadstartuptoys.com/... · Posted by u/notknifescience
olejorgenb · 4 years ago
Hehe, charitable to not call i a outright scam :)

> and the whole package actually solves a problem

The problem of having to carry one less item from the supermarket?

Soda stream is kinda the same, a machine which produce a easily available product directly in you home. But the soda cartridge doesn't expire after a week and can produce alot of fresh soda. So you save alot carrying and it's easy to always have soda since an extra cartridge takes little space. In addition it offer you a choice of how "strong" soda you want.

The only advantage of the juice packs is that they presumable ship it to your door. But it seems very strange if the packs actually are any fresher than presqueezed juice shipped in a regular container (which would've been more convenient). And from the few pictures I saw no water was added to the juice so no volume/weight is saved.

Keurig seems to be coffee capsules which arguable does solve a problem/brings convenience.

aarongolliver · 4 years ago
soda stream is a lot cheaper than buying bottled sparkling water, and you can make a very good analog to your favorite mineral water / soda / energy drink for even cheaper if you buy the right additives online. They did do a good job of making their luxury version waste most of the CO2 tank because it's impossible to make a good airtight seal.

you can homebrew your own though, and use a much larger/cheaper CO2 source than what they sell at grocery stores, which I'll probably be doing soon.

aarongolliver commented on The Windows 11 insider build is surprisingly unpolished and unfinished   arstechnica.com/gadgets/2... · Posted by u/airstrike
SirPrize · 4 years ago
> is surprisingly unpolished and unfinished

> Of course, this isn't a surprise

Wait, so isn't this what we'd expect from an alpha release? Interesting article but the headline seems misleading. Can others compare the severity of these bugs to other insider builds?

aarongolliver · 4 years ago
much worse than regular win 10 insider builds, not much worse than the other previews for unreleased windows versions. Except for a few bugs in the settings menu which I've figured out ways to work around (couldn't switch easily between stereo and 5.1) I pretty much don't notices the differences between 10 and 11
aarongolliver commented on Introducing Windows 11   blogs.windows.com/windows... · Posted by u/WalterSobchak
taviso · 4 years ago
PTT is part of the CPU, no external TPM module is necessary. PTT is Intel's implementation, AMD have something similar called fTPM.

You do not need any external module on machines with fTPM/PTT support (i.e. if you bought it in the last few years).

aarongolliver · 4 years ago
You're right! And now I qualify for the win 11 beta. Looks like I got confused between two different security setting pages in the UEFI menu, and had just enabled "the ability for it to use a TPM plugged in to the header" instead of enabling PPT like I thought I was doing.
aarongolliver commented on Introducing Windows 11   blogs.windows.com/windows... · Posted by u/WalterSobchak
bugfix · 4 years ago
Just enabled PTT in the BIOS, but the tool still says my computer is not compatible (but it doesn't tell me exactly why).
aarongolliver · 4 years ago
You probably only have the header on your motherboard, without a tpm module actually plugged in. Mine was like this, and the specs for your motherboard suggest this is also the case for you. You can buy them on online pretty cheap (I got one for $20)

Deleted Comment

u/aarongolliver

KarmaCake day406January 24, 2013
About
software @ tableau, june 2016 -> present
View Original