I've been trying to think about the multihoming problem for maybe five years, and the answers don't seem to be getting any better (:-) IPv6's advocates made a big deal in the early days about how they were going to give us magical solutions for scalable addressing and routing, and we weren't going to have all the end users in another big swamp with all the anarchy of IPv4 address assignment and just longer addresses, but the main thing that seems to have been done about it is have ICANN price IPv6 space high enough to discourage casual experimenters from getting their own space.
Some of the original motivations for end-users getting their own address space have gone away - DHCP means the cost of readdressing computers has gone to nearly zero, especially for desktop machines, and DNS means that you really _can_ move a server, though you might need a week or two of overlap on the address space for everybody's caches to time out (and IPv6 might force you to do some kind of tunneling deal with your old ISP), and firewalls mean that you might not by exposing most of your IP devices to the outside world anyway, just your public servers.
But even that doesn't mean that routing becomes much simpler, because that's only useful if you can aggregate - for instance, you could get/48 of provider-assigned address space from ISP1, and advertise that space on your connection to ISP2, so the global routing tables still have two entries for you even though they're assigned somewhat more cleanly. And aggregation doesn't always work well for geographically dispersed end-user customers - it's one thing for a university to aggregate the addresses from a bunch of buildings that are all in the same city, but if you've got a retail store chain with a thousand stores, should they all be part of one/48 at headquarters and route their external traffic there through IPSEC tunnels, or should each branch get provider-assigned address space from whatever ISP is nearby and try to tie that mess together, or some hybrid of both? For performance reasons, especially with VOIP, you'd like to keep latency down, so it's better to keep traffic in the same half-continent or so if you can, but it's not clear that there's an obvious answer.
IPv6 was supposed to free us from the evils of NAT. But the easiest ways to do multihoming either get into the swamp scalability problems or else do some kind of NAT or tunnel things to let you advertise one set of address space from two ISPs. Maybe that's not such a huge problem?
Your question d) about how many users it takes to assign 200/48s sounds like you're thinking about home internet service. Typically an ISP gets a/32, and provides/48s to business end-user customers, who would typically do things like assign a/64 to a building. So that's an ISP with 200 dedicated-access business customers - not really small, but not all that large either. On the other hand, an ISP that does a lot of dialup business is unlikely to assign a/48 to every dial POP - probably a/64, or possibly even a longer prefix, if anybody who still cares about dialup five years from now wants real IPv6 instead of IPv4 behind a 6to4 gateway or NAT.
There are conditions when it makes sense to provide/64s to smaller customers - I wouldn't be surprised to see home broadband service assigned that way, since that lets the ISP's/32 support four billion customers, each of whom can support 64K LANs each with host addresses assigned based on the 48-bit MAC address. Whether small-business-office customers get/64 or bigger remains to be seen - a typical standalone office really doesn't need a/48, but the politics of address space assignment may encourage ISPs to do it anyway. On the other hand, a gas station clearly doesn't need more than a/64.
Yes, lots of the equipment gets old and eventually needs replacing, but the government really does keep equipment around long after it'd be obsolete in the commercial world - after all, a desk grunt who's typing memos at 100wpm and sending a bit of email is only generating information at ~100 baud, and as long as you stay off the Upgrade-Microsoft-Office-Every-Year treadmill, the main reason not to be using a 386 PC is that too many web pages want newer memory-hogging browsers, and even upgrading to a 3GHz Pentium doesn't mean you need a bigger router for the office if he's not downloading a lot more material.
But upgrading custom software is a much different scale of project than simply upgrading boxes and reconfiguring some web servers. There's a huge amount of mission-critical big nasty badly-documented stuff out there running on mainframes, PCs, and Unix boxes of various sorts that knows about IPv4 and might or might not know about DNS and DHCP. Finding all of it isn't quite the same level of effort as finding Y2K bugs, but it's still a huge hard-to-estimate job.
A lot of the government's computer and network equipment can be upgraded fairly easily to support IPv6 or dual-stack environments, as long as the PCs are new enough to run XP (many of them aren't, but a couple of years of transition period can help that, and maybe we can get them to use Linux or BSD on the older boxes.) Some routers have enough horsepower to run IPv6, others will need to be replaced, but that's all pretty straightforward. And web servers and email can be easily configured for IPv6, so that takes care of a large part of the government's users.
But there's also a lot of custom server applications that would need to be rewritten to support IPv6 (not even counting the stuff that needs to be rewritten to support IPv4 instead of SNA, or to use DNS instead of hard-coded IP addresses:-). Most of it can be kept going by hiding it behind 6to4 gateways of various sorts, so you'd end up with a lot of 10.x IPv4 islands connected to the rest of the world by IPv6, and optionally tunneled with each other, somewhat the way a lot of the SNA stuff is really running as emulations and tunnel servers on top of IPv4 these days.
On the other hand, the folks who brought us Y2K consulting would all like their piece of the pie as well. Much of Halliburton's work in Iraq could be done by other people if they had the same political connections, but there are some parts of the oil business that Halliburton are not only the best at what they do, they're almost the only people capable of doing it, and only Schlumberger are close.
As Asians get broadband at home, they're going to start burning a lot of IPv4 addresses, and to the extent that they deploy cellphones as IPv4 instead of IPv6, they'll also burn up lots of addresses. China's the main fast-growing player right now, but India may gradually get its act together and catch up. Japan and Korea are already heavily wired and/or wirelessed (insert canonical old-people-in-Korea joke here).
But there are hard problems and easy problems
Linux, BSD, MacOS, and newer Windows versions all support IPv6 natively, though some of the support is rough (e.g. if your default DNS server doesn't know IPv6, things fail strangely or work slowly.)
BIND and Apache support IPv6 if you want them to, and Firefox mostly does. So do some LDAP servers.
Cisco, Juniper, and other major router vendors support IPv6 on newer equipment, but often their IPv4 support is in fast ASICs while the IPv6 uses slower CPU-driven processing so most ISPs haven't turned it on on most equipment, and IPv6 does take a lot more memory for tables because the addresses are bigger, and it seems that running dual-stack slows down everything compared to running IPv6-only and IPv4-only.
Dialup Internet support comes from a really wide variety of equipment - some stuff can be easily upgraded, other stuff is antique. Fortunately, most dial users are clients who can use NAT or tunnel servers so they can ignore the problem.
Home firewall routers like you've probably got under your desk don't support IPv6 - if you've got a Linux-based model, it might be upgradeable, but it might not have the horsepower to keep up with a fast broadband connection.
Lots of NAT, proxy, and tunnel variants, 6to4 gateways, etc. exist, and can be used to hide non-IPv6 equipment from the scary new IPv6 network, or to let IPv6 equipment pretend to be IPv4 when talking to older networks, so there's a lot of transition support possible for people who want to use it - but it's potentially a lot of work.
Lots of custom applications were written for IPv4 only, and would have to be rewritten to support IPv6 - it's a level of pain similar to getting Y2K bugs fixed. Some of them can be worked around by hiding behind 6to4 gateways, some can't. Sometimes it's just a database schema change, sometimes it's not.
ISP network management databases often just know IPv4 - supporting IPv6 not only means changing out lots of tools, but also input screens for users, etc. Some ISPs are better at that than others, but as with equipment replacement, major software changes require money, and most ISPs aren't making much.
Most of the SEO business is dishonest, even though it's still hard work - it's figuring out what the search engines think looks interesting to humans so you can take your client's web pages, which aren't interesting to humans other than your client, lie to the robots about them, so the robots will lie to humans who want to find interesting web pages about various subjects.
Zach is quite correct that it's about money - if you do a Google search for "rolex watches", for instance, the first five or so entries (other than the advertising section) appear to be legitimate, and the rest appear to be various sites put together by scammers who are trying to SEO themselves into the highest ranking by writing inane content and playing link games. (Fortunately, I don't want to buy such an ungeeky watch, but I do often want to find out technical information about various medicines, and that often gets swamped by SEO-spammer medicine stores. Bad enough that it's hard to find articles on how drug X interacts with drug Y, because even the legitimate sites will have indexes on their pages pointing to their articles about drugs A-Z, but if either drug is something that's heavily promoted for sale on the web, that increases the probability of your search drowning in spam.)
It's possible to make money as a white hat SEO, doing a couple of things
Showing your client how to use META tags for their keywords, and similar labelling so search engines can find the right information about your site, which should take about an hour's billable work, and that's not why you go into the SEO business.
Actually doing the work for them, which may take a bit longer, and may be an ongoing business relationship if they change content often enough.
Teaching them how to write interesting useful content so their website's worth visiting - that's like being an editor and writing coach and advertising consultant, and that's actual value you're providing if they're interested. You could actually make money doing this, and if calling yourself an SEO is how you hook your client, well, then call yourself that, but that's not really what you're doing.
But the SEOs who do most of the promotion about the SEO business are really the black-hats, building link farms and similer techniques to lie to the robots, making them think your boring pages are interesting to humans, so the robots will lie to the humans who want to find interesting pages. It's dishonest, and it screws up the value of search engines for the users, and good luck to Google in finding them and stopping them.
Most SEOs are mostly evil with a bit of trite good stuff; this guy had mostly good stuff with a small dose of evil. The way search engines work is to predict what will be interesting to humans, and let robots collect and rank it. You can either raise the rank by
making the content more interesting to humans
making it easier for robots to find your content, or
lying to the robots so they'll tell the humans that your uninteresting page is interesting. This is how most SEOs promise to raise your ranking.
TFA was mostly about how to make your content interesting, though to some extent that was "make it interesting to people so they link to your pages", but that's at least halfway fair. And it was also mostly about how to make your pages accessible to the robots, which is good advice, and many SEOs pretend that that's what they're really telling you how to do. But when TFA was talking about whether to work with a pro, it was somewhat friendly to the kinds of unethical SEO scum who lie to robots by building link farms and similar abuse, though it did mostly emphasize working with people about your content.
What really irks me about SEO stuff? It's when I'm looking for medical information on the web, and get zillions of robo-generated links that are pointing to sites that sell medicines, drowning out the sites that have really good information. Sure, sometimes you'll see the government websites first, but they're mostly the NIH ones with advice about dosage and insisting you follow your doctor's orders and what not to take along with that drug, not the more interesting ones about how the drugs work and what advantages or disadvantages they have compared to other drugs.
Already one of the world's most perfect drinks, and now we find out that it has health benefits as well. Has there been any positive news about whipped cream's potential health benefits?
A.C. commented that it's probably because of the diuretic effects of caffeine making you drink more liquids, which was also my first guess. However, it could equally well be incorrect - caffeine tends to dehydrate you more than the liquid in the coffee or tea replenishes, so unless you're careful to make up for it with water or other non-alcoholic non-caffeinated drinks, you mostly tend to have less water in your system.
I live in a condo also. Inside wiring isn't the telco's problem unless you're paying them extra for inside wiring coverage, and hasn't been for over a decade in most US states. The telco's problem is to make sure dial tone gets to the right jack in the wiring closet, though you can quibble about the couple of inches of jumper wire from the telco jack strip to the condo's inside-wire jack strip and occasionally I've had to. If they've connected working dialtone to the correct inside-wire jack that goes to your apartment, then they've done their job.
If you're paying extra for inside-wire coverage, which here in California PacBell territory is something like 85 cents a month, it's a different deal. A few years ago, during the rainy season, my phone line suddenly got really really noisy, and they found that it was a problem in the walls somewhere between two of the bedrooms. They didn't have the quality of electrician working for them to actually fix the problem (:-), but they at least isolated it and disconnected the bad section from the rest of the house, and I stuck a cordless phone in the isolated bedroom. (Really fixing it would require lots of carpentry or else external wire, which they charge real by-the-hour rates for, and I'd have had to move all my junk out of the junk-storage bedroom where the problem was.)
Back when there were competing local-access providers, somebody cross-connected my PacBell line with my neighbor's MCI line. Took forever to get it fixed, because MCI wouldn't talk to me (I wasn't their customer), and PacBell thought the line was working (electrically fine connection to nothing.) Eventually PacBell came and fixed it. We think the problem was really caused by the subcontractor installing Sprint local service in another neighbor's unit.
First of all, don't expect deep technical detail from a news article. Reverse engineering the technical detail from a news article is similarly fraught with peril, but worth a try:-)
Viruses on networks infect their victims by sending messages to (or back and forth with) their victims. You don't have to run the victim program to receive or detect the virus - you just have to accept and send the right messages, and then you need to distinguish between messages that are viruses and other kinds of messages (e.g. spam), and for a honeypot network you also need to communicate with your friends on a network that doesn't get flooded out by the virus, so a backdoor network can be helpful. For a honeypot network, you normally won't have any legitimate traffic on the Internet side, so all the packets you receive are either viruses or other malicious traffic, so your risks of false positives are somewhat reduced.
Most network viruses work in one of three ways
Sending single packets to a target application, such as the tightly crafted UDP 1434 attack in Slammer. For a honeypot, you need to listen on the port and distinguish between viruses and general scanner doorknocking, but if your response to possible attacks is to shun or divert all traffic from anybody who sends traffic to your honeypot, and your ISPs are making at least some effort to do IP address-spoofing prevention, you should be able to find miscreants fairly quickly even if they're not viruses.
Message exchanges, usually TCP, that are corrupt in some way. Here the job is a bit more complex, because your honeypot has to send one or more appropriate response packets back after a TCP handshake, and you may not be as effective if you're not sending back the right responses, but since you don't have any legitimate traffic, everything you get is at least some kind of malicious.
Valid sessions with applications such as SMTP that send an malicious payload to a separate application such as Outlook. For this kind of virus, there are a number of simple and safe SMTP servers, and the problem is figuring out what messages are viruses (usually few) and what are just spam (usually most). There are reasonable uses for spam detection, so your honeypot network can be highly useful even if it's not always correct about viruses, and these days most of the spam and phishing gets sent from zombies or open relays that need to be cleaned up anyway. But most of the spam is syntactically correct, because it's trying to display correctly and infect the gullible reader's wallet, not their computer, so you can fairly easily filter that out and find the more interesting stuff. That may not always be viruses, but it's at least stuff you'd like to classify as suspicious and block or filter out. You can't always tell if it's a virus without feeding it to Outlook, especially if it relies on user interaction such as clicking an "Are you gullible?" link or doing some sort of Javascript mouseover trick, but you can still find most of the problems without running Outlook.
The backdoor network doesn't *need* to be a private network separate from the Internet, though that's potentially useful. At least in the US, most major ISPs are working on traffic prioritization, so you could get by with running your backdoor network as IPSEC tunnels with a higher priority (plus putting a few gateways in the major networks, since most of them don't have business plans for exchanging diffserv with each other.) Also, many ISPs run T1 ports on Cisco equipment that does Weighted Fair Queueing by default, so your IPSEC tunnels may get adequate treatment just because they're not TCP, and some ISPs are willing to give explicit prioritization to easily-identified traffic types on a custom basis even if it's not a standard service.
Many mathematicians drink black coffee or espresso, but having calcium-containing milk around does make it possible to have cappuccino if you're civilized or at least have white powder stuff to dilute vending-machine coffee if you're a traditional academic researcher.
Current QC lab experiments tend to involve liquid helium and various physics tricks that you're not going to fit into a silicon chip, and I'll leave you to make up the jokes about overclocked AMD chips and liquid helium.
But it doesn't really matter, because QCs are much more useful for specialized types of problems than for the types of gamer-box graphical rendering that uses up most of the world's CPU capacity today. Ray tracing wants the kind of parallelism that generates lots of output in parallel, and it's a good job for relatively conventional computing. QC produces small amounts of output extracted from a really large search space, such as finding the two 1000-bit prime factors of a 2000-bit number - once you've found the answer, the amount of work to verify that it's correct is very small, but finding it using conventional computers is roughly exponentially hard.
That doesn't mean that gamers won't find uses for the things if they become available, but you'd be using them to crack the security of the database that tracks where your buddy is and what equipment he's got, not to draw the pretty picture after you've made his armor vanish and fragged him.
Integer Factoring and Discrete Logarithm are the two useful math problems that Quantum Computers collapse from being roughly exponentially hard to easy polynomial, so if somebody develops a working QC that can handle a few thousand qubits instead of the current small problems, they'll be trashed.
Elliptic Curve problems aren't known to be solvable by QCs, but they're still new enough in cryptography that nobody trusts them quite as much as the RSA and DH - we'll have to see if a serious QC gets developed before the patents on some types of EC crypto run out:-)
Conventional symmetric crypto is also affected - the general estimate seems to be a square-root factor, which is equivalent to saying that the effective key length gets cut in half. So you need to use conventional crypto with longer keys, such as 256-bit AES instead of 128-bit, but the basic technology still works. So it's possible to use symmetric-key crypto for session encryption and go back to Kerberos and similar Key-Distribution-Center approaches to session key distribution.
I don't remember if there are Digital Signature methods that survive, other than secret-key approaches like HMACs, plus the ECC versions that are currently sitting in a box with Schroedinger's cat.
Quantum Encryption's only useful if you've got a direct fiber or line-of-sight optical connection to the other party, which is to say it's almost never practical. Also, it seems to need some conventional-crypto help to make it both untappable and also reliable. If you're going to do that, you might as well use conventional crypto - symmetric crypto with long enough keys isn't bothered by quantum computing, and if public-key algorithms become obsolete, you can fall back to either key-distribution-center systems like Kerberos or else to guys with briefcases handcuffed to their arms. Both of those methods are less convenient than public-key crypto, but they're no worse than installing dedicated fiber.
He didn't say that the $200/1000 CDs was covering the upfront costs of developing the CD - it appeared that he was talking about marginal costs for making more copies to give away. Sure, the costs of making the original CD can be a lot higher, especially if you're not doing it yourself or at least not funding it yourself.
But yeah, a number of my friends are in small bands that perform lots of gigs, sometimes paid, sometimes just for tips, and selling the CDs at the gigs is often what makes the money, and they're often the format that your friends use to tip you. If you're a medium-sized band that can get 500 people to get $10-20 concert tickets, cool, but if you're playing in bars and weddings or DJing at dances or playing at local music festivals with lots of other bands, the economics are a lot different.
The Grateful Dead (and similar bands like Jefferson Airplane) had a few early albums that went through the learning curve process on "what happens if you give a bunch of creative hippies artistic control, relatively unlimited budget, cool recording equipment to do creative things with, no clear deadlines, and access to lots of psychedelics". ("What do you mean, you're trying to record 'the sound of thick air'?") The record label folks had to learn how to get the bands to finish projects so they'd have something to ship, and the bands had to learn how the economics of record labels ripping off bands work, and in their cases they mostly figured out how to put out enough shippable product fast enough that there was something to sell to make up for the costs of the earlier work.
These days, equipment is so much better and cheaper, and bands can do stuff on a Mac in their garage that previously required highly expensive equipment which came with a bunch of record company engineers. Of course, that doesn't mean that the average band necessarily knows enough about engineering or music production to do it themselves, so they may want to hire specialists, but of course record companies have more expertise in making music that they think is commercially sellable than in music that expresses some artistic vision.
My company gave up on central mail storage for most users years ago. That's partly because we work in a laptop environment, so you need your mail to be portable, but it also makes it much easier for the IT department to manage mail storage space - if you're storing it on your laptop, how much you keep in your mailbox is your problem, while if you're storing it on their server, how much mail you keep is _their_ problem. Microsoft Outlook encourages people to send mail in whatever most bloated format is available (:-), and my work mailboxes are always an order of magnitude larger than my home Eudora mail, even after accounting for Powerpoint attachments. Sure, disk space is cheap these days, but redundant high-speed high-capacity disk space costs a lot more than cheap space on laptops (especially if your IT department's attitude about backups is that your laptop has a CD burner so you should do them yourself.)
I work in a laptop environment, usually from home, sometimes from customer locations or random places on the road. At home I have DSL and a VPN, so I'm connected to work, but webmail's pretty lame in that environment, especially since MS Exchange encourages people to send mail in bloated formats. I'd rather have the mail on my PC, except of course when it breaks. When I'm on the road, webmail is even less useful.
If you were down here in Silicon Valley, I'd recommend that you take a walk through Weird Stuff Warehouse and check out some of the Sun or SGI machines they've got; the web site has just a small fraction of what their shop floor has. Ten years ago this box was a $30,000 server; now it's a $49 doorstop. My first Vax 11/780 cost $400K, but you wouldn't want to get an N-refrigerator-sized machine or convert your garage to 3-phase power just to try it out (though I've got a friend with a Dec-20 in his garage:-)
Oh, but you were really talking about high-priced cameras. The high-end stuff usually does cost an order of magnitude more than the pretty good stuff when it first comes out, and if you're a professional photographer it may make sense to buy it. If you need whatever this year's version of really high resolution is, with really perfect optics, really good color definition, high speed, and able to plug in a wide range of professional-quality lenses and similar frobs, yeah, you could spend that kind of money. On the other hand, if you're going to post pictures on a web page, a $99 camera and Photoshop is probably overkill. My general preference is toward the $49 range, e.g. a camera that would be $29 with a couple of features fixed, like removable memory cards instead of built-in, and slightly better batteries and maybe a flash. But I mostly take pictures to remember travel and family get-togethers, and 1024x768 is more than I need.
Well, there's non-negative feedback and there's non-negative feedback. I remember back during the Internet boom a recruiter called me to check out a reference for somebody who'd been posting on a publicly archived cryptography mailing list I was also on that he said had a [begin sarcastic voice]Really Amazing [/sarc] resume, and I replied that it certainly sounded [sarc]Quite InnnnCredible [/sarc] to me, and after one or two more sentences back and forth about how somebody that young had so many years of experience and important discoveries, etc., we'd verified that yes, neither of us believed a word of it, and could get down to laughing about how bogusly inflated it was. (And that crowd did have people of similar age who really _were_ that bright, and also had people with amusingly bogus cover stories about their shady pasts, but this guy was in neither category.)
So if you've been extorted into providing non-negative feedback, you can always talk about how thrilled you were about the merchandise not actually being available and how exciting it was to wonder what charges were going to show up on your credit card bill this month and how happy you'd be about the merchandise if what you ordered actually ever showed up....
The shorter HTML version mainly talks about attacks on the voice eavesdropping parts, while the Longer PDF paper for IEEE has even more technical detail and talks about attacks on dialed-number-recording Pen Registers and CallerID, which the Feds and Local Police are able to wiretap without the same level of court order that a voice wiretap requires. (I've done the NYUD-automatic-caching versions of the URLs, rather than the raw URL, to protect against Slashdotting.)
Basically, there's a fairly high proportion of the wiretapping gear that's actually deployed is vulnerable, in spite of what the police PR folks say, and it's much easier to hack the pen-register technology (though probably impossible to prevent the phone company from giving a direct billing database feed to the Feds, which you probably can't hack.)
It's not a backdoor, it's a design feature that's being phreaked. Analog Wiretaps can't use the phone switch standard signalling method to detect whether a phone's on-hook or off-hook, because they're patched around the switch, so the equipment transmits a tone whenever the phone's on-hook to tell the recorder not to bother recording. And because it's running on phone-quality wire, it's an in-band tone, usually one of the extra four Touch-Tone tones, which means that the phone's user can send the tone themselves to tell the wiretapper's recorder that they're not there. The recorder _could_ have been built to do voice detection, but it's an old design and this is a cheaper and dumber way to implement it.
But wiretappers don't just record voice, they record dialed numbers and caller-id. The other set of flaws, which you can read about in the longer PDF paper, depend on the fact that DTMF detectors are usually analog devices with a certain amount of sensitivity, and in general the phone switch and the wiretapper's equipment won't be the same. So you can find out how far off to bend your touchtones and have the phone switch still listen to you, and then you can send touchtones in-spec or out-of-spec to confuse the wiretapper's equipment, which can't tell whether the phone switch is or is not listening to the numbers you can dial. If it's more sensitive than the phone switch, you can send bogus digits that the wiretapper will record and the phone switch will ignore - but if it's less sensitive, and you're sending your digits just at the edge of the phone switch's range, the wiretapper won't see them.
You can play similar games with CallerID, giving the wiretapper lots of entertaining stuff to listen to when you're not on the phone.
For me the most important features in an IM client are a tradeoff between
Open Standard Protocols that aren't locked into any specific client or implementation or ISP, and include whatever features happen to be important to what I'm doing (e.g. encryption on messages, file transfers, integration with other applications so my outdoor thermometer can IM my PC weatherbot or whatever.) The big players here have been Jabber and IRC, and SIP is emerging because it's the market direction for VOIP protocols (and VOIP is really just a Presense Server plus a specific set of Media Connections, just as IM is) and because it supports Proxy servers so you can connect different SIP systems together in various ways and build cool interconnections between phones, PCs, and other widgets.
User communities that include the people I want to talk to - Primarily this means "It reaches my coworkers, so I can have an IM conversation while I'm on a long phone call." For this, I'd prefer if the communities I care about used open standards, but it's more important that everybody's on the same presence server and there's some integration with the corporate phone/HR database so you can look up people easily. My current work IM environment has been Jabber-based, but we've just gotten some new system with Shiny Friendly Icons and Couch-Potato Non-technical-User documentation and no real information about it; perhaps if everybody switches to it it'll actually be useful.
They're fairly orthogonal goals (:-) Some people deal with this by using multiple-protocol-multiple-server Swiss-Army-Knife IM clients, but for the most part I'd rather not have IM from random people or my AOL-using mother-in-law, so if that means that I'm using one client on my work PC to talk to coworkers and another client on my home PC to talk to my toaster, that's ok.
Yeah, obviously we wear sunglasses when we're sitting in the basement staring at the computer.... The last year or so I've had to start wearing reading glasses while working on the computer, and most of the time if I'm wearing sunglasses, I'm in my car, which has a much better sound system than they can cram in a pair of glasses.
Slashdot Mirror
Some of the original motivations for end-users getting their own address space have gone away - DHCP means the cost of readdressing computers has gone to nearly zero, especially for desktop machines, and DNS means that you really _can_ move a server, though you might need a week or two of overlap on the address space for everybody's caches to time out (and IPv6 might force you to do some kind of tunneling deal with your old ISP), and firewalls mean that you might not by exposing most of your IP devices to the outside world anyway, just your public servers.
But even that doesn't mean that routing becomes much simpler, because that's only useful if you can aggregate - for instance, you could get /48 of provider-assigned address space from ISP1, and advertise that space on your connection to ISP2, so the global routing tables still have two entries for you even though they're assigned somewhat more cleanly. And aggregation doesn't always work well for geographically dispersed end-user customers - it's one thing for a university to aggregate the addresses from a bunch of buildings that are all in the same city, but if you've got a retail store chain with a thousand stores, should they all be part of one /48 at headquarters and route their external traffic there through IPSEC tunnels, or should each branch get provider-assigned address space from whatever ISP is nearby and try to tie that mess together, or some hybrid of both? For performance reasons, especially with VOIP, you'd like to keep latency down, so it's better to keep traffic in the same half-continent or so if you can, but it's not clear that there's an obvious answer.
IPv6 was supposed to free us from the evils of NAT. But the easiest ways to do multihoming either get into the swamp scalability problems or else do some kind of NAT or tunnel things to let you advertise one set of address space from two ISPs. Maybe that's not such a huge problem?
There are conditions when it makes sense to provide /64s to smaller customers - I wouldn't be surprised to see home broadband service assigned that way, since that lets the ISP's /32 support four billion customers, each of whom can support 64K LANs each with host addresses assigned based on the 48-bit MAC address. Whether small-business-office customers get /64 or bigger remains to be seen - a typical standalone office really doesn't need a /48, but the politics of address space assignment may encourage ISPs to do it anyway. On the other hand, a gas station clearly doesn't need more than a /64.
But upgrading custom software is a much different scale of project than simply upgrading boxes and reconfiguring some web servers. There's a huge amount of mission-critical big nasty badly-documented stuff out there running on mainframes, PCs, and Unix boxes of various sorts that knows about IPv4 and might or might not know about DNS and DHCP. Finding all of it isn't quite the same level of effort as finding Y2K bugs, but it's still a huge hard-to-estimate job.
But there's also a lot of custom server applications that would need to be rewritten to support IPv6 (not even counting the stuff that needs to be rewritten to support IPv4 instead of SNA, or to use DNS instead of hard-coded IP addresses :-). Most of it can be kept going by hiding it behind 6to4 gateways of various sorts, so you'd end up with a lot of 10.x IPv4 islands connected to the rest of the world by IPv6, and optionally tunneled with each other, somewhat the way a lot of the SNA stuff is really running as emulations and tunnel servers on top of IPv4 these days.
On the other hand, the folks who brought us Y2K consulting would all like their piece of the pie as well. Much of Halliburton's work in Iraq could be done by other people if they had the same political connections, but there are some parts of the oil business that Halliburton are not only the best at what they do, they're almost the only people capable of doing it, and only Schlumberger are close.
But there are hard problems and easy problems
Zach is quite correct that it's about money - if you do a Google search for "rolex watches", for instance, the first five or so entries (other than the advertising section) appear to be legitimate, and the rest appear to be various sites put together by scammers who are trying to SEO themselves into the highest ranking by writing inane content and playing link games. (Fortunately, I don't want to buy such an ungeeky watch, but I do often want to find out technical information about various medicines, and that often gets swamped by SEO-spammer medicine stores. Bad enough that it's hard to find articles on how drug X interacts with drug Y, because even the legitimate sites will have indexes on their pages pointing to their articles about drugs A-Z, but if either drug is something that's heavily promoted for sale on the web, that increases the probability of your search drowning in spam.)
But the SEOs who do most of the promotion about the SEO business are really the black-hats, building link farms and similer techniques to lie to the robots, making them think your boring pages are interesting to humans, so the robots will lie to the humans who want to find interesting pages. It's dishonest, and it screws up the value of search engines for the users, and good luck to Google in finding them and stopping them.
- making the content more interesting to humans
- making it easier for robots to find your content, or
- lying to the robots so they'll tell the humans that your uninteresting page is interesting. This is how most SEOs promise to raise your ranking.
TFA was mostly about how to make your content interesting, though to some extent that was "make it interesting to people so they link to your pages", but that's at least halfway fair. And it was also mostly about how to make your pages accessible to the robots, which is good advice, and many SEOs pretend that that's what they're really telling you how to do. But when TFA was talking about whether to work with a pro, it was somewhat friendly to the kinds of unethical SEO scum who lie to robots by building link farms and similar abuse, though it did mostly emphasize working with people about your content.What really irks me about SEO stuff? It's when I'm looking for medical information on the web, and get zillions of robo-generated links that are pointing to sites that sell medicines, drowning out the sites that have really good information. Sure, sometimes you'll see the government websites first, but they're mostly the NIH ones with advice about dosage and insisting you follow your doctor's orders and what not to take along with that drug, not the more interesting ones about how the drugs work and what advantages or disadvantages they have compared to other drugs.
A.C. commented that it's probably because of the diuretic effects of caffeine making you drink more liquids, which was also my first guess. However, it could equally well be incorrect - caffeine tends to dehydrate you more than the liquid in the coffee or tea replenishes, so unless you're careful to make up for it with water or other non-alcoholic non-caffeinated drinks, you mostly tend to have less water in your system.
If you're paying extra for inside-wire coverage, which here in California PacBell territory is something like 85 cents a month, it's a different deal. A few years ago, during the rainy season, my phone line suddenly got really really noisy, and they found that it was a problem in the walls somewhere between two of the bedrooms. They didn't have the quality of electrician working for them to actually fix the problem (:-), but they at least isolated it and disconnected the bad section from the rest of the house, and I stuck a cordless phone in the isolated bedroom. (Really fixing it would require lots of carpentry or else external wire, which they charge real by-the-hour rates for, and I'd have had to move all my junk out of the junk-storage bedroom where the problem was.)
Back when there were competing local-access providers, somebody cross-connected my PacBell line with my neighbor's MCI line. Took forever to get it fixed, because MCI wouldn't talk to me (I wasn't their customer), and PacBell thought the line was working (electrically fine connection to nothing.) Eventually PacBell came and fixed it. We think the problem was really caused by the subcontractor installing Sprint local service in another neighbor's unit.
Viruses on networks infect their victims by sending messages to (or back and forth with) their victims. You don't have to run the victim program to receive or detect the virus - you just have to accept and send the right messages, and then you need to distinguish between messages that are viruses and other kinds of messages (e.g. spam), and for a honeypot network you also need to communicate with your friends on a network that doesn't get flooded out by the virus, so a backdoor network can be helpful. For a honeypot network, you normally won't have any legitimate traffic on the Internet side, so all the packets you receive are either viruses or other malicious traffic, so your risks of false positives are somewhat reduced.
Most network viruses work in one of three ways
The backdoor network doesn't *need* to be a private network separate from the Internet, though that's potentially useful. At least in the US, most major ISPs are working on traffic prioritization, so you could get by with running your backdoor network as IPSEC tunnels with a higher priority (plus putting a few gateways in the major networks, since most of them don't have business plans for exchanging diffserv with each other.) Also, many ISPs run T1 ports on Cisco equipment that does Weighted Fair Queueing by default, so your IPSEC tunnels may get adequate treatment just because they're not TCP, and some ISPs are willing to give explicit prioritization to easily-identified traffic types on a custom basis even if it's not a standard service.
Many mathematicians drink black coffee or espresso, but having calcium-containing milk around does make it possible to have cappuccino if you're civilized or at least have white powder stuff to dilute vending-machine coffee if you're a traditional academic researcher.
But it doesn't really matter, because QCs are much more useful for specialized types of problems than for the types of gamer-box graphical rendering that uses up most of the world's CPU capacity today. Ray tracing wants the kind of parallelism that generates lots of output in parallel, and it's a good job for relatively conventional computing. QC produces small amounts of output extracted from a really large search space, such as finding the two 1000-bit prime factors of a 2000-bit number - once you've found the answer, the amount of work to verify that it's correct is very small, but finding it using conventional computers is roughly exponentially hard.
That doesn't mean that gamers won't find uses for the things if they become available, but you'd be using them to crack the security of the database that tracks where your buddy is and what equipment he's got, not to draw the pretty picture after you've made his armor vanish and fragged him.
Elliptic Curve problems aren't known to be solvable by QCs, but they're still new enough in cryptography that nobody trusts them quite as much as the RSA and DH - we'll have to see if a serious QC gets developed before the patents on some types of EC crypto run out :-)
Conventional symmetric crypto is also affected - the general estimate seems to be a square-root factor, which is equivalent to saying that the effective key length gets cut in half. So you need to use conventional crypto with longer keys, such as 256-bit AES instead of 128-bit, but the basic technology still works. So it's possible to use symmetric-key crypto for session encryption and go back to Kerberos and similar Key-Distribution-Center approaches to session key distribution.
I don't remember if there are Digital Signature methods that survive, other than secret-key approaches like HMACs, plus the ECC versions that are currently sitting in a box with Schroedinger's cat.
Quantum Encryption's only useful if you've got a direct fiber or line-of-sight optical connection to the other party, which is to say it's almost never practical. Also, it seems to need some conventional-crypto help to make it both untappable and also reliable. If you're going to do that, you might as well use conventional crypto - symmetric crypto with long enough keys isn't bothered by quantum computing, and if public-key algorithms become obsolete, you can fall back to either key-distribution-center systems like Kerberos or else to guys with briefcases handcuffed to their arms. Both of those methods are less convenient than public-key crypto, but they're no worse than installing dedicated fiber.
But yeah, a number of my friends are in small bands that perform lots of gigs, sometimes paid, sometimes just for tips, and selling the CDs at the gigs is often what makes the money, and they're often the format that your friends use to tip you. If you're a medium-sized band that can get 500 people to get $10-20 concert tickets, cool, but if you're playing in bars and weddings or DJing at dances or playing at local music festivals with lots of other bands, the economics are a lot different.
The Grateful Dead (and similar bands like Jefferson Airplane) had a few early albums that went through the learning curve process on "what happens if you give a bunch of creative hippies artistic control, relatively unlimited budget, cool recording equipment to do creative things with, no clear deadlines, and access to lots of psychedelics". ("What do you mean, you're trying to record 'the sound of thick air'?") The record label folks had to learn how to get the bands to finish projects so they'd have something to ship, and the bands had to learn how the economics of record labels ripping off bands work, and in their cases they mostly figured out how to put out enough shippable product fast enough that there was something to sell to make up for the costs of the earlier work.
These days, equipment is so much better and cheaper, and bands can do stuff on a Mac in their garage that previously required highly expensive equipment which came with a bunch of record company engineers. Of course, that doesn't mean that the average band necessarily knows enough about engineering or music production to do it themselves, so they may want to hire specialists, but of course record companies have more expertise in making music that they think is commercially sellable than in music that expresses some artistic vision.
My company gave up on central mail storage for most users years ago. That's partly because we work in a laptop environment, so you need your mail to be portable, but it also makes it much easier for the IT department to manage mail storage space - if you're storing it on your laptop, how much you keep in your mailbox is your problem, while if you're storing it on their server, how much mail you keep is _their_ problem. Microsoft Outlook encourages people to send mail in whatever most bloated format is available (:-), and my work mailboxes are always an order of magnitude larger than my home Eudora mail, even after accounting for Powerpoint attachments. Sure, disk space is cheap these days, but redundant high-speed high-capacity disk space costs a lot more than cheap space on laptops (especially if your IT department's attitude about backups is that your laptop has a CD burner so you should do them yourself.)
I work in a laptop environment, usually from home, sometimes from customer locations or random places on the road. At home I have DSL and a VPN, so I'm connected to work, but webmail's pretty lame in that environment, especially since MS Exchange encourages people to send mail in bloated formats. I'd rather have the mail on my PC, except of course when it breaks. When I'm on the road, webmail is even less useful.
Oh, but you were really talking about high-priced cameras. The high-end stuff usually does cost an order of magnitude more than the pretty good stuff when it first comes out, and if you're a professional photographer it may make sense to buy it. If you need whatever this year's version of really high resolution is, with really perfect optics, really good color definition, high speed, and able to plug in a wide range of professional-quality lenses and similar frobs, yeah, you could spend that kind of money. On the other hand, if you're going to post pictures on a web page, a $99 camera and Photoshop is probably overkill. My general preference is toward the $49 range, e.g. a camera that would be $29 with a couple of features fixed, like removable memory cards instead of built-in, and slightly better batteries and maybe a flash. But I mostly take pictures to remember travel and family get-togethers, and 1024x768 is more than I need.
So if you've been extorted into providing non-negative feedback, you can always talk about how thrilled you were about the merchandise not actually being available and how exciting it was to wonder what charges were going to show up on your credit card bill this month and how happy you'd be about the merchandise if what you ordered actually ever showed up....
Basically, there's a fairly high proportion of the wiretapping gear that's actually deployed is vulnerable, in spite of what the police PR folks say, and it's much easier to hack the pen-register technology (though probably impossible to prevent the phone company from giving a direct billing database feed to the Feds, which you probably can't hack.)
But wiretappers don't just record voice, they record dialed numbers and caller-id. The other set of flaws, which you can read about in the longer PDF paper, depend on the fact that DTMF detectors are usually analog devices with a certain amount of sensitivity, and in general the phone switch and the wiretapper's equipment won't be the same. So you can find out how far off to bend your touchtones and have the phone switch still listen to you, and then you can send touchtones in-spec or out-of-spec to confuse the wiretapper's equipment, which can't tell whether the phone switch is or is not listening to the numbers you can dial. If it's more sensitive than the phone switch, you can send bogus digits that the wiretapper will record and the phone switch will ignore - but if it's less sensitive, and you're sending your digits just at the edge of the phone switch's range, the wiretapper won't see them.
You can play similar games with CallerID, giving the wiretapper lots of entertaining stuff to listen to when you're not on the phone.
- Open Standard Protocols that aren't locked into any specific client or implementation or ISP, and include whatever features happen to be important to what I'm doing (e.g. encryption on messages, file transfers, integration with other applications so my outdoor thermometer can IM my PC weatherbot or whatever.) The big players here have been Jabber and IRC, and SIP is emerging because it's the market direction for VOIP protocols (and VOIP is really just a Presense Server plus a specific set of Media Connections, just as IM is) and because it supports Proxy servers so you can connect different SIP systems together in various ways and build cool interconnections between phones, PCs, and other widgets.
- User communities that include the people I want to talk to - Primarily this means "It reaches my coworkers, so I can have an IM conversation while I'm on a long phone call." For this, I'd prefer if the communities I care about used open standards, but it's more important that everybody's on the same presence server and there's some integration with the corporate phone/HR database so you can look up people easily. My current work IM environment has been Jabber-based, but we've just gotten some new system with Shiny Friendly Icons and Couch-Potato Non-technical-User documentation and no real information about it; perhaps if everybody switches to it it'll actually be useful.
They're fairly orthogonal goals (:-) Some people deal with this by using multiple-protocol-multiple-server Swiss-Army-Knife IM clients, but for the most part I'd rather not have IM from random people or my AOL-using mother-in-law, so if that means that I'm using one client on my work PC to talk to coworkers and another client on my home PC to talk to my toaster, that's ok.Yeah, obviously we wear sunglasses when we're sitting in the basement staring at the computer.... The last year or so I've had to start wearing reading glasses while working on the computer, and most of the time if I'm wearing sunglasses, I'm in my car, which has a much better sound system than they can cram in a pair of glasses.