There was a separate goto utility in early UNIX. Pretty sure you can still find the source code if you look. Meanwhile, it's mentioned here: http://www.in-ulm.de/~mascheck/bourne/
One of his two nameservers, ns2.missoulaweb.com (66.235.178.171), is non-responsive. The other one works but it's listed second. No round-robin. That can slow down the DNS lookup, as the first listed nameserver will likely be tried first, adding to the "slowness" of a website.
Dead nameservers are relatively rare among sites that get posted to HN, since many are high traffic and use CDNs (that rely on DNS kludges). But it is still a regular occurrence. No one ever talks about it. But it's one of the DNS kludges that's continually slowing things down behind the scenes.
There is that term "link rot" for URL's that do not work anymore. And "bit rot" for source code. I propose a new one: "NS rot".
What language are they using for cleaning up the data for import?
Is there a market for a middleman (i.e., something as a service) that cleans up enterprise data, using customized solutions if necessary, for import into different databases?
If this type of company already exists who are some examples?
This is very unsexy work which I happen to enjoy. Its the phase that routinely comprises 80% or more of any so-called "Big Data" project.
This is a more accurate description IMO. However DNS does not have to be that way. Before DNS there used to be file sharing of all the data via a single file in the simple "HOSTS file" format. Then there was a feature in DNS for sharing all the data of each nameserver, in a "zone file" format. With network bandwidth as it is today, sharing of data in bulk could be quite useful to make DNS more peer-to-peer like. People still share data, e.g., block lists. But, practically speaking, everyone running a nameserver connected to the public internet disables axfr.
Also, in my view peer-to-peer supernodes do not monitor or forward all data, they only maintain address information of the peers (rendezvous as you say). DNS, as it is implemented on the public internet, is ripe with passive monitoring as all data flows through centralised points in the tree. Leaves, at the network's edge, are expected to be "dumb", needing to make hundreds single requests for the same information, 365 days per year, even when the majority of it is relatively static.
Every query and response packet containing a seemingly useless "Query" field that never varies from "1". There's no pipelining (when using TCP) or packets containing more than one query.
From what I understand there was interest in so-called "P2P DNS" in reaction to various incidents of censorship via the centralised points in the tree. If the leaves were truly connected as "peers", and sharing the database data directly "peer to peer", then we might have better protections against censorship.
Incidentally, "DNSSEC", as advertised, appears to anticipate centralisation and usage as a CA-like system where peers at the network edge are not only dumb but incapable or verifying messages themselves without involvement of third parties.
In contrast, encrypting DNS packets requires no third party assistance. It can be done by peers all by themselves. A client can encrypt queries and a nameserver can encrypt replies. Well suited to peer-to-peer style usage of DNS. Bulk DNS data can be rysnc'd between peers over SSH, or perhaps mrysnc'd among groups of peers.
There is "DNS" as implemented so far and then there is "what's possible" using DNS. Peer to peer sharing of the data is hardly far-fetched. But it does not yet seem to have caught on outside of small groups doing passive monitoring, blocking and other manipulation.
I'd prefer to see decentralized email before "encrypted" email.
Recipient runs qmail listening for connections on some personally chosen port from among 1000's of choices. She is also running a firewall such as pf. authpf might also be useful.
Recipient tells sender her chosen port number and a personally chosen address to use. How does she do this? In person. Through the postal mail. Over the telephone. But _not_ over the Internet. Of course she does not have to use the same port and address for every sender.
In addition to the potential randomness of the port, the address she chooses could be any string of legal characters up to 250 whatever in length.
The approved sender runs qmail to connect to recpient's qmail and leaves a message on recpient's computer.
No DNS. No "email provider". No POP3.
How two users can discover each others' IP address and connect to each other through firewalls _without forwarding traffic through a third party server_ is left an as exercise for the reader. Chances are most users have used software that does this at one time or another, maybe without even knowing it. The methods have been around for decades. It works.
Centralized DNS and the need for a "domain name" is not needed.
Centralized "email providers" who store users' email are not needed.
There are a number of disadvantages and limitations to this approach. Yes, I know what they are. But I have already tested this and it works so I'm biased.
My opinion is that the _advantanges_ of "peer-to-peer", SMTP-to-SMTP email easily outweigh the disadvantages of store and forward and POP3 and make this a useful _alternative_ (not a replacement) system for centralized email. It's an _option_ users could have that would be quite useful.
The status quo approach to email has become highly centralized in both the need for ICANN DNS and "email providers". Not to mention the commercialization of email and the need to have "permission" to be able to send mail "because of" the proliferation of spam. It's far too difficult for any user to control their own email under the current centralized system. Solution: Give users another system where they _can_ control their email.
IMHO the centralization and protectionism of the current system (email is a business, but it doesn't need to be) is a bigger problem than lack of encryption. It's also what makes spamming viable. Everyone knows your email address or can get it easily enough. In many cases, that is not necessary.
As it stands, email is concentrated in a limited number of locations (the servers of email providers), transferred over a few ports (25, etc.) and users are limited in the addresses they can use (commercially registered domainnames).
It's just the nature of decentralized + secure + anonymous (at least to the transport layer) ... you can't realistically have all three without being open to effectively a DDOS, poisoning the system as a whole.
I'd worked on a proof of concept that would have all three of the above features using a DHT for delivery, relying on collisions for addressing, so that targets overlap, but a given target could only decrypt messages actually to them... the down side is it would be possible to send MANY messages to a target, so many that the system would be brought to a crawl and effectively useless.
I can think of worse outcomes than having to use djb's software, whether it's dummy-proof libraries, well-designed, small programs that work together, or algorithms chosen as defaults by some self-authorized standards group or by a company selling bloated, proprietary software that only works with other programs written by that company.
"So the RPi foundation deliver the first mass-market hackable board,..."
I notice this type of negative comment about inexpensive, "hackable" hardware freqently on HN. As if the fact that a piece of hardware is inexpensive and "hackable" is insignificant. Perhaps to these commenters, it is. But to others it may be signifcant.
A pocket-sized computer with networking that boots _either_ a GNU/Linux project, a BSD project or Plan 9, not to mention a few other open source OS, from an SD card. For me, this is the major advance and appeal of the RPi.
Far from perfect but still a major advance from the previous status quo, IMHO. Thank you RPi.
In a sense RPi is a market maker. Now they have to find ways to compete in the market they made.
Right on. I remember using a VAX in the 1980's and it still seems like the fastest computer I ever used. Everything that came after seemed sluggish by comparison. Then many years ago I tried someone's VAX image in the simh simulator running on on MS Windows. It was "too fast", if there is such a thing. I want a pocket-sized VAX.
