The unfortunate part is that intel may very well kill of rambus in the 'consumer' level (ie: where the best price/performance tends to be for computational clusters), to a large extent due to 'public' misunderstanding of benchmarks. A lot of people think that ddr is as good as rambus.
For example, a lot of people trot out the 'latency' issues without understanding them. ddr requires a lengthy burst read of *64* bit wide data to achieve it's bandwidth, while rambus, also needing a brust read, reads only 16 bits per, resulting in a more 'localised' abiity to read memory, and therefore less wasted reads, which amounts to less wasted memory bandwidth.
It is very interesting to have a look at the memory subsystems used in mainframes, where it is very normal to have a large number of effectively seperate, and not very wide, memory busses to allow much more efficient 'scattered' data reads without generating false dependencies between memory addresses.
Ahh yes, but they don't derive, look at their view of such things as: 'the kings new groove' (reality, the spaniards turned up and killed/tortured everyone) 'the hunchback of notre dame' (reality, being killed for looking different) 'pocahontis' (nope, I'm not even going to touch that one). 'anastasia' (reality, the violent murder of the russian royal family)
they certainly aren't COPYING stories, just rewriting history to be SO MUCH NICER, what more can we ask from our leaders (sorry, I mean media).
Unfortunately, I get around a !20%! speed advantage using rambus over ddr-sdram for serious scientific computations (large matrix inversions, primarily, for simultanious equation solutions).
Rambus SIGNIFICANTLY kicks the arse of DDR (and certainly standard sdram), and the extra cost is well worth it in these situations. I wish people would stop trying to benchmark 'high-end' equipment by running office suite benchmarks on it and then think they are actually testing anything.
Good code (and trust me, with runtimes in the days it is WELL worth having good code for these problems) does actually make use of the full capabilities of rambus, and ddr doen't even come close to catching up.
I would love to see them produce 64-bit wide rambus dimms (the same width as ddr-sdram) as opposed to the current 16 bits wide, and THEN see the ddr try to keep up, as this would give them equivalent circuit board resource usage.
The future of RAM (well, for a while) will be rambus type busses, as they make much more effective use of pins on the chipsets, and pins are becoming a scarce resource (look at the pincounts for the new hammer line from AMD if you don't believe me), allowing rambus to support many moer busses than ddr.
Politically rambus is a complete failure, which is a pity, the technology is absolutly great, as is the real-world preformance FOR THOSE WHO NEED IT.
With all the 'public' money spent on space research, I wonder when we will start to see decent data available for the earth?
Yes, I know about terraserver, which is rather pathetic outside the US.
We know the planet has been mapped (rather a few times I bet), but many goverments seem to like to keep that data 'private' and sell it off for LARGE amounts of money.
I bet a lot of us could find fantastic uses for even 100m per value topographical data for the whole planet, not just the bits we are 'allowed' access to.
And please no one tell me it's for security reasons, as often the best data can be accessed for the 'secure' regions (ie: most of the US is easy, but try and get pitcairn island).
Imaging the fun of exploring a whole virtual planet, admitedly not up close, but there is a lot of truely wonderful topography to our planet.
the 'regulations' define the allowable total output power, the amount of 'focusing' you do is not controlled, since this does not ever actually increase the total output power.
the 'soup can' is a very crappy setup, it lowers the total ouput power a LOT (due to impedance mismatches) and gains a little by focusing this lower power reasonably. the helical actually has an impedance transformer, so uses all the power you have, a much better setup.
may I sugest you read up a little on radio transmission, and all will become clear.
These things perform miserably, for a much better design, have a look at:
http://users.bigpond.net.au/jhecker/
For a 2.4GHz hellical that is simple to build, these things are great.
This page gives actually useful measurements and a great bulding guide. I would (and do) use one of these over these non-functioning cans any day.
From my experience, NT doesn't so much have a guaranteed latency time as a probable crash time.
This is NOT a troll, NT makes it VERY hard to meet any true real-time requirements without writing at the driver level, which is a massive pain, and exposes you to BIG risks in destabilising the machine.
Linux currently (without these patches) has very good average latency, with these patches it has fantastic worst-case latency, windows CE (which is supposed to be real-time) cannot match it.
Windows hides behind it's multimedia guaranteed latency capabilities, fine if you want to do multi media, useless if you need machine control, or other real-time requirements.
- A clean, SIMPLE, powerfull core language
- Data types that make life easy (lists/dictionaries)
- A FANTASTIC set of cross-platform libraries
- A GREAT standard and simple GUI library (Tk)
- A GREAT powerful GUI library (WX)
Things I would love about python:)
- A compiler (very hard, but I can dream)
- Smaller/more tunable installs
- wxWindows built in
Python is the 'simple c++' I was always looking for and have now found;), 90% of the functionality with 1% of the complexity, and great cross-platform support to boot!
As a developer, I just love it. Python reduces my development time significantly, and also allows me to express algorithms in a logic way, without fighting the language. This is a VERY important feature. It lowers development stress, so I can spend more time working and less time reading language manuals.
You have to be kidding. Python is certainly not 'just a scripting language', I personally have written some rather major software using it, and find it a fantastic tool.
It finally answered the question that had been sitting in the back of my mind WRT C++, ie: 'this is good, but not quite what I want, it's overkill, but what is wrong?'. Python makes complex tasks my simpler, and does not try and make simple tasks appear complex.
The lack of a true compiler (and also good linking system) is an issue, but not, IMHO, a major one, there are options available (pyco, py2exe, JPython, etc) that partially address this, but more often it is not a real issue.
Python has probably doubled my efficiency as a developer, which is no small feat. C++ was probably the last tool to come close to that, and the startup time on c++ was around 6 months, python was closer to 2 weeks!
Firstly, there was quite a fuss with analogue recording (primarily with video, but also with the start of the compact casette tape), it was, as you say, addressed with a 'media corperate' tax being applied to these items, and the feared drop in profits never happened (infact quite the opposite), so the recording industry made big $$ out of this.
Secondly, the reason this *should* not happen to newer digital media is that a crapload of this is NOT used to record copywrited, stolen, artistic stuff. Much (most?) of the writable digital media (cdrom, harddrives, dvd, etc) are use for storage of computer data.
I would be VERY annoyed if these same companies manage to get a tax added to the rice of every HD/writable CD/etc, and believe me, they are trying, as they know this is free money for them!
This system works by making the 'bits' (ie: data stream) on the cd *wrong*, and by expecting the error correction used in *audio* playback (but not data readback!) to re-interpolate the data back to what was intended (they hope), therefore a data read gives the wrong data, and an audio play works.
This makes *big* assumptions about how the cd supplies data in audio versus data modes, and is apparently not true for all cdroms (and very few dvd roms), so does not always work.
it also assumes that an audio cd player uses a 'standard' interpolation method, any that use a different (maybe even improved) method will produce less accurate 'solutions' to their intentionally introduced errors.
hmm, the whole thing is a house of cards, and will no doubt fall over before long.
I have 'dark sun', and have read much wider than that on the subject. The russians were held up a LOT in the earlier development of fission as their leaders got the idea into their heads that fission was not possible very early on, they did not believe a lot of their own earlier spy information, and thus lost a lot of ground, they could have quite possibly lead the US if this had not happened.
So in reality both sides ignored their 'information', the russians since they initially believed fission was impossible, and the americans, not believing the russians were so far behind.
certainly the information flowing from the US helped the russians catch up faster than they otherwise might have, but they still had to do a lot of work to implement what they found out, and you can never quirte catch up by following!.
One very important fact to remember is that the Russians (and Germans) around this time were using an incorrect estimate of the cross section of uranium, which did seem to indicate that sustained fission was not possible. The Americans managed to get a different (and later proven more accurate) measurement, which showed that a chain reaction was possible, this is one of the major reasons the Russians ended up so far behind at first in the atomic race.
The Germans and Russians certainly had a large initial lead in the more theoretical aspects of radiation and atomic physics, however this one incorrect measurement certainly threw the Russians so far off the track that it basically stopped their work in the area for quite a few years.
The Americans for a long time refused to believe how far behind the Russians were, and managed to loose much advantage by following politically 'suitable' beliefs rather than believing their own intelligence information, whcih turned out to be quite accurate with respect to the Russian position.
On the flip side, both of these men were great scientists, I personally feel it is immaterial whos 'side' they were on in a war.
ok, so replace encryption with one way hashing. It's effectively the same thing here, it enhances the security of your passwords, a very very welcome step, and not something to be treated lightly.
One of the biggest problems I have with database servers are all the passwords that end up floating around semi-protected, this is a GREAT new feature!
I have no doubt humanity is still evolving, the question it, in what direction? remember, evolution is driven by changes that extend breeding probability (not intelligence or lifespan, etc..), so what increases our chances of breeding??
Interesting question, I think. A little scary if you think about it too much.
no, that was a nice try, perhaps you need to find out the difference between peak peformance and actualy performance.
For the macs, you are quoting an unobtainable (in real terms) peak of 7 to 8 floating point instructions PER CYCLE, not even close, not even for altivec code.
For the athlon, which also has a reasonable vector unit, you only allow just over one per cycle, hmm, a little biased aren't we?
Of course, there are now well priced P4's with a great vector unit (SSE2), and A COMPILER THAT ACTUALLY USES IT, which, in a real world situation, will blow the doors off either of these processors (and no, I'm not talking about photoshop, try overblown or some other suitably complex solver app). at around $170US per 1.6G CPU these are a great deal at present!
I would also like to know where you thing these G4's are going to get their data to execute 7GFlops, from their PC133 SDRAM? don't make me laugh.
Scientific computation is a complex business, and nothing at all like other areas, a good compiler is the number one requirement, and damn fast memory is a big second, to keep the CPU fed. A good CPU is required of course, but not the holy grail. For a good cluster price/performance is ALL that matters, and apple don't do that.
One mistake I've seen several times here on Slashdot, and often in other media, is that MEMS is related to Nano technology. This is not a fact.
MEMS technology is based on very well understood silicon chip production techniques (with a couple more stages usually:), and produces features of a size usually quite large by todays chip production standards, and not even close to atmoic scale.
Nanotechnology is a VERY different area, targeted at producing operating mechanical systems at close to atmoic scale, with all the associated advantages. This is a whole different can of worms, with almost no relation to MEMS technology.
As a basic exmaple, atmoic assembly is not possibly at a MEMS scale, but is at a Nano technology scale.
MEMS is simply the best we currently do at production levels, this does not mean it's nano scale any more than any previous 'smallest' was. It cannot scale to Nano scale systems, as the problems (and requirements) are not related. MEMS is just very small mechanics/engineering, Nano scale is physics at it's worst.
I personally feel the sooner TRUE Nano is seen for the unique advantages it holds the better, but often the smaller (hmmm...) advantages of MEMS cloud that issue.
Did you actually bother to check the link or look into any of the background to this?
if you look at
http://mail.gnome.org/archives/foundation-list/2 00 1-October/msg00049.html
you will see a more direct quote (although not the most damaging by a long way).
The 'hearsay evidence' is a public disclusure of discussions between RMS and Christian Schaller, who authors the GNOME summaries (and has done for some time, doing a fantastic job). He has been strongly backed in this particular event by people such as Alan Cox and Miguel de Icaza. This is not a case of anonymous rumour-mongering.
Perhaps you should learn to investigate issues rather than just defending people 'on principle'.
What utter rubish, 'GNOME' is not an entity, nor are many of it's developers, or people helping with such things as maining lists, etc. The 'GNOME Foundation' may be, but that certainly does not cover all that is gnome.
The people who are being *very* *damb* *generous* in working on the GNOME project have *NOT* bought into anything, they are just people who should be appreciated, not trampled upon due to differing ideologies.
If RMS, and the FSF, require absolute censure over everything that is related to the GNU project, then they had better make that *VERY* clear, include it in their licenses, and then see how many people are willing to continue to so generously help them.
I personally think RMS needs to get back to considering the workers who have put him in such a strong position, rather than trying to pressure them into doing his bidding over small idealogical details.
As a developer I find it harder and harder to place my work under the GPL, *purely* because of RMS's attempts to control all things related to it. Visionary or dictator? time and actions will tell.
And they CAN choose to run what they want, no one is forcing anyone to run anything here.
What RMS is trying to do is block people from even being TOLD about software which is not part of his empire.
The software he is trying to block (StarOffice, and by association OpenOffice) is certainly what I think most level headed people would consider 'free', however he doesn't want people to know about it, possibly the knowledge would poison their brains, turning them into rabid M%@#&soft zombies or something.
Perhaps he needs to do a little more reading w.r.t. his 'free as in speach' concept, and stop trying to block people from finding out about what is VERY useful software.
I use OpenOffice, it works well, and it's free, I'm very happy about that, it saves me rebooting to read the one or two Msoft office documents I get per week.
From what I can tell this software is:
a - available if you pay for it only (I'm sure they call this a distribution fee, but why no free download?)
and
b - only available *to* *US* *citizens*
Both of these are fair enough, the US paid for the software (via government funding of NASA) and they cann't be forced to give it away, but this is *not* public domain software, it is simply put in a more public place.
A lot of this software has always been available, so long as you knew who to ask, and would pay the fee for distribution, and were a US citizen, and signed the agreements, etc, etc, so not much has changed I guess.
Of course everyone knows that us in the non-US part of the world are still dragging our knuckles on the ground and trying to work out what to use fire for, but we still seem to find uses for this kind of software, believe it or not. I know, I use Overture from LANL for flow solving, it's MUCH more open source, and more free, and (to be honest) better than anything NASA has yet made available in this area.
For all the good(ish) things about perl (a massive developer community, libraries to do ANYTHING, reasonable performance under mod_perl, and instant recognition), describing perl as:
'Through the use of Perl's object-oriented features and some basic coding rules, you can build a set of code that is a pleasure to maintain, or at least no worse than other languages.'
is rather laughable.
Perl has a tacked-on-the-side OO layer that kind of works if you are careful, and I don't think anyone would argue against the well known write-only feature of perl code. Maintainable yes, equal to other languages? Less likely.
However, I find the most interesting part of the article the switch from MySQL (popular, but has REAL trouble scaling, I know I will get flamed for that, but it is my real experience) to Oracle. I wonder what other systems were tested? If they were getting a significant speedup with a berkely-db cache of serialised objects, then they were not getting a lot of performance from their database.
I would have been very interested in a comparison between their Oracle setup and a PostgreSQL system, given their need for local caching running a PostgreSQL cache on each machine could have been quite a win.
Their code samples given certainly do not represent 'clean and maintainable code' to my eye. perhaps they should invest in a python book, possibly the most readable language I have yet found (but will not stop looking).
You were not running the drive on the HPT366 ATA100 controller on the BP6, and the (I'm afraid to say as I have several) notorious instability of the BP6 could not have contributed?
There is starting to be some indications that these drives fail (which they should not..) when faced with 'unusual' setups, which both the BP6, and nearly anything combining Via and AMD, certainly count as.
As to vibration, it's quite impressive to see how fast drives die when used in a moderate vibration area (my experience, operating in moving vehicles), those G limits they publish are for single-shot events, not repetitive, we get drive failing a lot, notable the fater the rotation rate, the worse they seem to be (makes a lot of sense..)
Having done plenty of QNX development in the 'oldn days, the largest problem with it is the lack ov VM, and the memory thirst it tends to have. True, it can be cut right back for a specifically targeted embedded application, and VM can ge bad for real-time, but the memory footprint for a desktop application tend to be VERY big due to the lack of VM (you need enough ram for EVERYTHING at once..), and you tend to end up with a lot of stuff loaded, we generally ended up using pretty highly speced machines for QNX development, much higher than we needed for Linux, for example:(.
Also, it used to have VERY poor hardware support and a down right wierd networking layer below TCP, but hey, maybe these things have improved.
of course, YMMV, although there are now versions of Linux that are just as good at being used for embedded apps.
Slashdot Mirror
The unfortunate part is that intel may very well kill of rambus in the 'consumer' level (ie: where the best price/performance tends to be for computational clusters), to a large extent due to 'public' misunderstanding of benchmarks. A lot of people think that ddr is as good as rambus.
For example, a lot of people trot out the 'latency' issues without understanding them. ddr requires a lengthy burst read of *64* bit wide data to achieve it's bandwidth, while rambus, also needing a brust read, reads only 16 bits per, resulting in a more 'localised' abiity to read memory, and therefore less wasted reads, which amounts to less wasted memory bandwidth.
It is very interesting to have a look at the memory subsystems used in mainframes, where it is very normal to have a large number of effectively seperate, and not very wide, memory busses to allow much more efficient 'scattered' data reads without generating false dependencies between memory addresses.
Ahh yes, but they don't derive, look at their view of such things as:
'the kings new groove' (reality, the spaniards turned up and killed/tortured everyone)
'the hunchback of notre dame' (reality, being killed for looking different)
'pocahontis' (nope, I'm not even going to touch that one).
'anastasia' (reality, the violent murder of the russian royal family)
they certainly aren't COPYING stories, just rewriting history to be SO MUCH NICER, what more can we ask from our leaders (sorry, I mean media).
Unfortunately, I get around a !20%! speed advantage using rambus over ddr-sdram for serious scientific computations (large matrix inversions, primarily, for simultanious equation solutions).
Rambus SIGNIFICANTLY kicks the arse of DDR (and certainly standard sdram), and the extra cost is well worth it in these situations. I wish people would stop trying to benchmark 'high-end' equipment by running office suite benchmarks on it and then think they are actually testing anything.
Good code (and trust me, with runtimes in the days it is WELL worth having good code for these problems) does actually make use of the full capabilities of rambus, and ddr doen't even come close to catching up.
I would love to see them produce 64-bit wide rambus dimms (the same width as ddr-sdram) as opposed to the current 16 bits wide, and THEN see the ddr try to keep up, as this would give them equivalent circuit board resource usage.
The future of RAM (well, for a while) will be rambus type busses, as they make much more effective use of pins on the chipsets, and pins are becoming a scarce resource (look at the pincounts for the new hammer line from AMD if you don't believe me), allowing rambus to support many moer busses than ddr.
Politically rambus is a complete failure, which is a pity, the technology is absolutly great, as is the real-world preformance FOR THOSE WHO NEED IT.
With all the 'public' money spent on space research, I wonder when we will start to see decent data available for the earth?
Yes, I know about terraserver, which is rather pathetic outside the US.
We know the planet has been mapped (rather a few times I bet), but many goverments seem to like to keep that data 'private' and sell it off for LARGE amounts of money.
I bet a lot of us could find fantastic uses for even 100m per value topographical data for the whole planet, not just the bits we are 'allowed' access to.
And please no one tell me it's for security reasons, as often the best data can be accessed for the 'secure' regions (ie: most of the US is easy, but try and get pitcairn island).
Imaging the fun of exploring a whole virtual planet, admitedly not up close, but there is a lot of truely wonderful topography to our planet.
the 'regulations' define the allowable total output power, the amount of 'focusing' you do is not controlled, since this does not ever actually increase the total output power.
the 'soup can' is a very crappy setup, it lowers the total ouput power a LOT (due to impedance mismatches) and gains a little by focusing this lower power reasonably. the helical actually has an impedance transformer, so uses all the power you have, a much better setup.
may I sugest you read up a little on radio transmission, and all will become clear.
These things perform miserably, for a much better design, have a look at:
http://users.bigpond.net.au/jhecker/
For a 2.4GHz hellical that is simple to build, these things are great.
This page gives actually useful measurements and a great bulding guide. I would (and do) use one of these over these non-functioning cans any day.
From my experience, NT doesn't so much have a guaranteed latency time as a probable crash time.
This is NOT a troll, NT makes it VERY hard to meet any true real-time requirements without writing at the driver level, which is a massive pain, and exposes you to BIG risks in destabilising the machine.
Linux currently (without these patches) has very good average latency, with these patches it has fantastic worst-case latency, windows CE (which is supposed to be real-time) cannot match it.
Windows hides behind it's multimedia guaranteed latency capabilities, fine if you want to do multi media, useless if you need machine control, or other real-time requirements.
- A clean, SIMPLE, powerfull core language
:)
;), 90% of the functionality with 1% of the complexity, and great cross-platform support to boot!
- Data types that make life easy (lists/dictionaries)
- A FANTASTIC set of cross-platform libraries
- A GREAT standard and simple GUI library (Tk)
- A GREAT powerful GUI library (WX)
Things I would love about python
- A compiler (very hard, but I can dream)
- Smaller/more tunable installs
- wxWindows built in
Python is the 'simple c++' I was always looking for and have now found
As a developer, I just love it. Python reduces my development time significantly, and also allows me to express algorithms in a logic way, without fighting the language. This is a VERY important feature. It lowers development stress, so I can spend more time working and less time reading language manuals.
You have to be kidding. Python is certainly not 'just a scripting language', I personally have written some rather major software using it, and find it a fantastic tool.
It finally answered the question that had been sitting in the back of my mind WRT C++, ie: 'this is good, but not quite what I want, it's overkill, but what is wrong?'. Python makes complex tasks my simpler, and does not try and make simple tasks appear complex.
The lack of a true compiler (and also good linking system) is an issue, but not, IMHO, a major one, there are options available (pyco, py2exe, JPython, etc) that partially address this, but more often it is not a real issue.
Python has probably doubled my efficiency as a developer, which is no small feat. C++ was probably the last tool to come close to that, and the startup time on c++ was around 6 months, python was closer to 2 weeks!
two points.
Firstly, there was quite a fuss with analogue recording (primarily with video, but also with the start of the compact casette tape), it was, as you say, addressed with a 'media corperate' tax being applied to these items, and the feared drop in profits never happened (infact quite the opposite), so the recording industry made big $$ out of this.
Secondly, the reason this *should* not happen to newer digital media is that a crapload of this is NOT used to record copywrited, stolen, artistic stuff. Much (most?) of the writable digital media (cdrom, harddrives, dvd, etc) are use for storage of computer data.
I would be VERY annoyed if these same companies manage to get a tax added to the rice of every HD/writable CD/etc, and believe me, they are trying, as they know this is free money for them!
This system works by making the 'bits' (ie: data stream) on the cd *wrong*, and by expecting the error correction used in *audio* playback (but not data readback!) to re-interpolate the data back to what was intended (they hope), therefore a data read gives the wrong data, and an audio play works.
This makes *big* assumptions about how the cd supplies data in audio versus data modes, and is apparently not true for all cdroms (and very few dvd roms), so does not always work.
it also assumes that an audio cd player uses a 'standard' interpolation method, any that use a different (maybe even improved) method will produce less accurate 'solutions' to their intentionally introduced errors.
hmm, the whole thing is a house of cards, and will no doubt fall over before long.
I have 'dark sun', and have read much wider than that on the subject. The russians were held up a LOT in the earlier development of fission as their leaders got the idea into their heads that fission was not possible very early on, they did not believe a lot of their own earlier spy information, and thus lost a lot of ground, they could have quite possibly lead the US if this had not happened.
So in reality both sides ignored their 'information', the russians since they initially believed fission was impossible, and the americans, not believing the russians were so far behind.
certainly the information flowing from the US helped the russians catch up faster than they otherwise might have, but they still had to do a lot of work to implement what they found out, and you can never quirte catch up by following!.
One very important fact to remember is that the Russians (and Germans) around this time were using an incorrect estimate of the cross section of uranium, which did seem to indicate that sustained fission was not possible. The Americans managed to get a different (and later proven more accurate) measurement, which showed that a chain reaction was possible, this is one of the major reasons the Russians ended up so far behind at first in the atomic race.
The Germans and Russians certainly had a large initial lead in the more theoretical aspects of radiation and atomic physics, however this one incorrect measurement certainly threw the Russians so far off the track that it basically stopped their work in the area for quite a few years.
The Americans for a long time refused to believe how far behind the Russians were, and managed to loose much advantage by following politically 'suitable' beliefs rather than believing their own intelligence information, whcih turned out to be quite accurate with respect to the Russian position.
On the flip side, both of these men were great scientists, I personally feel it is immaterial whos 'side' they were on in a war.
ok, so replace encryption with one way hashing. It's effectively the same thing here, it enhances the security of your passwords, a very very welcome step, and not something to be treated lightly.
One of the biggest problems I have with database servers are all the passwords that end up floating around semi-protected, this is a GREAT new feature!
Simply put, where do you want to evolve to today?
no, sorry, wrong thread.
I have no doubt humanity is still evolving, the question it, in what direction? remember, evolution is driven by changes that extend breeding probability (not intelligence or lifespan, etc..), so what increases our chances of breeding??
Interesting question, I think. A little scary if you think about it too much.
no, that was a nice try, perhaps you need to find out the difference between peak peformance and actualy performance.
For the macs, you are quoting an unobtainable (in real terms) peak of 7 to 8 floating point instructions PER CYCLE, not even close, not even for altivec code.
For the athlon, which also has a reasonable vector unit, you only allow just over one per cycle, hmm, a little biased aren't we?
Of course, there are now well priced P4's with a great vector unit (SSE2), and A COMPILER THAT ACTUALLY USES IT, which, in a real world situation, will blow the doors off either of these processors (and no, I'm not talking about photoshop, try overblown or some other suitably complex solver app). at around $170US per 1.6G CPU these are a great deal at present!
I would also like to know where you thing these G4's are going to get their data to execute 7GFlops, from their PC133 SDRAM? don't make me laugh.
Scientific computation is a complex business, and nothing at all like other areas, a good compiler is the number one requirement, and damn fast memory is a big second, to keep the CPU fed. A good CPU is required of course, but not the holy grail. For a good cluster price/performance is ALL that matters, and apple don't do that.
One mistake I've seen several times here on Slashdot, and often in other media, is that MEMS is related to Nano technology. This is not a fact.
:), and produces features of a size usually quite large by todays chip production standards, and not even close to atmoic scale.
MEMS technology is based on very well understood silicon chip production techniques (with a couple more stages usually
Nanotechnology is a VERY different area, targeted at producing operating mechanical systems at close to atmoic scale, with all the associated advantages. This is a whole different can of worms, with almost no relation to MEMS technology.
As a basic exmaple, atmoic assembly is not possibly at a MEMS scale, but is at a Nano technology scale.
MEMS is simply the best we currently do at production levels, this does not mean it's nano scale any more than any previous 'smallest' was. It cannot scale to Nano scale systems, as the problems (and requirements) are not related. MEMS is just very small mechanics/engineering, Nano scale is physics at it's worst.
I personally feel the sooner TRUE Nano is seen for the unique advantages it holds the better, but often the smaller (hmmm...) advantages of MEMS cloud that issue.
Did you actually bother to check the link or look into any of the background to this?
2 00 1-October/msg00049.html
if you look at
http://mail.gnome.org/archives/foundation-list/
you will see a more direct quote (although not the most damaging by a long way).
The 'hearsay evidence' is a public disclusure of discussions between RMS and Christian Schaller, who authors the GNOME summaries (and has done for some time, doing a fantastic job). He has been strongly backed in this particular event by people such as Alan Cox and Miguel de Icaza. This is not a case of anonymous rumour-mongering.
Perhaps you should learn to investigate issues rather than just defending people 'on principle'.
What utter rubish, 'GNOME' is not an entity, nor are many of it's developers, or people helping with such things as maining lists, etc. The 'GNOME Foundation' may be, but that certainly does not cover all that is gnome.
The people who are being *very* *damb* *generous* in working on the GNOME project have *NOT* bought into anything, they are just people who should be appreciated, not trampled upon due to differing ideologies.
If RMS, and the FSF, require absolute censure over everything that is related to the GNU project, then they had better make that *VERY* clear, include it in their licenses, and then see how many people are willing to continue to so generously help them.
I personally think RMS needs to get back to considering the workers who have put him in such a strong position, rather than trying to pressure them into doing his bidding over small idealogical details.
As a developer I find it harder and harder to place my work under the GPL, *purely* because of RMS's attempts to control all things related to it. Visionary or dictator? time and actions will tell.
And they CAN choose to run what they want, no one is forcing anyone to run anything here.
What RMS is trying to do is block people from even being TOLD about software which is not part of his empire.
The software he is trying to block (StarOffice, and by association OpenOffice) is certainly what I think most level headed people would consider 'free', however he doesn't want people to know about it, possibly the knowledge would poison their brains, turning them into rabid M%@#&soft zombies or something.
Perhaps he needs to do a little more reading w.r.t. his 'free as in speach' concept, and stop trying to block people from finding out about what is VERY useful software.
I use OpenOffice, it works well, and it's free, I'm very happy about that, it saves me rebooting to read the one or two Msoft office documents I get per week.
From what I can tell this software is:
a - available if you pay for it only (I'm sure they call this a distribution fee, but why no free download?)
and
b - only available *to* *US* *citizens*
Both of these are fair enough, the US paid for the software (via government funding of NASA) and they cann't be forced to give it away, but this is *not* public domain software, it is simply put in a more public place.
A lot of this software has always been available, so long as you knew who to ask, and would pay the fee for distribution, and were a US citizen, and signed the agreements, etc, etc, so not much has changed I guess.
Of course everyone knows that us in the non-US part of the world are still dragging our knuckles on the ground and trying to work out what to use fire for, but we still seem to find uses for this kind of software, believe it or not. I know, I use Overture from LANL for flow solving, it's MUCH more open source, and more free, and (to be honest) better than anything NASA has yet made available in this area.
For all the good(ish) things about perl (a massive developer community, libraries to do ANYTHING, reasonable performance under mod_perl, and instant recognition), describing perl as:
'Through the use of Perl's object-oriented features and some basic coding rules, you can build a set of code that is a pleasure to maintain, or at least no worse than other languages.'
is rather laughable.
Perl has a tacked-on-the-side OO layer that kind of works if you are careful, and I don't think anyone would argue against the well known write-only feature of perl code. Maintainable yes, equal to other languages? Less likely.
However, I find the most interesting part of the article the switch from MySQL (popular, but has REAL trouble scaling, I know I will get flamed for that, but it is my real experience) to Oracle. I wonder what other systems were tested? If they were getting a significant speedup with a berkely-db cache of serialised objects, then they were not getting a lot of performance from their database.
I would have been very interested in a comparison between their Oracle setup and a PostgreSQL system, given their need for local caching running a PostgreSQL cache on each machine could have been quite a win.
Their code samples given certainly do not represent 'clean and maintainable code' to my eye. perhaps they should invest in a python book, possibly the most readable language I have yet found (but will not stop looking).
You were not running the drive on the HPT366 ATA100 controller on the BP6, and the (I'm afraid to say as I have several) notorious instability of the BP6 could not have contributed?
There is starting to be some indications that these drives fail (which they should not..) when faced with 'unusual' setups, which both the BP6, and nearly anything combining Via and AMD, certainly count as.
As to vibration, it's quite impressive to see how fast drives die when used in a moderate vibration area (my experience, operating in moving vehicles), those G limits they publish are for single-shot events, not repetitive, we get drive failing a lot, notable the fater the rotation rate, the worse they seem to be (makes a lot of sense..)
Having done plenty of QNX development in the 'oldn days, the largest problem with it is the lack ov VM, and the memory thirst it tends to have. :(.
True, it can be cut right back for a specifically targeted embedded application, and VM can ge bad for real-time, but the memory footprint for a desktop application tend to be VERY big due to the lack of VM (you need enough ram for EVERYTHING at once..), and you tend to end up with a lot of stuff loaded, we generally ended up using pretty highly speced machines for QNX development, much higher than we needed for Linux, for example
Also, it used to have VERY poor hardware support and a down right wierd networking layer below TCP, but hey, maybe these things have improved.
of course, YMMV, although there are now versions of Linux that are just as good at being used for embedded apps.