It looks to me like this game, an XBox, and the controller would be the best $300 mech simulator ever. That, plus Rallycross, might just push me into getting one.
concentrate on imagining a one square mile machine. This is not a farm, you don't throw seeds in the ground and walk away. This is a massive facility that needs to be built, serviced, and resupplied.
You mean, like an oil refinery, or a one mile section of any industrial area in any city in the world? OK, I'm imagining it. We've got thousands and thousands of them worldwide. Building and running an industrial complex is something that modern civilization understands and has lots of experience in.
As for your other arguments, I agree that scrubbing is not the best general solution, and might not be a net win at all. BUT the size and complexity of the scrubbing system is well within our capabilites.
60,000 acres is the size of a moderate wheat ranch in Montana. It's a tiny fraction of the size of the US, and it doesn't have to be centralized. We're talking about facilities comparable in size and complexity to sewage treatment plants, on a per-capita basis. If we can build power plants and the infrastructure to support them, we can certainly build these.
As for the industrial side of getting all that quicklime, that's not a huge endeavor compared to any other kind of mining. We pull so much copper and bauxite and titanium and coal out of the earth that extracting a few million tons of quicklime wouldn't change the scale of the world's mining industry perceptibly.
Would it work? Maybe, maybe not. BUT, the argument against it on size and complexity does not appear valid.
I remember that file system. The problem with it was that it was a file system that included a database, rather than a file system implemented on top of a database. If you have a pre-BFS BeBox around, see how many new files with a small amount of metadata you can create in one second. Now try similar inserts into a MSSQL2K setup, using the image datatype to represent a file store. Sure, the modern hardware is a big part of the difference... but that's part of the point. Fast machines make for more capability, even to the point of putting a relational / object database on every desktop.
Nuclear engines are much more dangerous than chemical ones. If a chemical rocket develops problems on ascent ground control push a button and blow it up. What if that rocket has a shitload of uranium or plutonium on board?
But why would we want to blow it up? It's not like it's full of rocket fuel or anything - it just has some radioactive stuff in it. The radioactive stuff is solid, and even if we make a full-acceleration nosedive into basalt (which we won't, because all we have to do to stop the thrust is dump the reaction mass, not to mention parachutes), the worst that's going to happen (assuming decent reactor design, like a pebble bed reactor, if they scale that small) is that you get a few chunks of radioactive material; there isn't enough energy involved to get a pulverizing effect. Men with geiger counters go find it and clean it up.
Nuclear rockets are safer than chemical rockets (provided that the reaction mass used is something basically low-energy, like CO2 or H2O, rather than H2 or H2O2). It's like the difference between a low-pressure solar steam engine and a dragster running on nitromethanol, and you're asking about what to do if the steam engine catches fire because of the flaming exhaust it doesn't have. The risk of boost-phase abort requiring the destruction of the craft in atomic rockets is very, very low.
If you want to have something to attack nuclear rocketry on, look into on what effect the very slightly radioactive exhaust trails will have in the ionosphere. Man-made Van Allen belts? Could be, if there's enough energy. Would there be? What would those do? How radioactive would each particle of reaction mass be? How many of them would there be, and what would happen to them, during the atomic rocket's atmospheric boost phase? What kind of reactor would it have? What are this reactor's modes of failure? Is there a reactor that is, by design, immune to modes of failure we want to be particularly concerned about?
Not all of these questions were addressed by Hickam, either, but that doesn't make the article dishonest.
First, your reaction mass is your reactor shielding. There's a whole lot of water or liquid CO2 between the pile and the crew.
Second, the craft only has to carry reaction mass for one way. You get to Mars, you turn on your compressor (powered by your atomic pile), and pump the local atmosphere into your tanks. This is a huge advantage. CO2 provides a lower specific impulse than, say liquid H2, but it's plenty to get back to Earth, or to push on to Titan.
In short, there are huge advantages to a nuclear rocket over a chemical rocket. Check out NERVA and NIMF, the two best treatments of the subject.
This is the same WSU that invented a cheese canning process during WWII for military purposes. You can still order it from their creamery in assorted flavors. The Cougar Gold in particular is good; it's the only cheddar-type cheese I know of that is aged for a full year.
Apart from your defense of the Oregonian (I don't think it's much of a paper either), you have hit it on the head. It's a strange place, but good. Those who don't like it are free to leave.
My biggest pet peeve about Oregon: I miss the old license plates.
Elite Hoplites in a city should have a significant defense bonus, plus the Elite bonus - and if you had city walls, so much the better. In the real world, 300 elite hoplites (the Spartan 300) held the pass at Thermopylae for days against the whole Persian army under Xerxes, killing more than 10,000 (some say 20,000) of the Persian's best. Seems pretty reasonable that your hoplites could stand against a half dozen warrior bands.
Dateline: 2006 - News Flash From the FUTURE!
on
RIAA to DoS Pirates?
·
· Score: 5, Funny
Here in the world of the future, 94% of all bandwidth is taken up by these three sets: machines falsely claiming to have resources, other machines falsely claiming to want same, and those two sets of machines pretending to transfer data very very slowly.
No, that's not so. There are a great many calls into vb.dll, but those are exactly analagous to calls into the C runtime. It's real object code, linked by pretty much the same linker used throughout Microsoft's toolset
As I posted below, I have written the same code in C++ and VB, and found them to run at the same speed - the performance improvements available in C are due to using techniques that are very difficult in VB (such as pointer arithmetic). What you say was sort-of true for earlier versions, but hey, it's not 1996 anymore.
I sympathize with you; Access VBA is horrible. Using Access for anything is horrible... but Access is not the same thing as VB. There is no redeeming feature to Microsoft Access, now that MSDE (Microsoft's free (beer) SQL database engine) is available.
I write top notch code in VB, and reach for C++ when I can't make the VB version work fast enough. In the last three years, that's happened once - I needed a fast way to concatenate an array of strings, so I wrote a one-function DLL. Part and parcel of this is profiling, and I found that if I used the same algorithm, there were NO improvements gained by writing in C. All benefits came from using pointer arithmetic techniques that were not easily available in VB.
Since I can write fewer lines in VB, compile faster, debug more easily, and so forth, I produce more results in less time. The downside: people who see my stuff don't believe it's written in VB, and when they do find out, go language-bigot apeshit. Summing up: VB is a real compiled language. Access VBA sucks giant ass. Your experience with bad VB code does not make the language bad. Have a nice day.
I was fired once from a job where I had brought my own table into the office. I disassembled it during a screaming match with my manager who thought it was company property. I didn't mind being fired, but no way was I going to leave without my table. He went to get a VP (presumably to stop me) and found that it was, in fact, my table. When he came back he told me that it was OK, I could have the table. No shit, asshole - it was mine all along.
In Oregon, the Department of Labor will give you up to $2000 of wages owed (and take taxes out of it), and then go after the company for you. I was owed rather more than that, but that's all I got -- I may have signed away the rest to the Dept of Labor to cover their recovery costs. It came in very, very handy.
All 12 of us who were owed money went down to the Dept of Labor together, and they gave us lots of perks and priority because we were all together: a conference room to do our paperwork in, our own caseworker, etc. It was terribly efficient; you should try it.
I know a fellow who used to work in MS Research, and he keeps in touch with his old buddies. He has been talking about this project for some time now, and assures me that the intent is not to have a single monolithic system, but rather to have many disparate devices appear as a monolithic system.
Differences of hardware cease to matter to the user. Need more power? Buy another box and plug it into the network; you're done. Hire another employee? Plug a relatively wampy box in; if they need to do anything heavy, their code can snag some cycles from the guy who's at lunch, or the big box o' processors in the basement. No problem.
but at a 256 kbps encoding rate (IMHO the lowest you can go to get decent sound quality without losing bass or getting artifacts) we're only talking about 100 minutes of music . ..
I felt the same way, until someone pointed me to r3mix, where there are many pointers on getting the best possible quality out of lossy compression. Using LAME with the --r3mix flag set, variable bit rate min 112, I can hear no difference from the source media, and I have very good ears. Try it; you'll save a ton of space, and be happier with your sound.
I'm still ripping / encoding, so I don't know for sure. What I've done so far was just the CD closest to my desk, which happened to be Frank Zappa's Make a Jazz Noise Here. This doesn't have anything so terribly exposed, so it didn't sound too bad on my old encoder. After reading some of the r3mix.net site, I decided to use their presets for encoding quality on LAME 3.89. The results are as follows: It sounds a trifling amount better (again, on this CD it wasn't bad to begin with) but VBR lets it come out 30% smaller. If nothing else, I'd want to re-encode everything just to get back some disk space.
I think that when I try this on the music that would not encode acceptably the way I was doing it before, I'll have a more dramatic improvement. Reiterating: upgrading to the latest LAME and using the --r3mix flag gave me slightly-better results with 30% smaller files.
I hereby take back what I said above. I compared the version number on my copy of LAME - I was sadly out of date. I am now re-encoding a bunch of stuff according to the r3mix specs, and will, in all likelyhood, find it to be wonderful now.
Yes, I agree with you. I've never tried it, but both the type of differences "audiophiles" reported hearing, and the supposed mechanism by which this "improvement" occured struck me as being complete bullshit.
What do you mean, a commonly-used bitrate? I can bet a lot of money on that if you give me a CD with any music and let me play it to you together with the same CD encoded at 256 kbps ABR high-quality pass with LAME 3.88, on an SB Live! hooked up to a good amp and a good pair of monitor speakers (play the CD on your favorite CD player hooked up to the same amp), you would not be able to hear the difference between the CD and the mp3. If you state otherwise, you're full of shit. The audio quality difference at this bitrate, with this encoder, cannot be heard by any human ear.
Bring it on. Some pieces I know I can hear a difference even at over 300 kbps include:
Any well-recorded a capella stuff (eg, The Bobs, The Persuasions), especially in the soprano / falsetto range.
Miles Davis "So What". The slight breathiness of tone on his first few entrances does not encode well at any bitrate.
any damned thing with an exposed ride cymbal part.
"Minimalist" contempory compositions. Phillip Glass operas in particular are extremely revealing on playback equipment.
I have all of these on CD, and have encoded them with recent versions of LAME at 320kbps. I listened to the MP3s, then deleted them because I considered the quality unacceptable.
If the quality is acceptable to you, that's cool. My point is that it is not the same thing as CD quality, and any music lover with a good ear can hear the difference.
The amount of data that is lost in MP3 compression is tiny, and is mostly sounds out of range of human hearing.
Hardly. Any musician, or any music fan with a good ear can distinguish between live music, CD-quality music, and MP3 at any commonly-used bitrate. There are significant audible artifacts in MP3-encoded music, particularly in the percussion sounds. Snare drums and cymbals seem to be most affected.
This is not like the subtle difference in sound quality that audiophiles used to claim from painting CD edges green - this is more like the difference between a well-miked drum kit and a pathologically distorted drum kit. Personally, I prefer the Ogg Vorbis sound at most bitrates. I haven't used WMA much.
I would like to see a test done with better controls and better reporting of test conditions.
Unfortunately, I can easily hear the difference between a $1k and a $10k setup. This is depressing when I can't afford more than about a $300 system, so I just don't even try anymore.
Slashdot Mirror
Spreadin' the load around:
Armchair Empire preview
The Controller In Question
It looks to me like this game, an XBox, and the controller would be the best $300 mech simulator ever. That, plus Rallycross, might just push me into getting one.
concentrate on imagining a one square mile machine. This is not a farm, you don't throw seeds in the ground and walk away. This is a massive facility that needs to be built, serviced, and resupplied.
You mean, like an oil refinery, or a one mile section of any industrial area in any city in the world? OK, I'm imagining it. We've got thousands and thousands of them worldwide. Building and running an industrial complex is something that modern civilization understands and has lots of experience in.
As for your other arguments, I agree that scrubbing is not the best general solution, and might not be a net win at all. BUT the size and complexity of the scrubbing system is well within our capabilites.
60,000 acres is the size of a moderate wheat ranch in Montana. It's a tiny fraction of the size of the US, and it doesn't have to be centralized. We're talking about facilities comparable in size and complexity to sewage treatment plants, on a per-capita basis. If we can build power plants and the infrastructure to support them, we can certainly build these.
As for the industrial side of getting all that quicklime, that's not a huge endeavor compared to any other kind of mining. We pull so much copper and bauxite and titanium and coal out of the earth that extracting a few million tons of quicklime wouldn't change the scale of the world's mining industry perceptibly.
Would it work? Maybe, maybe not. BUT, the argument against it on size and complexity does not appear valid.
I remember that file system. The problem with it was that it was a file system that included a database, rather than a file system implemented on top of a database. If you have a pre-BFS BeBox around, see how many new files with a small amount of metadata you can create in one second. Now try similar inserts into a MSSQL2K setup, using the image datatype to represent a file store. Sure, the modern hardware is a big part of the difference... but that's part of the point. Fast machines make for more capability, even to the point of putting a relational / object database on every desktop.
But why would we want to blow it up? It's not like it's full of rocket fuel or anything - it just has some radioactive stuff in it. The radioactive stuff is solid, and even if we make a full-acceleration nosedive into basalt (which we won't, because all we have to do to stop the thrust is dump the reaction mass, not to mention parachutes), the worst that's going to happen (assuming decent reactor design, like a pebble bed reactor, if they scale that small) is that you get a few chunks of radioactive material; there isn't enough energy involved to get a pulverizing effect. Men with geiger counters go find it and clean it up.
Nuclear rockets are safer than chemical rockets (provided that the reaction mass used is something basically low-energy, like CO2 or H2O, rather than H2 or H2O2). It's like the difference between a low-pressure solar steam engine and a dragster running on nitromethanol, and you're asking about what to do if the steam engine catches fire because of the flaming exhaust it doesn't have. The risk of boost-phase abort requiring the destruction of the craft in atomic rockets is very, very low.
If you want to have something to attack nuclear rocketry on, look into on what effect the very slightly radioactive exhaust trails will have in the ionosphere. Man-made Van Allen belts? Could be, if there's enough energy. Would there be? What would those do? How radioactive would each particle of reaction mass be? How many of them would there be, and what would happen to them, during the atomic rocket's atmospheric boost phase? What kind of reactor would it have? What are this reactor's modes of failure? Is there a reactor that is, by design, immune to modes of failure we want to be particularly concerned about?
Not all of these questions were addressed by Hickam, either, but that doesn't make the article dishonest.
You're missing a couple of critical points:
In short, there are huge advantages to a nuclear rocket over a chemical rocket. Check out NERVA and NIMF, the two best treatments of the subject.
This is the same WSU that invented a cheese canning process during WWII for military purposes. You can still order it from their creamery in assorted flavors. The Cougar Gold in particular is good; it's the only cheddar-type cheese I know of that is aged for a full year.
Apart from your defense of the Oregonian (I don't think it's much of a paper either), you have hit it on the head. It's a strange place, but good. Those who don't like it are free to leave.
My biggest pet peeve about Oregon: I miss the old license plates.
Elite Hoplites in a city should have a significant defense bonus, plus the Elite bonus - and if you had city walls, so much the better. In the real world, 300 elite hoplites (the Spartan 300) held the pass at Thermopylae for days against the whole Persian army under Xerxes, killing more than 10,000 (some say 20,000) of the Persian's best. Seems pretty reasonable that your hoplites could stand against a half dozen warrior bands.
Here in the world of the future, 94% of all bandwidth is taken up by these three sets: machines falsely claiming to have resources, other machines falsely claiming to want same, and those two sets of machines pretending to transfer data very very slowly.
No, that's not so. There are a great many calls into vb.dll, but those are exactly analagous to calls into the C runtime. It's real object code, linked by pretty much the same linker used throughout Microsoft's toolset
As I posted below, I have written the same code in C++ and VB, and found them to run at the same speed - the performance improvements available in C are due to using techniques that are very difficult in VB (such as pointer arithmetic). What you say was sort-of true for earlier versions, but hey, it's not 1996 anymore.
I sympathize with you; Access VBA is horrible. Using Access for anything is horrible... but Access is not the same thing as VB. There is no redeeming feature to Microsoft Access, now that MSDE (Microsoft's free (beer) SQL database engine) is available.
I write top notch code in VB, and reach for C++ when I can't make the VB version work fast enough. In the last three years, that's happened once - I needed a fast way to concatenate an array of strings, so I wrote a one-function DLL. Part and parcel of this is profiling, and I found that if I used the same algorithm, there were NO improvements gained by writing in C. All benefits came from using pointer arithmetic techniques that were not easily available in VB.
Since I can write fewer lines in VB, compile faster, debug more easily, and so forth, I produce more results in less time. The downside: people who see my stuff don't believe it's written in VB, and when they do find out, go language-bigot apeshit. Summing up: VB is a real compiled language. Access VBA sucks giant ass. Your experience with bad VB code does not make the language bad. Have a nice day.
I was fired once from a job where I had brought my own table into the office. I disassembled it during a screaming match with my manager who thought it was company property. I didn't mind being fired, but no way was I going to leave without my table. He went to get a VP (presumably to stop me) and found that it was, in fact, my table. When he came back he told me that it was OK, I could have the table. No shit, asshole - it was mine all along.
I still hate those fuckers.
In Oregon, the Department of Labor will give you up to $2000 of wages owed (and take taxes out of it), and then go after the company for you. I was owed rather more than that, but that's all I got -- I may have signed away the rest to the Dept of Labor to cover their recovery costs. It came in very, very handy.
All 12 of us who were owed money went down to the Dept of Labor together, and they gave us lots of perks and priority because we were all together: a conference room to do our paperwork in, our own caseworker, etc. It was terribly efficient; you should try it.
I know a fellow who used to work in MS Research, and he keeps in touch with his old buddies. He has been talking about this project for some time now, and assures me that the intent is not to have a single monolithic system, but rather to have many disparate devices appear as a monolithic system.
Differences of hardware cease to matter to the user. Need more power? Buy another box and plug it into the network; you're done. Hire another employee? Plug a relatively wampy box in; if they need to do anything heavy, their code can snag some cycles from the guy who's at lunch, or the big box o' processors in the basement. No problem.
Thank you Anonymous Coward! Thank You!
... at opening bid, that's 50 pounds of butter for 50 dollars. Have you checked your dairy case prices lately?
I felt the same way, until someone pointed me to r3mix, where there are many pointers on getting the best possible quality out of lossy compression. Using LAME with the --r3mix flag set, variable bit rate min 112, I can hear no difference from the source media, and I have very good ears. Try it; you'll save a ton of space, and be happier with your sound.
I'm still ripping / encoding, so I don't know for sure. What I've done so far was just the CD closest to my desk, which happened to be Frank Zappa's Make a Jazz Noise Here. This doesn't have anything so terribly exposed, so it didn't sound too bad on my old encoder. After reading some of the r3mix.net site, I decided to use their presets for encoding quality on LAME 3.89. The results are as follows: It sounds a trifling amount better (again, on this CD it wasn't bad to begin with) but VBR lets it come out 30% smaller. If nothing else, I'd want to re-encode everything just to get back some disk space.
I think that when I try this on the music that would not encode acceptably the way I was doing it before, I'll have a more dramatic improvement. Reiterating: upgrading to the latest LAME and using the --r3mix flag gave me slightly-better results with 30% smaller files.
I hereby take back what I said above. I compared the version number on my copy of LAME - I was sadly out of date. I am now re-encoding a bunch of stuff according to the r3mix specs, and will, in all likelyhood, find it to be wonderful now.
Yes, I agree with you. I've never tried it, but both the type of differences "audiophiles" reported hearing, and the supposed mechanism by which this "improvement" occured struck me as being complete bullshit.
Bring it on. Some pieces I know I can hear a difference even at over 300 kbps include:
- Any well-recorded a capella stuff (eg, The Bobs, The Persuasions), especially in the soprano / falsetto range.
- Miles Davis "So What". The slight breathiness of tone on his first few entrances does not encode well at any bitrate.
- any damned thing with an exposed ride cymbal part.
- "Minimalist" contempory compositions. Phillip Glass operas in particular are extremely revealing on playback equipment.
I have all of these on CD, and have encoded them with recent versions of LAME at 320kbps. I listened to the MP3s, then deleted them because I considered the quality unacceptable.If the quality is acceptable to you, that's cool. My point is that it is not the same thing as CD quality, and any music lover with a good ear can hear the difference.
Hardly. Any musician, or any music fan with a good ear can distinguish between live music, CD-quality music, and MP3 at any commonly-used bitrate. There are significant audible artifacts in MP3-encoded music, particularly in the percussion sounds. Snare drums and cymbals seem to be most affected.
This is not like the subtle difference in sound quality that audiophiles used to claim from painting CD edges green - this is more like the difference between a well-miked drum kit and a pathologically distorted drum kit. Personally, I prefer the Ogg Vorbis sound at most bitrates. I haven't used WMA much.
I would like to see a test done with better controls and better reporting of test conditions.
Unfortunately, I can easily hear the difference between a $1k and a $10k setup. This is depressing when I can't afford more than about a $300 system, so I just don't even try anymore.
When broadband comes up the Methow valley to Winthrop and Twisp, I'll move up there, telecommute, and never look back.