Which actually illustrates my point. The books for Windows users spend a lot of time explaining why you would want to run a program automatically. They have to - this may the first time the reader has been exposed to these concepts.
But coming from Linux/Unix world I already have the basic concepts. I can jump straight into the instructions, perhaps with some documentation of where the Linux/Unix and Windows concepts differ in their details.
How about a book going the other way? I usually try to stay far, far away from Windows admin tasks, but the generally low quality of Windows admins means that I'm often left on my own since the problems I'm solving rarely fit into the point-and-click world they live in.
There are books that attempt to explain simple Linux tasks to Windows users, but don't seem to be any books that discuss advanced Windows topics to Linux/Unix users. E.g., I know that the "system tray" is similar to our/etc/init.d, but what's the details?
We're (mostly) not lawyers, but we DO have an idea of what's usual and customary in this field.
Here's a clue - if somebody says "hey, can my (boss|client|contractor|whoever) do this?" and we've seen the same situation play out a dozen times, always with the same results, we don't need a lawyer to predict the likely outcome of the latest incarnation.
Of course people should consult lawyers when there's any real question about a situation, but we aren't infants who need to run to a lawyer for every single damn question. E.g., I occasionally get "invoices" for things I never ordered and things of no possible interest to me. (E.g., a directory listing for my "gasoline station.") I don't need to pay a lawyer to learn that they're probably scams and it would be a waste of my time and money to pursue the matter.
Bottom line, IMO, is that the beta tester was way out of line in making the request. Unless the success of the company depends on their good will, I would have told them to get lost and not given it another thought unless they actually hired a lawyer to pursue their bogus claims. Checking with a lawyer would be a waste of time and money -- unless you really want to pay a few thousand dollars to learn that there is no precedence for such claims. (AFAIK - I have never heard of a successful claim despite almost 20 years in this field.)
Given your handle, I'm relunctant to jump on that statement *too* fast, yet everything I've heard has said that this is a gross misstatement.
What I've seen in linguistics papers is that all of this variability is just conjugations of the same basic words. In English conjugation has been reduced to things like hot/hotter/hottest or smooth/smoothly or even priority/prioritize. But in other languages adjectives take the form of conjugation instead of separate words, so its akin to snowfreshly, snowcrustedly, snowicegrainedly, etc.
And a small handful of words for "snow" is hardly unreasonable. Fresh snow is very different from the stuff that's been on the ground for a while and is mostly large ice grains, and again that's different from weeks-old stuff which is solid ice. I would be surprised if skiers haven't created words for different type of snows, if they don't already exist.
Are you still defending them counting a single bug in the source code up to four times if all distros fixed it? And that it's legitimate to count the same bug fewer times if some distros never issued an advisory for it? (Shades of the usual closed source "it's not a bug until we admit its a bug!" attitude!)
Or are you using the author's inability to add a few two-digit numbers as some perverse proof that we should trust those numbers? Unless we have a list of the vulnerabilities behind those numbers, that explanation makes as much sense as anything else I've heard.
Ultimately, it's all irrelevant anyway since Microsoft itself has come out strongly against public discussion of vulnerabilities. Some vulnerabilities are undeniable because of exploits, but there's a huge grey area where it's not clear if its a bug or a vulnerability - and many people defer to the authors on these reports. This policy wasn't as explicitly stated at the time in question, but it's obviously been their policy for some time.
If this is the same article mentioned on LWN (can't be sure, since it's slashdotted), this article compared the number of bugs reported against Windows against the number of bugs reported against Red Hat. And Debian. And SuSE. And another distro - forgot which one.
I'm sure it was an honest mistake that most Linux bugs were counted multiple times.
But I don't buy into the "bug count" argument anyway. It's a lot like that controversy over the "most decorated US veteran" (Hacksworth?) - a lot of people think that you can have a warehouse full of bronze stars and distinguished service medals and it's all scrap metal next to a single Congressional Medal of Honor (post.).
What was the last remote root exploit for a widely used Unix service? What about local exploit for a widely used Unix application?
Now ask the same thing about Microsoft.
Finally, "NTBugTraq" may be respected but that doesn't mean it never publishes crap -- sometimes for the purpose of shooting it down. I've seen this happen on comp.risks and elsewhere.
I used to be a strong proponent of individual responsibility as the answer to all things, until I saw somebody make some seemingly small changes at work that eliminated long-standing problems.
Suddenly I saw the same pattern everywhere. When "most people" have a problem adhering to some rule or behavior, it's almost always because there's something in the environment or the rules that make compliance difficult or impossible.
We definitely see this pattern here. It's easy to say that adults should eat better and get more exercise. It becomes a bit more problematic when you hit the fact that the amount of free time available is much less today than a generation ago - far more hours at work, more hours doing household chores (larger houses and more possessions more than offseting labor-saving devices), etc. It becomes impossible when you hit the practical difficulties of arranging childcare, etc.
The situation is even worse with kids. A generation ago schools offered nutritional, albeit instititutional, cooking. Soda and candy machines were rare. PE classes mandatory, extracurricular sports and scouting common. Today schools have junk food in and outside of cafeterias. Many are eliminating all sports, and even PE class.
Some kids have external resources available... but anyone who expects more than a handful of teenagers to get up 30 minutes early every day so they can run through a calesthenics program before school (assuming they can get time in the shower, etc.) is crazy. This is a program that has to be solved as a society, not wagging a finger at the individual.
Most people seem to have forgotten that many things can drive evolution. Survival skills are obviously the most important, but once a population is stable then sexual selection can dominate.
If it's under control, you'll get lucky with makeup and hairpieces. (E.g., one experiment involved clipping the tail feathers of one male (loser) and taping the clipped feathers to the end of another male's tail (stud))
If it's out of control you get peacocks.
And if it's been taken over by humans with nothing better to do, you get show animals - pidgeons and dogs seem to have it worst. Natural selection would never breed large canine species guaranteed to have hip problems, and the things done to pidgeons are unmentionable.
Historically, much of the recent difference in first-world reproductive rates were due to social issues - specifically the willingness to use birth control, which in turn is related to whether the couple were observant Catholics.
But now this may be changing - the breeders are the ones who start early. If you get knocked up for the first time by the age of 15, you'll have lots of kids. And if you wait until after 25, you'll rarely have 3 or more kids.
And that means we would be selecting our species according to whatever young teen girls find sexually attractive. Scary - almost Karmic revenge for what we've done to other species.
February is getting a bum rap on this - the reason for X History Month is to provide tie-ins for the public schools. E.g., TV stations may air a 30-second segment on the evening news, or the newspaper may put in an extra column near the comics.
But what months are available? School's out in much of the country during June, July and August. The kids are back, but getting back into the groove in September.
November has Halloween recovery, Veterans Day and Thansksgiving. December has the large Christmas break. January, like September, is getting back into groove. March/April have a Easter and the usual disruptions spring, standardized tests, etc. May has preparation for final exams.
Out of the entire year, there are two, count 'em TWO, months suitable for X History month. October and February. And February is actually better since it has fewer distractions - there's no distraction as the kids see the first Christmas decorations go up or parents discuss Holiday travel plans.
I'm never been in the Beast, but I've always been struck by a weird dichotomy as an outsider.
On the one hand you have Steve Maguire and his experiences described in _Writing Solid Code_. Microsoft has known how to write reliable code for years, it's known it knows this (this book was published by Microsoft Press), yet some managers still resisted. Ditto many other excellent books published by Microsoft Press.
On the other hand I attended a MS job faire as a non-traditional CS grad student at the University of Colorado. I heard the recruiter tell the potential employees that Microsoft understands coders just want to code, not find and fix bugs. So they have other people do that stuff for them. I'm not the only one who heard it - Evi Nemeth et al mentioned it in the Red Book as well.
So I just don't get it. The public execution of an Outlook or IIS manager for inadequate supervision of the bug issue would do wonders for the motivation of the survivors to pay attention. (Not the literal execution, of course, but in the corporate world being escorted off campus after a meeting with the boss may be worse.)
There are different types of bugs. Some would require months of effort by senior people to fix - they're caused by different assumptions made by two different teams and there's no simple way to reconcile the two.
But a lot of bugs are really braindead things that are easily overlooked (if you don't have compiler warnings turned on) or fixed. Uninitialized variables, functions being called with the incorrect argument, many simple buffer overflows.
I've repeatedly converted "slow, fragile, flakey" code into something that's reasonably responsive and easy to work with in about a week. MS has a more code to deal with, but a serious month-long effort (and a commitment to this process) should show up in a much more reliable system.
Unfortunately many big bugs will remain, but once everyone knows that they just found and fixed a hundred-odd obvious bugs in their own code they'll take the bigger efforts more seriously.
Taking it at face value, they can do a lot in a month if they're serious. I know, I've done a lot in the first week when brought in as a "contractor of last resort" on dying projects - this timeline is stretched mostly because they have so much code to deal with.
First week: turn on "guaranteed bugs!" compiler warnings - uninitialized variables, improperly initialized variables, etc. I'm still floored when some junior programmer thinks that they know more than the compiler on stuff like this. If the compiler says something is uninitialized, 99% of the time it is because you overlooked some obscure branch in your code. If the compiler says the data is too large for the storage specified, it is.
End of first week: a subset of the prior point: turn on the compiler warnings for printf(). Yes, it's a pain to change so much of your code from %ld to %d or vice versa, but I've also found plenty of cases where somebody wasn't paying attention and they tried to print a number with %s. Or a string with %d. Mindnumbing, but celebrate with pizza and go home early when everyone finishes.
Second week: require function prototypes. generate suitable include files, declaring functions and data which is never used outside of its source file 'static.' This can be a pain a times - it's an iterative process that sometimes feels like it will never end - but it has never failed to uncover multiple bugs. People forget parameters, or put them in the wrong order, etc.
At this point you'll also need to make sure that functions always return values.
Third week: turn on rest of compiler warnings, should go quickly.
Third week, con't: turn on profiling. Where are you spending your time? Does it make sense? Inefficient code probably has other flaws, and if you're spending an unexpected amount of time in a single procedure it deserves a careful look.
Then compare the number of open() and close(), the number of malloc() and free(). Again, code with memory leaks often have other flaws, and memory leaks have lead me to overly complex routines that could be replaced with much simplier code without either memory leaks (because I allocated a sufficiently large single buffer instead of a linked link - size determined by domain knowledge) or bugs. Besides, who ever heard of bubblesorting a linked list?! Moron.
Fourth week: this is the start of an open-ended process. Start going through the code (perhaps in an order suggested by the results of the profiling) and verify that the parameters are legal. If something shouldn't be null, test for it. Check return values from procedures that you call.
Simple steps that don't take that long - as I said it usually takes me about a week when starting on a new project, and even if the client is initially skeptical they can accept it's a good way to become familiar with the code. A lot can be done in a month, even if the staff spends a week bitching that it's a waste of time, they don't have that many bugs in their code (one of my particular pleasures is listing a large number of obvious bugs after a few days of effort:-), etc.
The van had security from heavily armed guards in and near those vans, guards trained and authorized the use lethal force against attackers. They had security from good radio communications.
The deceptive coloring (camouflage, disinformation, etc.) wouldn't stop a serious attacker, but it would stop a casual one. Nobody denies that deceptive coloring can be a powerful tool. Unfortunately in the software world it's usually hard or impossible to do this - a link in a 1x1 pixel sounds hard to find... until you remember that it's in plain sight in the HTML - but a lot of people have a hard time understanding this.
Actual "security through obscurity" is things like the US policy of never revealing where its nukes are located, or how may are located at any particular site where the very nature of the facility guarantees that some nukes will be present. (E.g., an ICBM base.)
In your example, "security through obscurity" would be a semi leaving the facility ever 10 to 15 minutes with a big "US Nukes!" label on the side. But fewer than 1% of the trucks actually have nukes on board....
Something I haven't seen mentioned here (is the idea forgotten, or has it been proven to be flawed?) is the "construction ring" method.
Basically you launch your cable fabrication facility and create a *huge* loop of cable. Something long enough to encircle the earth at geostationary orbit. This loop is initially unstable and will require temporary station keeping engines. You don't care about north-south twists, but don't want in-out twists to grow to large. (Read any analysis of _Ringworld_ for details...)
You then turn the cable machines on their side and start laying cable towards/away from earth. The cables will follow local geopotential fields down and up, and eventually you'll have a starter cable touch down. This can be a temporary cable, designed to be discarded, that does nothing but throw mass up the cable to build the ballast and feed additional cable machines that are producing the production cables.
Eventually you have ring in geostationary orbit, plus numerous anchors along the equator. You supplement the ring at geostationary orbit with another ring a bit inside (or outside) of it so that it's always under tension.
Besides solving some construction issues, it eliminates many of the collapse modes. If the cable snaps, the upper portion is kept in place by the ring. Even if all cables are snapped, the ballast weights will keep the ring under tension and survivors can manage station keeping by dumping ballast. (Unfortunately, if all cables snap the rest of the system will have a different net orbital velocity and there could be a big jolt.) Since there are multiple anchors, there's little value to terrorists in destroying any single anchor.
I know that _3001_ mentioned a ring as an endstage after building the first beanstalk, but I thought I've seen papers suggesting they be used as a construction platform.
And the secondary benefits are huge. Let's say the ring is 250,000 km long, and there's a 500m wide band of solar cells attached to that ring. The solar constant is around 1370W/m^2, that's potentially 171 GW of pollution-free power than can be fed down superconducting cables - 540 trillion kWh/year. According to the USGS the US consumed about 9 billion kWh/year of power from all sources in 1998, so even if the ring has only 1% efficiency it would still provide every person in the world 300x more power than the average American consumed in 1998!
Well... I recall reading somewhere that the pattern of leap seconds was off from what was expected. Any theories on the cause, or did some reporter just get confused?
Another Robert Heinlein observation, this time from _Friday_. The issue is never energy, it's how the energy is stored.
The energy required to lift a ton of cargo to GEO is the same regardless of the mechanism used (and disregarding any power you can extract from descending cargo). But there's a tremendous practical difference in that energy coming down superconducting power lines from a solar array out by the ballast or if it comes from liquified oxygen and hydrogen stored in disposable tanks. It makes a tremendous difference whether you the energy is coming via an existing infrastructure (e.g., power cables) or if if you have to waste some fuel to lift the fuel you need now.
I don't know what the current factors are, but I wouldn't be surprised if putting something into GEO requires 99 kgs of fuel for every kg of payload. A beanstalk would get you there with no "waste" other than the reusable elevator car.
As for harmonics caused by weather... I think this has been dismissed. This cable is under millions of tons of tension, and has a cross section of well under a meter when it's in the atmosphere. The load bearing core will be surrounded by a much larger infrastructure for the elevator, power cables, etc., but since it's not load bearing it can be dampened -- and is still on the order of a few meters. With such a small profile and high tension you aren't going to see much energy transferred from weather systems into the cable. (Earthquakes are another matter.)
And the conservation of momentum issues are real, but I (and others) are skipping many of the fine details for overall clarity.
I was just out of college (iirc) when the first popular discussion of beanstalks came out (Charles Sheffield, in some long-dead Baen book-zine).
The numbers were so ludicrious that he repeatedly apologized for wasting our time. Of course this was a flight of fancy, the numbers were orders of magnitude larger than the strongest known materials. Yet, if "ultronium" could be developed from some exotic material....
Then buckyballs were discovered. Then buckytubes.
The fact that this is even "just" possible with known materials less than 20 years later is mindblowing. I can only compare it to the confident RSA predictions in Scientific American (which I also remember when it first appeared) that RSA-128 would take millions of years to crack. We all know how well that prediction held up.
Given this perspective, I don't think it's unreasonable for NASA to spend some serious money considering its options if/when stronger materials become available. It's easier to believe that even stronger materials will be discovered (e.g., perhaps by putting foreign elements within the tubes to manipulate quantum properties) than that we've suddenly hit the ultimate barrier.
Actually, there's strong evidence that the number of large dams constructed over the last few decades have changed the length of the earth's days. Not by a huge amount, but I think it has started to affect the introduction of leap seconds.
(The main reason the earth is slowing down, IIRC, is the tidal forces from the moon and sun. If the moon was gravitationally bound to the earth it would be falling, but since it's not it's slowly drifting away.)
This reminds me of a comment my parents made after taping Atomic Train (NBC) for me since NBC felt Coloradans were too feeble-minded to deal with the plot.
A train containing an atomic (not thermonuclear) bomb crashes in the mountains 40 miles west of Denver. It detonates! What would I do?
I told my mom I would go outside to watch. An atomic detonation at 40 miles away doesn't bother me. An accident at Rocky Flats (5 miles south) when it was operational is a bit worrisome, but not a fission explosion 40 miles away with several mountain ranges between us. Even a thermonuclear explosion at that range is not the instant death portrayed in that movie.
The point is that nuclear weapons, as destructive as they are, are still largely local events. The cable smacking into the equatorial oceans would dump a lot of energy into the water, but that energy would be spread across coastlines worldwide. Millions may still die, but not billions. And that risk may well be considered acceptable if the alternatives are far worse.
I think most serious plans suggest capturing an object already in space, not lifting it from the ground.
But even if you lift it from the ground you can still bootstrap the system. Say the cable extends an extra 20k past GEO - maybe you start with a minimal core and skimpy cars and can only lift 50 extra pounds. No problem, you just lift 50 pounds at a time for a few months. Then 100 pounds at a time. Then 200 pounds. Over time you can expand the core, improve the cars, and continue lifting additional mass into the ballast.
A one-way trip would take about 5 days or so, and your weight would gradually decrease from normal to zero as you reached the geostationary station.
You would not stop at the 200km height, no more than you get off a ski lift at the first tower.
At the 200km height another poster mentioned - you would have a hard time finding any change in your weight. Instead of being something like 6400 km from the center of the earth you're 6600 km away. That's enough for about a 6% change - less than the annual weight change by many people on yo-yo diets.
Robert Heinlein (iirc) once commented that low earth orbit (LEO) is halfway to anywhere, and that's even more true of geosynchronous orbit (GEO). It takes a *lot* of fuel to get out of the earth's gravity well, and getting to GEO for the cost of electricity (provided by in-space solar cells!) would profoundly change everything.
If you want to leave earth orbit, you take a second elevator that runs from geostationary station out to the anchor and let go. Depending on the length of this section, you'll have a ballistic launch to anywhere else in the solar system. Well, you'll need a modest amount of fuel unless the plane of earth's orbit is exactly aligned with your destination, but you'll need orders of magnitude less fuel than you need today, and you can get that fuel up to the launch point for the cost of electricity alone.
If you want to leave the solar system, you let go of the upper elevator and hop to the center of a freespinning tether, then inch outward. When you reach the end of this tether, you could be traveling at a few percent of c. You'll be at Alpha Centari within 100 years... and a second tether there could capture you and slow you down. That's too long for passenger traffic, but brief enough that interstellar colonization is a realistic possibility by the end of the millennium.
So all things considered, I think research into carbon nanotube space elevators has better long term potential than anything rocket propulsion technology. Even antimatter propulsion, excluding some unknown mechanism to mass-produce anti-atoms.
Slashdot Mirror
Or you could just check your mailbox. The spammers are so friendly - telling me how to get dates, add 3" to my penis to impress the dates, etc.
Which actually illustrates my point. The books for Windows users spend a lot of time explaining why you would want to run a program automatically. They have to - this may the first time the reader has been exposed to these concepts.
But coming from Linux/Unix world I already have the basic concepts. I can jump straight into the instructions, perhaps with some documentation of where the Linux/Unix and Windows concepts differ in their details.
How about a book going the other way? I usually try to stay far, far away from Windows admin tasks, but the generally low quality of Windows admins means that I'm often left on my own since the problems I'm solving rarely fit into the point-and-click world they live in.
/etc/init.d, but what's the details?
There are books that attempt to explain simple Linux tasks to Windows users, but don't seem to be any books that discuss advanced Windows topics to Linux/Unix users. E.g., I know that the "system tray" is similar to our
We're (mostly) not lawyers, but we DO have an idea of what's usual and customary in this field.
Here's a clue - if somebody says "hey, can my (boss|client|contractor|whoever) do this?" and we've seen the same situation play out a dozen times, always with the same results, we don't need a lawyer to predict the likely outcome of the latest incarnation.
Of course people should consult lawyers when there's any real question about a situation, but we aren't infants who need to run to a lawyer for every single damn question. E.g., I occasionally get "invoices" for things I never ordered and things of no possible interest to me. (E.g., a directory listing for my "gasoline station.") I don't need to pay a lawyer to learn that they're probably scams and it would be a waste of my time and money to pursue the matter.
Bottom line, IMO, is that the beta tester was way out of line in making the request. Unless the success of the company depends on their good will, I would have told them to get lost and not given it another thought unless they actually hired a lawyer to pursue their bogus claims. Checking with a lawyer would be a waste of time and money -- unless you really want to pay a few thousand dollars to learn that there is no precedence for such claims. (AFAIK - I have never heard of a successful claim despite almost 20 years in this field.)
Given your handle, I'm relunctant to jump on that statement *too* fast, yet everything I've heard has said that this is a gross misstatement.
What I've seen in linguistics papers is that all of this variability is just conjugations of the same basic words. In English conjugation has been reduced to things like hot/hotter/hottest or smooth/smoothly or even priority/prioritize. But in other languages adjectives take the form of conjugation instead of separate words, so its akin to snowfreshly, snowcrustedly, snowicegrainedly, etc.
And a small handful of words for "snow" is hardly unreasonable. Fresh snow is very different from the stuff that's been on the ground for a while and is mostly large ice grains, and again that's different from weeks-old stuff which is solid ice. I would be surprised if skiers haven't created words for different type of snows, if they don't already exist.
I'm sorry, I just don't understand your argument.
Are you still defending them counting a single bug in the source code up to four times if all distros fixed it? And that it's legitimate to count the same bug fewer times if some distros never issued an advisory for it? (Shades of the usual closed source "it's not a bug until we admit its a bug!" attitude!)
Or are you using the author's inability to add a few two-digit numbers as some perverse proof that we should trust those numbers? Unless we have a list of the vulnerabilities behind those numbers, that explanation makes as much sense as anything else I've heard.
Ultimately, it's all irrelevant anyway since Microsoft itself has come out strongly against public discussion of vulnerabilities. Some vulnerabilities are undeniable because of exploits, but there's a huge grey area where it's not clear if its a bug or a vulnerability - and many people defer to the authors on these reports. This policy wasn't as explicitly stated at the time in question, but it's obviously been their policy for some time.
If this is the same article mentioned on LWN (can't be sure, since it's slashdotted), this article compared the number of bugs reported against Windows against the number of bugs reported against Red Hat. And Debian. And SuSE. And another distro - forgot which one.
I'm sure it was an honest mistake that most Linux bugs were counted multiple times.
But I don't buy into the "bug count" argument anyway. It's a lot like that controversy over the "most decorated US veteran" (Hacksworth?) - a lot of people think that you can have a warehouse full of bronze stars and distinguished service medals and it's all scrap metal next to a single Congressional Medal of Honor (post.).
What was the last remote root exploit for a widely used Unix service? What about local exploit for a widely used Unix application?
Now ask the same thing about Microsoft.
Finally, "NTBugTraq" may be respected but that doesn't mean it never publishes crap -- sometimes for the purpose of shooting it down. I've seen this happen on comp.risks and elsewhere.
I used to be a strong proponent of individual responsibility as the answer to all things, until I saw somebody make some seemingly small changes at work that eliminated long-standing problems.
Suddenly I saw the same pattern everywhere. When "most people" have a problem adhering to some rule or behavior, it's almost always because there's something in the environment or the rules that make compliance difficult or impossible.
We definitely see this pattern here. It's easy to say that adults should eat better and get more exercise. It becomes a bit more problematic when you hit the fact that the amount of free time available is much less today than a generation ago - far more hours at work, more hours doing household chores (larger houses and more possessions more than offseting labor-saving devices), etc. It becomes impossible when you hit the practical difficulties of arranging childcare, etc.
The situation is even worse with kids. A generation ago schools offered nutritional, albeit instititutional, cooking. Soda and candy machines were rare. PE classes mandatory, extracurricular sports and scouting common. Today schools have junk food in and outside of cafeterias. Many are eliminating all sports, and even PE class.
Some kids have external resources available... but anyone who expects more than a handful of teenagers to get up 30 minutes early every day so they can run through a calesthenics program before school (assuming they can get time in the shower, etc.) is crazy. This is a program that has to be solved as a society, not wagging a finger at the individual.
Most people seem to have forgotten that many things can drive evolution. Survival skills are obviously the most important, but once a population is stable then sexual selection can dominate.
If it's under control, you'll get lucky with makeup and hairpieces. (E.g., one experiment involved clipping the tail feathers of one male (loser) and taping the clipped feathers to the end of another male's tail (stud))
If it's out of control you get peacocks.
And if it's been taken over by humans with nothing better to do, you get show animals - pidgeons and dogs seem to have it worst. Natural selection would never breed large canine species guaranteed to have hip problems, and the things done to pidgeons are unmentionable.
Historically, much of the recent difference in first-world reproductive rates were due to social issues - specifically the willingness to use birth control, which in turn is related to whether the couple were observant Catholics.
But now this may be changing - the breeders are the ones who start early. If you get knocked up for the first time by the age of 15, you'll have lots of kids. And if you wait until after 25, you'll rarely have 3 or more kids.
And that means we would be selecting our species according to whatever young teen girls find sexually attractive. Scary - almost Karmic revenge for what we've done to other species.
February is getting a bum rap on this - the reason for X History Month is to provide tie-ins for the public schools. E.g., TV stations may air a 30-second segment on the evening news, or the newspaper may put in an extra column near the comics.
But what months are available? School's out in much of the country during June, July and August. The kids are back, but getting back into the groove in September.
November has Halloween recovery, Veterans Day and Thansksgiving. December has the large Christmas break. January, like September, is getting back into groove. March/April have a Easter and the usual disruptions spring, standardized tests, etc. May has preparation for final exams.
Out of the entire year, there are two, count 'em TWO, months suitable for X History month. October and February. And February is actually better since it has fewer distractions - there's no distraction as the kids see the first Christmas decorations go up or parents discuss Holiday travel plans.
I'm never been in the Beast, but I've always been struck by a weird dichotomy as an outsider.
On the one hand you have Steve Maguire and his experiences described in _Writing Solid Code_. Microsoft has known how to write reliable code for years, it's known it knows this (this book was published by Microsoft Press), yet some managers still resisted. Ditto many other excellent books published by Microsoft Press.
On the other hand I attended a MS job faire as a non-traditional CS grad student at the University of Colorado. I heard the recruiter tell the potential employees that Microsoft understands coders just want to code, not find and fix bugs. So they have other people do that stuff for them. I'm not the only one who heard it - Evi Nemeth et al mentioned it in the Red Book as well.
So I just don't get it. The public execution of an Outlook or IIS manager for inadequate supervision of the bug issue would do wonders for the motivation of the survivors to pay attention. (Not the literal execution, of course, but in the corporate world being escorted off campus after a meeting with the boss may be worse.)
There are different types of bugs. Some would require months of effort by senior people to fix - they're caused by different assumptions made by two different teams and there's no simple way to reconcile the two.
But a lot of bugs are really braindead things that are easily overlooked (if you don't have compiler warnings turned on) or fixed. Uninitialized variables, functions being called with the incorrect argument, many simple buffer overflows.
I've repeatedly converted "slow, fragile, flakey" code into something that's reasonably responsive and easy to work with in about a week. MS has a more code to deal with, but a serious month-long effort (and a commitment to this process) should show up in a much more reliable system.
Unfortunately many big bugs will remain, but once everyone knows that they just found and fixed a hundred-odd obvious bugs in their own code they'll take the bigger efforts more seriously.
Taking it at face value, they can do a lot in a month if they're serious. I know, I've done a lot in the first week when brought in as a "contractor of last resort" on dying projects - this timeline is stretched mostly because they have so much code to deal with.
:-), etc.
First week: turn on "guaranteed bugs!" compiler warnings - uninitialized variables, improperly initialized variables, etc. I'm still floored when some junior programmer thinks that they know more than the compiler on stuff like this. If the compiler says something is uninitialized, 99% of the time it is because you overlooked some obscure branch in your code. If the compiler says the data is too large for the storage specified, it is.
End of first week: a subset of the prior point: turn on the compiler warnings for printf(). Yes, it's a pain to change so much of your code from %ld to %d or vice versa, but I've also found plenty of cases where somebody wasn't paying attention and they tried to print a number with %s. Or a string with %d. Mindnumbing, but celebrate with pizza and go home early when everyone finishes.
Second week: require function prototypes. generate suitable include files, declaring functions and data which is never used outside of its source file 'static.' This can be a pain a times - it's an iterative process that sometimes feels like it will never end - but it has never failed to uncover multiple bugs. People forget parameters, or put them in the wrong order, etc.
At this point you'll also need to make sure that functions always return values.
Third week: turn on rest of compiler warnings, should go quickly.
Third week, con't: turn on profiling. Where are you spending your time? Does it make sense? Inefficient code probably has other flaws, and if you're spending an unexpected amount of time in a single procedure it deserves a careful look.
Then compare the number of open() and close(), the number of malloc() and free(). Again, code with memory leaks often have other flaws, and memory leaks have lead me to overly complex routines that could be replaced with much simplier code without either memory leaks (because I allocated a sufficiently large single buffer instead of a linked link - size determined by domain knowledge) or bugs. Besides, who ever heard of bubblesorting a linked list?! Moron.
Fourth week: this is the start of an open-ended process. Start going through the code (perhaps in an order suggested by the results of the profiling) and verify that the parameters are legal. If something shouldn't be null, test for it. Check return values from procedures that you call.
Simple steps that don't take that long - as I said it usually takes me about a week when starting on a new project, and even if the client is initially skeptical they can accept it's a good way to become familiar with the code. A lot can be done in a month, even if the staff spends a week bitching that it's a waste of time, they don't have that many bugs in their code (one of my particular pleasures is listing a large number of obvious bugs after a few days of effort
The van had security from heavily armed guards in and near those vans, guards trained and authorized the use lethal force against attackers. They had security from good radio communications.
The deceptive coloring (camouflage, disinformation, etc.) wouldn't stop a serious attacker, but it would stop a casual one. Nobody denies that deceptive coloring can be a powerful tool. Unfortunately in the software world it's usually hard or impossible to do this - a link in a 1x1 pixel sounds hard to find... until you remember that it's in plain sight in the HTML - but a lot of people have a hard time understanding this.
Actual "security through obscurity" is things like the US policy of never revealing where its nukes are located, or how may are located at any particular site where the very nature of the facility guarantees that some nukes will be present. (E.g., an ICBM base.)
In your example, "security through obscurity" would be a semi leaving the facility ever 10 to 15 minutes with a big "US Nukes!" label on the side. But fewer than 1% of the trucks actually have nukes on board....
oops - I knew I should have triple-checked those numbers! It's potentially 1500 trillion kWh/year.
Something I haven't seen mentioned here (is the idea forgotten, or has it been proven to be flawed?) is the "construction ring" method.
Basically you launch your cable fabrication facility and create a *huge* loop of cable. Something long enough to encircle the earth at geostationary orbit. This loop is initially unstable and will require temporary station keeping engines. You don't care about north-south twists, but don't want in-out twists to grow to large. (Read any analysis of _Ringworld_ for details...)
You then turn the cable machines on their side and start laying cable towards/away from earth. The cables will follow local geopotential fields down and up, and eventually you'll have a starter cable touch down. This can be a temporary cable, designed to be discarded, that does nothing but throw mass up the cable to build the ballast and feed additional cable machines that are producing the production cables.
Eventually you have ring in geostationary orbit, plus numerous anchors along the equator. You supplement the ring at geostationary orbit with another ring a bit inside (or outside) of it so that it's always under tension.
Besides solving some construction issues, it eliminates many of the collapse modes. If the cable snaps, the upper portion is kept in place by the ring. Even if all cables are snapped, the ballast weights will keep the ring under tension and survivors can manage station keeping by dumping ballast. (Unfortunately, if all cables snap the rest of the system will have a different net orbital velocity and there could be a big jolt.) Since there are multiple anchors, there's little value to terrorists in destroying any single anchor.
I know that _3001_ mentioned a ring as an endstage after building the first beanstalk, but I thought I've seen papers suggesting they be used as a construction platform.
And the secondary benefits are huge. Let's say the ring is 250,000 km long, and there's a 500m wide band of solar cells attached to that ring. The solar constant is around 1370W/m^2, that's potentially 171 GW of pollution-free power than can be fed down superconducting cables - 540 trillion kWh/year. According to the USGS the US consumed about 9 billion kWh/year of power from all sources in 1998, so even if the ring has only 1% efficiency it would still provide every person in the world 300x more power than the average American consumed in 1998!
I've actually seen one analysis using DNA as the construction material!
It's not strong enough, but it has other interesting properties and could be used for related structures.
Well... I recall reading somewhere that the pattern of leap seconds was off from what was expected. Any theories on the cause, or did some reporter just get confused?
Another Robert Heinlein observation, this time from _Friday_. The issue is never energy, it's how the energy is stored.
The energy required to lift a ton of cargo to GEO is the same regardless of the mechanism used (and disregarding any power you can extract from descending cargo). But there's a tremendous practical difference in that energy coming down superconducting power lines from a solar array out by the ballast or if it comes from liquified oxygen and hydrogen stored in disposable tanks. It makes a tremendous difference whether you the energy is coming via an existing infrastructure (e.g., power cables) or if if you have to waste some fuel to lift the fuel you need now.
I don't know what the current factors are, but I wouldn't be surprised if putting something into GEO requires 99 kgs of fuel for every kg of payload. A beanstalk would get you there with no "waste" other than the reusable elevator car.
As for harmonics caused by weather... I think this has been dismissed. This cable is under millions of tons of tension, and has a cross section of well under a meter when it's in the atmosphere. The load bearing core will be surrounded by a much larger infrastructure for the elevator, power cables, etc., but since it's not load bearing it can be dampened -- and is still on the order of a few meters. With such a small profile and high tension you aren't going to see much energy transferred from weather systems into the cable. (Earthquakes are another matter.)
And the conservation of momentum issues are real, but I (and others) are skipping many of the fine details for overall clarity.
I was just out of college (iirc) when the first popular discussion of beanstalks came out (Charles Sheffield, in some long-dead Baen book-zine).
The numbers were so ludicrious that he repeatedly apologized for wasting our time. Of course this was a flight of fancy, the numbers were orders of magnitude larger than the strongest known materials. Yet, if "ultronium" could be developed from some exotic material....
Then buckyballs were discovered. Then buckytubes.
The fact that this is even "just" possible with known materials less than 20 years later is mindblowing. I can only compare it to the confident RSA predictions in Scientific American (which I also remember when it first appeared) that RSA-128 would take millions of years to crack. We all know how well that prediction held up.
Given this perspective, I don't think it's unreasonable for NASA to spend some serious money considering its options if/when stronger materials become available. It's easier to believe that even stronger materials will be discovered (e.g., perhaps by putting foreign elements within the tubes to manipulate quantum properties) than that we've suddenly hit the ultimate barrier.
Actually, there's strong evidence that the number of large dams constructed over the last few decades have changed the length of the earth's days. Not by a huge amount, but I think it has started to affect the introduction of leap seconds.
(The main reason the earth is slowing down, IIRC, is the tidal forces from the moon and sun. If the moon was gravitationally bound to the earth it would be falling, but since it's not it's slowly drifting away.)
This reminds me of a comment my parents made after taping Atomic Train (NBC) for me since NBC felt Coloradans were too feeble-minded to deal with the plot.
A train containing an atomic (not thermonuclear) bomb crashes in the mountains 40 miles west of Denver. It detonates! What would I do?
I told my mom I would go outside to watch. An atomic detonation at 40 miles away doesn't bother me. An accident at Rocky Flats (5 miles south) when it was operational is a bit worrisome, but not a fission explosion 40 miles away with several mountain ranges between us. Even a thermonuclear explosion at that range is not the instant death portrayed in that movie.
The point is that nuclear weapons, as destructive as they are, are still largely local events. The cable smacking into the equatorial oceans would dump a lot of energy into the water, but that energy would be spread across coastlines worldwide. Millions may still die, but not billions. And that risk may well be considered acceptable if the alternatives are far worse.
I think most serious plans suggest capturing an object already in space, not lifting it from the ground.
But even if you lift it from the ground you can still bootstrap the system. Say the cable extends an extra 20k past GEO - maybe you start with a minimal core and skimpy cars and can only lift 50 extra pounds. No problem, you just lift 50 pounds at a time for a few months. Then 100 pounds at a time. Then 200 pounds. Over time you can expand the core, improve the cars, and continue lifting additional mass into the ballast.
A one-way trip would take about 5 days or so, and your weight would gradually decrease from normal to zero as you reached the geostationary station.
You would not stop at the 200km height, no more than you get off a ski lift at the first tower.
At the 200km height another poster mentioned - you would have a hard time finding any change in your weight. Instead of being something like 6400 km from the center of the earth you're 6600 km away. That's enough for about a 6% change - less than the annual weight change by many people on yo-yo diets.
Robert Heinlein (iirc) once commented that low earth orbit (LEO) is halfway to anywhere, and that's even more true of geosynchronous orbit (GEO). It takes a *lot* of fuel to get out of the earth's gravity well, and getting to GEO for the cost of electricity (provided by in-space solar cells!) would profoundly change everything.
If you want to leave earth orbit, you take a second elevator that runs from geostationary station out to the anchor and let go. Depending on the length of this section, you'll have a ballistic launch to anywhere else in the solar system. Well, you'll need a modest amount of fuel unless the plane of earth's orbit is exactly aligned with your destination, but you'll need orders of magnitude less fuel than you need today, and you can get that fuel up to the launch point for the cost of electricity alone.
If you want to leave the solar system, you let go of the upper elevator and hop to the center of a freespinning tether, then inch outward. When you reach the end of this tether, you could be traveling at a few percent of c. You'll be at Alpha Centari within 100 years... and a second tether there could capture you and slow you down. That's too long for passenger traffic, but brief enough that interstellar colonization is a realistic possibility by the end of the millennium.
So all things considered, I think research into carbon nanotube space elevators has better long term potential than anything rocket propulsion technology. Even antimatter propulsion, excluding some unknown mechanism to mass-produce anti-atoms.