Any of the newer BSD licenses is GPL compatible, so you can relicense it to the GPL as you please, no permission necessary. This is the same as a company "stealing" the code and selling it in a commerical product.
GPLing BSD code doesn't really "protect" it though. You can't strip the copyright notice off, so anyone that wants to use it can find out where it came from and grab the original to use however they like. It protects any changes made to the GPLed version, but those changes can't be released into the BSD licensed original either.
a) While MacOS X libraries are from FreeBSD, Darwin (the kernel) is Mach derived and has very little to do with the FreeBSD kernel. The same tricks might work if they were ported, but that would be more of a rewrite with the same concepts rather than a port.
b) Who in their right mind uses MacOS X for routing? Serving, fine, but actual network infrastructure? I highly doubt it.
-Xinerama switched from being compiled in by default to being a compile time option that had to be specified in make.conf. I don't see a reasonable way I could have known that, at least not without spending hours and hours every week tracking changes.
-There was a week or so where KDE would not compile because it required a tool that was masked. The only possible way for this bug to slip through was if no one had tried to compile it on a stable system before releasing it, not even once. I don't see a reasonable way I could have avoided this, as I actually did check the forums pretty extensively before I sync'd.
-There has been a persistent problem where the second head on my computer is not initialized properly, causing the image to shake. This happened with XFree86 and X.org after the transition. I have no idea what causes it, but Suse, Fedora, Slackware, FreeBSD, and OpenBSD don't have the problem. They all used the same version of XFree86 that had the problem under Gentoo. I have yet to figure this one out, and probably never will.
-The 2004.0 and 2004.1 LiveCDs just plain wouldn't boot on my computer, or would crash soon after boot. I don't have weird hardware. I don't see any way I could be responsible for this.
In short, Gentoo is very powerful but I neither have the time nor the inclination to spend the kind of time required to keep it working. You will note, however, that some of the other OSes I tried (Slackware, FreeBSD, OpenBSD) do very little in the way of handholding. If I were simply an inept user, it's doubtful I could get those working properly.
Yeah... except it's better not to use Gentoo at all.
I shouldn't say that. It's better not to use Gentoo if you like to have a system that works after your updates more than, oh, 9 times in 10.
I used Gentoo for almost a year total (most recently in august of this year). Compile-time options change without notice, major and easy to spot bugs slip through on a regular basis, and when something like KDE gets updated, it can be a week before things work again. That is, when you can get YOUR config files updated when you're not even sure it's something you did wrong.
I figure Suse Pro paid for itself in about a weekend in the time I saved. Would you believe that not a single update has broken anything yet! What a concept./yes I'm bitter, but it's all true
Re:Nuclear has nothing to do with oil !
on
China Goes Nuclear
·
· Score: 1
To a certain extent, they are interchangable. If we're looking at a 50 year timeframe, there will be electric cars, and I think it's assumed there will be a lot of public transport, where nuclear is useful. Also, it's possible to convert coal into a something that can usefully replace oil in a lot of ways.
At the end of the day, while they are not perfectly interchangable, they do overlap a bit, and thus an increase in the price of one will make the others more attractive and cause people to look at the alternatives.
You clearly lack an understanding of the system. While it does affect the headers, a) sending the whole message first doesn't make any difference on bandwidth, it's just bits in the pipe, and the size of the signature is constant no matter where it is, and b) they're headers. They're sent first.
The message is stored on the server (exactly as was done previously), and a signature is computed for the message. The public key is distributed by DNS, which is a) quite secure and b) extremely bandwidth efficient.
"standards" that aren't acceptable to the general hacker population of the Internet aren't standards.
Yahoo!'s DomainKeys is free and technically superior, and it's not mutually exclusive with SenderID. That means it will end up all the mail-related software except Microsoft stuff. Now who's the standard?
I don't entirely agree with this. Some bills are a PITA to pay without a credit card. Just don't put anything on it that you can't pay back the moment you use it. In fact, I like to send them money before I even get the bill, just so I can't spend money I don't have.
Most months I've paid it off to the last cent before I even get the bill.
My P4 does just fine with the Intel OEM cooler with "emerge world" (basically, 100% CPU usage for 10 hours). Pretty quiet too, and I've taken no special care to make it quiet.
Well, it did just fine before I smote every last vestige of Gentoo from my system in a fit of incandescent rage because it had broken itself one too many times.
"Sorry, I live in a 64-bit world, to the point that I'm quite ignorant of X86 state of the art. I've been blindly (and wrongly) assuming a 64-bit context for this whole conversation."
Indeed.:)
These chips will probably all have the x86-64 extensions, so they are 64-bit chips. Chips with these extensions have been on the market for over a year, first from AMD and soon from Intel.
In the very high end market, very different tradeoffs are very clearly in effect. I'm not sure about die sizes, but there's that POWER 5 from IBM with 4 dual-core dies, each with IBM's version of hyperthreading and 144 megabytes (!) of cache. That might even be 130 nm, I forget.
"Unfortunately, most of what I know about Itanium I really can't talk about, other than in very general terms -- assuming I wish to remain employed, that is.:)"
Well, "Itanium is better a instruction level parallelism than x86." is not a statement I need you to confirm. Also... it's better than POWER.
"The "sweet spot" for cache size is really determined by a race between core performance, and memory latency/bandwidth. Doubling cores doubles the data production/consumption rate. Doubling the frequency also does. The former is less demanding on memory latency and mostly requires more bandwidth. The latter is equally demanding on both. If you double the data production/consumption, and keep the same memory/bus bandwidth, ideally, you'd like to halve the cache miss rate -- but that's pretty unlikely in practice. That's why caches keep growing (at least in the 64-bit world). There is a point of diminuishing returns, because there's an upper limit to both temporal and spacial locality, but we're not quite there yet for Itanium."
This is true... but from watching Intel for the last few years, they have had nothing but trouble getting any gains past the 3.2 ghz chips. They were stuck there for a long time, and they've only got it up to 3.6 ghz now. AMD has been doing well, but when their clock speeds get much faster, they might well begin hitting the same problems. At that point, adding a core is probably the easiest way to increase data production/consumption at all, even if memory bandwidth/latency becomes more of a bottleneck.
"When more CPUs start to have integrated memory controllers and point-to-point links instead of multi-drop busses, I predict that cache sizes per core will actually decline for a while, since the memory performance side of the balance will lower the "sweet spot". After that, caches will probably creep slowly upwards again, because no memory or interconnect technology ever scales fast enough to keep up with CPU core performance scaling."
Your statements make more sense now, if you've not been keeping up with x86. The AMD Athlon 64s and Opterons all have intergrated memory controllers, and in mutli-CPU systems, they use CPU-to-CPU links. They scale up to 8 CPUs with up to several TB of memory...
"So the $64 question is... When cache sizes per core start to decline or level off, will we see smaller die, or will we see even more cores per die? The way Intel seems to always position Itanium for high-end heavy metal, I expect huge die with more cores, although for X86 they went the other way. Or so I infer from your posting."
Probably both, some for low end value computers, and the dual cores for high end machines. Or middle end machines by your standards.
"Not sure which CPU you're referring to here. Is it something in the X86 line? If you're taking a single core power and multiplying by two, then you may be very pleasantly surprised. Montecito, despite having two cores, will have significantly lower total power than its single-core predecessors. (That much I can safely reveal, because it seems to be common knowledge already.)
Having designed systems, I can tell you that difficulties arising from high power-per-socket are very non linear: 200W isn't merely twice as hard to deal wi
FreeBSD has a large base install so nobody needs to fuck with it. Fucking with it negates many of the advantages of using FreeBSD. There are very few cases where fucking with it is worth the effort. In the vast majority of cases where something smaller is needed, something like Slackware is appropriate. In fact, Slackware has zipslack, a distribution optimized for what you're trying to do. Why ignore a ready made solution?
Learning the FreeBSD way includes just installing more than you need and forgetting about it because it doesn't matter. You're wasting less than a dollar's worth of disk space. Your time is worth more than that. Trying to trim the base install is premature optimization unless you already know it really well.
Premature optimization is a Siren's song, and a very powerful one. Just look at all the Gentoo people that can't install a security patch without breaking the world because of premature optimization.
Don't listen to it. FreeBSD can't be all things to all people, and it's a waste of time to try to make it that way. If you do need small, use something meant for it.
"I have no first-hand knowledge of AMD, but for Itanium, smaller process geometries do not increase yield through smaller die size. As they've shrunk to smaller geometries, they have not shrunk die size at all. All the extra real estate goes into larger caches, and the die size, and thus the (raw) yield, remains about the same. They have improved yield, but it's not through shrinking the die."
Right, but there comes a point where "more cache more cache!" just doesn't improve your performance anymore. The trivial case is where cache size equals memory size, and your hit probability is 1.
Note that cache sizes have fluctuated around 256-512 kb since the P2 days. My P2 and P4 both have 512 kb. I'd be shocked if the reason was something other than that being a sweet spot. They're moving to 1 mb now, but that just means they've got more transistors and they don't have worthwhile uses for them in the core. It's diminishing returns, but there's still returns.
But if another core can increase instruction throughput nearly twofold while completely bypassing hard problems like increasing the parallelism in one core, and without increasing die size too much because of the new smaller process, then it makes sense. Itanium is vastly better at extracting parallelism from its instructions because that was the primary design goal, so another core takes more for it to be worth it, and additional cache makes sense.
If x86 stays in the sweek spot at 512 kb but doubles the instruction throughput with two cores, that's a big win.
Of course, I'm no more thrilled with a 200 watt CPU than anyone else, but that's what you get with a two CPU system anyway.
"OEMs will happily pay well over double for a 2-core vs 1-core because of the savings they will make elsewhere in the system. Dual-core also gives system vendors much more flexibility by allowing the same board design to support twice as wide a range of CPU counts."
It would make me happy building my own system too.:)
"Packaging and testing, sure. But overall cost of 1-dual vs 2-single isn't as clear. Big die are expensive -- they require more costly fab techniques, and result in low yield. Beyond a certain size, the loss in yield is just huge."
Correct.
Amazing, then, that Intel and AMD are talking about going dual core as they start producing chips with 90 nm and smaller technology. It's almost as if they've reached some kind of break even point, where the probability of a defect on a dual core die falls to the point where the gains outweigh the losses.
"Bottom line: for equivalent complexity and cache size, I seriously doubt that it's any cheaper to produce one dual-core chip compared to two single-core ones, knowing how sensitive IC economics are to yield."
"Is this true? Does Intel put a 3GHz label on 1.5GHz dual/core CPU's"
No. One core running at 3 ghz working with two different streams of instructions so it looks like two processors. They must contend for resources, so each is slower by itself than the single stream you have with hyperthreading disabled, but together they get more work done overall when working on some tasks. Sometimes hyperthreading makes things worse.
Dual core is a completely different idea. Basically, they print two processors onto the same hunk of silicon and it's cheaper to manufacture than two seperate processors because all the other costs like packaging it and testing it stay the same.
Hyperthreading is not a better solution, particularly when dealing with the Intel implementation. Unless it's very carefully done, all it does is keep the cache from working effectively. Linux and FreeBSD actually got performance improvements from leaving one of the virtual processors idle when there were more processes scheduled to run. When there's two threads of the same process, they let them both run because those tend to have better locality of reference and therefore don't thrash the cache so much.
Processor designers are in a different situation now than 10 years ago. They've got more transistors than they know what to do with, so adding cache and adding another core are cheap. Streamlining one core to run faster is much harder, as evidenced by Intel's unending troubles with anything faster than 3.2 ghz.
"enterprise-class" is a moving target. Look at Solaris 10 for examples of things Linux cannot do. Hotpluggable everything (ZFS can do things no one else can), massively redundant, lots of checksumming everywhere, etc. Stuff that Linux doesn't have.
The place to debate the merit of those things is not here, and as someone will point out if I don't say it, SCO's UNIX can't do those things, nor can Windows.
"I recently looked at some straonomy pictures and saw images of galaxies far far away where you could see individual stars. Surely these galaxies are so very far away that they would cover no more of the sky than a star that is only a few lightyears away would? So why can we get such good images of them but not of individual nearby stars or planets?"
Unfortunately this is not so.
The angular size of a star is much smaller than the angular size of (say) the Andromeda Galaxy, which probably makes up a majority of the non-Milky Way pictures of galaxies that most people see.
A star is usually tens to hundreds of thousands of km across. There are a few exceptions, but for the most part this is true. A galaxy is tens to hundreds of thousands of light years across. That's about 10000000000000 times larger. However, a galaxy like Andromeda is less than a 100000 times more distant than they stars we're talking about. Therefore, we can see significant internal detail.
Resolution isn't wasn't necessary to make this technique work. Even the best telescopes have trouble detecting stars as more than point sources.
What matters is the quantity of light recieved per unit time. With the proper equipment on the end, even a small telescope can accurately measure very precisely the amount of light it recieves. I imagine the tricky part is eliminating other factors such as local environmental conditions.
Where does the helium we put in baloons come from? Natural gas wells where it collects from decaying uranium and thorium. Those things are what keep the Earth's core hot. Vast quantities of these things are released every day by coal plants.
I'm not saying we can just replace coal power trivially, but we should be working towards that as a goal. I'm also not saying fission power is perfect either, but a well maintained nuclear plant causes less radioactivity in the environment than a coal plant of similar power output, and as the isotopes released have basically unlimited half-lives (4.5 b.y. for uranium and 14 b.y. for thorium, which are essentially forever to humans), the problem will last a lot longer.
Ultimately, neither is acceptable, and we should be doing our best to replace them both as soon as we can do it without bankrupting the world.
While it lacks CPAN, Python modules for various things are easy to find with Google. It's a little more annoying, but having a language that's not annoying makes up for it very quickly.
Slashdot Mirror
Keeping it running for a month isn't the problem. Keeping it running in a major transition (eg KDE 3.1 -> 3.2 or XFree86 -> X.org) is the problem.
That, and the random bugs that get thrown in from time to time that you may not even notice.
You might need something else if you want a decent firewall... but no stateful firewall is going to give you an Mpps. There's just no way.
Okay, well I was clearly wrong about what I said. Thanks to all the corrections (3 of them as of now.).
Still-- I don't know anyone that uses MacOS as a router that will see an Mpps.
Any of the newer BSD licenses is GPL compatible, so you can relicense it to the GPL as you please, no permission necessary. This is the same as a company "stealing" the code and selling it in a commerical product.
GPLing BSD code doesn't really "protect" it though. You can't strip the copyright notice off, so anyone that wants to use it can find out where it came from and grab the original to use however they like. It protects any changes made to the GPLed version, but those changes can't be released into the BSD licensed original either.
Unlikely.
a) While MacOS X libraries are from FreeBSD, Darwin (the kernel) is Mach derived and has very little to do with the FreeBSD kernel. The same tricks might work if they were ported, but that would be more of a rewrite with the same concepts rather than a port.
b) Who in their right mind uses MacOS X for routing? Serving, fine, but actual network infrastructure? I highly doubt it.
I wouldn't be so quick to assume that.
-Xinerama switched from being compiled in by default to being a compile time option that had to be specified in make.conf. I don't see a reasonable way I could have known that, at least not without spending hours and hours every week tracking changes.
-There was a week or so where KDE would not compile because it required a tool that was masked. The only possible way for this bug to slip through was if no one had tried to compile it on a stable system before releasing it, not even once. I don't see a reasonable way I could have avoided this, as I actually did check the forums pretty extensively before I sync'd.
-There has been a persistent problem where the second head on my computer is not initialized properly, causing the image to shake. This happened with XFree86 and X.org after the transition. I have no idea what causes it, but Suse, Fedora, Slackware, FreeBSD, and OpenBSD don't have the problem. They all used the same version of XFree86 that had the problem under Gentoo. I have yet to figure this one out, and probably never will.
-The 2004.0 and 2004.1 LiveCDs just plain wouldn't boot on my computer, or would crash soon after boot. I don't have weird hardware. I don't see any way I could be responsible for this.
In short, Gentoo is very powerful but I neither have the time nor the inclination to spend the kind of time required to keep it working. You will note, however, that some of the other OSes I tried (Slackware, FreeBSD, OpenBSD) do very little in the way of handholding. If I were simply an inept user, it's doubtful I could get those working properly.
Yeah... except it's better not to use Gentoo at all.
/yes I'm bitter, but it's all true
I shouldn't say that. It's better not to use Gentoo if you like to have a system that works after your updates more than, oh, 9 times in 10.
I used Gentoo for almost a year total (most recently in august of this year). Compile-time options change without notice, major and easy to spot bugs slip through on a regular basis, and when something like KDE gets updated, it can be a week before things work again. That is, when you can get YOUR config files updated when you're not even sure it's something you did wrong.
I figure Suse Pro paid for itself in about a weekend in the time I saved. Would you believe that not a single update has broken anything yet! What a concept.
To a certain extent, they are interchangable. If we're looking at a 50 year timeframe, there will be electric cars, and I think it's assumed there will be a lot of public transport, where nuclear is useful. Also, it's possible to convert coal into a something that can usefully replace oil in a lot of ways.
At the end of the day, while they are not perfectly interchangable, they do overlap a bit, and thus an increase in the price of one will make the others more attractive and cause people to look at the alternatives.
Their government has no choice. Their oil imports are expanding a lot, and oil is expensive enough as it is.
You clearly lack an understanding of the system. While it does affect the headers, a) sending the whole message first doesn't make any difference on bandwidth, it's just bits in the pipe, and the size of the signature is constant no matter where it is, and b) they're headers. They're sent first.
The message is stored on the server (exactly as was done previously), and a signature is computed for the message. The public key is distributed by DNS, which is a) quite secure and b) extremely bandwidth efficient.
"standards" that aren't acceptable to the general hacker population of the Internet aren't standards.
Yahoo!'s DomainKeys is free and technically superior, and it's not mutually exclusive with SenderID. That means it will end up all the mail-related software except Microsoft stuff. Now who's the standard?
With a good wireless network, you can cruise slashdot in class.
Sometimes, your choice is between staying awake on slashdot or falling asleep.
eh
I don't entirely agree with this. Some bills are a PITA to pay without a credit card. Just don't put anything on it that you can't pay back the moment you use it. In fact, I like to send them money before I even get the bill, just so I can't spend money I don't have.
Most months I've paid it off to the last cent before I even get the bill.
My P4 does just fine with the Intel OEM cooler with "emerge world" (basically, 100% CPU usage for 10 hours). Pretty quiet too, and I've taken no special care to make it quiet.
Well, it did just fine before I smote every last vestige of Gentoo from my system in a fit of incandescent rage because it had broken itself one too many times.
"Sorry, I live in a 64-bit world, to the point that I'm quite ignorant of X86 state of the art. I've been blindly (and wrongly) assuming a 64-bit context for this whole conversation."
:)
:)"
Indeed.
These chips will probably all have the x86-64 extensions, so they are 64-bit chips. Chips with these extensions have been on the market for over a year, first from AMD and soon from Intel.
In the very high end market, very different tradeoffs are very clearly in effect. I'm not sure about die sizes, but there's that POWER 5 from IBM with 4 dual-core dies, each with IBM's version of hyperthreading and 144 megabytes (!) of cache. That might even be 130 nm, I forget.
"Unfortunately, most of what I know about Itanium I really can't talk about, other than in very general terms -- assuming I wish to remain employed, that is.
Well, "Itanium is better a instruction level parallelism than x86." is not a statement I need you to confirm. Also... it's better than POWER.
"The "sweet spot" for cache size is really determined by a race between core performance, and memory latency/bandwidth. Doubling cores doubles the data production/consumption rate. Doubling the frequency also does. The former is less demanding on memory latency and mostly requires more bandwidth. The latter is equally demanding on both. If you double the data production/consumption, and keep the same memory/bus bandwidth, ideally, you'd like to halve the cache miss rate -- but that's pretty unlikely in practice. That's why caches keep growing (at least in the 64-bit world). There is a point of diminuishing returns, because there's an upper limit to both temporal and spacial locality, but we're not quite there yet for Itanium."
This is true... but from watching Intel for the last few years, they have had nothing but trouble getting any gains past the 3.2 ghz chips. They were stuck there for a long time, and they've only got it up to 3.6 ghz now. AMD has been doing well, but when their clock speeds get much faster, they might well begin hitting the same problems. At that point, adding a core is probably the easiest way to increase data production/consumption at all, even if memory bandwidth/latency becomes more of a bottleneck.
"When more CPUs start to have integrated memory controllers and point-to-point links instead of multi-drop busses, I predict that cache sizes per core will actually decline for a while, since the memory performance side of the balance will lower the "sweet spot". After that, caches will probably creep slowly upwards again, because no memory or interconnect technology ever scales fast enough to keep up with CPU core performance scaling."
Your statements make more sense now, if you've not been keeping up with x86. The AMD Athlon 64s and Opterons all have intergrated memory controllers, and in mutli-CPU systems, they use CPU-to-CPU links. They scale up to 8 CPUs with up to several TB of memory...
"So the $64 question is... When cache sizes per core start to decline or level off, will we see smaller die, or will we see even more cores per die? The way Intel seems to always position Itanium for high-end heavy metal, I expect huge die with more cores, although for X86 they went the other way. Or so I infer from your posting."
Probably both, some for low end value computers, and the dual cores for high end machines. Or middle end machines by your standards.
"Not sure which CPU you're referring to here. Is it something in the X86 line? If you're taking a single core power and multiplying by two, then you may be very pleasantly surprised. Montecito, despite having two cores, will have significantly lower total power than its single-core predecessors. (That much I can safely reveal, because it seems to be common knowledge already.)
Having designed systems, I can tell you that difficulties arising from high power-per-socket are very non linear: 200W isn't merely twice as hard to deal wi
FreeBSD has a large base install so nobody needs to fuck with it. Fucking with it negates many of the advantages of using FreeBSD. There are very few cases where fucking with it is worth the effort. In the vast majority of cases where something smaller is needed, something like Slackware is appropriate. In fact, Slackware has zipslack, a distribution optimized for what you're trying to do. Why ignore a ready made solution?
Learning the FreeBSD way includes just installing more than you need and forgetting about it because it doesn't matter. You're wasting less than a dollar's worth of disk space. Your time is worth more than that. Trying to trim the base install is premature optimization unless you already know it really well.
Premature optimization is a Siren's song, and a very powerful one. Just look at all the Gentoo people that can't install a security patch without breaking the world because of premature optimization.
Don't listen to it. FreeBSD can't be all things to all people, and it's a waste of time to try to make it that way. If you do need small, use something meant for it.
"I have no first-hand knowledge of AMD, but for Itanium, smaller process geometries do not increase yield through smaller die size. As they've shrunk to smaller geometries, they have not shrunk die size at all. All the extra real estate goes into larger caches, and the die size, and thus the (raw) yield, remains about the same. They have improved yield, but it's not through shrinking the die."
:)
Right, but there comes a point where "more cache more cache!" just doesn't improve your performance anymore. The trivial case is where cache size equals memory size, and your hit probability is 1.
Note that cache sizes have fluctuated around 256-512 kb since the P2 days. My P2 and P4 both have 512 kb. I'd be shocked if the reason was something other than that being a sweet spot. They're moving to 1 mb now, but that just means they've got more transistors and they don't have worthwhile uses for them in the core. It's diminishing returns, but there's still returns.
But if another core can increase instruction throughput nearly twofold while completely bypassing hard problems like increasing the parallelism in one core, and without increasing die size too much because of the new smaller process, then it makes sense. Itanium is vastly better at extracting parallelism from its instructions because that was the primary design goal, so another core takes more for it to be worth it, and additional cache makes sense.
If x86 stays in the sweek spot at 512 kb but doubles the instruction throughput with two cores, that's a big win.
Of course, I'm no more thrilled with a 200 watt CPU than anyone else, but that's what you get with a two CPU system anyway.
"OEMs will happily pay well over double for a 2-core vs 1-core because of the savings they will make elsewhere in the system. Dual-core also gives system vendors much more flexibility by allowing the same board design to support twice as wide a range of CPU counts."
It would make me happy building my own system too.
"Packaging and testing, sure. But overall cost of 1-dual vs 2-single isn't as clear. Big die are expensive -- they require more costly fab techniques, and result in low yield. Beyond a certain size, the loss in yield is just huge."
Correct.
Amazing, then, that Intel and AMD are talking about going dual core as they start producing chips with 90 nm and smaller technology. It's almost as if they've reached some kind of break even point, where the probability of a defect on a dual core die falls to the point where the gains outweigh the losses.
"Bottom line: for equivalent complexity and cache size, I seriously doubt that it's any cheaper to produce one dual-core chip compared to two single-core ones, knowing how sensitive IC economics are to yield."
You're wrong.
"Is this true? Does Intel put a 3GHz label on 1.5GHz dual/core CPU's"
No. One core running at 3 ghz working with two different streams of instructions so it looks like two processors. They must contend for resources, so each is slower by itself than the single stream you have with hyperthreading disabled, but together they get more work done overall when working on some tasks . Sometimes hyperthreading makes things worse.
Dual core is a completely different idea. Basically, they print two processors onto the same hunk of silicon and it's cheaper to manufacture than two seperate processors because all the other costs like packaging it and testing it stay the same.
Hyperthreading is not a better solution, particularly when dealing with the Intel implementation. Unless it's very carefully done, all it does is keep the cache from working effectively. Linux and FreeBSD actually got performance improvements from leaving one of the virtual processors idle when there were more processes scheduled to run. When there's two threads of the same process, they let them both run because those tend to have better locality of reference and therefore don't thrash the cache so much.
Processor designers are in a different situation now than 10 years ago. They've got more transistors than they know what to do with, so adding cache and adding another core are cheap. Streamlining one core to run faster is much harder, as evidenced by Intel's unending troubles with anything faster than 3.2 ghz.
"enterprise-class" is a moving target. Look at Solaris 10 for examples of things Linux cannot do. Hotpluggable everything (ZFS can do things no one else can), massively redundant, lots of checksumming everywhere, etc. Stuff that Linux doesn't have.
The place to debate the merit of those things is not here, and as someone will point out if I don't say it, SCO's UNIX can't do those things, nor can Windows.
"I recently looked at some straonomy pictures and saw images of galaxies far far away where you could see individual stars. Surely these galaxies are so very far away that they would cover no more of the sky than a star that is only a few lightyears away would? So why can we get such good images of them but not of individual nearby stars or planets?"
Unfortunately this is not so.
The angular size of a star is much smaller than the angular size of (say) the Andromeda Galaxy, which probably makes up a majority of the non-Milky Way pictures of galaxies that most people see.
A star is usually tens to hundreds of thousands of km across. There are a few exceptions, but for the most part this is true. A galaxy is tens to hundreds of thousands of light years across. That's about 10000000000000 times larger. However, a galaxy like Andromeda is less than a 100000 times more distant than they stars we're talking about. Therefore, we can see significant internal detail.
Resolution isn't wasn't necessary to make this technique work. Even the best telescopes have trouble detecting stars as more than point sources.
What matters is the quantity of light recieved per unit time. With the proper equipment on the end, even a small telescope can accurately measure very precisely the amount of light it recieves. I imagine the tricky part is eliminating other factors such as local environmental conditions.
Where does the helium we put in baloons come from? Natural gas wells where it collects from decaying uranium and thorium. Those things are what keep the Earth's core hot. Vast quantities of these things are released every day by coal plants.
I'm not saying we can just replace coal power trivially, but we should be working towards that as a goal. I'm also not saying fission power is perfect either, but a well maintained nuclear plant causes less radioactivity in the environment than a coal plant of similar power output, and as the isotopes released have basically unlimited half-lives (4.5 b.y. for uranium and 14 b.y. for thorium, which are essentially forever to humans), the problem will last a lot longer.
Ultimately, neither is acceptable, and we should be doing our best to replace them both as soon as we can do it without bankrupting the world.
While it lacks CPAN, Python modules for various things are easy to find with Google. It's a little more annoying, but having a language that's not annoying makes up for it very quickly.