I believe it was in the early 60s. A defense project launched a bundle of several million needles into orbit to use as a signal reflector.
This was attempted several times (or at least twice). One of the needle distribution payloads failed to deploy... until many years later. The needles performed very very poorly as a reflector.
Sorry this is all so vague. My source of this information is out of town. As soon as he's back, I'll post the specifics (if anyone's interested).
If you take out a sattelite, you run a decent chance of leaving MORE debris in space than you start with.
Specifically, depending on how you "take it out", you are likely to introduce a lot of orbital debris. An energetic disassembly (i.e., you blow it up) will result in many small particles being spread out with a broad range of directions and velocities. Many of these will be directed into the atmosphere, where they'll burn up. Many will be directed out into space: if they have sufficient velocity, they'll leave the earth system, however, most will assume a very "tall" elliptical orbit and will burn up in the atmosphere when trying to approach perigee.
But there is a class of the particles that will remain in orbit. These will often have an interesting orbital dynamic in that they'll all have orbital foci at the point of the detonation and at the opposite point on the orbital sphere.
For more information, and some diagrams, look up references to the disastrous Haystack project.
Also, remember that objects in orbit are (not surprisingly) moving at orbital velocity, which is quite fast. Even a small particle or fleck of paint is an amazing kinetic energy weapon at that speed -- especially if you're in a different orbit, and the net vector adds. There are some scary pictures of aluminum portions of the Long Duration Exposure Facility (LDEF) that were badly pitted or blasted through by debris that was 1mm or smaller.
That's why the shuttle always tries to keep the narrow profile (keep tangent to the orbital sphere). It's also why you couldn't get me out on a space walk!
Genetics is just part of it
on
Genome
·
· Score: 1
As should probably be clear, when talking about living organisms, we're talking about extremely complicated electrochemical machines here.
Sure, genes determine some critical information about the "hardware," but, like any complex machine, organisms are affected by use and environment.
The purely deterministic genetic view is pretty weak. For an amusing, somewhat outrageous analysis of the situation (and why Darwinism is *really* just a flavor of Christianity), check out Brian Goodwin's "How the Leopard Changed Its Spots (the evolution of complexity)". ISBN 1857992512.
After giving my 86-year-old Grandmother a Windows box, I've learned a lot about how easy GUIs are to use. Or aren't, as the case may be.
We talk a lot about "inituitive" GUIs, but that intuition has to be learned a click at a time.
The whole single-click vs. double-click vs. click-drag is fairly arbitrary in the Windows world. For example, why are toolbars single-click, while desktop icons double-click? It's easy for people who understand the difference, but it's not easy to learn if this is all new and frightening.
And especially for someone with coordination limitations, it's a real challenge to navigate and use Windows. Putting it into 640x480 mode on a 17" monitor helps, since it makes the icons bigger and easier to see. Putting the mouse on lowest sensitivity helps, except for the click/double-click timing issue.
I think that if we want to get the largest audience, a purely menu-driven system (like old BBSes, or DOS using Peter Norton's menuing utilities from the days when Peter himself was writing 'em) might be the way to go. I dunno.
I think one of the biggest issues will be identifying Denial of Service as an attack. I have a legitimate load testing utility that simulates actual browser traffic. Say I run it against someone else's site. They'll see that a lot of traffic's coming from me, and eventually figure out it's bogus and take appropriate measures. But distribute this, and it'll look like actual traffic. Get enough friends doing it, and we take 'em down with what appears to be perfectly normal browsing.
The analogy to the "real" world is roads and bridges. During normal hours, they run well. During rush hour, they clog up and perform poorly. And during a demonstration (like recent examples in Seattle and Miami), they clog up and perform poorly. You can consider the recent anti-WTO situation up in Seattle to have been a DoS attack on downtown. But you wouldn't consider gridlock at 5:30PM in Los Angeles to be a DoS attack.
To solve these problems, you have to know what's causing it. If it's just normal traffic and the infrastructure is insufficient, it gets ignored until people get fed up enough to vote more tax money into building wider roads or better public transportation (again, analogous to buying more servers or a fatter pipe). If it's demonstrators, you either address their concerns or you send in the National Guard to beat the crap out of them (depending on the political climate).
In this world, it's easier to differentiate the two situations. If a bunch of cars are jammed together at rush hour, you know it's a traffic problem. If it's crowds of people singing songs and holding signs, you know it's a demonstration. And if it's a possible sick-out at Northwest Airlines, you're not sure if it's a DoS or not, so you get a warrant to read their home email and find out.
With computer protocols, though, usage and abuse can look identical. Even wild surges in activity can be from legitimate usage. How do you forsee systems being put in place that can differentiate between actual usage and DoS? Doesn't this almost inevitably lead to some non-forge-able, traceable, unique identifier? And doesn't this translate to the demise of privacy on the web?
Presumably, the FBI has identified the specific DoS programs that were used in the Yahoo and subsequent attacks. But how hard is it to change the signature and/or name of the program?
Since we don't know what they're looking for, we don't know that they're doing it right. And unless we run as root, we can't look at what piece of code is using what port. AND, since we don't have the source available and don't know exactly what it's doing, we're certainly not running the code as root.
So it kind of seems like a "oh shit -- let's look like we have a solution!" ploy to reassure Wall Street. It doesn't seem like a viable approach to really address the problem.
Some ideas have been advanced here on/. as well as other areas as to how to control this kind of problem. I think that getting responsible sysadmins and ISPs (or convincing irresponsible syasadmins and ISPs to try harder) is really the first step.
I'm currently working on the Secure Treasury And Shaerd Hoard, a system to allow documents to live out in a distributed cloud. Any given node only has a little piece of the information, thus individual node operators are not liable.
Preliminary details can be found at http://www.andthehorseyourodeinon.com/stash
I'm about 10% done with a Java test implementation; I invite comments and participation by people who understand the issues better than I do.
Open source software will always be the quickest for bugfixes assuming that the software is currently being actively maintained.
Aye, there's the rub. There are a fair number of Open Source packages that are no longer maintained. Bug fixes may or may not ever come for those packages.
Of course, you do have the opportunity to fix 'em yourself, if you have the skill and inclination. So even un-maintained packages are not dead-ends, if you have the time and talent to do your own maintenance. It should be clear that not everybody does.
The inescapable conclusion is that the User classes are doomed to use buggy software if they don't pick their packages carefully. This is true of commercial closed-source products just as it is of Linux applications, world domination or not.
There are plenty of products that will now never see the light of day on Linux because the cost will be too high to retrofit them into the text-only Makefile nightmare that is g++. THAT should be a reason for Linux users to complain -- Metrowerks' decision to cancel this product deprives you of software that otherwise will never be ported from Windows or the Mac because Linux doesn't have the rich set of IDE-based tools that modern developers rely on to deliver code in a cost-effective manner. Please don't consider the previous statement flame bait. It's not. It's a cold, hard fact about managing large, complicated development tasks. There are better ways to do it now in the 21st century than using a directory full of text files glued together with a batch-oriented makefile. Metrowerks has what is arguably one of the best cross-platform environments for doing this and now you'll never see it (or the software that would have been ported with it) because Metrowerks has reneged on a long-standing promise. Boo!
While I'm not a big fan of IDEs, there are starting to be other commercial offerings. Check out IBM's Visual Age for Java. Now that IBM's commiting to strongly support Linux, they may be willing to port Visual Age for C++ to Linux as well (if I were in charge there, I'd certainly see this as a Big opportunity)
The Coolpix cameras, in general, are outstanding. I have a Coolpix 900, and it's great. The image quality is much higher than any other digital camera I've tried. In decent light, it'll take pictures that are as high quality as scanning a 4x5 print.
For use under Linux, photopc works. It uses the serial port, which is kind of painful, but it works. You can take the pictures at standard resolution, which produces ~260k jpeg images. You can do the math how long you'll be waiting around.
For serious use, though, a CompactFlash Memory reader is crucial. I have one for my Mac, but it would be great to have it on one of the Linux boxes. That would put everything in one place!
Slashdot Mirror
This was attempted several times (or at least twice). One of the needle distribution payloads failed to deploy ... until many years later. The needles performed very very poorly as a reflector.
Sorry this is all so vague. My source of this information is out of town. As soon as he's back, I'll post the specifics (if anyone's interested).
Specifically, depending on how you "take it out", you are likely to introduce a lot of orbital debris. An energetic disassembly (i.e., you blow it up) will result in many small particles being spread out with a broad range of directions and velocities. Many of these will be directed into the atmosphere, where they'll burn up. Many will be directed out into space: if they have sufficient velocity, they'll leave the earth system, however, most will assume a very "tall" elliptical orbit and will burn up in the atmosphere when trying to approach perigee.
But there is a class of the particles that will remain in orbit. These will often have an interesting orbital dynamic in that they'll all have orbital foci at the point of the detonation and at the opposite point on the orbital sphere.
For more information, and some diagrams, look up references to the disastrous Haystack project.
Also, remember that objects in orbit are (not surprisingly) moving at orbital velocity, which is quite fast. Even a small particle or fleck of paint is an amazing kinetic energy weapon at that speed -- especially if you're in a different orbit, and the net vector adds. There are some scary pictures of aluminum portions of the Long Duration Exposure Facility (LDEF) that were badly pitted or blasted through by debris that was 1mm or smaller.
That's why the shuttle always tries to keep the narrow profile (keep tangent to the orbital sphere). It's also why you couldn't get me out on a space walk!
As should probably be clear, when talking about living organisms, we're talking about extremely complicated electrochemical machines here.
Sure, genes determine some critical information about the "hardware," but, like any complex machine, organisms are affected by use and environment.
The purely deterministic genetic view is pretty weak. For an amusing, somewhat outrageous analysis of the situation (and why Darwinism is *really* just a flavor of Christianity), check out Brian Goodwin's "How the Leopard Changed Its Spots (the evolution of complexity)". ISBN 1857992512.
Obfuscation cuts both ways.
Now when I want to grab DeCSS to play DVDs on my Linux box, I have to search through ten times as much noise to find what I need.
It hinders the profiteers at MPAA, and it hinders the legitimate users as well.
Still, it's pretty damn funny.
After giving my 86-year-old Grandmother a Windows box, I've learned a lot about how easy GUIs are to use. Or aren't, as the case may be.
We talk a lot about "inituitive" GUIs, but that intuition has to be learned a click at a time.
The whole single-click vs. double-click vs. click-drag is fairly arbitrary in the Windows world. For example, why are toolbars single-click, while desktop icons double-click? It's easy for people who understand the difference, but it's not easy to learn if this is all new and frightening.
And especially for someone with coordination limitations, it's a real challenge to navigate and use Windows. Putting it into 640x480 mode on a 17" monitor helps, since it makes the icons bigger and easier to see. Putting the mouse on lowest sensitivity helps, except for the click/double-click timing issue.
I think that if we want to get the largest audience, a purely menu-driven system (like old BBSes, or DOS using Peter Norton's menuing utilities from the days when Peter himself was writing 'em) might be the way to go. I dunno.
I think one of the biggest issues will be identifying Denial of Service as an attack. I have a legitimate load testing utility that simulates actual browser traffic. Say I run it against someone else's site. They'll see that a lot of traffic's coming from me, and eventually figure out it's bogus and take appropriate measures. But distribute this, and it'll look like actual traffic. Get enough friends doing it, and we take 'em down with what appears to be perfectly normal browsing.
The analogy to the "real" world is roads and bridges. During normal hours, they run well. During rush hour, they clog up and perform poorly. And during a demonstration (like recent examples in Seattle and Miami), they clog up and perform poorly. You can consider the recent anti-WTO situation up in Seattle to have been a DoS attack on downtown. But you wouldn't consider gridlock at 5:30PM in Los Angeles to be a DoS attack.
To solve these problems, you have to know what's causing it. If it's just normal traffic and the infrastructure is insufficient, it gets ignored until people get fed up enough to vote more tax money into building wider roads or better public transportation (again, analogous to buying more servers or a fatter pipe). If it's demonstrators, you either address their concerns or you send in the National Guard to beat the crap out of them (depending on the political climate).
In this world, it's easier to differentiate the two situations. If a bunch of cars are jammed together at rush hour, you know it's a traffic problem. If it's crowds of people singing songs and holding signs, you know it's a demonstration. And if it's a possible sick-out at Northwest Airlines, you're not sure if it's a DoS or not, so you get a warrant to read their home email and find out.
With computer protocols, though, usage and abuse can look identical. Even wild surges in activity can be from legitimate usage. How do you forsee systems being put in place that can differentiate between actual usage and DoS? Doesn't this almost inevitably lead to some non-forge-able, traceable, unique identifier? And doesn't this translate to the demise of privacy on the web?
Presumably, the FBI has identified the specific DoS programs that were used in the Yahoo and subsequent attacks. But how hard is it to change the signature and/or name of the program?
/. as well as other areas as to how to control this kind of problem. I think that getting responsible sysadmins and ISPs (or convincing irresponsible syasadmins and ISPs to try harder) is really the first step.
Since we don't know what they're looking for, we don't know that they're doing it right. And unless we run as root, we can't look at what piece of code is using what port. AND, since we don't have the source available and don't know exactly what it's doing, we're certainly not running the code as root.
So it kind of seems like a "oh shit -- let's look like we have a solution!" ploy to reassure Wall Street. It doesn't seem like a viable approach to really address the problem.
Some ideas have been advanced here on
Just my humble and ignorant opinions...
Preliminary details can be found at http://www.andthehorseyourodeinon.com/stash
I'm about 10% done with a Java test implementation; I invite comments and participation by people who understand the issues better than I do.
maintained.
Aye, there's the rub. There are a fair number of Open Source packages that are no longer maintained. Bug fixes may or may not ever come for those packages.
Of course, you do have the opportunity to fix 'em yourself, if you have the skill and inclination. So even un-maintained packages are not dead-ends, if you have the time and talent to do your own maintenance. It should be clear that not everybody does.
The inescapable conclusion is that the User classes are doomed to use buggy software if they don't pick their packages carefully. This is true of commercial closed-source products just as it is of Linux applications, world domination or not.
light of day on Linux because the cost will be too high to retrofit them into the text-only Makefile nightmare that
is g++. THAT should be a reason for Linux users to complain -- Metrowerks' decision to cancel this product
deprives you of software that otherwise will never be ported from Windows or the Mac because Linux doesn't
have the rich set of IDE-based tools that modern developers rely on to deliver code in a cost-effective manner.
Please don't consider the previous statement flame bait. It's not. It's a cold, hard fact about managing large,
complicated development tasks. There are better ways to do it now in the 21st century than using a directory full
of text files glued together with a batch-oriented makefile. Metrowerks has what is arguably one of the best
cross-platform environments for doing this and now you'll never see it (or the software that would have been
ported with it) because Metrowerks has reneged on a long-standing promise. Boo!
While I'm not a big fan of IDEs, there are starting to be other commercial offerings. Check out IBM's Visual Age for Java. Now that IBM's commiting to strongly support Linux, they may be willing to port Visual Age for C++ to Linux as well (if I were in charge there, I'd certainly see this as a Big opportunity)
Presumably, it uses ATP or some similar biologically-derived compound. Once the energy's spent, it goes out. It's not actually alive.
For use under Linux, photopc works. It uses the serial port, which is kind of painful, but it works. You can take the pictures at standard resolution, which produces ~260k jpeg images. You can do the math how long you'll be waiting around.
For serious use, though, a CompactFlash Memory reader is crucial. I have one for my Mac, but it would be great to have it on one of the Linux boxes. That would put everything in one place!