That's not what I said at all. If you don't want to spend money on battery life, then don't. Buy a cheaper model with a smaller battery. But don't sit there and argue that nobody needs that functionality, just because you don't need it yourself.
But since we have only one example of life-supporting planets, we are unable to state definitively which planetary properties are necessary for supporting life. We can make some good guesses, but until we have a larger sample size we aren't able to say that conditions X, Y, and Z are what make life possible.
If it can occur then it will occur, and given enough time it must occur.
I'm not even going to start on the huge problems with this way of thinking.
In terms of science, we know it's possible, it's not an issue of "can" it happen it's an issue of "where" did it happen again.
Part of the fascination is that we don't know if it's possible. We think that it might be, and the odds seem to be in favor of it, but we won't know for sure until we find some evidence of it. That's how science works.
It seems to me the only reason people are obessed with finding life on Mars, or anywhere else for that matter, is to fill some urge that if they do, to less scientific minded (read: religious) people will be proven wrong.
First, I think this is a false dichotomy, as if a God who created the Heavens and the Earth isn't capable of creating life in multiple places. See Out of the Silent Planet by C.S. Lewis.
Second, I've met a lot of scientists, and very few of them seem to be motivated by the desire to prove religious people wrong. Most of them (and all of the good ones) seem motivated by curiosity and a desire to understand the world and universe around us. That, coincidentally, is the same impulse behind most of the religious people I know, as well.
Agreed. I'm also disappointed that so many people read the robot books (Caves of Steel, etc.) and don't realize that they should also read the Empire stories (Pebble in the Sky, etc.) and the Foundation series, since they make one big story arc.
Okay, this made me curious. I can see how it'd be horribly inefficient, but I'm not quite the astrophysicist as to see why it'd be flat out impossible. Could you explain?
The compiler generates binary code that is executed directly by the CPU, avoiding the intermediate process of compiling to bytecode and running in a virtual machine
The new compiler (you know, the one mentioned in the news item) doesn't say anything about being able to compile on one system and run elsewhere, but it uses gcc so it should be possible to target another architecture, in theory. Whether or not the Roadsend compiler supports that is another question.
I agree, this makes it hard to justify something besides PHP in a lot of situations.
It's too bad the compiler is $399 per year, and only currently available on Linux. If it was a little less, and not licensed annually, I'd be uninstalling a lot of other development tools right now.
The specific shell: protocol was pointed out as maybe dangerous one day before it was fixed (with just a configuration change, because that framework was already there).
Your post illustrates the problem in the framework that was created to address the problem. It depends on knowing which protocols are dangerous, which is impossible since any program can register a protocol handler. The root of the problem is the way Windows handles these protocols, but the way Mozilla dealt with that problem was, in hindsight, not the best solution. Let's learn from the mistake and move on, instead of pretending everything went perfectly.
This isn't a triumph of open source - it's an example of how open source falls prey to exactly the same problems closed source does. Except publically, so you can point to these discussions to demonstrate that they knew about the issues for two years.
The advantage to open source, in this situation, is that this is transparent and everyone can look in on the process. We can see, in hindsight, where the mistake was made (choosing a blacklist strategy instead of whitelist or user confirmation). And then we (the whole community, not just Mozilla) can try to avoid making the same mistake again.
My point is just that, in hindsight, it becomes obvious that the blacklist wasn't a complete solution, since it (by definition) only blocks those handlers known to be bad. Any new bad handler that comes along has to be added to the list. The proposed solution to prompt the user for confirmation of unhandled protocols (somewhere around comment #8) or the eventual implementation of a whitelist are both much better options.
That said, Mozilla is still the best game in town, and all I'm trying to say is that we ought to look at how the vulnerability stuck around so long, in the interest of improving an already excellent product.
I agree completely (see that, mods?). My point is just that since Mozilla has a transparent bug process, we (the open source community as a whole) ought to make use of the hindsight we now have and look at where the bug process let us down: specifically, when it was decided that a blacklist, rather than the whitelist that was eventually implemented, would be sufficient.
Where did you see that it showed up outside of SP2? All the article said was that it was reported on SP2 but could not be found on SP1. Did I miss something?
An additional issue allowing malicious sites to inject script into the Local Security Zone using anchor references has also been reported to affect Internet Explorer 6 running on Windows XP SP2 (release candidate / beta). This issue could not be confirmed on a fully patched Windows XP SP1 system.
So SP2, which is supposed to make Windows super-safe (even at the expense of backwards-compatibility in some case) may have actually introduced an IE bug.
On the Windows side of things, part of it (handling of the hcp:// protocol) was quietly patched with SP1, although too many protocol handlers are still allowed to do crazy things.
While I agree completely that the root cause of this bug is in Windows (you see that, whoever modded me flamebait?), I don't think that really excuses the Mozilla folks. In October of 2002, according to bugzilla, it was known that unsafe protocols were being passed to an OS that couldn't be trusted to handle them safely. Their solution was to put in a blacklist, which by definition only covers the bad protocol handlers they knew about, and waited until last week to put something in place that actually fixed the problem.
The 'bug report' opened at Mozilla in 2002 was essentially trying to deal with the way Mozilla handles unknown protocols. The normal way was just to pass them to the OS.
Did you even read the bug report? The link is:
http://bugzilla.mozilla.org/show_bug.cgi?id=1674 75 (you have to copy/paste and strip out the extra space, they disable links from/.)
Look at comment #11, which links to a duplicate bug. It was known in October of 2002 that it was possible for certain HTML to launch code locally. Yes, this was a result of passing unknown protocols to the operating system, which then handled them in an irresponsible manner. That doesn't change the fact that the Mozilla team just kept on trusting the OS to do the right thing. If they had allowed HTML like <img src="del c:\*.*"> to get through to Windows, would you also write that off as a bug in the OS?
Slashdot Mirror
That's not what I said at all. If you don't want to spend money on battery life, then don't. Buy a cheaper model with a smaller battery. But don't sit there and argue that nobody needs that functionality, just because you don't need it yourself.
If it can occur then it will occur, and given enough time it must occur.
I'm not even going to start on the huge problems with this way of thinking.
Part of the fascination is that we don't know if it's possible. We think that it might be, and the odds seem to be in favor of it, but we won't know for sure until we find some evidence of it. That's how science works.
It seems to me the only reason people are obessed with finding life on Mars, or anywhere else for that matter, is to fill some urge that if they do, to less scientific minded (read: religious) people will be proven wrong.
First, I think this is a false dichotomy, as if a God who created the Heavens and the Earth isn't capable of creating life in multiple places. See Out of the Silent Planet by C.S. Lewis.
Second, I've met a lot of scientists, and very few of them seem to be motivated by the desire to prove religious people wrong. Most of them (and all of the good ones) seem motivated by curiosity and a desire to understand the world and universe around us. That, coincidentally, is the same impulse behind most of the religious people I know, as well.
In other words, what you're saying is, "I don't think I'd ever need that functionality, so I don't believe anyone else will ever need it, either."
Not everyone lives their life within easy reach of an electrical outlet, and those who don't appreciate every extra bit of battery life they can get.
And surely there is no price variation from one part of the country to another, or from some stores (in the mall) to others (large retailers).
Agreed. I'm also disappointed that so many people read the robot books (Caves of Steel, etc.) and don't realize that they should also read the Empire stories (Pebble in the Sky, etc.) and the Foundation series, since they make one big story arc.
Okay, this made me curious. I can see how it'd be horribly inefficient, but I'm not quite the astrophysicist as to see why it'd be flat out impossible. Could you explain?
Au contraire:
Mach 10 = 3.4029 km/s
Max Earth-Neptune distance: 4,686,510,980 km
4,686,510,980 km / (3.4029 km/s) = 43.6421121 years
So, while he'd definitely not make it back in his lifetime (let alone the six minutes he spoke of), he could make it there in his lifetime at Mach 10.
You'd $like $the $RIAA $a $lot, $too, $if $you $saw $them $the $same $way $politicians $do.
You realize that you just inspired about two dozen Sourceforge projects, right?
The whole book is good, you should read it from the start.
The compiler generates binary code that is executed directly by the CPU, avoiding the intermediate process of compiling to bytecode and running in a virtual machine
That's a true native compiler to me.
The new compiler (you know, the one mentioned in the news item) doesn't say anything about being able to compile on one system and run elsewhere, but it uses gcc so it should be possible to target another architecture, in theory. Whether or not the Roadsend compiler supports that is another question.
It's too bad the compiler is $399 per year, and only currently available on Linux. If it was a little less, and not licensed annually, I'd be uninstalling a lot of other development tools right now.
Your post illustrates the problem in the framework that was created to address the problem. It depends on knowing which protocols are dangerous, which is impossible since any program can register a protocol handler. The root of the problem is the way Windows handles these protocols, but the way Mozilla dealt with that problem was, in hindsight, not the best solution. Let's learn from the mistake and move on, instead of pretending everything went perfectly.
The advantage to open source, in this situation, is that this is transparent and everyone can look in on the process. We can see, in hindsight, where the mistake was made (choosing a blacklist strategy instead of whitelist or user confirmation). And then we (the whole community, not just Mozilla) can try to avoid making the same mistake again.
My point is just that, in hindsight, it becomes obvious that the blacklist wasn't a complete solution, since it (by definition) only blocks those handlers known to be bad. Any new bad handler that comes along has to be added to the list. The proposed solution to prompt the user for confirmation of unhandled protocols (somewhere around comment #8) or the eventual implementation of a whitelist are both much better options. That said, Mozilla is still the best game in town, and all I'm trying to say is that we ought to look at how the vulnerability stuck around so long, in the interest of improving an already excellent product.
I agree completely (see that, mods?). My point is just that since Mozilla has a transparent bug process, we (the open source community as a whole) ought to make use of the hindsight we now have and look at where the bug process let us down: specifically, when it was decided that a blacklist, rather than the whitelist that was eventually implemented, would be sufficient.
Or just define dissenting opinion as an "annoyance", and then this system will cover that, as well.
Where did you see that it showed up outside of SP2? All the article said was that it was reported on SP2 but could not be found on SP1. Did I miss something?
Been reading Snow Crash again, have we?
An additional issue allowing malicious sites to inject script into the Local Security Zone using anchor references has also been reported to affect Internet Explorer 6 running on Windows XP SP2 (release candidate / beta). This issue could not be confirmed on a fully patched Windows XP SP1 system.
So SP2, which is supposed to make Windows super-safe (even at the expense of backwards-compatibility in some case) may have actually introduced an IE bug.
On the Windows side of things, part of it (handling of the hcp:// protocol) was quietly patched with SP1, although too many protocol handlers are still allowed to do crazy things. While I agree completely that the root cause of this bug is in Windows (you see that, whoever modded me flamebait?), I don't think that really excuses the Mozilla folks. In October of 2002, according to bugzilla, it was known that unsafe protocols were being passed to an OS that couldn't be trusted to handle them safely. Their solution was to put in a blacklist, which by definition only covers the bad protocol handlers they knew about, and waited until last week to put something in place that actually fixed the problem.
Did you even read the bug report? The link is:
http://bugzilla.mozilla.org/show_bug.cgi?id=1674 75 (you have to copy/paste and strip out the extra space, they disable links from /.)
Look at comment #11, which links to a duplicate bug. It was known in October of 2002 that it was possible for certain HTML to launch code locally. Yes, this was a result of passing unknown protocols to the operating system, which then handled them in an irresponsible manner. That doesn't change the fact that the Mozilla team just kept on trusting the OS to do the right thing. If they had allowed HTML like <img src="del c:\*.*"> to get through to Windows, would you also write that off as a bug in the OS?
Yeah, the bug was opened in 2002. Not quite "quickly fixed".