Wow, that's a long ways from what I experienced. My high school chemistry instructor actually flipped through the Anarchist's Cookbook looking for things that we could safely experiment with in the lab.
It's sad that my experience is much more the exception than the rule.
While you are right that conventional coal plants can be made just as clean as gasification, it's just much more expensive to scrub a conventional coal plant than a gasification plant. The difference is quite significant.
Most of the savings is due to more beneficial thermodynamics. Syngas (the product of gasification) has a much higher concentration of CO2 than exhaust gas (the product of a conventional plant). This higher concentration (also higher pressure and temperature than at the exhaust stack) provide a larger driving force for the removal of CO2 from the gas stream. This larger driving force means that there is less need for capital investment in scrubbing equipment. It also means that less energy is utilized in scrubbing the gas. Finally, since gasification results in more complete oxidation of the carbon, the plant is overall more efficient. The result is cheaper energy from the same coal.
Adding scrubbing and sequestering equipment onto existing plants is estimated to add 75% to the cost of energy from coal. Coal gasification (with carbon sequestration) would only add around 33% to the cost of energy from coal.
Correct.
They don't need to. The theory is that the three-core Phenom is about AMD recouping a loss on their four-core when there's a defect that causes one of the cores to be bad. They can just disable the bad core and then sell a three-core product instead of throwing it in the trash.
For Intel if one of the two dual-core modules in the MCM has a bad core, they can either just sell it as a single-core or eat the loss of only one dual-core module. It's much cheaper to just toss half the silicon. When you add in the fact that Intel has higher yields on their process, it means that they just don't need to worry about recouping losses with a three-core.
I hate to pick a nit (since I do like the concept of greener energy), but solar panels do nothing about demand for foreign oil.
The vast majority of electrical power in this country (U.S.) is generated from coal. Americans don't import coal either, since we're the Saudi Arabia of coal.
Here is my experience as someone who has used a Mac primarily for scientific computing. I've used MacOS as my primary work OS for 2 years. Prior to that, I used Linux as my primary work OS for 4 years.
Other posters have mentioned that X11 isn't installed by default. Nor is aqua X11. There will be inconsistency in look / feel between apps running in X11. Aqua isn't network transparent.
Darwin uses the FreeBSD libc5, not glibc (which Linux distros use). This causes problems occasionally when compiling a random app for Darwin.
Apple does include some common services in OSX, like Apache. Apple takes care of issuing updates when there's a security vulnerability in Apache. There are however, many things you might want to run (like php and mysql, etc) which Apple doesn't provide. There are definitely ways to get these things installed (3rd party installers, fink, and darwinports). However, there is now centralized repository or utility for updating all these programs. If you have a computer with a (relatively) static IP and open ports to the internet, you personally have to keep up with security updates to all the extra things you install. This is a huge headache, and something I really miss from the Debian world.
Darwin runs a hybrid kernel, called XNU. XNU is not as fast at creating threads as the Linux kernel. You'll feel it if you have a script that spawns lots of threads in quick succession.
MacOS doesn't have a builtin defrag utility for HFS+. Part of the reason is that MacOS does on-the-fly defragging of small files (under 20 MB, I believe -- there are Apple Docs on this). That said, if you're regularly creating lots of files under 20MB (which I do), you'll feel a slow down compared to Linux. Also, when I'm downloading files, I see that stupid rotating beach ball at the start and end of the download -- for the uninitiated, this means that that particular application is unresponsive until the ball stops spinning. I'm not sure if the downloading issue is related to on-the-fly defragging or not, but the point is that disk IO on MacOS just isn't quite as fast as a similar system under Linux.
Apple's gcc is different that GNU gcc. Also, created binaries are not ELF format, but rather Mach-O. Together, these things mean that Apple intends for all binaries to be dynamically linked. This makes it a pain to compile a statically linked binary. It's possible, but can be a huge pain in the butt!
Some things are really nice. I enjoy using the 'open' command on the commandline to open a file with it's default association, or you can specify the app to open it with 'open -a'.
Another thing that's really nice is spotlight. Beagle works well under Linux, but it's just not as widely spread.
The ability to run a supported version of MS Office is really nice. This makes collaboration with less tech-savvy colleagues much easier.
Installing apps is really easy. Most of the time, it's just copy and paste. Also, it's really easy for unprivileged users to install most apps in their home directory and have those apps work well.
There are finder quirks, especially if you run a virtual desktop application, like VirtueDesktops. The one that gets me the most is that if I have a particular folder open on some other desktop, double clicking that folder doesn't open a new window, it just brings that window to the top on that other desktop. You have open a new finder window and then navigate to the folder you originally wanted to get two finder windows open to the same folder on different desktops.
Apple insists on hiding certain folders from Aqua applications. You can get to those from the Open and Save dialogs (most of the time -- MS Office, I'm looking at you), it's just a nuisance. The folders that are hidden that I'd most like un-hidden are/tmp,/usr, and/etc. Of course, I'd rather they're all unhidden.
IWILL makes an 8-way motherboard. They claim 128 Gb of RAM will fit.
I'm pretty sure that the 1U rack statement is an error, but there are 32 DIMM slots. I have no idea if one could actually get a 4 GB stick, but with 2 GB sticks that's 64 GB.
In fact, while attempting to get some work done from a Panera in Osage Beach, MO, I was blocked from ssh'ing to my office machine. This made the Wi-Fi totally useless.
I'm not sure what distribution you're using to evaluate GNOME's performance, but I have no performance problems with Debian on my P3 600 laptop (256MB RAM). In my experience, I have found that for some reason RedHat's GNOME crawls on older hardware, while Debian's performs nicely.
If you haven't yet, I suggest you give Debian a try.
Um, those are screenshots for an older version of gnumeric for gtk1. Here are some much more recent screenshots, using gtk2.
It's really quite nice to use under gnome2.
Also, the theme of your desktop affects the appearance of every gnome2 application, so the screenshots are dependent upon the theme used in taking the screenshot.
You really cannot run threads or single-systems-image systems on a cluster. That is something you can do on Crays and SGIs.
This is true, from a programming aspect. However, from a hardware performance standpoint, there is no difference between a (non-vector machine) shared memory HPC, and a cluster HPC. I say this because even a shared memory machine does not actually allow simultaneous access to the same memory address (or memory controller for that matter.) This is due to a physical imposibility; memory controllers can only handle one request at a time. Thus, memory operations involving the same memory controller of a shared memory machine get serialized, resulting in non-parallel (very bad) performance.
The best shared memory situation is one in which every memory address has an independent controller. Since this is prohibitively expensive, a common compromise is to have each processor use a dedicated memory controller for a portion of the total memory, and then provide a mechanism for other processors to request to look at that "local" memory. This is actually how the Opteron works, and incidently what the Cray XD1 uses. The only difference between this and a cluster is the interconnect -- HyperTransport vs. Infiniband (or Myrinet, Dolphin, Quadrics, etc.)
Now don't get me wrong, HyperTransport is a much better interconnect than Infiniband. It's just that from an algorithmic point of view, all HPC's, whether shared memory or clusters should be treated as a cluster to achieve the best performance. Keeping memory accesses local to each thread (or node) minimizes the serialization and latency associated with trying to access the same memory controller from different threads (or nodes).
I agree that ECC is very much needed. How do you know that Apple isn't putting ECC memory into these boxes? Is the motherboard chipset incapable of handling ECC memory?
Really, I am curious.
Afterall, it does seem like Apple's doing some customiziation beyond what we can order at the Apple Store (Infiniband interconnect).
This worm does cause a lot of traffic *right now*, but as more and more computers get patched, the traffic on the internet will reduce as even this "white-hat" worm will no longer be able to "infect" patched computers.
Here's the link to the actual journal his article was published in, for the curious.
From the article, it would be a stretch to say that Pashley has found a way to overcome "long-range" hydrophobic effects. Those effects are still present. However, he has found a way to get the hydrophobic liquid to break away in small droplets. Once broken away from the bulk, standard DLVO theory takes over to keep the particles apart. DLVO is not a cancelation of hydrophobic effects, it is just an overpowering of hydrophobic effects by electrostatic effects.
Unfortunately, it seems as though Pashley has no good explanation for why the degassing method works, it just does. This could be interesting, as more researchers study the role of gasses in keeping hydrophobic and hydrophilic liquids apart.
Overall, quite interesting, though New Scientist does tend to exagerate scientific findings.
Tony
Of course the comparisons were made using gcc 2.95.x (or 2.8 in the second article).
gcc has come a long way in terms of performance since 2.95.x. 3.2.x now compiles code that runs as fast (or faster, depending on the code) as Intel's C/C++ compiler. Right now, the only reason for me to use Intel's compiler is OpenMP.
Now, if anyone has made some benchmarks using gcc 3.2.x, I'd be interested. (In fact, I may have to do some on Monday.)
Your comment about metadata is apt. However, it's not Linux that's at fault (nor BSD, nor Windows). The fault lies squarely with the filesystem. In Linux, the filesystem is driven by one of many different drivers, each with their own support (or lack) of metadata.
However, Linux's inherent view of files (ie. everything is a file) is not necessarily wrong. This allows many very easy solutions to problems. It makes it easy for applications which want to use a device; they simply read or write to a file. It also makes it easy to monitor your system; just read proc files with a text parser.
So in conclusion, Linux's current view of files is not incompatible with metadata, and there are many advantages to viewing files in the way that Linux does.
Why shelve the disks? You brought up a couple of very important reasons not to shelve IDE drives; namely, stiction and life span.
Rather, use a couple of live backup computers, one in-house and one off-site. Put large RAID 1, hot-swappable raids in the two computers and schedule these computers to periodically back-up your data.
The RAID 1 buys you redundancy for a drive to fail and be replaced, without losing your backup.
The two computers (or three, or more, up to your heart/wallet's content) buy you redundancy for a computer to fail or be destroyed (and take the drives with it).
The live computers buy you the freedom from media and from worry. If Serial ATA becomes all the rage, you can just swap in a Serial ATA (or Ultra-New-Large-Storage-Media) based backup computer. Plus, a live computer (or a watchdog computer, which watches to make sure your backup computer is actually up), lets you know if you need to replace a faulty drive or faulty computer, before it's too late and you have three bad drives on the shelf.
So, in summary. Don't shelve. Run live redundant backup computers.
Re:Religious paranoid idiots will ban anything
on
Don't Stymie Nanotech
·
· Score: 2, Insightful
I wouldn't be so quick to pin resistance to nanotech on those who are religious.
So, the moral of the story is: just because you might happen to know (alright, we might all happen to know) some religious folk who are not willing to listen to a single new idea, don't blame all religious folk (or even the majority) for resisting technology. The evidence shows that religiosity is not at all correlated to technological resistance.
To go a step further in your thinking, don't just assume that all technology is good. Don't assume it's bad either. Rather, think intelligently about the pros and cons, and based on those make a decision.
Slashdot Mirror
Wow, that's a long ways from what I experienced. My high school chemistry instructor actually flipped through the Anarchist's Cookbook looking for things that we could safely experiment with in the lab. It's sad that my experience is much more the exception than the rule.
While you are right that conventional coal plants can be made just as clean as gasification, it's just much more expensive to scrub a conventional coal plant than a gasification plant. The difference is quite significant.
Most of the savings is due to more beneficial thermodynamics. Syngas (the product of gasification) has a much higher concentration of CO2 than exhaust gas (the product of a conventional plant). This higher concentration (also higher pressure and temperature than at the exhaust stack) provide a larger driving force for the removal of CO2 from the gas stream. This larger driving force means that there is less need for capital investment in scrubbing equipment. It also means that less energy is utilized in scrubbing the gas. Finally, since gasification results in more complete oxidation of the carbon, the plant is overall more efficient. The result is cheaper energy from the same coal.
http://pubs.acs.org/isubscribe/journals/cen/85/i44/html/8544gov1.html
Adding scrubbing and sequestering equipment onto existing plants is estimated to add 75% to the cost of energy from coal. Coal gasification (with carbon sequestration) would only add around 33% to the cost of energy from coal.
Correct. They don't need to. The theory is that the three-core Phenom is about AMD recouping a loss on their four-core when there's a defect that causes one of the cores to be bad. They can just disable the bad core and then sell a three-core product instead of throwing it in the trash. For Intel if one of the two dual-core modules in the MCM has a bad core, they can either just sell it as a single-core or eat the loss of only one dual-core module. It's much cheaper to just toss half the silicon. When you add in the fact that Intel has higher yields on their process, it means that they just don't need to worry about recouping losses with a three-core.
I hate to pick a nit (since I do like the concept of greener energy), but solar panels do nothing about demand for foreign oil. The vast majority of electrical power in this country (U.S.) is generated from coal. Americans don't import coal either, since we're the Saudi Arabia of coal.
Agreed. Throw in a USB TV tuner and either external storage or increased internal storage, and you've got a nice PVR box. MythTV/PS3, anyone?
The thing is, as long it's running Linux well, Sony doesn't have to do squat to make the PS3 a PVR box. That's already a solved problem under Linux.
LyX works.
In fact there's a Qt/aqua version precompiled. You'll still need the rest of LaTeX from fink or darwinports, but LyX works.
http://wiki.lyx.org/LyX/LyXOnMac
IWILL makes an 8-way motherboard. They claim 128 Gb of RAM will fit.
I'm pretty sure that the 1U rack statement is an error, but there are 32 DIMM slots. I have no idea if one could actually get a 4 GB stick, but with 2 GB sticks that's 64 GB.
http://www.iwillusa.com/product_2.asp?p_id=90
Tony
In fact, while attempting to get some work done from a Panera in Osage Beach, MO, I was blocked from ssh'ing to my office machine. This made the Wi-Fi totally useless.
I'm not sure what distribution you're using to evaluate GNOME's performance, but I have no performance problems with Debian on my P3 600 laptop (256MB RAM). In my experience, I have found that for some reason RedHat's GNOME crawls on older hardware, while Debian's performs nicely.
If you haven't yet, I suggest you give Debian a try.
Um, those are screenshots for an older version of gnumeric for gtk1. Here are some much more recent screenshots, using gtk2.
It's really quite nice to use under gnome2.
Also, the theme of your desktop affects the appearance of every gnome2 application, so the screenshots are dependent upon the theme used in taking the screenshot.
*humbled* I stand corrected.
You really cannot run threads or single-systems-image systems on a cluster. That is something you can do on Crays and SGIs.
This is true, from a programming aspect. However, from a hardware performance standpoint, there is no difference between a (non-vector machine) shared memory HPC, and a cluster HPC. I say this because even a shared memory machine does not actually allow simultaneous access to the same memory address (or memory controller for that matter.) This is due to a physical imposibility; memory controllers can only handle one request at a time. Thus, memory operations involving the same memory controller of a shared memory machine get serialized, resulting in non-parallel (very bad) performance.
The best shared memory situation is one in which every memory address has an independent controller. Since this is prohibitively expensive, a common compromise is to have each processor use a dedicated memory controller for a portion of the total memory, and then provide a mechanism for other processors to request to look at that "local" memory. This is actually how the Opteron works, and incidently what the Cray XD1 uses. The only difference between this and a cluster is the interconnect -- HyperTransport vs. Infiniband (or Myrinet, Dolphin, Quadrics, etc.)
Now don't get me wrong, HyperTransport is a much better interconnect than Infiniband. It's just that from an algorithmic point of view, all HPC's, whether shared memory or clusters should be treated as a cluster to achieve the best performance. Keeping memory accesses local to each thread (or node) minimizes the serialization and latency associated with trying to access the same memory controller from different threads (or nodes).
No kidding.
If this had been an option when I got my office Dell, it so would've had FreeDOS on it.
Tony (a happy Debian user)
I agree that ECC is very much needed. How do you know that Apple isn't putting ECC memory into these boxes? Is the motherboard chipset incapable of handling ECC memory?
Really, I am curious.
Afterall, it does seem like Apple's doing some customiziation beyond what we can order at the Apple Store (Infiniband interconnect).
Tony
This worm does cause a lot of traffic *right now*, but as more and more computers get patched, the traffic on the internet will reduce as even this "white-hat" worm will no longer be able to "infect" patched computers.
How about backing up your hard drive and then sending it in?
Tony
Here's the link to the actual journal his article was published in, for the curious.
From the article, it would be a stretch to say that Pashley has found a way to overcome "long-range" hydrophobic effects. Those effects are still present. However, he has found a way to get the hydrophobic liquid to break away in small droplets. Once broken away from the bulk, standard DLVO theory takes over to keep the particles apart. DLVO is not a cancelation of hydrophobic effects, it is just an overpowering of hydrophobic effects by electrostatic effects.
Unfortunately, it seems as though Pashley has no good explanation for why the degassing method works, it just does. This could be interesting, as more researchers study the role of gasses in keeping hydrophobic and hydrophilic liquids apart.
Overall, quite interesting, though New Scientist does tend to exagerate scientific findings.
Tony
If Reasoning found bugs in the Linux TCP/IP stack, then they should contribute to the community and send bug reports (or fix the code).
Tony
Copyrights are not the same thing as slavery. Slavery is the ownership of people. Copyrights are the ownership of ideas.
Do you see the difference? Ideas are not people.
There is nothing inherently wrong with owning ideas. As a previous poster noted, it's the abuse of copyrights that is wrong.
Tony
Of course the comparisons were made using gcc 2.95.x (or 2.8 in the second article).
gcc has come a long way in terms of performance since 2.95.x. 3.2.x now compiles code that runs as fast (or faster, depending on the code) as Intel's C/C++ compiler. Right now, the only reason for me to use Intel's compiler is OpenMP.
Now, if anyone has made some benchmarks using gcc 3.2.x, I'd be interested. (In fact, I may have to do some on Monday.)
Tony
Your comment about metadata is apt. However, it's not Linux that's at fault (nor BSD, nor Windows). The fault lies squarely with the filesystem. In Linux, the filesystem is driven by one of many different drivers, each with their own support (or lack) of metadata.
This is the direction that ReiserFS is moving toward.
However, Linux's inherent view of files (ie. everything is a file) is not necessarily wrong. This allows many very easy solutions to problems. It makes it easy for applications which want to use a device; they simply read or write to a file. It also makes it easy to monitor your system; just read proc files with a text parser.
So in conclusion, Linux's current view of files is not incompatible with metadata, and there are many advantages to viewing files in the way that Linux does.
Tony
Why shelve the disks? You brought up a couple of very important reasons not to shelve IDE drives; namely, stiction and life span.
Rather, use a couple of live backup computers, one in-house and one off-site. Put large RAID 1, hot-swappable raids in the two computers and schedule these computers to periodically back-up your data.
The RAID 1 buys you redundancy for a drive to fail and be replaced, without losing your backup.
The two computers (or three, or more, up to your heart/wallet's content) buy you redundancy for a computer to fail or be destroyed (and take the drives with it).
The live computers buy you the freedom from media and from worry. If Serial ATA becomes all the rage, you can just swap in a Serial ATA (or Ultra-New-Large-Storage-Media) based backup computer. Plus, a live computer (or a watchdog computer, which watches to make sure your backup computer is actually up), lets you know if you need to replace a faulty drive or faulty computer, before it's too late and you have three bad drives on the shelf.
So, in summary. Don't shelve. Run live redundant backup computers.
I wouldn't be so quick to pin resistance to nanotech on those who are religious.
That may be the case in the area where you live, but worldwide, we see that the least religious folk (Europeans, in a somewhat recent worldwide survey) are also the most stringent about genetically modified organisms.
So, the moral of the story is: just because you might happen to know (alright, we might all happen to know) some religious folk who are not willing to listen to a single new idea, don't blame all religious folk (or even the majority) for resisting technology. The evidence shows that religiosity is not at all correlated to technological resistance.
To go a step further in your thinking, don't just assume that all technology is good. Don't assume it's bad either. Rather, think intelligently about the pros and cons, and based on those make a decision.
Tony
I don't think so. It is a binary only release, so unless you're running x86 with libc6, you're out of luck.
Tony