OpenNTPD has clearly been written by someone who doesn't understand NTP. For example, it advertises incorrect root delay and disperson values, which can cause clients to fail to achieve a majority vote, or to pick the wrong peer to synchronise against. (Earlier versions were even worse, they advertised themselves as being at stratum 0, which could cause synchronisation loops; this has thankfully been fixed, but it doesn't inspire much confidence in the authors' competence.)

I've also found OpenNTP to fail to regulate the local clock on dodgy hardware (it would oscillate wildly, with an amplitude of 3 seconds or so), in situations where the reference ntpd coped just fine.

Folks, do yourself and everyone a favour -- run the reference NTP, run chrony, heck, run some SNTP client, but please avoid OpenNTPD.

No, it means White Ruthenia . (Rus' as opposed to Rossiya.)

--jch

IPv6 is enabled by default on all Linux distributions known to me, and that has been the case for five years or so.

(Your confusion may stem from the fact that, unlike Windows, Linux distributions do not enable the Teredo protocol by default. But that's a different matter.)

--jch

More difficult to debug when it fails, but often yields better performance:

sudo apt-get install miredo

--jch

So you invest $175,000 without making sure you'll get software updates?

I rest my case -- it's your own fault.

--jch

The following table specifies the limits on physical memory for Windows 7.
...
Windows 7 Starter 2 GB N/A

http://msdn.microsoft.com/en-us/library/windows/desktop/aa366778(v=vs.85).aspx

Most large companies have been requiring IPv6-capable gear for the last 4 years or so, while the DoD mandages IPv6 support since 2005.

Because of that, most recent hardware and software is IPv6-capable. Cisco IOS, for example, has been doing IPv6 since 2001. Microsoft servers have been able to work over IPv6 since Server 2003. Mac OS X since 10.4, Linux since the 2.4 series.

If you're still stuck with IPv4-only hardware or software, it's your fault.

--jch

Andy Hertzfeld might disagree.

--jch

--jch

Subscriber based -- the disconnection is linked to the real-world identity of the subscriber. (In France, you cannot even buy a pre-paid telephone SIM without showing id.)

In principle, yes.

You may want to read http://en.wikipedia.org/wiki/HADOPI .

--jch

Tor is not only for hiding your identity from the server; it's also useful for preventing your ISP from learning who you're connecting to, and for tunnelling aroud any firewalls that might be in place (as long as tor itself isn't blocked).

For example, I commonly use ssh over tor. Since I'm authentifying to the server, I'm obviously not hiding from it, but I prevent my ISP from knowing where I ssh to.

-- jch

Neither does it mention Darcs, Mercurial or GNU Arch.

-- jch (who prefers Darcs himself, but has been switching to Git for compatibility with the rest of the universe)

The magnet link contains a hash of the .torrent file, which happens to be the key to search for in the DHT (it's in the btid field of the magnet link). The local peer consults the DHT, and finds some peers that participate in the desired swarm; it then downloads the .torrent file from those peers. After checking that the torrent matches the expected hash, the local peer just does normal trackerless operation.

-- jch

Actually, you don't even need the DHT. Most BitTorrent clients implement "local network discovery", a protocol extension that allows them to automatically and quickly discover peers participating in the same swarm on the local LAN segment. It's usually disabled by default, for obvious privacy reasons, so you'll want to hunt for the features in your preferences dialog.

--jch

It uses a technique known as a Kademlia Distributed Hash Table (DHT). It's a rather tricky algorithm, which turns out to work beautifully for this particular application.

--jch