Actually IPv6 interfaces can, nay MUST, allow multiple address assignments. So in an all IPv6 world, each of your computers will have an ISP-dependent (publically routable) address, as you say. But, they will each ALSO have a locally assigned, non-routable ("site-local") address that you can use as an unchanging address on your LAN.

Plus, with IPv6 router solicitation/advertisement and/or DHCPv6, even the case of updating machines with new ISP-dependent addresses is not the onerous task you make it out to be.

This is what DHCP is for.

Unfortunately, ISP's have other options for shaping. Bittorrent traffic is quite distinctive and is detectable to a fairly high degree of accuracy just by analyzing the traffic pattern. Encrypting the packets does not (and cannot) obscure the traffic pattern.

The original question asked was: Why is verbosity bad? My answer was to define verbosity as the inverse of expressiveness, with the implicit assumption that greater expressiveness is better. I think that you intuitively also make this assumption when you speak positively of the "compactness" (expressiveness?) of shell scripts when applied to suitable tasks.

Let's say you are given two scripts that accomplish exactly the same task. One script has 10 LOC, and the other has 100 LOC (ignoring all comments, whitespace, etc). Which script would you say is more verbose? And which would you say is more expressive?

Mod parent up. Very well put.

For a given task, one language is more expressive than another language if the former takes fewer LOC to accomplish the task than the latter. If we take LOC to be a reasonable approximation for verbosity, then verbosity and expressiveness have an inverse relationship.

I don't know Objective-C, but since C is just a few steps up from assembler, I can accept that Objective-C is probably more expressive than C, since nearly every language is. Thus, I cannot agree with you that Objective-C is more verbose than C. You and I must be using different definitions of "verbosity".

Verbosity = ( 1 / Expressiveness )

IMHO, this is the biggest barrier that keeps commercial development out of Linux. Basically, the Linux philosophy assumes that all applications are open source, so it doesn't matter if the ABI changes with every point release of the kernel, since the distros can just recompile all their binaries when packaging. This philosophy is incompatible with the commercial software method of distributing apps as binary blobs.

You raise some good questions. I don't think I explicitly advocated for or against inheritance of property, although I believe that in a free society, a person should be allowed to give away their possessions to whomever they choose, before or after death.

But let's try to stay on topic. A property owner is entitled to earn as much or as little from his ownership as the market will bear. If there were a sensible way to define property in the digital sense, then the same would apply to digital property owners. Unfortunately, because copies of digital works can be created at virtually no cost (unlike real property), normal physical markets cannot be applied to them, lest we come to the inevitable conclusion that, by the laws of supply and demand, the price for a digital work will tend rapidly to zero. Who is going to pay for an item that is (potentially) infinitely abundant?

Since you and I both see intrinsic value in many digital works (I like to watch TV and movies as much as the next guy), I think we can agree that such works cannot be treated the same as physical goods. So far, attempts to monetize digital works have mostly revolved around turning them into physical objects (CDs, DVDs), or using encryption to enforce the creator's will over every copy created, or both. These avenues of monetization are forever destined to fail in a free society, because people in such a society are free to communicate with each other, and that includes digital files.

So where does that leave the digital creator who wants to earn a living from his works? I believe that trying to turn digital works into widgets that can be bought and sold is the wrong way to go. Unfortunately, I don't have a satisfactory counter scheme that is fair to all involved, so I'll just leave it at that.