The solution then is to rate-limit at the router or TCP stack, or for applications to start being more careful about how much bandwidth they use -- just because a user has 6.0Mbps available for peak speed, doesn't mean that applications should assume that they can or should use as much of it as possible, all the time.
P2P applications have had rate-limiting controls for a long time; it's probably about time for Skype and video-chat applications to have them too. Skype is particularly bad in this regard because it automatically defaults to the highest-quality codec that a connection supports. While this might make sense on fixed-bandwidth connections, it's not great for the majority of broadband connections, which have the capability of pushing a high peak speed, but shouldn't be expected to sustain that peak for very long. (And this isn't a bad thing or rare, either; lots of "real" internet connections are the same way. You can buy a 100Mb pipe because you occasionally need the full 100 megabits, even though you can't afford to saturate it 24/7. I'd wager most SLAed connections at.coms and.edus are like this.)
In general, it's a pretty fair policy, especially because it only goes into effect when a neighborhood node starts to become congested. (Unlike their 250GB/mo cap and their old policy, which didn't care whether you were actually competing for resources with anyone else.) If I'm using huge amounts of bandwidth for Skype or video-chat, to the point where my neighbors are being affected even though they're just trying to check their mail and log off, they're not going to care what application I'm using. It's fundamentally no different, to anyone else in my neighborhood, if I'm taking up all the bandwidth on the upstream node with VoIP calls, Linux ISOs, or midget porn. They all have the same effect on my network neighbors, and all should get me throttled.
What needs to happen, is applications need to get smarter about their bandwidth consumption. If a VoIP program finds itself getting throttled (increased latency), it should try dialing down its bandwidth usage -- by choosing a tighter codec, perhaps -- and seeing if the situation improves.
I'm sure OEMs will install something for exactly this reason, however I wouldn't be surprised if whatever they choose to put on there is worse than Microsoft's crap.
The net effect of this lightening might actually be an increase in bloat -- moderately bloated stuff from MS replaced by horribly bloated stuff from OEMs, who have even less of an idea about what constitutes good software than Microsoft.
I agree, I've always thought base 32 or base 36 would have been a good choice for IPv6.
I think something is off with your math, though; for a full 64-bit address (max value 2^64), you'd need a 12 or 13-digit Base36 'number'. This seems to me like a fairly big improvement (in terms of memorization by a human) from the 18 digits of hex that would otherwise be required, and puts the value down in credit-card-number-length territory, which many people memorize easily with use.
This converter says that hex FF:FF:FF:FF:FF:FF:FF:FF (decimal 18446744073709551615) is equal to Base36 3W5E11264SGSF.
So in the worst case it's not quite as compact as the 4 digit addresses you're thinking of, I don't think. Still, I'd like to see equipment manufacturers / software developers include the ability to enter IPv6 addresses in a form besides hex, since I'm unconvinced that it's the most convenient way for humans to represent them. (I'd never given much thought to base-32 but maybe that's a good compromise; it preserves the ability to break it up by octet -- although I don't know how necessary that is anymore with CIDR.)
It shouldn't have to be this way. If every device had a globally-unique, routable address, you wouldn't have to have nasty NAT-traversal hacks, or use SIP/IAX trunking nearly as often. It would still be possible to set up a single "front office" line that then redirected to various extensions, but it wouldn't always have to be that way.
And really, I doubt that many people -- if they had the choice -- would choose to have one phone number plus an extension, if they could have unique direct-dial phone numbers for everyone in the office plus a front-office line. (Sure, there are exceptions, like callcenters, but they're not really the rule.) But with NAT you get stuck setting up SIP proxies and trunks, and giving users extensions, far more often than is really necessary in order to accomplish what the users want in the optimal case.
As an aside: most users don't really even understand what an end-to-end VoIP system might look like, because they're still thinking about it in terms of POTS. If you have SIP everywhere, you don't even have "phone numbers", much less extensions. You have email-style user@domain.tld addresses, and the call magically routes to wherever that user happens to be at that particular moment in time. Calling a phone, as opposed to a person, will one day seem pretty antiquated and strange, I think. (And before anyone says that users will never accept this or that it'll never happen -- how many people have contacts in their cell phones' addressbook that they don't know the numbers for? I thought so. We're already most of the way there.)
More generally: It's always a bit strange to argue about IPv6, because people always claim that it's unnecessary because nothing we do right now requires it. Well, of course nothing we do right now requires it -- if it did, we wouldn't be using it, because IPv6 isn't widespread. Everything we do right now we can do over IPv4, because IPv4 is basically all there is. But that doesn't mean that IPv4 is good, or there isn't a whole lot of really neat stuff that we could do (stuff like VoIP mobile roaming) if we weren't stuck making everything work in the IPv4 framework.
That's not really an inbound/outbound traffic issue -- you might as well just block all connections using port 25 to those machines. If you're blocking outbound on 25, there's little reason why you'd want to allow inbound connection attempts on 25 either. (Given that the stated goal of blocking outbound attempts in the first place is to stop users from running what are effectively mailservers -- albeit spammy ones.)
So really you're just talking about blocking port 25 in both directions. If you were using a hypothetical IPv6, non-NATing firewall, you'd accomplish the same task by just turning off port 25, period. (Although any firewall would allow you to block outbound/inbound independently if you wanted to, I'm suspect, unless it was a very low-grade consumer device.)
That's a lot of expense saved if they can delay switching over for a year.
A whole lot of that savings would probably get eaten up by lawyers.
Assume for a second that a company currently has an/8. For them to switch to NAT -- which would only be useful for a year or two, because that's how long we're delaying IPv6 by, with all this screwing around -- would cost a lot of money. They're not just going to let go of their allocation willingly. They're going to drag their feet using every method available to them, for as long as possible, right up until fighting becomes more expensive than giving in.
Even assuming rational behavior (which isn't a safe assumption), in the worst case they might spend just as much on lawyers, fighting the allocation-grab, as the NAT conversion will cost, and the entity trying to wrest their allocation away from them will have to match or exceed this spending in order to win. (Maybe even outspend them by a lot -- all the company has to do is delay for a couple of years until it becomes a moot point because IPv6 has already happened; this is easy and comparatively cheap -- look at SCO.) So the total broken-window loss as a result of this, to all parties involved, is quite possibly twice the amount of converting the company to NAT. And the amount of converting a huge multinational company to NAT might be staggering; there's no telling how much grimy legacy stuff they might have to fix. It's probably a Y2K-level problem.
And that's without getting into who exactly is going to take on, single-handedly, some of the biggest companies in the world. ICANN is effectively part of the U.S. Department of Commerce, who are typically friends of business anyway. I don't think it would take too many phone calls (or bags of cash) from IBM, GM, Ford, Halliburton, etc. to squash any plan that would cost them millions of dollars and put them at a disadvantage. Particularly in the current political climate, it could easily be spun to look like sacrificing American business for the benefit of the Chinese -- it's a political nightmare.
The refrigerator is a poor example, but other appliances and home HVAC systems could realize significant energy savings by communicating with each other, and by being controlled remotely over the internet (or some other means).
There are a lot of interesting scenarios: if you had real-time, fluctuating power pricing, you might want to have appliances change their energy consumption or other settings in response to their cost. Only run some appliances when the spot price is below $0.15/kwh, for example.
Or even simpler, if you have a peak-load factor as a component of your bill, devices could communicate with each other to ensure the total draw at any one time doesn't exceed some predetermined maximum. Different appliances would each have a priority, and would have to shut down to accommodate higher-priority draws. (E.g.: the clothes dryer would shut off if you turned on the electric stove or microwave, because it would have a lower priority -- unless you were really obsessive about not having wrinkled clothes, I suppose, in which case you could set it the other way around.)
The two could be combined, as well: once you have the infrastructure in place, you could set up whatever rules you wanted, balancing preferences for certain services against costs, and prioritizing certain services at various times. It wouldn't be hard to produce detailed reports of what each appliance/service was costing to operate, and how new rules would affect costs based on past usage patterns. (There's the potential for a lot of complexity in the control system, but to a user it might seem very simple on the surface.)
Also, there's a wide range of appliances that really only need to run when people are in the house (or just before they enter the house) but tend to run continuously because it's a PITA to run them based on inflexible timers: HVAC, lighting, water heaters, possibly even water pressure-pumps. Devices would only be turned on when necessary for another device, or a user need was anticipated. I could easily imagine a system that was plugged into an online calendar and controlled this in a way that hid it from the user as much as possible. Heck, if you had a PDA with GPS, you wouldn't have to do anything.
The driving force behind "home automation" up until now has mostly been the geek factor of controlling all your lights/appliances/whatevers from a single point, but I think in the future, energy savings and integration will be the selling point. Since it seems unlikely that we'll really make significant inroads on alternative sources of energy before we start to run low on petroleum, there's a non-trivial chance that energy may become staggeringly expensive. I could easily see a future where the running costs of energy-intensive appliances greatly exceed -- even to the point of triviality -- their purchase price.
Couldn't you send an email containing a URL, which when clicked sends the user to a page that checks for the presence of a browser cookie (set, over HTTPS, when they submitted the recovery request), and lets them set a new password?
That would seem to eliminate a host of problems: it doesn't require storing the user's password in plaintext in a DB somewhere (it's a 'password change' system, not a 'password recovery' one), it doesn't send out any critical information via email, and it doesn't let someone who intercepts the email en route do anything with it. Yet it's still more secure than just doing the whole password-change procedure over the web, because it ensures that the user has control over (or at least access to) the email address that's on file.
The only requirement it creates is that the user click on the email link from the same computer (and using the same browser) that they submitted the request with. Since ideally you'd want them to reset the password quickly after submitting the request, this doesn't seem onerous.
If they're so worried about it, they're in the perfect position to open up their own newsgroup service and charge a few bucks a month. There's no way this wouldn't be profit, as they would no longer have to pay for much bandwidth if they just downloaded EVERYTHING once and then updated as necessary when someone changed something.
They're not really in a position to do this; they don't even run their own Usenet service anymore -- it's farmed out to Giganews. (Not a bad thing, Giganews is far more competent than I think Comcast would be running their own spool.) By cutting off Usenet access I expect all they're really doing is eliminating the money they pay to Giganews every month.
The logical choice if you're a Comcast user affected by their decision is just to go to Giganews and sign up privately. That would get you the same service, and run you about $8USD/mo. (That's for the 2GB cap, which is what Giganews-via-Comcast allowed.)
Anyway, I think your overall sentiment -- it's cost-cutting under the guise of "think of the childrenn!!!111" -- is spot on.
This is precisely why most commercial software that supports Linux, doesn't support "Linux."
Instead they support "RHEL 5.2", "SuSE 10", "Ubuntu 8.04", etc. Those are all specific, identifiable pieces of software that a user could conceivably go out, download or buy, and install on their hardware. Each of them have teams of people concentrating on making them into basically stable development targets (some moreso than others, sure). Supporting "Linux" could mean any number of things. If your software runs only on Ubuntu, is it really "Linux" compatible? Sure, in a way -- but RHEL users probably won't be pleased.
It's not unreasonable for a vendor to specify a particular distro, especially if you're talking about enterprise software (where the software generally dictates the platform/OS choice), and doubly so when the OS being dictated doesn't cost anything or come with any real strings attached.
People bash Microsoft because they've managed to do something that many of us who've been around for a while thought was impossible: they produced an OS so architecturally ugly, it makes Unix -- the system that inspired "Worse is Better" -- seem elegant by comparison.
Probably because NewsBank wouldn't sell it to them if they knew Google was going to release it all for free.
I mean, unless Google was prepared to pay NewsBank more than the sum total of all their current subscribers, they'd be stupid to go along with that plan. Their business depends on charging for information that Google wants to provide to everyone for free; they're not going to take to that very kindly.
Maybe Google could just buy NewsWire outright, and with them get their collection/database, if that were cheaper than digitizing from microfiche than I'd say that's a good plan. But that might be prohibitively expensive if NewsBank has other lines of business besides selling access to their archive that would inflate their cost beyond the value of the archive itself.
More germaine would be President Bush and Vice President Cheney's drunk driving covictions. I'd say something that could result in people getting killed is a lot more serious than streaking.
Well, Ted Kennedy actually killed somebody and it doesn't seem to have kept him out of politics.
The electorate doesn't seem to care unless you're buggering somebody (aside from simply "America" generally); that they'll break out the pitchforks for.
Ah, yes. 3M Fluorinert. That stuff seems to pop up here in discussion every once in a while. I don't believe they actually manufacture it anymore -- what you can buy is basically "New Old Stock" -- and it's staggeringly expensive. (For the home hobbyist, anyway; if you're actually maintaining a Fluorinert-cooled system in production, it's probably nothing.)
The common alternative you can play with at home is mineral oil, although it's not nearly as good. What makes Fluorinert useful is its relatively low boiling point. It's liquid at room temperature and on most idle parts, but on a hot component, it will boil. It's the boiling, not just the submersion in liquid, that draws the heat away so effectively. Most home liquid-submersion experiments miss this entirely.
Personally I've always wondered about coolant solutions that use the solid/liquid state change rather than the liquid/gas one; maybe a slurry of solid, low-melt-point crystals suspended in a liquid carrier. I've worked with some plasticizers that have basically room-temperature freezing points, but I've never seen that particular property taken much advantage of. (Most of them actually become more dense as they freeze, rather than less dense like water, so you could put your hot parts at the bottom of a tank filled with slurry, and when the coolant melted the liquid would rise to the top and more frozen coolant would fill in over the part. It would be similar to Fluorinert boiling, but without the gas production.)
$12hr PT IT job where a CS degree is required for consideration
When there are CS grads willing to work for $12/hr PT, that's what their skills are going to be worth. I mean, do you seriously think that someone with a CS degree shouldn't be allowed to work for $12/hr, if that's what they want to do, or need to do in order to get a job?
Replace "CS grad" for a minute with "English major". We've all heard the stories about kids graduating with English (or Anthropology, or Sociology, or any number of other 'useless' majors) degrees and having to work at Pizza Hut, or working as filing assistants in some dank basement somewhere. It's understood that they're going to end up working for peanuts, because there are too damn many of them competing for too few really good jobs. So a few rockstars get the cool jobs in their fields, while the rest do scut work and dream of grad school. That's kind of what you get for majoring in a field that there's very little demand for.
There's nothing any different about CS: sure, it's a technical field rather than a liberal arts one, but it's not immune to saturation, either. There's nothing about CS, or Engineering, or Physics (or anything else) that's supposed to automatically mean that you get a job after graduation. Universities have been turning out low-quality CS grads for years, and that's taken its toll on the market.
That said, there's still a huge demand for really good CS people (and really good engineers, etc.); if you're working one of the $12/hr jobs, either you're selling yourself short, or you're really not that good.
There is no magic solution to this. A lot of CS people got the idea in their heads back during the 90s that having IT skills should and would automatically guarantee anyone a decent job for the rest of their life, even if they don't work hard to stay on top of their game. That's just not true and there's no reason why it ought to be true. The late 90s tech boom was a fluke; it was the exception, not the rule. Now the supply -- colleges and people going into college and picking majors -- has caught up with demand, and IT is like anything else: you can make a lot of money if you're very good, you can probably scrape along if you're only better-than-average, and you can starve or find something else to do if you're untalented.
There's nothing to 'fix' there, because that's not a problem. IT is not gnosticism; it's not some secret priesthood. If lots of people want to try their hand at it, they shouldn't be prevented from doing that. Just because someone got to the party earlier, or happened to be born earlier, doesn't mean they should be able to keep someone more talented than they out of the field -- and that's exactly the effect that protectionist laws or union rules would have.
A company is (generally) free to fire union members who strike and replace them with others.
I'm not aware of any U.S. state where this is broadly the case. Generally, companies have to negotiate with unions, and there's a whole process (time-consuming, expensive) that needs to be gone through before a company can effectively tell the union to get lost.
I wouldn't have nearly as much of a problem with unions if they weren't entrenched by legislation; if they existed purely as part of the labor market, they'd be fine. Workers ought to be able to band together and bargain collectively, if they want to and believe that it'll get them a better deal as individuals. But companies also ought to be able to fire them all and re-hire people off of the street. Unfortunately that's not how it works in most cases.
The reason I'd like to see union-protecting legislation eliminated isn't because I hate unions on principle, it's because I hate what unions become when they're protected artificially like that: rather than existing for the good of all workers, or all workers in a particular industry or with a particular skillset, they become nothing more than an extortion scheme for a small number of members, at the direct expense of other workers with similar skills who are kept out of jobs.
If unions weren't protected by legislation, in order to bargain effectively (and not just be told to get lost by employers), they would need to recruit a large percentage of available works in a market segment. It wouldn't be enough to just let people currently holding a job into the union, you'd need to also let all the people who are potential employees into the union. You wouldn't be able to use the union as a way of disempowering otherwise employable people, at least not in large numbers, which is exactly what they do now.
Not necessarily. You just need to do sanity checks all the way up the chain. Fixing the protocol is definitely the way to go, long term, but in the immediate future the problem can be minimized if everyone keeps an eye on those downstream from them.
It's much the same as with forged route advertisements. ISPs have to monitor and not unquestioningly accept routes from end users/customers. If some guy on a cable modem suddenly starts advertising routes to Yahoo.com's servers, it's probably best to not pass that advertisement along without looking into it first. Likewise, that ISP's ISP (in the case of a local or regional ISP) or the backbone provider or peers (in the case of a large ISP) need to check advertised routes before accepting them as well, in case the original ISPs admins get lazy and accept a route that they shouldn't.
It's a lot of work, but everyone needs to be diligent and critically evaluate information that's flowing up and asking to be propagated before they pass it along, from local ISPs all the way up to backbone providers.
> So Firefox's solution has been make it hard to pick the unsafe choice.
Except they really haven't. They've made it hard to make the sorta-kinda-theoretically-less-safe choice, the one that might result in a MITM attack, but in doing so they discourage SSL use generally.
Do you think that hypothetical user you're talking about is going to notice whether the page is using SSL or not? I doubt it. And a lot of companies seem to agree, and use plain old HTTP for all sorts of stuff when they shouldn't (we just had an FPP on this a few days ago, in fact).
As script-kiddyable as MITM attacks may get, they're never going to be as easy as just sniffing unencrypted traffic, and any time you make encryption difficult or complicated, that's the alternative people use.
That question doesn't even address the bigger issue, IMO, which is that releasing toxins into the environment leads to birth defects and chronic illnesses -- essentially guaranteeing generations of people who will be permanently disabled as a result of the activity. (Also, their are sometentativelinks between even mild heavy-metal poisoning during childhood and violent tendencies later in life; not only might you be creating thousands of people with birth defects or mental retardation, but you might be dooming an entire society to increased violence and crime as a result.)
There's a reason why places with functioning governments almost universally don't allow this sort of thing. The social costs are vastly greater than the benefits it brings to the people who actually do it, and many of the people who end up paying the price never asked to be involved at all. They just happen to have the misfortune of living downwind, downstream, on the same coast, or drinking from the same aquifer. That, by itself, makes it a morally bankrupt activity -- nothing justifies poisoning others who never asked to be involved.
Just because someone is starving doesn't give them a blanket license to harm others. It might make their actions understandable and perhaps even morally justifiable on an individual level, but it doesn't mean that it ought to be allowed as a matter of policy. Food shortages are a tractable problem -- the immediate solution, at least, is straightforward. However once an area has been contaminated with toxic waste, and especially once the population has a high level of birth defects secondary to toxic exposure, it can take generations to even realize the scope of the problem.
If they discovered that you were keeping 200 cats in your home under extremely unsanitary conditions, they would do the same thing: move all of the cats to a shelter somewhere, and charge you with violating local health regulations once they had assessed the entire situation.
Much as I like cats and wish a slow, painful death on anyone who's cruel to domestic animals, I wouldn't want the authorities busting in and confiscating anyone's cats without a warrant, either. I'd want them to go through the proper procedure, which involves ensuring there's probable cause that something illegal is going on (including, specifically, what law is being violated), getting a warrant, and then going in and dealing with the situation.
There is a reason why our legal system has only very narrowly-defined exceptions to the rules requiring warrants (or at least, it used to) -- it's that process that keeps us from falling off the very steep cliff that ends with a police state.
Sure, there's something to be said for using them as an educational tool, but again, you're still better off getting a newer high powered box and just running a virtualization environment on it to mess around with distributed parallel computing environments.
I'm not so sure this is true. When considering the purchase of a brand-new computer, you need to take into account not only it's "running cost", but also the energy involved in its manufacture.
An older computer might use more energy to operate, but if you already own it, it might make sense to continue using it. A brand new machine may well be more efficient, but will come with a huge 'manufacturing debt' that it has to make up before it's really saving any energy. It takes huge quantities of energy to manufacture a new PC and all the components that go into it.
From a purely economic perspective, all that energy equals money -- you can buy a lot of electricity for the cost of a new PC. If you're not running a machine 24/7, it may not make sense to upgrade it simply for more efficiency, either for environmental or cost-reduction reasons, until it's well and truly obsolete and has to be replaced anyway.
Just as a follow-up... anyone considering taking e-waste to a recycler should first check to see if the recycler is listed here as having been approved by the Basel Action Network (an anti-dumping group). The list includes "e-Waste recyclers that have agreed to adhere to strict criteria [...] The criteria require that no hazardous electronics equipment or parts (as defined internationally) will be exported to developing countries or be processed by captive prison labor, and that none of it will end up in landfills or incinerators."
As far as I know, it's the only (somewhat) reliable way to know that a "recycler" isn't just exporting the trash to the developing world. Many recyclers talk a lot about the environment, but don't give very many specifics about what actually happens to e-waste you drop off (besides vague platitudes like "in accordance with all State and Federal laws" which means little given how minimal most laws concerning e-waste are). That's because they may just be loading it into containers bound for the other side of the planet.
I'd have some reservations about taking it to many "recyclers". Some actually perform the recycling and metals reclaimation themselves, but many more just take all the equipment to the Third World (Africa and South Asia seem to be popular) and dump it there.
Anyone taking old IT junk for free or without charging significantly for its disposal is almost certainly dumping. Although there is a significant precious-metals content in them, it's not (yet) worth the labor required to reclaim it in the developed world. (Which is why you don't see people soliciting e-waste in the same way they do scrap metal or junk cars.) It's a lucrative business when you can employ starving children to do it, but not so much otherwise.
Slashdot Mirror
The solution then is to rate-limit at the router or TCP stack, or for applications to start being more careful about how much bandwidth they use -- just because a user has 6.0Mbps available for peak speed, doesn't mean that applications should assume that they can or should use as much of it as possible, all the time.
P2P applications have had rate-limiting controls for a long time; it's probably about time for Skype and video-chat applications to have them too. Skype is particularly bad in this regard because it automatically defaults to the highest-quality codec that a connection supports. While this might make sense on fixed-bandwidth connections, it's not great for the majority of broadband connections, which have the capability of pushing a high peak speed, but shouldn't be expected to sustain that peak for very long. (And this isn't a bad thing or rare, either; lots of "real" internet connections are the same way. You can buy a 100Mb pipe because you occasionally need the full 100 megabits, even though you can't afford to saturate it 24/7. I'd wager most SLAed connections at .coms and .edus are like this.)
In general, it's a pretty fair policy, especially because it only goes into effect when a neighborhood node starts to become congested. (Unlike their 250GB/mo cap and their old policy, which didn't care whether you were actually competing for resources with anyone else.) If I'm using huge amounts of bandwidth for Skype or video-chat, to the point where my neighbors are being affected even though they're just trying to check their mail and log off, they're not going to care what application I'm using. It's fundamentally no different, to anyone else in my neighborhood, if I'm taking up all the bandwidth on the upstream node with VoIP calls, Linux ISOs, or midget porn. They all have the same effect on my network neighbors, and all should get me throttled.
What needs to happen, is applications need to get smarter about their bandwidth consumption. If a VoIP program finds itself getting throttled (increased latency), it should try dialing down its bandwidth usage -- by choosing a tighter codec, perhaps -- and seeing if the situation improves.
I think what they're doing is averaging your traffic over 15 minute periods.
At least that was the impression that I got from reading about it (not from TFA, but from the article on Ars a few days ago).
I'm sure OEMs will install something for exactly this reason, however I wouldn't be surprised if whatever they choose to put on there is worse than Microsoft's crap.
The net effect of this lightening might actually be an increase in bloat -- moderately bloated stuff from MS replaced by horribly bloated stuff from OEMs, who have even less of an idea about what constitutes good software than Microsoft.
I agree, I've always thought base 32 or base 36 would have been a good choice for IPv6.
I think something is off with your math, though; for a full 64-bit address (max value 2^64), you'd need a 12 or 13-digit Base36 'number'. This seems to me like a fairly big improvement (in terms of memorization by a human) from the 18 digits of hex that would otherwise be required, and puts the value down in credit-card-number-length territory, which many people memorize easily with use.
This converter says that hex FF:FF:FF:FF:FF:FF:FF:FF (decimal 18446744073709551615) is equal to Base36 3W5E11264SGSF.
So in the worst case it's not quite as compact as the 4 digit addresses you're thinking of, I don't think. Still, I'd like to see equipment manufacturers / software developers include the ability to enter IPv6 addresses in a form besides hex, since I'm unconvinced that it's the most convenient way for humans to represent them. (I'd never given much thought to base-32 but maybe that's a good compromise; it preserves the ability to break it up by octet -- although I don't know how necessary that is anymore with CIDR.)
Yes, but this is pretty ugly.
It shouldn't have to be this way. If every device had a globally-unique, routable address, you wouldn't have to have nasty NAT-traversal hacks, or use SIP/IAX trunking nearly as often. It would still be possible to set up a single "front office" line that then redirected to various extensions, but it wouldn't always have to be that way.
And really, I doubt that many people -- if they had the choice -- would choose to have one phone number plus an extension, if they could have unique direct-dial phone numbers for everyone in the office plus a front-office line. (Sure, there are exceptions, like callcenters, but they're not really the rule.) But with NAT you get stuck setting up SIP proxies and trunks, and giving users extensions, far more often than is really necessary in order to accomplish what the users want in the optimal case.
As an aside: most users don't really even understand what an end-to-end VoIP system might look like, because they're still thinking about it in terms of POTS. If you have SIP everywhere, you don't even have "phone numbers", much less extensions. You have email-style user@domain.tld addresses, and the call magically routes to wherever that user happens to be at that particular moment in time. Calling a phone, as opposed to a person, will one day seem pretty antiquated and strange, I think. (And before anyone says that users will never accept this or that it'll never happen -- how many people have contacts in their cell phones' addressbook that they don't know the numbers for? I thought so. We're already most of the way there.)
More generally: It's always a bit strange to argue about IPv6, because people always claim that it's unnecessary because nothing we do right now requires it. Well, of course nothing we do right now requires it -- if it did, we wouldn't be using it, because IPv6 isn't widespread. Everything we do right now we can do over IPv4, because IPv4 is basically all there is. But that doesn't mean that IPv4 is good, or there isn't a whole lot of really neat stuff that we could do (stuff like VoIP mobile roaming) if we weren't stuck making everything work in the IPv4 framework.
That's not really an inbound/outbound traffic issue -- you might as well just block all connections using port 25 to those machines. If you're blocking outbound on 25, there's little reason why you'd want to allow inbound connection attempts on 25 either. (Given that the stated goal of blocking outbound attempts in the first place is to stop users from running what are effectively mailservers -- albeit spammy ones.)
So really you're just talking about blocking port 25 in both directions. If you were using a hypothetical IPv6, non-NATing firewall, you'd accomplish the same task by just turning off port 25, period. (Although any firewall would allow you to block outbound/inbound independently if you wanted to, I'm suspect, unless it was a very low-grade consumer device.)
That's a lot of expense saved if they can delay switching over for a year.
A whole lot of that savings would probably get eaten up by lawyers.
Assume for a second that a company currently has an /8. For them to switch to NAT -- which would only be useful for a year or two, because that's how long we're delaying IPv6 by, with all this screwing around -- would cost a lot of money. They're not just going to let go of their allocation willingly. They're going to drag their feet using every method available to them, for as long as possible, right up until fighting becomes more expensive than giving in.
Even assuming rational behavior (which isn't a safe assumption), in the worst case they might spend just as much on lawyers, fighting the allocation-grab, as the NAT conversion will cost, and the entity trying to wrest their allocation away from them will have to match or exceed this spending in order to win. (Maybe even outspend them by a lot -- all the company has to do is delay for a couple of years until it becomes a moot point because IPv6 has already happened; this is easy and comparatively cheap -- look at SCO.) So the total broken-window loss as a result of this, to all parties involved, is quite possibly twice the amount of converting the company to NAT. And the amount of converting a huge multinational company to NAT might be staggering; there's no telling how much grimy legacy stuff they might have to fix. It's probably a Y2K-level problem.
And that's without getting into who exactly is going to take on, single-handedly, some of the biggest companies in the world. ICANN is effectively part of the U.S. Department of Commerce, who are typically friends of business anyway. I don't think it would take too many phone calls (or bags of cash) from IBM, GM, Ford, Halliburton, etc. to squash any plan that would cost them millions of dollars and put them at a disadvantage. Particularly in the current political climate, it could easily be spun to look like sacrificing American business for the benefit of the Chinese -- it's a political nightmare.
The refrigerator is a poor example, but other appliances and home HVAC systems could realize significant energy savings by communicating with each other, and by being controlled remotely over the internet (or some other means).
There are a lot of interesting scenarios: if you had real-time, fluctuating power pricing, you might want to have appliances change their energy consumption or other settings in response to their cost. Only run some appliances when the spot price is below $0.15/kwh, for example.
Or even simpler, if you have a peak-load factor as a component of your bill, devices could communicate with each other to ensure the total draw at any one time doesn't exceed some predetermined maximum. Different appliances would each have a priority, and would have to shut down to accommodate higher-priority draws. (E.g.: the clothes dryer would shut off if you turned on the electric stove or microwave, because it would have a lower priority -- unless you were really obsessive about not having wrinkled clothes, I suppose, in which case you could set it the other way around.)
The two could be combined, as well: once you have the infrastructure in place, you could set up whatever rules you wanted, balancing preferences for certain services against costs, and prioritizing certain services at various times. It wouldn't be hard to produce detailed reports of what each appliance/service was costing to operate, and how new rules would affect costs based on past usage patterns. (There's the potential for a lot of complexity in the control system, but to a user it might seem very simple on the surface.)
Also, there's a wide range of appliances that really only need to run when people are in the house (or just before they enter the house) but tend to run continuously because it's a PITA to run them based on inflexible timers: HVAC, lighting, water heaters, possibly even water pressure-pumps. Devices would only be turned on when necessary for another device, or a user need was anticipated. I could easily imagine a system that was plugged into an online calendar and controlled this in a way that hid it from the user as much as possible. Heck, if you had a PDA with GPS, you wouldn't have to do anything.
The driving force behind "home automation" up until now has mostly been the geek factor of controlling all your lights/appliances/whatevers from a single point, but I think in the future, energy savings and integration will be the selling point. Since it seems unlikely that we'll really make significant inroads on alternative sources of energy before we start to run low on petroleum, there's a non-trivial chance that energy may become staggeringly expensive. I could easily see a future where the running costs of energy-intensive appliances greatly exceed -- even to the point of triviality -- their purchase price.
Couldn't you send an email containing a URL, which when clicked sends the user to a page that checks for the presence of a browser cookie (set, over HTTPS, when they submitted the recovery request), and lets them set a new password?
That would seem to eliminate a host of problems: it doesn't require storing the user's password in plaintext in a DB somewhere (it's a 'password change' system, not a 'password recovery' one), it doesn't send out any critical information via email, and it doesn't let someone who intercepts the email en route do anything with it. Yet it's still more secure than just doing the whole password-change procedure over the web, because it ensures that the user has control over (or at least access to) the email address that's on file.
The only requirement it creates is that the user click on the email link from the same computer (and using the same browser) that they submitted the request with. Since ideally you'd want them to reset the password quickly after submitting the request, this doesn't seem onerous.
If they're so worried about it, they're in the perfect position to open up their own newsgroup service and charge a few bucks a month. There's no way this wouldn't be profit, as they would no longer have to pay for much bandwidth if they just downloaded EVERYTHING once and then updated as necessary when someone changed something.
They're not really in a position to do this; they don't even run their own Usenet service anymore -- it's farmed out to Giganews. (Not a bad thing, Giganews is far more competent than I think Comcast would be running their own spool.) By cutting off Usenet access I expect all they're really doing is eliminating the money they pay to Giganews every month.
The logical choice if you're a Comcast user affected by their decision is just to go to Giganews and sign up privately. That would get you the same service, and run you about $8USD/mo. (That's for the 2GB cap, which is what Giganews-via-Comcast allowed.)
Anyway, I think your overall sentiment -- it's cost-cutting under the guise of "think of the childrenn!!!111" -- is spot on.
This is precisely why most commercial software that supports Linux, doesn't support "Linux."
Instead they support "RHEL 5.2", "SuSE 10", "Ubuntu 8.04", etc. Those are all specific, identifiable pieces of software that a user could conceivably go out, download or buy, and install on their hardware. Each of them have teams of people concentrating on making them into basically stable development targets (some moreso than others, sure). Supporting "Linux" could mean any number of things. If your software runs only on Ubuntu, is it really "Linux" compatible? Sure, in a way -- but RHEL users probably won't be pleased.
It's not unreasonable for a vendor to specify a particular distro, especially if you're talking about enterprise software (where the software generally dictates the platform/OS choice), and doubly so when the OS being dictated doesn't cost anything or come with any real strings attached.
People bash Microsoft because they've managed to do something that many of us who've been around for a while thought was impossible: they produced an OS so architecturally ugly, it makes Unix -- the system that inspired "Worse is Better" -- seem elegant by comparison.
I meant to write "NewsBank" where I wrote "NewsWire". I don't know where "NewsWire" came from ...
Probably because NewsBank wouldn't sell it to them if they knew Google was going to release it all for free.
I mean, unless Google was prepared to pay NewsBank more than the sum total of all their current subscribers, they'd be stupid to go along with that plan. Their business depends on charging for information that Google wants to provide to everyone for free; they're not going to take to that very kindly.
Maybe Google could just buy NewsWire outright, and with them get their collection/database, if that were cheaper than digitizing from microfiche than I'd say that's a good plan. But that might be prohibitively expensive if NewsBank has other lines of business besides selling access to their archive that would inflate their cost beyond the value of the archive itself.
More germaine would be President Bush and Vice President Cheney's drunk driving covictions. I'd say something that could result in people getting killed is a lot more serious than streaking.
Well, Ted Kennedy actually killed somebody and it doesn't seem to have kept him out of politics.
The electorate doesn't seem to care unless you're buggering somebody (aside from simply "America" generally); that they'll break out the pitchforks for.
Ah, yes. 3M Fluorinert. That stuff seems to pop up here in discussion every once in a while. I don't believe they actually manufacture it anymore -- what you can buy is basically "New Old Stock" -- and it's staggeringly expensive. (For the home hobbyist, anyway; if you're actually maintaining a Fluorinert-cooled system in production, it's probably nothing.)
The common alternative you can play with at home is mineral oil, although it's not nearly as good. What makes Fluorinert useful is its relatively low boiling point. It's liquid at room temperature and on most idle parts, but on a hot component, it will boil. It's the boiling, not just the submersion in liquid, that draws the heat away so effectively. Most home liquid-submersion experiments miss this entirely.
Personally I've always wondered about coolant solutions that use the solid/liquid state change rather than the liquid/gas one; maybe a slurry of solid, low-melt-point crystals suspended in a liquid carrier. I've worked with some plasticizers that have basically room-temperature freezing points, but I've never seen that particular property taken much advantage of. (Most of them actually become more dense as they freeze, rather than less dense like water, so you could put your hot parts at the bottom of a tank filled with slurry, and when the coolant melted the liquid would rise to the top and more frozen coolant would fill in over the part. It would be similar to Fluorinert boiling, but without the gas production.)
$12hr PT IT job where a CS degree is required for consideration
When there are CS grads willing to work for $12/hr PT, that's what their skills are going to be worth. I mean, do you seriously think that someone with a CS degree shouldn't be allowed to work for $12/hr, if that's what they want to do, or need to do in order to get a job?
Replace "CS grad" for a minute with "English major". We've all heard the stories about kids graduating with English (or Anthropology, or Sociology, or any number of other 'useless' majors) degrees and having to work at Pizza Hut, or working as filing assistants in some dank basement somewhere. It's understood that they're going to end up working for peanuts, because there are too damn many of them competing for too few really good jobs. So a few rockstars get the cool jobs in their fields, while the rest do scut work and dream of grad school. That's kind of what you get for majoring in a field that there's very little demand for.
There's nothing any different about CS: sure, it's a technical field rather than a liberal arts one, but it's not immune to saturation, either. There's nothing about CS, or Engineering, or Physics (or anything else) that's supposed to automatically mean that you get a job after graduation. Universities have been turning out low-quality CS grads for years, and that's taken its toll on the market.
That said, there's still a huge demand for really good CS people (and really good engineers, etc.); if you're working one of the $12/hr jobs, either you're selling yourself short, or you're really not that good.
There is no magic solution to this. A lot of CS people got the idea in their heads back during the 90s that having IT skills should and would automatically guarantee anyone a decent job for the rest of their life, even if they don't work hard to stay on top of their game. That's just not true and there's no reason why it ought to be true. The late 90s tech boom was a fluke; it was the exception, not the rule. Now the supply -- colleges and people going into college and picking majors -- has caught up with demand, and IT is like anything else: you can make a lot of money if you're very good, you can probably scrape along if you're only better-than-average, and you can starve or find something else to do if you're untalented.
There's nothing to 'fix' there, because that's not a problem. IT is not gnosticism; it's not some secret priesthood. If lots of people want to try their hand at it, they shouldn't be prevented from doing that. Just because someone got to the party earlier, or happened to be born earlier, doesn't mean they should be able to keep someone more talented than they out of the field -- and that's exactly the effect that protectionist laws or union rules would have.
A company is (generally) free to fire union members who strike and replace them with others.
I'm not aware of any U.S. state where this is broadly the case. Generally, companies have to negotiate with unions, and there's a whole process (time-consuming, expensive) that needs to be gone through before a company can effectively tell the union to get lost.
I wouldn't have nearly as much of a problem with unions if they weren't entrenched by legislation; if they existed purely as part of the labor market, they'd be fine. Workers ought to be able to band together and bargain collectively, if they want to and believe that it'll get them a better deal as individuals. But companies also ought to be able to fire them all and re-hire people off of the street. Unfortunately that's not how it works in most cases.
The reason I'd like to see union-protecting legislation eliminated isn't because I hate unions on principle, it's because I hate what unions become when they're protected artificially like that: rather than existing for the good of all workers, or all workers in a particular industry or with a particular skillset, they become nothing more than an extortion scheme for a small number of members, at the direct expense of other workers with similar skills who are kept out of jobs.
If unions weren't protected by legislation, in order to bargain effectively (and not just be told to get lost by employers), they would need to recruit a large percentage of available works in a market segment. It wouldn't be enough to just let people currently holding a job into the union, you'd need to also let all the people who are potential employees into the union. You wouldn't be able to use the union as a way of disempowering otherwise employable people, at least not in large numbers, which is exactly what they do now.
Not necessarily. You just need to do sanity checks all the way up the chain. Fixing the protocol is definitely the way to go, long term, but in the immediate future the problem can be minimized if everyone keeps an eye on those downstream from them.
It's much the same as with forged route advertisements. ISPs have to monitor and not unquestioningly accept routes from end users/customers. If some guy on a cable modem suddenly starts advertising routes to Yahoo.com's servers, it's probably best to not pass that advertisement along without looking into it first. Likewise, that ISP's ISP (in the case of a local or regional ISP) or the backbone provider or peers (in the case of a large ISP) need to check advertised routes before accepting them as well, in case the original ISPs admins get lazy and accept a route that they shouldn't.
It's a lot of work, but everyone needs to be diligent and critically evaluate information that's flowing up and asking to be propagated before they pass it along, from local ISPs all the way up to backbone providers.
> So Firefox's solution has been make it hard to pick the unsafe choice.
Except they really haven't. They've made it hard to make the sorta-kinda-theoretically-less-safe choice, the one that might result in a MITM attack, but in doing so they discourage SSL use generally.
Do you think that hypothetical user you're talking about is going to notice whether the page is using SSL or not? I doubt it. And a lot of companies seem to agree, and use plain old HTTP for all sorts of stuff when they shouldn't (we just had an FPP on this a few days ago, in fact).
As script-kiddyable as MITM attacks may get, they're never going to be as easy as just sniffing unencrypted traffic, and any time you make encryption difficult or complicated, that's the alternative people use.
That question doesn't even address the bigger issue, IMO, which is that releasing toxins into the environment leads to birth defects and chronic illnesses -- essentially guaranteeing generations of people who will be permanently disabled as a result of the activity. (Also, their are some tentative links between even mild heavy-metal poisoning during childhood and violent tendencies later in life; not only might you be creating thousands of people with birth defects or mental retardation, but you might be dooming an entire society to increased violence and crime as a result.)
There's a reason why places with functioning governments almost universally don't allow this sort of thing. The social costs are vastly greater than the benefits it brings to the people who actually do it, and many of the people who end up paying the price never asked to be involved at all. They just happen to have the misfortune of living downwind, downstream, on the same coast, or drinking from the same aquifer. That, by itself, makes it a morally bankrupt activity -- nothing justifies poisoning others who never asked to be involved.
Just because someone is starving doesn't give them a blanket license to harm others. It might make their actions understandable and perhaps even morally justifiable on an individual level, but it doesn't mean that it ought to be allowed as a matter of policy. Food shortages are a tractable problem -- the immediate solution, at least, is straightforward. However once an area has been contaminated with toxic waste, and especially once the population has a high level of birth defects secondary to toxic exposure, it can take generations to even realize the scope of the problem.
If they discovered that you were keeping 200 cats in your home under extremely unsanitary conditions, they would do the same thing: move all of the cats to a shelter somewhere, and charge you with violating local health regulations once they had assessed the entire situation.
Much as I like cats and wish a slow, painful death on anyone who's cruel to domestic animals, I wouldn't want the authorities busting in and confiscating anyone's cats without a warrant, either. I'd want them to go through the proper procedure, which involves ensuring there's probable cause that something illegal is going on (including, specifically, what law is being violated), getting a warrant, and then going in and dealing with the situation.
There is a reason why our legal system has only very narrowly-defined exceptions to the rules requiring warrants (or at least, it used to) -- it's that process that keeps us from falling off the very steep cliff that ends with a police state.
Sure, there's something to be said for using them as an educational tool, but again, you're still better off getting a newer high powered box and just running a virtualization environment on it to mess around with distributed parallel computing environments.
I'm not so sure this is true. When considering the purchase of a brand-new computer, you need to take into account not only it's "running cost", but also the energy involved in its manufacture.
An older computer might use more energy to operate, but if you already own it, it might make sense to continue using it. A brand new machine may well be more efficient, but will come with a huge 'manufacturing debt' that it has to make up before it's really saving any energy. It takes huge quantities of energy to manufacture a new PC and all the components that go into it.
From a purely economic perspective, all that energy equals money -- you can buy a lot of electricity for the cost of a new PC. If you're not running a machine 24/7, it may not make sense to upgrade it simply for more efficiency, either for environmental or cost-reduction reasons, until it's well and truly obsolete and has to be replaced anyway.
Just as a follow-up ... anyone considering taking e-waste to a recycler should first check to see if the recycler is listed here as having been approved by the Basel Action Network (an anti-dumping group). The list includes "e-Waste recyclers that have agreed to adhere to strict criteria [...] The criteria require that no hazardous electronics equipment or parts (as defined internationally) will be exported to developing countries or be processed by captive prison labor, and that none of it will end up in landfills or incinerators."
As far as I know, it's the only (somewhat) reliable way to know that a "recycler" isn't just exporting the trash to the developing world. Many recyclers talk a lot about the environment, but don't give very many specifics about what actually happens to e-waste you drop off (besides vague platitudes like "in accordance with all State and Federal laws" which means little given how minimal most laws concerning e-waste are). That's because they may just be loading it into containers bound for the other side of the planet.
I'd have some reservations about taking it to many "recyclers". Some actually perform the recycling and metals reclaimation themselves, but many more just take all the equipment to the Third World (Africa and South Asia seem to be popular) and dump it there.
Anyone taking old IT junk for free or without charging significantly for its disposal is almost certainly dumping. Although there is a significant precious-metals content in them, it's not (yet) worth the labor required to reclaim it in the developed world. (Which is why you don't see people soliciting e-waste in the same way they do scrap metal or junk cars.) It's a lucrative business when you can employ starving children to do it, but not so much otherwise.