You're viewing a comment by argv and its responses.
You're viewing a comment by argv and its responses.
I am being sponsored by Syntress! They bought me an amazing dedicated server to run catonmat on. If you're looking web services, I highly recommend the Syntress guys!
I love to read science books. They make my day and I get ideas for awesome blog posts, such as Busy Beaver, On Functors, Recursive Regular Expressions and many others.
Take a look at my
Amazon wish list, if you're curious about what I have planned reading next, and want to surprise me. :)
If you are interested in advertising on catonmat.net, contact me.
Free tools for coding on Vietstarsoft.com.
Programming homework help.


Returning to catonmat to reference that excellent "command line history" article. But I'll leave another silly comment while I'm here... hope you'll look more into DNS and maybe write some more articles on it.
re: async lookups
My command line browser has had a built-in async dns resolver for the last 10 yrs. And it has a switch so it can be used as a stand alone lookup tool, e.g. in a shell script.
If someone besides me did a 'speed test' of this browser against any high level language module (like lwp and all its progeny) - whether for doing dns lookups alone or completing entire http transactions - and they asked me to bet the likely winner... even after 10 yrs of "development", I would still put my money on the C code of my browser over any perl or python module as well as any other later developed scripting language challenger. This is one reason I why I never bother with the high level scripting languages. (Another reason is I'm too lazy to learn them.) Anyway, my vote is for the many async dns libs available in C.
With DNS lookups, shouldn't we also be mindful of what the servers can handle? What is the usual and reasonable QPS load for the server you are querying? I think this is may be more important than how fast we can send out bulk queries and receieve the reponses.
Reply To This Comment