I wonder how much they are spending on theses launches? I assume that using an ICBM rocket is probably far cheaper and (with nuclear arms cutbacks - especially in long range specs) far more expendable.
Still this is probably costing several million in administration and R&D alone.
Probably. Rather less than NASA spent on space shuttle tiles I suspect, although I don't know whether this system could handle a vehicle of the Space Shuttle's weight. Then again, it wouldn't need to weigh as much if it used this system.
Yes, any illegality of your use of Kazaa could be an issue; the ISP may have records of your connections to other Kazaa servers and they would probably try to bring that up in court.
Grins. That was not exactly my experience. I used to work with him whilst he was doing a summer job before he went to Cambridge. He didn't actually get fired or have to resign; but let's just say that at the time he was rather more interested in security than the system administrators would wish perhaps...
Anyway he matured loads at Cambridge; must have done, cos he's still alive;-)
Can your/usr/local/ tree be made to go away reproducibly?
To prove you theory you could take the hash function in reiserfs and replace it with a function that always returns '1'. You would probably have to reformat your partitions though for that test though. The filesystem should still work. If it doesn't that's a bug.
The chances of their being a bug in reiserfs is about 100%. Same is true of ext3 though.
Move a few big asteroids into low earth orbit. That way everytime it goes around its gravity would give any debris a small kick. This will change the orbital eccentricity, and after a while the debris will intersect the atmosphere and reenter.
Moving asteroids isn't that hard, although care is needed to ensure you don't reenter it. An asteroid big enough to make this work would be big enough to wipe out all life on earth- so be careful out there guys.;-)
Apparently you have to be smarter than mister Top 2 Percent to make this work.
Actually he's very capable of doing this kind of stuff right. More or less he had to follow the tftp spec, so what's he gonna do?
But my real point is still that most people don't know enough to do it right.
You certainly sound like you might have your head around what TCP does, so probably your protocol works very well.
Exponential backoff is braindead when you need good thoughput on a fat but noisy pipe.
Yes, you are optimising your protocol to deal with cases where packet loss is caused by noise. The internet is built mostly on the assumption that packet loss is caused by congestion, so of course TCP will perform more poorly, and a more tailored protocol is a win, and UDP allows you to do that.
I do wonder if your protocol might trigger congestion collapse, but I have no doubt you've designed against that and tested for it too.
Newsflash: tftp is UDP from the get-go. That's the whole point. And since tftp is a request-response type protocol, of *course* it's going to see less performance out of your networks than ftp.
Precisely! It's supposed to be a lightweight protocol, which is one of the reasons people choose UDP, but it turns out to be slower in this case. And it's because of what's been left out of the UDP protocol stack; UDP isn't inherently bad because of this, but usually you would want what's been left out. Right now I would not want to deploy tftp ever, it lacks passwords, and it's performance is poor on a congested network.
Finally, UDP wasn't designed to handle congestion. But that doesn't mean it can't. Counter-example: build congestion avoidance into your application.
Absolutely, but then you have to implement it yourself! And it is very much not simple.
There is no way to "aggressively defend" your bandwidth if (for example) you're playing a game. If someone else comes along with their own UDP application that doesn't back off when detected packet loss gets extremely high, you lose out just as much as they do. There is no defence in this case, there is only *higher packet loss.*
Being aggressive does not guarantee more bandwidth. But in most situations most other people are using ftp/http etc. they normally will back off and you will get more bandwidth if your protocol is aggressive. Of course if everyone is aggressive, especially inappropriately- you and everyone else ends up losing worse than if you'd have used TCP; it's rather like real life. It probably only makes sense in cases where you only need a small amount of bandwidth; but you NEED that bandwidth. If you start to lose packets due to congestion, you are supposed to send more slowly. However, if you increase the rate you send, you end up with a bigger slice of the pie; if the slice is then enough for what you need, you can control your bandwidth to some extent. However, ultimately you can't send more than your pipe will take, so really heavy congestion will still kill you.
Anything TCP can do, UDP can do--the problem lies in how much work you have to do to implement it.
Yes. Exactly. It's often a lot more work, and unless you really, really know what you are doing UDP is likely to be the wrong choice.
If you have very special requirements, or very non special requirements, or you simply can't use TCP for some reason, then UDP can give you better performance. But it usually won't.
About the only reason for using UDP is if you deliberately want to circumvent the congestion avoidance protocols that are built into TCP. So, if you are playing a game, and you need the packets to get through at all costs, but you aren't sending many packets- by using UDP you can agressively defend the small amount of bandwidth you need- any TCP connections around will tend to back off and get out of your way; and that's reasonable if you code it carefully. But writing the protocol to do that is hard, you have to understand not only UDP but also TCP, as well as your game requirements.
And that's the real problem. In most cases people think that waving UDP at the problem will solve their problems- in fact it makes them worse; and TCP has solutions to problems only PhDs have even thought of, and the solutions are built in.
As an example, somebody I know implemented a tftp protocol using UDP. The guy is off the chart in his software abilities (trust me the guy is amazing, he's in the top 2 percent of software engineers according to the tests). Anyway in a back-back comparison against a standard ftp protocol- the tftp protocol loses by a factor of 10 or more (on a network with some congestion, I expect a quiescent network would have been much more level). Of course tftp isn't supposed to handle congestion. But that's the problem- UDP can't handle network congestion out of the box... indeed if anything it tends to create network congestion.
The main algorithms in tcp include 'slow start' and 'exponential backoff'. Both of these are missing in UDP, and both improve the network performance enormously. If your application doesn't affect network performance and doesn't worry about packet loss much, then UDP may be the way to go, otherwise stay away from UDP.
It's the infrastructure of the reactor chamber and everything around it. It gradually becomes radioactive. Still, in a sense you are partly correct. The half life of the materials may be able to be chosen to decay in years, rather than hundreds or thousands of years. But there's going to be constraints, and some long-lived radioactivity is extremely likely IMO.
The problem with fusion is that it isn't quite that clean. As it runs, the most likely reactions tend to spits out large amounts of radiation; and gradually makes the fusion reactor itself radioactive.
That means that the fusion reactor itself becomes radioactive- and the reactor is going to have a finite life. Therefore fusion reactors end up as hazardous, radioactive waste.
Also some schemes for making energy involve irradiating material in a fusion reactor, and then putting it into a fission reactor, and boiling steam in the conventional way to make electricity. That also gives radioactive waste.
Bottom line: fusion is never going to be truly clean
For the antimatter generation - which is cheaper? Carrying a billion tonnes of power plant and particle accelerator into space, or leaving it on the ground and carrying a hundred micrograms of antimatter into space?
Of the two I'd say building the billion tonnes of power plant (they get heavy these days these power plants!) in space, and building the rocket there too is cheaper.
If we _can_ build an interstellar probe, why shouldn't we? It would teach us far more about other star systems than we're likely to learn by any other means.
We haven't even investigated this one yet! The cost for launching rockets should be near to $100/kg. It's currently at $2600/kg. If it reaches $100/kg then pretty much anyone reasonably well off can get to go to space. No amount of antimatter rockets can do this. Building large equipment in space is actually easier than building it on the ground; and energy to make antimatter is easy to collect up there.
It's just like Christopher Columbus just discovered America and you're planning to go to the moon! (Why not, the problems are orthogonal!)
This is why the antimatter-triggered fusion rocket is the most promising design for an interstellar craft. It needed a few hundred micrograms, which is within our capacity to produce.
Look we haven't even worked out how to get off the planet cheaply- and interplanetary hasn't been done yet, and you're worried about interstellar?
With current production techniques, the cost of the antimatter would far dwarf the cost of bringing the rest of your ship into orbit, so cost-effectiveness of the launch vehicle doesn't matter.
Oh well in that case... what a great idea, it's so much more expensive than the obscenely expensive launch vehicle that it must be a good idea!
Secondly, an antimatter annihilation should produce no fallout. You'd have a ferocious gamma-ray burst, and a giant fireball if you have enough antimatter (due to gamma rays heating the air nearby), but you'd have neither direct radioactive byproducts nor significant transmutation going on.
Nope. Antimatter, unless it is made of pure positrons; does create fallout. And you can't use pure positrons, or atleast its very hard because the charges repel each other; and the state of the art with positron production is tiny amounts; and storage is worse. [Positrons don't produce fallout because the gamma rays have insufficient energy to transmute anything- other antimatter is not so fortunate.]
From what I've seen the hard bit by far is getting into space at all. Once you're there, conventional fission can get us about the solar system plenty fast enough. The main limitation isn't energy- it's materials. We really need a cheap launch system!
Deuterium fusion? Don't make me laugh. Containment is a total nightmare. It's been 50 years away for 50 years; except now it's only 30 years away; maybe, or maybe they're just being more optimistic because someone was going to cut their funding. And that's just getting it to fuse and stay contained; getting electricity from it- that's almost equally as hard.
I went to a talk on positron manufacture and its possible use on an unmanned air vehicle. It turns out that the entire output of the world so far and probably the next 20 years wasn't enough to make a single unmanned vehicle work for 1 minute. Production rates were more than 1000x lower than necessary for even that. And even if they could- storage of large quantities is currently well beyond the state of the art.
Large quantities of antimatter is practically the definition of 'unobtainium' right now.
No. Mod this parent down, and while your asking, wonder if he knows how much antimatter has been made, and why it even matters.
If we actually had cost effective space launch then antimatter research might actually be worth it. Right now, it's so far out- a launch accident involving antimatter could go off like fission bomb. It only makes sense if you make it in space.
I'm actually pro nuclear power- but launching significant antimatter from the earth 'scares even me, and I'm fearless'. Plutonium- I laugh at plutonium.;-)
What's the point of messing about with antimatter right now? The amount of antimatter that has ever been made is smaller than a pinhead. The use of this for a propulsion system- that dog does not fly.
I mean, cmon; NASA is an aging, flabby, inept (X33), and misguided, accident prone (Challenger) and not well managed (ISS) organization.
Costs in most other parts of the world are far lower, and this is not simply because their engineers are cheaper; there has been studies on that. The ISS is predominately of Russian build and launch, and again Russia managed it for a tiny fraction of what it would have cost NASA.
America deserves far better for their money. Space is important, NASA achieves little with their huge budget.
True private launch infrastructure is the way to go; how a left wing organisation like NASA has survived this long in a country like America is completely beyond me.
Yes, still, it might be a replacement for aluminum in some aerospace usages. After all, aluminum loses temper at ~750 F too, and this alloy is supposed to be stronger below that- mind you they didn't quote its strength/weight ratio which is the most critical issue in aerospace; I'm assuming it isn't 3x heavier or something.
It's based on evolution, which everyone knows is false. Afterall doesn't it say in the good book that man was made in Gods own image?
Whose image was this keyboard layout? Who is he to play at being God?
This is a good example of everything that's wrong with the world; just like GM foods. I don't want some Frankenkeyboard, that might spread its genes out into the environment, anymore than I want frankenfoods, we'll be knee deep in genetically modified keyboards next. Contact your congressman. This has to be stopped.
Obviously they needed to dilute it by a factor of 13000...its almost homeopathy.
Homeopathy would take something bitter, then dilute it down. They'd then claim that the more dilute you make it, the sweeter it gets. Uh Huh. And if you buy that I've got a bridge to sell you.
Yes, the company I work for used this technique to build up gprof style call trace information on a huge embedded, persistent, realtime, multitasking, concurrent system we built (yes it is/was horrible;-).
Anyway, we ran the equivalent of pstack at frequent intervals (like once per millisecond) and then collected the addresses of all functions in the call tree present each time we polled the system. Got a humongous file. Then postprocessed the file to record which functions called what other functions, and how often and looked up the addresses in the symbol table to give usable names.
It turns out that polling the system like that usually gives all the important information you could want- it tends to show not the most called functions but the heaviest users of the processor because they are much more likely to be running when the pstack happens- the number of times they will appear is proportional to the total time they run for, statistically. And the technique is minimally invasive and doesn't require recompilation of the code under test.
Then we printed the summary out in a huge printout, each function sorted by percentage ticks spent in it; and then spent a week or two staring at it. It showed some amazing features like certain functions were spending an order of magnitude longer in them than originally designed, that kind of thing.
Not only that, but he's numerically integrating it up I believe, so the actual answer will diverge from the true one due to rounding errors, probably more so in the higher dimensions.
OTOH the value of 'pi' (ratio of circumference to diameter) is actually BIGGER in hyperbolic geometry, and smaller in spherical plane geometry than the normal value, and varies with the size of the circle. Atleast that's something vaguely interesting.
Slashdot Mirror
Still this is probably costing several million in administration and R&D alone.
Probably. Rather less than NASA spent on space shuttle tiles I suspect, although I don't know whether this system could handle a vehicle of the Space Shuttle's weight. Then again, it wouldn't need to weigh as much if it used this system.
Yes, any illegality of your use of Kazaa could be an issue; the ISP may have records of your connections to other Kazaa servers and they would probably try to bring that up in court.
Some contracts have a no-server clause. In that case they would probably be allowed to block this program- P2P programs run as a server.
Grins. That was not exactly my experience. I used to work with him whilst he was doing a summer job before he went to Cambridge. He didn't actually get fired or have to resign; but let's just say that at the time he was rather more interested in security than the system administrators would wish perhaps...
Anyway he matured loads at Cambridge; must have done, cos he's still alive ;-)
Bloody smart guy.
To prove you theory you could take the hash function in reiserfs and replace it with a function that always returns '1'. You would probably have to reformat your partitions though for that test though. The filesystem should still work. If it doesn't that's a bug.
The chances of their being a bug in reiserfs is about 100%. Same is true of ext3 though.
Moving asteroids isn't that hard, although care is needed to ensure you don't reenter it. An asteroid big enough to make this work would be big enough to wipe out all life on earth- so be careful out there guys. ;-)
Actually he's very capable of doing this kind of stuff right. More or less he had to follow the tftp spec, so what's he gonna do?
But my real point is still that most people don't know enough to do it right.
You certainly sound like you might have your head around what TCP does, so probably your protocol works very well.
Exponential backoff is braindead when you need good thoughput on a fat but noisy pipe.
Yes, you are optimising your protocol to deal with cases where packet loss is caused by noise. The internet is built mostly on the assumption that packet loss is caused by congestion, so of course TCP will perform more poorly, and a more tailored protocol is a win, and UDP allows you to do that.
I do wonder if your protocol might trigger congestion collapse, but I have no doubt you've designed against that and tested for it too.
Precisely! It's supposed to be a lightweight protocol, which is one of the reasons people choose UDP, but it turns out to be slower in this case. And it's because of what's been left out of the UDP protocol stack; UDP isn't inherently bad because of this, but usually you would want what's been left out. Right now I would not want to deploy tftp ever, it lacks passwords, and it's performance is poor on a congested network.
Finally, UDP wasn't designed to handle congestion. But that doesn't mean it can't. Counter-example: build congestion avoidance into your application.
Absolutely, but then you have to implement it yourself! And it is very much not simple.
There is no way to "aggressively defend" your bandwidth if (for example) you're playing a game. If someone else comes along with their own UDP application that doesn't back off when detected packet loss gets extremely high, you lose out just as much as they do. There is no defence in this case, there is only *higher packet loss.*
Being aggressive does not guarantee more bandwidth. But in most situations most other people are using ftp/http etc. they normally will back off and you will get more bandwidth if your protocol is aggressive. Of course if everyone is aggressive, especially inappropriately- you and everyone else ends up losing worse than if you'd have used TCP; it's rather like real life. It probably only makes sense in cases where you only need a small amount of bandwidth; but you NEED that bandwidth. If you start to lose packets due to congestion, you are supposed to send more slowly. However, if you increase the rate you send, you end up with a bigger slice of the pie; if the slice is then enough for what you need, you can control your bandwidth to some extent. However, ultimately you can't send more than your pipe will take, so really heavy congestion will still kill you.
Anything TCP can do, UDP can do--the problem lies in how much work you have to do to implement it.
Yes. Exactly. It's often a lot more work, and unless you really, really know what you are doing UDP is likely to be the wrong choice.
About the only reason for using UDP is if you deliberately want to circumvent the congestion avoidance protocols that are built into TCP. So, if you are playing a game, and you need the packets to get through at all costs, but you aren't sending many packets- by using UDP you can agressively defend the small amount of bandwidth you need- any TCP connections around will tend to back off and get out of your way; and that's reasonable if you code it carefully. But writing the protocol to do that is hard, you have to understand not only UDP but also TCP, as well as your game requirements.
And that's the real problem. In most cases people think that waving UDP at the problem will solve their problems- in fact it makes them worse; and TCP has solutions to problems only PhDs have even thought of, and the solutions are built in.
As an example, somebody I know implemented a tftp protocol using UDP. The guy is off the chart in his software abilities (trust me the guy is amazing, he's in the top 2 percent of software engineers according to the tests). Anyway in a back-back comparison against a standard ftp protocol- the tftp protocol loses by a factor of 10 or more (on a network with some congestion, I expect a quiescent network would have been much more level). Of course tftp isn't supposed to handle congestion. But that's the problem- UDP can't handle network congestion out of the box... indeed if anything it tends to create network congestion.
The main algorithms in tcp include 'slow start' and 'exponential backoff'. Both of these are missing in UDP, and both improve the network performance enormously. If your application doesn't affect network performance and doesn't worry about packet loss much, then UDP may be the way to go, otherwise stay away from UDP.
It's the infrastructure of the reactor chamber and everything around it. It gradually becomes radioactive. Still, in a sense you are partly correct. The half life of the materials may be able to be chosen to decay in years, rather than hundreds or thousands of years. But there's going to be constraints, and some long-lived radioactivity is extremely likely IMO.
That means that the fusion reactor itself becomes radioactive- and the reactor is going to have a finite life. Therefore fusion reactors end up as hazardous, radioactive waste.
Also some schemes for making energy involve irradiating material in a fusion reactor, and then putting it into a fission reactor, and boiling steam in the conventional way to make electricity. That also gives radioactive waste.
Bottom line: fusion is never going to be truly clean
Of the two I'd say building the billion tonnes of power plant (they get heavy these days these power plants!) in space, and building the rocket there too is cheaper.
We haven't even investigated this one yet! The cost for launching rockets should be near to $100/kg. It's currently at $2600/kg. If it reaches $100/kg then pretty much anyone reasonably well off can get to go to space. No amount of antimatter rockets can do this. Building large equipment in space is actually easier than building it on the ground; and energy to make antimatter is easy to collect up there.
It's just like Christopher Columbus just discovered America and you're planning to go to the moon! (Why not, the problems are orthogonal!)
Look we haven't even worked out how to get off the planet cheaply- and interplanetary hasn't been done yet, and you're worried about interstellar?
Oh well in that case... what a great idea, it's so much more expensive than the obscenely expensive launch vehicle that it must be a good idea!
Nope. Antimatter, unless it is made of pure positrons; does create fallout. And you can't use pure positrons, or atleast its very hard because the charges repel each other; and the state of the art with positron production is tiny amounts; and storage is worse. [Positrons don't produce fallout because the gamma rays have insufficient energy to transmute anything- other antimatter is not so fortunate.]
Deuterium fusion? Don't make me laugh. Containment is a total nightmare. It's been 50 years away for 50 years; except now it's only 30 years away; maybe, or maybe they're just being more optimistic because someone was going to cut their funding. And that's just getting it to fuse and stay contained; getting electricity from it- that's almost equally as hard.
I went to a talk on positron manufacture and its possible use on an unmanned air vehicle. It turns out that the entire output of the world so far and probably the next 20 years wasn't enough to make a single unmanned vehicle work for 1 minute. Production rates were more than 1000x lower than necessary for even that. And even if they could- storage of large quantities is currently well beyond the state of the art.
Large quantities of antimatter is practically the definition of 'unobtainium' right now.
If we actually had cost effective space launch then antimatter research might actually be worth it. Right now, it's so far out- a launch accident involving antimatter could go off like fission bomb. It only makes sense if you make it in space.
I'm actually pro nuclear power- but launching significant antimatter from the earth 'scares even me, and I'm fearless'. Plutonium- I laugh at plutonium. ;-)
What's the point of messing about with antimatter right now? The amount of antimatter that has ever been made is smaller than a pinhead. The use of this for a propulsion system- that dog does not fly.
I mean, cmon; NASA is an aging, flabby, inept (X33), and misguided, accident prone (Challenger) and not well managed (ISS) organization.
Costs in most other parts of the world are far lower, and this is not simply because their engineers are cheaper; there has been studies on that. The ISS is predominately of Russian build and launch, and again Russia managed it for a tiny fraction of what it would have cost NASA.
America deserves far better for their money. Space is important, NASA achieves little with their huge budget.
True private launch infrastructure is the way to go; how a left wing organisation like NASA has survived this long in a country like America is completely beyond me.
Yes, still, it might be a replacement for aluminum in some aerospace usages. After all, aluminum loses temper at ~750 F too, and this alloy is supposed to be stronger below that- mind you they didn't quote its strength/weight ratio which is the most critical issue in aerospace; I'm assuming it isn't 3x heavier or something.
Aibo. Obviously!
Whose image was this keyboard layout? Who is he to play at being God?
This is a good example of everything that's wrong with the world; just like GM foods. I don't want some Frankenkeyboard, that might spread its genes out into the environment, anymore than I want frankenfoods, we'll be knee deep in genetically modified keyboards next. Contact your congressman. This has to be stopped.
Homeopathy would take something bitter, then dilute it down. They'd then claim that the more dilute you make it, the sweeter it gets. Uh Huh. And if you buy that I've got a bridge to sell you.
Anyway, we ran the equivalent of pstack at frequent intervals (like once per millisecond) and then collected the addresses of all functions in the call tree present each time we polled the system. Got a humongous file. Then postprocessed the file to record which functions called what other functions, and how often and looked up the addresses in the symbol table to give usable names.
It turns out that polling the system like that usually gives all the important information you could want- it tends to show not the most called functions but the heaviest users of the processor because they are much more likely to be running when the pstack happens- the number of times they will appear is proportional to the total time they run for, statistically. And the technique is minimally invasive and doesn't require recompilation of the code under test.
Then we printed the summary out in a huge printout, each function sorted by percentage ticks spent in it; and then spent a week or two staring at it. It showed some amazing features like certain functions were spending an order of magnitude longer in them than originally designed, that kind of thing.
It is really quite a useful technique.
OTOH the value of 'pi' (ratio of circumference to diameter) is actually BIGGER in hyperbolic geometry, and smaller in spherical plane geometry than the normal value, and varies with the size of the circle. Atleast that's something vaguely interesting.