If you're looking for security, setup a RADIUS server and use 802.1x authentication instead of PSK.
Not to get nitpicky, but it's Slashdot and we're supposed to know better. The standard is 802.1X, not 802.1x. Capital letters for stand-alone standards, lowercase for addendums to a standard. Case matters, people.
Drivers who wait until they reach the road workers before trying to merge into the correct lane so they can pass everyone else who already queued up to go through the construction.
I agreed with you up to this point. Everyone queuing up in one lane before you reach the point of lane closure just means that you're slamming all of that traffic into half of the available space, and creating an even longer line and wait. I've been in too many jams where I wanted to get off at an exit two miles down the road, but there was construction five miles past that, and everyone was queuing up in a single lane (thanks to "helpful" truckers who sat in the free lane to prevent people from jumping ahead of everyone else).
Use ALL the available lanes, until you're forced not to. Seriously, it's better.
Chapter 3 is about text navigation. Sadly, the book doesn't go into as much detail on movement commands as I would've liked.
I had high hopes for Chapter 6 and 7, which deal with Vim scripting, but I was largely disappointed.
If you're looking for any advancing information on writing your own functions in Vim script, you're mostly out of luck here.
Overall, stylistically the book is a bit dry and humorless
I do feel the book should've gone into more detail in many areas. At 244 pages, the book is short and gives a rather shallow view of many of Vim's features.
There's nothing in this book you won't find in Vim's built-in documentation
At best, it seems like this would earn a 5 rating.
ATM is hugely popular in the US. Lots of DSL providers are running it in their network.
It caught on very briefly with the backbone providers, but had a huge amount of overhead compared to packet-over-SONET or more recently, Ethernet.
If you're trying to combine different types of access (leased-line, cable, DSL), I think you're out of luck with trying to aggregate everything into a single "super circuit". However, you can certainly utilize all of those individual circuits. Look up policy-based routing. Most every platform out there should support it through some method. Set it up so that email goes over the DSL, your database queries goes over the cable connection, and your VoIP goes over the leased-line. You'll probably need to tweak it a bit at first until you get a nice blend of traffic, and you'll want to make sure to set up some default routes to handle things if you have an outage on one of your circuits, but you'll see better performance on individual circuits and use all of them. If you've got the same type of access, but through different providers, you'll probably have to do the same. If you've got the same type of access through the same provider, then MLPPP or GRE should work.
Because there's no such thing as IPv4 multicast... Oh, wait. That's exactly what cable companies have already been doing with switched digital. Multicast isn't the main reason a cable company would go with IPv6. The biggest problem Comcast (and other cable companies) has is that your cable modem gets two, and sometimes three IP addresses, let alone all those set-top boxes doing that switched digital. One to manage it, one to give you your "public" IP, and perhaps a third for your phone. 24 bits (10.0.0.0/8) only gives you 16 million addresses, and that's assuming you're utilizing them rather effectively. They're probably using the 172.16.0.0/12 for their internal network, but even so, that only gets you an extra million addresses. Look at the number of customers Comcast has, and you begin to see the problem they have just with addressing all those cable modems and set-top boxes.
Don't expect to be getting your own IPv6 address any time soon. Most likely, they're going to roll it out for managing all those devices first, and you'll still be assigned an IPv4 address for your Internet connectivity.
Do you really trust the routing registry? And I'm talking about more than just using an SSL cert to verify their information. How frequently do they update their entries? I saw a number of problems dealing with RADB when I worked at Sprint a few years back. Customers get assigned blocks that used to be assigned to other customers, and RADB didn't always reflect that change in usage in a timely manner.
That's where your money's going to go. Creating a secure registry, and the infrastructure to handle the amounts of changes that occur on a daily basis.
It's more than just authenticating your neighbor. It's also about confirming that they have the right to be announcing the blocks that they're trying to announce to you.
The Post Office is a good example for the Internet. Right around the holidays, everyone starts to send catalogs, Christmas cards, and other packages. Far more than the Post Office deals with on a normal basis. Which causes delays in delivery. They even warn people: send everything by such-and-such date or it won't arrive in time for Christmas.
That's pretty much the Internet. Everyone expects a certain amount of bandwidth to be used. Occasionally, someone will exceed that, but usually at the same time, someone else isn't using theirs, so it's okay. But with Torrent, it's basically everyone using their bandwidth all at the same time. It's always Christmas. Now, the Post Office could staff for that situation, but obviously, prices will have to go up to accommodate their extra load. Likewise, your ISP can provide all the bandwidth necessary to let everyone use their limit of bandwidth all the time, but they're going to have to raise the prices a lot in order to provide that.
"What man has done, man can aspire to do." -- Jerry Pournelle, about space flight
