There may be other constellations of physical laws which could generate a universe complex enough to support life, but there are far, far more that couldn't, no matter how good your imagination is.
Since my imagination can think of an infinite number of variations on any set of physical laws, how do you quantify "more"?
The correct answer to "What if you people are all a dream of mine?" is to smack the questioner in the side of the head. What's he going to do, get mad at one of his dreams?
Is Windows XP still vulnerable to bugs that you originally found in Windows 95? I'd think they'd have fixed things like that by accident by now, just in the normal course of rewriting code.
Actually such features are possible in Duke Nukem 3D.
On which level?
But anyway, you're wrong. Duke 3D levels have to be designed so that at no place in the game can a character view solid ground with open space both above and below it. If you still have the game (and the Build editor, which IIRC shipped on the same disk) you can test this for yourself: on the first level in the movie theater there is a solid wall that goes from the projection booth all the way to the ground. There is a hallway underneath the projection booth, but because the wall is there it is impossible to see both a point inside the projection booth and a point directly underneath it in the hallway at the same time. If you remove the wall, then you would expect to be able to see something like that, but instead you'll see strange graphics glitches.
If, to use my original example, you were to try and model a house with a roof you can walk on and windows, you would have to construct the roof entirely out of sprites (the way the ventilation duct across a chasm is made in one of the moon levels in Duke3D). I don't know if you can even do that trick with an angled roof, and you definitely can't do it unless the building shape can be constructed from rectangles.
You can't have X billion polygons in one map in Quake 3 whereas you could in "real 3D".
If you don't think that this is a pedantic complaint, but the inability to model a solid object with space above and below it is not, I don't see how I could convince you otherwise. Hell, why don't we call Zelda 1 a "3-D" game then? It's just 3-D that happens to be viewed from the top down from an unchangeable camera angle.
Oh, come on, that "2.5D" argument is really, really getting boring. Sure, the engine uses a 2D model for representing the levels internally, but since when does that make the game "2.5D"?
Since as soon as you try to make a level with general 3-D features (say, a building that has both windows you can enter and a roof you can walk on top of) you find that the engine makes it impossible. The levels look highly 3D, but that's mostly because their designers did an excellent job of hiding the engine's limitations. If you picked a random level from most real 3-D FPS games, odds are there would be some part of the level which you would be unable to recreate with the Build engine. And by "some part" I mean an area significant to game play on that level; there would also be countless decorative features that can use 3-D models in a real 3-D engine but have to be approximated with sprites in Build.
Don't get me wrong; Duke Nukem was a great game, and it had lots of wonderful features like "cooperative multiplayer" and "interesting maps which make sense as places and not just as videogame levels" that other FPS games never quite picked up on. But the engine wasn't really 3-D.
Even as far back as 4.1 (when I started using Red Hat) they kept the commercial software on separate CDs, which made the legalities of redistribution as simple as "you can redistribute anything and everything on disks 1 and 2, but little or nothing on disk 3".
What you've described (connect to a few different index servers, break all your files into chunks, start offering to upload chunks as soon as they're downloaded before the rest of the file even finishes) sounds just like the system that mldonkey (and eDonkey, and probably a bunch of other compatible clients) uses. Are there any significant advantages to your protocol?
The only software Red Hat could legally release under a "turns into GPL after a week" license is software solely written by their employees. Are there any Red Hat packages at all that don't even accept large patches from outside contributors?
Ten years ago I was discussing Super Nintendo games on Prodigy, now that I think about it. Okay, okay, I guess I should have said "15 years ago", or "40 years ago my parents couldn't", or something accurate instead. I still stand by my point in the abstract, though.
For example, a "lights on" command requires conscious thought in order to get lights, and some linguistic processing. The alternative light switch technology is less so, even automatic [you might notice this when the power goes out you still hit switches].
That's right: the behavior we have been using to turn lights on since childhood comes more naturally to us than a behavior we have never used to turn lights on. I'll bet people would get used to saying "lights on" automatically after a few weeks of doing it, though. You make it sound like "people associate switches with lights" is a biological rule.
Flicking a light switch is much faster than saying the words.
Is it? What if you're lying in bed reading and want to turn the lights off before you go to sleep? This is a situation I've been in literally thousands of times, and getting up to go across the room when you're half asleep is definitely slower than speaking would be. It's not like there aren't low-tech solutions to problems like that, too (My bed sits underneath a light switch right now), but just because you don't see a use for a new technology doesn't mean there isn't one. Ten years ago I couldn't participate in a discussion like this with people across the country. I would never have conceived of that fact as being a "problem", but it's still nice to have a "solution" to it anyway.
And I think I got the version I'm using from the apt repository maintained by freshrpms.net. If you're using Red Hat 8, you might be able to get it installed with just:
What mechanism is more responsible than click-thru software EULAs for training computer users to believe that they should expect to regularly see large blocks of text emphatically declaring dire warnings and that they should just click "OK" without reading when those blocks of text pop up?
Of course, it could melt on reentry, but the consequences of a ton of molten steel hitting you at supersonic speed are even worse than if it stayed solid.
The steel would melt very high up in the atmosphere, and as it descended could break up into droplets that would slow and cool too quickly to do much damage. IIRC the Earth gets hit by 1 ton meteors pretty regularly, which don't make it to the ground with anything intact.
You really want some sort of heat shielding, to keep the steel from melting (or vaporizing!) until it hits the target. There's a study called "Air Force 2025" that's relevant; the main site seems to be down right now, but if you do a search for that term and "hydrodynamic penetrator" you can still hit the Google cache.
Is receives your public key, and sends his public key to the SSL server in it's place. He also receives the SSL server's public key, and sends his public key to you in it's place. He then decrypts every message you send to the server (which you will have encrypted using his public key, thinking it was the server's public key), reads it, and reencrypts the plaintext using the server's real public key before sending it on to the server.
Granted, this sort of attack can't be very easy unless he has total control of a router in between you and the server, but unless there's some out of channel way of verifying the private keys (web of trust or certifying authorities, for example) then this is at least theoretically possible.
You might want to take a look at "rotovator" systems, which rely on reaction mass from the ground (or on momentum transfers from rocks in space being lowered to Earth) to keep them in orbit, but which therefore don't need to be tethered to the ground and so don't need to be in a geosynchronous orbit. You spin the entire rotovator in such a way that its tips come to a brief stop in the atmosphere for payloads to be attached, and counterintuitively this allows the rotovator to be much shorter, lighter, and less stressed than a geosynchronous elevator would be. Geosynchronous beanstalks on Earth pretty much require supermaterials like buckytubes; you might be able to pull off a rotovator with Kevlar.
A bit of correction, though:
Your design is slightly different in that you have the CM sitting outside geosynchronous orbit in the realm where it experiences the outward centrifugal force all the time.
Right. This also keeps the system more dynamically stable and allows you to have a base station that isn't exactly on the equator.
So you've got the other end attached to the ground, pulling up on it.
Pulling down on it really, but I think you get what I mean. "Up" and "down" start getting a little fuzzy in this discussion.
This is conceptually a little bit simpler to grasp, but it puts increased tension in the cable,
No, it doesn't. The "increased tension" is only there when a payload isn't. Once you load your payload onto the cable, the payload weight provides the force that had previously come from tension between cable and ground. Since payload weight is a force that even a detached cable like your proposal would need to support, having the same force constantly applied through tension doesn't add anything to the structural requirements of the cable.
and after lifting a certain amount of stuff into orbit, the CM of the system will reach geosynchronous orbit anyway-
No, it won't. The CM of the system will always be above geosynchronous orbit; that's how you keep the system from falling back to Earth. The CM starts out above GEO, moves closer to GEO as you add payload, then moves farther away from GEO again as the payload rises.
and all the tension at the ground will be gone.
If all the tension at the ground is gone, the cable starts to crumple. You don't let that happen.
This is why most designs count on the bottom of the elevator touching the ground, so that a significant portion of the elevator's weight can be supported by contact with the earth instead of tension in the elevator.
First of all, the tendency to buckle makes it vastly more difficult to build a long structure under compression than one under tension. Building a structure to support the elevator from below would be just like building any other skyscraper; you wouldn't get the top of the section under compression to be more than a mile off the ground, and after that you'd still have 25,000 miles to go.
But perhaps just as importantly, the bottom of a geosynchronous elevator design needs to touch the ground because it needs the base to be pulling down on it, not lifting up. If you want to take a 20 ton payload up the elevator without pulling it down, then the elevator is going to need to be under at least 20 tons of tension at the ground when there is no payload on it.
Probably because not all asteroids would fit the profile of an inevitable extinction event. There are probably smaller ones that we can do something about,
Dinosaur-killer sized asteroids only come around every hundred million years or so; the last I had heard we had recently acquired good orbital data (good in both the "accurate" and "not going to hit the Earth any time soon" senses) for over 90% of the asteroids with orbits crossing ours and diameters over 1 kilometer.
The problem is that asteroid populations are disproportionately distributed among smaller sized rocks; asteroids large enough to flatten a small city or cause a small tidal wave may come along every few centuries. It would be nice to start looking for those too.
given a fair enough lead time.
The lead time is the important thing, isn't it? Even if there is a supermassive asteroid that is going to smash into Earth, if we found it with a few centuries lead time before impact then there are lots of options for protecting ourselves.
At the time of voting, the machine generates 2 unique random numbers (Public and Private) for each voter. The voter receives a printout with both random numbers and his votes on it. At the end of voting, a list is published containing (for each voter) the first random number and the votes. Individual voters can find their public number and verify their votes (as well as use a spreadsheet to tally election results themselves if they are so inclined.)
This also means that anyone else can request a voter's public number and ensure that the voter cast his ballot the way he was blackmailed to do. Perhaps it's worth giving up secret ballots to prevent vote tampering, but there ought to be a better way.
The number of people voting at each polling place is also published.
It would be nice to have some way of verifying this, too; your random number scheme prevents tampered machines from deleting or altering votes, but not from adding votes.
IRV is great for letting you cast "protest" votes for unpopular parties, but once a third party becomes popular you end up with the same strategic voting problems that plurality voting has. Don't get me wrong, sticking with plurality is insane, but IRV would be a placebo; we need approval or Condorcet voting instead.
Slashdot Mirror
There may be other constellations of physical laws which could generate a universe complex enough to support life, but there are far, far more that couldn't, no matter how good your imagination is.
Since my imagination can think of an infinite number of variations on any set of physical laws, how do you quantify "more"?
The correct answer to "What if you people are all a dream of mine?" is to smack the questioner in the side of the head. What's he going to do, get mad at one of his dreams?
Is Windows XP still vulnerable to bugs that you originally found in Windows 95? I'd think they'd have fixed things like that by accident by now, just in the normal course of rewriting code.
Actually such features are possible in Duke Nukem 3D.
On which level?
But anyway, you're wrong. Duke 3D levels have to be designed so that at no place in the game can a character view solid ground with open space both above and below it. If you still have the game (and the Build editor, which IIRC shipped on the same disk) you can test this for yourself: on the first level in the movie theater there is a solid wall that goes from the projection booth all the way to the ground. There is a hallway underneath the projection booth, but because the wall is there it is impossible to see both a point inside the projection booth and a point directly underneath it in the hallway at the same time. If you remove the wall, then you would expect to be able to see something like that, but instead you'll see strange graphics glitches.
If, to use my original example, you were to try and model a house with a roof you can walk on and windows, you would have to construct the roof entirely out of sprites (the way the ventilation duct across a chasm is made in one of the moon levels in Duke3D). I don't know if you can even do that trick with an angled roof, and you definitely can't do it unless the building shape can be constructed from rectangles.
You can't have X billion polygons in one map in Quake 3 whereas you could in "real 3D".
If you don't think that this is a pedantic complaint, but the inability to model a solid object with space above and below it is not, I don't see how I could convince you otherwise. Hell, why don't we call Zelda 1 a "3-D" game then? It's just 3-D that happens to be viewed from the top down from an unchangeable camera angle.
Oh, come on, that "2.5D" argument is really, really getting boring. Sure, the engine uses a 2D model for representing the levels internally, but since when does that make the game "2.5D"?
Since as soon as you try to make a level with general 3-D features (say, a building that has both windows you can enter and a roof you can walk on top of) you find that the engine makes it impossible. The levels look highly 3D, but that's mostly because their designers did an excellent job of hiding the engine's limitations. If you picked a random level from most real 3-D FPS games, odds are there would be some part of the level which you would be unable to recreate with the Build engine. And by "some part" I mean an area significant to game play on that level; there would also be countless decorative features that can use 3-D models in a real 3-D engine but have to be approximated with sprites in Build.
Don't get me wrong; Duke Nukem was a great game, and it had lots of wonderful features like "cooperative multiplayer" and "interesting maps which make sense as places and not just as videogame levels" that other FPS games never quite picked up on. But the engine wasn't really 3-D.
Even as far back as 4.1 (when I started using Red Hat) they kept the commercial software on separate CDs, which made the legalities of redistribution as simple as "you can redistribute anything and everything on disks 1 and 2, but little or nothing on disk 3".
What you've described (connect to a few different index servers, break all your files into chunks, start offering to upload chunks as soon as they're downloaded before the rest of the file even finishes) sounds just like the system that mldonkey (and eDonkey, and probably a bunch of other compatible clients) uses. Are there any significant advantages to your protocol?
The only software Red Hat could legally release under a "turns into GPL after a week" license is software solely written by their employees. Are there any Red Hat packages at all that don't even accept large patches from outside contributors?
Ten years ago I was discussing Super Nintendo games on Prodigy, now that I think about it. Okay, okay, I guess I should have said "15 years ago", or "40 years ago my parents couldn't", or something accurate instead. I still stand by my point in the abstract, though.
For example, a "lights on" command requires conscious thought in order to get lights, and some linguistic processing. The alternative light switch technology is less so, even automatic [you might notice this when the power goes out you still hit switches].
That's right: the behavior we have been using to turn lights on since childhood comes more naturally to us than a behavior we have never used to turn lights on. I'll bet people would get used to saying "lights on" automatically after a few weeks of doing it, though. You make it sound like "people associate switches with lights" is a biological rule.
Flicking a light switch is much faster than saying the words.
Is it? What if you're lying in bed reading and want to turn the lights off before you go to sleep? This is a situation I've been in literally thousands of times, and getting up to go across the room when you're half asleep is definitely slower than speaking would be. It's not like there aren't low-tech solutions to problems like that, too (My bed sits underneath a light switch right now), but just because you don't see a use for a new technology doesn't mean there isn't one. Ten years ago I couldn't participate in a discussion like this with people across the country. I would never have conceived of that fact as being a "problem", but it's still nice to have a "solution" to it anyway.
If you reply to him then The Terrorists has already won.
And I think I got the version I'm using from the apt repository maintained by freshrpms.net. If you're using Red Hat 8, you might be able to get it installed with just:
/ apt/apt-0.5.5cnc4.1-fr1.i386.rpm
rpm -Uvh http://ftp.freshrpms.net/pub/freshrpms/redhat/8.0
apt-get update
apt-get install xine
(note that Slashdot will probably insert an space somewhere in that URL...)
I thought using the "new" operator in C++ on built-in data types gives you zero'ed memory, like calloc() instead of malloc() in C.
Those DV Bridges cost roughly $300; you can get an analog TV tuner for $50.
I just wanted to congratulate you for getting the phrase "glowing cyber-balls" on the front page of Slashdot!
When I was looking for computer->analog control chips a few years ago, the best methods I could find were:
Build (or buy) a serial->I2C or parallel->I2C converter; you can get D/A chips with I2C interfaces pretty cheaply.
Use a PIC microcontroller, which gives you serial and analog I/O built in.
What mechanism is more responsible than click-thru software EULAs for training computer users to believe that they should expect to regularly see large blocks of text emphatically declaring dire warnings and that they should just click "OK" without reading when those blocks of text pop up?
Think of it, http://boobies.slashdot.org/
Admit it people, how many of you read this post and then went to that URL, just in case?
Of course, it could melt on reentry, but the consequences of a ton of molten steel hitting you at supersonic speed are even worse than if it stayed solid.
The steel would melt very high up in the atmosphere, and as it descended could break up into droplets that would slow and cool too quickly to do much damage. IIRC the Earth gets hit by 1 ton meteors pretty regularly, which don't make it to the ground with anything intact.
You really want some sort of heat shielding, to keep the steel from melting (or vaporizing!) until it hits the target. There's a study called "Air Force 2025" that's relevant; the main site seems to be down right now, but if you do a search for that term and "hydrodynamic penetrator" you can still hit the Google cache.
Is receives your public key, and sends his public key to the SSL server in it's place. He also receives the SSL server's public key, and sends his public key to you in it's place. He then decrypts every message you send to the server (which you will have encrypted using his public key, thinking it was the server's public key), reads it, and reencrypts the plaintext using the server's real public key before sending it on to the server.
Granted, this sort of attack can't be very easy unless he has total control of a router in between you and the server, but unless there's some out of channel way of verifying the private keys (web of trust or certifying authorities, for example) then this is at least theoretically possible.
You might want to take a look at "rotovator" systems, which rely on reaction mass from the ground (or on momentum transfers from rocks in space being lowered to Earth) to keep them in orbit, but which therefore don't need to be tethered to the ground and so don't need to be in a geosynchronous orbit. You spin the entire rotovator in such a way that its tips come to a brief stop in the atmosphere for payloads to be attached, and counterintuitively this allows the rotovator to be much shorter, lighter, and less stressed than a geosynchronous elevator would be. Geosynchronous beanstalks on Earth pretty much require supermaterials like buckytubes; you might be able to pull off a rotovator with Kevlar.
A bit of correction, though:
Your design is slightly different in that you have the CM sitting outside geosynchronous orbit in the realm where it experiences the outward centrifugal force all the time.
Right. This also keeps the system more dynamically stable and allows you to have a base station that isn't exactly on the equator.
So you've got the other end attached to the ground, pulling up on it.
Pulling down on it really, but I think you get what I mean. "Up" and "down" start getting a little fuzzy in this discussion.
This is conceptually a little bit simpler to grasp, but it puts increased tension in the cable,
No, it doesn't. The "increased tension" is only there when a payload isn't. Once you load your payload onto the cable, the payload weight provides the force that had previously come from tension between cable and ground. Since payload weight is a force that even a detached cable like your proposal would need to support, having the same force constantly applied through tension doesn't add anything to the structural requirements of the cable.
and after lifting a certain amount of stuff into orbit, the CM of the system will reach geosynchronous orbit anyway-
No, it won't. The CM of the system will always be above geosynchronous orbit; that's how you keep the system from falling back to Earth. The CM starts out above GEO, moves closer to GEO as you add payload, then moves farther away from GEO again as the payload rises.
and all the tension at the ground will be gone.
If all the tension at the ground is gone, the cable starts to crumple. You don't let that happen.
This is why most designs count on the bottom of the elevator touching the ground, so that a significant portion of the elevator's weight can be supported by contact with the earth instead of tension in the elevator.
First of all, the tendency to buckle makes it vastly more difficult to build a long structure under compression than one under tension. Building a structure to support the elevator from below would be just like building any other skyscraper; you wouldn't get the top of the section under compression to be more than a mile off the ground, and after that you'd still have 25,000 miles to go.
But perhaps just as importantly, the bottom of a geosynchronous elevator design needs to touch the ground because it needs the base to be pulling down on it, not lifting up. If you want to take a 20 ton payload up the elevator without pulling it down, then the elevator is going to need to be under at least 20 tons of tension at the ground when there is no payload on it.
Probably because not all asteroids would fit the profile of an inevitable extinction event. There are probably smaller ones that we can do something about,
Dinosaur-killer sized asteroids only come around every hundred million years or so; the last I had heard we had recently acquired good orbital data (good in both the "accurate" and "not going to hit the Earth any time soon" senses) for over 90% of the asteroids with orbits crossing ours and diameters over 1 kilometer.
The problem is that asteroid populations are disproportionately distributed among smaller sized rocks; asteroids large enough to flatten a small city or cause a small tidal wave may come along every few centuries. It would be nice to start looking for those too.
given a fair enough lead time.
The lead time is the important thing, isn't it? Even if there is a supermassive asteroid that is going to smash into Earth, if we found it with a few centuries lead time before impact then there are lots of options for protecting ourselves.
So the person attempting to blackmail him just asks to see the receipt.
At the time of voting, the machine generates 2 unique random numbers (Public and Private) for each voter. The voter receives a printout with both random numbers and his votes on it. At the end of voting, a list is published containing (for each voter) the first random number and the votes. Individual voters can find their public number and verify their votes (as well as use a spreadsheet to tally election results themselves if they are so inclined.)
This also means that anyone else can request a voter's public number and ensure that the voter cast his ballot the way he was blackmailed to do. Perhaps it's worth giving up secret ballots to prevent vote tampering, but there ought to be a better way.
The number of people voting at each polling place is also published.
It would be nice to have some way of verifying this, too; your random number scheme prevents tampered machines from deleting or altering votes, but not from adding votes.
Instant Runoff Voting Problems
IRV is great for letting you cast "protest" votes for unpopular parties, but once a third party becomes popular you end up with the same strategic voting problems that plurality voting has. Don't get me wrong, sticking with plurality is insane, but IRV would be a placebo; we need approval or Condorcet voting instead.