If all the fanzines grouped together and published consistent but incorrect dates (which would obviously not be copyright DataCo), the backlash of fans turning up at the wrong locations (and the resulting civil unrest) would ensure that these royalties disappeared overnight.
Cringley may be a fool, but he's almost right on this one.
There's a saying in networking that you can't buy latency. The speed of light is just too low for Google's AJAX applications to take over the world - for many apps you can never get the latency low enough if you use only a few datacenters.
So, the shipping container is irrelevant to the important part of this story. The key is that for Google to succeed in making online services as effective as desktop applications, they have to get the latency down. And there's only one way to do that, which is to move the servers close to the customers. To do that, they need a lot of data centers, and they need a lot of bandwidth between them, because when you connect they need to move your data to the nearest data center to you. So, they really do need to have a way to provide data centers quickly and easily to places all over the world.
But Cringely doesn't seem to have realized why this is the only way Google can succeed in the long run. It appears you can buy latency after all if you spend enough.
- Fzz
I don't know about that. Ariancespace seems to be doing OK. Sure they don't put people in orbit, but there's no profit in that. However, Ariane 5 ECA can put 10 tonnes in geostationary transfer orbit, so it would certainly be big enough to launch a manned capsule if there was any serious need. From their web site:
Arianespace is the commercial launch services leader, holding more than 50 percent of the world market for satellites to geostationary transfer orbit (GTO). Created as the first commercial space transportation company in 1980, Arianespace has signed contracts for more than 260 satellite payloads.
Wouldn't it benefit Apple in the long run to get more of its software into the public's hands?
Apple is clearly a hardware company, and so they make most of their money from selling hardware. Thus it's very unlikely that Apple would want to support generic x86 boxes.
But Apple has an interesting opportunity here. If they simply ignored people running unlicensed x86 copies, but prevented else anyone selling pre-installed Macs, then they probably wouldn't lose much business. The people who are willing to install MacOS themselves are unlikely to be the people who'd buy Mac hardware in the first place.
However, Apple would gain a lot of mindshare with the kids and with the technically savvy who are happy installing their own OS. In the long run, this will bring many more people to Apple hardware, and to influence their parents/family/employers to buy the supported Apple products.
Four years ago I built a "silent" PC. Very quiet PSU and CPU fan, mid-range Athlon, fanless graphics card, silentdrive enclosure for a (fairly slow) disk.
At first I was really happy, but then when the weather got warmer, it started to be unstable. An extra 80mm fan added to the inside of the PSU cured this temporarily, and was much quieter than anywhere else I could mount it. Then it got unstable again. The usual fluff had slightly restricted the airflow on the CPU fan. Vacuumed it out, and it was stable again. But then the fans started to get noisy. After a year or so, it wasn't nearly so silent. Then it got unstable again due to fluff, and this time I junked the quiet CPU fan/cooler - too much trouble, and not so quiet anymore anyway. In the end the PSU fan got noisy too, mostly I think because the fan was temperature controlled, and the PSU now had enough fluff in it to cause it to run hot. I finally replaced it with a regular PSU because it was more important it worked than that it was silent.
Lessons: quiet fans get noisy. Quiet PSUs get noisy, especially if you can't keep them clean. Silent PCs don't stay that way. If you build a quiet PC, install air filters, especially if it's going to be in a bedroom, and expect to have to replace the fans periodically.
The one thing I expected to fail was the disk in the silentdrive enclosure - it ran rather hot right from the start, but it's still working quietly four years later. At least it encouraged me to keep good backups.
Agreed. The main problem with such automated vigilante DoS tools is that you can't control who they'll be targetted at. The spammers will just send a wave of pretty obvious spam linking to a few high profile sites like the FBI or the Whitehouse or Slashdot, and this service will promptly disappear like all the previous similar services.
I mean who would "want" to buy this?! I hope Linux is ready for the desktop (at least for Joe SP) when this rolls out because this is THE chance for linux to explode into the market.
Unfortunately the choice the public will see is likely to be between:
Buy Longhorn, and be able to view this premium video content.
Run Linux/MacOS/BSD and not be able to view this content.
Sure, it may be possible for someone to crack the encrypted path, and distribute unrestricted versions online. But you can't exactly advertise that in your marketing campaign, whereas Microsoft can advertise this premium content as only being available on Longhorn.
As Phil Zimmerman said (paraphrased) wrapping electronic communication with cryptography is not unlike wrapping your mail in an envelope. Nobody wonders why we don't send everything on postcard..
Another analogy for you: Dave Clark once commented that using cryptography to communicate with a stranger is like meeting that stranger in a dark alley. Whatever happens, there won't be any witnesses.
I guess the lesson is to use the right tool for the right job. No dogma.
If the person talking on a cellphone is talking too loudly, then it's the fact that the person is talking too loudly that is annoying. The fact that the person just so happens to be talking on a cellphone while doing it is irrelevant.
Not entirely. Wired phones feedback part of the signal from the microphone to the earpiece. This audio feedback is a side-effect of simple analog phone design, but it also serves to help you know the line is live, and help you regulate your volume because you can hear yourself well, and so you assume the other person can hear you.
Cellphones don't provide this feedback. Thus one of the clues you get on a wireline phone is missing. Some people seem to need this clue to help them regulate their volume and some people don't.
Another way that cellphones differ is in audio quality. In general, if you can't hear someone well, you increase the volume at which you speak - this is something we learn when we're very young.
Poor cellphone codecs and poor signal strength contribute to the feeling that the other person can't hear you very well, so subconciously you speak louder. Again, different people are affected by this differently, but the effect is pretty common.
So cellphones really are different from wired phones, although not everyone is affected by those differences in the same way.
If the FCC is getting hundreds of thousands of complaints, then there's no way for them to actually investigate these complains. So probably all they can do is count them.
What this means is that any organization that can muster large numbers of complaints about random programs they don't like can cause the system to collapse completely. There'd be no effective way for the FCC to use the complaint system as an alert mechanism.
The only problem with this is that the slashdot crowd aren't nearly as good at organizing as the PTC. So the question is whether we can write python scripts with output that is not detectably different than the PTC's form letters?
Microsoft actually fund quite a bit of research, and not all of it is related to their direct business plans.
As far as I can tell, Microsoft don't want to go head-to-head with Cisco in the marketplace. So they don't really want to be in this market, but they can't afford everyone else (Linux, FreeBSD, etc) to have solutions in this space when they don't. Hence ensuring XORP can run on Windows avoids them getting shut out.
From XORP's point of view, the more people who can run XORP and contribute to its development, the better. Pretty much the same reason Firefox and Apache are available for Windows.
So a curious situation where open-source and Microsoft's interests are fairly well aligned.
And a lot of the concepts in CORBA were previously in the ANSA RPC framework, which dates back to the mid 1980s. Although ANSA wasn't object-oriented at the time, many of the basic concepts are the same.
So if this patent is on the distributed systems middleware aspects, there's certainly likely to be prior art.
Would it make a difference if the public version of the video was time-delayed by (say) 24 hours?
You'd still be able to use it to document police abuses (so long as all the data was appropriately digitally signed), but it would greatly decrease the abuses that criminals could make of it.
Re:Anatomy of a Slashdotting
on
XORP 1.0 Released
·
· Score: 3, Interesting
And here is a graph of the traffic on the primary link between www.xorp.org and the outside world. At least right now, the 30Mb/s peak there is pretty obvious.
Anatomy of a Slashdotting
on
XORP 1.0 Released
·
· Score: 4, Informative
In case you wondered about the wisdom of linking to an ISO, here are our traffic stats.
www.xorp.org is
in California, www2.xorp.org is in London. Both are 6-year old dual 450MHz Xeon machines with 768MBytes of RAM and SCSI disks, running FreeBSD and Apache 1.3.x. Both machines have 100Mb/s access to the Internet.
In 5 hours:
www.xorp.org:
transfered ~30 GBytes
peaked at around 175 simultaneous httpd processes
15 min load average peaked at 0.7.
www2.xorp.org:
transfered ~20 GBytes
peaked at around 75 simultaneous httpd processes
15 min load average peaked at 0.4.
Aggregate bandwidth was ~25Mbit/sec average. I won't know the peak bandwidth without some more analysis, but it's obviously quite a bit more than 25Mb/s. I didn't notice any obvious slowdown on either machine.
I've no idea how typical this is, but I'm always curious about how easily sites seem to die due to slashdotting.
- Mark
Re:Performance is pretty reasonable
on
XORP 1.0 Released
·
· Score: 3, Informative
Take a look at figures 17 and 18 of this paper:
Eddie Kohler et al, "The Click modular router". ACM Transactions on Computer Systems 18(3), August 2000, pages 263-297.
These experiments are a few years old now, but 32-bit PCI hasn't changed in that time, so they should still be valid on non-server-class PCs.
Vanilla Linux topped out at around 80Kpps, whereas
polling gets you over 300Kpps, and the Click optimizations get you nearer 400Kpps.
Similar experiments on FreeBSD with device polling
give results in the same ballpark.
- Mark
Performance is pretty reasonable
on
XORP 1.0 Released
·
· Score: 5, Informative
I don't have results for a new machine with PCI-Express, but a regular 1GHz-class x86 PCs
with 32 bit PCI tops out at about 400K minimum-size packets per second. This is limited by PCI saturation - you get fairly low PCI utilization with small packets. But even so, a $300 PC compares favourably with something like a Cisco 7206VXR (which cost ~$30K about 3-4 years ago). This is assuming you are smart about using interface polling rather that being interrupt-driven. Otherwise you die from interrupt livelock.
This is plenty fast enough for most edge routers, but clearly not going to compete with a Cisco CRS-1 or Juniper core router.
But most of the software in a router is control-plane (routing protocols and the like) and this is what XORP has focussed on to-date. As more people get involved with the project, we'll be able to do more things.
A decade ago no-one thought we'd be running Linux on a supercomputer. But we are. If we can get to the point where XORP is stable enough and fully featured enough for carrier-grade routers, who knows what hardware people will run it on in a few years time.
We are however very committed to keeping XORP as an open-source platform. No matter who uses it commercially, in the long run the only way to open up the router software market is for many boxes from many vendors to run a common open base software platform. With luck and with a lot of help, maybe that can be XORP.
You don't simultaneously join all chatrooms do you?
This is just the same - you'd probably join just a few channels that interest you and that you trust (whatever that means). You could certainly imagine a hierarchical categorization like usenet groups, with some of those channels being moderated or closed to members only.
Thus, a 500 lb. rope might support 500 lbs when there's less than a foot or so in length between the pully and the weight, but might only support 250 lbs when there is a good 100 ft. or so...
Ignoring the weight of the rope itself, probably the main reason for this rule-of-thumb is the difference between dynamic loading and static loading.
If you (accidentally) get something bouncing on a short rope, the bounce will damp out pretty quicky and the period of oscillation is short. If you get something bouncing on a long rope, it will bounce for a while, and the rope is stretched for much longer with each bounce. It doesn't take all that much of a bounce to double the load on a rope, and perhaps take it past its elastic limit.
I'm guessing, but I think that pre-synthetic ropes
probably can be briefly overstretched without losing strength because they knit back together again. If you continuously overstretch them, the fibres probably don't get a chance to recover before the slide past each other a little more, and so on.
So my guess is this doesn't apply nearly so much to modern synthetic ropes. In the case of a space elevator, I'd hope they'd try really hard to avoid excess dynamic loading.
16km is a little too high for a helicopter (they top out at about 7-8km), but it's well within the reasonably altitude range for a large helium baloon.
Could you use the elevator itself to lift the counterweight? You start off with a small counterweight and an even smaller elevator car, and make multiple trips, each one increasing the mass of the counterweight. As the counterweight increases you can bring up more additional counterweight mass each time, until you've got enough to allow you to substitute a larger elevator car.
I've decided that I'm going to keep all my data in online storage - the hard drives in my server. It's backed up (to an external USB2 hard drive) and I'm not going to lose it or find that I can't read it in five years.
You need to be careful with strategies like this.
If the drive you're backing up doesn't fail catastrophically, likely the time you'll discover it's failing is when you're reading it. What do you read the whole drive? When you're backing it up. So you're halfway through doing a backup, overwriting the external drive when you discover that the internal drive is bad. Ooops.
Safest is to have two external drives, and alternate the backups between them. If you can't afford this, then you need to think pretty carefully about how you overwrite data on the external drive, so as to minimize the data you'll lose when the backup fails.
Next problem: how often do you read back the entire external drive to check it's actually readable? You want to do this before and after every time you backup data to it. It really sucks to lose your main drive, and only then discover that the backup drive has some calibration issues and can't read everything back. But who has time to really check the whole external drive every time?
You really do want two external drives, and ideally from different manufacturers.
We are not competing on basis of skill here, we're competing on the basic cost of living.
In a free market, this means one of three things:
Make the cost of living in the US cheaper.
Make the cost of employment elsewhere more expensive.
Have higher productivity in the US than elsewhere, to offset the differences.
The second will happen extremely slowly, as the standard of living elsewhere increases. The third is really hard, but if you don't succeed, then the first will happen. The first means a large balance of payments deficit that drives down the value of the dollar, and also very high unemployment. Hmm, where have I seen that recently...
Slashdot Mirror
- Fzz
Cringley may be a fool, but he's almost right on this one. There's a saying in networking that you can't buy latency. The speed of light is just too low for Google's AJAX applications to take over the world - for many apps you can never get the latency low enough if you use only a few datacenters. So, the shipping container is irrelevant to the important part of this story. The key is that for Google to succeed in making online services as effective as desktop applications, they have to get the latency down. And there's only one way to do that, which is to move the servers close to the customers. To do that, they need a lot of data centers, and they need a lot of bandwidth between them, because when you connect they need to move your data to the nearest data center to you. So, they really do need to have a way to provide data centers quickly and easily to places all over the world. But Cringely doesn't seem to have realized why this is the only way Google can succeed in the long run. It appears you can buy latency after all if you spend enough. - Fzz
Arianespace is the commercial launch services leader, holding more than 50 percent of the world market for satellites to geostationary transfer orbit (GTO). Created as the first commercial space transportation company in 1980, Arianespace has signed contracts for more than 260 satellite payloads.
-Fzz
Apple is clearly a hardware company, and so they make most of their money from selling hardware. Thus it's very unlikely that Apple would want to support generic x86 boxes.
But Apple has an interesting opportunity here. If they simply ignored people running unlicensed x86 copies, but prevented else anyone selling pre-installed Macs, then they probably wouldn't lose much business. The people who are willing to install MacOS themselves are unlikely to be the people who'd buy Mac hardware in the first place.
However, Apple would gain a lot of mindshare with the kids and with the technically savvy who are happy installing their own OS. In the long run, this will bring many more people to Apple hardware, and to influence their parents/family/employers to buy the supported Apple products.
Seems like Apple can't lose here.
-Fzz
At first I was really happy, but then when the weather got warmer, it started to be unstable. An extra 80mm fan added to the inside of the PSU cured this temporarily, and was much quieter than anywhere else I could mount it. Then it got unstable again. The usual fluff had slightly restricted the airflow on the CPU fan. Vacuumed it out, and it was stable again. But then the fans started to get noisy. After a year or so, it wasn't nearly so silent. Then it got unstable again due to fluff, and this time I junked the quiet CPU fan/cooler - too much trouble, and not so quiet anymore anyway. In the end the PSU fan got noisy too, mostly I think because the fan was temperature controlled, and the PSU now had enough fluff in it to cause it to run hot. I finally replaced it with a regular PSU because it was more important it worked than that it was silent.
Lessons: quiet fans get noisy. Quiet PSUs get noisy, especially if you can't keep them clean. Silent PCs don't stay that way. If you build a quiet PC, install air filters, especially if it's going to be in a bedroom, and expect to have to replace the fans periodically.
The one thing I expected to fail was the disk in the silentdrive enclosure - it ran rather hot right from the start, but it's still working quietly four years later. At least it encouraged me to keep good backups.
Agreed. The main problem with such automated vigilante DoS tools is that you can't control who they'll be targetted at. The spammers will just send a wave of pretty obvious spam linking to a few high profile sites like the FBI or the Whitehouse or Slashdot, and this service will promptly disappear like all the previous similar services.
Unfortunately the choice the public will see is likely to be between:
- Buy Longhorn, and be able to view this premium video content.
- Run Linux/MacOS/BSD and not be able to view this content.
Sure, it may be possible for someone to crack the encrypted path, and distribute unrestricted versions online. But you can't exactly advertise that in your marketing campaign, whereas Microsoft can advertise this premium content as only being available on Longhorn.I think this can only hurt other OSes.
Another analogy for you: Dave Clark once commented that using cryptography to communicate with a stranger is like meeting that stranger in a dark alley. Whatever happens, there won't be any witnesses.
I guess the lesson is to use the right tool for the right job. No dogma.
-Fzz
Not entirely. Wired phones feedback part of the signal from the microphone to the earpiece. This audio feedback is a side-effect of simple analog phone design, but it also serves to help you know the line is live, and help you regulate your volume because you can hear yourself well, and so you assume the other person can hear you.
Cellphones don't provide this feedback. Thus one of the clues you get on a wireline phone is missing. Some people seem to need this clue to help them regulate their volume and some people don't.
Another way that cellphones differ is in audio quality. In general, if you can't hear someone well, you increase the volume at which you speak - this is something we learn when we're very young. Poor cellphone codecs and poor signal strength contribute to the feeling that the other person can't hear you very well, so subconciously you speak louder. Again, different people are affected by this differently, but the effect is pretty common.
So cellphones really are different from wired phones, although not everyone is affected by those differences in the same way.
If the FCC is getting hundreds of thousands of complaints, then there's no way for them to actually investigate these complains. So probably all they can do is count them.
What this means is that any organization that can muster large numbers of complaints about random programs they don't like can cause the system to collapse completely. There'd be no effective way for the FCC to use the complaint system as an alert mechanism.
The only problem with this is that the slashdot crowd aren't nearly as good at organizing as the PTC. So the question is whether we can write python scripts with output that is not detectably different than the PTC's form letters?
As far as I can tell, Microsoft don't want to go head-to-head with Cisco in the marketplace. So they don't really want to be in this market, but they can't afford everyone else (Linux, FreeBSD, etc) to have solutions in this space when they don't. Hence ensuring XORP can run on Windows avoids them getting shut out.
From XORP's point of view, the more people who can run XORP and contribute to its development, the better. Pretty much the same reason Firefox and Apache are available for Windows.
So a curious situation where open-source and Microsoft's interests are fairly well aligned.
So if this patent is on the distributed systems middleware aspects, there's certainly likely to be prior art.
You'd still be able to use it to document police abuses (so long as all the data was appropriately digitally signed), but it would greatly decrease the abuses that criminals could make of it.
And here is a graph of the traffic on the primary link between www.xorp.org and the outside world. At least right now, the 30Mb/s peak there is pretty obvious.
www.xorp.org is in California, www2.xorp.org is in London. Both are 6-year old dual 450MHz Xeon machines with 768MBytes of RAM and SCSI disks, running FreeBSD and Apache 1.3.x. Both machines have 100Mb/s access to the Internet.
In 5 hours:
www.xorp.org: transfered ~30 GBytes peaked at around 175 simultaneous httpd processes 15 min load average peaked at 0.7. www2.xorp.org: transfered ~20 GBytes peaked at around 75 simultaneous httpd processes 15 min load average peaked at 0.4. Aggregate bandwidth was ~25Mbit/sec average. I won't know the peak bandwidth without some more analysis, but it's obviously quite a bit more than 25Mb/s. I didn't notice any obvious slowdown on either machine.I've no idea how typical this is, but I'm always curious about how easily sites seem to die due to slashdotting.
- Mark
Eddie Kohler et al, "The Click modular router". ACM Transactions on Computer Systems 18(3), August 2000, pages 263-297.
These experiments are a few years old now, but 32-bit PCI hasn't changed in that time, so they should still be valid on non-server-class PCs. Vanilla Linux topped out at around 80Kpps, whereas polling gets you over 300Kpps, and the Click optimizations get you nearer 400Kpps.
Similar experiments on FreeBSD with device polling give results in the same ballpark.
- Mark
This is plenty fast enough for most edge routers, but clearly not going to compete with a Cisco CRS-1 or Juniper core router.
But most of the software in a router is control-plane (routing protocols and the like) and this is what XORP has focussed on to-date. As more people get involved with the project, we'll be able to do more things.
A decade ago no-one thought we'd be running Linux on a supercomputer. But we are. If we can get to the point where XORP is stable enough and fully featured enough for carrier-grade routers, who knows what hardware people will run it on in a few years time.
We are however very committed to keeping XORP as an open-source platform. No matter who uses it commercially, in the long run the only way to open up the router software market is for many boxes from many vendors to run a common open base software platform. With luck and with a lot of help, maybe that can be XORP.
- Mark Handley, XORP Project
Thanks for the pointer. Here's a link to some background on ARC, and a paper describing the algorithm. Looks like an interesting algorithm.
This is just the same - you'd probably join just a few channels that interest you and that you trust (whatever that means). You could certainly imagine a hierarchical categorization like usenet groups, with some of those channels being moderated or closed to members only.
Ignoring the weight of the rope itself, probably the main reason for this rule-of-thumb is the difference between dynamic loading and static loading.
If you (accidentally) get something bouncing on a short rope, the bounce will damp out pretty quicky and the period of oscillation is short. If you get something bouncing on a long rope, it will bounce for a while, and the rope is stretched for much longer with each bounce. It doesn't take all that much of a bounce to double the load on a rope, and perhaps take it past its elastic limit.
I'm guessing, but I think that pre-synthetic ropes probably can be briefly overstretched without losing strength because they knit back together again. If you continuously overstretch them, the fibres probably don't get a chance to recover before the slide past each other a little more, and so on.
So my guess is this doesn't apply nearly so much to modern synthetic ropes. In the case of a space elevator, I'd hope they'd try really hard to avoid excess dynamic loading.
16km is a little too high for a helicopter (they top out at about 7-8km), but it's well within the reasonably altitude range for a large helium baloon.
Could you use the elevator itself to lift the counterweight? You start off with a small counterweight and an even smaller elevator car, and make multiple trips, each one increasing the mass of the counterweight. As the counterweight increases you can bring up more additional counterweight mass each time, until you've got enough to allow you to substitute a larger elevator car.
That's a good question. The prevailing theory is that the universe underwent cosmic inflation early in its life.
You need to be careful with strategies like this. If the drive you're backing up doesn't fail catastrophically, likely the time you'll discover it's failing is when you're reading it. What do you read the whole drive? When you're backing it up. So you're halfway through doing a backup, overwriting the external drive when you discover that the internal drive is bad. Ooops.
Safest is to have two external drives, and alternate the backups between them. If you can't afford this, then you need to think pretty carefully about how you overwrite data on the external drive, so as to minimize the data you'll lose when the backup fails.
Next problem: how often do you read back the entire external drive to check it's actually readable? You want to do this before and after every time you backup data to it. It really sucks to lose your main drive, and only then discover that the backup drive has some calibration issues and can't read everything back. But who has time to really check the whole external drive every time?
You really do want two external drives, and ideally from different manufacturers.
In a free market, this means one of three things:
- Make the cost of living in the US cheaper.
- Make the cost of employment elsewhere more expensive.
- Have higher productivity in the US than elsewhere, to offset the differences.
The second will happen extremely slowly, as the standard of living elsewhere increases. The third is really hard, but if you don't succeed, then the first will happen. The first means a large balance of payments deficit that drives down the value of the dollar, and also very high unemployment. Hmm, where have I seen that recently...Education is really the only option.