Non-rotating machinery is really nice for databases and transaction journalling - this stuff is likely to be significantly cheaper and more reliable than Battery-Backed RAM disks which are the main alternative, or than putting more RAM onto your CPU's motherboard. You could do a multi-tier database that journals to smaller Flash drives and then spools out to rotating disks, but this is big enough that it may be a cleaner solution.
Ownership isn't necessarily a useful concept when you're talking about information, compared to what actions you're capable of doing with information and what actions are appropriate or polite to do with it.
I think the "ownership" that's being asserted here is Facebook asserting that it owns the data about friend relationships and friend email and can limit what users like Scoble can do with it, and that it's doing that because it thinks users will be happier that way than if anybody can do anything they want with that info. For instance
If you sell your friends email addresses, or friends-of-friends addresses, to Spammers-R-Us, that's obviously rude, and Facebook probably wants to forbid that because otherwise nobody'd trust it with their email address. On just about any social network, you're not more than six degrees of separation away from some annoying spammer.
If you copy your friends' email addresses into your own desktop-based email system, on the other hand, that's perfectly reasonable, and as long as you don't send them mail that's outside what you'd expect from the relationship you have in the social network, sending them email is fine. (If it's a basically-social-discussion network, telling them what music you've been playing recently is usually polite, and inviting them to join your Multi-Level Marketing Network is obviously rude, and you can usually tell polite from rude when you see it.)
If you use one of those new-shiny-Web2.0-style online address management services, and it doesn't suck, and it doesn't do rude things with your information, I think copying your friends' contact info into it is probably ok, assuming you trust the system to respect the privacy of the information you're giving it. Gmail/Hotmail/Yahoomail, for instance, are probably fine, though obviously there's some privacy risk there (but probably no more than on the social-network site itself.) Some people might consider that privacy violation to be rude, but most people who feel that way probably aren't using their main email address on the social-network site.
It's been a year or two since I looked at Plaxo - I remember deciding that it was well-intentioned but sucked, though I don't remember if that was because of its privacy policies (if any) or its user interfaces. Social-network and information-management services that don't think clearly about privacy implications are a dime a dozen, as are sites that do think about it and want to exploit users.
But if you're a social-network provider, how do you decide what's the boundary between Contact-management services that are ok, and services that will annoy your users? Should you be more conservative than your average user, with a blanket policy against them, to avoid the risk that some of those services will annoy your user base? Should you be more liberal than average, because your users will get annoyed if you're overreachingly picky? Should you default to a greedy-capitalist approach that treats that contact information as your treasured marketing product that you don't want to share with other possibly-competing service providers?
I think Facebook probably overreacted here. I'd expect them to be more conservative than Myspace, but this probably goes too far.
It actually implied that *useful* IPv6 communication was impossible until now, which is true. HTTP 1.1 and SMTP _can_ be configured to work without domain name resolution, but it's very difficult to make it scale, because the most common configurations are virtual-server environments that serve lots of names behind one server (normally with one IP address, though IPv6 does give you the luxury of burning as many IPv6 addresses as you need, if your server OS can handle it.)
Just because ping works doesn't mean that you can have useful communication. Sure, it's fun to say "My email address is myname@2001:dead:beef::42", but if you even want to access a website, you want to be able to support HTTP 1.1 virtual web servers and therefore you need DNS, unless you want to first put their IPv6 address into your HOSTS.TXT file. I guess there's alway UUCP, though:-)
In practice there's one benefit of IPv6, which is that sometime before the Mayan Calendar rolls over in 2012, we're going to run out of IPv4 addresses, so if you haven't switched over to IPv6 by then, it'll be like sailing off the edge of the world near the "Here Be Dragons" sign. It's not actually quite that abrupt, but it gets increasingly very ugly, and different parts of the net either won't be able to reach each other, or will have limited functionality through 6-to-4 NAT kinds of things. Basically, if you're doing full IPv6 by then, you can say "I'm not dead yet", but otherwise you'll have to stop saying it sometime soon. And of course you've got to get your plans all lined up and your staff trained first.
In theory there were a lot of cool things that IPv6 was going to give us, back when we were optimistically planning for them in the early 90s. Most of them got implemented in IPv4, either fairly similarly (like IPSEC), or using different mechanisms that get the same job done (like DHCP for address assignment compared to IPv6's Netware-like stateless autoconfiguration.) And address allocation is a bit simpler, because we've got enough bits that you don't have to keep stealing them all the time, so you can do a cleaner job. (Though apparently DHCPv6 has feature-crept its way into more complexity than IPv4's original DHCP.)
But some of those cool things just haven't really worked out. Letting the subnetting hierarchy mirror the physical routing structure so that routing tables are smaller and cleaner was supposed to be really cool, but it doesn't match how the US ISP market is interconnected (YMMV in Europe, where big-city exchange points dominate the market as opposed to overlapping wide-area Tier 1 ISPs), and it especially doesn't work if lots of end users are multi-homed to different ISPs for reliability reasons, which is basically most businesses that have their servers at their offices instead of colo centers. There's a horridly ugly kluge called "shim6" that's trying to fix that, with makes-NAT-look-good levels of ugliness, and there are other games that the mobile-IP people may be able to help with, but basically any multi-homed customer is likely to end up advertising at least one fairly-specific route to the whole world in addition to getting connectivity from their ISP's larger netblock, so for the most part we don't win.
The lack of success in simplifying routing tables through hierarchy is becoming increasingly frustrating to the ISP community as we keep hitting limits on router performance. In the past, some of the problems were simple (RAM costs an order of magnitude more if you put it into a box with teal paint on the front, so many routers couldn't do full BGP tables once the net hit ~100000 routes), but we're running into things like some very popular very-large-user hardware that only has enough CAM hardware to support ~256K routes, which is about how many a typical ISP backbone connection sees (depending on how many of their own customers' routes the same box also handles) so ISPs are starting to filter out longer route advertisements - which can have effects like interfering with customers' redundant-ISP reliability, or making some traffic load-balancing less effective. The alternatives are to spend large chunks of money now (and of course IPv6 addresses are 4x as big so the box can support 1/4 as many routes if you're doing pure IPv6 on it) or waiting another year or two for Moore's Law to help.
ISPs have a range of reasons for using dynamic IP addresses rather than static, some of which have been mentioned here.
Administering addresses takes work and therefore costs money. Not that much work if you do it well, but a lot more work than running a DHCP pool.
It's *definitely* the easy way to configure addresses on PCs, compared to talking a non-geek through Windows's network administration menus. Windows defaults to DHCP, and you plug it in and it works. That's especially important for people who have laptops that they sometimes connect at home and sometimes at work or school or Starbucks.
It's also easier than talking a user through configuring a random-vendor NAT firewall box with their statically-assigned IP address using DHCP (which is how I run my home systems:-) In some cases, if the ISP manages the DSL/cablemodem box, they could administer it directly, but that's not universal and still takes work.
Some ISPs have anti-server policies, originally because Comcast was afraid of bad PR from bad performance, but mostly because they're greedy, don't want to support Real Users instead of couch potatoes, and can usually get Real Users to pay extra for a static address.
Renumbering a network is much much easier with DHCP, and ISPs occasionally need to renumber networks, either because they're changing equipment or getting bought or sold or doing different things with their architectures or getting larger blocks of addresses from ARIN, etc.
As far as I could tell from Zed's writing, it was his way of threatening to kick people's asses if they dissed him. It certainly seemed unprofessional.
I did finally get around to installing Firefox 2.x so I could run Adblock and Flashblock, and while it helps a bit, Firefox is still hopeless. For instance, this morning I started a browser, opened fark.com, opened up many news articles in tabs, read them and closed them, and after I was done and only had the main window open, FF was using about 200MB of RAM and 30-45% of my CPU, even though Fark's page itself didn't use much in the way of resources when I first started it.
If FF3 has learned how to clean up after itself, that'll be a huge improvement.
You've got your assertions pretty much backwards. Most general-purpose computers are IPv6-compatible, running either Windows XP (or occasionally Vista) or Linux or MacOS, though the user may not have a clue how to enable it or manage it and their ISP help desk may not know either. There are two different kinds of hardware that have problems with IPv6, for different reasons:
Home NAT/Firewall boxes, which may not be upgradeable, and which the user almost certainly didn't save the instructions for even if they were. On the other hand, they cost $29, so you may not care.
Big ISP routers often can't handle IPv6 well - for instance, Cisco software has supported IPv6 for a couple of years, but the routers perform as well as they do because most of the packet-routing grunt-work is done in ASICs that only know IPv4, not in the relatively slow CPUs which handle administration, routing protocols, and other applications that can't be done by the ASICs, including IPv6. Some of this is mitigated by ISPs that use routing at the edges and have a switched core using MPLS or ATM, so it's a bit more scalable, but they still need lots of IP routing hardware.
There are other intermediate layers - cable head ends, routers that support DSLAMs, dialup infrastructure for anybody who still cares, etc., which may also have trouble, but the big issues are at the core.
You could go look up the variety of approaches for connecting between IPv4 and IPv6 systems - there are NAT-like things, and tunneling, and embedding IPv4 addresses into IPv6, etc. They've all got their own issues, because translation often breaks things. DNS is one of the issues - for instance, if you know an IPv4 address for a given destination, and also an IPv6 address, should you default to IPv6? What if your IPv6 doesn't successfully connect to theirs (which is a problem in hybrid-v6 environments, and seems to be the default behaviour for some systems)?
But fundamentally, the reason we need to switch to IPv6 is that we're going to run out of IPv4 addresses, so at some point you or some guy in China or mobilephone user in India are going to have an IPv6 address with no corresponding IPv4 address. That means that if you want to reach a server that only has an IPv4 address, you're going to need to use some NAT-like translation gateway, which can share its IPv4 address with a bunch of IPv6 users. It may be ok as a transition strategy, and one or more solutions like that will probably have to be deployed for transition, but it gets ugly in the long run. (Better than having everybody's DSL, cable, and mobile network using 10.x.x.x and NAT, though, since you'd be able to use native IPv6 to reach other v6 users for real applications.)
Having a business degree is nice, but it doesn't usually teach you much about what real business environments are like; unfortunately the Real World is a better school for some kinds of things. As you say, clients aren't always good at paying on time. Some are consistently much worse than others - big businesses are often slow but usually will pay eventually, while small businesses sometimes just don't have the money, which they may or may not have known when they hired you, and maybe they're waiting for their clients to pay them so they can pay you, or maybe they're waiting for the customers who were supposed to be banging down the doors to hand them money once their really cool website was up and running, in which case you should have known going into the deal that you weren't going to get paid any time soon.
And clients aren't always realistic about what work they need done, or what it'll cost them. The old "$5 to turn the knob, $995 to know which knob to turn and how far" kind of story has pretty much always been true. Back when I was in the billable-hours game, it took a while to get used to the idea that my work might be worth $500K/year to a client (more if they only needed a day's work, negotiably a lot less for extended jobs), but the first time you tell somebody "Don't do X, that would be a Really Bad Idea, do Y instead", you've potentially saved them millions, and you don't feel at all bad charging them $250 an hour to do the grunt work on Y that their own employees could do for $50 if they knew how. (It was also interesting to have law firms as customers, since their attitude toward money was that computer consultants usually bill less per hour than associate lawyers, so go do what you need to do and don't waste our time supervising you. By contrast, retail companies are universally very price-sensitive about everything.)
Yeah, that part was even tackier than the rest. If he were to get in _my_ face like that I'd say "Sure, you do that. Saturday, High noon." And on Monday, if he was still pissed about my not showing up Saturday, I'd explain aikido to him.
I actually do qi gong rather than tai chi, but they're pretty much the same thing. As a fighting technique, you can threaten the other guy with "Dude, if you don't back off, I'm going to breathe deeply and start moving reeeaallll sllllloooooowwwwww!" On the other hand, it's amazingly good old-guy exercise; I wish I'd discovered them when I was younger. Awareness of what your body is doing when you move can be really cool.
Tai chi does have a few techniques for fighting with sticks or knives, though I get the impression they're mainly there to give younger guys something to keep them interested so they can learn the less flashy parts. The real risk in fighting against an older tai-chi practitioner is that if you can't always tell whether he's a newbie or has been doing this stuff for 20 years, and can take all that slow controlled stuff and do it really fast. I suspect that if a bar brawl were to start happening around my teacher, either it would get distracted by a couple of confusing remarks, or the participants would find that some of them were sitting on the floor unharmed while the others were throwing punches that kept missing their targets.
My college theater professor's boyfriend taught aikido as well as fencing, and he gave us a day's lesson as part of our classes. It was kind of fun to throw a punch at him, and find myself on the floor without him having used much of any force. It doesn't take too much work to learn how to deflect attacks from unskilled fighters so you've got time to get out of their way; doing so without anybody else getting hurt requires more skill. Tai chi has some of that as well; it's especially useful for the kind of fights where you don't want to hurt the other person, like when your kids are mad and feel like thrashing at you.
Chuck Norris says his actual way of dealing with fights is to not get into them, and walk away if he has to. Just because you _can_ beat the other guy up doesn't mean you have to.
A friend of mine was stationed at the US Army base in Okinawa during the late 70s. He had a Japanese-market car that got about 45mpg. It was very low-powered and small, but did fine for getting around town. When he came back to the US, he looked into bringing it back here, but found it would have to pass US safety standards, which would have been difficult even with the minimal standards back then.
There was also the problem that the car company would have to do the testing, including crashing a couple of cars, which was the problem Bill Gates had with his Porsche. That wouldn't be a problem for Tata, but they'd still probably need to reinforce the car body, and add some higher-cost features like airbags and anti-lock brakes that their low-budget car probably doesn't have.
ICANN's "grace period" policy permits "domain tasting", which means that something like 90% of the domain registrations are names being kited by "domainers" who hope to see enough hits to their ad banners to make it worth registering random names - and registering names that real people are actually interested in means they not only have a higher chance of getting random traffic, but also can scalp the names to the real users as well. And since there not only seems to be some leakage depending on what methods you use to check domain names, but also potentially from the TLD servers and registry themselves, the only way to check a name's availability without losing it seems to be to buy the name before checking and hope that if you get rejected because yourname.com was taken you won't also lose it in whatever.org or.net or other TLDs were left because the domainers were faster than you.
Ironically, the article that Slashdot's reporting on is at "Daily Domainer", a site which is targeted to parasites who buy up domain names for speculation that real people might otherwise want for real content (or typos from real domains.) So it's one parasite complaining about other parasites. There's not any obvious way to stop domainers (though eliminating the grace period would slow them down by changing the economics a bit) - it's trivial to generate a website with enough correctly-buzzworded content to fool an automated test, and not much harder to generate or plagiarize content if you need something fancier, such as good enough content to get search engines to start directing more traffic to your site; some of the SEO-scum web pages do in fact have more useful content than a lot of human-generated pages (though much of that's in blogs these days.)
ICANN's actual rules are that you get a 5-day grace period on returning the name for free, where "free" includes a refund of ICANN's cut of the domain reg fee. So domainer scum are constantly kiting domain names for slightly under 5 days, seeing if they get enough hits on their web pages to make it worth actually buying the domain name for the standard $6 (so they can park it and collect ad-banner revenue, as well as possibly scalping it to a legitimate user for a higher price.)
If a registrar lets you have a 30 day trial on a domain name, it's a business decision they're making on the risks of buying a name - they must be buying the name themselves after the grace period runs out (assuming you're remembering the time-frame correctly.)
I've recently been using the Cisco Press books by Wendell Odom, which are a two-volume set for 802 (or ICND1 640-822 + ICND2 640-816.) Volume 1 doesn't have too much IPv6, but Volume 2 has a lot, with lots of gory details to remember.
As you say, the 801 test that just got retired barely mentioned IPv6.
If Mozilla is using 250MB of RAM, and I've got 10 tabs currently open after opening and closing a couple of hundred windows, I would *hope* that there's a lot of memory that a garbage collector can reclaim, no matter _how_ fragmented the space has gotten.
The site that causes the most trouble for me is fark.com, which has pointers to lots of random newswire articles (and snarky headlines), which I normally read by opening each interesting-sounding one in its own tab and then reading the articles. Most online newspapers have some collection of random components, with whatever Javascript and flash animation the page designers thought would be most eyecatching or insightful or shiny, so it's 50-100 different kinds of dancing pigs burning RAM and CPU time and every piece of bad scriptware ever written and every different source of annoying ad-banner that's fit to print. Unfortunately, it's not a really good test case for the developers, because not only is FARK constantly adding new articles and scrolling old ones off into the archives, but the news articles they point to may stick around a few days or not depending on how the newspaper manages their website, and the advertising banners on the newspapers are coming up differently every time.
Their methodology's not the same as any other comparison I've seen - for them, a checkmark means "The candidate has a position that we could find easily", not "We agree with the candidate's position". So people got checkmarks for "Gun Control" if they said anything about it, whether it was "takin' eeeevilll gunz outa that handz o' our children" or "Protectin' our traditional second amendment" or anything in between. And I agree that on many of these issues, "taking a position" usually does mean "Federal Spending", but it doesn't have to - you could have promised to get the Feds out of space funding and that'd still get you a checkbox.
And yeah, they only rated the bigger-name candidates from the bigger-money parties, and they left out issues that many geeks think are critical, like communication privacy and spectrum policy.
Remember that Popular Mechanics isn't a political magazine, or a computer techie magazine, it's what's left of a mechanical-techie magazine. So they not only have urban network geeks in their audience (some of whom like guns), they also have NASCAR Geeks (many of whom like guns), and engineering types who are interested in big things that go boom (and most techies I know grew up blowing stuff up even if we didn't also shoot things.)
Unless they've added him in the last hour, I think people have been missing him because they're looking for "Ron", and he's listed as "Paul". Either that, or the fact that he's listed with the other Republicans mean that the fnords are too thick for most of you to see his name there.
Yes, most people aren't using IPv6, because we haven't quite hit the wall on IPv4 address space yet, and any of the other advantages of IPv6 either haven't panned out (hierarchical efficiencies) or else have equivalents that have been incorporated into IPv4 (IPSEC, DHCP), and most people haven't been sufficiently motivated by "We're all going to die, but not yet". And yes, IPv6 has more addresses than we'll hopefully ever need, but one reason for doing that is that protocol changeover is a real pain, and we _will_ have to do it, so we should avoid having to do it more than once.
I don't know what you mean by "People don't subnet anymore" - I work for a carrier, and believe me, users subnet all the time, even behind their NAT networks, and they've used Variable Length Subnet Masking for a decade or more, and using 10.x for their internal networks means they have plenty of room to play subnet games.
VLANs let you manage networks administratively using switches instead of letting routers manage them automatically, and I've never been a big fan of them except that they let you trade off sysadmin salary costs for router hardware costs and sometimes simplify your ACLs, but from an address space perspective you generally need a subnet per VLAN rather than per physical segment, so sometimes you can save address space but often it'll cost you more.
NAT breaks the end-to-end principle that's one of the things that makes the Internet such a powerful tool. One of the reasons for having enough IPv6 address space was so we don't need to do NAT; in the last decade we've gotten better at NAT traversal, which is fortunate because NAT has taken over as a way to provide firewalling and let people with multiple computers use braindamaged broadband carriers, but it's still an ugly hack. Basically, if you want to be a producer of information services, you need a real IP address, and even if you're just a couch potato, using VOIP requires ugly NAT traversal techniques like Skype's and doing file sharing requires at least a Bittorrent level of trickery, and even those things don't scale very well.
But let's go back to how many addresses we really need. There are almost 2**33 people on the planet, and if everybody has separate connectivity at home and at work (whether "work" is "a modern office building" or "the cellphone you carry while you're doing subsistence farming"), then we need to address at least 2**34 locations, and it's better to round that up to 2**40 so that everything's on byte boundaries and you've got a few bits to indicate different addressing types and a few more for population growth if we don't fix that. But that's how many _subnet_ addresses you need, not how many end-system address, because people have multiple addressible devices. Sure, you may not need a separate IP address for every atom in your body, but most people have a bunch of hardware, and at some point all of that may be addressable, whether it's your wristwatch or your toaster or your car or your car stereo or your phone or your headset or your wallet, etc. *Could* we get by with 64 bits of address space, with 40 bits per subnet and 24-bit subnet sizes? Maybe, if we give up on MAC-based stateless autoconfiguration, which was one of the cool things Netware had back in the early 90s. 48/16 would make it easier to manage the network side cleanly, but there are definitely companies that need more than a 16-bit Class B of their own just for internal use, and you'd rather avoid supernetting. In practice, the organizational structure of RIRs, LIRs, and ISPs is a lot cleaner if we've got 64 bits of network space to play with, plus whatever size of subnet's behind that.
But what's the cost of 128 bits vs. 64 vs. intermediate proposals like 80 or 96 or OSI-crufty 160? 64 bits _might_ cause a later protocol redesign, or at least NAT, while 128 is definitely overkill, and if it's not good past the end of the next century, it's because the Great Nanotech Singularity happened, in which case our artifi
Arrrgh - I get really tired of pro-evolution people treating it as if it's some sort of impersonal but friendly intelligent design that's trying to make us better and better. Evolution doesn't work that way - random things happen to the genome, and sometimes they interact with their local environments in ways that lead to more or fewer children successfully reaching reproductive age in good condition, and they either become more common or less common as a result.
That's *all* - it doesn't mean that things like tetrachromatism are an improvement - being a tetrachromat is cool, and being the son of one is uncool, and it doesn't mean that sickle cell anemia is good, even though being a carrier for it reduces your chances of dying from malaria so there are lots of carriers in places where malaria's common and variants on it have shown up independently in at least five different times and places. It *certainly* doesn't mean that evolution is or could try out ideas for the next generation human brain; evolution doesn't work like cell phone marketing, where you announce complex plans for a something you want to call a next generation and see if everybody else signs on before you've finished making it work. It just means that some random changes don't stick around because they lead to their hosts being dead or less reproductively successful, and other changes stick around and become more common, and "more common" doesn't mean "better", it just means "more common".
Don't get me wrong - NewAgey Progress-worshipping people who misunderstand evolution are usually much nicer to be around than Social Darwinist kill-the-inferior-races-and-dominate-the-inferior-social-classes people who misunderstand evolution. (Usually, anyway - occasionally they switch sides if they think you're standing in the way of progress, especially if they're socialists who believe in History.) But they still don't understand it.
I'm not a gamer, and gamers have been the big performance burners for desktop PCs for the last few years. I do typical office work and browsing, and would really rather have a desktop that sits quietly in the background and doesn't go dancing and rotating just because there's spare CPU.
Occasionally I'll do something that needs a few seconds of CPU time, such as recalculating a spreadsheet or having Word re-juggle large parts of a document, or doing public-key encryption setting up a VPN tunnel, but normally my CPU's running at about 5%, and the only time it really burns a lot of CPU is when Mozilla gets cranky about something and decides to burn all the CPU it can get, probably running some badly-written Flash or Javascript dancing ad banner, so a multicore CPU would just lose one core to Mozilla instead of the whole thing. (And yeah, maybe a newer Mozilla version would help, and I could run Adblock, but basically that would just mean my CPU would be idle even more of the time.) Once in a while I'll watch movies on the PC, which can burn a bit of CPU but is still basically limited by download speed.
Obviously servers are an entirely different case, but for the most part they're either running work that's easily parallelized (serving lots of web pages or other kinds of sessions) or else they're running a database application that gets lots of transactions dumped into it, so the DBMS needs to have its parallelism written carefully but everything else is still multiple applications. So they'd do well switching to multicore, but otherwise it's really just the gamers who need the extra horsepower.
PDFs are great for some things - reproducing the way a document looks when it's printed on a specific size and shape of dead tree product. But they're really lousy if you're trying to read the document on something that isn't the same size or shape as the dead trees, such as a computer monitor or an e-book reader or whatever. The example I run into most often is reading articles formatted in 2-column for academic journals - you've got to constantly scroll up and down the things. An e-book has a closer aspect ratio match - it's portrait as opposed to landscape - but if you want to shrink the document to fit the screen, the letters will be too small and there won't be enough pixels. (Leave aside the fact that I'm getting old, so I can no longer read 4-up printing without reading glasses:-)
HTML is the right kind of markup language - it describes the objects you want to display, and provides some hints about the author's preferences in fonts, etc., but leaves it up to the browser to display the document using whatever display technology it has and whatever layout capabilities it has, and uses the reader's preferences in fonts, etc. when appropriate.
It's not a new problem - I was on standards committees 20 years ago where some people got the reader-driven format issue (at that time we were using SGML rather than HTML) and some wanted to impose an author-driven marks-on-dead-trees model, which works fine if you're trying to print your airplane documents in replaceable-page A-sized paper manuals, and is fairly useless if the reader has a handheld monospace display that they're using while trying to fix an airplane.
Slashdot Mirror
Non-rotating machinery is really nice for databases and transaction journalling - this stuff is likely to be significantly cheaper and more reliable than Battery-Backed RAM disks which are the main alternative, or than putting more RAM onto your CPU's motherboard. You could do a multi-tier database that journals to smaller Flash drives and then spools out to rotating disks, but this is big enough that it may be a cleaner solution.
I think the "ownership" that's being asserted here is Facebook asserting that it owns the data about friend relationships and friend email and can limit what users like Scoble can do with it, and that it's doing that because it thinks users will be happier that way than if anybody can do anything they want with that info. For instance
But if you're a social-network provider, how do you decide what's the boundary between Contact-management services that are ok, and services that will annoy your users? Should you be more conservative than your average user, with a blanket policy against them, to avoid the risk that some of those services will annoy your user base? Should you be more liberal than average, because your users will get annoyed if you're overreachingly picky? Should you default to a greedy-capitalist approach that treats that contact information as your treasured marketing product that you don't want to share with other possibly-competing service providers?
I think Facebook probably overreacted here. I'd expect them to be more conservative than Myspace, but this probably goes too far.
It actually implied that *useful* IPv6 communication was impossible until now, which is true. HTTP 1.1 and SMTP _can_ be configured to work without domain name resolution, but it's very difficult to make it scale, because the most common configurations are virtual-server environments that serve lots of names behind one server (normally with one IP address, though IPv6 does give you the luxury of burning as many IPv6 addresses as you need, if your server OS can handle it.)
In theory there were a lot of cool things that IPv6 was going to give us, back when we were optimistically planning for them in the early 90s. Most of them got implemented in IPv4, either fairly similarly (like IPSEC), or using different mechanisms that get the same job done (like DHCP for address assignment compared to IPv6's Netware-like stateless autoconfiguration.) And address allocation is a bit simpler, because we've got enough bits that you don't have to keep stealing them all the time, so you can do a cleaner job. (Though apparently DHCPv6 has feature-crept its way into more complexity than IPv4's original DHCP.)
But some of those cool things just haven't really worked out. Letting the subnetting hierarchy mirror the physical routing structure so that routing tables are smaller and cleaner was supposed to be really cool, but it doesn't match how the US ISP market is interconnected (YMMV in Europe, where big-city exchange points dominate the market as opposed to overlapping wide-area Tier 1 ISPs), and it especially doesn't work if lots of end users are multi-homed to different ISPs for reliability reasons, which is basically most businesses that have their servers at their offices instead of colo centers. There's a horridly ugly kluge called "shim6" that's trying to fix that, with makes-NAT-look-good levels of ugliness, and there are other games that the mobile-IP people may be able to help with, but basically any multi-homed customer is likely to end up advertising at least one fairly-specific route to the whole world in addition to getting connectivity from their ISP's larger netblock, so for the most part we don't win.
The lack of success in simplifying routing tables through hierarchy is becoming increasingly frustrating to the ISP community as we keep hitting limits on router performance. In the past, some of the problems were simple (RAM costs an order of magnitude more if you put it into a box with teal paint on the front, so many routers couldn't do full BGP tables once the net hit ~100000 routes), but we're running into things like some very popular very-large-user hardware that only has enough CAM hardware to support ~256K routes, which is about how many a typical ISP backbone connection sees (depending on how many of their own customers' routes the same box also handles) so ISPs are starting to filter out longer route advertisements - which can have effects like interfering with customers' redundant-ISP reliability, or making some traffic load-balancing less effective. The alternatives are to spend large chunks of money now (and of course IPv6 addresses are 4x as big so the box can support 1/4 as many routes if you're doing pure IPv6 on it) or waiting another year or two for Moore's Law to help.
As far as I could tell from Zed's writing, it was his way of threatening to kick people's asses if they dissed him. It certainly seemed unprofessional.
If FF3 has learned how to clean up after itself, that'll be a huge improvement.
But fundamentally, the reason we need to switch to IPv6 is that we're going to run out of IPv4 addresses, so at some point you or some guy in China or mobilephone user in India are going to have an IPv6 address with no corresponding IPv4 address. That means that if you want to reach a server that only has an IPv4 address, you're going to need to use some NAT-like translation gateway, which can share its IPv4 address with a bunch of IPv6 users. It may be ok as a transition strategy, and one or more solutions like that will probably have to be deployed for transition, but it gets ugly in the long run. (Better than having everybody's DSL, cable, and mobile network using 10.x.x.x and NAT, though, since you'd be able to use native IPv6 to reach other v6 users for real applications.)
And clients aren't always realistic about what work they need done, or what it'll cost them. The old "$5 to turn the knob, $995 to know which knob to turn and how far" kind of story has pretty much always been true. Back when I was in the billable-hours game, it took a while to get used to the idea that my work might be worth $500K/year to a client (more if they only needed a day's work, negotiably a lot less for extended jobs), but the first time you tell somebody "Don't do X, that would be a Really Bad Idea, do Y instead", you've potentially saved them millions, and you don't feel at all bad charging them $250 an hour to do the grunt work on Y that their own employees could do for $50 if they knew how. (It was also interesting to have law firms as customers, since their attitude toward money was that computer consultants usually bill less per hour than associate lawyers, so go do what you need to do and don't waste our time supervising you. By contrast, retail companies are universally very price-sensitive about everything.)
Yeah, that part was even tackier than the rest. If he were to get in _my_ face like that I'd say "Sure, you do that. Saturday, High noon." And on Monday, if he was still pissed about my not showing up Saturday, I'd explain aikido to him.
Tai chi does have a few techniques for fighting with sticks or knives, though I get the impression they're mainly there to give younger guys something to keep them interested so they can learn the less flashy parts. The real risk in fighting against an older tai-chi practitioner is that if you can't always tell whether he's a newbie or has been doing this stuff for 20 years, and can take all that slow controlled stuff and do it really fast. I suspect that if a bar brawl were to start happening around my teacher, either it would get distracted by a couple of confusing remarks, or the participants would find that some of them were sitting on the floor unharmed while the others were throwing punches that kept missing their targets.
My college theater professor's boyfriend taught aikido as well as fencing, and he gave us a day's lesson as part of our classes. It was kind of fun to throw a punch at him, and find myself on the floor without him having used much of any force. It doesn't take too much work to learn how to deflect attacks from unskilled fighters so you've got time to get out of their way; doing so without anybody else getting hurt requires more skill. Tai chi has some of that as well; it's especially useful for the kind of fights where you don't want to hurt the other person, like when your kids are mad and feel like thrashing at you.
Chuck Norris says his actual way of dealing with fights is to not get into them, and walk away if he has to. Just because you _can_ beat the other guy up doesn't mean you have to.
There was also the problem that the car company would have to do the testing, including crashing a couple of cars, which was the problem Bill Gates had with his Porsche. That wouldn't be a problem for Tata, but they'd still probably need to reinforce the car body, and add some higher-cost features like airbags and anti-lock brakes that their low-budget car probably doesn't have.
Ironically, the article that Slashdot's reporting on is at "Daily Domainer", a site which is targeted to parasites who buy up domain names for speculation that real people might otherwise want for real content (or typos from real domains.) So it's one parasite complaining about other parasites. There's not any obvious way to stop domainers (though eliminating the grace period would slow them down by changing the economics a bit) - it's trivial to generate a website with enough correctly-buzzworded content to fool an automated test, and not much harder to generate or plagiarize content if you need something fancier, such as good enough content to get search engines to start directing more traffic to your site; some of the SEO-scum web pages do in fact have more useful content than a lot of human-generated pages (though much of that's in blogs these days.)
If a registrar lets you have a 30 day trial on a domain name, it's a business decision they're making on the risks of buying a name - they must be buying the name themselves after the grace period runs out (assuming you're remembering the time-frame correctly.)
As you say, the 801 test that just got retired barely mentioned IPv6.
The site that causes the most trouble for me is fark.com, which has pointers to lots of random newswire articles (and snarky headlines), which I normally read by opening each interesting-sounding one in its own tab and then reading the articles. Most online newspapers have some collection of random components, with whatever Javascript and flash animation the page designers thought would be most eyecatching or insightful or shiny, so it's 50-100 different kinds of dancing pigs burning RAM and CPU time and every piece of bad scriptware ever written and every different source of annoying ad-banner that's fit to print. Unfortunately, it's not a really good test case for the developers, because not only is FARK constantly adding new articles and scrolling old ones off into the archives, but the news articles they point to may stick around a few days or not depending on how the newspaper manages their website, and the advertising banners on the newspapers are coming up differently every time.
And yeah, they only rated the bigger-name candidates from the bigger-money parties, and they left out issues that many geeks think are critical, like communication privacy and spectrum policy.
Remember that Popular Mechanics isn't a political magazine, or a computer techie magazine, it's what's left of a mechanical-techie magazine. So they not only have urban network geeks in their audience (some of whom like guns), they also have NASCAR Geeks (many of whom like guns), and engineering types who are interested in big things that go boom (and most techies I know grew up blowing stuff up even if we didn't also shoot things.)
On the other hand, Kucinich isn't there.
I don't know what you mean by "People don't subnet anymore" - I work for a carrier, and believe me, users subnet all the time, even behind their NAT networks, and they've used Variable Length Subnet Masking for a decade or more, and using 10.x for their internal networks means they have plenty of room to play subnet games.
VLANs let you manage networks administratively using switches instead of letting routers manage them automatically, and I've never been a big fan of them except that they let you trade off sysadmin salary costs for router hardware costs and sometimes simplify your ACLs, but from an address space perspective you generally need a subnet per VLAN rather than per physical segment, so sometimes you can save address space but often it'll cost you more.
NAT breaks the end-to-end principle that's one of the things that makes the Internet such a powerful tool. One of the reasons for having enough IPv6 address space was so we don't need to do NAT; in the last decade we've gotten better at NAT traversal, which is fortunate because NAT has taken over as a way to provide firewalling and let people with multiple computers use braindamaged broadband carriers, but it's still an ugly hack. Basically, if you want to be a producer of information services, you need a real IP address, and even if you're just a couch potato, using VOIP requires ugly NAT traversal techniques like Skype's and doing file sharing requires at least a Bittorrent level of trickery, and even those things don't scale very well.
But let's go back to how many addresses we really need. There are almost 2**33 people on the planet, and if everybody has separate connectivity at home and at work (whether "work" is "a modern office building" or "the cellphone you carry while you're doing subsistence farming"), then we need to address at least 2**34 locations, and it's better to round that up to 2**40 so that everything's on byte boundaries and you've got a few bits to indicate different addressing types and a few more for population growth if we don't fix that. But that's how many _subnet_ addresses you need, not how many end-system address, because people have multiple addressible devices. Sure, you may not need a separate IP address for every atom in your body, but most people have a bunch of hardware, and at some point all of that may be addressable, whether it's your wristwatch or your toaster or your car or your car stereo or your phone or your headset or your wallet, etc. *Could* we get by with 64 bits of address space, with 40 bits per subnet and 24-bit subnet sizes? Maybe, if we give up on MAC-based stateless autoconfiguration, which was one of the cool things Netware had back in the early 90s. 48/16 would make it easier to manage the network side cleanly, but there are definitely companies that need more than a 16-bit Class B of their own just for internal use, and you'd rather avoid supernetting. In practice, the organizational structure of RIRs, LIRs, and ISPs is a lot cleaner if we've got 64 bits of network space to play with, plus whatever size of subnet's behind that.
But what's the cost of 128 bits vs. 64 vs. intermediate proposals like 80 or 96 or OSI-crufty 160? 64 bits _might_ cause a later protocol redesign, or at least NAT, while 128 is definitely overkill, and if it's not good past the end of the next century, it's because the Great Nanotech Singularity happened, in which case our artifi
That's *all* - it doesn't mean that things like tetrachromatism are an improvement - being a tetrachromat is cool, and being the son of one is uncool, and it doesn't mean that sickle cell anemia is good, even though being a carrier for it reduces your chances of dying from malaria so there are lots of carriers in places where malaria's common and variants on it have shown up independently in at least five different times and places. It *certainly* doesn't mean that evolution is or could try out ideas for the next generation human brain; evolution doesn't work like cell phone marketing, where you announce complex plans for a something you want to call a next generation and see if everybody else signs on before you've finished making it work. It just means that some random changes don't stick around because they lead to their hosts being dead or less reproductively successful, and other changes stick around and become more common, and "more common" doesn't mean "better", it just means "more common".
Don't get me wrong - NewAgey Progress-worshipping people who misunderstand evolution are usually much nicer to be around than Social Darwinist kill-the-inferior-races-and-dominate-the-inferior-social-classes people who misunderstand evolution. (Usually, anyway - occasionally they switch sides if they think you're standing in the way of progress, especially if they're socialists who believe in History.) But they still don't understand it.
Occasionally I'll do something that needs a few seconds of CPU time, such as recalculating a spreadsheet or having Word re-juggle large parts of a document, or doing public-key encryption setting up a VPN tunnel, but normally my CPU's running at about 5%, and the only time it really burns a lot of CPU is when Mozilla gets cranky about something and decides to burn all the CPU it can get, probably running some badly-written Flash or Javascript dancing ad banner, so a multicore CPU would just lose one core to Mozilla instead of the whole thing. (And yeah, maybe a newer Mozilla version would help, and I could run Adblock, but basically that would just mean my CPU would be idle even more of the time.) Once in a while I'll watch movies on the PC, which can burn a bit of CPU but is still basically limited by download speed.
Obviously servers are an entirely different case, but for the most part they're either running work that's easily parallelized (serving lots of web pages or other kinds of sessions) or else they're running a database application that gets lots of transactions dumped into it, so the DBMS needs to have its parallelism written carefully but everything else is still multiple applications. So they'd do well switching to multicore, but otherwise it's really just the gamers who need the extra horsepower.
HTML is the right kind of markup language - it describes the objects you want to display, and provides some hints about the author's preferences in fonts, etc., but leaves it up to the browser to display the document using whatever display technology it has and whatever layout capabilities it has, and uses the reader's preferences in fonts, etc. when appropriate.
It's not a new problem - I was on standards committees 20 years ago where some people got the reader-driven format issue (at that time we were using SGML rather than HTML) and some wanted to impose an author-driven marks-on-dead-trees model, which works fine if you're trying to print your airplane documents in replaceable-page A-sized paper manuals, and is fairly useless if the reader has a handheld monospace display that they're using while trying to fix an airplane.