OSX is based on BSD. Apple has continuing access to the decades of experience of the entire BSD community, which itself builds on many generations of operating system technology. There were a LOT of Macs at the last open source conference. Apple's close ties to the open source community, and their friendly non-combative approach, gives them access to more programmers, and far more ways of thinking, than Microsoft could ever hope for. That is why their move to BSD was such a brilliant move.
OSX in a typical user machine is indeed more secure than most Linux distros in a user machine. As long as the communication between the FOSS and OSX communities remains open, the advantage will persist. This is not because OSX is inherently more secure than Linux, but because it is not expected to do as many different security-related things, and is typically far less experimental. A poorly configured OSX server is just as easy to rootkit as a poorly configured Linux server - but there are far fewer OSX servers. Macs rarely have services turned on, while newbie "install everything on the CD" Linux users open zillions of potential vulnerabilities in their systems. That is a difference in exposure, not vulnerability. A well designed and supported distro for newbies (like Xandros) doesn't turn on those exposures either.
The malware exposure for OSX may increase with the recently revealed graphic image vulnerabilities. Macs have a lot of graphics handling code in their many applications. I imagine there is a lot of midnight oil being burned in Cupertino right now, hunting for these newly revealed vulnerabilities. This may be where Linux pulls ahead (it is not as graphics-rich), though I hope both communities complete their code repair and distribution of updates before the virus writers get traction.
I hope the windows community stays safe, too, but I fear that this is one area where their balkanization into little proprietary enclaves will be their undoing.
There are far more Linux machines connected with more bandwidth today than there were net-connected Windows machines when viruses started becoming a problem for those users.
Linux is heavily used by Wall Street and major banks, many websites handling ecommerce, and many sites with fast links. If I was a virus writer, I would aim for the first two if I was after money, and the latter if I wanted zombies for denial-of-service attacks. And if my goal was demonstrating my technical virtuosity, I would go after Linux (and OpenBSD, and Solaris, and Mac) systems rather than Aunt Tildy's Win98 box.
No, the reason there are few Linux exploits is because a properly configured Linux machine is a lot harder to attack, and the different distros make for enough variations that a virus will have a hard time cross-infecting enough of the variants. Linux upgrades are pesky, but frequent and free. If Linspire Linux (log in as root? feh!) ever becomes popular with the newbies, then there will be plenty of exploits - for a while. Then the not-so-newbie users will migrate to more secure but equally easy to use Linux distros (like Xandros), and Linux will regain its well-deserved reputation for security.
Any OS can be made more insecure by carelessness. There are probably hundreds of zombied Linux boxen out there right now. But only proprietary software forbids exceeding the security the manufacturer provides for you. Microsoft and Symantec have some great programmers working on security, but they are few, and limited by corporate monoculture attitudes. It is the search for security excellence among the far more numerous developers and savvy users of Linux that make it grow more secure daily, and it is the democratization and openness of the process that makes good security practices spread among more ordinary users.
Yes, a script kiddie can easily guess the root password of a Knoppix CD. But there are no exploitable open ports, and even if a black hat could get in (somehow), they cannot do anything to the CD and the executables on it.
Yes, they could still (somehow) launch programs, but a flick of the power switch returns the system to the pre-compromise status quo.
I would be far more worried about them looking at the outbound traffic, and sniffing passwords and such. But that can happen with careless users on any operating system, no matter how robust.
My sister-in-law was having problems with Win98 security. I brought over a Knoppix disk, and taught her and her kids how to use Mozilla and Gaim. That took care of their internet needs, and it is damned hard to root a CD.
Next time I visit, I will show them how to mount the C drive and use OpenOffice. That will take care of most school and work needs.
Yes, Linux can be complicated, and the games suck, but this family has modest computing needs, and no time for games. Knoppix, on the CD, is a good fit. It would probably work great for Kathleen Day's needs, too.
Outbound mail can easily be sent from a Linux server to smtp.comcast.net. There is a 10MB cap on filesize, but most recipients have smaller caps so I rarely have a problem with this.
To provide services (such as incoming SMTP, SSH, etc.), one can rent a co-located box (or a User Mode Linux virtual colo) offsite, drive an outbound encrypted tunnel to that, and pass packets through the outbound connected pipe for all the ports and services blocked by Comcast. Linux servers can stay completely within the TOS. Dynamic IP addresses can change with no changes to the DNS tables. The best part of this is that if Comcast ever gets fiesty and NATs their users, there will be no interruption of service. Since you can choose whatever ports you want, an outbound tunnel will always work. At the user level, you can still use the web, download files, etc. without using bandwidth at the colo.
I am currently setting this up now with a local UML colo service, www.pdxcolo.net. $20/month, which is admittedly not free as in beer, but the cost is less painful than the enormous amount of Comcast zombie spam. And the colo can be shared, so real cheapskates can reduce the colo cost further.
I am glad Comcast is finally removing their heads from their posteriors about this. Maybe with some oxygen to their brains, they can make even more smart decisions.:-)
And there is about 1.7E24 Kg of water in the ocean, a lot more locked up in lithospheric rock. When everyone on the planet gets one thousand computers and monitors each, we will have "used up" (I assume that means lost in hyperspace, most water I know about gets reused) about 6E9 * 1E3 * 1.5E3 Kg of water, or about 9E15 Kg, which will lower the ocean surface by 25 millimeters. I guess we will have to increase global warming just a tad to melt some glaciers and fill back in. The other material will lower the land surface by an average of 1mm, which will make the distance to orbit much higher, rendering space travel very difficult:-)
Of course, these scare stories are nonsense, promoted by people that don't understand arithmetic. The major negative consequence of computers is their energy consumption during use. Newer models provide more computation per watt than older models, so old ones should be recycled and the materials they are made of re-used more efficiently. I know of at least two people that went bankrupt assuming that re-using old computers was commercially viable. That said, there is a place for old computers right now, but I hope such niches are filled by modest-performance, ultra-low-power new machines. The performance of a 486-50 grade computer with monitor can be exceeded by a hundred dollars worth of state-of-the-art hand-held hardware consuming perhaps a watt (assuming an available source of natural backlight for the 640x480 LCD screen).
The most important thing is to use that computation wisely and efficiently. Better software can help that. Replacing Windoze with smaller, less bloated OSes can do that, too. Think about how much energy is wasted computing the pixels for Clippy.:-(
Re:Cable propagation lessons from the launch loop
on
Space Elevators Going Up
·
· Score: 2, Insightful
Your familiarity with the aircraft roll control invention simplifies my answer. As you know, it was the Wright invention of three axis control, following years of observation and experiment, that solved the real problem of sustained, powered flight. The competition was hung up on more engine power and more complicated (and hard to understand) structures.
My complaint about the space elevator fans is that they tend to focus on one problem, material strength, to the exclusion of a lot of other issues that they can analyze and in many cases perform experiments to learn about. Cable stability is one such item; having studied it, I can assure you that the problems are not as simple as a "properly designed gripping mechanism". There is no way to hold onto a cable that has fractured because of the accumulation of tension waves, or has caught fire from a lightning strike.
Most people don't even understand the simple behavior of stress reflection at terminations - cables almost always break at discontinuities, because stress waves double when they reflect off them. A lump of mass attached in any way to a cable is such a discontinuity, and there are at least three of them on a space elevator with a single climber on it. For analytical purposes, something is a lump if it is significantly shorter than the wavelengths in the system. On a >40k km cable, *everything* is a lump.
This is not an impossible problem to solve. But if you don't think about it, it will bite you, like the aircraft stability problem bit Lilenthal, Langley, and Santos-Dumont. Getting bit during the attempted construction and use of a space elevator would be a terrible waste. On the other hand, the analysis and solution of problems like this leads to those unexpected tangents that produce spectacular new inventions.
The reason I brought up the Narrows bridge was as an example of something that had all the strength of materials necessary, and was even analyzed for oscillations. However, it was not modelled with sufficient accuracy to find all its resonant modes, especially the nonlinear one that brought it down. Only in the last decade have we developed the mathematical tools to understand the failure analytically; we are still learning things about that bridge.
With zero experience in undamped, transatmospheric ribbons of combustable material, it behooves us to think and analyze and experiment, to find the real problems and their solutions. This is the triumph of the Wright story. These fellows broke away from the herd and solved the real problems of heavier-than-air flight, relying on experiment, observation, and analysis rather than the pontification of so-called experts.
The Space Shuttle, the Chinook helicopter, the Iridium phone constellation, and countless other large engineering projects illustrate that we still haven't gotten over our tendency to optimistically ignore the nitpicky real issues in large designs, issues that could be identified and solved with a bit of skepticism applied correctly.
Low cost access to space is possible, and a worthy goal, but it will not happen until we discover and solve the real problems as opposed to the glamorous ones.
Cable propagation lessons from the launch loop
on
Space Elevators Going Up
·
· Score: 5, Insightful
I've fiddled with the math for these kinds of things for decades on an old idea called the "launch loop". The dynamics of long tapered cables are not impossible, but they are nasty. Very long cables are not like a stout rope to a fixed point nearby, they are more like reaction mass that vibrates. Think "Tacoma Narrows Bridge", which fell down because 1930's engineers did not take their differential equations up to 7th order.
As a climber goes up, the surface anchoring system must pay out more cable to fill in the less tensioned region under the climber, faster and faster as the climber accelerates up the cable, proportional to the speed of the vehicle, total acceleration (including gravity) and inversely proportional to the mass per meter and the square of the propagation velocity of the material.
This is continuously changing, so forces and velocities at the surface are changing also. The problem is, this is an underconstrained and essentially undamped end-terminated system - as the cable gets very long, you develop big standing wave complexes with only two points (surface and top anchor) to remove or store the energy. Keeping the standing waves from building up is difficult, but not impossible. However, it does add an additional constraint on launch rate; you have to spend a lot of time damping out the waves, even granting that these people are more clever than I am at modelling and removing this energy.
Tapering of the cables, necessary even with magic nanotube unobtainium, makes the math even more "exciting", with the additional constraint that the through-atmosphere sections, along with the sections that dip into the atmosphere during wave motion, have to be thoroughly protected against atmospheric degradation (hint: C + O2 -> CO2 ). The portions of the system below the Van Allen belt have to be armored against atomic oxygen damage. Atomic oxygen will burn off the leading edge of ISS at rates approaching a millimeter per decade; the space elevator will be stationary in the gas field, but there are still a lot of fast moving oxygen atoms up to, and through, the radiation belt.
All motor driven systems have limits to their power-to-weight ratio. To get to GEO, we have to add about 60MJ/kg. If we take 33 hours to do so, we need to move an average of 500 watts per kg (total climber weight) through the (photovoltaic or microwave) energy collectors, motors, rollers, etc. For comparison, a 1500 kg sports car with a 300 horsepower gasoline engine uses 150 watts per kg. However, that underestimates the problem. Most of the energy will be added at the beginning of the climb, during the first 10% of the travel distance, as the climber leaves the depths of the gravity well, so expect thousands of kilowatts per kilogram in the power train during this phase. If there are unexpected variations in the power, the change in climbing acceleration will add more ripples to the cable.
I tried to avoid these problems with the launch loop (see URL below) by keeping the altitude under 100 km and the motors on the surface. Even over those "short" distances, cable propagation issues are problematic. Funny/bad things like lightning, ice buildup, fractally gusty winds, and jittery payload forces require special attention, and all reduce the capacity of the anchoring and stability cables. Everything above the atmosphere is exposed to a steady rain of the garbage that your launch system has accumulated in orbit (it all comes down, eventually). Reentry systems for human payloads (in case of failure) add weight. Problems, problems.
At the end of the day, though, the killer issue is lack of demand. The launch loop, with about the price as a space elevator (+/- 3dB) and using materials and technologies we have had for two decades, can put 80 tonnes of payload into orbit *per hour*, for less than $10/kg. Unfortunately, nobody wants that much mass in orbit, even at that miniscule price. Perhaps "if you build it, they will come", or perhaps you end up with another white elephant lik
ESR is right on the money on his observations. His response is prescriptive, and wise, and well thought out.
However, a constructive response is be even better than a prescriptive response. Eric's essay is an instructive example of the thought process that goes into debugging an incomplete user interface, and prescribes excellent principles for user interface design. The essay fails as a description of the process of bringing up a networked CUPS printer. While that was not Eric's purpose, I humbly suggest that his task is not complete until he does so. If he can find the time, he should create another web page, describing his CUPS problem, and the most direct way to solve it, now that he knows what he knows. Countless other users could find his example on the web, and emulate it if applicable.
Windows comes from a box, Linux comes from a community. The solution to the Linux user interface problem comes from the community, too. We can compensate for the rough edges of our software by sharing our experiences and solutions on the web.
If you encounter a difficult problem with Linux, and manage to solve it, don't just sigh and move on. Don't stop with a witty and cogent essay about the bad practices that led to your suffering. Figure out what worked, and write it down, and turn it into a web page. A HOWTO. A cookbook. Whatever you can write that helps others.
Put your helpful web page in a stable place, where other folks can find it and link to it. Keep it fresh and updated as you learn more. Add links to other useful sites (this increases your Google score, and is helpful to your readers). Every once in a great while, you will get a nice email from someone, asking a question or providing further illumination.
Write up your failures, too! You might warn others away from crippled software, or a wrong approach. You might help the authors of a FOSS application find an improvement. Best of all, someone might offer a solution to your problem - then you can change your failure page into a recipe for success!
Most of what I've learned about Linux has come from the webbed experiences of others. I've tried to add a few writeups myself (for example, http://www.keithl.com/linuxbackup.html ), a few pages per year. This has resulted in valuable feedback. There are thousands of people doing this now, many (like ESR) far more prolific than I am. If 10 times as many people wrote about their Linux experiences, what a wealth of helpful information there would be, only a Google search away. This helps more people join us, which adds to the problem-solving power of our community.
Best of all, someday some smart team will figure out how to gather the best of these contributions into help systems that are even more easily searched and evaluated than the search-engine/web-browser paradigm we work with now. Just as Linus Torvalds added a brilliant but relatively small bit of kernel coding to the nutrient-rich primordial soup of GNU free software, unleashing the power of Linux, so our small writeups and howtos will fuel the innovative user discovery systems that will drive the next wave of desktop computing. Open source will be a critical part of that - if user discovery engines can determine functionality from source code, it can relate configurations to behavior and guide the user towards solutions.
Again, Eric's thought provoking essay indicates a problem, and helps us sympathize with the user of a traditional standalone program, isolated from the Internet. But the Internet exists. The cookbooks and examples that can help any user solve any ordinary problem WILL exist, if we all devote a little bit of time sharing our hard-won solutions on the web.
If you can't do, teach. Even the best of us can't repair all the incomplete user interfaces out there, but we can still help others succeed with the interfaces that exist. Aunt Tillie is not alone; when she runs Linux, she can have millions of helpful friends.
I am a chip designer, and pretty good at what I do. I am a diligent reader. But I am not a lawyer, and rely on lawyers to change my written intentions into legally supportable language. NOT legalese; it's just that some words used in ordinary language have special meaning under the law and should be used appropriately.
I have partly rewritten every significant contract I've ever signed. The main problem with a rewrite is time; you must get going on the task while taking the risk that the contract negotiation will drag on. You should sign a simple NDA so that you can get started - the stuff we work on rarely can wait the month or so it will take to review and rewrite (a good lawyer will be busy).
I have not encountered a consulting client that objected too strongly to judicious strikeouts. I am working with one client right now that is reviewing a contract that I added to pages to. This is harder for my clients to accept, but they understand what I am trying to do. My lawyer helped me tweak this massive (and unusual) addition into shape.
If I were mediocre, I would probably be less finicky. In the end, though, a contract is not between abstract entities, but you and a few other individual people, and that relationship is unique. Contracts should describe that unique relationship. If handled correctly, then sympathetic efforts put into crafting a unique contract will be a sign of your attentiveness, not of your waywardness, and in engineering and software especially this should be valued.
On one currently progressing contract negotiation, I am working with Portland Oregon attorney Robert Swider (robert@swider.com), who has worked on a number of software employment contracts and knows where the landmines are. For example, scan for the word "negligent", and be ready to add the word "intentional". Robert also pointed out some gifts in the contract, too. For example, a clause (from my client's lawyer) limiting MY financial responsibility for arbitration. A good lawyer finds both the bad stuff and the good stuff, and knowing about the good stuff will strengthen your sympathies for your client/employer.
This cost me a few hundred dollars. Not throwaway money, but cheaper than a future misunderstanding.
Sex is good, friendship makes good sex last. Play! Spend your hundred bucks on some simple toys/props/cleanup-aids that the two of you can be inventive with.
Sexy? A plastic sheet, squeeze bottles of chocolate and mustard, and a blindfold can be fun for a game of "follow that taste". But that may be a little too intense.
Less sexy? Art paper and fingerpaints. Or plastic sheeting and bodypaint. Make sure it washes off.
Two spud guns, eye protection, a few potatoes, and a park for some more innocent fun.
Set up a treasure hunt. Buy a walkman-style cassette recorder at Goodwill, one with lots of screws on it. Take it apart and put the pieces in waterproof ziploc bags. Put a nice song on a tape for him - if you are careful, you can take apart the cassette, too. Hide the pieces around the neighborhood, including notes explaining how to find the next piece. A good excuse for that leatherman you bought him!
Fireworks are always appreciated, any time of year. I know one elderly couple that have made high explosives together for the last 50 years. If you don't have 400 acres, get something that makes a smaller crater.
A pair of pogo sticks, or hula hoops, or styrofoam swords.
Rent a tandem bicycle.
If you have a friend with acreage, rent a bulldozer (that might cost more like $300, but perhaps your friend needs some work done and can pay part of it). Nothing says love like a D4 Cat.
When inventing games, make it something that he
can control - a lot of us are geeks because we
do not respond well to authority, and prefer things that do what we tell them to. He wants to be clever, give him things he can be clever with. If you are feeling especially creative, give him things you BOTH can be clever with.
Sex is fun, but is over much too quickly. Stuff - especially geek stuff - becomes obsolete too quickly. Memories of laughter can last a lifetime.
I've found replacement parts for both battery charger boards and backlight power boards (the probable reason for a failed backlight) at www.acsparts.com. I've also bought LiIon batteries. Not supercheap, but not too bad most times.
Many of those 300K IBM employees are sales and support staff at remote offices, working zillions of odd little apps that help them do their unique jobs. Many are manufacturing. Think about the amazing diversity of desktops a place like IBM must have.
The really awesome aspect of this move is it goes way beyond Mozilla and Open Office(?). This is a move to Linux support for Milling Machine Master and Band Practice Pro and Golf Buddy 2004, since there are probably people at IBM that use such things full time. Windows is not just an OS, it is a universe of associated third-party applications, and engulfing that whole universe will mean that everything gets ported, or that Wine gets a LOT more attention.
The announcement was made for its market and psychological impact, but if it is really serious it will imply enormous efforts devoted to Wine and to porting tools for third-party software vendors. That may be the only way to remain compatable with all those thousands of third-party applications, and still meet the 2005 goal.
This will get very interesting, because IBM probably has contractual access to a lot of source code for Windows. If the SCO stink is "interesting", imagine the legal ruckus that Microsoft is going to make when all the porting tools and Wine improvements start showing up!
I run Linux on my Thinkpad T30. Most things work. It was non-zero effort to set up. If Linux came pre-installed, I could spend my time on other things.
Thinkpads will be Linux-at-IBM's point of maximum leverage. While lots of apps can be made to work in a web/java/distributed environment, many will have to be ported to work standalone with laptops.
I suspect, though, that full support for Thinkpads will not occur by 2005, and these will probably be exempted as "not desktop" by management for some time. As I understand it, the laptops are manufactured by asian third parties, and the choice of chipsets and components will be limited to what's on the market and functional and inexpensive. So we will continue to see Windows-optimized video and wifi and modem chips, and while we may see complete sets of drivers for these by the 2005 "deadline" they probably won't be open source.
But then, as a Linux-loving chip designer, maybe I can help change that...:-)
Slashdot Mirror
OSX is based on BSD. Apple has continuing access to the decades of experience of the entire BSD community, which itself builds on many generations of operating system technology. There were a LOT of Macs at the last open source conference. Apple's close ties to the open source community, and their friendly non-combative approach, gives them access to more programmers, and far more ways of thinking, than Microsoft could ever hope for. That is why their move to BSD was such a brilliant move.
OSX in a typical user machine is indeed more secure than most Linux distros in a user machine. As long as the communication between the FOSS and OSX communities remains open, the advantage will persist. This is not because OSX is inherently more secure than Linux, but because it is not expected to do as many different security-related things, and is typically far less experimental. A poorly configured OSX server is just as easy to rootkit as a poorly configured Linux server - but there are far fewer OSX servers. Macs rarely have services turned on, while newbie "install everything on the CD" Linux users open zillions of potential vulnerabilities in their systems. That is a difference in exposure, not vulnerability. A well designed and supported distro for newbies (like Xandros) doesn't turn on those exposures either.
The malware exposure for OSX may increase with the recently revealed graphic image vulnerabilities. Macs have a lot of graphics handling code in their many applications. I imagine there is a lot of midnight oil being burned in Cupertino right now, hunting for these newly revealed vulnerabilities. This may be where Linux pulls ahead (it is not as graphics-rich), though I hope both communities complete their code repair and distribution of updates before the virus writers get traction.
I hope the windows community stays safe, too, but I fear that this is one area where their balkanization into little proprietary enclaves will be their undoing.
There are far more Linux machines connected with more bandwidth today than there were net-connected Windows machines when viruses started becoming a problem for those users.
Linux is heavily used by Wall Street and major banks, many websites handling ecommerce, and many sites with fast links. If I was a virus writer, I would aim for the first two if I was after money, and the latter if I wanted zombies for denial-of-service attacks. And if my goal was demonstrating my technical virtuosity, I would go after Linux (and OpenBSD, and Solaris, and Mac) systems rather than Aunt Tildy's Win98 box.
No, the reason there are few Linux exploits is because a properly configured Linux machine is a lot harder to attack, and the different distros make for enough variations that a virus will have a hard time cross-infecting enough of the variants. Linux upgrades are pesky, but frequent and free. If Linspire Linux (log in as root? feh!) ever becomes popular with the newbies, then there will be plenty of exploits - for a while. Then the not-so-newbie users will migrate to more secure but equally easy to use Linux distros (like Xandros), and Linux will regain its well-deserved reputation for security.
Any OS can be made more insecure by carelessness. There are probably hundreds of zombied Linux boxen out there right now. But only proprietary software forbids exceeding the security the manufacturer provides for you. Microsoft and Symantec have some great programmers working on security, but they are few, and limited by corporate monoculture attitudes. It is the search for security excellence among the far more numerous developers and savvy users of Linux that make it grow more secure daily, and it is the democratization and openness of the process that makes good security practices spread among more ordinary users.
Yes, a script kiddie can easily guess the root password of a Knoppix CD. But there are no exploitable open ports, and even if a black hat could get in (somehow), they cannot do anything to the CD and the executables on it.
Yes, they could still (somehow) launch programs, but a flick of the power switch returns the system to the pre-compromise status quo. I would be far more worried about them looking at the outbound traffic, and sniffing passwords and such. But that can happen with careless users on any operating system, no matter how robust.
My sister-in-law was having problems with Win98 security. I brought over a Knoppix disk, and taught her and her kids how to use Mozilla and Gaim. That took care of their internet needs, and it is damned hard to root a CD.
Next time I visit, I will show them how to mount the C drive and use OpenOffice. That will take care of most school and work needs.
Yes, Linux can be complicated, and the games suck, but this family has modest computing needs, and no time for games. Knoppix, on the CD, is a good fit. It would probably work great for Kathleen Day's needs, too.
Vote them out of office in November?
To provide services (such as incoming SMTP, SSH, etc.), one can rent a co-located box (or a User Mode Linux virtual colo) offsite, drive an outbound encrypted tunnel to that, and pass packets through the outbound connected pipe for all the ports and services blocked by Comcast. Linux servers can stay completely within the TOS. Dynamic IP addresses can change with no changes to the DNS tables. The best part of this is that if Comcast ever gets fiesty and NATs their users, there will be no interruption of service. Since you can choose whatever ports you want, an outbound tunnel will always work. At the user level, you can still use the web, download files, etc. without using bandwidth at the colo.
I am currently setting this up now with a local UML colo service, www.pdxcolo.net. $20/month, which is admittedly not free as in beer, but the cost is less painful than the enormous amount of Comcast zombie spam. And the colo can be shared, so real cheapskates can reduce the colo cost further.
I am glad Comcast is finally removing their heads from their posteriors about this. Maybe with some oxygen to their brains, they can make even more smart decisions. :-)
And there is about 1.7E24 Kg of water in the ocean, a lot more locked up in lithospheric rock. When everyone on the planet gets one thousand computers and monitors each, we will have "used up" (I assume that means lost in hyperspace, most water I know about gets reused) about 6E9 * 1E3 * 1.5E3 Kg of water, or about 9E15 Kg, which will lower the ocean surface by 25 millimeters. I guess we will have to increase global warming just a tad to melt some glaciers and fill back in. The other material will lower the land surface by an average of 1mm, which will make the distance to orbit much higher, rendering space travel very difficult :-)
:-(
Of course, these scare stories are nonsense, promoted by people that don't understand arithmetic. The major negative consequence of computers is their energy consumption during use. Newer models provide more computation per watt than older models, so old ones should be recycled and the materials they are made of re-used more efficiently. I know of at least two people that went bankrupt assuming that re-using old computers was commercially viable. That said, there is a place for old computers right now, but I hope such niches are filled by modest-performance, ultra-low-power new machines. The performance of a 486-50 grade computer with monitor can be exceeded by a hundred dollars worth of state-of-the-art hand-held hardware consuming perhaps a watt (assuming an available source of natural backlight for the 640x480 LCD screen).
The most important thing is to use that computation wisely and efficiently. Better software can help that. Replacing Windoze with smaller, less bloated OSes can do that, too. Think about how much energy is wasted computing the pixels for Clippy.
Your familiarity with the aircraft roll control invention simplifies my answer. As you know, it was the Wright invention of three axis control, following years of observation and experiment, that solved the real problem of sustained, powered flight. The competition was hung up on more engine power and more complicated (and hard to understand) structures.
My complaint about the space elevator fans is that they tend to focus on one problem, material strength, to the exclusion of a lot of other issues that they can analyze and in many cases perform experiments to learn about. Cable stability is one such item; having studied it, I can assure you that the problems are not as simple as a "properly designed gripping mechanism". There is no way to hold onto a cable that has fractured because of the accumulation of tension waves, or has caught fire from a lightning strike.
Most people don't even understand the simple behavior of stress reflection at terminations - cables almost always break at discontinuities, because stress waves double when they reflect off them. A lump of mass attached in any way to a cable is such a discontinuity, and there are at least three of them on a space elevator with a single climber on it. For analytical purposes, something is a lump if it is significantly shorter than the wavelengths in the system. On a >40k km cable, *everything* is a lump.
This is not an impossible problem to solve. But if you don't think about it, it will bite you, like the aircraft stability problem bit Lilenthal, Langley, and Santos-Dumont. Getting bit during the attempted construction and use of a space elevator would be a terrible waste. On the other hand, the analysis and solution of problems like this leads to those unexpected tangents that produce spectacular new inventions.
The reason I brought up the Narrows bridge was as an example of something that had all the strength of materials necessary, and was even analyzed for oscillations. However, it was not modelled with sufficient accuracy to find all its resonant modes, especially the nonlinear one that brought it down. Only in the last decade have we developed the mathematical tools to understand the failure analytically; we are still learning things about that bridge.
With zero experience in undamped, transatmospheric ribbons of combustable material, it behooves us to think and analyze and experiment, to find the real problems and their solutions. This is the triumph of the Wright story. These fellows broke away from the herd and solved the real problems of heavier-than-air flight, relying on experiment, observation, and analysis rather than the pontification of so-called experts.
The Space Shuttle, the Chinook helicopter, the Iridium phone constellation, and countless other large engineering projects illustrate that we still haven't gotten over our tendency to optimistically ignore the nitpicky real issues in large designs, issues that could be identified and solved with a bit of skepticism applied correctly.
Low cost access to space is possible, and a worthy goal, but it will not happen until we discover and solve the real problems as opposed to the glamorous ones.
I've fiddled with the math for these kinds of things for decades on an old idea called the "launch loop". The dynamics of long tapered cables are not impossible, but they are nasty. Very long cables are not like a stout rope to a fixed point nearby, they are more like reaction mass that vibrates. Think "Tacoma Narrows Bridge", which fell down because 1930's engineers did not take their differential equations up to 7th order.
As a climber goes up, the surface anchoring system must pay out more cable to fill in the less tensioned region under the climber, faster and faster as the climber accelerates up the cable, proportional to the speed of the vehicle, total acceleration (including gravity) and inversely proportional to the mass per meter and the square of the propagation velocity of the material.
This is continuously changing, so forces and velocities at the surface are changing also. The problem is, this is an underconstrained and essentially undamped end-terminated system - as the cable gets very long, you develop big standing wave complexes with only two points (surface and top anchor) to remove or store the energy. Keeping the standing waves from building up is difficult, but not impossible. However, it does add an additional constraint on launch rate; you have to spend a lot of time damping out the waves, even granting that these people are more clever than I am at modelling and removing this energy.
Tapering of the cables, necessary even with magic nanotube unobtainium, makes the math even more "exciting", with the additional constraint that the through-atmosphere sections, along with the sections that dip into the atmosphere during wave motion, have to be thoroughly protected against atmospheric degradation (hint: C + O2 -> CO2 ). The portions of the system below the Van Allen belt have to be armored against atomic oxygen damage. Atomic oxygen will burn off the leading edge of ISS at rates approaching a millimeter per decade; the space elevator will be stationary in the gas field, but there are still a lot of fast moving oxygen atoms up to, and through, the radiation belt.
All motor driven systems have limits to their power-to-weight ratio. To get to GEO, we have to add about 60MJ/kg. If we take 33 hours to do so, we need to move an average of 500 watts per kg (total climber weight) through the (photovoltaic or microwave) energy collectors, motors, rollers, etc. For comparison, a 1500 kg sports car with a 300 horsepower gasoline engine uses 150 watts per kg. However, that underestimates the problem. Most of the energy will be added at the beginning of the climb, during the first 10% of the travel distance, as the climber leaves the depths of the gravity well, so expect thousands of kilowatts per kilogram in the power train during this phase. If there are unexpected variations in the power, the change in climbing acceleration will add more ripples to the cable.
I tried to avoid these problems with the launch loop (see URL below) by keeping the altitude under 100 km and the motors on the surface. Even over those "short" distances, cable propagation issues are problematic. Funny/bad things like lightning, ice buildup, fractally gusty winds, and jittery payload forces require special attention, and all reduce the capacity of the anchoring and stability cables. Everything above the atmosphere is exposed to a steady rain of the garbage that your launch system has accumulated in orbit (it all comes down, eventually). Reentry systems for human payloads (in case of failure) add weight. Problems, problems.
At the end of the day, though, the killer issue is lack of demand. The launch loop, with about the price as a space elevator (+/- 3dB) and using materials and technologies we have had for two decades, can put 80 tonnes of payload into orbit *per hour*, for less than $10/kg. Unfortunately, nobody wants that much mass in orbit, even at that miniscule price. Perhaps "if you build it, they will come", or perhaps you end up with another white elephant lik
ESR is right on the money on his observations. His response is prescriptive, and wise, and well thought out.
However, a constructive response is be even better than a prescriptive response. Eric's essay is an instructive example of the thought process that goes into debugging an incomplete user interface, and prescribes excellent principles for user interface design. The essay fails as a description of the process of bringing up a networked CUPS printer. While that was not Eric's purpose, I humbly suggest that his task is not complete until he does so. If he can find the time, he should create another web page, describing his CUPS problem, and the most direct way to solve it, now that he knows what he knows. Countless other users could find his example on the web, and emulate it if applicable.
Windows comes from a box, Linux comes from a community. The solution to the Linux user interface problem comes from the community, too. We can compensate for the rough edges of our software by sharing our experiences and solutions on the web.
If you encounter a difficult problem with Linux, and manage to solve it, don't just sigh and move on. Don't stop with a witty and cogent essay about the bad practices that led to your suffering. Figure out what worked, and write it down, and turn it into a web page. A HOWTO. A cookbook. Whatever you can write that helps others.
Put your helpful web page in a stable place, where other folks can find it and link to it. Keep it fresh and updated as you learn more. Add links to other useful sites (this increases your Google score, and is helpful to your readers). Every once in a great while, you will get a nice email from someone, asking a question or providing further illumination.
Write up your failures, too! You might warn others away from crippled software, or a wrong approach. You might help the authors of a FOSS application find an improvement. Best of all, someone might offer a solution to your problem - then you can change your failure page into a recipe for success!
Most of what I've learned about Linux has come from the webbed experiences of others. I've tried to add a few writeups myself (for example, http://www.keithl.com/linuxbackup.html ), a few pages per year. This has resulted in valuable feedback. There are thousands of people doing this now, many (like ESR) far more prolific than I am. If 10 times as many people wrote about their Linux experiences, what a wealth of helpful information there would be, only a Google search away. This helps more people join us, which adds to the problem-solving power of our community.
Best of all, someday some smart team will figure out how to gather the best of these contributions into help systems that are even more easily searched and evaluated than the search-engine/web-browser paradigm we work with now. Just as Linus Torvalds added a brilliant but relatively small bit of kernel coding to the nutrient-rich primordial soup of GNU free software, unleashing the power of Linux, so our small writeups and howtos will fuel the innovative user discovery systems that will drive the next wave of desktop computing. Open source will be a critical part of that - if user discovery engines can determine functionality from source code, it can relate configurations to behavior and guide the user towards solutions.
Again, Eric's thought provoking essay indicates a problem, and helps us sympathize with the user of a traditional standalone program, isolated from the Internet. But the Internet exists. The cookbooks and examples that can help any user solve any ordinary problem WILL exist, if we all devote a little bit of time sharing our hard-won solutions on the web.
If you can't do, teach. Even the best of us can't repair all the incomplete user interfaces out there, but we can still help others succeed with the interfaces that exist. Aunt Tillie is not alone; when she runs Linux, she can have millions of helpful friends.
I am a chip designer, and pretty good at what I do. I am a diligent reader. But I am not a lawyer, and rely on lawyers to change my written intentions into legally supportable language. NOT legalese; it's just that some words used in ordinary language have special meaning under the law and should be used appropriately.
I have partly rewritten every significant contract I've ever signed. The main problem with a rewrite is time; you must get going on the task while taking the risk that the contract negotiation will drag on. You should sign a simple NDA so that you can get started - the stuff we work on rarely can wait the month or so it will take to review and rewrite (a good lawyer will be busy).
I have not encountered a consulting client that objected too strongly to judicious strikeouts. I am working with one client right now that is reviewing a contract that I added to pages to. This is harder for my clients to accept, but they understand what I am trying to do. My lawyer helped me tweak this massive (and unusual) addition into shape.
If I were mediocre, I would probably be less finicky. In the end, though, a contract is not between abstract entities, but you and a few other individual people, and that relationship is unique. Contracts should describe that unique relationship. If handled correctly, then sympathetic efforts put into crafting a unique contract will be a sign of your attentiveness, not of your waywardness, and in engineering and software especially this should be valued.
On one currently progressing contract negotiation, I am working with Portland Oregon attorney Robert Swider (robert@swider.com), who has worked on a number of software employment contracts and knows where the landmines are. For example, scan for the word "negligent", and be ready to add the word "intentional". Robert also pointed out some gifts in the contract, too. For example, a clause (from my client's lawyer) limiting MY financial responsibility for arbitration. A good lawyer finds both the bad stuff and the good stuff, and knowing about the good stuff will strengthen your sympathies for your client/employer.
This cost me a few hundred dollars. Not throwaway money, but cheaper than a future misunderstanding.
Sexy? A plastic sheet, squeeze bottles of chocolate and mustard, and a blindfold can be fun for a game of "follow that taste". But that may be a little too intense.
Less sexy? Art paper and fingerpaints. Or plastic sheeting and bodypaint. Make sure it washes off.
Two spud guns, eye protection, a few potatoes, and a park for some more innocent fun.
Set up a treasure hunt. Buy a walkman-style cassette recorder at Goodwill, one with lots of screws on it. Take it apart and put the pieces in waterproof ziploc bags. Put a nice song on a tape for him - if you are careful, you can take apart the cassette, too. Hide the pieces around the neighborhood, including notes explaining how to find the next piece. A good excuse for that leatherman you bought him!
Fireworks are always appreciated, any time of year. I know one elderly couple that have made high explosives together for the last 50 years. If you don't have 400 acres, get something that makes a smaller crater.
A pair of pogo sticks, or hula hoops, or styrofoam swords.
Rent a tandem bicycle.
If you have a friend with acreage, rent a bulldozer (that might cost more like $300, but perhaps your friend needs some work done and can pay part of it). Nothing says love like a D4 Cat.
When inventing games, make it something that he can control - a lot of us are geeks because we do not respond well to authority, and prefer things that do what we tell them to. He wants to be clever, give him things he can be clever with. If you are feeling especially creative, give him things you BOTH can be clever with.
Sex is fun, but is over much too quickly. Stuff - especially geek stuff - becomes obsolete too quickly. Memories of laughter can last a lifetime.
I've found replacement parts for both battery charger boards and backlight power boards (the probable reason for a failed backlight) at www.acsparts.com. I've also bought LiIon batteries. Not supercheap, but not too bad most times.
Many of those 300K IBM employees are sales and support staff at remote offices, working zillions of odd little apps that help them do their unique jobs. Many are manufacturing. Think about the amazing diversity of desktops a place like IBM must have.
The really awesome aspect of this move is it goes way beyond Mozilla and Open Office(?). This is a move to Linux support for Milling Machine Master and Band Practice Pro and Golf Buddy 2004, since there are probably people at IBM that use such things full time. Windows is not just an OS, it is a universe of associated third-party applications, and engulfing that whole universe will mean that everything gets ported, or that Wine gets a LOT more attention.
The announcement was made for its market and psychological impact, but if it is really serious it will imply enormous efforts devoted to Wine and to porting tools for third-party software vendors. That may be the only way to remain compatable with all those thousands of third-party applications, and still meet the 2005 goal.
This will get very interesting, because IBM probably has contractual access to a lot of source code for Windows. If the SCO stink is "interesting", imagine the legal ruckus that Microsoft is going to make when all the porting tools and Wine improvements start showing up!
I run Linux on my Thinkpad T30. Most things work. It was non-zero effort to set up. If Linux came pre-installed, I could spend my time on other things.
... :-)
Thinkpads will be Linux-at-IBM's point of maximum leverage. While lots of apps can be made to work in a web/java/distributed environment, many will have to be ported to work standalone with laptops.
I suspect, though, that full support for Thinkpads will not occur by 2005, and these will probably be exempted as "not desktop" by management for some time. As I understand it, the laptops are manufactured by asian third parties, and the choice of chipsets and components will be limited to what's on the market and functional and inexpensive. So we will continue to see Windows-optimized video and wifi and modem chips, and while we may see complete sets of drivers for these by the 2005 "deadline" they probably won't be open source.
But then, as a Linux-loving chip designer, maybe I can help change that