Because it's far easier, cheaper, and less error-prone to deploy a range of, say, spectroscopic sensors, which allow you to detect the by-products of life, rather than life itself. Moreover, even if life no longer exists on the planet, the by-products would remain. Therefore, a mission like this allows one to detect current conditions, as well as what happened in the past. Plus, these types of devices may provide more generally useful functions (eg, a spectrometer can be used by geologists to try and understand how Mars has evolved), rather than a microscope, which is rather limited in it's range of uses.
It would evaporate. IOW, vaporize. IOW, transition to gaseous form. This effect can actually be observed by boiling water at different altitudes. At sea level, water boils at around 100C. At higher altitudes, the boiling point is less, due to lower atmospheric pressure. Mars is just a really extreme case (ie, VERY low atmospheric pressure), and as such, the water would boil at a relatively low temperature. Possibly low enough that, rather than freeze on the surface, it would evaporate.
"Isn't that what commets are primarily composed of?"
Well, not exactly. Yes, water is present on comets. However, the H2O present on comets is primarily in a solid state. IOW, it's not fit to react with surrounding minerals (at least not in any sizeable quantities). So, yeah, it's perfectly reasonable to find trace amounts of water on Mars. However, the presence of large hydrated material deposits requires that this water be present in liquid form for relatively long periods of time.
Those who write software in the hope that users use it.
Yeah, sounds great. 'course, if I can't actually *write* the damned app because the toolkit isn't complete, or because it doesn't work on my (or my users') platform, or because I can't figure out how to use it because the documentation is all but non-existent, it makes the prettiness of the GUI a moot point, now doesn't it?
Maybe, but most *users* will chose a SWT app over a Swing one anytime.
Umm, I think you're missing the point. Who cares if users prefer SWT over Swing. The problem is that SWT will rarely be chosen by *developers* because 1) it's incomplete, 2) poorly documented, 3) buggy, and 4) difficult to deploy.
The main reason for Eclipse's success (and the demise of the other free IDEs) is that only Eclipse offers a pleasant GUI, which no Swing-based IDE can.
Actually, I disagree with this. Have you ever used JEdit? It's not my cup of tea (I prefer Emacs), however despite being a Swing app, it's remarkably capable and responsive.
Err, it's IBM's baby... if they wanted it used by the common man, they certainly have the resources to make it so. Meanwhile, I have better things to do.
While I do understand the role of Ogg, it does concern me, though, that we're talking about yet another plugin API layered into an existing API (like Gstreamer). Moreover, something like OggFile is really a duplication of effort. See, Gstreamer, for example, was designed specifically to allow things like demuxing container formats and autoplugging decoders for various media types. So, rather than writing this OggFile thing, including creating a whole new plugin API, etc, the developers could be working on creating nice decoder plugins for Gstreamer for the various codecs, and assisting in getting the autoplugging code in Gstreamer up to snuff (Spider works, just not perfectly yet).
Sorry, dude, but SWT is nowhere *near* as complete as Swing, in terms of functionality. I know, I've tried to use it. Basically, because SWT was designed more or less specifically with Eclipse in mind, it has massive gaps in it's APIs (for example, the imaging model is *severely* lacking). Worse, it's difficult to deploy, and even more difficult to use, as the documentation is remarkably incomplete. So, as much as I hate to say it, SWT simply can't replace Swing right now, and I don't expect it to any time soon.
Oh yes, that's absolutely true. However, the original contention was that most apps won't see any performance benefits from being converted to x86-64 apps, and this isn't true, simply due to the additional registers provided.
Actually, a simple recompile could provide additional performance, as the AMD-64 has a host of additional registers over and above the standard x86 set.
Hey, come on, now... don't you think you're being just a little overly critical?
Re:Validation and the GUI
on
XForms Essentials
·
· Score: 3, Insightful
No matter how much the browser will do, you still need to validate the entered information at the server.
Well of course. No one in their right mind would suggest that the client should do all the data validation, and the server none, for the exact reasons you gave. However, your argument is probably a little too strict, in that it is perfectly allowable to have a great deal of the data verification occur in the client, with the server only performing the final verification step before committing the transaction.
In addition, you gave the exact reason why client-side validation is good: it can "provide quick feedback to the user, and/or update GUI displays", which takes load off the server side and reduces the amount of network traffic involved in the transaction, while at the same time improving useability, since you don't have to make multiple transactions to perform every single operation the user might wish to perform.
You're telling me that one scream from one Elf in a 3 hour movie during a protracted battle scene "detracts from the movie"? Can we say "overly critical"?
Meh, just ignore it. There's always someone out there just waiting for the opportunity to show the world how big of an asshole they can be... and on Slashdot, they can do it without fear of being punched in the face, thus removing one of the most effective checks society has for dealing with these sorts people.
Regarding the usefulness of the other protection rings on the Intel, it would appear Linus doesn't quite agree with your assessment. To quote:
" I suspect that the _real_ answer is that ring 1/2 are just fundamentally useless, and it has nothing to do with x86 implementation semantics or anything else."
Why? If I created a very useful library and then chose to release it under the GPL, that means that I as the copyright holder do not want closed source applications making use of my work for some reason (perhaps I'm idealogically opposed to closed source software). What's wrong with that? I'm the author, after all, and it's up to me to decide how my work can be distributed. And if I wanted closed source apps to use my code, I'd release it under the LGPL.
Slashdot Mirror
Because it's far easier, cheaper, and less error-prone to deploy a range of, say, spectroscopic sensors, which allow you to detect the by-products of life, rather than life itself. Moreover, even if life no longer exists on the planet, the by-products would remain. Therefore, a mission like this allows one to detect current conditions, as well as what happened in the past. Plus, these types of devices may provide more generally useful functions (eg, a spectrometer can be used by geologists to try and understand how Mars has evolved), rather than a microscope, which is rather limited in it's range of uses.
It would evaporate. IOW, vaporize. IOW, transition to gaseous form. This effect can actually be observed by boiling water at different altitudes. At sea level, water boils at around 100C. At higher altitudes, the boiling point is less, due to lower atmospheric pressure. Mars is just a really extreme case (ie, VERY low atmospheric pressure), and as such, the water would boil at a relatively low temperature. Possibly low enough that, rather than freeze on the surface, it would evaporate.
"Isn't that what commets are primarily composed of?"
Well, not exactly. Yes, water is present on comets. However, the H2O present on comets is primarily in a solid state. IOW, it's not fit to react with surrounding minerals (at least not in any sizeable quantities). So, yeah, it's perfectly reasonable to find trace amounts of water on Mars. However, the presence of large hydrated material deposits requires that this water be present in liquid form for relatively long periods of time.
Wow. That, sir, was impressive.
Those who write software in the hope that users use it.
Yeah, sounds great. 'course, if I can't actually *write* the damned app because the toolkit isn't complete, or because it doesn't work on my (or my users') platform, or because I can't figure out how to use it because the documentation is all but non-existent, it makes the prettiness of the GUI a moot point, now doesn't it?
Maybe, but most *users* will chose a SWT app over a Swing one anytime.
Umm, I think you're missing the point. Who cares if users prefer SWT over Swing. The problem is that SWT will rarely be chosen by *developers* because 1) it's incomplete, 2) poorly documented, 3) buggy, and 4) difficult to deploy.
The main reason for Eclipse's success (and the demise of the other free IDEs) is that only Eclipse offers a pleasant GUI, which no Swing-based IDE can.
Actually, I disagree with this. Have you ever used JEdit? It's not my cup of tea (I prefer Emacs), however despite being a Swing app, it's remarkably capable and responsive.
Err, it's IBM's baby... if they wanted it used by the common man, they certainly have the resources to make it so. Meanwhile, I have better things to do.
While I do understand the role of Ogg, it does concern me, though, that we're talking about yet another plugin API layered into an existing API (like Gstreamer). Moreover, something like OggFile is really a duplication of effort. See, Gstreamer, for example, was designed specifically to allow things like demuxing container formats and autoplugging decoders for various media types. So, rather than writing this OggFile thing, including creating a whole new plugin API, etc, the developers could be working on creating nice decoder plugins for Gstreamer for the various codecs, and assisting in getting the autoplugging code in Gstreamer up to snuff (Spider works, just not perfectly yet).
Sorry, dude, but SWT is nowhere *near* as complete as Swing, in terms of functionality. I know, I've tried to use it. Basically, because SWT was designed more or less specifically with Eclipse in mind, it has massive gaps in it's APIs (for example, the imaging model is *severely* lacking). Worse, it's difficult to deploy, and even more difficult to use, as the documentation is remarkably incomplete. So, as much as I hate to say it, SWT simply can't replace Swing right now, and I don't expect it to any time soon.
OOC, how does this library fit in with existing multimedia architectures (I'm thinking Gstreamer, specifically, here)?
And what's your income level, Mr. High-Tech Slashdot poster?
The worst part is that it's a freakin' repost, too...
Oh yes, that's absolutely true. However, the original contention was that most apps won't see any performance benefits from being converted to x86-64 apps, and this isn't true, simply due to the additional registers provided.
Actually, a simple recompile could provide additional performance, as the AMD-64 has a host of additional registers over and above the standard x86 set.
Absolutely. Caffeine is an effective bronchodilator. As such, it's useful for asthmatics in a pinch if they don't have an inhaler around.
Hey, come on, now... don't you think you're being just a little overly critical?
No matter how much the browser will do, you still need to validate the entered information at the server.
Well of course. No one in their right mind would suggest that the client should do all the data validation, and the server none, for the exact reasons you gave. However, your argument is probably a little too strict, in that it is perfectly allowable to have a great deal of the data verification occur in the client, with the server only performing the final verification step before committing the transaction.
In addition, you gave the exact reason why client-side validation is good: it can "provide quick feedback to the user, and/or update GUI displays", which takes load off the server side and reduces the amount of network traffic involved in the transaction, while at the same time improving useability, since you don't have to make multiple transactions to perform every single operation the user might wish to perform.
You're telling me that one scream from one Elf in a 3 hour movie during a protracted battle scene "detracts from the movie"? Can we say "overly critical"?
Meh, just ignore it. There's always someone out there just waiting for the opportunity to show the world how big of an asshole they can be... and on Slashdot, they can do it without fear of being punched in the face, thus removing one of the most effective checks society has for dealing with these sorts people.
Damn, I hate ignorant American beer. It's bad enough it tastes like crap, but it's stupid, too!
Regarding the usefulness of the other protection rings on the Intel, it would appear Linus doesn't quite agree with your assessment. To quote:
" I suspect that the _real_ answer is that ring 1/2 are just fundamentally useless, and it has nothing to do with x86 implementation semantics or anything else."
Well, given that the platters in these things are significantly smaller, I suspect the effect isn't nearly as noticeable.
Damn... I'm wondering the same thing. I mean, honestly... WTF?
Then tell him and see if he'll relicense. *shrug*
Why? If I created a very useful library and then chose to release it under the GPL, that means that I as the copyright holder do not want closed source applications making use of my work for some reason (perhaps I'm idealogically opposed to closed source software). What's wrong with that? I'm the author, after all, and it's up to me to decide how my work can be distributed. And if I wanted closed source apps to use my code, I'd release it under the LGPL.