You're right in that temperature changes have happened before, and they will happen again.
That's all the more reason we shouldn't try to deny it's possible, and it's happening now. And we should do everything we can to NOT accelerate it artificially, even if underlying source is natural. In fact, we should consider trying to decelerate, if that's possible.
And you're right that life will probably survive whatever change (unless we end up in one of the extremes - like Venus and Mars) is coming, despite the reason.
But that doesn't mean it's good for us humans, we'll probably survive as a species, but even a small part of the globe becoming uninhabitable in a short period of time for one reason or another could cause mass-migrations, wars and starvations on a scale that would make WW2 look like few children at sandbox. It doesn't even take very big change to make very fragile political, economical and agricultural situations to become so different it could just as well be the end of the world from a viewpoint of modern western cultures.
I've installed a few HSF's on Athlon/Duron chips, and while you obviously should be fairly careful, it's not that easy to "crunch" the chip if the clip mechanism on the cooler is decent.
And on those that aren't, you can just feel it's needing more force than is healthy and a) try to do it anyway extra carefully or b) dump the pos and go buy something that isn't designed to murder your CPU.
1. The kjsembed library provides access to the existing objects with no (repeat *no*) need for the host app to write any extra code. ie. it can extend apps that were not intended to support this stuff (though obviously it is better if they are).
If the bindings are already there, why couldn't this be extended to another language as well?
2. A huge proportion of kde apps already link kjs via either khtml or via kdeinit. This adds no extra overhead (rather than a large python interpreter).
Python can work as a shared library rather than separate executable, windows version does this, mac too, but dunno if there are any Linux implementations around.
3. We would have huge version skew problems because the distros (and users) would immediately rip out the chosen version of python and link the code against their default installed one. This would lead to impossible to track down bugs.
4. Most of the stuff that people use from the python libs is already available from the kde libs. By providing bindings to those we get better integration with things like cookies, cache handling etc. as well as a very low overhead in terms of type conversions.
Solution for problem 2 addresses this automatically, if you ship your own python as a library or inside kdelibs, it's not going to be replaced very easily. And there's no need to include parts of the standard library you don't need, as long as it's possible to import them from some other source if user wants to do so.
"Sexyness" may or may not be necessary in a portable mp3 player depending on who you ask, but sleekness damn certainly is.
Have you seen that 20GB backpack they have for Neuros? It's enormous. No, I don't mean the disk space, I mean the physical size. And probably weights a ton as well. If I want something the size of dinosaur and expandable, I'll buy a laptop thank you very much.
If, on the other hand, I want portable mp3 player, I'll take something small and lightweight.
Would be nice, of course, but that kind of money will be daaaamn hard to come by these days.
Maybe one day, but probably not before we have a big-ass camera on the orbit to point out truely safe landing sites and maybe even few human operators on that side of the solar system orchestrating the thing.
Well, maybe the Chinese can get anyone else to crap their pants and kick-start western space exploration again...
I realize that the beagle had a shoestring budget compared to NASA, but I don't understand is why no testing of the reentry system?
They just didn't have time.
The Beagle was a very late add-on, and not only a shoestring budget but it was also built very fast, if they'd thoroughly tested every system they would not have finished it by the time launch window closed.
Yeah, they are rocket scientists, but they are not successfull rocket scientists yet. NASA, the USAF, the Soviets, and the Chinese had their share of tests that malfunctioned spectacularly, but they learned and continued on.
As for you implying that the others had few failed missions early on and then "learned" to make them never blow again, well, frankly, that's bollocks. I don't need to reminder you that the two last NASA Mars missions before the current ones failed.
The Russians have a particularly earth (mars?)-shattering record of 14 failures to 16 missions, and even those two worked only partially and for a very short time.
There are some things you can learn from, but right now, the success of a cheap Mars mission is just as much dependent on pure old fashined luck as it is from anything else. And the combined success rate is fifty-fifty, if even that!
Continued on? Sure. What makes you think we don't continue on and try again?
And they probably did consult with Russians. And everyone else.
If you think it's not good, then pick up the gimp and draw better one. If you do it good enough, they'll probably even implement.
And why on earth should a FILE SELECTOR be somehow awe inspiring? What should it do, if not provide clean and useful interface for... err... ah, yes, selecting files, that was it.
Volume is not all, though, something with bit more thickness and more squarish shape can still feel lot smaller than very "long" ipodmini, even if it's actually larger.
The same holds especially true for Karma vs. iPod, it's 8.9 vs. 7.1 but damn me if it still looks lot smaller. And probably feels as well, though I havent held either.
Er. You're getting the 94xx series processors and 97x-series processors confused. Yes, the Opteron runs neck and neck with G4 servers.
Err. No, I'm not. And Opteron (or any other current generation x86'ish chip) does not run anywhere near neck and neck with G4 servers, they run way faster.
The G5 has a massively different system architecture, and you cannot say "because it beats G4s it'll beat G5s".
I'm well aware of the fact that G5 is a new system and haven't drawn that kind of conclusions.
Real-world tests of Opteron servers has shown them to be very strange beasts. Freakishly fast as some tasks, very slow at others.
From anything I've seen this far, more like: freakishly fast on most tasks, pretty average on others, and by no means slow on anything.
I'd accuse AMD of pulling the old graphic card scam - benchmarks run very fast even though real world differences are minimal - but dear lord, that would be a hellishly expensive scam to pull off.
Graphics card scams are done on drivers or by "optimizing" the benchmark software in question. And usually they get faster results by leaving out some computations that are not visible, that's impossible on general purpose CPU. And you don't have any "drivers" to do it either, nor can you make benchmarkers use your own optimized software.
No, there's no scam here.
I run an AthlonXP and steer people towards AMD systems left and right, but the Opteron is proving to be a very odd design.
How, and why exactly? Opteron is a rather conservative incremental design on Athlon core, nothing radically new except for the 64-bitness.
And as thus, it's not really even "version 1.0"
BTW, when calling someone to the mat for making blanket untrue statements, just contradicting their statement for not providing references isn't enough, unless you provide them yourself. It's a case of he-said she-said, and frankly, your word amounts to a hill of beans to me (as does the other guy).
I've got better things to do than try to prove someone like grandparent who has already made up his mind and won't listen to anyone, no matter the truth. Especially as it really is damn hard to find trustworthy results, any credible sources haven't touched this debate with a 10-foot pole.
But if you wish. Let's start with some SPECmark tests, you know the same Apple used to claim G5 was faster than anything else at the launch (Opteron scores were mysteriously missing, and they've later been accused of tampering with P4 scores as well).
So lookee what we have here. Dual G5 can barely hold it's own against single Opteron at rate tests and is completely decimated in base tests. I won't bother with dual opteron numbers, but they scale well and leave G5 behind every time. They're at spec.org for everyone to see.
So... ok, now you're probably yeah, sure, nice set of numbers but what about real world applications? Well. The fact still stands there aren't many, or any benchmarks out there that I trust but let's dig some of the trash anyway.
So there is no equivilent hardware on the x86 side.
Usually that kind of blanket statements are supported by some kind of evidence.
You don't have any, and you don't find any, because it's simply just not true - the two are very comparable in performance, and usually it's the opteron that has slight edge instead of other way.
Changing the opinions of general public and the political climate needs quite a bit more than mere inspiration. In 16th century you could do anything to anyone and get away with it, but things just don't work that way any more.
It'll happen, eventually, when someone more pragmatic about these things than western government agency does it - be it the Chinese or corporations - and people start to realize they're being left behind while others reap the benefits.
Because combined wattage of power supply means nothing, and they need to make absolutely sure it works or get a bad name for being "unstable" even if the real reason is bad PSU.
So the recommendation needs to be geared for maximum load of worst-case scenario with a lousy power supply that may even lie about the specs and plenty of high-draw components. And then inflated a bit to make sure.
That's quite invidual. For some of us, getting lock on parallel is very easy and even fast, while getting a focus while cross-eyed is nigh impossible.
Though there are limits, and the bigger the picture the harder it gets, at some point it's just impossible to get eyes any more separated - crossing supposedly allows for a bigger maximum size.
Not only does parallel not give you headache, but it might even prevent or soothe headache from other reasons.
After all, the whole focusing in distance and relaxation of eye muscles is what you're supposed to do every now and then to prevent some of adverse effects of focusing on monitor few inches away for hours.
Is the long initial KDE startup time because GNOME has already started at login/startx, while KDE must start when its first app calls it?
Yes, that's probably the biggest part of it. KDE apps start kdeinit and need to load QT libraries when they're first started, if there's not already something else using them.
How about starting KDE in the background after GNOME offers an environment, while the other startup apps are starting?
That would help, but it eats up quite a bit of memory, and slows down the already rather lengthy boot process as a whole while we don't even know if any KDE apps will be started.
The problem with middle layer is that it always needs to be compatible with lowest common denominator.
And there already is such a system, it's called wxWindows. Too bad it suffers from the same problem, you can't do a lot of things GTK or QT allows because they also need to cater for the other(s) (like win32)
Reverse would be nice though... too bad starting first KDE app from Gnome will still take 10 seconds on even a modern machine. And probably vice versa.
/.'ers always froth when someone EOL's - even if it's Linux distro.
Actually, they were WAY more rabid about RedHat EOL than they are bashing Microsoft on this one.
And Windows 98 IS a bad os, there's no question about that, but it just happens there's not much else for that particular niche. Bad is better than nothing, which is why many people here ran it on their parent's smallish systems, that can't handle anything more modern.
The setting may have a bit misleading name, but it's not universal, it only matters when opening links in new tabs. If you just normally left-click on links they do open up normally in same window/tab you're in.
If you control-click or middle-click on them, they open as background tabs.
If you shift-control-click on them, they open in a new tab and focus into it.
And open in new window is still available from the context menu... is there still something missing?
Slashdot Mirror
You're right in that temperature changes have happened before, and they will happen again.
That's all the more reason we shouldn't try to deny it's possible, and it's happening now. And we should do everything we can to NOT accelerate it artificially, even if underlying source is natural. In fact, we should consider trying to decelerate, if that's possible.
And you're right that life will probably survive whatever change (unless we end up in one of the extremes - like Venus and Mars) is coming, despite the reason.
But that doesn't mean it's good for us humans, we'll probably survive as a species, but even a small part of the globe becoming uninhabitable in a short period of time for one reason or another could cause mass-migrations, wars and starvations on a scale that would make WW2 look like few children at sandbox. It doesn't even take very big change to make very fragile political, economical and agricultural situations to become so different it could just as well be the end of the world from a viewpoint of modern western cultures.
So pretty much everyone, not only some, now count dogs as a subspecies of gray wolf (Canis lupus).
I've installed a few HSF's on Athlon/Duron chips, and while you obviously should be fairly careful, it's not that easy to "crunch" the chip if the clip mechanism on the cooler is decent.
And on those that aren't, you can just feel it's needing more force than is healthy and a) try to do it anyway extra carefully or b) dump the pos and go buy something that isn't designed to murder your CPU.
So does the potentially excellent but damn buggy Temple of Elemental Evil
1. The kjsembed library provides access to the existing objects with no (repeat *no*) need for the host app to write any extra code. ie. it can extend apps that were not intended to support this stuff (though obviously it is better if they are).
If the bindings are already there, why couldn't this be extended to another language as well?
2. A huge proportion of kde apps already link kjs via either khtml or via kdeinit. This adds no extra overhead (rather than a large python interpreter).
Python can work as a shared library rather than separate executable, windows version does this, mac too, but dunno if there are any Linux implementations around.
3. We would have huge version skew problems because the distros (and users) would immediately rip out the chosen version of python and link the code against their default installed one. This would lead to impossible to track down bugs.
4. Most of the stuff that people use from the python libs is already available from the kde libs. By providing bindings to those we get better integration with things like cookies, cache handling etc. as well as a very low overhead in terms of type conversions.
Solution for problem 2 addresses this automatically, if you ship your own python as a library or inside kdelibs, it's not going to be replaced very easily. And there's no need to include parts of the standard library you don't need, as long as it's possible to import them from some other source if user wants to do so.
"Sexyness" may or may not be necessary in a portable mp3 player depending on who you ask, but sleekness damn certainly is.
Have you seen that 20GB backpack they have for Neuros? It's enormous. No, I don't mean the disk space, I mean the physical size. And probably weights a ton as well. If I want something the size of dinosaur and expandable, I'll buy a laptop thank you very much.
If, on the other hand, I want portable mp3 player, I'll take something small and lightweight.
Would be nice, of course, but that kind of money will be daaaamn hard to come by these days.
Maybe one day, but probably not before we have a big-ass camera on the orbit to point out truely safe landing sites and maybe even few human operators on that side of the solar system orchestrating the thing.
Well, maybe the Chinese can get anyone else to crap their pants and kick-start western space exploration again...
I realize that the beagle had a shoestring budget compared to NASA, but I don't understand is why no testing of the reentry system?
They just didn't have time.
The Beagle was a very late add-on, and not only a shoestring budget but it was also built very fast, if they'd thoroughly tested every system they would not have finished it by the time launch window closed.
Yeah, they are rocket scientists, but they are not successfull rocket scientists yet. NASA, the USAF, the Soviets, and the Chinese had their share of tests that malfunctioned spectacularly, but they learned and continued on.
As for you implying that the others had few failed missions early on and then "learned" to make them never blow again, well, frankly, that's bollocks. I don't need to reminder you that the two last NASA Mars missions before the current ones failed.
The Russians have a particularly earth (mars?)-shattering record of 14 failures to 16 missions, and even those two worked only partially and for a very short time.
There are some things you can learn from, but right now, the success of a cheap Mars mission is just as much dependent on pure old fashined luck as it is from anything else. And the combined success rate is fifty-fifty, if even that!
Continued on? Sure. What makes you think we don't continue on and try again?
And they probably did consult with Russians. And everyone else.
Funny mods don't boost karma.
If beta versions of longhorn will have good enough file selectors that it should be copied, then sure, someone will probably do it. Which is good.
Nothing bad in "ripping off" working designs.
And this has been ripped of from mac and kde just as much if not more as it has from windows.
If you think it's not good, then pick up the gimp and draw better one. If you do it good enough, they'll probably even implement.
... err... ah, yes, selecting files, that was it.
And why on earth should a FILE SELECTOR be somehow awe inspiring? What should it do, if not provide clean and useful interface for
Volume is not all, though, something with bit more thickness and more squarish shape can still feel lot smaller than very "long" ipodmini, even if it's actually larger.
The same holds especially true for Karma vs. iPod, it's 8.9 vs. 7.1 but damn me if it still looks lot smaller. And probably feels as well, though I havent held either.
Er. You're getting the 94xx series processors and 97x-series processors confused. Yes, the Opteron runs neck and neck with G4 servers.
Err. No, I'm not. And Opteron (or any other current generation x86'ish chip) does not run anywhere near neck and neck with G4 servers, they run way faster.
The G5 has a massively different system architecture, and you cannot say "because it beats G4s it'll beat G5s".
I'm well aware of the fact that G5 is a new system and haven't drawn that kind of conclusions.
Real-world tests of Opteron servers has shown them to be very strange beasts. Freakishly fast as some tasks, very slow at others.
From anything I've seen this far, more like: freakishly fast on most tasks, pretty average on others, and by no means slow on anything.
I'd accuse AMD of pulling the old graphic card scam - benchmarks run very fast even though real world differences are minimal - but dear lord, that would be a hellishly expensive scam to pull off.
Graphics card scams are done on drivers or by "optimizing" the benchmark software in question. And usually they get faster results by leaving out some computations that are not visible, that's impossible on general purpose CPU. And you don't have any "drivers" to do it either, nor can you make benchmarkers use your own optimized software.
No, there's no scam here.
I run an AthlonXP and steer people towards AMD systems left and right, but the Opteron is proving to be a very odd design.
How, and why exactly? Opteron is a rather conservative incremental design on Athlon core, nothing radically new except for the 64-bitness.
And as thus, it's not really even "version 1.0"
BTW, when calling someone to the mat for making blanket untrue statements, just contradicting their statement for not providing references isn't enough, unless you provide them yourself. It's a case of he-said she-said, and frankly, your word amounts to a hill of beans to me (as does the other guy).
I've got better things to do than try to prove someone like grandparent who has already made up his mind and won't listen to anyone, no matter the truth. Especially as it really is damn hard to find trustworthy results, any credible sources haven't touched this debate with a 10-foot pole.
But if you wish. Let's start with some SPECmark tests, you know the same Apple used to claim G5 was faster than anything else at the launch (Opteron scores were mysteriously missing, and they've later been accused of tampering with P4 scores as well).
SPECint_base 2000:
Dual G5 2.0GHz - 800
Opteron 148 (2.2GHz) - 1304
Opteron 146 (2.0GHz) - 1115
SPECint_rate_base 2000:
Dual G5 2.0GHz - 17.2
Opteron 148 (2.2GHz) - 15.1
Opteron 146 (2.0GHz) - 12.9
SPECfp_base 2000:
Dual G5 2.0GHz - 840
Opteron 148 (2.2GHz) - 1505
Opteron 146 (2.0GHz) - 1217
SPECfp_rate_base 2000:
Dual G5 2.0GHz - 15.7
Opteron 148 (2.2GHz) - 17.5
Opteron 146 (2.0GHz) - 13.6
So lookee what we have here. Dual G5 can barely hold it's own against single Opteron at rate tests and is completely decimated in base tests. I won't bother with dual opteron numbers, but they scale well and leave G5 behind every time. They're at spec.org for everyone to see.
So... ok, now you're probably yeah, sure, nice set of numbers but what about real world applications? Well. The fact still stands there aren't many, or any benchmarks out there that I trust but let's dig some of the trash anyway.
(mostly) favoring opteron:
http://www.pcmag.com/article2/0,4149,1274637,00.as p
http://www.pcworld.com/news/article/0,aid,112749,p g,8,00.asp
vastly favoring G5:
http://www.barefeats
Opterons are MUCH slower than G5s.
So there is no equivilent hardware on the x86 side.
Usually that kind of blanket statements are supported by some kind of evidence.
You don't have any, and you don't find any, because it's simply just not true - the two are very comparable in performance, and usually it's the opteron that has slight edge instead of other way.
... is it hideously expensive, it's also butt ugly compared to the original iPod and just about everything else out there.
Or at least so it seems, of course it might be that those pics just don't "catch" it and it's better IRL.
Oh well.
Changing the opinions of general public and the political climate needs quite a bit more than mere inspiration. In 16th century you could do anything to anyone and get away with it, but things just don't work that way any more.
It'll happen, eventually, when someone more pragmatic about these things than western government agency does it - be it the Chinese or corporations - and people start to realize they're being left behind while others reap the benefits.
Because combined wattage of power supply means nothing, and they need to make absolutely sure it works or get a bad name for being "unstable" even if the real reason is bad PSU.
So the recommendation needs to be geared for maximum load of worst-case scenario with a lousy power supply that may even lie about the specs and plenty of high-draw components. And then inflated a bit to make sure.
That's quite invidual. For some of us, getting lock on parallel is very easy and even fast, while getting a focus while cross-eyed is nigh impossible.
Though there are limits, and the bigger the picture the harder it gets, at some point it's just impossible to get eyes any more separated - crossing supposedly allows for a bigger maximum size.
Not only does parallel not give you headache, but it might even prevent or soothe headache from other reasons.
After all, the whole focusing in distance and relaxation of eye muscles is what you're supposed to do every now and then to prevent some of adverse effects of focusing on monitor few inches away for hours.
Is the long initial KDE startup time because GNOME has already started at login/startx, while KDE must start when its first app calls it?
Yes, that's probably the biggest part of it. KDE apps start kdeinit and need to load QT libraries when they're first started, if there's not already something else using them.
How about starting KDE in the background after GNOME offers an environment, while the other startup apps are starting?
That would help, but it eats up quite a bit of memory, and slows down the already rather lengthy boot process as a whole while we don't even know if any KDE apps will be started.
The problem with middle layer is that it always needs to be compatible with lowest common denominator.
... too bad starting first KDE app from Gnome will still take 10 seconds on even a modern machine. And probably vice versa.
And there already is such a system, it's called wxWindows. Too bad it suffers from the same problem, you can't do a lot of things GTK or QT allows because they also need to cater for the other(s) (like win32)
Reverse would be nice though
SCO?
No. SCO has not taken any derivative work claims to court, they're just yapping their mouth, trying to spread FUD and get their stocks high.
Their case against IBM is a contract violation, not copyright.
/.'ers always froth when someone EOL's - even if it's Linux distro.
Actually, they were WAY more rabid about RedHat EOL than they are bashing Microsoft on this one.
And Windows 98 IS a bad os, there's no question about that, but it just happens there's not much else for that particular niche. Bad is better than nothing, which is why many people here ran it on their parent's smallish systems, that can't handle anything more modern.
Or FB 7.0, then it'd be one version ahead of IE, and it's certainly more than good enough to warrant that.
The setting may have a bit misleading name, but it's not universal, it only matters when opening links in new tabs. If you just normally left-click on links they do open up normally in same window/tab you're in.
If you control-click or middle-click on them, they open as background tabs.
If you shift-control-click on them, they open in a new tab and focus into it.
And open in new window is still available from the context menu... is there still something missing?