I think it's the other way around. Large software programs are *hard*.
The Linux kernel works because it fills a need, and because it fills a need, lots of people will want to work on it.
The Hurd is more researchy and hence doesn't fullfill anyone's needs exactly, and yes, to the extent that Linux does fit them, then there are less people working on Hurd.
In my experience, a program that fills 90% of the need for 10% of the effort will nearly always win out, even if the extra 10% costs another 90%. The Linux kernel was a quick hack (and I don't mean that in a bad way), whereas Hurd was trying for perfection...
I actually prefer to run about half my test cases on an emulator. Indeed I don't believe that good testing can be performed without isolating from the real hardware (but there are exceptions, clearly if the hardware is dirt cheap or something, and the debugging hooks are excellent...)
That's true, but often the real equipment is the first few off the production line, and hence is quite expensive and in limited supply, and even buggy, whereas the emulators can be duplicated as many times as you want.
Also, you have better control of what goes on in an emulation, and that can help you find mysterious bugs that are very opaque on the real hardware.
Finally, there's certain situations where emulators are probably the only way to go- for example Space Shuttle software validation is done on the emulator, they *really* didn't want to use the real thing for that;-)
There will never be a discovery (publically at least) of indefinitely life-extending consequence. There will, however, be discoveries that prolong life. But not too much at a time.
Why not open source medicine?
We have open source software. And it benefits everyone who works on it if life extension becomes an actuality. So there may be plenty of volunteers, particularly among the retired community...
And have these insurers ever actually paid out? If not, then what's the point? If yes, how come there's no relation between what they charge to get a certificate and the value of the transaction?
the analogy sucks... really. a graphics card is MADE to do that stuff.
Really? No. A graphics card is designed to do graphics. The fact that that might mean that it can do matrix multiplications, even has to do matrix multiplications doesn't mean that that allows it to do matrix multiplications for the main processor. You are making an error of composition. If it can do so it is actually fortuitous.
I don't understand. There is nothing intrinsic in the number 2 and the number 5 that will tell you what they will equal when they are multiplied.
Correct. I think he has shapes for each of the numbers he's multiplying and he has learnt the shape that they turn into when you multiply them. Because the visual powers of the human mind are quite powerful he's able to do that fast.
It's kinda like using your computer's graphics card to do matrix multiplication. If you feed the info in the right format you can get the answer out faster than using the main processor, because the graphics processor actually has more computing power; but it's not as general purpose.
Synesthesia is a not uncommon brain disorder which links the senses together. For example some people when told a name see a colour. Others taste or smell something etc. Interestingly, for each person with the disorder each word always connects to the same sensation, and different people with the same sort of synesthesia sometimes have similar sensations...
The upside is that this can make it easier to remember things- it means you've got more things about the thing to connect to other things- his description of how he remembered pi as a story is a *classic* description of the mnemonic technique for remembering things- you basically turn what you want to remember into a series of pictures that you string into a whacky story. It works really, really well; people easily get upwards of 90% recall using it. And he has a built in picture or sensation to help him with this; which is the hardest bit of the technique.
Um. Several studies into dirty bombs have been done. They all showed that the most dangerous part of a dirty bomb is the conventional explosive.
Whilst it is easy enough to make a dirty bomb, the expected number of casualties is very small; as in low single digit, and decontaminating the area is straightforward.
It looks a lot like what you are doing is assuming that most of the energy of an orbit is potential energy. When in fact ~93% it is kinetic energy- sideways.
In other words: to get to orbit- you have to go sideways *fast*- really, really, really fast. You go up a little bit, but you go sideways a whole bunch.
And in case you're wondering: yes, you do have to go sideways really, really, really fast to go from London to Tokyo too. It's just that you arrange for the orbit to intersect the atmosphere so that you land in Japan. And that's the *optimum* ballistic trajectory to get from London to Tokyo. In fact, IRC, you usually actually go to a higher altitude to go suborbital than LEO.
Oh yeah, check out this launcher, some of the versions have back-back comparisons of LEO and ICBM payload. http://www.astronautix.com/lvs/r29.htm
I can explain the same thing in a dozen different ways, but I don't think you're listening at all, and you don't show any signs of being able to understand the whys/what and hows so I'm stopping right here.
Lets compare 350k LEO and 140k suborbital. Potential energy difference (assuming same velocity - orbital velocity is higher, but we won't be going as high as orbital vel) is m*9.8*(350k-150k)=m*1.96 MJ. E=1/2 mv^2=m*1.96 MJ; v^2=3.92 MJ; v=1.979 km/s energy equivalent.
That's not how it works. LEO is more typically quoted at 180km high anyway; and you'd have to go pretty much that high or higher to get to Tokyo anyway.
No, look. Ignoring the ascent air resistance (which is the same for orbital/suborbital anyway pretty much), as soon as you leave the atmosphere, you are in orbit right? I mean, the orbit may intersect the ground(!), but you are technically in orbit.
Now, to go long distances you need perigee to not be too far below ground level, otherwise you will hit the ground almost immediately.
So perigee has to be close to ground level, and apogee has to be above 100km. So, right away you are describing an orbit that is 98% of the way to being a stable orbit.
I mean, what's a hundred kilometers out of 6200km (the radius of the earth). Right?
If you don't believe me, do the *real* math. As a kick-off check out the vis-visa equation and other equations on that site.
Calculate the delta-v to reach an orbit with apogee at 100km and perigee at 0km. Then add on 2km/s to deal with gravity and atmospheric losses during ascent. That will give you the delta-v for going about 1/4-1/2 of the way around the world.
> Gary Hudson gave it as a rule of thumb on USENET a year or two back IRC.
Well, then he was eiter wrong, or using way too high of an orbit.
Gary Hudson is a leading rocket engineer that has worked on numerous launch vehicles, including an ICBM IRC (which *are* suborbital delivery systems if you bother to think about it). If he says it's 30% reduction in payload; that's what it is. Period.
However, I still find setting up a sidestream (private branch? Google had nothing on ClearCse sidestreams) a lot of bother when under CVS I can simply edit files and merge in all changes as they come.
Yes, private branch. It was a fair amount of bother, but for the highly disciplined software engineering I was involved with, the extra process wasn't significant- not when it could take 2 days to change 1-5 lines of code:-( We had scripts to automate it mostly; so it wasn't so bad.
It may very well be that CVS is a better fit for most people. I used clearcase on a *big*, cross-site (international) project (as in several hundred software engineers all hacking away simultaneously, millions of lines of code- *BIG* project, and there it worked very well, although it seemed somewhat overcomplex to use. I think we evaluated CVS, but elected not to go that way.
IMO- The biggest problem with clearcase is that it's overcomplicated. You simply shouldn't have to jump through that many hoops to do the common stuff.
Actually I didn't bother to read your article carefully:
Kerosene will cost you perhaps 30 cents a kilogram in bulk;
In your dreams. Aviation fuel is over a dollar. Where you planning to get this magic cheap kero from then?
LOX will cost you perhaps 5 cents per kilogram
Last time I checked it was more like 40c a kg if you have your own plant. It's actually probably cheaper if you haven't got your own plant- the big boys wring the neck of the process to save electricity.
Yes I know ClearCase can kind of do something like that, but not very well
No, it can do exactly that, and very well. If it is set up correctly, basically designers can create their own side-stream, and do repeated merges into it to keep up to date.
and I have seen clear case totally bungle automatic merges before.
I have seen *designers* totally bungle merges before. A perfect merge tool or process does not exist; but it nearly always works fine. Automated merge tools are nearly always a big help though.
It's nearly always a good idea to code review all changes that are being merged back into a stream. That can solve nearly all merge problems.
And if somebody makes a change before you merge back, code inspect the merge with that too. The final merge shouldn't actually involve changing any code on the sidestream.
Where on earth are you getting your number from for 30% less payload? -30% delta-V sounds about right (probably even more difference if anything; I'd have to check my rocket simulator)
Gary Hudson gave it as a rule of thumb on USENET a year or two back IRC. It's also born out with experience of using *my* rocket simulator.
Even with a typical 20:1 payload fraction for kerosene rockets
Really? Name one with a 5% payload fraction. Orbital fraction maybe, but *not* payload. For seat price, you want payload fraction, including customer, seat, lifesupport etc. etc. Actually $15000 is probably low, it assumes only 100kg per person.
Actually orbital rockets typically have a 1-2% payload fraction. Divide that by 0.7 and that's roughly the London-tokyo payload.
I have priced LOX and kero in the past, and I'm comfortable with $50/kg of payload. You might be able to go somewhat lower if you manage to get a cheap supplier of LOX. The kero- if you use aviation fuel- is fairly easy to price up. I've optimistically multiplied the fuel price by only 3 to get the price. Probably 5-10 is more realistic initially.
Not even remotely. Fuel for rockets is incredibly cheap compared to everything else involved.
Yup. Compared to everything else that is currently involved.
Kerosene will cost you perhaps 30 cents a kilogram in bulk; LOX will cost you perhaps 5 cents per kilogram (you just refrigerate it out of the air, so the only cost is refrigeration).
Yeah, I priced that up too. It actually takes quite a bit of electricity to make LOX; and the electricity is not cost free.
1) Heating is proportional to velocity squared, not velocity. That means you're only getting half of the heating.
You're not listening. The delta-v to get to Tokyo is pretty close to the delta-v to get to orbit. It's not 30% less; maybe 10% less or something. You'd get nearly the same heating.
Yeah, but even then this is $15,000 one-way; and I wouldn't like to bet you could even hit that price. And even if you could, you probably wouldn't. You'd probably up the price by 30% and go for orbit instead, because there's less competition from subsonic launchers- the same problem that killed Concorde.
You can always return them from orbit back to Tokyo, and still beat the airflight.
Right, except for one thing: Suborbital flight, even doing half an orbit, is a heck of a lot cheaper and easier than orbital flight. 30% delta-V less equates to a huge reduction in required TPS, greatly reduced ISP (and thus reduced maintenance) or greatly improved payload fraction, etc. The difficulty of getting out of a big gravity well scales geometrically with the required delta-V, not linearly.
True, except- wrong. The delta-v isn't 30% less; the *payload* is 30% less to go intercontinental than to go to orbit.
Lastly, since it's in a suborbital flight path for so short of a period of time, you don't have to worry so much about thermal or atmospheric regulation as you would for a true orbital craft that would be up there for days. This could be an especially big advantage for simplifying hydraulics (although I'd like to see spacecraft move away from hydraulics anyways...;) ).
Yeah, but you do have to worry about reentry- the velocity is pretty much orbital speed.
Lastly,
You mean it this time?
you get much better economies of scale. All in all, I'd expect travel on a suborbital liner to cost at most 1/20th as much per kg if built properly, and probably much less. You might even be able to go under 100$/kg if you got enough passengers. No matter what, though, probably way too expensive for ordinary commuter flights:P It probably could fill a niche industry - a combination of space tourism with Earth tourism.
The rocket fuel is still expensive though. Maybe $50/kg of payload if you use hydrocarbon fuel. So you probably need to triple that- giving a ticket price of maybe $15,000. Looking expensive. And for the foreseeable future- dangerous.
"In short, Space Hops are a very carefully calculated set of thruster burns that allow a ship to reach Geostationary orbit in such a way as to be able to cross great distances in a very short time."
Um, no... that doesn't work. It takes the best part of a day to get to GEO.
For instance, a flight from London to Tokyo clocks in at just under an hour (takeoff and landing included).
Sure, that works no, problem. You just don't via GEO; oh yeah, and it costs about the same as going to orbit, since the launch vehicle needs about the same performance, baring about 30%.
Slashdot Mirror
The Linux kernel works because it fills a need, and because it fills a need, lots of people will want to work on it.
The Hurd is more researchy and hence doesn't fullfill anyone's needs exactly, and yes, to the extent that Linux does fit them, then there are less people working on Hurd.
In my experience, a program that fills 90% of the need for 10% of the effort will nearly always win out, even if the extra 10% costs another 90%. The Linux kernel was a quick hack (and I don't mean that in a bad way), whereas Hurd was trying for perfection...
It's the only tool needed. It's how evolution made *you* after all.
Bad assumption.
It's just as likely to be a recorded advert.
I actually prefer to run about half my test cases on an emulator. Indeed I don't believe that good testing can be performed without isolating from the real hardware (but there are exceptions, clearly if the hardware is dirt cheap or something, and the debugging hooks are excellent...)
Also, you have better control of what goes on in an emulation, and that can help you find mysterious bugs that are very opaque on the real hardware.
Finally, there's certain situations where emulators are probably the only way to go- for example Space Shuttle software validation is done on the emulator, they *really* didn't want to use the real thing for that ;-)
Why not open source medicine?
We have open source software. And it benefits everyone who works on it if life extension becomes an actuality. So there may be plenty of volunteers, particularly among the retired community...
That way browsers could run checks on it and only display stuff that is suitable.
And at that scale, I imagine the question "Is it in yet?" may never be answered to anyone's satisfaction, given quantum tunneling and such like. :-)
Presumably, they're admitting to it now because they've changed their mind and they don't consider it to be a big threat :-)
And have these insurers ever actually paid out? If not, then what's the point? If yes, how come there's no relation between what they charge to get a certificate and the value of the transaction?
Really? No. A graphics card is designed to do graphics. The fact that that might mean that it can do matrix multiplications, even has to do matrix multiplications doesn't mean that that allows it to do matrix multiplications for the main processor. You are making an error of composition. If it can do so it is actually fortuitous.
That's just what a computer would say if they got annoyed :-)
Correct. I think he has shapes for each of the numbers he's multiplying and he has learnt the shape that they turn into when you multiply them. Because the visual powers of the human mind are quite powerful he's able to do that fast.
It's kinda like using your computer's graphics card to do matrix multiplication. If you feed the info in the right format you can get the answer out faster than using the main processor, because the graphics processor actually has more computing power; but it's not as general purpose.
The upside is that this can make it easier to remember things- it means you've got more things about the thing to connect to other things- his description of how he remembered pi as a story is a *classic* description of the mnemonic technique for remembering things- you basically turn what you want to remember into a series of pictures that you string into a whacky story. It works really, really well; people easily get upwards of 90% recall using it. And he has a built in picture or sensation to help him with this; which is the hardest bit of the technique.
Um. Several studies into dirty bombs have been done. They all showed that the most dangerous part of a dirty bomb is the conventional explosive.
Whilst it is easy enough to make a dirty bomb, the expected number of casualties is very small; as in low single digit, and decontaminating the area is straightforward.
It looks a lot like what you are doing is assuming that most of the energy of an orbit is potential energy. When in fact ~93% it is kinetic energy- sideways.
In other words: to get to orbit- you have to go sideways *fast*- really, really, really fast. You go up a little bit, but you go sideways a whole bunch.
And in case you're wondering: yes, you do have to go sideways really, really, really fast to go from London to Tokyo too. It's just that you arrange for the orbit to intersect the atmosphere so that you land in Japan. And that's the *optimum* ballistic trajectory to get from London to Tokyo. In fact, IRC, you usually actually go to a higher altitude to go suborbital than LEO.
Oh yeah, check out this launcher, some of the versions have back-back comparisons of LEO and ICBM payload. http://www.astronautix.com/lvs/r29.htm
I can explain the same thing in a dozen different ways, but I don't think you're listening at all, and you don't show any signs of being able to understand the whys/what and hows so I'm stopping right here.
That's not how it works. LEO is more typically quoted at 180km high anyway; and you'd have to go pretty much that high or higher to get to Tokyo anyway.
No, look. Ignoring the ascent air resistance (which is the same for orbital/suborbital anyway pretty much), as soon as you leave the atmosphere, you are in orbit right? I mean, the orbit may intersect the ground(!), but you are technically in orbit.
Now, to go long distances you need perigee to not be too far below ground level, otherwise you will hit the ground almost immediately.
So perigee has to be close to ground level, and apogee has to be above 100km. So, right away you are describing an orbit that is 98% of the way to being a stable orbit.
I mean, what's a hundred kilometers out of 6200km (the radius of the earth). Right?
If you don't believe me, do the *real* math. As a kick-off check out the vis-visa equation and other equations on that site.
Calculate the delta-v to reach an orbit with apogee at 100km and perigee at 0km. Then add on 2km/s to deal with gravity and atmospheric losses during ascent. That will give you the delta-v for going about 1/4-1/2 of the way around the world.
> Gary Hudson gave it as a rule of thumb on USENET a year or two back IRC.
Well, then he was eiter wrong, or using way too high of an orbit.
Gary Hudson is a leading rocket engineer that has worked on numerous launch vehicles, including an ICBM IRC (which *are* suborbital delivery systems if you bother to think about it). If he says it's 30% reduction in payload; that's what it is. Period.
Yes, private branch. It was a fair amount of bother, but for the highly disciplined software engineering I was involved with, the extra process wasn't significant- not when it could take 2 days to change 1-5 lines of code :-( We had scripts to automate it mostly; so it wasn't so bad.
It may very well be that CVS is a better fit for most people. I used clearcase on a *big*, cross-site (international) project (as in several hundred software engineers all hacking away simultaneously, millions of lines of code- *BIG* project, and there it worked very well, although it seemed somewhat overcomplex to use. I think we evaluated CVS, but elected not to go that way.
IMO- The biggest problem with clearcase is that it's overcomplicated. You simply shouldn't have to jump through that many hoops to do the common stuff.
Kerosene will cost you perhaps 30 cents a kilogram in bulk;
In your dreams. Aviation fuel is over a dollar. Where you planning to get this magic cheap kero from then?
LOX will cost you perhaps 5 cents per kilogram
Last time I checked it was more like 40c a kg if you have your own plant. It's actually probably cheaper if you haven't got your own plant- the big boys wring the neck of the process to save electricity.
Do you have a reference to a 5c LOX price?
No, it can do exactly that, and very well. If it is set up correctly, basically designers can create their own side-stream, and do repeated merges into it to keep up to date.
and I have seen clear case totally bungle automatic merges before.
I have seen *designers* totally bungle merges before. A perfect merge tool or process does not exist; but it nearly always works fine. Automated merge tools are nearly always a big help though.
It's nearly always a good idea to code review all changes that are being merged back into a stream. That can solve nearly all merge problems.
And if somebody makes a change before you merge back, code inspect the merge with that too. The final merge shouldn't actually involve changing any code on the sidestream.
Gary Hudson gave it as a rule of thumb on USENET a year or two back IRC. It's also born out with experience of using *my* rocket simulator.
Even with a typical 20:1 payload fraction for kerosene rockets
Really? Name one with a 5% payload fraction. Orbital fraction maybe, but *not* payload. For seat price, you want payload fraction, including customer, seat, lifesupport etc. etc. Actually $15000 is probably low, it assumes only 100kg per person.
Actually orbital rockets typically have a 1-2% payload fraction. Divide that by 0.7 and that's roughly the London-tokyo payload.
I have priced LOX and kero in the past, and I'm comfortable with $50/kg of payload. You might be able to go somewhat lower if you manage to get a cheap supplier of LOX. The kero- if you use aviation fuel- is fairly easy to price up. I've optimistically multiplied the fuel price by only 3 to get the price. Probably 5-10 is more realistic initially.
Not even remotely. Fuel for rockets is incredibly cheap compared to everything else involved.
Yup. Compared to everything else that is currently involved.
Kerosene will cost you perhaps 30 cents a kilogram in bulk; LOX will cost you perhaps 5 cents per kilogram (you just refrigerate it out of the air, so the only cost is refrigeration).
Yeah, I priced that up too. It actually takes quite a bit of electricity to make LOX; and the electricity is not cost free.
1) Heating is proportional to velocity squared, not velocity. That means you're only getting half of the heating.
You're not listening. The delta-v to get to Tokyo is pretty close to the delta-v to get to orbit. It's not 30% less; maybe 10% less or something. You'd get nearly the same heating.
You can always return them from orbit back to Tokyo, and still beat the airflight.
True, except- wrong. The delta-v isn't 30% less; the *payload* is 30% less to go intercontinental than to go to orbit.
Lastly, since it's in a suborbital flight path for so short of a period of time, you don't have to worry so much about thermal or atmospheric regulation as you would for a true orbital craft that would be up there for days. This could be an especially big advantage for simplifying hydraulics (although I'd like to see spacecraft move away from hydraulics anyways... ;) ).
Yeah, but you do have to worry about reentry- the velocity is pretty much orbital speed.
Lastly,
You mean it this time?
you get much better economies of scale. All in all, I'd expect travel on a suborbital liner to cost at most 1/20th as much per kg if built properly, and probably much less. You might even be able to go under 100$/kg if you got enough passengers. No matter what, though, probably way too expensive for ordinary commuter flights :P It probably could fill a niche industry - a combination of space tourism with Earth tourism.
The rocket fuel is still expensive though. Maybe $50/kg of payload if you use hydrocarbon fuel. So you probably need to triple that- giving a ticket price of maybe $15,000. Looking expensive. And for the foreseeable future- dangerous.
Um, no... that doesn't work. It takes the best part of a day to get to GEO.
For instance, a flight from London to Tokyo clocks in at just under an hour (takeoff and landing included).
Sure, that works no, problem. You just don't via GEO; oh yeah, and it costs about the same as going to orbit, since the launch vehicle needs about the same performance, baring about 30%.