There is no lack of redundancy in powerlines. The servers all stayed up when the transformer went out. The problem is that AC units are normally not connected to the UPS, since that would increase power-draw to twice normal and result in the UPS failing in half the time. They are connected to the generators however so when outside power fails, the AC units are offlined for only ten minutes. But that is enough to melt the servers nowadays.
That and the fact that the powercircuits are not tested for failures regularly (unlike the generators) leads to problems like this. But testing the powercircuits is a very difficult thing to do. Inducing failures in loaded circuits that dissipate 200 kilowatts or more is no fun, and the transients are hell on everything connected.
Capacity per dollar is dropping faster for SSDs than it is for HDDs. And they are only a factor 30 apart right now. I expect to see them cross in 5 years. And even before that it is already tempting to go SSD, especially for laptops, since the power usage of SSDs is much lower than for HDDs.
People like you said HDDs would never win from tape 10 years ago. And look at the backup market now, HDD is king, tape is dead.
Look up IPv6 multihoming. Then look up IPv6 allocation policies. Add the two together. See that all the small ISPs have no incentive whatsoever to switch to IPv6.
In case you're wondering what I'm talking about, it's the totally stupid IPv6 hierarchical prefix space. If you are not big enough, you don't get a globally peerable/32, you get a/48 from a bigger ISP. But you want to be able to peer with more than just that ISP, so you talk to your other peers. They also give you a/48. And now you have to assign IP addresses from all those/48's to each server you have, or put very complex middelboxes (that NAT one/48 to another) to get connectivity on all/48's. And DNS servers with round robin AAAA records and incredibly short expiry times. See the incredible mess?
And all because the IPv6 committee thinks that prefix growth is bigger than Moore's growth, so routers cannot cope with the whole prefix space. Which is ridiculous of course...
And the only RIR that gets it is ARIN, since they started allocating/32's to anyone, regardless of size. Too bad my company is European.
What I cannot understand is how you Americans can call a 30mpg vehicle 'fuel-efficient'. We Europeans call that average fuel use. Our fuel-efficient cars do 60mpg. Why don't yours?
--Blerik
(Oh, in case you're wondering what vehicle I'm referring to, it's the Volkswagen Polo Blue Motion. And yeah, it's a diesel. And no, that isn't a cussword, diesels are more environmentally friendly than gasoline cars)
Not to mention the problems with "Man in the Middle" attacks. Since quantum encryption doesn't validate the endpoints, you could just cut the fiber and attach two new transceivers and nobody will know. And no, the technique in the article doesn't protect against this. There are only a few ways to get around this problem:
-Monitor the fiber for cuts by keeping it lit at all times. Backhoe accidents will still happen, and then you need to guard the cut and use trusted technicians. -Have huge fiber ducts and patrol them with guards. -Use certificates to validate the endpoints. But then you need to trust public key crypto and then quantum doesn't add anything.
One reason: Gravity. They have it on the moon. They don't have it in orbit. Makes showering, sleeping, eating, everything more comfortable. Plus the fact that you don't have your colonists dying of accidentally bumping into something and breaking all their bones.
A colony implies people living there for longer than 10 years. Zero gravity is a bitch at 10+ years.
Terrorism doesn't exist. Think about it... the number of victims is such an insignificant low number when compared to victims of the flu that it is laughable. And terrorism only thrives on attention. No attention, no terrorism.
So please remember this the next time you spout of about terrorism: Terrorism doesn't exist! (except as a political coin that is)
Let's take a nice big enemy like Iran. They muster about half their reserves (5 million grunts). They have obsolete tanks and guns, who cares. There are 5 _million_ of them. Now all you have to do to fight the American army is disrupt their support lines. Fuck up their harbors and ships. That is all. There is no way in hell the American army can fight (and win) against your army when all their supplies need to be airlifted in. America just doesn't have the airlift capacity.
The only reason America could do the Shock and Awe campaign is the amount of preparation they did. It took months to get all the fuel and ordnance into place, and then they had time for a short (but brutal) campaign. If that war had taken two months longer, America would have 1 option. Retreat.
Check out the Wikipedia article on the 2003 invasion of Iraq. See how preciously little troops America had, and the incredibly short timespan of that war. And they only killed about 10.000 Iraq soldiers. Now try the same scenario against Iran (active army 700.000, reserves 11 million). Please, do the math. And stop believing the PR.
In still scenes you can't. In moving scenes however, it is quite easy to extract the relative depth of moving objects by measuring their relative speed. Try googling for 'optic flow'. And since most 'movies' consist of moving scenes, it is possible to give them a sense of depth by this technology. It is of course impossible to change the POV, because you cannot know how the back of the actor looks like.
No, you are absolutely correct. And what's more, we also have a nice thing called "mandatory ID" a.k.a. "papers please". We have to carry ID at all times and that ID can be requested by almost anyone (there are some minor restrictions related to where you are and who is asking). And now we have to get our ID's registered at the bank as well, or our accounts will be frozen. So privacy is pretty nonexistant here as well.
-sarcasm on- Excuse me? A reference counting implementation that is fast. Could you please post some links to articles describing this magical algorithm? -sarcasm off-
Mark-and-sweep GC or copying GC is _always_ faster than doing reference counting.
Or maybe ATI will make a GPU with built-in memory controller (like xbox360) and HyperTransport bus. No more PCIe or whatever, just a simple and fast HT pipe to the CPU. Puts the GPU closer to main memory (where it needs to be) and looks just like normal memory.
> The speed of code written in computer language is based on the number of CPU cycles required to carry it out.
Nope, not true anymore. The speed of code written in computer language is based on how efficiently it utilizes the cache of the CPU it is running on. Loop unrolling for instance used to be a surefire way to increase speed. Now it just takes up valuable cache space and actually reduces speed. Counting the number of cycles instructions take is pretty irrelevant if a cache-miss takes up 10 times the amount of time the execution of the instruction takes.
Xen version 3 and higher allow for unmodified guests, no need to 'enlighten' the guests anymore. This works only with VT-x enabled Intel chips for now...
What you want is called a balloon driver. It tries to take away memory from the guest operating system to increase memory presure and activate swap. Parallels doesn't have a balloon driver yet. Xen has one, albeit a primitive one. And VMWare has a very nice one.
Downloading a 50Gig movie on 10mbps ADSL-2 takes about a day. On 100mbps fiber it takes 2 hours. (Yes, the kind everybody in Hong Kong already has). The costs for a company when using tier-1 internet connectivity is about $5 per movie per client, just for the transport. But using a cheap upstream (like Cogent) the price drops to below $0.50. So yes, that business model is possible. And when you use BitTorrent or usenet to distribute the movies, the bandwidth is essentially free. (And providers like usenet, put one big server inside your network where bandwidth is cheap and 1000 clients turn into 1)
The diagram is of the SMART-1 ion drive, with acceleration grid and neutralizer. This new engine doesn't need an acceleration grid or a neutralizer which leads to less wear and tear, and more efficiency (no useful ions hitting the grid, no useful ions return to the engine because the neutralizer didn't neutralize them).
> Most of the technological hurdles in connectivity have been overcome
Multihoming is not fixed yet, and basically cannot be fixed within IPv6 (hierarchical address space and multihoming don't like each other). The current hack to fix this is give out addresses from all ISPs you want to connect to and have the _endpoints_ negotiate which address to use (proposal is called SHIM6, google for it). So basically, the network engineer needs root/administrator access to all endpoints in the network to do his/her work.
Now, should I drop one of my peers (and lose my redundancy) just to use IPv6, or just keep my IPv4 addresses until the end of time?
And everybody knows what a broken piece of insecure crud that is. Give me SSL any day.
# Authentication: X.509 within IPSec
Ooh goody, I cannot wait to pay $300 per server to get my x509 certs.
# Fragmented Packets:
Path MTU not good enough for you?
# Latency:
one word - MPLS.
# Multicasting:
Too bad nobody has made a workable protocol for it yet.
# Anycasting:
Brilliant, but what happened to broadcasting?
# Autoconfiguration:
It's called DHCP. Oh, and why sacrifice 64 of the 128 address bits for it? Seems excessive.
# Mobility:
And is based on Mobile IP which works fine over IPv4.
# Advanced Headers:
But nobody except the endpoint can look at them. And the endpoint already looks inside the packet. So what is this good for?
# High Availability:
Oh? So multihoming is not a problem anymore? They fixed this already? Nope, because they cannot fix it. See shim6 for an example of an ugly hack...
# Tunneling: There is no agreed method of tunneling in IPv4
VPN? Okay, that uses IPSec so that doesn't count. SSL? Cannot connect a network to a network. Hmmm, maybe tunneling is a very generic concept and we need to have multiple protocols to get everything we want. IPv6-over-IPv6 doesn't do layer-II networking because IP is already layer-III. So there will always be a layer-II tunneling protocol as well. So there will not be a single tunneling concept in IPv6 as well.
# Clusters: Infiniband cooperates well with IPv6
Okay... nice corner case. Too bad most everything else isn't compatible with IPv6 yet.
# Reachability: IPv6 can reach all IPv4 nodes
And IPv4 cannot ever reach any IPv6 nodes. So a new business always needs IPv4 addresses to get to a sufficiently large client base.
---
The biggest problem with IPv6 is that it is revolutionary instead of evolutionary. That is why overlay networks are already much more succesfull now.
Iff IPv6 supports proper multihoming without nasty hacks, then I'll give it another look. Until then it's IPv4 for me.
And that address hierarchy leads to problems when multihoming... so IPv6 doesn't support it*. Brilliant! I cannot wait to kill of all of my peers but one, so I can use IPv6.
--Blerik
*Look up shim6 and multi6 for proposals (I should say hacks) to fix this. Basically, you need to get addresses from all of your providers, and your endpoints (the servers, not the routers or the firewalls) bear the brunt of redundant routing. Absolutely brilliant!
When I manage a webserver there are two different types of access needed:
-web traffic from the outside -management traffic from the inside
This is where the firewall comes in. I especially don't want people trying to get into management on the server even though the passwords are solid.
And no, you don't want to solve this with a management interface on the server, then anybody that gets into the server can get to the management of all the servers.
I agree that the server itself should be secured as well, but see the firewalls as 'defense in depth'.
Well, if it acts as a solar sail, station keeping should be pretty simple. Just use the force the sail generates to keep the sail in position. If the force is big enough, you don't even have to keep it near L1.
The only fix that kinda works is disabling hyperthreading. But on a dual core processor the problem is there as well (if there is a shared cache somewhere). And switching of the second core because of that would be stupid.
The problem Colin points out (getting an RSA key) is a userland problem anyway, so there is nothing to fix for Linus... fixing cache eviction covert channels in the kernel is possible, but not without losing a lot of performance.
Nobody uses this because if you try to force people to use passwords they can't remember, they write them down. Just like forcing people to get a new password every month makes them use counter passwords.
A better solution are passphrases, easy to remember and difficult to crack because of their length. Too bad most software won't allow you to use long passwords.
Slashdot Mirror
There is no lack of redundancy in powerlines. The servers all stayed up when the transformer went out. The problem is that AC units are normally not connected to the UPS, since that would increase power-draw to twice normal and result in the UPS failing in half the time. They are connected to the generators however so when outside power fails, the AC units are offlined for only ten minutes. But that is enough to melt the servers nowadays.
That and the fact that the powercircuits are not tested for failures regularly (unlike the generators) leads to problems like this. But testing the powercircuits is a very difficult thing to do. Inducing failures in loaded circuits that dissipate 200 kilowatts or more is no fun, and the transients are hell on everything connected.
--Blerik
Capacity per dollar is dropping faster for SSDs than it is for HDDs. And they are only a factor 30 apart right now. I expect to see them cross in 5 years. And even before that it is already tempting to go SSD, especially for laptops, since the power usage of SSDs is much lower than for HDDs.
People like you said HDDs would never win from tape 10 years ago. And look at the backup market now, HDD is king, tape is dead.
--Blerik
Look up IPv6 multihoming. Then look up IPv6 allocation policies. Add the two together. See that all the small ISPs have no incentive whatsoever to switch to IPv6.
/32, you get a /48 from a bigger ISP. But you want to be able to peer with more than just that ISP, so you talk to your other peers. They also give you a /48. And now you have to assign IP addresses from all those /48's to each server you have, or put very complex middelboxes (that NAT one /48 to another) to get connectivity on all /48's. And DNS servers with round robin AAAA records and incredibly short expiry times. See the incredible mess?
/32's to anyone, regardless of size. Too bad my company is European.
In case you're wondering what I'm talking about, it's the totally stupid IPv6 hierarchical prefix space. If you are not big enough, you don't get a globally peerable
And all because the IPv6 committee thinks that prefix growth is bigger than Moore's growth, so routers cannot cope with the whole prefix space. Which is ridiculous of course...
And the only RIR that gets it is ARIN, since they started allocating
--Blerik
What I cannot understand is how you Americans can call a 30mpg vehicle 'fuel-efficient'. We Europeans call that average fuel use. Our fuel-efficient cars do 60mpg. Why don't yours?
--Blerik
(Oh, in case you're wondering what vehicle I'm referring to, it's the Volkswagen Polo Blue Motion. And yeah, it's a diesel. And no, that isn't a cussword, diesels are more environmentally friendly than gasoline cars)
Not to mention the problems with "Man in the Middle" attacks. Since quantum encryption doesn't validate the endpoints, you could just cut the fiber and attach two new transceivers and nobody will know. And no, the technique in the article doesn't protect against this. There are only a few ways to get around this problem:
-Monitor the fiber for cuts by keeping it lit at all times. Backhoe accidents will still happen, and then you need to guard the cut and use trusted technicians.
-Have huge fiber ducts and patrol them with guards.
-Use certificates to validate the endpoints. But then you need to trust public key crypto and then quantum doesn't add anything.
So quantum crypto is still useless.
--Blerik
One reason: Gravity. They have it on the moon. They don't have it in orbit. Makes showering, sleeping, eating, everything more comfortable. Plus the fact that you don't have your colonists dying of accidentally bumping into something and breaking all their bones.
A colony implies people living there for longer than 10 years. Zero gravity is a bitch at 10+ years.
--Blerik
Bollocks!
Terrorism doesn't exist. Think about it... the number of victims is such an insignificant low number when compared to victims of the flu that it is laughable. And terrorism only thrives on attention. No attention, no terrorism.
So please remember this the next time you spout of about terrorism: Terrorism doesn't exist! (except as a political coin that is)
--Blerik
Not really.
Let's take a nice big enemy like Iran. They muster about half their reserves (5 million grunts). They have obsolete tanks and guns, who cares. There are 5 _million_ of them. Now all you have to do to fight the American army is disrupt their support lines. Fuck up their harbors and ships. That is all. There is no way in hell the American army can fight (and win) against your army when all their supplies need to be airlifted in. America just doesn't have the airlift capacity.
The only reason America could do the Shock and Awe campaign is the amount of preparation they did. It took months to get all the fuel and ordnance into place, and then they had time for a short (but brutal) campaign. If that war had taken two months longer, America would have 1 option. Retreat.
Check out the Wikipedia article on the 2003 invasion of Iraq. See how preciously little troops America had, and the incredibly short timespan of that war. And they only killed about 10.000 Iraq soldiers. Now try the same scenario against Iran (active army 700.000, reserves 11 million). Please, do the math. And stop believing the PR.
--Blerik
In still scenes you can't. In moving scenes however, it is quite easy to extract the relative depth of moving objects by measuring their relative speed. Try googling for 'optic flow'. And since most 'movies' consist of moving scenes, it is possible to give them a sense of depth by this technology. It is of course impossible to change the POV, because you cannot know how the back of the actor looks like.
--Blerik
No, you are absolutely correct. And what's more, we also have a nice thing called "mandatory ID" a.k.a. "papers please". We have to carry ID at all times and that ID can be requested by almost anyone (there are some minor restrictions related to where you are and who is asking). And now we have to get our ID's registered at the bank as well, or our accounts will be frozen. So privacy is pretty nonexistant here as well.
--Blerik (from Holland)
>It's also very fast
e s.htmlf
-sarcasm on-
Excuse me? A reference counting implementation that is fast. Could you please post some links to articles describing this magical algorithm?
-sarcasm off-
Mark-and-sweep GC or copying GC is _always_ faster than doing reference counting.
references:
http://www.hpl.hp.com/personal/Hans_Boehm/gc/issu
http://www.cs.umass.edu/~emery/pubs/gcvsmalloc.pd
http://en.wikipedia.org/wiki/Reference_counting
--Blerik
Or maybe ATI will make a GPU with built-in memory controller (like xbox360) and HyperTransport bus. No more PCIe or whatever, just a simple and fast HT pipe to the CPU. Puts the GPU closer to main memory (where it needs to be) and looks just like normal memory.
--Blerik
> The speed of code written in computer language is based on the number of CPU cycles required to carry it out.
Nope, not true anymore. The speed of code written in computer language is based on how efficiently it utilizes the cache of the CPU it is running on. Loop unrolling for instance used to be a surefire way to increase speed. Now it just takes up valuable cache space and actually reduces speed. Counting the number of cycles instructions take is pretty irrelevant if a cache-miss takes up 10 times the amount of time the execution of the instruction takes.
--Blerik
Xen version 3 and higher allow for unmodified guests, no need to 'enlighten' the guests anymore. This works only with VT-x enabled Intel chips for now...
--Blerik
What you want is called a balloon driver. It tries to take away memory from the guest operating system to increase memory presure and activate swap. Parallels doesn't have a balloon driver yet. Xen has one, albeit a primitive one. And VMWare has a very nice one.
--Blerik
Downloading a 50Gig movie on 10mbps ADSL-2 takes about a day. On 100mbps fiber it takes 2 hours. (Yes, the kind everybody in Hong Kong already has). The costs for a company when using tier-1 internet connectivity is about $5 per movie per client, just for the transport. But using a cheap upstream (like Cogent) the price drops to below $0.50. So yes, that business model is possible. And when you use BitTorrent or usenet to distribute the movies, the bandwidth is essentially free. (And providers like usenet, put one big server inside your network where bandwidth is cheap and 1000 clients turn into 1)
--Blerik
The diagram is of the SMART-1 ion drive, with acceleration grid and neutralizer. This new engine doesn't need an acceleration grid or a neutralizer which leads to less wear and tear, and more efficiency (no useful ions hitting the grid, no useful ions return to the engine because the neutralizer didn't neutralize them).
--Blerik
Since you are not an ISP, you are not required to keep these records. Your ISP (or Colo) however will need to keep logs.
--Blerik
> Most of the technological hurdles in connectivity have been overcome
Multihoming is not fixed yet, and basically cannot be fixed within IPv6 (hierarchical address space and multihoming don't like each other). The current hack to fix this is give out addresses from all ISPs you want to connect to and have the _endpoints_ negotiate which address to use (proposal is called SHIM6, google for it). So basically, the network engineer needs root/administrator access to all endpoints in the network to do his/her work.
Now, should I drop one of my peers (and lose my redundancy) just to use IPv6, or just keep my IPv4 addresses until the end of time?
--Blerik
# Security: IPv6 mandates IPSec
And everybody knows what a broken piece of insecure crud that is. Give me SSL any day.
# Authentication: X.509 within IPSec
Ooh goody, I cannot wait to pay $300 per server to get my x509 certs.
# Fragmented Packets:
Path MTU not good enough for you?
# Latency:
one word - MPLS.
# Multicasting:
Too bad nobody has made a workable protocol for it yet.
# Anycasting:
Brilliant, but what happened to broadcasting?
# Autoconfiguration:
It's called DHCP. Oh, and why sacrifice 64 of the 128 address bits for it? Seems excessive.
# Mobility:
And is based on Mobile IP which works fine over IPv4.
# Advanced Headers:
But nobody except the endpoint can look at them. And the endpoint already looks inside the packet. So what is this good for?
# High Availability:
Oh? So multihoming is not a problem anymore? They fixed this already? Nope, because they cannot fix it. See shim6 for an example of an ugly hack...
# Tunneling: There is no agreed method of tunneling in IPv4
VPN? Okay, that uses IPSec so that doesn't count. SSL? Cannot connect a network to a network. Hmmm, maybe tunneling is a very generic concept and we need to have multiple protocols to get everything we want. IPv6-over-IPv6 doesn't do layer-II networking because IP is already layer-III. So there will always be a layer-II tunneling protocol as well. So there will not be a single tunneling concept in IPv6 as well.
# Clusters: Infiniband cooperates well with IPv6
Okay... nice corner case. Too bad most everything else isn't compatible with IPv6 yet.
# Reachability: IPv6 can reach all IPv4 nodes
And IPv4 cannot ever reach any IPv6 nodes. So a new business always needs IPv4 addresses to get to a sufficiently large client base.
---
The biggest problem with IPv6 is that it is revolutionary instead of evolutionary. That is why overlay networks are already much more succesfull now.
Iff IPv6 supports proper multihoming without nasty hacks, then I'll give it another look. Until then it's IPv4 for me.
--Blerik
And that address hierarchy leads to problems when multihoming... so IPv6 doesn't support it*. Brilliant! I cannot wait to kill of all of my peers but one, so I can use IPv6.
--Blerik
*Look up shim6 and multi6 for proposals (I should say hacks) to fix this. Basically, you need to get addresses from all of your providers, and your endpoints (the servers, not the routers or the firewalls) bear the brunt of redundant routing. Absolutely brilliant!
When I manage a webserver there are two different types of access needed:
-web traffic from the outside
-management traffic from the inside
This is where the firewall comes in. I especially don't want people trying to get into management on the server even though the passwords are solid.
And no, you don't want to solve this with a management interface on the server, then anybody that gets into the server can get to the management of all the servers.
I agree that the server itself should be secured as well, but see the firewalls as 'defense in depth'.
Well, if it acts as a solar sail, station keeping should be pretty simple. Just use the force the sail generates to keep the sail in position. If the force is big enough, you don't even have to keep it near L1.
--Blerik
And how will they fix this?
The only fix that kinda works is disabling hyperthreading. But on a dual core processor the problem is there as well (if there is a shared cache somewhere). And switching of the second core because of that would be stupid.
The problem Colin points out (getting an RSA key) is a userland problem anyway, so there is nothing to fix for Linus... fixing cache eviction covert channels in the kernel is possible, but not without losing a lot of performance.
--Blerik
Nobody uses this because if you try to force people to use passwords they can't remember, they write them down. Just like forcing people to get a new password every month makes them use counter passwords.
A better solution are passphrases, easy to remember and difficult to crack because of their length. Too bad most software won't allow you to use long passwords.
--Blerik