I beg to differ. Mine's got an R4400 CPU. See the manual at http://www.mips.com/publications/documentation/R44 00_Uman_book_Ed2.pdf, specifically page 39:
"The natural mode of operation for the R4000 processor is as a 64-bit microprocessor; however, 32-bit applications maintain compatibility even when the processor operates as a 64-bit processor."
I've got two 64-bit machines at home, myself - an SGI Indigo2 and a DEC AlphaStation 200. Yeah, they're seriously out of date now, but they're still nice little workstations. *nix has been doing just fine on 64 bits for some time now. I do have to put up with all sorts of 'cast to pointer from integer of different size' warnings when I compile stuff, but I'm able to run 99% of the stuff I'd run on an x86 box on the Alpha.
Testimony becomes the sole property of the Library of Congress. Unauthorized redistribution or reproduction is expressly prohibited. By submitting your request, you agree to these terms and conditions.
The actual cost of rocket fuel is a tiny portion of your launch cost. And we've used kerosene before - the Saturn V F-1 engines burned it with LOX, if I remember right.
Actually, it's been reported much further back than the 1980's. Only a thousand years ago, it wasn't attributed to electromagnetic fields or trace chemicals, but evil spirits inhabiting a home, or maybe a spell cast by the local witch. Though I think an exorcism or spiritual cleansing (or witch burning) was probably cheaper than moving to a geodesic dome in Alaska. Probably had the same effect, though.
This is what makes language interesting to me... it's sort of taking those abstract ideas and packaging it into 'cross-platform' compatible building blocks (i.e., words). It takes a good speaker/writer to effectively take a multifaceted, complex idea and break it up into those blocks in such a way that it can be re-constructed in the listener's own brain and fit together with what's already there.
I think if we're going to have some sort of 'thought transmission', it'll be sort of a machine-assisted super language. You'd still need some kind of common frame of reference to start with, though. It makes my head hurt just trying to imagine where you'd start when trying to decode and quantify ideas directly from the brain.
What I'd like to see is a 'mind's eye' feedback device - something that can build a picture from what you see in your head, and display it for you, like on a computer screen. You could picture a face, or a scene, or whatever. If you're like me and not a gifted artist, it'd probably be pretty rough at first, but by looking at it you'd be able to say 'no, that's not right', and fix details one at a time. Like working with a police sketch artist, but in real time.
Difficult, but not impossible. Especially in a write-only language like Perl. =]
I remember doing something like that in C when I was first learning the language. I can't remember why, now, but it wasn't a distributed application. I had what was essentially a deliberate buffer overrun - not for overwriting the stack, but for overwriting an authentication flag adjacent to the variable in question. Even with pretty close analysis, it'd just look like a subtle off-by-one bug.
Maybe it's just because I work for a defense contractor, but putting deliberate (security) backdoors in programs has never even really crossed my mind. Even with unclassified systems, it'd probably mean the end of my career. Or at the very least, it'd cost me my job and my security clearance.
That's not to say I haven't put some undocumented features in place, just not ones that deliberately compromise security. They're simple debugging tools - an extra URI parameter that makes an ASP page report (in HTML comments) SQL statements executed and profiles execution times.
Maybe the mindset is different in the commercial world, but here it's a given that someone else will be responsible for your code someday, that there are many eyes watching for things that don't belong.
People get this cloak and dagger impression of security in the military... I don't think that fits at all. It's all about paperwork and documentation and following procedures and regulations. Yeah, I've got a security clearance, but I avoid having to mess with classified stuff whenever possible. In truth, most of it's pretty boring stuff, and it's a pain in the ass to deal with.
The bottom line is that all of us here take too much pride in the quality of our work to deliberately compromise it.
Try $200 for a toner cartridge for a Lexmark Optra S like the one in my office here. I've mostly stopped using it because it's cheaper to print in color on the HP4600 in the other room.
1. The SSID field is the suffix. The callsign element is based on the AX.25 address field, which also allows 6 characters with a SSID.
2. The altitude format is biased to -10,000 meters MSL - about 200 meters short of being able to handle reports from the Challenger Deep. Assuming you're able to transmit through 7 miles of seawater. =] For satellites, I think providing Keplerian elements would be more effective. AO-40 goes very quickly from hundreds of kilometers to tens of thousands of kilometers in altitude. If someone can present a good case for having extended altitude support, though, I'm all ears.
3. Driving backwards would just change the reported heading. I think reporting actual vehicle direction wouldn't be terribly practical since it'd require a separate input - either manual or a magnetic compass. Maybe there would be a need for this with ships?
4. The maidenhead grid locator is admittedly kind of redundant, and I'm considering dropping it (hence the note in red.) The spec tries to address the needs of BEACONet.25, which commonly uses maidenhead grids in its propagation reports.
5. The radio capabilities field is still being tweaked. I think it needs some more refinement to adequately represent modes in use, and things like digital PL tones.
Man, I knew I shouldn't have picked the new topic. I got my server all geared up for a slashdotting, finally got a story posted, and it gets buried in the least-visible spot imaginable.
I asked a friend about this a few years back, when Mir was going to be de-manned. He's a graduate of the Merchant Marine Academy and has a pretty good grounding in the Law of the Sea. He argued against salvage rights in space, because apparently salvage rights in international waters are based on the idea that everyone has pretty much equal access. I don't think the same thing could be argued for space. Besides that, the vast majority of property in orbit is unmanned - just because there's no one sitting on the Hubble Space Telescope doesn't mean you can go and take it for yourself. The same would apply to the station - it's a satellite too, just one that happens to be habitable.
I don't see how most of that is a problem... it's covered pretty clearly in the Outer Space Treaty of 1967. But then, I haven't read the book. (Yeah, practical concerns like getting out without a ladder are certainly an issue, though!)
You can read the text of the treaty at http://www.oosa.unvienna.org/SpaceLaw/outersptxt.h tm - the relevant part is Article V:
States Parties to the Treaty shall regard astronauts as envoys of mankind in outer space and shall render to them all possible assistance in the event of accident, distress, or emergency landing on the territory of another State Party or on the high seas. When astronauts make such a landing, they shall be safely and promptly returned to the State of registry of their space vehicle.
In carrying on activities in outer space and on celestial bodies, the astronauts of one State Party shall render all possible assistance to the astronauts of other States Parties.
States Parties to the Treaty shall immediately inform the other States Parties to the Treaty or the Secretary-General of the United Nations of any phenomena they discover in outer space, including the moon and other celestial bodies, which could constitute a danger to the life or health of astronauts.
The launch failure of Intelsat 708 in China a few years back raised some concerns about crypto material falling into the 'wrong hands'. Seriously, you don't need any sinister motives for hunting down classified material... the paperwork alone from its loss would probably be more trouble than a massive ground search. =]
Here's an excerpt from the Intelsat 708 investigation that might shed some light on the subject.
The Intelsat 708 Encryption Boards Were Never Recovered
The Intelsat 708 satellite carried two FAC-3R encryption boards, one in each of its command processor units. These boards are considered Controlled Cryptographic Items by the Department of Defense, and the algorithm is classified "Secret."
Encryption boards are used to protect the command and control links between the ground station and satellite. They are required even on satellites that carry unclassified U.S. Government communications traffic. These devices do not encrypt the communications traffic that is otherwise processed by the satellite payload.373
Shortly after the Intelsat 708 launch failure, Loral's Communications Security custodian reported to the Department of Defense that the status of the encryption boards was being changed to "destroyed."
This was not seen as unusual by Department of Defense, however, because its prescribed policy requires that encryption boards be reported as "destroyed" when they are launched into orbit.
The Department of Defense did not require Loral to produce any evidence that the FAC-3R boards were in fact destroyed.374
After recovering debris from the crash site, Loral engineers grossly estimated the percentages of various subsystems and components that had been recovered.375 In that estimate, Loral engineer Muhammad Wahdy estimated that 30% of the command processors were recovered.376 Loral personnel then packaged the debris and shipped it to Palo Alto, where engineers examined the debris to specifically determine if the encryption boards were recovered.377
That examination determined that the FAC-3R boards were not, in fact, recovered from the crash site.378
The two FAC-3R encryption boards used on the Intelsat 708 satellite were mounted near the hydrazine propellant tanks and most likely were destroyed in the explosion. Additionally, the two FAC-3R boards had no distinguishing markings other than a serial number, making it extremely difficult to locate them amongst the crash debris.379
It is not known, however, whether the FAC-3R boards were recovered by the PRC. If they were, it would be difficult for the PRC to determine the cryptographic algorithm that was imprinted on them.
Reverse-engineering of a damaged board would be even more difficult. Any successful reverse-engineering would be resource intensive for the PRC.
If the PRC were able to determine the cryptographic algorithm contained on the FAC-3R board, it would gain insight into the state of the U.S. military in the 1960s, although such algorithms remain in use today.380
When the National Security Agency designs and recommends algorithms for use in equipment, it assumes that the equipment will be lost or compromised sometime during its operational lifetime. The National Security Agency relies on unique cryptographic keys for each separate satellite to keep command and control links secure. Because the FAC-3R boards on Intelsat 708 were uniquely keyed, the National Security Agency remains convinced that there is no risk to other satellite systems, now or in the future, resulting from having not recovering the FAC-3R boards from the PRC.381
You don't even have sunlight. That's right, the windows are opaque when there ISN'T a current flowing through them! Better have an UPS on your window or it's going to get really dark when the power goes out.
Most unlocked doors and windows don't result in a burglary, either, but for everyone to ignore the issue is a bad idea when there are bad guys running around out there who can just walk in at will.
Of course most vulnerabilities don't get exploited, it's just a matter of volume.
UNIX-like configuration files? Yeah, there's nothing I enjoy more than tweaking my sendmail.cf...
Config files in *nix are often inconsistent and obscure. Not that hairy, undocumented registry keys are any better. How about an open, common XML format for configuration files? That way we can edit them in vi, or build whatever fancy GUI you want.
I remember seeing the same idea in the first Larry Niven book I ever read, A World Out of Time - the idea's been around for at least a quarter of a century.
Slashdot Mirror
Insightful? It was a joke, and not a very good one. I would have done better, but I wasn't feeling terribly inspired.
Sheesh.
I beg to differ. Mine's got an R4400 CPU. See the manual at http://www.mips.com/publications/documentation/R44 00_Uman_book_Ed2.pdf, specifically page 39:
"The natural mode of operation for the R4000 processor is as a 64-bit microprocessor; however, 32-bit applications maintain compatibility even when the processor operates as a 64-bit processor."
I've got two 64-bit machines at home, myself - an SGI Indigo2 and a DEC AlphaStation 200. Yeah, they're seriously out of date now, but they're still nice little workstations. *nix has been doing just fine on 64 bits for some time now. I do have to put up with all sorts of 'cast to pointer from integer of different size' warnings when I compile stuff, but I'm able to run 99% of the stuff I'd run on an x86 box on the Alpha.
Testimony becomes the sole property of the Library of Congress. Unauthorized redistribution or reproduction is expressly prohibited. By submitting your request, you agree to these terms and conditions.
The actual cost of rocket fuel is a tiny portion of your launch cost. And we've used kerosene before - the Saturn V F-1 engines burned it with LOX, if I remember right.
Are available here.
Takes a bit more equipment, though.
Actually, it's been reported much further back than the 1980's. Only a thousand years ago, it wasn't attributed to electromagnetic fields or trace chemicals, but evil spirits inhabiting a home, or maybe a spell cast by the local witch. Though I think an exorcism or spiritual cleansing (or witch burning) was probably cheaper than moving to a geodesic dome in Alaska. Probably had the same effect, though.
This is what makes language interesting to me... it's sort of taking those abstract ideas and packaging it into 'cross-platform' compatible building blocks (i.e., words). It takes a good speaker/writer to effectively take a multifaceted, complex idea and break it up into those blocks in such a way that it can be re-constructed in the listener's own brain and fit together with what's already there.
I think if we're going to have some sort of 'thought transmission', it'll be sort of a machine-assisted super language. You'd still need some kind of common frame of reference to start with, though. It makes my head hurt just trying to imagine where you'd start when trying to decode and quantify ideas directly from the brain.
What I'd like to see is a 'mind's eye' feedback device - something that can build a picture from what you see in your head, and display it for you, like on a computer screen. You could picture a face, or a scene, or whatever. If you're like me and not a gifted artist, it'd probably be pretty rough at first, but by looking at it you'd be able to say 'no, that's not right', and fix details one at a time. Like working with a police sketch artist, but in real time.
Difficult, but not impossible. Especially in a write-only language like Perl. =]
I remember doing something like that in C when I was first learning the language. I can't remember why, now, but it wasn't a distributed application. I had what was essentially a deliberate buffer overrun - not for overwriting the stack, but for overwriting an authentication flag adjacent to the variable in question. Even with pretty close analysis, it'd just look like a subtle off-by-one bug.
Maybe it's just because I work for a defense contractor, but putting deliberate (security) backdoors in programs has never even really crossed my mind. Even with unclassified systems, it'd probably mean the end of my career. Or at the very least, it'd cost me my job and my security clearance.
That's not to say I haven't put some undocumented features in place, just not ones that deliberately compromise security. They're simple debugging tools - an extra URI parameter that makes an ASP page report (in HTML comments) SQL statements executed and profiles execution times.
Maybe the mindset is different in the commercial world, but here it's a given that someone else will be responsible for your code someday, that there are many eyes watching for things that don't belong.
People get this cloak and dagger impression of security in the military... I don't think that fits at all. It's all about paperwork and documentation and following procedures and regulations. Yeah, I've got a security clearance, but I avoid having to mess with classified stuff whenever possible. In truth, most of it's pretty boring stuff, and it's a pain in the ass to deal with.
The bottom line is that all of us here take too much pride in the quality of our work to deliberately compromise it.
With attention spans as short as they are these days? I don't think I can even pay attention long enough to finish this messa
I've glanced over the website, and I still don't have a freaking clue what they're selling. To me, that's not exactly effective advertising.
Try $200 for a toner cartridge for a Lexmark Optra S like the one in my office here. I've mostly stopped using it because it's cheaper to print in color on the HP4600 in the other room.
1. The SSID field is the suffix. The callsign element is based on the AX.25 address field, which also allows 6 characters with a SSID.
2. The altitude format is biased to -10,000 meters MSL - about 200 meters short of being able to handle reports from the Challenger Deep. Assuming you're able to transmit through 7 miles of seawater. =] For satellites, I think providing Keplerian elements would be more effective. AO-40 goes very quickly from hundreds of kilometers to tens of thousands of kilometers in altitude. If someone can present a good case for having extended altitude support, though, I'm all ears.
3. Driving backwards would just change the reported heading. I think reporting actual vehicle direction wouldn't be terribly practical since it'd require a separate input - either manual or a magnetic compass. Maybe there would be a need for this with ships?
4. The maidenhead grid locator is admittedly kind of redundant, and I'm considering dropping it (hence the note in red.) The spec tries to address the needs of BEACONet.25, which commonly uses maidenhead grids in its propagation reports.
5. The radio capabilities field is still being tweaked. I think it needs some more refinement to adequately represent modes in use, and things like digital PL tones.
Man, I knew I shouldn't have picked the new topic. I got my server all geared up for a slashdotting, finally got a story posted, and it gets buried in the least-visible spot imaginable.
Scripts discriminate against YOU!!!
(Or maybe that should be Hollywood...)
Hey, we've got tons of 'Secret Government Property' at work... but a spectrographic differential analyzer, THAT's something I could use in my garage.
I asked a friend about this a few years back, when Mir was going to be de-manned. He's a graduate of the Merchant Marine Academy and has a pretty good grounding in the Law of the Sea. He argued against salvage rights in space, because apparently salvage rights in international waters are based on the idea that everyone has pretty much equal access. I don't think the same thing could be argued for space. Besides that, the vast majority of property in orbit is unmanned - just because there's no one sitting on the Hubble Space Telescope doesn't mean you can go and take it for yourself. The same would apply to the station - it's a satellite too, just one that happens to be habitable.
I don't see how most of that is a problem... it's covered pretty clearly in the Outer Space Treaty of 1967. But then, I haven't read the book. (Yeah, practical concerns like getting out without a ladder are certainly an issue, though!)
h tm - the relevant part is Article V:
You can read the text of the treaty at http://www.oosa.unvienna.org/SpaceLaw/outersptxt.
States Parties to the Treaty shall regard astronauts as envoys of mankind in outer space and shall render to them all possible assistance in the event of accident, distress, or emergency landing on the territory of another State Party or on the high seas. When astronauts make such a landing, they shall be safely and promptly returned to the State of registry of their space vehicle.
In carrying on activities in outer space and on celestial bodies, the astronauts of one State Party shall render all possible assistance to the astronauts of other States Parties.
States Parties to the Treaty shall immediately inform the other States Parties to the Treaty or the Secretary-General of the United Nations of any phenomena they discover in outer space, including the moon and other celestial bodies, which could constitute a danger to the life or health of astronauts.
The launch failure of Intelsat 708 in China a few years back raised some concerns about crypto material falling into the 'wrong hands'. Seriously, you don't need any sinister motives for hunting down classified material... the paperwork alone from its loss would probably be more trouble than a massive ground search. =]
Here's an excerpt from the Intelsat 708 investigation that might shed some light on the subject.
The Intelsat 708 Encryption Boards Were Never Recovered
The Intelsat 708 satellite carried two FAC-3R encryption boards, one in each of its command processor units. These boards are considered Controlled Cryptographic Items by the Department of Defense, and the algorithm is classified "Secret."
Encryption boards are used to protect the command and control links between the ground station and satellite. They are required even on satellites that carry unclassified U.S. Government communications traffic. These devices do not encrypt the communications traffic that is otherwise processed by the satellite payload.373
Shortly after the Intelsat 708 launch failure, Loral's Communications Security custodian reported to the Department of Defense that the status of the encryption boards was being changed to "destroyed."
This was not seen as unusual by Department of Defense, however, because its prescribed policy requires that encryption boards be reported as "destroyed" when they are launched into orbit.
The Department of Defense did not require Loral to produce any evidence that the FAC-3R boards were in fact destroyed.374
After recovering debris from the crash site, Loral engineers grossly estimated the percentages of various subsystems and components that had been recovered.375 In that estimate, Loral engineer Muhammad Wahdy estimated that 30% of the command processors were recovered.376 Loral personnel then packaged the debris and shipped it to Palo Alto, where engineers examined the debris to specifically determine if the encryption boards were recovered.377
That examination determined that the FAC-3R boards were not, in fact, recovered from the crash site.378
The two FAC-3R encryption boards used on the Intelsat 708 satellite were mounted near the hydrazine propellant tanks and most likely were destroyed in the explosion. Additionally, the two FAC-3R boards had no distinguishing markings other than a serial number, making it extremely difficult to locate them amongst the crash debris.379
It is not known, however, whether the FAC-3R boards were recovered by the PRC. If they were, it would be difficult for the PRC to determine the cryptographic algorithm that was imprinted on them.
Reverse-engineering of a damaged board would be even more difficult. Any successful reverse-engineering would be resource intensive for the PRC.
If the PRC were able to determine the cryptographic algorithm contained on the FAC-3R board, it would gain insight into the state of the U.S. military in the 1960s, although such algorithms remain in use today.380
When the National Security Agency designs and recommends algorithms for use in equipment, it assumes that the equipment will be lost or compromised sometime during its operational lifetime. The National Security Agency relies on unique cryptographic keys for each separate satellite to keep command and control links secure. Because the FAC-3R boards on Intelsat 708 were uniquely keyed, the National Security Agency remains convinced that there is no risk to other satellite systems, now or in the future, resulting from having not recovering the FAC-3R boards from the PRC.381
You don't even have sunlight. That's right, the windows are opaque when there ISN'T a current flowing through them! Better have an UPS on your window or it's going to get really dark when the power goes out.
Most unlocked doors and windows don't result in a burglary, either, but for everyone to ignore the issue is a bad idea when there are bad guys running around out there who can just walk in at will.
Of course most vulnerabilities don't get exploited, it's just a matter of volume.
UNIX-like configuration files? Yeah, there's nothing I enjoy more than tweaking my sendmail.cf...
Config files in *nix are often inconsistent and obscure. Not that hairy, undocumented registry keys are any better. How about an open, common XML format for configuration files? That way we can edit them in vi, or build whatever fancy GUI you want.
...and nobody understood a word that it said, but we all had fun filling out forms and playing with the penciles on the bench there...