Your first principle is the basis of multi-stage rocket designs, right? (Leave behind the earlier stages rather than continuing to propell them.) And the second principle could be applied to a first-stage rocket.
Which is not to say that I think space plane launchers are a bad idea; I just think the idea of 'escape velocity' misleads people about the nature of getting into space.
It comes from the myth of "escape velocity". People figure, hey, why not just fly horizontally until you hit escape velocity, and then up you go, instead of trying to reach escape velocity vertically.
In practice, escape velocity changes as your altitude changes. All the energy you burn going sideways to hit escape velocity could have been spent going upwards to reach a lower escape velocity. But even so, escape velocity is just a confusing thing to introduce, instead of using an energy model. With an energy model (e.g. you must climb to height X and introduce "potential energy" Y--escape velocity is derived from a kinetic/potential energy model anyway), it becomes unambiguous about how energy you've spent so gains you, and you can now integrate issues of energy lost to drag from doing anything other than flying straight up, and the validity of shooting straight up is clear.
I had the same experience with the new search bar. I'm convinced that something neither of us saw is a good thing: the search bar should probably be at the top, not the bottom. Of course, if it's at the top not the bottom, it'll cause the whole page to jerk down when it opens, but that already happens switching between 1 tab and 2 tabs (unless you disable that).
Similarly, and this is probably more important, when I had a failed search, I didn't see the response on the search bar because (a) it was at the bottom of the window and (b) it was all the way past the buttons. Search status messages should be right adjacent to the search-text field, not past the buttons.
IAAGD*. Games vs. "products like web servers and operating systems" is a false dichotomy. Joel Spolsky has identified five distinct "worlds" of software develolpment--so taking games as representative of all commercial software is quite misleading.
The quote in the summary is no longer the lede of the article on the Palm Beach Post. I don't know if that's because it was a misquote, or because PBP screwed up, corrected, and didn't bother leaving an indication that they corrected.
The current text at PBP is An administrative law judge ruled Friday that the 15 counties that use touch-screen voting systems must be able to perform manual recounts in extremely close elections.
The real bug here is that the developer's debugger changes the OS open file limit! Running under the debugger shouldn't change the behavior of the program at all.
The author never explains why the debugger did this; at first gues it sounds like a hack made because the debugger runs in the same process as the application, and needs to open files itself, but that sounds pretty crazy. (And it did this under both MacOS and Windows? WTF?!?)
I realize that the existence of a bug in the debugger doesn't mean the author could have magically solved his problem somehow else--he still had to solve the problem without ever knowing there was a bug in the debugger. But clearly the bottom-line fault lies there, yet he never points a finger at it (nor names the debuggers in question). Moreover, that means this is not the anatomy of a typical bug at all; it is the anatomy of an incredibly rare species of bug, one that owes to a bug (misfeature) of the debugger. (Or rather, the bug itself did not, but the difficulty in debugging it did.)
Don't forget that Nike attempted to claim the right to lie in its "non-commercial" speech. (The Supreme Court rejected Nike's initial appeal, and then Nike settled--for a tiny amount--so hard to say what the outcome has been.)
You seem to have missed the part of the prospectus where they explain that they reserve the right to set the stock price to a value other than that determined by the auction.
During the bidding process, we and our managing underwriters will monitor the master order book to evaluate the demand that exists for our initial public offering. Based on this information and other factors, we and our underwriters may revise the public offering price range for our initial public offering set forth on the cover of this prospectus. In addition, we and the selling stockholders may decide to change the number of shares of Class A common stock offered through this prospectus. It is very likely that the number of shares offered will increase if the price range increases.
and
The initial public offering price will be determined by us and our underwriters after the auction closes. We intend to use the auction clearing price to determine the initial public offering price and, therefore, to set an initial public offering price that is equal to the clearing price. However, we and our underwriters have discretion to set the initial public offering price below the auction clearing price.
I have been beating this horse for over ten years. There are three kinds of people who come out in favor of software patants:
the Patent Office
patent lawyers
people with profitable software patents
These people offer various reasons one should be in favor of software patents:
the Patent Office: because patents are, like, good, duh!
patent lawyers: because patents are, like, good, duh!
people with profitable software patents: because inventors should have a moral right to not have their ideas ripped off
However, these people, and nobody else, stand to gain something obvious from software patents:
the Patent Office: money
patent laywers: money
people with profitable software patents: money
Changing the lawyers' minds isn't going to be easy. So the first order of business is to make patents not a profit center for the PTO. If patents are something worth having, let the taxpayers foot most of the bill.
See also the Windows Graphics Foundation power point slides on this page for more info.
KEY: "summary of what it says (paraphrase, not an actual quote)" - what it means - what it means from a perhaps slightly biased POV
1. "Talk at Microsoft's Meltdown conference: DX Futures"
2. "Talked about Longhorn's 'Windows Graphics Foundation'" - quote from powerpoint: 'WGF is the "next Direct3D"' - a 3d architecture for both games and for the OS (and maybe for non-rendering tasks)
3. "Unifying vertex/pixel shaders; support multiplexing by multiple apps" - Microsoft is going to continue driving the process of specifying what next generation hardware's feature sets should be (only natural, since Talisman and Fahrenheit were such succesful designs).
4. "remove fixed-function pipeline features; everything must be done by shaders" - Because obviously everyone wants to write shaders themselves for everything, even in the simple cases! Yes, please make me look up the Phong lighting formula every time I write a throwaway 3d app! Actually, the article doesn't make clear but the presentation above does that they're continuing to support the legacy DirectX interfaces, and improving support for OpenGL, so at least you can use those interfaces for fixed-function support. But the ppt above does seem to say that the hardware won't implement fixed-function stuff (which makes perfect sense--the drivers can supply an equivalent shader), and it states that a high-level shading language "will be the only methodology for Windows Graphics Foundation", with an example showing a shader iterating over multiple lights and computing the results itself.
5. "no more caps bits (capability bits)" - Hey, it's yet another of the things that OpenGL got right all along. Not sure what prevents someone from accessing a legacy D3D API and getting at the caps bits there, but at least there won't be any new ones.
6. "stability; if we're using 3d graphics hardware for basic desktop rendering, it's got to be super stable, and when it crashes, it needs to be able to reset trivially without the machine going down." - the ppt says the new architecture design is trying to reduce driver complexity. I am extremely doubtful about this.
Although there are other strategic fixes discussed in the bugzilla discussion, it seems to me the first point of order is to NOT allow disabling/hiding of the toolbars and status line. These are tools for the user; there's no reason for "untrusted" sites to be able to do this. There seems to be a strange mentality of trusting the remote site's opinion over that of the user, rather than "sandboxing" the remote site's control into a limited part of the browser (the "client area" aka the "content area").
Some site authors may say "but I really want to author a popup that doesn't have all that crap etc," but I don't see how it can be that important, especially given all the consequent badness. The only case I can see for this is that sometimes you do trust the content author--that there is a notion of Mozilla as a platform for application development. And, hey, ok, code reuse is good, but using Mozilla as a platform for a company-internal application is a totally different scenario; can't we recognize that as a different scenario and give it different rules instead of using one browser to rule them all?
Now, without being able to disable the location bar, you can't spoof the location bar trivially. You could put up a second one and hope people don't notice, and yeah, some people won't. Unfortunately, as pointed out on bugzilla, there's a case that this won't stop: you create an entire faux window, one that appears to be in front of the main one, but is actually just a part of it. So in the middle of your page you have a seeming popup window with a seeming location bar with a faux address. It wouldn't be draggable outside of the client area of the main window, but some people wouldn't notice it.
It's hard to see how to defend against that, although I am a wacky retro guy who thinks all of this DHTML stuff has given content creators way more power than they really need, and there would be nothing wrong with just pushing back on the standards until things weren't spoofable. (Remember when standards meant you wrote an RFC about something you had already implemented and figured out really worked; it didn't become a standard until people had exercised it in the field? Whatever happened to that?) Or maybe Ian Hickson is right and we're all just raving paranoic nutjobs. But it seems like exactly the sort of 'power before security' attitude that's gotten MS in a lot of trouble.
An entirely different way of looking at the problem of spoofing is that we transmit our secrets "in the clear" to the remote site. (Obviously encrypted by https or whatever.) If the remote site is spoofing, they get our password (and can maybe even open a connection to paypal or whatever and pass through everything so we don't know it's been spoofed). There's no need for us to give the secret to the remote site, though; just prove that we know it. For example, the server can give us some random data, and we use a non-reversible encryption algorithm to combine the random data and the password, and return the result of that. The server can verify that it's the right result without anyone transmitting the actual password (though the server must store the actual password, and not a hash of it). If this were the technology we were using, a spoofer wouldn't be able to use the password, unless the spoofer DID open a connection to the real site first, and get the challenge; then it could pass it through, but then the spoofer would have only this one chance to make use of the spoofed data, since the next time the real site challenged, the spoofer is stuck; whereas currently a spoofer just captures the user/password combo and keeps it around for later processing. This would raise the complexity bar for making effective use of spoofing (including email phishing!), although I don't know if it's high enough. But good luck getting it into browsers AND making it impossible for spoofers to create what looks like a login prompt of this kind but actually is just a plain old plaintext submit.
Dude, you seem to have missed the part where they ALREADY marked the bug unconfidential on bugzilla (before this particular demo of the exploit was released) and where a bunch of researchers at Dartmouth published several papers on it.
Your implied claim ("hyperthreading isn't really two processors") only makes sense with an overly simplistic view of what a "processor" is.
Let's say the basic components in a processor are: instruction fetch, instruction decode, load/store units (memory save/load), various execution units (that do the adds, multiplies, etc.), and a register file. Current hyperthreading allows for relatively fine grained switching between threads, so I believe there are two separate register files, but all the other units shared. (Are there two MMUs and TLBs? I'm not sure, but somehow they allow hyperthreading between two unrelated processes, supposedly.) Already we do have two of something (register file, and maybe the memory management hardware).
There's a continuum of possibilities. What if there are two of everything except the execution and load/store units? Note that the whole machine is massively pipelined, so there are multiples of these even when there is just one procesor. So do you have two processors which share execution units, or one processor with super-hyperthreading?
Assuming you consider it the former, then we can mix it up. Maybe there's two instruction fetch units, but a single instruction decoder. Etc. etc. Now, you could pick one thing, say instruction decode, and say 'there must be two of these to be considered two processors'. Oops, I forgot to mention, superscalar processors already can decode multiple instructions at once (just not from multiple instruction streams), and even so, different people are going to pick different definitions; there's no clear differentiator.
A pure two-core approach is just easier/cheaper to design, since you basically just design them separately, or really, design one and clone it. But you can probably get more performance for the same chip area by pushing those two cores together and allowing them to share resources, even though that will look more like hyperthreading in terms of design. Normally you think of hyperthreading as being less efficient than pure two separate processes, yet I claim this more-like hyperthreading design gets higher performance that two separate processors; I can't see how you wouldn't be better off sharing the 2N execution units rather than using a fixed N in each core.
In the end it boils down to (roughly) "I can get so many FP and integer units on chip; what's the best way I can feed instructions from any number of threads to maximize their usage?"
Yeah, I have to give Macromedia props on Flash. Bitching about ads or other abuses is insane; if there was some popular open source Flash-like thing, that would be getting equivalently abused. Flash is small, it works, and it's a lot better through than most "web standards".
An example of that last thing: stuff I access off the web is "untrusted content". Good window managers understand that as much as possible, the user (not the app) should be in control of the windows and the window location on the desktop. The same is true in the browser: the status line is for the user; the buttons are for the user. HTML and javascript goes crazy with allowing opening of new windows without status bars, without scrollbars (even when the client can detect that a scrollbar is needed anyway, most don't provide one if the code requested none), etc. See those dopey "vibrate your window" javascript apps. Flash can't do this; the flash application is sandboxed not in terms of disk, but in terms of screen real estate. Here you go; here's your client space. This has been a mess for years with javascript; w3c has sided with a "trust the author" paradigm with CSS, and browsers (e.g. Firefox) still don't sensibly override all of it (e.g. with needed scrollbars); whereas Flash picked a "safe" model from day one and hasn't changed it.
Two miles and a second are both fathomable, obviously.
Instead of directly trying to imagine achieving that distance in that time, though, let's just step back for a second.
Current passenger airliners (presumably the fastest things most of us have immediate experience with) fly on the order of 600 mph. Mach 1 is 761 mph. So think about how fast a passenger airliner moves, and then imagine something going 12 times as fast. That's two miles per second.
I find this a lot easier to comprehend than, say, a car at the same speed ("100 times faster than a 65mph car!"), or just some abstract concept of speed.
That trip to LEO would take up to nine days, but that's a good thing; for, what goes up fast, must come down fast, and speed is energy which must be bled off by either massive amounts of expensive and explosive rocket fuel, or through ablative heat transfer which has its own problems
I'm not a rocket scientist, but this seems nonsensical. You don't need to "bleed off" the speed of something going into orbit--gravity will do it for you. The kinetic energy (speed) is turned into potential energy (gravitational). Any speed short of escape velocity will fail to escape earth orbit, so any speed short of escape velocity doesn't need bleeding off. (It's true that if you throw a ball up at higher speeds it comes down at higher speed [ignoring air resistance], but this has nothing to do with throwing a self-propelled ball into orbit.)
You can maybe naively figure work is energy, and work is force times distance, and a reduced force through the same distance is less work, but it's not actually less energy. Try going into low-earth orbit and not orbiting, instead hover without orbiting. I guarantee you'll be spending energy hovering, even though naive work of force-times-distance is 0 (since distnace is 0). No matter what speed you go getting into orbit, you'll need to increase your potential energy by the same amount--but a nine day trip to orbit is like nine extra days spent hovering.
Please note that I'm saying this without having read "the" article, since I don't know which of the twelve links this claim might have came from.
Sleep wit' da Fishes!
Nebulae Drawing Tool
Stunt Hamsters
Deadly Dance of the Robots
Robot Circus (sort of)
BootLooter
Some of the downloads are huge because of large music files (even after downsampling) and image files. We'll try to institute a system next year that allows things like replacing WAVs with MP3s without needing to touch the source code, so we can shrink the downloads more effectively after the event.
They get tons of submissions every day. We're not asking them to read or validate every submission. We're asking them to take the ones they're going to post and actually click through and read a little. That does not seem unreasonable, given that there's no voting on stories, only on comments.
In fact, presumably they do this, since we don't get lots of interesting-sounding submissions that turn out to be blind links to the goatse.cx du jour. So the more natural conclusion is they do read things behind the link, and they don't give a damn if the submitter is plagiarizing. Or at CmdrTaco doesn't.
Maybe the writers and animators deserve raises more, though, than people geting 125K for 30 minutes of work. Of course, they're not "stars", so they don't get press, and they don't have the not-easily-replaceable quality that the voice talent does. So, yes, the voice talent can effectively extort more money, because they're visible; that doesn't mean they deserve it more than the others.
Slashdot Mirror
SIMNET is 10 years old and could scale up that large, so I doubt there's much relevance to this new thing for gaming.
Which is not to say that I think space plane launchers are a bad idea; I just think the idea of 'escape velocity' misleads people about the nature of getting into space.
It comes from the myth of "escape velocity". People figure, hey, why not just fly horizontally until you hit escape velocity, and then up you go, instead of trying to reach escape velocity vertically.
In practice, escape velocity changes as your altitude changes. All the energy you burn going sideways to hit escape velocity could have been spent going upwards to reach a lower escape velocity. But even so, escape velocity is just a confusing thing to introduce, instead of using an energy model. With an energy model (e.g. you must climb to height X and introduce "potential energy" Y--escape velocity is derived from a kinetic/potential energy model anyway), it becomes unambiguous about how energy you've spent so gains you, and you can now integrate issues of energy lost to drag from doing anything other than flying straight up, and the validity of shooting straight up is clear.
Similarly, and this is probably more important, when I had a failed search, I didn't see the response on the search bar because (a) it was at the bottom of the window and (b) it was all the way past the buttons. Search status messages should be right adjacent to the search-text field, not past the buttons.
It's called "hyperbole". Look it up.
[*] I Am A Game Developer
The quote in the summary is no longer the lede of the article on the Palm Beach Post. I don't know if that's because it was a misquote, or because PBP screwed up, corrected, and didn't bother leaving an indication that they corrected. The current text at PBP is An administrative law judge ruled Friday that the 15 counties that use touch-screen voting systems must be able to perform manual recounts in extremely close elections.
The author never explains why the debugger did this; at first gues it sounds like a hack made because the debugger runs in the same process as the application, and needs to open files itself, but that sounds pretty crazy. (And it did this under both MacOS and Windows? WTF?!?)
I realize that the existence of a bug in the debugger doesn't mean the author could have magically solved his problem somehow else--he still had to solve the problem without ever knowing there was a bug in the debugger. But clearly the bottom-line fault lies there, yet he never points a finger at it (nor names the debuggers in question). Moreover, that means this is not the anatomy of a typical bug at all; it is the anatomy of an incredibly rare species of bug, one that owes to a bug (misfeature) of the debugger. (Or rather, the bug itself did not, but the difficulty in debugging it did.)
Don't forget that Nike attempted to claim the right to lie in its "non-commercial" speech. (The Supreme Court rejected Nike's initial appeal, and then Nike settled--for a tiny amount--so hard to say what the outcome has been.)
and
These people offer various reasons one should be in favor of software patents:
However, these people, and nobody else, stand to gain something obvious from software patents:
Changing the lawyers' minds isn't going to be easy. So the first order of business is to make patents not a profit center for the PTO. If patents are something worth having, let the taxpayers foot most of the bill.
PS. Man, LZW expired. I need to make a new shirt.
KEY: "summary of what it says (paraphrase, not an actual quote)" - what it means - what it means from a perhaps slightly biased POV
1. "Talk at Microsoft's Meltdown conference: DX Futures"
2. "Talked about Longhorn's 'Windows Graphics Foundation'" - quote from powerpoint: 'WGF is the "next Direct3D"' - a 3d architecture for both games and for the OS (and maybe for non-rendering tasks)
3. "Unifying vertex/pixel shaders; support multiplexing by multiple apps" - Microsoft is going to continue driving the process of specifying what next generation hardware's feature sets should be (only natural, since Talisman and Fahrenheit were such succesful designs ).
4. "remove fixed-function pipeline features; everything must be done by shaders" - Because obviously everyone wants to write shaders themselves for everything, even in the simple cases! Yes, please make me look up the Phong lighting formula every time I write a throwaway 3d app! Actually, the article doesn't make clear but the presentation above does that they're continuing to support the legacy DirectX interfaces, and improving support for OpenGL, so at least you can use those interfaces for fixed-function support. But the ppt above does seem to say that the hardware won't implement fixed-function stuff (which makes perfect sense--the drivers can supply an equivalent shader), and it states that a high-level shading language "will be the only methodology for Windows Graphics Foundation", with an example showing a shader iterating over multiple lights and computing the results itself.
5. "no more caps bits (capability bits)" - Hey, it's yet another of the things that OpenGL got right all along. Not sure what prevents someone from accessing a legacy D3D API and getting at the caps bits there, but at least there won't be any new ones.
6. "stability; if we're using 3d graphics hardware for basic desktop rendering, it's got to be super stable, and when it crashes, it needs to be able to reset trivially without the machine going down." - the ppt says the new architecture design is trying to reduce driver complexity. I am extremely doubtful about this.
Some site authors may say "but I really want to author a popup that doesn't have all that crap etc," but I don't see how it can be that important, especially given all the consequent badness. The only case I can see for this is that sometimes you do trust the content author--that there is a notion of Mozilla as a platform for application development. And, hey, ok, code reuse is good, but using Mozilla as a platform for a company-internal application is a totally different scenario; can't we recognize that as a different scenario and give it different rules instead of using one browser to rule them all?
Now, without being able to disable the location bar, you can't spoof the location bar trivially. You could put up a second one and hope people don't notice, and yeah, some people won't. Unfortunately, as pointed out on bugzilla, there's a case that this won't stop: you create an entire faux window, one that appears to be in front of the main one, but is actually just a part of it. So in the middle of your page you have a seeming popup window with a seeming location bar with a faux address. It wouldn't be draggable outside of the client area of the main window, but some people wouldn't notice it.
It's hard to see how to defend against that, although I am a wacky retro guy who thinks all of this DHTML stuff has given content creators way more power than they really need, and there would be nothing wrong with just pushing back on the standards until things weren't spoofable. (Remember when standards meant you wrote an RFC about something you had already implemented and figured out really worked; it didn't become a standard until people had exercised it in the field? Whatever happened to that?) Or maybe Ian Hickson is right and we're all just raving paranoic nutjobs. But it seems like exactly the sort of 'power before security' attitude that's gotten MS in a lot of trouble.
An entirely different way of looking at the problem of spoofing is that we transmit our secrets "in the clear" to the remote site. (Obviously encrypted by https or whatever.) If the remote site is spoofing, they get our password (and can maybe even open a connection to paypal or whatever and pass through everything so we don't know it's been spoofed). There's no need for us to give the secret to the remote site, though; just prove that we know it. For example, the server can give us some random data, and we use a non-reversible encryption algorithm to combine the random data and the password, and return the result of that. The server can verify that it's the right result without anyone transmitting the actual password (though the server must store the actual password, and not a hash of it). If this were the technology we were using, a spoofer wouldn't be able to use the password, unless the spoofer DID open a connection to the real site first, and get the challenge; then it could pass it through, but then the spoofer would have only this one chance to make use of the spoofed data, since the next time the real site challenged, the spoofer is stuck; whereas currently a spoofer just captures the user/password combo and keeps it around for later processing. This would raise the complexity bar for making effective use of spoofing (including email phishing!), although I don't know if it's high enough. But good luck getting it into browsers AND making it impossible for spoofers to create what looks like a login prompt of this kind but actually is just a plain old plaintext submit.
Dude, you seem to have missed the part where they ALREADY marked the bug unconfidential on bugzilla (before this particular demo of the exploit was released) and where a bunch of researchers at Dartmouth published several papers on it.
Let's say the basic components in a processor are: instruction fetch, instruction decode, load/store units (memory save/load), various execution units (that do the adds, multiplies, etc.), and a register file. Current hyperthreading allows for relatively fine grained switching between threads, so I believe there are two separate register files, but all the other units shared. (Are there two MMUs and TLBs? I'm not sure, but somehow they allow hyperthreading between two unrelated processes, supposedly.) Already we do have two of something (register file, and maybe the memory management hardware).
There's a continuum of possibilities. What if there are two of everything except the execution and load/store units? Note that the whole machine is massively pipelined, so there are multiples of these even when there is just one procesor. So do you have two processors which share execution units, or one processor with super-hyperthreading?
Assuming you consider it the former, then we can mix it up. Maybe there's two instruction fetch units, but a single instruction decoder. Etc. etc. Now, you could pick one thing, say instruction decode, and say 'there must be two of these to be considered two processors'. Oops, I forgot to mention, superscalar processors already can decode multiple instructions at once (just not from multiple instruction streams), and even so, different people are going to pick different definitions; there's no clear differentiator.
A pure two-core approach is just easier/cheaper to design, since you basically just design them separately, or really, design one and clone it. But you can probably get more performance for the same chip area by pushing those two cores together and allowing them to share resources, even though that will look more like hyperthreading in terms of design. Normally you think of hyperthreading as being less efficient than pure two separate processes, yet I claim this more-like hyperthreading design gets higher performance that two separate processors; I can't see how you wouldn't be better off sharing the 2N execution units rather than using a fixed N in each core.
In the end it boils down to (roughly) "I can get so many FP and integer units on chip; what's the best way I can feed instructions from any number of threads to maximize their usage?"
An example of that last thing: stuff I access off the web is "untrusted content". Good window managers understand that as much as possible, the user (not the app) should be in control of the windows and the window location on the desktop. The same is true in the browser: the status line is for the user; the buttons are for the user. HTML and javascript goes crazy with allowing opening of new windows without status bars, without scrollbars (even when the client can detect that a scrollbar is needed anyway, most don't provide one if the code requested none), etc. See those dopey "vibrate your window" javascript apps. Flash can't do this; the flash application is sandboxed not in terms of disk, but in terms of screen real estate. Here you go; here's your client space. This has been a mess for years with javascript; w3c has sided with a "trust the author" paradigm with CSS, and browsers (e.g. Firefox) still don't sensibly override all of it (e.g. with needed scrollbars); whereas Flash picked a "safe" model from day one and hasn't changed it.
Instead of directly trying to imagine achieving that distance in that time, though, let's just step back for a second.
Current passenger airliners (presumably the fastest things most of us have immediate experience with) fly on the order of 600 mph. Mach 1 is 761 mph. So think about how fast a passenger airliner moves, and then imagine something going 12 times as fast. That's two miles per second.
I find this a lot easier to comprehend than, say, a car at the same speed ("100 times faster than a 65mph car!"), or just some abstract concept of speed.
I'm not a rocket scientist, but this seems nonsensical. You don't need to "bleed off" the speed of something going into orbit--gravity will do it for you. The kinetic energy (speed) is turned into potential energy (gravitational). Any speed short of escape velocity will fail to escape earth orbit, so any speed short of escape velocity doesn't need bleeding off. (It's true that if you throw a ball up at higher speeds it comes down at higher speed [ignoring air resistance], but this has nothing to do with throwing a self-propelled ball into orbit.)
You can maybe naively figure work is energy, and work is force times distance, and a reduced force through the same distance is less work, but it's not actually less energy. Try going into low-earth orbit and not orbiting, instead hover without orbiting. I guarantee you'll be spending energy hovering, even though naive work of force-times-distance is 0 (since distnace is 0). No matter what speed you go getting into orbit, you'll need to increase your potential energy by the same amount--but a nine day trip to orbit is like nine extra days spent hovering.
Please note that I'm saying this without having read "the" article, since I don't know which of the twelve links this claim might have came from.
FTC Consumer Alert: Is Someone "Phishing" for Your Information? Not that I have any clue how often they prosecute.
Sleep wit' da Fishes!
Nebulae Drawing Tool
Stunt Hamsters
Deadly Dance of the Robots
Robot Circus (sort of)
BootLooter
Some of the downloads are huge because of large music files (even after downsampling) and image files. We'll try to institute a system next year that allows things like replacing WAVs with MP3s without needing to touch the source code, so we can shrink the downloads more effectively after the event.
Good call. Updated.
In fact, presumably they do this, since we don't get lots of interesting-sounding submissions that turn out to be blind links to the goatse.cx du jour. So the more natural conclusion is they do read things behind the link, and they don't give a damn if the submitter is plagiarizing. Or at CmdrTaco doesn't.
Capitalism, of course, is not about "right", it is about having the power to make money, so this outcome is perfectly consistent with capitalism.
Maybe the writers and animators deserve raises more, though, than people geting 125K for 30 minutes of work. Of course, they're not "stars", so they don't get press, and they don't have the not-easily-replaceable quality that the voice talent does. So, yes, the voice talent can effectively extort more money, because they're visible; that doesn't mean they deserve it more than the others.