If you wanted to do something useful with abandoned homes, you could use them to house people who are losing theirs.
You can get houses either for free or for ridiculously low prices in places like Detroit and Flint. People still aren't moving there. There's no work -- you can get a house for free, but what do you do for electricity and heat and food?
You wouldn't be doing people who've gotten foreclosed on any favors by encouraging them to move to Flint or Detroit. You wouldn't do those cities any favors either; they're cash-strapped enough as it is, providing services to the people who live there, without adding more residents.
People have been trying for years to figure out what to do with the surplus housing in the rust belt and former industrial cities. It's a losing battle, and it's time to admit that nobody wants to live in these cities the way they are now, and work on making them places people want to move to by choice, not just because they have nowhere else to go.
Uh, people don't seem to be exactly chomping at the bit to "redevelop" these areas. If they were, I'm sure Flint or Detroit would love to hear from them. Real estate investment, especially commercial RE, isn't exactly a hot area right now, perhaps you've noticed.
They're demolishing them because nobody wants to live there, nobody wants to redevelop them, and the buildings are hazardous.
They would much prefer "demolish and redevelop" I'm sure, but they're going for "demolish, wait a generation or two, maybe hopefully redevelop," precisely because Plan A hasn't worked.
Part of the point of this is to raise population densities. Right now you have huge tracts of abandoned buildings, with people living here and there among them. It's a huge drain on public resources (providing police and, especially, fire protection to all the abandoned buildings), and doesn't really foster healthy communities.
Most of the plans that I've seen, including the one in Flint, involve buying up abandoned properties and demolishing them, while simultaneously restoring ones in better areas and encouraging people to move from blighted areas into them. The result is condensing the remaining residents of the city into a smaller, more densely-populated area. More public services in a smaller area, better public transportation, etc.
They're not trying to chase people out of the cities and into the suburbs or exurbs, quite the opposite. Most of the areas they're trying to get rid of were the original suburbs, and what they are trying to achieve is a rebuilding of the urban core.
Yeah, it would be great to get people to move in from the suburbs and fill in the high-density rowhousing in places like Baltimore, but that's just not going to happen. Nobody wants to live there, not given the way the areas are now. And those areas aren't going to get better. What's needed is a "rebooting" of cities -- get people back into the core areas, demolish some of the older urban/suburban transitional areas, and show that cities actually work. When people out in the 'burbs see that a city can be a nice place to live again, and not just a ghetto for people who have nowhere else to go, then it'll be time for new construction. (But this time, build mixed-use and actually plan the growth, rather than just letting stuff grow and create huge tracts of transportation-dependent, single-use housing, miles away from commercial or industrial areas.)
This is the first step towards making cities desirable again.
> It makes one wonder what the city would be like if it ended up being completely abandoned, sort of like Rome after the fall of the empire.
This isn't really true; Rome was never completely abandoned. The population just shrank dramatically as the infrastructure broke down. People moved out when the water stopped flowing and sewage stopped being washed away, or when there started to be outbreaks of plague or other diseases. But some people stayed.
So Detroit is a lot closer to Rome already than I think you imagine.
No reason you can't save the historical sites while demolishing the rest of the neighborhood. If there's a significant building, build a park around it. It'll be in the middle of the wilderness, but that'll just make it all the more interesting.
I suspect people will be a lot more likely to pay attention to historic sites when they're not in the middle of a boarded-up section of town, and it might be better for the buildings in the long run, since they're less likely to be destroyed in a fire. (Wildfires would be a problem, admittedly.)
I don't think that historical preservation and getting rid of hazardous, blighted buildings are mutually exclusive. You just need to achieve some sort of balance. Not every old rowhouse is really "historic," and not every building needs to come down just because it's in a crappy neighborhood and has some peeling paint. A few significant buildings here and there can stay, and won't impact wildlife if they're managed correctly.
Just to clarify the bit about the addresses, because I forgot a couple of sections...
The whole IPv6 address is 128 bits, but in a unicast address, the first 3 are the "prefix identifier," basically saying that this is unicast. Then you have a 13 bit "TLD Identifier" and 8 reserved bits, completing the global prefix portion.
But then you have a 24 bit "NLA ID", which might specify an ISP or some other intermediate network. This provides for traffic aggregation, and they get assigned (I guess) by the national registries. This brings you to 48 bits. Exactly how they'll choose to distribute the NLA IDs, and how many each organization/ISP will get, I'm not quite clear on. I've heard some people allude to ISPs getting large blocks at this level and putting a "subscriber ID" or "customer ID" in this region, leaving 80 bits free per customer, but I don't think this is really the case.
After the NLA is a "SLA ID", which is like a very big subnet identifier. It's 16 bits long, bringing you to 64 for the address so far. This is what I think individual home routers will get from ISPs, assuming the NLA IDs get given out with enough granularity so that there isn't competition.
Beyond the SLA ID is 64 bits for the "interface ID," which a host can pretty much define however it wants. In most applications this can be easily created by padding out the Ethernet MAC, although it can also be generated randomly if that's not desired.
The decision to use hex quad notation to represent IPv6 isn't really that important from a technical perspective. It's important in the short run that IPv6 addresses look different from IPv4s, to distinguish one from the other. However, in the long run it's quite possible to use an IPv4-type notation scheme with v6.
IPv6 addresses will in most instances consist of two components, one which will typically come down from an ISP (the "global prefix" is the proper name, IIRC) and consists of 24 bits, followed by a subnet identifier (8 bits), and then an interface identifier (32 bits).
In most cases where a user is calling their ISP for help, the global prefix will already be known by the tech on the line. It's not necessary for the user to report it. So, if IPv6 addresses become an unbearable burden (which I really don't think they are; people are well-trained to read seemingly meaningless numbers over the phone to tech support), you could quite easily adjust user-facing software to display the subnet and interface identifier in a friendly, IPv4-style form. In this form, the subnet+interface address would look just like an IPv4 address with one extra group of octal digits.
Frankly, I don't really anticipate many reasons for users to need to communicate their IP addresses to tech support once IPv6 becomes the norm. You used to get that a lot because automatic address assignment was a bolt-on to IPv4 and often didn't work right; with IPv6 it's the idea from the very beginning. Plus, IPv6 does a much better job of handling multicast and broadcast traffic, which means you can have automatic service discovery and automatic machine discovery without broadcast storms and all the other issues that have plagued attempts at such systems on IPv4.
So instead of going to flickr I have to know and maintain all of my friends' computer addresses? In what, an address book that I store on my computer? What if I'm at a friend's house and want to show them another friend's picture, but they don't know the address?
That's no harder than knowing his username on Flickr, or the URL of his photostream. You already need to know some piece of information to be able to find his photos on the web; it doesn't matter (from the perspective of the person viewing the photos) whether that URL points to Yahoo's servers or one in his house. You'll probably get it via email or IM and click on it either way.
> I would prefer an addressing system that simplifies life for me.
IPv6 probably will, by virtue -- ironically -- of having more complex addresses. Since you can't reasonably expect people to remember a 128-bit value, even when expressed in hex (hell even if you used Base-64), there will be a far greater reliance on automatic addressing schemes under IPv6 than under IPv4. That's a good thing; Appleshare had the right idea in 1984, and the adoption of IP was a step backwards in this regard (although IP is superior in just about every other way, don't get me wrong, and Appleshare wouldn't have scaled like IP). The length of the IP address shouldn't matter, because the user should never encounter them anyway. With IPv4, doing this automatically was optional because manual addressing was, although inconvenient, admittedly practical. With IPv6 it won't be except in real edge cases, and we'll finally be able to start ignoring IP addresses the same way we basically ignore Ethernet MACs. (Quick! What's your Ethernet MAC? You don't know, more than likely, and it doesn't matter at all. That's how IP should be as well.)
And unlike IPv4, those addresses will be end-to-end routable, which means a lot less fussing around with port forwarding. Plus, the huge number of addresses ought to get rid of dynamic addressing completely, at least the sort of addresses that change themselves automatically from time to time when you disconnect and reconnect. (The addresses will still be "dynamic" in the sense that they're comprised of some part handed down from upstream and some part that's specific to the device, but they won't need to be doled out from some small pool with short leases.) That means no more dyndns.org and abnormally short TTLs to get a usable DNS.
VoIP will be far simpler as well. VoIP over IPv4 is a total pain in the ass, and there are a lot of ugly hacks (STUN, I'm looking at you) in order to try and make it work. In many cases, consumer VoIP equipment tries to avoid the whole mess by forcing you to attach it directly to your WAN uplink, ahead of your router -- which can often be nowhere near where you want it, either in terms of physical location or network topology. The hope of VoIP that comes closer to "just working" in the same way that POTS does would be enough to sell me on IPv6, long addresses be damned.
Are we supposed to be shocked and horrified by that or something? If so, it's not working.
It seems like a perfectly reasonable solution to me. They're not taking inhabited property by eminent domain, instead they're targeting abandoned houses and demolishing them to create open space. Net result is fewer abandoned buildings -- which are a safety hazard, and create lots of extra work for fire and police departments -- more open space, and healthier communities in the nicer sections of town instead of a few people spread out and squatting amongst the ruins.
The only people who should be appalled by this are American exceptionalist, growth uber alles neo-"conservatives." In other words, morons.
"Negative growth" is something we're going to have to start dealing with in a lot of places in the near future, and as a society in general within a generation. The United States managed to get very high on the hog by growing continuously throughout the 20th century, which is getting increasingly unsustainable and simply cannot continue. The 20th century (arguably the 19th as well) as experienced in the US was very probably a singular event, built on cheap energy, rapid population growth, industrialization, and coming out on the winning side of two World Wars. The party is over.
We need to look forward, and unflinchingly and without nostalgia analyze what's likely to work in the future and what isn't. Trying to force some sort of return to the "good old days" is doomed. The things that aren't going to work need to die. That means industries that aren't profitable need to be wound down, rotting, unwanted houses need to be bulldozed, and government programs that depend on or assume never-ending growth to function need to stop.
I am glad to see that Flint is at least making some attempt to move forward, rather than sit and wait for some sort of salvation that's plainly not going to come, as other cities seem hell-bent on doing. I have some minor issues with the way it sounds like they're doing things -- my geo-libertarian sensibilities would be less offended by an "abandoned buildings tax" that attempted to stick owners of vacant structures with the costs they're externalizing on the community, than any use of eminent domain -- but these are issues of implementation rather than overall intent.
I agree that document management is the way to go, but I would just point out in their defense that they're not just exclusively "big corporation" products anymore.
All my knowledge is FileNet-centric, but at least with FN you can stand up a system quite easily; it's not a huge investment for what you get. I've seen deployments done for small and medium-size businesses (and relatively small departments within large companies) that justified the cost pretty easily in terms of not losing or having documents accidentally deleted, and being able to guarantee compliance and conformance to a backup strategy.
Versioning is also a big plus. You can let people edit documents without worrying that they're going to wipe out anyone else's work -- if you don't like their changes, just grab the previous version instead. Most places I've seen introduce most of their file-share complexity because they try to basically do version control in a non-versioning filesystem using file names, and everyone does it a bit differently. Total mess. Much better to do it the right way and use some sort of version control system or ECM product from the beginning, rather than try to use bare-filesystem share drives until they're totally unmanageable and then migrate.
I have a personal bias, but I think IBM's FileNet would solve this quite neatly. I've done implementations of it that are pretty much exactly what the OP describes.
Customer has a share that's gotten totally out of control, just stuffed full of files. They want to make them available across multiple offices, generally without getting into complex VPN crap, and also want to simplify management, add more security / compartmentalization, or integrate it with corporate SSI. All doable. Runs on your choice of platforms, too. (Linux, Unix/AIX, Windows all OK as servers.)
There are even tools that basically take a share drive and walk the directory structure, importing documents at extremely high volume and using the folder structure to categorize and tag the documents within FileNet. It's quite slick and can either be used as a one-shot migration from a traditional fileserver to FileNet, or as an ongoing thing (take all files in a particular directory or set of directories and commit them).
Once you have the documents into FileNet you can access them over a web interface or via various desktop clients, and there is a nice API for integrating it with custom in-house applications if that's a requirement. Also, IBM makes some add-ons for Word and Excel (and maybe PowerPoint) that allow you to work directly with items stored in a FileNet repository. Plus, if down the road you want to get into "workflow" (basically building your document management system around your business process), that can be easily bolted on.
Email is in profile if you want specific case studies or whitepapers, or if you want me to put you in touch with people who do these sorts of things regularly.
I am not a big fan of OpenDNS either. Rather than use L3's or Verizon's servers (4.1.1.1 and 4.2.2.2 sets respectively, I think), you might want to try the Open Root Server Confederation's. They are what OpenDNS purports to be; an actual grassroots effort to provide an alternative DNS, without the sleazy failed-lookup pages or obvious profit motive of OpenDNS. There are some TLDs in the ORSC root zone that don't exist in the traditional ICANN one, but you can just ignore them unless you want to take part.
Their top-level servers are listed here. You can also run `dig . ns @ns1.vrx.net` for a more up-to-date list; when I run that I get the following:
a.root-servers.orsc. 172800 IN A 199.166.24.1 c.root-servers.orsc. 172800 IN A 199.166.26.200 f.root-servers.orsc. 172800 IN A 199.166.31.3 i.root-servers.orsc. 172800 IN A 199.166.26.51
I think their intention is that people will put the root file into their local caching nameserver rather than hitting one of their top-level servers with each request (unlike OpenDNS), but there's no actual discouragement of the latter practice and I assume it's considered acceptable for laptops and other portable machines.
The only way I can imagine they'd profit from this is by blocking access to alternative DNS servers like OpenDNS, or even just putting in well-known public DNS servers like 4.2.2.2, so that they can intercept unknown requests and return ad-laden pages instead. Basically typosquatting.
Various ISPs have gone down this road before. (Rogers Cable has tried, and so has Road Runner.) Unfortunately -- for the shady ISPs, anyway -- it's easy for annoyed users to get around these schemes; they can just configure their computer or NATing router to use a different DNS server besides the one supplied by the ISP via DHCP.
By transparently redirecting all DNS requests to their own servers, Comcast would eliminate this method of circumventing their advertising. They could also block sites at the DNS level much more easily than before.
A lot of censorship schemes (ab)use DNS in order to return a bogus result to a query; these schemes aren't very good, though, because any user with two brain cells to rub together and the tiniest bit of motivation can change their DNS configuration to use clean servers instead. By doing transparent redirection, you prevent this.
Those strike me as the two obvious reasons. The profit-motivated one (squatting on failed DNS queries) is annoying and causes many non-web applications to fail or behave improperly, but it's not nearly as bad as the censorship-motivated one is. However, the same technique that makes failed-lookup ads harder to avoid could easily be used as part of a censorship scheme if demanded by the government. It's important that even casual Internet users (who may not really care about returning a "page not found" web page instead of the normal browser message) understand why letting their ISP monkey with DNS lookups is a Really Bad Idea.
In both cases you can get around the hijacking by using a VPN and forcing DNS queries though it, but that's significantly harder than changing from automatically-assigned DNS servers to well-known ones like OpenDNS's or Verisign's.
I just ran the ICSI test from a host on Comcast's network in the Metro DC area (inside the 69.255.0.0/16 space) and port 53 was not redirected according to the results.
No blocks to anything else, although I have periodically experienced blocks on the common SIP negotiation ports (5060, 5061, etc.) that stop my VoIP from working until I change the port in use. I'm not sure what that's all about, and whether it's malice or just some sort of incompetent rate-limiting thing on Comcast's part.
They might have technical chops or they might just be taking advantage of a disgruntled employee or other low-tech hole; it's impossible to say so far. What's clear is that they obviously had no idea what to do with the data once they got their hands on it.
I mean, did they really think they could just grab a dump of T-Mobile's customer database and sell it to AT&T? C'mon. Let's think about that for a minute -- what the hell is AT&T going to do with it? I'm sure their marketing department knows all about T-Mobile's demographics versus their own, and if not (and if they care) they could find out with a few calls and some relatively small payments to a research firm. Same with just about anything else I can possibly imagine them extracting from T-Mobile's servers. If AT&T or Verizon is really dying to know something about T-Mobile's operations, they have lots of easier ways to figure it out that involve a lot less risk than buying red-hot DB dumps from criminals.
Also, anyone with half a brain ought to realize that all the telco companies live in fear of being broken into, and that a major breakin is going to hurt the public's perception of the entire industry. The U.S. cellular telcos are, basically, a cartel: and if there's one thing cartel members hate more than each other, it's disruptive outsiders. T-Mobile's competitors probably didn't respond because they thought it was a joke, or some sort of Nigeria scam; if they'd known it was serious, they almost certainly would have done what Pepsi did and called the cops. Not for altruistic reasons, but for sound business ones: having basically mercenary criminals screwing around, stealing data, scaring customers, and generally upsetting the normal business environment is not to any legitimate player's advantage.
The other red-flag that screams amateur hour about the whole thing is what they did after being turned down by the "competitors" -- they posted what amounts to a "for sale" ad to the Full Disclosure list. They thought that was the best venue for selling a shitload of customer financial records? Really? There are bulletin boards, whole online communities, where criminals trade identity information. It's a mature underground economy; the information they had -- names, addresses, CC numbers, SSNs -- would have been a fungible, commodity product, well-understood and easy to resell for cash.
However they got the information in the first place, it's pretty clear they didn't think their cunning plan all the way through.)
One simple way would be to come out with more 'classic' releases - selling reprints of older game titles for a fraction of their original cost, but still pure profit for the manufacturers at this point. Pressing discs isn't that much.
Bingo. And that they're not doing that is what convinces me they're not really interested in giving customers a good value proposition; they're just bitching that someone is preventing them from screwing customers as hard as they'd like to.
If they sold "classic" (anything that's not the new hotness) games in different packaging for the price of used, who would buy used? They could take the wind out of Gamestop's sales right there.
Lots of companies spend giant piles of money trying to figure out what customers want so that they can try to deliver it. In this case, it's blatantly obvious what customers want -- a slightly cheaper game -- and it's even obvious exactly what price they're willing to pay. Gamestop has done all the market research for them. If they want to make money, it's on the table for them to take. If they don't, they can let Gamestop take it.
That hourly rate neglects risk. Not all games are created equal. There's a certain risk that you're going to get a game, open it up, start to play it, and realize it sucks.
If you realize a $60 game sucks, you're out $60, or at least ($60 - (resale value)). If you've only paid $10, that's the most you risk losing.
Consumers are understandably wary of plunking down more than a couple of bucks unless they're very sure they're going to like the game. This is why it's a lot easier to gain traction and marketshare in the low end "casual game" end of the market, but also why there seems to be so little innovation at the high end. People are willing to take risks only when they don't have too much skin in the game.
There have been a bunch of proposals over the years to store public keys in DNS. Many of them are reflected in the list of DNS record types over on WP.
I recently heard some talk about the SSHFP record, but I don't know if any SSH clients actually try to retrieve or check it. (Right now with DNS not secured by anything it might be considered a security vulnerability, although I still think it would be better than the current system, where your SSH client throws a fingerprint at you and tells you to validate it -- which of course next to nobody actually does.)
I think the record you'd want to use is probably the "CERT" one, although that may be used or is intended for use by PGP, I'm not sure.
> and any actual problems it might touch upon have been solved better by SSL certificates years ago.
A lot of what SSL does, or tries to do, would not be necessary if the DNS was secure and not as open to spoofing. DNSSEC fixes some of the biggest flaws and will hopefully reduce the dependence on SSL and the enormous economic rents charged by Verisign et al for certificates.
You do, but the encryption part is relatively easy; it's the authentication that's hard. Right now, Verisign et al charge megabucks for "Extended Validation" certificates (mostly to banks, insurance companies, etc.) whose only advantage over a regular "el cheapo" SSL cert is the supposed additional validation.
Securing DNS would let you use it for validation, rather than the SSL certificate trust chain. So the E.V. certs would really not be necessary anymore.
Actually I think securing DNS would make MITMs a lot harder (although I wouldn't go so far as to say 'impossible') because most current MITM attacks rely on DNS poisoning.
There are lots of natural gas pipelines under the ground besides the low-pressure ones that end users tap into to run domestic appliances. The higher-pressure transportation pipelines aren't something you touch unless you want to die a spectacular death, so they'd be guaranteed to be left alone by everyone save the gas company. And if you wanted to protect against that, you could create some sort of paper company that owned it and was responsible for maintenance: I've never met a utility company that would touch something once they got an inkling of a way in which it could be made somebody else's problem.
The bigger and even medium-size datacenters have dozens of generators. Huge ones, too; they need to be able to put out megawatts and still have N+1 or N+2 in case one goes down, maintenance, etc.
I don't know if the slowdown in new construction has cleared the backlog any, but about a year or two ago, the big limitation on datacenter construction (or at least startup) was sourcing the gensets. Everything else might be in place and ready to go, but if customer contracts specified redundant power supplies with generator backup, you can't really tell them you're good to go when the generators haven't been built yet. Apparently that was the situation some places were in.
Slashdot Mirror
You can get houses either for free or for ridiculously low prices in places like Detroit and Flint. People still aren't moving there. There's no work -- you can get a house for free, but what do you do for electricity and heat and food?
You wouldn't be doing people who've gotten foreclosed on any favors by encouraging them to move to Flint or Detroit. You wouldn't do those cities any favors either; they're cash-strapped enough as it is, providing services to the people who live there, without adding more residents.
People have been trying for years to figure out what to do with the surplus housing in the rust belt and former industrial cities. It's a losing battle, and it's time to admit that nobody wants to live in these cities the way they are now, and work on making them places people want to move to by choice, not just because they have nowhere else to go.
Uh, people don't seem to be exactly chomping at the bit to "redevelop" these areas. If they were, I'm sure Flint or Detroit would love to hear from them. Real estate investment, especially commercial RE, isn't exactly a hot area right now, perhaps you've noticed.
They're demolishing them because nobody wants to live there, nobody wants to redevelop them, and the buildings are hazardous.
They would much prefer "demolish and redevelop" I'm sure, but they're going for "demolish, wait a generation or two, maybe hopefully redevelop," precisely because Plan A hasn't worked.
Part of the point of this is to raise population densities. Right now you have huge tracts of abandoned buildings, with people living here and there among them. It's a huge drain on public resources (providing police and, especially, fire protection to all the abandoned buildings), and doesn't really foster healthy communities.
Most of the plans that I've seen, including the one in Flint, involve buying up abandoned properties and demolishing them, while simultaneously restoring ones in better areas and encouraging people to move from blighted areas into them. The result is condensing the remaining residents of the city into a smaller, more densely-populated area. More public services in a smaller area, better public transportation, etc.
They're not trying to chase people out of the cities and into the suburbs or exurbs, quite the opposite. Most of the areas they're trying to get rid of were the original suburbs, and what they are trying to achieve is a rebuilding of the urban core.
Yeah, it would be great to get people to move in from the suburbs and fill in the high-density rowhousing in places like Baltimore, but that's just not going to happen. Nobody wants to live there, not given the way the areas are now. And those areas aren't going to get better. What's needed is a "rebooting" of cities -- get people back into the core areas, demolish some of the older urban/suburban transitional areas, and show that cities actually work. When people out in the 'burbs see that a city can be a nice place to live again, and not just a ghetto for people who have nowhere else to go, then it'll be time for new construction. (But this time, build mixed-use and actually plan the growth, rather than just letting stuff grow and create huge tracts of transportation-dependent, single-use housing, miles away from commercial or industrial areas.)
This is the first step towards making cities desirable again.
> It makes one wonder what the city would be like if it ended up being completely abandoned, sort of like Rome after the fall of the empire.
This isn't really true; Rome was never completely abandoned. The population just shrank dramatically as the infrastructure broke down. People moved out when the water stopped flowing and sewage stopped being washed away, or when there started to be outbreaks of plague or other diseases. But some people stayed.
So Detroit is a lot closer to Rome already than I think you imagine.
No reason you can't save the historical sites while demolishing the rest of the neighborhood. If there's a significant building, build a park around it. It'll be in the middle of the wilderness, but that'll just make it all the more interesting.
I suspect people will be a lot more likely to pay attention to historic sites when they're not in the middle of a boarded-up section of town, and it might be better for the buildings in the long run, since they're less likely to be destroyed in a fire. (Wildfires would be a problem, admittedly.)
I don't think that historical preservation and getting rid of hazardous, blighted buildings are mutually exclusive. You just need to achieve some sort of balance. Not every old rowhouse is really "historic," and not every building needs to come down just because it's in a crappy neighborhood and has some peeling paint. A few significant buildings here and there can stay, and won't impact wildlife if they're managed correctly.
Just to clarify the bit about the addresses, because I forgot a couple of sections...
The whole IPv6 address is 128 bits, but in a unicast address, the first 3 are the "prefix identifier," basically saying that this is unicast. Then you have a 13 bit "TLD Identifier" and 8 reserved bits, completing the global prefix portion.
But then you have a 24 bit "NLA ID", which might specify an ISP or some other intermediate network. This provides for traffic aggregation, and they get assigned (I guess) by the national registries. This brings you to 48 bits. Exactly how they'll choose to distribute the NLA IDs, and how many each organization/ISP will get, I'm not quite clear on. I've heard some people allude to ISPs getting large blocks at this level and putting a "subscriber ID" or "customer ID" in this region, leaving 80 bits free per customer, but I don't think this is really the case.
After the NLA is a "SLA ID", which is like a very big subnet identifier. It's 16 bits long, bringing you to 64 for the address so far. This is what I think individual home routers will get from ISPs, assuming the NLA IDs get given out with enough granularity so that there isn't competition.
Beyond the SLA ID is 64 bits for the "interface ID," which a host can pretty much define however it wants. In most applications this can be easily created by padding out the Ethernet MAC, although it can also be generated randomly if that's not desired.
References:
http://technet.microsoft.com/en-us/library/cc757359(WS.10).aspx - Surprisingly good TechNet article
RFC 2462
IPv4 is decimal, obviously, not octal; you just stop incrementing each group at 255.
The decision to use hex quad notation to represent IPv6 isn't really that important from a technical perspective. It's important in the short run that IPv6 addresses look different from IPv4s, to distinguish one from the other. However, in the long run it's quite possible to use an IPv4-type notation scheme with v6.
IPv6 addresses will in most instances consist of two components, one which will typically come down from an ISP (the "global prefix" is the proper name, IIRC) and consists of 24 bits, followed by a subnet identifier (8 bits), and then an interface identifier (32 bits).
In most cases where a user is calling their ISP for help, the global prefix will already be known by the tech on the line. It's not necessary for the user to report it. So, if IPv6 addresses become an unbearable burden (which I really don't think they are; people are well-trained to read seemingly meaningless numbers over the phone to tech support), you could quite easily adjust user-facing software to display the subnet and interface identifier in a friendly, IPv4-style form. In this form, the subnet+interface address would look just like an IPv4 address with one extra group of octal digits.
Frankly, I don't really anticipate many reasons for users to need to communicate their IP addresses to tech support once IPv6 becomes the norm. You used to get that a lot because automatic address assignment was a bolt-on to IPv4 and often didn't work right; with IPv6 it's the idea from the very beginning. Plus, IPv6 does a much better job of handling multicast and broadcast traffic, which means you can have automatic service discovery and automatic machine discovery without broadcast storms and all the other issues that have plagued attempts at such systems on IPv4.
That's no harder than knowing his username on Flickr, or the URL of his photostream. You already need to know some piece of information to be able to find his photos on the web; it doesn't matter (from the perspective of the person viewing the photos) whether that URL points to Yahoo's servers or one in his house. You'll probably get it via email or IM and click on it either way.
> I would prefer an addressing system that simplifies life for me.
IPv6 probably will, by virtue -- ironically -- of having more complex addresses. Since you can't reasonably expect people to remember a 128-bit value, even when expressed in hex (hell even if you used Base-64), there will be a far greater reliance on automatic addressing schemes under IPv6 than under IPv4. That's a good thing; Appleshare had the right idea in 1984, and the adoption of IP was a step backwards in this regard (although IP is superior in just about every other way, don't get me wrong, and Appleshare wouldn't have scaled like IP). The length of the IP address shouldn't matter, because the user should never encounter them anyway. With IPv4, doing this automatically was optional because manual addressing was, although inconvenient, admittedly practical. With IPv6 it won't be except in real edge cases, and we'll finally be able to start ignoring IP addresses the same way we basically ignore Ethernet MACs. (Quick! What's your Ethernet MAC? You don't know, more than likely, and it doesn't matter at all. That's how IP should be as well.)
And unlike IPv4, those addresses will be end-to-end routable, which means a lot less fussing around with port forwarding. Plus, the huge number of addresses ought to get rid of dynamic addressing completely, at least the sort of addresses that change themselves automatically from time to time when you disconnect and reconnect. (The addresses will still be "dynamic" in the sense that they're comprised of some part handed down from upstream and some part that's specific to the device, but they won't need to be doled out from some small pool with short leases.) That means no more dyndns.org and abnormally short TTLs to get a usable DNS.
VoIP will be far simpler as well. VoIP over IPv4 is a total pain in the ass, and there are a lot of ugly hacks (STUN, I'm looking at you) in order to try and make it work. In many cases, consumer VoIP equipment tries to avoid the whole mess by forcing you to attach it directly to your WAN uplink, ahead of your router -- which can often be nowhere near where you want it, either in terms of physical location or network topology. The hope of VoIP that comes closer to "just working" in the same way that POTS does would be enough to sell me on IPv6, long addresses be damned.
Are we supposed to be shocked and horrified by that or something? If so, it's not working.
It seems like a perfectly reasonable solution to me. They're not taking inhabited property by eminent domain, instead they're targeting abandoned houses and demolishing them to create open space. Net result is fewer abandoned buildings -- which are a safety hazard, and create lots of extra work for fire and police departments -- more open space, and healthier communities in the nicer sections of town instead of a few people spread out and squatting amongst the ruins.
The only people who should be appalled by this are American exceptionalist, growth uber alles neo-"conservatives." In other words, morons.
"Negative growth" is something we're going to have to start dealing with in a lot of places in the near future, and as a society in general within a generation. The United States managed to get very high on the hog by growing continuously throughout the 20th century, which is getting increasingly unsustainable and simply cannot continue. The 20th century (arguably the 19th as well) as experienced in the US was very probably a singular event, built on cheap energy, rapid population growth, industrialization, and coming out on the winning side of two World Wars. The party is over.
We need to look forward, and unflinchingly and without nostalgia analyze what's likely to work in the future and what isn't. Trying to force some sort of return to the "good old days" is doomed. The things that aren't going to work need to die. That means industries that aren't profitable need to be wound down, rotting, unwanted houses need to be bulldozed, and government programs that depend on or assume never-ending growth to function need to stop.
I am glad to see that Flint is at least making some attempt to move forward, rather than sit and wait for some sort of salvation that's plainly not going to come, as other cities seem hell-bent on doing. I have some minor issues with the way it sounds like they're doing things -- my geo-libertarian sensibilities would be less offended by an "abandoned buildings tax" that attempted to stick owners of vacant structures with the costs they're externalizing on the community, than any use of eminent domain -- but these are issues of implementation rather than overall intent.
I agree that document management is the way to go, but I would just point out in their defense that they're not just exclusively "big corporation" products anymore.
All my knowledge is FileNet-centric, but at least with FN you can stand up a system quite easily; it's not a huge investment for what you get. I've seen deployments done for small and medium-size businesses (and relatively small departments within large companies) that justified the cost pretty easily in terms of not losing or having documents accidentally deleted, and being able to guarantee compliance and conformance to a backup strategy.
Versioning is also a big plus. You can let people edit documents without worrying that they're going to wipe out anyone else's work -- if you don't like their changes, just grab the previous version instead. Most places I've seen introduce most of their file-share complexity because they try to basically do version control in a non-versioning filesystem using file names, and everyone does it a bit differently. Total mess. Much better to do it the right way and use some sort of version control system or ECM product from the beginning, rather than try to use bare-filesystem share drives until they're totally unmanageable and then migrate.
I have a personal bias, but I think IBM's FileNet would solve this quite neatly. I've done implementations of it that are pretty much exactly what the OP describes.
Customer has a share that's gotten totally out of control, just stuffed full of files. They want to make them available across multiple offices, generally without getting into complex VPN crap, and also want to simplify management, add more security / compartmentalization, or integrate it with corporate SSI. All doable. Runs on your choice of platforms, too. (Linux, Unix/AIX, Windows all OK as servers.)
There are even tools that basically take a share drive and walk the directory structure, importing documents at extremely high volume and using the folder structure to categorize and tag the documents within FileNet. It's quite slick and can either be used as a one-shot migration from a traditional fileserver to FileNet, or as an ongoing thing (take all files in a particular directory or set of directories and commit them).
Once you have the documents into FileNet you can access them over a web interface or via various desktop clients, and there is a nice API for integrating it with custom in-house applications if that's a requirement. Also, IBM makes some add-ons for Word and Excel (and maybe PowerPoint) that allow you to work directly with items stored in a FileNet repository. Plus, if down the road you want to get into "workflow" (basically building your document management system around your business process), that can be easily bolted on.
Email is in profile if you want specific case studies or whitepapers, or if you want me to put you in touch with people who do these sorts of things regularly.
Apparently the ORSN project has been shut down, at least for the moment, due to lack of involvement and resources.
Some of the servers continue to operate, but it was officially discontinued as of 31 Dec 2008. Too bad.
I am not a big fan of OpenDNS either. Rather than use L3's or Verizon's servers (4.1.1.1 and 4.2.2.2 sets respectively, I think), you might want to try the Open Root Server Confederation's. They are what OpenDNS purports to be; an actual grassroots effort to provide an alternative DNS, without the sleazy failed-lookup pages or obvious profit motive of OpenDNS. There are some TLDs in the ORSC root zone that don't exist in the traditional ICANN one, but you can just ignore them unless you want to take part.
Their top-level servers are listed here. You can also run `dig . ns @ns1.vrx.net` for a more up-to-date list; when I run that I get the following:
a.root-servers.orsc. 172800 IN A 199.166.24.1
c.root-servers.orsc. 172800 IN A 199.166.26.200
f.root-servers.orsc. 172800 IN A 199.166.31.3
i.root-servers.orsc. 172800 IN A 199.166.26.51
I think their intention is that people will put the root file into their local caching nameserver rather than hitting one of their top-level servers with each request (unlike OpenDNS), but there's no actual discouragement of the latter practice and I assume it's considered acceptable for laptops and other portable machines.
The only way I can imagine they'd profit from this is by blocking access to alternative DNS servers like OpenDNS, or even just putting in well-known public DNS servers like 4.2.2.2, so that they can intercept unknown requests and return ad-laden pages instead. Basically typosquatting.
Various ISPs have gone down this road before. (Rogers Cable has tried, and so has Road Runner.) Unfortunately -- for the shady ISPs, anyway -- it's easy for annoyed users to get around these schemes; they can just configure their computer or NATing router to use a different DNS server besides the one supplied by the ISP via DHCP.
By transparently redirecting all DNS requests to their own servers, Comcast would eliminate this method of circumventing their advertising. They could also block sites at the DNS level much more easily than before.
A lot of censorship schemes (ab)use DNS in order to return a bogus result to a query; these schemes aren't very good, though, because any user with two brain cells to rub together and the tiniest bit of motivation can change their DNS configuration to use clean servers instead. By doing transparent redirection, you prevent this.
Those strike me as the two obvious reasons. The profit-motivated one (squatting on failed DNS queries) is annoying and causes many non-web applications to fail or behave improperly, but it's not nearly as bad as the censorship-motivated one is. However, the same technique that makes failed-lookup ads harder to avoid could easily be used as part of a censorship scheme if demanded by the government. It's important that even casual Internet users (who may not really care about returning a "page not found" web page instead of the normal browser message) understand why letting their ISP monkey with DNS lookups is a Really Bad Idea.
In both cases you can get around the hijacking by using a VPN and forcing DNS queries though it, but that's significantly harder than changing from automatically-assigned DNS servers to well-known ones like OpenDNS's or Verisign's.
I just ran the ICSI test from a host on Comcast's network in the Metro DC area (inside the 69.255.0.0/16 space) and port 53 was not redirected according to the results.
Ports blocked were:
135 (RPC)
139 (NetBIOS)
445 (SMB)
No blocks to anything else, although I have periodically experienced blocks on the common SIP negotiation ports (5060, 5061, etc.) that stop my VoIP from working until I change the port in use. I'm not sure what that's all about, and whether it's malice or just some sort of incompetent rate-limiting thing on Comcast's part.
They might have technical chops or they might just be taking advantage of a disgruntled employee or other low-tech hole; it's impossible to say so far. What's clear is that they obviously had no idea what to do with the data once they got their hands on it.
I mean, did they really think they could just grab a dump of T-Mobile's customer database and sell it to AT&T? C'mon. Let's think about that for a minute -- what the hell is AT&T going to do with it? I'm sure their marketing department knows all about T-Mobile's demographics versus their own, and if not (and if they care) they could find out with a few calls and some relatively small payments to a research firm. Same with just about anything else I can possibly imagine them extracting from T-Mobile's servers. If AT&T or Verizon is really dying to know something about T-Mobile's operations, they have lots of easier ways to figure it out that involve a lot less risk than buying red-hot DB dumps from criminals.
Also, anyone with half a brain ought to realize that all the telco companies live in fear of being broken into, and that a major breakin is going to hurt the public's perception of the entire industry. The U.S. cellular telcos are, basically, a cartel: and if there's one thing cartel members hate more than each other, it's disruptive outsiders. T-Mobile's competitors probably didn't respond because they thought it was a joke, or some sort of Nigeria scam; if they'd known it was serious, they almost certainly would have done what Pepsi did and called the cops. Not for altruistic reasons, but for sound business ones: having basically mercenary criminals screwing around, stealing data, scaring customers, and generally upsetting the normal business environment is not to any legitimate player's advantage.
The other red-flag that screams amateur hour about the whole thing is what they did after being turned down by the "competitors" -- they posted what amounts to a "for sale" ad to the Full Disclosure list. They thought that was the best venue for selling a shitload of customer financial records? Really? There are bulletin boards, whole online communities, where criminals trade identity information. It's a mature underground economy; the information they had -- names, addresses, CC numbers, SSNs -- would have been a fungible, commodity product, well-understood and easy to resell for cash.
However they got the information in the first place, it's pretty clear they didn't think their cunning plan all the way through.)
Bingo. And that they're not doing that is what convinces me they're not really interested in giving customers a good value proposition; they're just bitching that someone is preventing them from screwing customers as hard as they'd like to.
If they sold "classic" (anything that's not the new hotness) games in different packaging for the price of used, who would buy used? They could take the wind out of Gamestop's sales right there.
Lots of companies spend giant piles of money trying to figure out what customers want so that they can try to deliver it. In this case, it's blatantly obvious what customers want -- a slightly cheaper game -- and it's even obvious exactly what price they're willing to pay. Gamestop has done all the market research for them. If they want to make money, it's on the table for them to take. If they don't, they can let Gamestop take it.
That hourly rate neglects risk. Not all games are created equal. There's a certain risk that you're going to get a game, open it up, start to play it, and realize it sucks.
If you realize a $60 game sucks, you're out $60, or at least ($60 - (resale value)). If you've only paid $10, that's the most you risk losing.
Consumers are understandably wary of plunking down more than a couple of bucks unless they're very sure they're going to like the game. This is why it's a lot easier to gain traction and marketshare in the low end "casual game" end of the market, but also why there seems to be so little innovation at the high end. People are willing to take risks only when they don't have too much skin in the game.
There have been a bunch of proposals over the years to store public keys in DNS. Many of them are reflected in the list of DNS record types over on WP.
I recently heard some talk about the SSHFP record, but I don't know if any SSH clients actually try to retrieve or check it. (Right now with DNS not secured by anything it might be considered a security vulnerability, although I still think it would be better than the current system, where your SSH client throws a fingerprint at you and tells you to validate it -- which of course next to nobody actually does.)
I think the record you'd want to use is probably the "CERT" one, although that may be used or is intended for use by PGP, I'm not sure.
> and any actual problems it might touch upon have been solved better by SSL certificates years ago.
A lot of what SSL does, or tries to do, would not be necessary if the DNS was secure and not as open to spoofing. DNSSEC fixes some of the biggest flaws and will hopefully reduce the dependence on SSL and the enormous economic rents charged by Verisign et al for certificates.
You do, but the encryption part is relatively easy; it's the authentication that's hard. Right now, Verisign et al charge megabucks for "Extended Validation" certificates (mostly to banks, insurance companies, etc.) whose only advantage over a regular "el cheapo" SSL cert is the supposed additional validation.
Securing DNS would let you use it for validation, rather than the SSL certificate trust chain. So the E.V. certs would really not be necessary anymore.
Actually I think securing DNS would make MITMs a lot harder (although I wouldn't go so far as to say 'impossible') because most current MITM attacks rely on DNS poisoning.
There are lots of natural gas pipelines under the ground besides the low-pressure ones that end users tap into to run domestic appliances. The higher-pressure transportation pipelines aren't something you touch unless you want to die a spectacular death, so they'd be guaranteed to be left alone by everyone save the gas company. And if you wanted to protect against that, you could create some sort of paper company that owned it and was responsible for maintenance: I've never met a utility company that would touch something once they got an inkling of a way in which it could be made somebody else's problem.
The bigger and even medium-size datacenters have dozens of generators. Huge ones, too; they need to be able to put out megawatts and still have N+1 or N+2 in case one goes down, maintenance, etc.
I don't know if the slowdown in new construction has cleared the backlog any, but about a year or two ago, the big limitation on datacenter construction (or at least startup) was sourcing the gensets. Everything else might be in place and ready to go, but if customer contracts specified redundant power supplies with generator backup, you can't really tell them you're good to go when the generators haven't been built yet. Apparently that was the situation some places were in.