> Linux is just a much more mature platform for 64bit computers.
Much more mature? Perhaps you were unaware of Windows XP 64-bit Edition? Sure, it only runs on Itanium, but do you not honestly think that for Microsoft to have released it in early 2003 that they would probably have been working on it and testing it for at least a couple years prior to that?
Linux was ported to the alpha about a decade ago (this was still a 32-bit kernel, just like NT on alpha AFAIK), sometime in 1996 a real 64-bit version was released (2.0). Despite MS market share, I'd guess that there are a lot more 64-bit linux installations around than 64-bit windows.
Another important things is that since most linux software is open source and designed for portability from the start, a 64-bit kernel with a 64-bit userspace is as easy as a recompile (well, almost). MS has a big disadvantage here, because they need to wait for their ISV:s to produce 64-bit programs as well as drivers.
Hmm, you have a point. There is of course a risk that there will be fewer users of the community release than with the current release as some people will choose to wait until the official release.
Anyway, they will have a couple of months of extra freeze time to iron out the bugs. It would kinda defeat the whole purpose of it, if they would make major upgrades to the packages in the time between the community and official releases, now wouldn't it?
Incidentally, did anyone else notice that BP has restated its oil reserves with a massive reduction on what it previously said it had. We're possibly closer to the end of oil than we thought.
I read in the paper today that Shell has dropped it's estimates by a fifth. The article also gave as the reason some changes in how the US government requires the companies to report their reserves. I haven't heard about the BP thing, but I suspect it's the same reason.
As you certainly know, burning any hydrocarbon fuel essentially boils down to the reactions
H2 + 2 O2 => 2 H2O
C + O2 => CO2
Obviously, with a hydrogen fuel cell one can't utilize the second reaction for electricity generation. So, for say diesel fuel, how large fraction of the total thermal energy is from the coal reaction? I gather from your post that it is in fact quite small? Anyway, I guess this energy is not totally wasted, but used as a heat source in the reformer, right? Does a reformer then need any external heat source like waste heat from the fuel cell, or burning some of the diesel to heat it, or is it "self-sufficient"?
On a side note, both articles seemed to be written in a somewhat childish and excessively dramatic style (abrupt sentences, bold higlighting, lots of CAPS, etc.) - while skimming through them, I kept expecting to run into a 'So NYAH!' or two:)
Umm, well, perhaps. Anyway, Kahan is the guy behind the IEEE 754 floating point standard, so you can rest assured that he knows what he's doing when he talks about issues in floating point computation.
Like the little 40mm fan that was cooling the northbridge on my KT7A-RAID, until it stopped working (dust). Now the board only sees one HD.
Hmm, my northbridge fan broke down on my KT7-RAID too. I just threw the thing away and the board works as usual. Guess I am lucky, eh?;-)
OTOH, I have a power supply with a 120mm fan, another 120mm fan in the case, and the CPU is quite slow (Duron 800) with a 80mm fan (PS and CPU fans are temperature controlled), so it might be that those three fans are big enough to cool the entire system.
Yes, I know. And so has gnome for that matter. I just said that my personal preference is the wxwindows bindings. No offence meant to either the KDE or GNOME crowd.
My post had two main points:
1. For GUI programming, I prefer a higher level language than either C or C++. As an example I mentioned my own favourite, python+wxpython.
2. In general, I prefer a mixed language style programming, again mentioning my own favourite, python+C, as an example. In this context I feel that learning C++ is not worth the significant effort it takes, since the modules (called from python) are quite small and indepentent, whereas many of the benefits of C++ over C are in large scale software construction.
Ah, the eternal C vs. C++ flamewar. I've been somewhat of a C++ fan, actually learning C++ before C when I started learning about programming a long time ago. But lately I've been gravitating towards C, primarily because of its simplicity. Rob Pike (one of the creators of Plan 9) summarized C++ quite well with "it's a very difficult, tricky, special-case-ridden language that takes taste and experience to use well.". E.g. take a look at gotw.ca (Herb Sutters website) for a large bunch of situations where C++ manages to bite your ass, in quite non-obvious ways.
Now, on to GUI programming. If there is one area where OO programming languages shines, it's GUI programming. I'm personally not very much in love with doing OO programming with C, GTK-style. What I prefer is using a high level language with bindings to a GUI toolkit, my personal favourite being python and the wxpython bindings to the wxwindows toolkit.
While python as a (bytecode)-interpreted language is slow compared to C/C++, performance of a GUI app doesn't suck that much because much of the prosessing is done in the C/C++ layers beneath your own code.
And if performance is a problem, it's easy to code that part as an extension with C and call it via python (SWIG is very helpful here). This is, IMHO, a very powerful approach to develop many kinds of applications, i.e. code the majority of the program in python, while the parts that are critical to performance (if any) are done in C and then use SWIG to make the C code callable from python.
I did some searching for a cheap NIC that doesn't suck. Intel and 3Com NICs are of course very good, but expensive. The low end cards seem to be mostly realtek crap or almost-as-crap AMD Pcnet based. Eventually I found a real gem in the Linksys LNX100TX cards. They are cheap, about 14 EUR here (the cheapest realtek cards are about 9 EUR), and the chipset they use is a clone of the famous DEC Tulip chip, which BTW has a real good Linux driver.
What I don't understand is why anyone needs to cram a whole multi-user, multi-tasking OS onto a small device with only two or three modes of operation (voice phone, Internet and maybe digital camera). None of these devices really need to be upgradeable - most Europeans get a whole new phone every 12-18 months because their network provider allows cheap upgrades - so that can't be the reason.
The new generation of 2.5G/3G phones are more like computers stuffed into a small case than a traditional phone. While multi-user functionality perhaps is unnecessary on a phone, multi-tasking is definitively needed. OTOH, how cool wouldn't it be to run sshd on your phone?
Presumably it's cheaper to build additional processor speed and storage into the device, to cope with the overhead of Linux/Windows Embedded, than it is to spend developer time to knock up a custom OS for the limited hardware?
Uh, I don't agree with your point. With the same logic you could say that introductory (and references for that matter) programming books are also unnecessary, since these contain stuff that "every CS undergraduate" should know. Well, you have to start somewhere and build on that. And while your memory might be perfect, mine certainly isn't, so I feel it's very helpful to have those books available.
Re:Gentoo, Portage, Python
on
Linux in 2004?
·
· Score: 2, Funny
That's one of differences of Gentoo from other distros: in Gentoo you don't spend weeks of your time for tweaking, you just say what flags to use, and ebauild will decide in a very consistent way where it is appropriate or not.
No, instead you spend a week defining all those USE flags, then wait two weeks for the stuff to compile, and THEN you spend weeks tweaking.
I thought it was? If I recall, CANDU is the only reactor design to combine water moderation and use U-238. Most other reactor designs use U-235, which it seems to me is fissile without moderation.
No, CANDU gets its power from U235, just like every other power producing reactor. U238 is not fissile, so it's of no use directly in a reactor. The basic reactions for U in a reactor are:
U235 + n -> BOOM (i.e. fission)
and
U238 + n -> U239 (instable) -> Pu239
Reactor that are designed to produce Pu239 through the second of these reactions are called breeder reactors. For various reasons, they are quite different than normal reactors.
Anyway, back to CANDU.
The point is that normal water has a higher adsorption cross section for neutrons than heavy water. In fact, it's so big that it's impossible to get a reactor critical with natural U. That's why normal power reactors need encriched U. The point with CANDU is that by using heavy water, you can use natural U and thus skip the entire (extremely expensive) enriching process. OTOH, you need heavy water which is also expensive to produce. But IIRC Canada had some pretty advanced heavy water technology (dating back to WWII) when they started the CANDU project, which probably influenced their decision.
Seems like the power5 will be able to run only two threads per core, like the pentium 4. For the P4 it is understandable that they want to reduce cost as much as possible, but why be so frugal on a high-end cpu like the power5?
I mean, the MTA supercomputer which pioneered the entire SMT concept, was able to run 128 threads per cpu. Ok, so they had different design constraints as well. Basically, the idea was that the cpu:s didn't have any cache at all thus making them simpler and cheaper. To avoid the performance hit usually associated with this they simply switched to another thread when one thread became blocked waiting for memory access.
Anyway, is there any specific reason why IBM didn't put more than 2, say 8 or 16 threads per cpu on the power5?
Current uranium reserves are estimated to last for hundreds of years with the current usage rate + a modest increase. If we want to use the fuel for longer than that we can always develop breeder reactors so that we can utilize U238 and thorium. Current known reserves with breeder reactors will last something like 7000 years. By that time I'm sure we have figured out fusion.
Incidentally, almost every power producing reactor in the western hemisphere is water moderated. And, discounting RBMK and their ilk, also in the rest of the world, for that matter. As you say, water moderation means that if the coolant boils off the chain reaction will stop. CANDU is in no way unique in this aspect. The problem is that the fuel will continue to generate a significant amount of heat even after the chain reaction is stopped, because of the radioactive decay of very short-lived fission products. This heat is enough to melt the reactor core if it's not cooled. This is essentially what happened at three mile island. That's why all nuclear power plants have all kinds of emergency power supplies etc. so that they can continue cooling the reactor after they shut it down.
For one thing, a bottleneck in supercomputers is in most cases the network. In this regard, dropping some per/node performance might not affect the overall performance for applications that need intensive interprocess communication.
OTOH, with faster nodes you need fewer nodes and thus also less network traffic.
IIRC, the green destiny uses plain ethernet for networking, so it won't be able to compete with higher end cluster interconnects anyway (ethernet latency kills performance for many applications). However, the general idea is very neat and worth developing further, IMHO.
Slashdot Mirror
> Linux is just a much more mature platform for 64bit computers.
Much more mature? Perhaps you were unaware of Windows XP 64-bit Edition? Sure, it only runs on Itanium, but do you not honestly think that for Microsoft to have released it in early 2003 that they would probably have been working on it and testing it for at least a couple years prior to that?
Linux was ported to the alpha about a decade ago (this was still a 32-bit kernel, just like NT on alpha AFAIK), sometime in 1996 a real 64-bit version was released (2.0). Despite MS market share, I'd guess that there are a lot more 64-bit linux installations around than 64-bit windows.
Another important things is that since most linux software is open source and designed for portability from the start, a 64-bit kernel with a 64-bit userspace is as easy as a recompile (well, almost). MS has a big disadvantage here, because they need to wait for their ISV:s to produce 64-bit programs as well as drivers.
Hmm, you have a point. There is of course a risk that there will be fewer users of the community release than with the current release as some people will choose to wait until the official release.
Anyway, they will have a couple of months of extra freeze time to iron out the bugs. It would kinda defeat the whole purpose of it, if they would make major upgrades to the packages in the time between the community and official releases, now wouldn't it?
Incidentally, did anyone else notice that BP has restated its oil reserves with a massive reduction on what it previously said it had. We're possibly closer to the end of oil than we thought.
I read in the paper today that Shell has dropped it's estimates by a fifth. The article also gave as the reason some changes in how the US government requires the companies to report their reserves. I haven't heard about the BP thing, but I suspect it's the same reason.
As you certainly know, burning any hydrocarbon fuel essentially boils down to the reactions
H2 + 2 O2 => 2 H2O
C + O2 => CO2
Obviously, with a hydrogen fuel cell one can't utilize the second reaction for electricity generation. So, for say diesel fuel, how large fraction of the total thermal energy is from the coal reaction? I gather from your post that it is in fact quite small? Anyway, I guess this energy is not totally wasted, but used as a heat source in the reformer, right? Does a reformer then need any external heat source like waste heat from the fuel cell, or burning some of the diesel to heat it, or is it "self-sufficient"?
Mr Fusion here I come!
I'm still using Mozilla 1.0
Hey, a C64 could finish that task as fast as the earth simulator!
*hint* In case you didn't know, Pi has an infinite number of digits. Scary, huh?
On a side note, both articles seemed to be written in a somewhat childish and excessively dramatic style (abrupt sentences, bold higlighting, lots of CAPS, etc.) - while skimming through them, I kept expecting to run into a 'So NYAH!' or two
Umm, well, perhaps. Anyway, Kahan is the guy behind the IEEE 754 floating point standard, so you can rest assured that he knows what he's doing when he talks about issues in floating point computation.
The only enemy is ignorance, but it is also the enemy of productivity, so Python is fighting the good fight
Touche!
And yes, I agree that python totally rocks. Waaah!!
While on the topic of disregarding execution speed, python allows _really_ fast development speed. Way faster than Java, for that matter.
Like the little 40mm fan that was cooling the northbridge on my KT7A-RAID, until it stopped working (dust). Now the board only sees one HD.
Hmm, my northbridge fan broke down on my KT7-RAID too. I just threw the thing away and the board works as usual. Guess I am lucky, eh?
OTOH, I have a power supply with a 120mm fan, another 120mm fan in the case, and the CPU is quite slow (Duron 800) with a 80mm fan (PS and CPU fans are temperature controlled), so it might be that those three fans are big enough to cool the entire system.
KDE has excellent Python bindings.
Yes, I know. And so has gnome for that matter. I just said that my personal preference is the wxwindows bindings. No offence meant to either the KDE or GNOME crowd.
My post had two main points:
1. For GUI programming, I prefer a higher level language than either C or C++. As an example I mentioned my own favourite, python+wxpython.
2. In general, I prefer a mixed language style programming, again mentioning my own favourite, python+C, as an example. In this context I feel that learning C++ is not worth the significant effort it takes, since the modules (called from python) are quite small and indepentent, whereas many of the benefits of C++ over C are in large scale software construction.
Ah, the eternal C vs. C++ flamewar. I've been somewhat of a C++ fan, actually learning C++ before C when I started learning about programming a long time ago. But lately I've been gravitating towards C, primarily because of its simplicity. Rob Pike (one of the creators of Plan 9) summarized C++ quite well with "it's a very difficult, tricky, special-case-ridden language that takes taste and experience to use well.". E.g. take a look at gotw.ca (Herb Sutters website) for a large bunch of situations where C++ manages to bite your ass, in quite non-obvious ways.
Now, on to GUI programming. If there is one area where OO programming languages shines, it's GUI programming. I'm personally not very much in love with doing OO programming with C, GTK-style. What I prefer is using a high level language with bindings to a GUI toolkit, my personal favourite being python and the wxpython bindings to the wxwindows toolkit.
While python as a (bytecode)-interpreted language is slow compared to C/C++, performance of a GUI app doesn't suck that much because much of the prosessing is done in the C/C++ layers beneath your own code.
And if performance is a problem, it's easy to code that part as an extension with C and call it via python (SWIG is very helpful here). This is, IMHO, a very powerful approach to develop many kinds of applications, i.e. code the majority of the program in python, while the parts that are critical to performance (if any) are done in C and then use SWIG to make the C code callable from python.
I have a blazing headache because I'm trying to cut down on my coffee drinking after reading the recent article!
I did some searching for a cheap NIC that doesn't suck. Intel and 3Com NICs are of course very good, but expensive. The low end cards seem to be mostly realtek crap or almost-as-crap AMD Pcnet based. Eventually I found a real gem in the Linksys LNX100TX cards. They are cheap, about 14 EUR here (the cheapest realtek cards are about 9 EUR), and the chipset they use is a clone of the famous DEC Tulip chip, which BTW has a real good Linux driver.
What I don't understand is why anyone needs to cram a whole multi-user, multi-tasking OS onto a small device with only two or three modes of operation (voice phone, Internet and maybe digital camera). None of these devices really need to be upgradeable - most Europeans get a whole new phone every 12-18 months because their network provider allows cheap upgrades - so that can't be the reason.
The new generation of 2.5G/3G phones are more like computers stuffed into a small case than a traditional phone. While multi-user functionality perhaps is unnecessary on a phone, multi-tasking is definitively needed. OTOH, how cool wouldn't it be to run sshd on your phone?
Presumably it's cheaper to build additional processor speed and storage into the device, to cope with the overhead of Linux/Windows Embedded, than it is to spend developer time to knock up a custom OS for the limited hardware?
Yeah, you got it!! Hooray!
Uh, I don't agree with your point. With the same logic you could say that introductory (and references for that matter) programming books are also unnecessary, since these contain stuff that "every CS undergraduate" should know. Well, you have to start somewhere and build on that. And while your memory might be perfect, mine certainly isn't, so I feel it's very helpful to have those books available.
That's one of differences of Gentoo from other distros: in Gentoo you don't spend weeks of your time for tweaking, you just say what flags to use, and ebauild will decide in a very consistent way where it is appropriate or not.
No, instead you spend a week defining all those USE flags, then wait two weeks for the stuff to compile, and THEN you spend weeks tweaking.
I thought it was? If I recall, CANDU is the only reactor design to combine water moderation and use U-238. Most other reactor designs use U-235, which it seems to me is fissile without moderation.
No, CANDU gets its power from U235, just like every other power producing reactor. U238 is not fissile, so it's of no use directly in a reactor. The basic reactions for U in a reactor are:
U235 + n -> BOOM (i.e. fission)
and
U238 + n -> U239 (instable) -> Pu239
Reactor that are designed to produce Pu239 through the second of these reactions are called breeder reactors. For various reasons, they are quite different than normal reactors.
Anyway, back to CANDU.
The point is that normal water has a higher adsorption cross section for neutrons than heavy water. In fact, it's so big that it's impossible to get a reactor critical with natural U. That's why normal power reactors need encriched U. The point with CANDU is that by using heavy water, you can use natural U and thus skip the entire (extremely expensive) enriching process. OTOH, you need heavy water which is also expensive to produce. But IIRC Canada had some pretty advanced heavy water technology (dating back to WWII) when they started the CANDU project, which probably influenced their decision.
Seems like the power5 will be able to run only two threads per core, like the pentium 4. For the P4 it is understandable that they want to reduce cost as much as possible, but why be so frugal on a high-end cpu like the power5?
I mean, the MTA supercomputer which pioneered the entire SMT concept, was able to run 128 threads per cpu. Ok, so they had different design constraints as well. Basically, the idea was that the cpu:s didn't have any cache at all thus making them simpler and cheaper. To avoid the performance hit usually associated with this they simply switched to another thread when one thread became blocked waiting for memory access.
Anyway, is there any specific reason why IBM didn't put more than 2, say 8 or 16 threads per cpu on the power5?
Current uranium reserves are estimated to last for hundreds of years with the current usage rate + a modest increase. If we want to use the fuel for longer than that we can always develop breeder reactors so that we can utilize U238 and thorium. Current known reserves with breeder reactors will last something like 7000 years. By that time I'm sure we have figured out fusion.
Incidentally, almost every power producing reactor in the western hemisphere is water moderated. And, discounting RBMK and their ilk, also in the rest of the world, for that matter. As you say, water moderation means that if the coolant boils off the chain reaction will stop. CANDU is in no way unique in this aspect. The problem is that the fuel will continue to generate a significant amount of heat even after the chain reaction is stopped, because of the radioactive decay of very short-lived fission products. This heat is enough to melt the reactor core if it's not cooled. This is essentially what happened at three mile island. That's why all nuclear power plants have all kinds of emergency power supplies etc. so that they can continue cooling the reactor after they shut it down.
For one thing, a bottleneck in supercomputers is in most cases the network. In this regard, dropping some per/node performance might not affect the overall performance for applications that need intensive interprocess communication.
OTOH, with faster nodes you need fewer nodes and thus also less network traffic.
IIRC, the green destiny uses plain ethernet for networking, so it won't be able to compete with higher end cluster interconnects anyway (ethernet latency kills performance for many applications). However, the general idea is very neat and worth developing further, IMHO.
Perhaps, but that doesn't prove that the layman will understand it after the scientist explains it.
Actually, both Red Hat and Suse sell "enterprise" version of their distros with a minimum 5 year guaranteed full support.