One thing I do not understand is why Friend Codes are so hated. They do exactly what Nintendo wants. Keep their kid safe image. With friends codes, you only play with the yahoos who you KNOW PHYSICALLY.
I don't think kids should be knowing each other physically.
Just because a Leatherman has screwdrivers doesn't mean you can use them on cars, or plumbing, or anything that requires high torque. You keep your Leatherman, I'll keep my 88 piece Craftsman set.
Well you take the Leatherman when you're going out (not to a job site) because it's smaller and more portable, even though it doesn't do everything great. The Craftsman set stays in the garage for when your working on your car. Just like you might have a mobile jack-of-all-trades device, but when you're sitting at home it makes sense to have a superior stand-alone device for each task.
Well if a developer is not taking advantage of the SPEs, chances are they didn't bother to take advantage of the extra cores in the 360 either. Perhaps.
Perhaps, yes. The 360 requires threaded programming to use well. The PS3 needs to be multithreaded, and those threads have to be suitable for the SPEs which have strange programming models. For example, their 'caches' don't mirror memory like normal caches, instead the they have to be explicitly managed and data moved in and out.
I find it far more likely that the developer just has a much better handle on DX9 than OpenGL(which is basically what the PS3 graphics API is).
Very well could be, I hadn't thought of the API issue at all.
That is actually an interesting observation. Personally, I'd prefer to see fewer ports, or maybe ports that are just far more differentiated. If I have to buy more than one console in order to play everything I want to play, so be it.
I'm not sure how I feel about it. I don't really want to buy multiple consoles, but I also don't really like crappy ports. If I only have one console, I also don't care how differentiated they are.
Yeah, but I'll admit to being dissapointed when I read that. I'm glad the game is fun, and I look forward to playing it, but the screenshots for the game looked pretty sweet and I was also looking forward to great Zelda graphics. If Gabe is touting the game and saying how good it is while simultaneously admitting that it doesn't look very good for a GC game, that does kind of worry me. Maybe I won't think about the graphics, but maybe I want to think about the graphics from time to time, specifically "these graphics rock!"
The power glove flopped because it was an expensive add-on and there were basically no games designed for it, so it was a glove that had to somehow act like a Nintendo controller. I never had one (see price), but from what I heard it was fun to play Punch-Out with and that was about it. The NES was really not a great system to try innovative motion-sensing control schemes on, considering how few NES games even used all 8 binary game pad directions. Funny, because even a decade later I was reading about hobbiests praising the power glove for actually being a pretty good glove that could do things like detect how far you had curled each finger that other similarly priced gloves couldn't do. So basically total overkill.
The Wiimote is built into the console and is the foundation of Wii gameplay, is cheaper if you want extras, and is matched to a system capable of doing something useful with the nuanced input it is getting. I completely agree that it's appropriate to wait and see how it feels after using it a while before passing judgement good or bad. I just disagree that history gives me reason to doubt.
P.S. speaking of failed Nintendo add-on controllers, I don't hear many people mention whatever the hell they called that ridiculous light-bazooka for the SNES. Seriously, it was the size of a small shoulder-fired rocket launcher and was intended to be held the same way. I don't know what the hell that was about. A relative accidentally bought me a game that needed it, so I never played it, making it only a slightly better gift than Donkey Kong 3 was.
The new format war is going to stifle acceptance and sales of both types of HD media as the public is not going to be able to figure out what the hell they need to buy.
I completely agree. The only way it will work is if Joe Blow can walk into Best Buy and ask "What do I need to buy?" and the clerk can say "Buy one of these players, they play everything" and then he never has to care about formats again -- until of course the Powers That Be decide we need to re-purchase our movie libraries once again.
Nobody doubts that the PS3 has potential. If you just look at raw numbers (like everyone did with the Emotion Engine, but still) the Cell is freaking awesome. I went to a talk by IBM about the Cell where they discussed some architectural tidbits about the SPEs and the internal interconnect ring (IBM loves rings*) which is also just nuts. When fully banging away, you could get a ridiculous amount of data throughput.
The problem is you have to give those SPEs something to do. But it's a new programming model with some strange quirks compared to processors most programmers are used to, and I don't think the tools are up to snuff yet either so it's all manual coding to get it to work.
I wouldn't be surprised if a lot of early games, especially the hasty ports from xbox, don't even use the SPEs and just use the Power core. In which case the PS3 isn't as powerful as the xbox.
So there's lots of potential, no doubt about it, the question is just if we'll see it taken advantage of in most games and how long it will take for that to happen. As always the longer a console is out the better people get at programming for it. It just seems like with the Cell architecture that it is going to take longer for people to wrap their heads around the PS3, even if the payoff is huge.
It's interesting that in this generation there seems to be higher barriers to porting than before. The PS3 with it's odd architecture and the Wii with it's odd control scheme may mean we see fewer ports... or maybe just shittier ones. Maybe that's what Tony Hawk is a herald of.
* Maybe it's just me, but between their obvious love of rings (ring interconnect bus on Cell, using token ring networks as late as 98) and their legal team known as the Nazgul, IBM kinda scares me.
If your program relies upon a shared library, and that library breaks ABI compatibility, though, you're still screwed. Sure, there are work-arounds if you control your program's sources - you could statically link things in, or do some LD_PRELOAD hack to load the right version of the right shared libraries. But this assumes that you have a lot under your control. You might not have this luxury if you're using a 3rd-party proprietary library or program.
I come at this from the standpoint of a debian user, where the update of the library would also bring an update of dependent software, so ABI compatability isn't as important because everything gets updated to the new ABI. Yeah, it's true that a 3rd party proprietary program can't do this, which is why I'm suggesting that to get the most out of Linux businesses may want to move away from such programs or start negotiating for source access. I readily admit this may not be feasible.
But then there's also API breakage, which is a major part of "backwards compatibility" that must be taken into account. If the kernel syscall numbers (or the arguments thereto) change, there's major breakage. inotify vs. dnotify vs. fam? udev vs. static dev? Does your program assume that/dev/fd0 is the floppy drive?
Yeah, I realize that APIs are actually less stable than I implied. Free software still has the nice property of being a more dynamic system that can be updated to track API changes, but it isn't as easy as just recompiling in all cases by any means.
They go to great lengths to keep old applications running with new Windows versions, and not just old versions of actual Windows OS.
Of course that's what I was talking about. If it was 'just old versions' that would be, I don't know what you'd call it, "not-changing-anything compatability", which most systems are pretty good at.
No matter how violent and predatory we may imagine ourselves to be, we are amateurs compared to what nature has produced.
You have very good points, but I wouldn't call us amateurs. I'd say we are one of nature's better attempts.
As far as cruel, nasty death: Before the invention of crafted tools, humans hunted by using our more efficient jogging gait to run down animals, pursuing them relentlessly until they collapsed from heat exhaustion, at which point we'd walk up and kill them with our bare hands, or a rock or stick. Remember what you felt like when you ran the farthest you could, the burning lungs and muscles. Then imagine running more because something was trying to eat you, until a long time later you are physically incapable of moving even under threat of death because your body has overheated. Then you get bludgeoned to death by a hairless monkey.
I think we have doled out our fair share of pain through the food chain.
Heh, it's funny though, this post reminds me of when I was much younger and would often watch nature shows with my dad, which of course would feature things like a jaguar tackling a gazelle. He would always tell me that it was okay, because first it was nature, and second the gazelle would kinda pass out as soon as the jaguar got him so he didn't feel any pain. Now of course I know that isn't true but it did probably keep me from crying a lot so I could learn from the shows. Thanks for sheltering me, dad.
Because I know they need it. Without compatability with old Windows software, the next buying cycle every CTO on earth would have a chance to consider whatever operating system they wanted since all would involve switching to entirely new software, as opposed to now where buying Windows to replace Older Windows is the automatic choice. It isn't just Window's market share that maintains there monopoly, it's the resulting market share of software for Windows that really does it. Drop that, and Windows' real advantage is gone.
I do make fun of them for not being able to stabilize and secure some of the old code, though I understand it's tough when the code is old, complicated, and crufty, and a lot of old programs require "bug for bug" compatability.
I think the solution for them is deprecation. Old interfaces that are stuffed with crufty code, and which were often insecure by design anyway, should simply be made unavailable for new applications. You have an old app that wants to use it, fine. You want to code a new app using OLE or ActiveX or what have you? Tough. Eventually software gets replaced, and eventually you wouldn't have any software using the old systems and you could disable them. Sadly there's still plenty of new development using ActiveX and other crap, so MS both shows no interest in doing this nor may they be able to.
Now how does this apply to Linux? In Free Software Happy Land, you have the source to all the software on your system, so with the ability to recompile you don't need binary backward compatability. Being able to link your source code against new libraries can fix a lot of the problems with having to support really old binaries. There's still the issue of interface compatability (which is tied up in binary compatability in the Windows world), but a lot of the interfaces are stable.
This isn't Free Software Happy Land, though, we're talking about businesses. Personally I think that adopting Linux should also come with adopting some of its philosophies, in particular that having source code is much much better than not having it, so if you aren't getting source then it had better be much much better than the program you can get with source. Linux does not have a strong history of binary compatability, and I'm not sure it's best for Linux to start establishing such a history. Business may not like it, but maybe they need to adapt to Linux not the other way around. Who knows, they might figure out that they like getting source code from their vendors and accidentally discover a better way to do things.
So we're going to rely on bigger and bigger pizza pies to protect our bigger and bigger space investments? My god, man, you're talking about a pizza larger than we're capable of baking. And think of the tomatoes necessary for such an operation!
Yes! Space-based pizza infrastructure doesn't have the inherent weight problem that a ground-based one does, so we could theoretically build truly gigantic pizza ovens, powered with nuclear weapons. Let's ressurect Cold War tech for the Cold Pizza War!
I forsee a Pepperoni gap between us and the Russkies.
I'm afraid it's the Italians we'll have to be worried about. I hear they're already planning a space-based pizza-pie so large that with it's crust side facing earth it would appear as large and bright as the moon from the ground. It's codenamed Amore, and I hear they already have a nationalistic song about it.
In the rough sketches I have seen, the Isp would be about 5 times higher.
And thus the energy per kg are 5 times higher for the same thrust. Which given some rough calculations based on a single Shuttle SRB (500,000 kg of fuel over 120 second burn, impulse 2500 m/s) is about 25 terrawatts of delivered power to match the one booster. There's a reason high thrust and high Isp aren't often seen together.
How about the machine counts the paper ballot you filled out and drops it in a bin?
Yeah, and in theory, it could also tell you if it couldn't read the ballot because it was badly formed. Okay, machines can already do that, though in some notable cases in Florida this capability was disabled (but people just assumed it was because those voters were idiots).
I do think an electronic ballot machine has some advantages. I like the part of e-voting where I can easily browse candidates, click buttons that show the full text of any propositions or measures being voted on, easily change a vote if I decide to change my vote, and so on. I like the idea of eliminating penciling errors by having the computer print it. I like the accessibility options e-voting can give.
In my ideal e-voting world, you'd have one machine that prints ballots on card stock in a human-and-machine readable format (with the same markings, not human-readable-text and a barcode). You'd take the ballot it prints out and put it in a different machine that could count the vote. In fact, because the format of the ballot would be a matter of public record, anyone could make a ballot counting machine and after passing some basic certification (that it doesn't mangle ballots for example) could bring it to the election to verify that their machine got the same count as everyone else's machine.
Of course something simple like you describe works. As long as there is the paper record which is considered authoritative, and the machine count only an initial estimate, then that's a voting system I support.
But you would have substantial velocity. You'd have the same velocity as the ribbon itself, the same angular velocity as the earth times 500km. All for zero fuel, and thus no weight penalty that you have to account for in the amount of fuel needed for further acceleration.
The Wicked Lasers are more powerful than your typical green laser, but most green lasers are bright enough that you can see the beam, but can't do the tricks you see in those (totally sweet) videos. They're great for pointing at stellar objects when out stargazing. Just watch out for airplanes, not just for safety and common sense, but because Homeland Security will come after your sorry ass.
Go up another measly 500 kilometers, and your new acceleration is approximately (6.67e-11 * 5.97e24) / (6.87e6^2) = 8.44 m/s^2. That's only a 14% difference; a very noticeable reduction, but not enough to have significant savings. Your rocket fuel wouldn't go much farther at all, at least when the goal of the space elevator is to reduce cargo costs by orders of magnitude.
Yeah, but you also didn't have to carry the fuel to go those first 500 kilometers, so your craft is much lighter.
For all the engineers here: why would you want to build a cable tens of thousands of miles long out of currently UNAVAILABLE materials (unobtanium) to slowly ratchet up one payload at a time?today, because we can't, but one day maybe we can. On that day, building a space elevator will be a great idea.
It's a horrid idea, and it STILL takes just as much actual energy to put anything in orbit...just it does so pathetically slowly.
This is incorrect. It takes much more energy to lift something with a rocket because the rocket also has to lift its fuel, which requires more fuel and thus more weight and thus more fuel... In fact, much more energy is spent lifting the fuel that provides energy than is spent lifting the actual cargo. Look at the relative size of the Shuttle's SRBs and external fuel tank compared to the cargo bay. This is why launch costs are so high.
Pulses of light vaporize the fuel in a sequence such that the shock wave of superheated vaporized gas is planar : basically a rocket engine without needing
This has the same fundamental problem as all reaction engines: If you push your craft by throwing particles out the ass-end, you have to carry the particles you're going to be throwing which means a heavier craft which means more particles are needed, resulting in the same exponentially increasing weight problems as existing chemical rockets.
Your idea is no better than the space shuttle in terms of lift capacity, except we have to provide the same amount of Power as all the shuttle's rockets with lasers. The advantage here of the space elevator, aside from not having to pay the reaction mass penalty, is that the lasers can be much lower wattage.
x86 is a horrible mismash of backwards compatibility
My only disagreement with this statement is that you didn't use enough superlatives and explitives.
the day we have to wipe the slate and start over will be the day x86 stability improves 10fold.
Are you talking about software stability? I highly doubt ISA backward compatability is a significant source of instability. Old software may be unstable, but it would be unstable on old hardware or new. Windows backward compatability causes instability because it prevents them from re-writing or getting rid of insecure and unstable interfaces, but the ISA isn't the problem.
Besides, one nice thing is that when a new operating mode is introduced it provides an opportunity to drop old features, except in compatability modes. E.g., x86-64 (mostly) doesn't have segmentation, it doesn't have undefined flag values, it doesn't have some of the stranger and more useless instructions. Sure if you switch to 32-bit or 16-bit mode it does, but new software isn't encumbered with the cruft. And hardware designers are free to make the old cruft slow so as to discourage it's continued usage.:)
If you know the source code of the software (including build options etc), and the compiler/linker versions that have been used to build it, it will be possible to prove whether or not the binary code on the machine was generated from the source code in front of you.
No, you cannot prove it, because you cannot know that the software/hardware isn't lying to you. It's like a rootkit, designed to fool you into thinking everything is normal while simultaneously subverting the machine. It's only even conceivable to do this with some kind of Trusted Computing platform, but there's the rub -- when it is you the user who does not trust the manufacturer, how do you know that the Trusted Computing encryption chip isn't similarly designed to lie to you?
OSS is nice, but it does not solve the fundamental problem. Until we solve that fundamental problem, lobbying for open source is counter-productive. It will be a more difficult fight, and it won't fix anything. The real fight is for paper ballots. Once we know the machine is working right because it prints our ballots correctly, then we can worry about the source code if there is still a reason to.
The last time I looked, I seem to remember some folks working on decompilers that would produce higher-level languages (mostly C, that I recall), but have no idea if anybody ever got 'em working well.
It's been about five years since I touched one, but they work well enough. They do a fine job of identifying basic blocks, variables, and functions, and produce code that can be fed back into a compiler. The big problem is that it's still largely unreadable because it doesn't have any of the conceptual meaning conveyed by the original code -- i.e. descriptive function/variable names.
Slashdot Mirror
One thing I do not understand is why Friend Codes are so hated. They do exactly what Nintendo wants. Keep their kid safe image. With friends codes, you only play with the yahoos who you KNOW PHYSICALLY.
I don't think kids should be knowing each other physically.
Just because a Leatherman has screwdrivers doesn't mean you can use them on cars, or plumbing, or anything that requires high torque. You keep your Leatherman, I'll keep my 88 piece Craftsman set.
Well you take the Leatherman when you're going out (not to a job site) because it's smaller and more portable, even though it doesn't do everything great. The Craftsman set stays in the garage for when your working on your car. Just like you might have a mobile jack-of-all-trades device, but when you're sitting at home it makes sense to have a superior stand-alone device for each task.
Well if a developer is not taking advantage of the SPEs, chances are they didn't bother to take advantage of the extra cores in the 360 either. Perhaps.
Perhaps, yes. The 360 requires threaded programming to use well. The PS3 needs to be multithreaded, and those threads have to be suitable for the SPEs which have strange programming models. For example, their 'caches' don't mirror memory like normal caches, instead the they have to be explicitly managed and data moved in and out.
I find it far more likely that the developer just has a much better handle on DX9 than OpenGL(which is basically what the PS3 graphics API is).
Very well could be, I hadn't thought of the API issue at all.
That is actually an interesting observation. Personally, I'd prefer to see fewer ports, or maybe ports that are just far more differentiated. If I have to buy more than one console in order to play everything I want to play, so be it.
I'm not sure how I feel about it. I don't really want to buy multiple consoles, but I also don't really like crappy ports. If I only have one console, I also don't care how differentiated they are.
Yeah, but I'll admit to being dissapointed when I read that. I'm glad the game is fun, and I look forward to playing it, but the screenshots for the game looked pretty sweet and I was also looking forward to great Zelda graphics. If Gabe is touting the game and saying how good it is while simultaneously admitting that it doesn't look very good for a GC game, that does kind of worry me. Maybe I won't think about the graphics, but maybe I want to think about the graphics from time to time, specifically "these graphics rock!"
The power glove flopped because it was an expensive add-on and there were basically no games designed for it, so it was a glove that had to somehow act like a Nintendo controller. I never had one (see price), but from what I heard it was fun to play Punch-Out with and that was about it. The NES was really not a great system to try innovative motion-sensing control schemes on, considering how few NES games even used all 8 binary game pad directions. Funny, because even a decade later I was reading about hobbiests praising the power glove for actually being a pretty good glove that could do things like detect how far you had curled each finger that other similarly priced gloves couldn't do. So basically total overkill.
The Wiimote is built into the console and is the foundation of Wii gameplay, is cheaper if you want extras, and is matched to a system capable of doing something useful with the nuanced input it is getting. I completely agree that it's appropriate to wait and see how it feels after using it a while before passing judgement good or bad. I just disagree that history gives me reason to doubt.
P.S. speaking of failed Nintendo add-on controllers, I don't hear many people mention whatever the hell they called that ridiculous light-bazooka for the SNES. Seriously, it was the size of a small shoulder-fired rocket launcher and was intended to be held the same way. I don't know what the hell that was about. A relative accidentally bought me a game that needed it, so I never played it, making it only a slightly better gift than Donkey Kong 3 was.
The new format war is going to stifle acceptance and sales of both types of HD media as the public is not going to be able to figure out what the hell they need to buy.
I completely agree. The only way it will work is if Joe Blow can walk into Best Buy and ask "What do I need to buy?" and the clerk can say "Buy one of these players, they play everything" and then he never has to care about formats again -- until of course the Powers That Be decide we need to re-purchase our movie libraries once again.
Nobody doubts that the PS3 has potential. If you just look at raw numbers (like everyone did with the Emotion Engine, but still) the Cell is freaking awesome. I went to a talk by IBM about the Cell where they discussed some architectural tidbits about the SPEs and the internal interconnect ring (IBM loves rings*) which is also just nuts. When fully banging away, you could get a ridiculous amount of data throughput.
The problem is you have to give those SPEs something to do. But it's a new programming model with some strange quirks compared to processors most programmers are used to, and I don't think the tools are up to snuff yet either so it's all manual coding to get it to work.
I wouldn't be surprised if a lot of early games, especially the hasty ports from xbox, don't even use the SPEs and just use the Power core. In which case the PS3 isn't as powerful as the xbox.
So there's lots of potential, no doubt about it, the question is just if we'll see it taken advantage of in most games and how long it will take for that to happen. As always the longer a console is out the better people get at programming for it. It just seems like with the Cell architecture that it is going to take longer for people to wrap their heads around the PS3, even if the payoff is huge.
It's interesting that in this generation there seems to be higher barriers to porting than before. The PS3 with it's odd architecture and the Wii with it's odd control scheme may mean we see fewer ports... or maybe just shittier ones. Maybe that's what Tony Hawk is a herald of.
* Maybe it's just me, but between their obvious love of rings (ring interconnect bus on Cell, using token ring networks as late as 98) and their legal team known as the Nazgul, IBM kinda scares me.
If your program relies upon a shared library, and that library breaks ABI compatibility, though, you're still screwed. Sure, there are work-arounds if you control your program's sources - you could statically link things in, or do some LD_PRELOAD hack to load the right version of the right shared libraries. But this assumes that you have a lot under your control. You might not have this luxury if you're using a 3rd-party proprietary library or program.
/dev/fd0 is the floppy drive?
I come at this from the standpoint of a debian user, where the update of the library would also bring an update of dependent software, so ABI compatability isn't as important because everything gets updated to the new ABI. Yeah, it's true that a 3rd party proprietary program can't do this, which is why I'm suggesting that to get the most out of Linux businesses may want to move away from such programs or start negotiating for source access. I readily admit this may not be feasible.
But then there's also API breakage, which is a major part of "backwards compatibility" that must be taken into account. If the kernel syscall numbers (or the arguments thereto) change, there's major breakage. inotify vs. dnotify vs. fam? udev vs. static dev? Does your program assume that
Yeah, I realize that APIs are actually less stable than I implied. Free software still has the nice property of being a more dynamic system that can be updated to track API changes, but it isn't as easy as just recompiling in all cases by any means.
They go to great lengths to keep old applications running with new Windows versions, and not just old versions of actual Windows OS.
Of course that's what I was talking about. If it was 'just old versions' that would be, I don't know what you'd call it, "not-changing-anything compatability", which most systems are pretty good at.
No matter how violent and predatory we may imagine ourselves to be, we are amateurs compared to what nature has produced.
You have very good points, but I wouldn't call us amateurs. I'd say we are one of nature's better attempts.
As far as cruel, nasty death: Before the invention of crafted tools, humans hunted by using our more efficient jogging gait to run down animals, pursuing them relentlessly until they collapsed from heat exhaustion, at which point we'd walk up and kill them with our bare hands, or a rock or stick. Remember what you felt like when you ran the farthest you could, the burning lungs and muscles. Then imagine running more because something was trying to eat you, until a long time later you are physically incapable of moving even under threat of death because your body has overheated. Then you get bludgeoned to death by a hairless monkey.
I think we have doled out our fair share of pain through the food chain.
Heh, it's funny though, this post reminds me of when I was much younger and would often watch nature shows with my dad, which of course would feature things like a jaguar tackling a gazelle. He would always tell me that it was okay, because first it was nature, and second the gazelle would kinda pass out as soon as the jaguar got him so he didn't feel any pain. Now of course I know that isn't true but it did probably keep me from crying a lot so I could learn from the shows. Thanks for sheltering me, dad.
$600 plus frostbite to do what my computer can already do.
Shit, you need that too? I'm in central Texas, where am I going to get frostbite?!
Because I know they need it. Without compatability with old Windows software, the next buying cycle every CTO on earth would have a chance to consider whatever operating system they wanted since all would involve switching to entirely new software, as opposed to now where buying Windows to replace Older Windows is the automatic choice. It isn't just Window's market share that maintains there monopoly, it's the resulting market share of software for Windows that really does it. Drop that, and Windows' real advantage is gone.
I do make fun of them for not being able to stabilize and secure some of the old code, though I understand it's tough when the code is old, complicated, and crufty, and a lot of old programs require "bug for bug" compatability.
I think the solution for them is deprecation. Old interfaces that are stuffed with crufty code, and which were often insecure by design anyway, should simply be made unavailable for new applications. You have an old app that wants to use it, fine. You want to code a new app using OLE or ActiveX or what have you? Tough. Eventually software gets replaced, and eventually you wouldn't have any software using the old systems and you could disable them. Sadly there's still plenty of new development using ActiveX and other crap, so MS both shows no interest in doing this nor may they be able to.
Now how does this apply to Linux? In Free Software Happy Land, you have the source to all the software on your system, so with the ability to recompile you don't need binary backward compatability. Being able to link your source code against new libraries can fix a lot of the problems with having to support really old binaries. There's still the issue of interface compatability (which is tied up in binary compatability in the Windows world), but a lot of the interfaces are stable.
This isn't Free Software Happy Land, though, we're talking about businesses. Personally I think that adopting Linux should also come with adopting some of its philosophies, in particular that having source code is much much better than not having it, so if you aren't getting source then it had better be much much better than the program you can get with source. Linux does not have a strong history of binary compatability, and I'm not sure it's best for Linux to start establishing such a history. Business may not like it, but maybe they need to adapt to Linux not the other way around. Who knows, they might figure out that they like getting source code from their vendors and accidentally discover a better way to do things.
And thus the energy per kg are 5 times higher for the same thrust.
I meant energy per unit thrust, you need 1/5th the mass but energy is quadratic with velocity.
So we're going to rely on bigger and bigger pizza pies to protect our bigger and bigger space investments? My god, man, you're talking about a pizza larger than we're capable of baking. And think of the tomatoes necessary for such an operation!
:)
Yes! Space-based pizza infrastructure doesn't have the inherent weight problem that a ground-based one does, so we could theoretically build truly gigantic pizza ovens, powered with nuclear weapons. Let's ressurect Cold War tech for the Cold Pizza War!
I forsee a Pepperoni gap between us and the Russkies.
I'm afraid it's the Italians we'll have to be worried about. I hear they're already planning a space-based pizza-pie so large that with it's crust side facing earth it would appear as large and bright as the moon from the ground. It's codenamed Amore, and I hear they already have a nationalistic song about it.
We could go on for days
In the rough sketches I have seen, the Isp would be about 5 times higher.
And thus the energy per kg are 5 times higher for the same thrust. Which given some rough calculations based on a single Shuttle SRB (500,000 kg of fuel over 120 second burn, impulse 2500 m/s) is about 25 terrawatts of delivered power to match the one booster. There's a reason high thrust and high Isp aren't often seen together.
How about the machine counts the paper ballot you filled out and drops it in a bin?
Yeah, and in theory, it could also tell you if it couldn't read the ballot because it was badly formed. Okay, machines can already do that, though in some notable cases in Florida this capability was disabled (but people just assumed it was because those voters were idiots).
I do think an electronic ballot machine has some advantages. I like the part of e-voting where I can easily browse candidates, click buttons that show the full text of any propositions or measures being voted on, easily change a vote if I decide to change my vote, and so on. I like the idea of eliminating penciling errors by having the computer print it. I like the accessibility options e-voting can give.
In my ideal e-voting world, you'd have one machine that prints ballots on card stock in a human-and-machine readable format (with the same markings, not human-readable-text and a barcode). You'd take the ballot it prints out and put it in a different machine that could count the vote. In fact, because the format of the ballot would be a matter of public record, anyone could make a ballot counting machine and after passing some basic certification (that it doesn't mangle ballots for example) could bring it to the election to verify that their machine got the same count as everyone else's machine.
Of course something simple like you describe works. As long as there is the paper record which is considered authoritative, and the machine count only an initial estimate, then that's a voting system I support.
Yeah, good point, all the people asking for source shows that if they get source they'll think they're okay. Ugh. Let's kill this stupid idea.
If you eat the pizza you destroy your shield!
The pizza shield would be extra thick, for extra safety and to ensure a reasonable amount could be eaten without endangering the passengers.
And just where do you think you're going to get pizza for the return journey.
Once we have the space elevator, lifting an automated pizzaria into space would be relatively cheap.
Okay, I may be wrong.
But you would have substantial velocity. You'd have the same velocity as the ribbon itself, the same angular velocity as the earth times 500km. All for zero fuel, and thus no weight penalty that you have to account for in the amount of fuel needed for further acceleration.
The Wicked Lasers are more powerful than your typical green laser, but most green lasers are bright enough that you can see the beam, but can't do the tricks you see in those (totally sweet) videos. They're great for pointing at stellar objects when out stargazing. Just watch out for airplanes, not just for safety and common sense, but because Homeland Security will come after your sorry ass.
Go up another measly 500 kilometers, and your new acceleration is approximately (6.67e-11 * 5.97e24) / (6.87e6^2) = 8.44 m/s^2. That's only a 14% difference; a very noticeable reduction, but not enough to have significant savings. Your rocket fuel wouldn't go much farther at all, at least when the goal of the space elevator is to reduce cargo costs by orders of magnitude.
Yeah, but you also didn't have to carry the fuel to go those first 500 kilometers, so your craft is much lighter.
For all the engineers here: why would you want to build a cable tens of thousands of miles long out of currently UNAVAILABLE materials (unobtanium) to slowly ratchet up one payload at a time?today, because we can't, but one day maybe we can. On that day, building a space elevator will be a great idea.
It's a horrid idea, and it STILL takes just as much actual energy to put anything in orbit...just it does so pathetically slowly.
This is incorrect. It takes much more energy to lift something with a rocket because the rocket also has to lift its fuel, which requires more fuel and thus more weight and thus more fuel... In fact, much more energy is spent lifting the fuel that provides energy than is spent lifting the actual cargo. Look at the relative size of the Shuttle's SRBs and external fuel tank compared to the cargo bay. This is why launch costs are so high.
Pulses of light vaporize the fuel in a sequence such that the shock wave of superheated vaporized gas is planar : basically a rocket engine without needing
This has the same fundamental problem as all reaction engines: If you push your craft by throwing particles out the ass-end, you have to carry the particles you're going to be throwing which means a heavier craft which means more particles are needed, resulting in the same exponentially increasing weight problems as existing chemical rockets.
Your idea is no better than the space shuttle in terms of lift capacity, except we have to provide the same amount of Power as all the shuttle's rockets with lasers. The advantage here of the space elevator, aside from not having to pay the reaction mass penalty, is that the lasers can be much lower wattage.
x86 is a horrible mismash of backwards compatibility
:)
My only disagreement with this statement is that you didn't use enough superlatives and explitives.
the day we have to wipe the slate and start over will be the day x86 stability improves 10fold.
Are you talking about software stability? I highly doubt ISA backward compatability is a significant source of instability. Old software may be unstable, but it would be unstable on old hardware or new. Windows backward compatability causes instability because it prevents them from re-writing or getting rid of insecure and unstable interfaces, but the ISA isn't the problem.
Besides, one nice thing is that when a new operating mode is introduced it provides an opportunity to drop old features, except in compatability modes. E.g., x86-64 (mostly) doesn't have segmentation, it doesn't have undefined flag values, it doesn't have some of the stranger and more useless instructions. Sure if you switch to 32-bit or 16-bit mode it does, but new software isn't encumbered with the cruft. And hardware designers are free to make the old cruft slow so as to discourage it's continued usage.
If you know the source code of the software (including build options etc), and the compiler/linker versions that have been used to build it, it will be possible to prove whether or not the binary code on the machine was generated from the source code in front of you.
No, you cannot prove it, because you cannot know that the software/hardware isn't lying to you. It's like a rootkit, designed to fool you into thinking everything is normal while simultaneously subverting the machine. It's only even conceivable to do this with some kind of Trusted Computing platform, but there's the rub -- when it is you the user who does not trust the manufacturer, how do you know that the Trusted Computing encryption chip isn't similarly designed to lie to you?
OSS is nice, but it does not solve the fundamental problem. Until we solve that fundamental problem, lobbying for open source is counter-productive. It will be a more difficult fight, and it won't fix anything. The real fight is for paper ballots. Once we know the machine is working right because it prints our ballots correctly, then we can worry about the source code if there is still a reason to.
The last time I looked, I seem to remember some folks working on decompilers that would produce higher-level languages (mostly C, that I recall), but have no idea if anybody ever got 'em working well.
It's been about five years since I touched one, but they work well enough. They do a fine job of identifying basic blocks, variables, and functions, and produce code that can be fed back into a compiler. The big problem is that it's still largely unreadable because it doesn't have any of the conceptual meaning conveyed by the original code -- i.e. descriptive function/variable names.