Mod parent up. I don't know why this didn't occur to the submitter in the first place. The entire thing could have been done - for free - using Google or any number of Cloud providers.
Large network operators have NO EXCUSE. They knew this was coming and their profit margins are wide enough that they could have thrown money at it.
You're right - we don't have an excuse. But it is amazing how a project like IPv6 falls through the cracks when your business is profit-driven. Marketing can't dress IPv6 up for Joe Sixpack, Sales can't sell it to businesses who are not ready for it, Planning can't afford to justify ripping out every non-IPv6 piece of equipment in the network (from CPE to Core Router), and there is no hope in hell that the Support teams will be given extra money for training on something that is, through and through, an operating expense.
Also, don't forget, large providers are married to equipment vendors. Unless vendors like Alcatel, Cisco, Huawei, Juniper, Nokia, et al., guarantee and support all of their hardware for IPv6, adoption from service provider side will be extremely slow, and will likely only happen with new build. Service-provider NAT is more supported than IPv6 right now, and a lot less expensive to turn on.
Finally, economically speaking, there is more money for us in an IPv4 shortage, because we can charge you for one where we didn't have to before.
I don't think it's a question of "what's the point", but "how high can you go". Considering that a run-of-the-mill Chili pepper runs at about 40 000 SU and can make food unbearable for most of the population, growing a pepper which is almost 40x hotter really only has one use - crowd control. Even if you are a seasoned spice hound and eat Habanero peppers for breakfast (at 200 000 SU), this thing would burn a hole in your stomach lining if you ate it whole.
Where are my mod points. Parent is correct. The function of the IT department is to ensure that the tools are working the way the user expects. It's much easier to enforce blanket policies at the click of a mouse than it is to actually sit down with your users and understand what they do, but these policies should only exist if it has been properly determined they are required. Yes, that means talking to people, assembling cases for/against these policies, and creating plans. If you are half-way decent at your job, you are able to do all of these things.
The odds of finding any documentation stating exactly what happened there is slim to none. Remember, Chernobyl was in the clutches of the Soviet Union at that time. The rest of the world only found out about the disaster once the contaminated winds drifted into nearby countries.
Having said that, it may just be a tale. Only the original residents of Pripyat know for sure. But the point remains the same - 1000 mSv of leakage is hardly anything by comparison.
I believe that Chernobyl will be nothing next to this disaster soon.
I don't know about that... one of the big differences here is that the Chernobyl core was actually exposed, and releasing radioactive materials which killed observers over a kilometer away. Look up the "Bridge of Death" in Pripyat.
By comparison, Fukushima is releasing (only) 1000 mSv per hour - this is concerning, and would poison anyone exposed to it, but compared to Chernobyl (estimates there were 350+ Sv per hour - several orders of magnitude higher), not even in the same ballpark. Furthermore, the option still does exist to cover the leaking reactors in a concrete sarcophagus... but things need to get a lot more dire before that happens, because then you have a permanent radioactive structure.
That does not mean the entire system is autonomous. There may not be a human in the cab of the train, but there are still real-time operators and a team of people supporting the system to ensure it is working. I can guarantee your average car is not maintained as well as these trains. Sure, the safety record is fantastic. But the trains only go two directions and have a well understood top speed. The system is much simpler than coordinating a couple hundred cars on a road.
Most airlines still require two human pilots... the algorithms are supplemental to their skills, not a solution to the "flawed human element" this technology claims to solve.
How would such a system "notice" a heavy animal? Motion tracking does not always work - a lot of critters remain perfectly still near roads, including humans. Infrared would not work, either, during winter conditions - winter coats prevent heat from being emitted. We're already talking about some pretty expensive kit for something that most humans are able to do reliably already.
As for how humans handle a creature popping out in front of them, the answer is actually quite well. There are only four options in this situation: brake, move left, move right, do nothing. Doing nothing can actually be the safest option, unless the system is keenly aware of what is happening in the left and right lanes. What if it tried to dodge the animal by going over the median because it could not sense another vehicle there, which ended up in a head-on collision? Or if the system ran the animal down but the human knew the right lane was free? The system would need to be able to justify every single action it takes during the lifetime of the vehicle, AND THEN that judgment would have to stand up to the scrutiny of insurance companies or the legal system.
And just what is a moose-crossing zone? Does the wildlife adhere to crossing the road in certain locations? I commute 160km a day - 80km per direction, on a highway where the posted speed limit is 100km/hour. Except for the tail end of the journey - Calgary, Alberta - the entire stretch is known for wildlife encounters. The probability is extremely low, but the potential impact of such an encounter - literally, impact - is life threatening. And by virtue of themselves, wildlife is unpredictable. Critters such as deer and moose rarely travel alone, make different decisions based on time of day and day of year (more young creatures in the spring), and can be on top of you in less than a second, regardless of whether there are fences or medians or other drivers on the road.
I realize my particular case is a very small part of the big picture, but it does highlight one area where a human operator is required. It also begs the question - would someone who is used to driving in these conditions ever surrender control inside of a major urban center?
In Hell when I trust my life and the lives of my loved ones to an algorithm, no matter how well written or secure. Humans may be flawed and dangerous operators, but unless this system can operate under all conditions and in all environments, human intuition will trump predetermined logic every time. I'd love to see how this system handles a one ton moose jumping out in front of your car while you're traveling at 100km/hour.
You can call it sheer ignorance, but honestly, if driving is such a drag, DON'T DRIVE. Walk. Bike. Take transit. Carpool. Telecommute. I know you want your own personal gas guzzling chariot - who doesn't - but there are already much more cost effective and safer ways to get from Point A to Point B in most urban centres.
Actually, stateless auto-configuration for IPv6 does allow a random address to be assigned instead of one derived from your MAC address. Furthermore, MAC addresses can be spoofed on any operating system. It can even be spoofed on just about every Internet gateway.
Some ISPs do track MAC/IP assignments per customer, but honestly, there is nothing to gain from them doing so. And since IPv6 assigns addresses derived from the MAC address of the router, there is a good chance your IPv6 Internet address will be quite dynamic.
No, I'm not referring to the fact that he reproduced an historic device. I'm referring to the article itself. From TFA:
Certainly Coster-Mullen's ambitious project is a neat example of the ingenuity that led America to be the first to develop the atomic bomb. But it's also a stark reminder that our most powerful technologies can end up being reworked and used in other ways, by people much less friendly than truck drivers with lots of time on their hands.
Seriously? Someone spends the time to fabricate a replica from the 1940s, validating historical records in the process, and the author thinks it's time to go all fear-crazed? It's akin to panicking over someone building a blunderbuss - without any black powder - and then saying it would be easy for sea-faring pirates to loot our merchant ships with their increased firepower and malicious ways.
It also doesn't help when someone anonymous assumes "ownership" of an article and fights any changes you make to it. Then the whole thing turns into a colossal waste of time, even if you are an academic with something important to say. Unless you're contributing to a niche, your time is better spent working with students or writing for grants.
Someone famous once said "He who would trade liberty for some temporary security, deserves neither liberty nor security."
Just as relevant then as it is now.
Things getting too difficult to handle? Feel like you're being treated unfairly? Go sue someone!
Seriously, this is ridiculous. Perhaps they should pass laws to make businesses more productive instead of trying to make a quick buck by suing everyone else. It's no surprise that a nation filled with lawyers has difficulty competing with countries that actually produce things.
The entire IPv6 situation can be summed up with basic economics: until the cost of acquiring IPv4 addresses exceeds the cost of implementing IPv6 - for developers and service providers alike - a transition will not occur. None of you want to hear it, but Service Provider NAT is actually less expensive than IPv6 right now. A much more likely future scenario instead of widespread IPv6 adoption is that you will be paying extra for a globally routable address instead of a NAT'd address.
Disclaimer: I work for one of the largest telcos in North America.
I work in an organization with 32 000+ employees. There is only one "Reply All" storm per year, and it's usually the fault of the sender for not using BCC in a distribution email. If this is a common thing at your workplace, you need email etiquette training or your mail admins need to get off their asses and properly administer distribution lists. Or even better, delegate the ability to manage the dist lists to group managers.
This is nothing more than an advertisement for a new AOL "feature".
Disclaimer: I work for a major Canadian ISP. The only one not implementing UBB.
I completely agree with your first point... but it does conflict with your second point. There is only so much bandwidth available between Yourself and your Content. The amount of available bandwidth varies depending on where your Content lies - so to say that you expect the maximum speed, all the time, is like saying you expect the entire Internet to be built in a uniform manner, with pipes big enough to support everyone during peak times.
The simple fact of the matter is, you want a Committed Information Rate, or CIR - a promise that you will be given your maximum bandwidth all the time. There are also very good reasons a CIR of even 1 Mbps costs upwards of $500/month - because the service provider will build their network around you, even if it means laying extra fiber to your house. But you still wind up paying for.
The other thing at play here is that the cost of bandwidth changes. Much like gas or electricity. If you truly want to be charged on the actual cost of the bandwidth, the service provider will need to take into account where your traffic is going, and when. The easier solution is just to charge a flat rate. Not at 10000% markup, but at something more like 20 cents/GB. Should cover traffic going just about anywhere.
Protip: Put up a fake "progress" bar on the screen while you are "recovering" the files. Set it for something like 20 minutes. Now you at least have a chance to talk to a girl for that time, unless you're a real sucker and you let her find an excuse to leave you alone for 20 minutes.
Agree. Facebook is not the cause here - marriages are difficult, life-long commitments, and technology provides an easy way out for a lot of people who find themselves unhappy and unwilling to work things out with their partner. Everyone has different reasons for divorce, but the moral of this story is simple - don't make a commitment you can't keep, and don't simply give up when things get difficult.
Seriously, mod this guy up. All too common in our industry is the mentality that the user needs to conform to the technology. If you want to be truly successful in everything you do, try understanding the needs of your users before throwing "solutions" at them.
That is a very interesting idea, but a bit of a nightmare from an ISP perspective. Think about those who deliver TV or phone over your pipe - as soon as you turn on the TV or make a call, it's going to be choppy and terrible while you wait for the Top 40 QoS to kick in. People will instantly change channels or try calling again, only to find the same result. The average user will keep doing this as they look up the number for your call center.
Okay, so the solution is to use the multiple queues, as you describe. TV gets the best, phone gets second best*, everything else is "best effort +1", and BT is "best effort" and throttled when needed. Well, now you've added an entirely new QoS queue to your ISP router for the majority of traffic. These router will contain several thousand customers, now it is performing several thousand more QoS calculator per second. This costs the ISP money, as they need better equipment. Much easier to leave three QoS queues, everything else lumped as Best Effort, and BT throttled into oblivion. We might see this idea emerge in a few years, or something similar.
*TV makes the ISP more money - therefore, it gets a higher QoS profile than phone calls. Even if those phone calls are to 911. Makes you think, doesn't it?
Slashdot Mirror
Mod parent up. I don't know why this didn't occur to the submitter in the first place. The entire thing could have been done - for free - using Google or any number of Cloud providers.
Large network operators have NO EXCUSE. They knew this was coming and their profit margins are wide enough that they could have thrown money at it.
You're right - we don't have an excuse. But it is amazing how a project like IPv6 falls through the cracks when your business is profit-driven. Marketing can't dress IPv6 up for Joe Sixpack, Sales can't sell it to businesses who are not ready for it, Planning can't afford to justify ripping out every non-IPv6 piece of equipment in the network (from CPE to Core Router), and there is no hope in hell that the Support teams will be given extra money for training on something that is, through and through, an operating expense.
Also, don't forget, large providers are married to equipment vendors. Unless vendors like Alcatel, Cisco, Huawei, Juniper, Nokia, et al., guarantee and support all of their hardware for IPv6, adoption from service provider side will be extremely slow, and will likely only happen with new build. Service-provider NAT is more supported than IPv6 right now, and a lot less expensive to turn on.
Finally, economically speaking, there is more money for us in an IPv4 shortage, because we can charge you for one where we didn't have to before.
It may seem funny when these things actually factor into buying a house or not, but they can be a deal-breaker for some.
I don't think it's a question of "what's the point", but "how high can you go". Considering that a run-of-the-mill Chili pepper runs at about 40 000 SU and can make food unbearable for most of the population, growing a pepper which is almost 40x hotter really only has one use - crowd control. Even if you are a seasoned spice hound and eat Habanero peppers for breakfast (at 200 000 SU), this thing would burn a hole in your stomach lining if you ate it whole.
Where are my mod points. Parent is correct. The function of the IT department is to ensure that the tools are working the way the user expects. It's much easier to enforce blanket policies at the click of a mouse than it is to actually sit down with your users and understand what they do, but these policies should only exist if it has been properly determined they are required. Yes, that means talking to people, assembling cases for/against these policies, and creating plans. If you are half-way decent at your job, you are able to do all of these things.
The odds of finding any documentation stating exactly what happened there is slim to none. Remember, Chernobyl was in the clutches of the Soviet Union at that time. The rest of the world only found out about the disaster once the contaminated winds drifted into nearby countries.
Having said that, it may just be a tale. Only the original residents of Pripyat know for sure. But the point remains the same - 1000 mSv of leakage is hardly anything by comparison.
I believe that Chernobyl will be nothing next to this disaster soon.
I don't know about that... one of the big differences here is that the Chernobyl core was actually exposed, and releasing radioactive materials which killed observers over a kilometer away. Look up the "Bridge of Death" in Pripyat.
By comparison, Fukushima is releasing (only) 1000 mSv per hour - this is concerning, and would poison anyone exposed to it, but compared to Chernobyl (estimates there were 350+ Sv per hour - several orders of magnitude higher), not even in the same ballpark. Furthermore, the option still does exist to cover the leaking reactors in a concrete sarcophagus... but things need to get a lot more dire before that happens, because then you have a permanent radioactive structure.
That does not mean the entire system is autonomous. There may not be a human in the cab of the train, but there are still real-time operators and a team of people supporting the system to ensure it is working. I can guarantee your average car is not maintained as well as these trains. Sure, the safety record is fantastic. But the trains only go two directions and have a well understood top speed. The system is much simpler than coordinating a couple hundred cars on a road.
Most airlines still require two human pilots... the algorithms are supplemental to their skills, not a solution to the "flawed human element" this technology claims to solve.
How would such a system "notice" a heavy animal? Motion tracking does not always work - a lot of critters remain perfectly still near roads, including humans. Infrared would not work, either, during winter conditions - winter coats prevent heat from being emitted. We're already talking about some pretty expensive kit for something that most humans are able to do reliably already.
As for how humans handle a creature popping out in front of them, the answer is actually quite well. There are only four options in this situation: brake, move left, move right, do nothing. Doing nothing can actually be the safest option, unless the system is keenly aware of what is happening in the left and right lanes. What if it tried to dodge the animal by going over the median because it could not sense another vehicle there, which ended up in a head-on collision? Or if the system ran the animal down but the human knew the right lane was free? The system would need to be able to justify every single action it takes during the lifetime of the vehicle, AND THEN that judgment would have to stand up to the scrutiny of insurance companies or the legal system.
And just what is a moose-crossing zone? Does the wildlife adhere to crossing the road in certain locations? I commute 160km a day - 80km per direction, on a highway where the posted speed limit is 100km/hour. Except for the tail end of the journey - Calgary, Alberta - the entire stretch is known for wildlife encounters. The probability is extremely low, but the potential impact of such an encounter - literally, impact - is life threatening. And by virtue of themselves, wildlife is unpredictable. Critters such as deer and moose rarely travel alone, make different decisions based on time of day and day of year (more young creatures in the spring), and can be on top of you in less than a second, regardless of whether there are fences or medians or other drivers on the road.
I realize my particular case is a very small part of the big picture, but it does highlight one area where a human operator is required. It also begs the question - would someone who is used to driving in these conditions ever surrender control inside of a major urban center?
In Hell when I trust my life and the lives of my loved ones to an algorithm, no matter how well written or secure. Humans may be flawed and dangerous operators, but unless this system can operate under all conditions and in all environments, human intuition will trump predetermined logic every time. I'd love to see how this system handles a one ton moose jumping out in front of your car while you're traveling at 100km/hour.
You can call it sheer ignorance, but honestly, if driving is such a drag, DON'T DRIVE. Walk. Bike. Take transit. Carpool. Telecommute. I know you want your own personal gas guzzling chariot - who doesn't - but there are already much more cost effective and safer ways to get from Point A to Point B in most urban centres.
+5 Insightful? Methinks you weren't the only one... =)
Actually, stateless auto-configuration for IPv6 does allow a random address to be assigned instead of one derived from your MAC address. Furthermore, MAC addresses can be spoofed on any operating system. It can even be spoofed on just about every Internet gateway.
Some ISPs do track MAC/IP assignments per customer, but honestly, there is nothing to gain from them doing so. And since IPv6 assigns addresses derived from the MAC address of the router, there is a good chance your IPv6 Internet address will be quite dynamic.
Certainly Coster-Mullen's ambitious project is a neat example of the ingenuity that led America to be the first to develop the atomic bomb. But it's also a stark reminder that our most powerful technologies can end up being reworked and used in other ways, by people much less friendly than truck drivers with lots of time on their hands.
Seriously? Someone spends the time to fabricate a replica from the 1940s, validating historical records in the process, and the author thinks it's time to go all fear-crazed? It's akin to panicking over someone building a blunderbuss - without any black powder - and then saying it would be easy for sea-faring pirates to loot our merchant ships with their increased firepower and malicious ways.
It also doesn't help when someone anonymous assumes "ownership" of an article and fights any changes you make to it. Then the whole thing turns into a colossal waste of time, even if you are an academic with something important to say. Unless you're contributing to a niche, your time is better spent working with students or writing for grants.
Someone famous once said "He who would trade liberty for some temporary security, deserves neither liberty nor security."
Just as relevant then as it is now.
Things getting too difficult to handle? Feel like you're being treated unfairly? Go sue someone!
Seriously, this is ridiculous. Perhaps they should pass laws to make businesses more productive instead of trying to make a quick buck by suing everyone else. It's no surprise that a nation filled with lawyers has difficulty competing with countries that actually produce things.
The entire IPv6 situation can be summed up with basic economics: until the cost of acquiring IPv4 addresses exceeds the cost of implementing IPv6 - for developers and service providers alike - a transition will not occur. None of you want to hear it, but Service Provider NAT is actually less expensive than IPv6 right now. A much more likely future scenario instead of widespread IPv6 adoption is that you will be paying extra for a globally routable address instead of a NAT'd address.
Disclaimer: I work for one of the largest telcos in North America.
I work in an organization with 32 000+ employees. There is only one "Reply All" storm per year, and it's usually the fault of the sender for not using BCC in a distribution email. If this is a common thing at your workplace, you need email etiquette training or your mail admins need to get off their asses and properly administer distribution lists. Or even better, delegate the ability to manage the dist lists to group managers.
This is nothing more than an advertisement for a new AOL "feature".
Disclaimer: I work for a major Canadian ISP. The only one not implementing UBB.
I completely agree with your first point... but it does conflict with your second point. There is only so much bandwidth available between Yourself and your Content. The amount of available bandwidth varies depending on where your Content lies - so to say that you expect the maximum speed, all the time, is like saying you expect the entire Internet to be built in a uniform manner, with pipes big enough to support everyone during peak times.
The simple fact of the matter is, you want a Committed Information Rate, or CIR - a promise that you will be given your maximum bandwidth all the time. There are also very good reasons a CIR of even 1 Mbps costs upwards of $500/month - because the service provider will build their network around you, even if it means laying extra fiber to your house. But you still wind up paying for.
The other thing at play here is that the cost of bandwidth changes. Much like gas or electricity. If you truly want to be charged on the actual cost of the bandwidth, the service provider will need to take into account where your traffic is going, and when. The easier solution is just to charge a flat rate. Not at 10000% markup, but at something more like 20 cents/GB. Should cover traffic going just about anywhere.
Protip: Put up a fake "progress" bar on the screen while you are "recovering" the files. Set it for something like 20 minutes. Now you at least have a chance to talk to a girl for that time, unless you're a real sucker and you let her find an excuse to leave you alone for 20 minutes.
Agree. Facebook is not the cause here - marriages are difficult, life-long commitments, and technology provides an easy way out for a lot of people who find themselves unhappy and unwilling to work things out with their partner. Everyone has different reasons for divorce, but the moral of this story is simple - don't make a commitment you can't keep, and don't simply give up when things get difficult.
Seriously, mod this guy up. All too common in our industry is the mentality that the user needs to conform to the technology. If you want to be truly successful in everything you do, try understanding the needs of your users before throwing "solutions" at them.
That is a very interesting idea, but a bit of a nightmare from an ISP perspective. Think about those who deliver TV or phone over your pipe - as soon as you turn on the TV or make a call, it's going to be choppy and terrible while you wait for the Top 40 QoS to kick in. People will instantly change channels or try calling again, only to find the same result. The average user will keep doing this as they look up the number for your call center.
Okay, so the solution is to use the multiple queues, as you describe. TV gets the best, phone gets second best*, everything else is "best effort +1", and BT is "best effort" and throttled when needed. Well, now you've added an entirely new QoS queue to your ISP router for the majority of traffic. These router will contain several thousand customers, now it is performing several thousand more QoS calculator per second. This costs the ISP money, as they need better equipment. Much easier to leave three QoS queues, everything else lumped as Best Effort, and BT throttled into oblivion. We might see this idea emerge in a few years, or something similar.
*TV makes the ISP more money - therefore, it gets a higher QoS profile than phone calls. Even if those phone calls are to 911. Makes you think, doesn't it?