Name server records are not what "defines the domain's very existence", it only defines whether the domain exists in DNS.
There are cases where e.g. name server changes or domain name transfers results in a loss of name server data in the root servers. The domain still exists, but it is or will quickly be in an unusable state.
So, to reiterate:
DNS shows you whether the domain works. WHOIS currently shows you whether the domain exists, as well as domain ownership information.
If ICANN wants to get rid of whois for domain names, it needs to replace it with something else.
Functional EPP implementations would do fine for those of us who are registrars, but leaves the public with no practical way of yielding ownership information.
If you have a DynDNS account, chances are good that you don't forward all your e-mail to a HotMail account.
The Hotmail example was meant as an example in how email is already broken, not as an example of something you might want to communicate with (DynDNS or otherwise).
With this reliabity levels of modern e-mail systems being substantially higher than its past predecessors, the practical needs for this NDR messages are nil. These practical, anti-spam, merits far outweigh the prevailing RFC 2822 technical requirements.
Excuse me, but due to the vast amount of spam handling, modern e-mail systems are substantially less reliable than they used to be.
If you redirect email for your domain name to Hotmail, chances are good that it will disappear without a trace. (No NDR, not in the spam box either.)
Someone else already mentioned the problem of people typoing email addresses. This is a common problem.
Email can be bounced for other reasons, too, such as a full mailbox, or that there is a relaying mail server (yes, DynDNS, they still exist, and in abundance!) which gives up on delivery after a week of timeouts for the destination host.
And so on.
Someone at DynDNS needs a good whack with the clue bat.
Anyway, the Apple solution to buggy software requiring elevated privileges is "you can't run that software" - not very helpful if you need it.
Do you have a cite for that?
I would've thought that sudo let you run basically any software with elevated privileges. But I won't dismiss the possibility that there's some Mac Classic software that won't work with sudo, or that there is some other new software which is coded in a way that means sudo won't work.
Also note that there isn't a DSLR on the market that can take full advantage of these cards, but SanDisk is launching new card readers that do.
Re:Lack of PHP Security in 5 sentences, Not 500 Pa
on
Pro PHP Security
·
· Score: 1
Think you need to wake-up, since PHP 5 there is the PDO extension set which supports lots of DBs and there is also the MySQL(i) extension which stands for "improved" that has prepared statements.
Okay, I didn't consider these to be "native" when I wrote it, but I can see how you might want to consider them "native", and I didn't think it prudent to mention database-specific interfaces.
My recommendation for PEAR::DB is because it supports emulation of prepared statements for databases that don't support it natively, such as MySQL versions older than 4.1.
But I see now that I should've recommended PEAR::MDB2 instead; that was a bad lapse on my part, since PEAR::DB isn't actively maintained anymore.
Lack of PHP Security in 5 sentences, Not 500 Pages
on
Pro PHP Security
·
· Score: 2, Informative
I think you just showed us why you need more than five sentences to describe PHP security.
For one thing, you're not protecting yourself from URL-encoded strings.
And since PHP doesn't yet support bind-variables (prepared statements) natively, looking at PEAR::DB is a good idea; it saves you the hassle of quoting and whatnot.
You're also not dealing with the problem of XSS, since you've failed to deal with output to screen.
You are, in fact, not dealing with anything that's not related to MySQL.
My words needs to be much more extreme to get the exact same meaning, to most people.
Well, in my experience* with online communication mediums, I've found the opposite to be far less problematic and inflammatory. Usually, experienced communicators will ignore outbursts like yours (and followups like mine), while some people do indeed feel provoked to answer. However, those are hardly representative for the constructive responses.
And I'm repeating earlier points because you seem to not agree, yet still haven't really told me why. We are getting closer, you've told a bit about which situations you think escaping is not enough, but not so much why.
I thought I was telling you why in the point about rule 16. What you're missing is information isolation; you shouldn't let escaped whateveritis into your middleware, backend or whatever, because of possible unexpected side effects. When you're programming for the web or other user systems, you can't expect to be in full control of the entire data flow, so you have to protect your interfaces as well as your own code. Yes, this is elementary programming practice, but also easily missed.
In the point about filtering, you again miss the point; filtering is there to avoid divulging information about your system internals.
In the point you make about type casting, you're not type casting, you're type converting. But if the input is a string, in which the semantics may change in the underlying layers, that doesn't help you at all. In other words, you don't just have to know the language, but you have to know quite a bit about the underlying layers as well. This includes knowing how PHP interfaces with things, either through the various default PHP interfaces (escaped data may be made insecure by PHP itself), or through the PEAR installed modules (now that's a beehive of fun), or through system() calls to ImageMagick binaries... This reflects back to the point about filtering, in which you have to take care with what you receive from, for instance, the database you just put stuff into, or the PEAR module you just used to simplify your XML handling.
You pointed out exactly what you where talking about.
No, I pointed out a small fragment about what I was talking about.
I could also mention the problem of object encapsulation in Perl, which can add all sorts of nastiness when people assume that their object instance's data structure is unique and inaccessible to other object instances.
The book itself probably doesn't cover it all, but the rules list shows what the book does cover. And of course the book isn't only about XSS, it covers basic to advanced security for developers in general.
For instance, one avenue of attack I believe isn't covered directly in the book, is the standard security problem in popular PHP software (image galleries, blogs, bulletin boards, CMS, you name it), which is that they consider code in their include path to be safe, even though it's in a publically available path. The presumably experienced programmers -- I say presumably, because the general code quality otherwise indicates that they're far from newbies -- don't seem to notice that this might be a problem.
As I hinted at, I could go on and on and on, and Slashdot is just the Wrong Place for it. The Right Place is a book. Perhaps an online, free-of-charge book, but at this point, I could hardly put something like that into motion without being accused of plagiarism**.
What the recommended book does, is to set people on the right track -- if they're capable and willing -- to dealing with such problems, even if they're not directly covered.
When I wrote the initial recommendation, I erred on the side of brevity, thinking that the books's official web pages could speak for themselves, instead of letting Wiley's promotional page make the attempt. The rest shoul
I don't dislike you personally. I dislike your style, I dislike your methods for "discussion" -- which clearly shows that you have no practical people experience, I dislike your attitude, and I dislike your self-satisfaction at "succeeding" with your low tactics. And still, after complaining that I don't add anything even after I did, you're not contributing yourself; just repeating earlier points. That's what's ticking me off, and that's why you're not getting any further technical response. (You surely don't believe that anyone else is reading this by now, do you?)
If you don't realise that this is a problem with your posting style, then you certainly have no business telling other people how to post. Flaming leads to flaming at least 99% of the time.
I admit to a certain weakness to over-explanation, and as such, I normally prefer brevity to that. If your first response had been "hey, I looked at that list of rules, and I don't see how they do anything for me that escaping won't solve", you'd have gotten a helpful response instantly. And that's a promise, I'm a sucker for people asking for help.
If your next response is technical, to the point and steps away from this completely insane avenue we've walked down, you'll get a technical response.
If not, this is my last post on the topic, because I think I don't have any business adding any more crap, I've already added far more than I should've.
Feel free to email me for the mud-slinging instead.
...by advertising for a book? Yeah, we slashdotter really love that.
You don't seem to mind the other ones quite as much...
If you said what you said in your previous post, in the same post you linked to the book in, it wouldn't be such a pointless advertisement. It would be a relevant comment in the thread AND a good book reference. (Assuming it's a good book, of course.)
What I "said" in that post added nothing to what was already there, on the website of the book, the infamous third link; it's the typical kind of speculation that anyone with a modicum of programming experience could infer.
Yes, it's a good book, otherwise I wouldn't spend any time at all promoting it. There is no financial gain for me to be had; even the author only earns a pittance, as anyone in the publishing industry can tell you. The personal gain I have from promoting it, is that if one out of a thousand programmers actually read the points and understand them, and one out of a hundred thousand programmers read the book and understand it, the web will be a safer place, and leave me less hassle in my daily work.
But now I've got exactly what I wanted, and now we're having an interesting discussion.
No, I don't think so. You fouled it up at the start.
Yes, you got me riled enough to post that previous entry -- including my ad hominem -- but that's what you got for coming across as an idiot. I don't see anything in your attitude to change that impression, and I expect that this post won't help your impression of me.
Well, I guess that teaches me for trying to be helpful on Slashdot.
Maybe you could just mention which of the rules you think would be relevant for preventing XSS (except escaping which I already suggested), or which of them you think is a surprice to a "seasoned programmer".
"Seasoned programmers" have different ideas about what they think is obvious and not. I think many of the rules are relevant, but it depends on the programmer's personality, background and experience battling security issues.
Here's one that's caught a few, and which definitely is something other than your one-in-all solution, escaping:
Rule 16: Do not massage invalid input to make it valid
Escaping invalid input can be an example of falling into this pit trap.
Rule 22: Filter all data before including them in a web page, no matter the origin
Escaping won't help you here, either.
Another thing that escaping won't catch, is input that is perfectly valid, but which in an underlying layer has different semantics. I believe the book mentions an example using VBscript, which IIRC is typeless. The incoming value might be okay for validation, but once it reaches has gone through the database layer and is returned to the VBscript layer again, it's harmful.
Rule 1: Do not underestimate the power of the dark side
This is the first rule for a reason.
Rule 3: In a server-side context, there's no such thing as client-side security
Apparently, few programmers know what a client is. The obvious problem is, of course, that the input you get from JavaScript/ECMAscript, VBscript, Java applets etc. cannot be trusted. The not-so-obvious problem, is that from a middle-ware point of view, the web server is a client, and cannot be trusted.
By the way, my first reply to you was really to teach you about discussing online,
In online discussions, that kind of statement basically means "you win, I have nothing but direct or indirect ad hominem to add". Have you even considered that attacking someone else's post for being not quite to the point is further removed from the point? You have contributed nothing else in this subthread.
Before you presume to "teach" anyone about "online discussions", I suggest that you tone down your patronizing arrogance a few levels, and -- if I may patronize you a bit in return -- learn a bit more about discussions in general.
I've read that skeletal issues are only a concern for those that make the trip...not for those that would live there.
I've read that skeletal issues are a concern for those making the trip, but I haven't read that it's a problem exclusive to the trip, as you imply.
Unfortunately, none of us can back up these claims with "hard" research, since there has been no long-term studies on the effects of a low gravity environment on the skeletal system; the current studies are about microgravity environments, which is reasonable enough, given that we've had space stations to perform such studies in.
It remains speculation that people may have skeletal problems under lower gravity, but it's not an unreasonable inference from the fact that there are skeletal problems with microgravity. The onus is on showing that this is not the case.
It seems you have uniquely redefined the term, "terrforming".
I haven't.
As I mentioned in an earlier post, the term has different usages. Feel free to Google it, or use a bunch of different dictionaries; my usage is common enough, and it is AFAIK very close to the origin of the term.
Lower gravity increases the risk of skeletal damage, which is a well known problem, thanks to the space programs. Of course, this problem is far more significant on the Moon or in near zero gravity. There are other effects as well, but I'm not sure how significant those are at one third gravity.
Right now, skeletal damage a big enough hurdle just for getting the first batch of astronauts to Mars, but the solution sketches are sound; using centrifugal effect as artificial gravity, exercising regularly and getting enough calcium are part of a satisfactory solution to that problem.
As for your other question, yes, I mean "live in the open air as care-free as we do on Earth now". That should be a minimum requirement for a successful terraforming project; without that, we'll be living in bubble villages (and perhaps cities, in time).
May I ask you to re-read my posts -- both of the previous ones as well as this one -- and see if you can catch my thread of reasoning? I have read quite a few articles on the subject, and I remain unconvinced that Mars is "a great hope" as you like to call it.
It's a slim hope at the best of times, and the problems I've mentioned (or "questions") are fundamental to terraforming the planet.
Perhaps your attitude comes from a misunderstanding; when I write "terraforming", I'm writing about making the planet permanently* suitable for terrestrial life forms. You seem to be using it as a far broader term.
* For a value of permanence reasonably close to that of Terra.
The hope of actually terraforming Mars is at best slim.
How will you fix the gravity (1/3 Earth standard, approximately)?
Where will you get the protective magnetic field, so that you don't get roasted next time Father Sun decides to blow his nose?
Where will you get the ozone layer to protect from UV?
Where will you get the rest of the atmosphere to provide additional protection?
It's only the latter two points that have -- and then only very vaguely with hand-waving regarding water, CO2 and O3 -- been covered for, in a suggested process lasting not a few years, a few hundred years or anything that comfortable; rather, we're operating on a scale of at least a few millennia.
Sure, Total Recall had a cool idea, but...
As for Venus, the pressures and temperature also make terraforming unrealistic with technology that we can plausibly explain how might work.
Settling on the planets is another matter entirely.
The topic is too large to cover in a comment on Slashdot.
It's so large that it's best covered in a full-day class at a bare minimum.
I cannot recite the contents of the book, for obvious reasons.
That is why I provided a book recommendation -- a small, reasonably priced book -- and a link to the book's home page, where you can find part of the introduction and an incredibly useful excerpt to the intelligent reader and experienced programmer.
Why am I even bothering with spending time with comments like these on Slashdot? Well, because of people like the first person who responded to me; I know that one person more with the necessary knowledge and experience is worth a hundred times more professionally than the rest, and that saves me time and money. That others don't see the point is irrelevant; you wouldn't have seen the point if I hadn't posted, either.
Mars is the second most hospitable planet we know, after Earth.
Well, Venus is closer, warmer and with a substantial atmosphere. Granted, it's a hell on traditional materials and space technology, but the atmosphere offers significant protection as well as a plentiful source for oxygen (carbon dioxide). On the downside is the weak magnetic field, but Mars offers nothing in that department either.
It's easier to focus on Mars because the planet has been more thoroughly explored, and the lack of atmosphere means that we can practice on the Moon. We have no similar testing grounds for Venus, except for high pressure equipment used in deep sea exploration and drilling.
I'll also agree that Venus probably is more technically challenging to settle, but a bonus point is that as an inner planet, it has less risk of meteoritic impacts.:)
Now, however, that idea is totally gone from speculative fiction.
The idea was picked up again by the Uplift trilogies by David Brin; Sundiver (1980), Startide Rising (1983) and The Uplift War (1987); Brightness Reef (1995), Infinity's Shore (1996) and Heaven's Reach (1998). I suppose that Startide Rising and The Uplift War are the most notable. Baby seals will cry if you don't buy these books, but nobody else.;)
And of course, we have Douglas Adams.
I wouldn't call the idea "totally gone", just not overwhelmingly popular or compelling.
Yet even this can be too simplistic, since there may be other things that's happening in the background.
The first book to deal with this properly that I ever saw was Innocent Code by Sverre H. Huseby (ISBN 0-470-85744-7, Wiley).
I recommend this not only to people new to web programming, but also to seasoned programmers. There's more than one time that I've heard people say "pfah, I know the pit traps, I don't need this book", and a few weeks later tell me that there were things there they hadn't thought about.
The book is concise and to the point.
Note: I'm not neutral about this book; I was one of the people who read through the book and commented on it before publishing time, and Sverre is one of my friends.
Slashdot Mirror
There is no way of keeping track of news without RSS/Atom.
Name server records are not what "defines the domain's very existence", it only defines whether the domain exists in DNS.
There are cases where e.g. name server changes or domain name transfers results in a loss of name server data in the root servers. The domain still exists, but it is or will quickly be in an unusable state.
So, to reiterate:
DNS shows you whether the domain works.
WHOIS currently shows you whether the domain exists, as well as domain ownership information.
If ICANN wants to get rid of whois for domain names, it needs to replace it with something else.
Functional EPP implementations would do fine for those of us who are registrars, but leaves the public with no practical way of yielding ownership information.
The Hotmail example was meant as an example in how email is already broken, not as an example of something you might want to communicate with (DynDNS or otherwise).
Excuse me, but due to the vast amount of spam handling, modern e-mail systems are substantially less reliable than they used to be.
If you redirect email for your domain name to Hotmail, chances are good that it will disappear without a trace. (No NDR, not in the spam box either.)
Someone else already mentioned the problem of people typoing email addresses. This is a common problem.
Email can be bounced for other reasons, too, such as a full mailbox, or that there is a relaying mail server (yes, DynDNS, they still exist, and in abundance!) which gives up on delivery after a week of timeouts for the destination host.
And so on.
Someone at DynDNS needs a good whack with the clue bat.
Well, if I know the path to the program binary I want to run, such as for e.g. Firefox, then I can do the following to run Firefox as root:This works as expected, opening a new Firefox app running as root.
I don't know which apps this wouldn't work for, hence my disclaimer.
Do you have a cite for that?
I would've thought that sudo let you run basically any software with elevated privileges. But I won't dismiss the possibility that there's some Mac Classic software that won't work with sudo, or that there is some other new software which is coded in a way that means sudo won't work.
Rob Galbraith has a review of these new cards, but they're not on the market yet.
Also note that there isn't a DSLR on the market that can take full advantage of these cards, but SanDisk is launching new card readers that do.
Okay, I didn't consider these to be "native" when I wrote it, but I can see how you might want to consider them "native", and I didn't think it prudent to mention database-specific interfaces.
My recommendation for PEAR::DB is because it supports emulation of prepared statements for databases that don't support it natively, such as MySQL versions older than 4.1.
But I see now that I should've recommended PEAR::MDB2 instead; that was a bad lapse on my part, since PEAR::DB isn't actively maintained anymore.
I think you just showed us why you need more than five sentences to describe PHP security.
For one thing, you're not protecting yourself from URL-encoded strings.
And since PHP doesn't yet support bind-variables (prepared statements) natively, looking at PEAR::DB is a good idea; it saves you the hassle of quoting and whatnot.
You're also not dealing with the problem of XSS, since you've failed to deal with output to screen.
You are, in fact, not dealing with anything that's not related to MySQL.
Well, in my experience* with online communication mediums, I've found the opposite to be far less problematic and inflammatory. Usually, experienced communicators will ignore outbursts like yours (and followups like mine), while some people do indeed feel provoked to answer. However, those are hardly representative for the constructive responses.
I thought I was telling you why in the point about rule 16. What you're missing is information isolation; you shouldn't let escaped whateveritis into your middleware, backend or whatever, because of possible unexpected side effects. When you're programming for the web or other user systems, you can't expect to be in full control of the entire data flow, so you have to protect your interfaces as well as your own code. Yes, this is elementary programming practice, but also easily missed.
... This reflects back to the point about filtering, in which you have to take care with what you receive from, for instance, the database you just put stuff into, or the PEAR module you just used to simplify your XML handling.
In the point about filtering, you again miss the point; filtering is there to avoid divulging information about your system internals.
In the point you make about type casting, you're not type casting, you're type converting. But if the input is a string, in which the semantics may change in the underlying layers, that doesn't help you at all. In other words, you don't just have to know the language, but you have to know quite a bit about the underlying layers as well. This includes knowing how PHP interfaces with things, either through the various default PHP interfaces (escaped data may be made insecure by PHP itself), or through the PEAR installed modules (now that's a beehive of fun), or through system() calls to ImageMagick binaries
No, I pointed out a small fragment about what I was talking about.
I could also mention the problem of object encapsulation in Perl, which can add all sorts of nastiness when people assume that their object instance's data structure is unique and inaccessible to other object instances.
The book itself probably doesn't cover it all, but the rules list shows what the book does cover. And of course the book isn't only about XSS, it covers basic to advanced security for developers in general.
For instance, one avenue of attack I believe isn't covered directly in the book, is the standard security problem in popular PHP software (image galleries, blogs, bulletin boards, CMS, you name it), which is that they consider code in their include path to be safe, even though it's in a publically available path. The presumably experienced programmers -- I say presumably, because the general code quality otherwise indicates that they're far from newbies -- don't seem to notice that this might be a problem.
As I hinted at, I could go on and on and on, and Slashdot is just the Wrong Place for it. The Right Place is a book. Perhaps an online, free-of-charge book, but at this point, I could hardly put something like that into motion without being accused of plagiarism**.
What the recommended book does, is to set people on the right track -- if they're capable and willing -- to dealing with such problems, even if they're not directly covered.
When I wrote the initial recommendation, I erred on the side of brevity, thinking that the books's official web pages could speak for themselves, instead of letting Wiley's promotional page make the attempt. The rest shoul
I don't dislike you personally. I dislike your style, I dislike your methods for "discussion" -- which clearly shows that you have no practical people experience, I dislike your attitude, and I dislike your self-satisfaction at "succeeding" with your low tactics. And still, after complaining that I don't add anything even after I did, you're not contributing yourself; just repeating earlier points. That's what's ticking me off, and that's why you're not getting any further technical response. (You surely don't believe that anyone else is reading this by now, do you?)
If you don't realise that this is a problem with your posting style, then you certainly have no business telling other people how to post. Flaming leads to flaming at least 99% of the time.
I admit to a certain weakness to over-explanation, and as such, I normally prefer brevity to that. If your first response had been "hey, I looked at that list of rules, and I don't see how they do anything for me that escaping won't solve", you'd have gotten a helpful response instantly. And that's a promise, I'm a sucker for people asking for help.
If your next response is technical, to the point and steps away from this completely insane avenue we've walked down, you'll get a technical response.
If not, this is my last post on the topic, because I think I don't have any business adding any more crap, I've already added far more than I should've.
Feel free to email me for the mud-slinging instead.
You don't seem to mind the other ones quite as much
What I "said" in that post added nothing to what was already there, on the website of the book, the infamous third link; it's the typical kind of speculation that anyone with a modicum of programming experience could infer.
Yes, it's a good book, otherwise I wouldn't spend any time at all promoting it. There is no financial gain for me to be had; even the author only earns a pittance, as anyone in the publishing industry can tell you. The personal gain I have from promoting it, is that if one out of a thousand programmers actually read the points and understand them, and one out of a hundred thousand programmers read the book and understand it, the web will be a safer place, and leave me less hassle in my daily work.
No, I don't think so. You fouled it up at the start.
Yes, you got me riled enough to post that previous entry -- including my ad hominem -- but that's what you got for coming across as an idiot. I don't see anything in your attitude to change that impression, and I expect that this post won't help your impression of me.
Well, I guess that teaches me for trying to be helpful on Slashdot.
"Seasoned programmers" have different ideas about what they think is obvious and not. I think many of the rules are relevant, but it depends on the programmer's personality, background and experience battling security issues.
Here's one that's caught a few, and which definitely is something other than your one-in-all solution, escaping:
Rule 16: Do not massage invalid input to make it valid
Escaping invalid input can be an example of falling into this pit trap.
Rule 22: Filter all data before including them in a web page, no matter the origin
Escaping won't help you here, either.
Another thing that escaping won't catch, is input that is perfectly valid, but which in an underlying layer has different semantics. I believe the book mentions an example using VBscript, which IIRC is typeless. The incoming value might be okay for validation, but once it reaches has gone through the database layer and is returned to the VBscript layer again, it's harmful.
Rule 1: Do not underestimate the power of the dark side
This is the first rule for a reason.
Rule 3: In a server-side context, there's no such thing as client-side security
Apparently, few programmers know what a client is. The obvious problem is, of course, that the input you get from JavaScript/ECMAscript, VBscript, Java applets etc. cannot be trusted. The not-so-obvious problem, is that from a middle-ware point of view, the web server is a client, and cannot be trusted.
In online discussions, that kind of statement basically means "you win, I have nothing but direct or indirect ad hominem to add". Have you even considered that attacking someone else's post for being not quite to the point is further removed from the point? You have contributed nothing else in this subthread.
Before you presume to "teach" anyone about "online discussions", I suggest that you tone down your patronizing arrogance a few levels, and -- if I may patronize you a bit in return -- learn a bit more about discussions in general.
Is there anything I can say to make you follow the link?
That you can't be bothered with it, and instead keep repeating your request here, is a waste of my time and yours. Get on with it already.
I've read that skeletal issues are a concern for those making the trip, but I haven't read that it's a problem exclusive to the trip, as you imply.
Unfortunately, none of us can back up these claims with "hard" research, since there has been no long-term studies on the effects of a low gravity environment on the skeletal system; the current studies are about microgravity environments, which is reasonable enough, given that we've had space stations to perform such studies in.
It remains speculation that people may have skeletal problems under lower gravity, but it's not an unreasonable inference from the fact that there are skeletal problems with microgravity. The onus is on showing that this is not the case.
I haven't.
As I mentioned in an earlier post, the term has different usages. Feel free to Google it, or use a bunch of different dictionaries; my usage is common enough, and it is AFAIK very close to the origin of the term.
Lower gravity increases the risk of skeletal damage, which is a well known problem, thanks to the space programs. Of course, this problem is far more significant on the Moon or in near zero gravity. There are other effects as well, but I'm not sure how significant those are at one third gravity.
Right now, skeletal damage a big enough hurdle just for getting the first batch of astronauts to Mars, but the solution sketches are sound; using centrifugal effect as artificial gravity, exercising regularly and getting enough calcium are part of a satisfactory solution to that problem.
As for your other question, yes, I mean "live in the open air as care-free as we do on Earth now". That should be a minimum requirement for a successful terraforming project; without that, we'll be living in bubble villages (and perhaps cities, in time).
Well, I blew the fuses on several sets of seats with my Acer Ferrari 4005, so the answer to your question appears to be "no".
:)
The stewards boggled, I boggled, and there was no mention of this limitation in any inflight information or in the material they had available.
But I got lucky in that the fourth attempt didn't blow any fuses.
As for the technical level of the service, I was satisfied.
May I ask you to re-read my posts -- both of the previous ones as well as this one -- and see if you can catch my thread of reasoning? I have read quite a few articles on the subject, and I remain unconvinced that Mars is "a great hope" as you like to call it.
It's a slim hope at the best of times, and the problems I've mentioned (or "questions") are fundamental to terraforming the planet.
Perhaps your attitude comes from a misunderstanding; when I write "terraforming", I'm writing about making the planet permanently* suitable for terrestrial life forms. You seem to be using it as a far broader term.
* For a value of permanence reasonably close to that of Terra.
The hope of actually terraforming Mars is at best slim.
...
How will you fix the gravity (1/3 Earth standard, approximately)?
Where will you get the protective magnetic field, so that you don't get roasted next time Father Sun decides to blow his nose?
Where will you get the ozone layer to protect from UV?
Where will you get the rest of the atmosphere to provide additional protection?
It's only the latter two points that have -- and then only very vaguely with hand-waving regarding water, CO2 and O3 -- been covered for, in a suggested process lasting not a few years, a few hundred years or anything that comfortable; rather, we're operating on a scale of at least a few millennia.
Sure, Total Recall had a cool idea, but
As for Venus, the pressures and temperature also make terraforming unrealistic with technology that we can plausibly explain how might work.
Settling on the planets is another matter entirely.
The topic is too large to cover in a comment on Slashdot.
It's so large that it's best covered in a full-day class at a bare minimum.
I cannot recite the contents of the book, for obvious reasons.
That is why I provided a book recommendation -- a small, reasonably priced book -- and a link to the book's home page, where you can find part of the introduction and an incredibly useful excerpt to the intelligent reader and experienced programmer.
Why am I even bothering with spending time with comments like these on Slashdot? Well, because of people like the first person who responded to me; I know that one person more with the necessary knowledge and experience is worth a hundred times more professionally than the rest, and that saves me time and money. That others don't see the point is irrelevant; you wouldn't have seen the point if I hadn't posted, either.
Well, Venus is closer, warmer and with a substantial atmosphere. Granted, it's a hell on traditional materials and space technology, but the atmosphere offers significant protection as well as a plentiful source for oxygen (carbon dioxide). On the downside is the weak magnetic field, but Mars offers nothing in that department either.
It's easier to focus on Mars because the planet has been more thoroughly explored, and the lack of atmosphere means that we can practice on the Moon. We have no similar testing grounds for Venus, except for high pressure equipment used in deep sea exploration and drilling.
I'll also agree that Venus probably is more technically challenging to settle, but a bonus point is that as an inner planet, it has less risk of meteoritic impacts.
The idea was picked up again by the Uplift trilogies by David Brin; Sundiver (1980), Startide Rising (1983) and The Uplift War (1987); Brightness Reef (1995), Infinity's Shore (1996) and Heaven's Reach (1998). I suppose that Startide Rising and The Uplift War are the most notable. Baby seals will cry if you don't buy these books, but nobody else.
And of course, we have Douglas Adams.
I wouldn't call the idea "totally gone", just not overwhelmingly popular or compelling.
Yet even this can be too simplistic, since there may be other things that's happening in the background.
The first book to deal with this properly that I ever saw was Innocent Code by Sverre H. Huseby (ISBN 0-470-85744-7, Wiley).
I recommend this not only to people new to web programming, but also to seasoned programmers. There's more than one time that I've heard people say "pfah, I know the pit traps, I don't need this book", and a few weeks later tell me that there were things there they hadn't thought about.
The book is concise and to the point.
Note: I'm not neutral about this book; I was one of the people who read through the book and commented on it before publishing time, and Sverre is one of my friends.
Why do you think that?
You still have to pay for Windows 2003 Server, even though you'll get perfectly functional competing operating systems for free.
You still have to pay for your MacOS X upgrade, even though you'll get
Similar examples in software abound.
Businesses like paying for their software.
It would certainly explain why they were hard to come by.