Slashdot Mirror

Release some CRM software that doesn't suck (please, pretty please do that) and watch how quickly you get "embraced".

• Chordiant
• Genesys
• Kana
• Epiphany
• Siebel (well, OK, eaten by Oracle - I'll give you that one, even though you meant "embraced by Microsoft")
• Salesforce.com
• Teradata
• SAS
• Aprimo
• SAP
• Amdocs
• Unica

Release some CRM software that doesn't suck (please, pretty please do that) and watch how quickly you get "embraced".

• Chordiant
• Genesys
• Kana
• Epiphany
• Siebel (well, OK, eaten by Oracle - I'll give you that one, even though you meant "embraced by Microsoft")
• Salesforce.com
• Teradata
• SAS
• Aprimo
• SAP
• Amdocs
• Unica

A good start would be to not use tape. I don't know what actual the percentage of tape failures is (and they're not telling), but in my own experience it's pretty high. Hard disks and PCs are cheap enough that every movie could have its own little RAID array somewhere.

In addition, tape has two major advantages over HDD. The first is the ability to remove a cartridge to a completely separate location for safekeeping, and the second is the stability of the storage media over time. Tape is considerably more stable over long periods (years) of inactive time, whereas HDD mechanisms must be activated periodically (every few months) to maintain viability.

That equates to x object locks required - which is a relatively expensive operation.

Not really. Even by 1.3 for many cases synchronization costs were often quite small. There is no compeeling reason these days to afraid of the performance penalty of method/object synchronization.

You're kind of thinking of Chandler, which could grow into an OpenSource Notes. IBM still makes real money with Notes, so they're not going to Open-Source it, but they will happily sell you an installation and a consultant in a blue suit.

Notes vs. Exchange is kind of one of those VI vs Emacs things; binary opinions only, and users are all willing to carry a sharpened Pike to defend their choice. What we really need is the email equivalent of the introduction of gunpowder to make this argument irrelevant.

I don't know why you think NFS doesn't support failover; check out Red Hat Cluster (PDF) or Sun Cluster. You will need a RAID array that has two host ports, such as VTrak E310s, IBM DS3200, HP StorageWorks 500, or Xserve RAID.

I would not suggest cluster file systems such as Lustre for a small installation; they're generally designed to scale up to hundreds or thousands of servers, but not to scale down to a handful.

I think the project you're referring to is Xdmx. Here's a decent tutorial.

"Time Machine" for Windows. Perhaps not easy enough for a grandmother to use but definitely easy enough for the average PHB.

http://www-306.ibm.com/software/tivoli/products/co ntinuous-data-protection/

There is a free trial too...

On the really Big Iron, IBM doesn't care either, because they have AIX. Yes those machines will run Linux, but they'll run other, more tightly-controlled, highly-optimized, technologies as well. It's all scale, and at the low end, Intel/AMD has the scale. At the higher-end, then Power + proprietary OS + services becomes competitive. Home desktop is uninteresting because the margins are too thin, product cycles short, and the after-market services non-existant.

The other side is that they still have low-end, 1-4 core Linux-compatible systems, which clock in starting at $3K each. Most of these compete nicely against Itanium or late Alpha systems, and outpace Opterons. In the HPC arena, nothing else has the floating-point chops except the IA-64, and it's not clear that Intel/HP have the guts to push it hard enough to compete. The Power systems are not going to wither away, especially as they gain an increasing foothold in High-performance systems, as well as being the core of IBM's Z-series main-frames and smaller systems. IBM has decided on the customer size it wants to deal with, and unsurprisingly, that size is large, with margins. They're returning to their roots. You'll probably see Sparc and IA-64 dropped long before Power is.

On the really Big Iron, IBM doesn't care either, because they have AIX. Yes those machines will run Linux, but they'll run other, more tightly-controlled, highly-optimized, technologies as well. It's all scale, and at the low end, Intel/AMD has the scale. At the higher-end, then Power + proprietary OS + services becomes competitive. Home desktop is uninteresting because the margins are too thin, product cycles short, and the after-market services non-existant.

The other side is that they still have low-end, 1-4 core Linux-compatible systems, which clock in starting at $3K each. Most of these compete nicely against Itanium or late Alpha systems, and outpace Opterons. In the HPC arena, nothing else has the floating-point chops except the IA-64, and it's not clear that Intel/HP have the guts to push it hard enough to compete. The Power systems are not going to wither away, especially as they gain an increasing foothold in High-performance systems, as well as being the core of IBM's Z-series main-frames and smaller systems. IBM has decided on the customer size it wants to deal with, and unsurprisingly, that size is large, with margins. They're returning to their roots. You'll probably see Sparc and IA-64 dropped long before Power is.

It looks like they might be planning to pump liquid between the layers:

http://www.zurich.ibm.com/st/cooling/integrated.ht ml

http://www.research.ibm.com/journal/rd/504/topol.h tml

http://domino.watson.ibm.com/comm/pr.nsf/pages/new s.20021111_3d_ic.html

http://www.research.ibm.com/journal/rd/504/topol.h tml

http://domino.watson.ibm.com/comm/pr.nsf/pages/new s.20021111_3d_ic.html

Not sure about the 128 SIMDs. The PS3's cell processor has 7 so-called SPUs (Synergistic Processor Units), basically coprocessors that work on a 256k separate internal storage. If your code is embarassingly parallel, you can greatly benefit from this architecture.

The hard-coded floating point unit is single-precision indeed, and doesn't implement the full IEEE floating point spec, which raises eyebrows in the scientific double-precision junky crowd. The individual registers are 128-bit, although they are organized as 4 32-bit words.

Here is a nice little intro to the beast: http://www-128.ibm.com/developerworks/linux/librar y/pa-linuxps3-1/index.html?ca=drs-

I've owned a Treo 300, 600 and 700. I've read PDF's on all of them.

HOWEVER: It is not easy. The best is the 700. The high-res screen (320x320) makes a big difference. But even then, you're talking about using a device that has a screen that's 2 inches x 2 inches to try to read a document formatted for 8.5 x 11. The whole idea of a PDF is to preserve precise paper-based formatting. Working with that on a handheld is awkward at best.

Your best option is to convert the PDF to text and read the text on the PDF, using some sort of eReader (Plucker or ,A HREF="http://www.isilo.com/">iSilo come to mind). I read lots of PG material that way, as well as IBM Redbooks that I've converted to text.

Yet human vision is even better than reported since is able to perceive misalignment in lines and curves (e.g aliasing pattern) at sub-receptor accuracy - see Venier Acuity: e.g http://www.pc.ibm.com/ww/healthycomputing/vdt13eye e.html

This article is more in the vein of "Windows to Linux Roadmap", another useful article from this group. This is great stuff if you are interested in weaning non-guru users off of Windows. http://www-128.ibm.com/developerworks/linux/librar y/l-roadmap.html/ And IMO it's certainly more interesting fare than yet another breathtaking article on the implications of taxing linden dollars.

The article may or may not belong on the front page, but claiming someone's illiterate for not knowing stuff like this, especially if they were in an Apple or MS shop? Heaven forbid.

Actually, IBM does target me. I develop server side applications. I haven't used their WebSphere application server in years. What I remember about it is great reliability, great performance, and a bit of a nightmare to administer. Things are most probably different now. I admit that I have not kept up to date on WebSphere. What I remember about it was that it had a funky directory structure. At the time, I was in a J2EE portal infrastructure company whose products had to run on all the popular application containers. If code was going to have a container dependent issue, it was always going to be with WebSphere.

My feelings about DB2 are similar; great performance, great reliability, not developer friendly. Of all the modern, enterprise worthy DBMSs out there, only DB2 doesn't support automatic generation of artificial keys. MS SQL Server has the identity keyword. MySql has the auto_increment keyword. Oracle has the sequence object. Postgresql has the serial type. What does DB2 have? Nothing. Nada. According to DB2 gurus, artificial keys are bad and natural keys are good. So, the user always has to type in the primary key to retrieve a record. Ha, ha, imagine having to type in the ISBN if you wanted to look up a book on Amazon.

I just got this from IBM's about page.

Perhaps they are neither a software nor hardware company. Perhaps they are a solutions company.

Last year, IBM reported over $18 billion in revenue from Software alone. Which is more total revenue than Oracle, SAP, and every other software company not named Microsoft earned last year. I'd say IBM already is great software company (or at least a large one).

This seems to be part of a campaign bend apple into more of a green product.

On their own page, they go as far as manipulating the truth to make it appear that
Apple is doing less work than it is actually doing: http://www.greenpeace.org/apple/about.html

"Apple finally came around to a limited recycling program in the US, but they can do better."

This is worded as if it just happened recently. Except that the US (and Japan) take-back program started
up in 2002. (Announced in 2001) It includes not only recycling of its own computers, but also other
vendor's computers and monitors. I wonder which way they consider this to be "limited"?

http://www.apple.com/environment/recycling/
http://www.apple.com/environment/

The images at the top of the Greenpeace site show Chinese children holding color iMac keyboards dating
before 2000.... before recycling programs in the US and Asia actually existed.

The page is designed to get Apple to do two things:
        * Remove the worst toxic chemicals from all their products and production lines.
        * Offer and promote free "take-back" for all their products everywhere they are sold.

The question here is, is it reasonable to persecute Apple for not meeting an arbitrarily set "worst toxic chemicals" goal? And I say this because "worst toxic chemicals" is fairly ambiguous.
They recycle plastics, foam, paper and whatnot from their products, they follow a number of environmental standards in the US and Europe and maintain their own.

Should Apple offer free "take-back" worldwide? Even Levono doesn't do so.
http://www.pc.ibm.com/ww/lenovo/about/environment/ ptb_us.html

However, in the very least, it should be reasonable for Apple to accept recycled equipment worldwide, if at
a fee.

I find it interesting which ones of the object-recognition and scene categorization algorithms make it to Slashdot.
Why does this one make it?
This is a very hot research topic at the moment.
to name a couple of groups:

http://www.robots.ox.ac.uk/~vgg/
http://lear.inrialpes.fr/
http://www.vision.caltech.edu/
http://www.science.uva.nl/research/isla/
http://www.cdvp.dcu.ie/
http://www.informedia.cs.cmu.edu/
http://www.research.ibm.com/slam/
http://www.ee.columbia.edu/ln/dvmm/newResearch.htm

oh, and people should not stare themselves blind on the claimed results.
Research papers *always* have to present good results, or else you do not get published.
Furthermore, these images are of a very high quality, make by professional photographers.
Many algorithms perform very well on these ('corel'-like) sets, while utterly failing if applied on real-world data:
http://www-nlpir.nist.gov/projects/trecvid/

You're going to have to make a more coherent argument than a simple google search, especially one where the first hit actually explains how MacOSX is POSIX complient and based on FreeBSD and NeXTStep, both of which are bonified unicies. So unless your argument is "If it looks like a duck and quacks like duck, it must be rock," then try again.

My hardware is supported.

I've never seen hardware 100% supported under linux.

Wireless drivers that don't support WPA

Graphics cards that don't support 3d acceleration.

Kernels having to be patched for usb support.

Hell, I had to actually patch (i.e. modify the source) to get linux to recognize my digital camera (a Sony DSC-F707)

even though it was supported as a simple usb storage device.

(The patch was incrementing a hex number in unusualdevs.h. Simple yes, but completely unacceptable.) Modules that refuse to insert automatically.

Again, the implication is that somehow the popular computer (e.g., a "PC") pre-dated the Apple's adoption of the standard whereas the exact opposite is true. It was only after the Macintosh adopted USB that the standard actually took off. Here is a link for a more accurate history of this transition: http://www-128.ibm.com/developerworks/power/librar y/pa-spec7.html

The author neglects to take into account that although there is only one overarching "USB Protocol" you still need to explain to your grandmother why she needs to use a cable with an "A" port instead of a "B" port or a mini USB 2.0 port, or the Canon USB port.... Still, I agree that this is a great deal better than we had prior to the adoption of USB.

The article itself was generally correct in its assessment of the impact of the USB port on industry. I just take issue with the rewriting of history as I (and I am sure, many of you) were there to witness it firsthand.

I've been using macs for the bulk of my computing for over a decade, so I'm well aware that there's plenty of software available for most every need. Most of my issues have been with a few very specific pieces of software, but unfortunately life puts me in positions where I can't always choose how I'm going to solve a problem.

You showed my point, it's not so much that Macs can't do what's needed or don't have the apps to do them, it all boils down to what apps the employer demands be used. You say you're an architect and use AutoCAD, is there anything AutoCAD can do that CAD software for Macs can't do? I don't know if you know of it but there is a community of Mac users of CAD program, Architosh. I found it when I searched for CAD programs for Macs, I plan on getting a Mac and wanted to see what CAD was available for Macs. Also though AutoCAD is probably the most widely known CAD isn't CATIA the 800 lb gorilla?

Luckily, or unluckily depending on how you want to look a it, currently I am on disability and don't work but I'm hoping to start my own business this year so I'll be in a position to decide what sort of software will do what I want then choose the hardware and OS based on that. So far I haven't found any software app I will need that is not available for Macs. Linux is another matter, it has some but not the big or important app I'll want to get, Photoshop, otherwise it would work for me. What I want to do is to become a pro photographer as well as develop websites for other photographers.

I don't think it's publicly downloadable, but IBM has a tool called BEAM. http://www.research.ibm.com/da/beam.html

The results are okay from BEAM. Maybe you can submit a comment (see bottom of the page) to request use of the tool.

I've tried to use splint with mixed results. The default warnings were rather verbose, and most of them were unimportant.

Another open source project ran Coverity over our source code and sent us a summary of the results. The noise to signal ratio seemed better for BEAM and Coverity than splint. Though it's possible that the person running Coverity over our code turned off some warnings by default.

If you're interested in runtime tools in addition to static analysis tools, IBM Rational Purify (commercial) and valgrind (free) work fairly well. Each have their own issues. Both occasionally give false positives. The valgrind tool comes with many Linux distributions, but it's not really there for Windows.

Of course, those tools don't work effectively, unless you have a good test suite. IBM Rational PureCoverage help you to discover where code coverage is needed by your test suite. Our open source project aims for 100% API coverage and >85% overall line coverage for each release. While it's difficult to get some error conditions to be exercised and tested with the test suites, it's well worth it in the long run. It's satisfying to fix a bug, add a test for the bug, and see that your fix didn't break any of the other tests. You might also be able to use the gcc profile option to get similar functionality as PureCoverage, but it won't generate a summary graph to tell you if you're meeting your code coverage coverage goals.

The static analysis tools are good to test for things that you didn't think about testing, or didn't have time to test. None of these tools solve all your software stability problems, but they greatly improve the stability. Turning on compiler warnings for your application will find some minor issues, but the static analysis tools make it easier to find bugs that only appear if you analyze both the called function and the function caller.

(Full disclosure: I work on open source software at IBM)

As a programmer, I'm amused by you using floating point to store whole numbers.

The oddities of floating point math is also why many languages now have a decimal data type or library, emulating decimals using integer math.

IBM has one for C and C++.

As a programmer, I'm amused by you using floating point to store whole numbers.

The oddities of floating point math is also why many languages now have a decimal data type or library, emulating decimals using integer math.

IBM has one for C and C++.

mertz article

A coworker of mine who's quite a C/C++ jockey used it recently (this month), and said it's still very good.

However, as a pretty damn safe rule of thumb, no system is going to run faster on equivalent hardware after being virtualized.

Oddly enough, that's not as true as you'd think. I know that HP and IBM both had projects to virtual hardware (not in exactly VMWare style virtualization, more like a JIT optimization) where software ran faster after being virtualized. By about 20% if I remember correctly. HP's project was Dynamo and IBM's was DAISY.

Virtualizing a CPU at runtime in a JIT-optimization fashion can actually lead to a significant speed up. Some of this might have been pulled into CPU's by now, but I'm always surprised that more technology isn't moving this direction. Ultimately optimization at runtime has more information then at compile-time, and thus can apply optimizations not otherwise available.

Kirby

Here is the smaller unit I was thinking about, although I seem to recall a Japanese outfit building something similar. IMHO, this is stretching the limits of a useable UI. Probably not suitable for surfing the web.

not being an electronics expert, I could not find a copy of the actual paper, but this url http://www.zurich.ibm.com/news/07/cooling.html actually gives some details, so people can actually shoot their mouths off knowing what it is that is being trashed.

If that was the only issue at stake, he wouldn't be interested in OOo in the first place. He'd only need antiword, and something like this method of reading xls files. The objective here, however, is probably to be able to author MS Word documents as well. Otherwise he'd probably be using LaTeX.

Since you obviously have no clue what I was talking about I assume you are either a manager, and should be letting your programmers do their job, or you don't belong in a position to fire people.

I didn't say anything about reordering methods at all. What I was talking about was making your most frequently used references (or primitives for that matter) in a method be the first four (between method parameters and local references) and if at all possible making there be only 4 in total (including the 'this' reference for instance methods and constructors). This is part of the Java Byte Code and is clearly defined in the specification, if you want to read that. Any java developer worth paying knows byte code, wether they have ever actually written direct byte code or not. All load and store operations in byte code, the most common operations, have 5 different versions. There are 4 that have no arguments (i.e. aload_0 thru aload_3) and one that takes a single argument(i.e. aload x). The byte code specifications states that the first 4 versions will perform as well or better than the final one. On every implementation I have used the first 4 were significantly higher performing. This is because on most platforms those first 4 can be optimized to look at specific registers or register parts, while the last one must load from an in memory array, which at best requires multiple machine code operations against physical memory and at worst has to deal with the over head of virtual memory. Not to mention the fact that the byte code itself is more compact and can be parsed in half the time using the first 4 variants.

Needless to say that you have actually proven my point that understanding the underlying system is very important to actually understanding what effect you are having when writing code. The fact that you "would be sorely tempted to fire" a developer that was writing optimal code shows that you don't understand the effects that pessimal code has on your entire system. But then it's possible that Peter Haggar and I don't know what we are talking about, but I doubt it.

Denying the problem doesn't make it go away, really. All the hibernation and sleep modes in the world don't change the fact that Linux boot times are much longer than, say, Windows XP's.

I've never seen this happen. Reapeating this FUD does not convince me it is true.

for many laptops [power management does not work]

If your laptop does not work, you need to get your money back. Take it back and tell them why. Better yet, test it before you buy it. Don't buy things that waste your time.

Thinkpads usually work out of the box. I usually turn off ACPI and use APM, but ACPI works too.

SPU's do have local memory access. However, local memory access is not the same as unprotected memory access. All accesses to external memory (DMA) can be protected. DMA commands use the same type of translation and protection governed by the page and segment tables of the Power Architecture as the PPU (indeed there is MMU management for each Memory Flow Controller for each SPU). I suggest you read this paper to see the memory management on the SPU: http://www-128.ibm.com/developerworks/power/librar y/pa-celldmas/

The SPU's can run in a completely safe and sand-boxed environment with actual SPU threads and processes. In fact, you can set a secure "vault" mode in which the SPU is completely disconnected from external access and it's possible to ensure that SPU's are not capable of touching anything other than what is in their local memory (and nothing external can touch the SPU's local store in this mode).

If during normal SPU something goes wrong (i.e. access to a protected area), it's possible to kill the curren SPU process and restart the SPU with a new process -- neither that specific SPU nore the Cell processor need to be hung up by some bad SPU code. In this respect, it's possible to build a secure OS that allows SPU access. If something bad happens on an SPU, you can kill the offending process -- just like if something goes bad on a single core on a Core2Duo process, the linux kernel can kill the process. The machine won't go "tits up" -- just your process will get killed. But this is true of any bad program on any "secure" OS.

I don't know what you're claiming as a "supervisor" bit for memory protection. Perhaps you're referring to read/modify/execute (RWX) page settings on the page-table (and cached in the TLB) with virtualized memory access. The SPU's do not have a TLB for local store (although it is mapped into the PPU address space and that TLB). However, they can set up "privileged" areas in local memory (and local register address space - i.e. DMA regs) that can be used to accomplish memory protection for local store and access to non-allowed areas can cause an exception which the OS can then deal with appropriately. Additionally, there is an Local Store Limit Register (LSLR) to mask the available region of local store. Now witin the normally accessible area of local store, the SPU can store instructions and execute them allowing for self-modifying code. Before DEP on windows (and/or if your CPU is more than a year or two old and doesn't support execution page protection), you could make self-modfying code run in any region of writeable memory -- one reason why windows buffer overflows are so easy to exploit.

As far as the "this is how we program SPU's", sure you can program stuff to only run only 6 fixed SPU tasks with no swapping and use 256K data blocks (minus code overhead) so you have DMA latencies. However, you implied by stating those as limitations that was the *ONLY* way to program them which is wrong. All the papers out there from IBM and Sony suggest PREFERRED METHODS which are different than your implied limitation. They advocate cooperatively running multiple small task (dozens or even hundreds) rather than dedicating cores to fixed tasks and to double-buffer data (or even code) to mask DMA latencies. Singular task SPU usage can lead to idle SPU's very easily. Additionally, the double-buffer method can hide DMA latencies which can double the speed of your code if you're roughly equal on memory (DMA) and SPU compute time. We prefer to program SPU's in the manner in which they will be utilized much more fully and run up to 2X faster. I think anyone rewriting code for the SPU (since you have to retarget for the SPU anyway, there's no reason to write your code in a manner that will deliberately underperform).

Single precision floating point computation is geared for throughput of media and 3D graphics objects. In this vein, the decision to support only a subset of IEEE floating point arithmetic and sacrifice full IEEE compliance was driven by the target applications. Thus, multiple rounding modes and IEEE-compliant exceptions are typically unimportant for these workloads, and are not supported. This design decision is based the real time nature of game workloads and other media applications: most often, saturation is mathematically the right solution. Also, occasional small display glitches caused by saturation in a display frame is tolerable. On the other hand, incomplete rendering of a display frame, missing objects or tearing video due to long exception handling is objectionable.

Yeah, they're looking ahead too eagerly. That's what academics do.

Let's not forget that Intel and IBM both recently found a manufacturing process to keep Moore's law going for the next several years. Most people in 2006 thought we hit a wall, and that the multicore revolution was inevitably under way, but that just might not be true anymore. That said, it is always nice to have at least a few cores in available in your system.

At the same time, AMD's Fusion strategy looks pretty interesting. I really wonder what's going to become of that.

>> Building a space elevator using carbon nanotubes...that's advanced. Magnetic field
>> drives...that's advanced. Solar sails, antimatter engines, gravitational drives...all
>> advanced.

> All *fictional*. With the possible exception of solar sails, based on my understanding
> of those "technologies", they are not at a point where time might be usefully spent on
> them by engineers as opposed to SciFi writers.

It is not necessarily true that currently fictional technologies are unlikely to be near-term realities. Science fiction and genuine science are not entirely disconnected; the best science fiction is grounded in at least some form of true science, and then takes off from there. Many scientists are curious about the kinds of "science" that appears in fiction, especially if there is enough of a framework to make it at least plausible.

Manned space flight was fictional from pre-1900 until 1961. The concept of geosynchronous communications satellites was largely invented by Arthur C. Clarke several decades before they were engineered into reality.

Space elevators are complete fiction--except that the research and engineering to actually *build* one is going on right now, and the discovery/creation of carbon nanotubes is a likely candidate for the material needed. Ion drives were theoretical, then fictional, and are now used in actual satellites and probes. I've just recently read about some proposed magnetic field propulsion--that might lose funding with the elimination of NIAC. The Star Trek transporters of the 1960s, originally 'invented' to avoid wasting air time on landing/takeoff, were pure fiction...but controlled quantum teleportation is now a (limited) reality.

Gravitational drives (or 'warp drive') are still well into the realm of fiction, *but* there are two active research programs looking for gravitational waves (LISA (Laser Interferometer Space Antenna) and LIGO (Laser Interferometer Gravitational Wave Observatory).

Is it possible that discoveries in gravitational wave physics might make gravity-based drives possible? I don't know, but if we are already doing the background work to evaluate it, we'll be better prepared to capitalize on any future discoveries.

When I was in my early 20s and had been programming only a few years, and John was already a legend and IBM Fellow for his work on FORTRAN, I had the pleasure of meeting him informally a few times. You would have thought our positions and experiences were nearly the same. He was always as engaged and delighted with younger people like me as with other giants of the computer field, some of whom were standing right with us at those get togethers (Jim Gray comes to mind). John was extraordinarily decent, kind, and down-to-earth, and he will be very much missed.

I think some of the wise guys/gals on this list are missing the point of the FORTRAN team's contributions. It wasn't that FORTRAN was the perfect language. To some degree, that wasn't even the goal. Quoting from an an article by Backus (full text is available only to ACM subscribers, unfortunately):

At the time the FORTRAN work was done, people didn't believe that a compiler could produce code that was fast enough. If you go back to the early references on FORTRAN you'll find that they implemented optimizations that were still considered sophisticated 15 years later. The difference is: the FORTRAN team did it at a time when nobody had done it before. Furthermore, they did it on an IBM 704 that would be too weak (if not too small!) to power a wrist watch today. Its core storage units were tens of cubic feet in size, and each held 4K 36 bit words, or just over 32K bytes in modern terms. Even the "high speed" drum storage units (like a disk, but with no seeking needed) held only 16K of those 36 bit words. On this machine, they built optimizations that were considered sophisticated even decades later, when machines had gotten much bigger and faster. Quoting from that same article:

The computing field has lost someone very special.

When I was in my early 20s and had been programming only a few years, and John was already a legend and IBM Fellow for his work on FORTRAN, I had the pleasure of meeting him informally a few times. You would have thought our positions and experiences were nearly the same. He was always as engaged and delighted with younger people like me as with other giants of the computer field, some of whom were standing right with us at those get togethers (Jim Gray comes to mind). John was extraordinarily decent, kind, and down-to-earth, and he will be very much missed.

I think some of the wise guys/gals on this list are missing the point of the FORTRAN team's contributions. It wasn't that FORTRAN was the perfect language. To some degree, that wasn't even the goal. Quoting from an an article by Backus (full text is available only to ACM subscribers, unfortunately):

At the time the FORTRAN work was done, people didn't believe that a compiler could produce code that was fast enough. If you go back to the early references on FORTRAN you'll find that they implemented optimizations that were still considered sophisticated 15 years later. The difference is: the FORTRAN team did it at a time when nobody had done it before. Furthermore, they did it on an IBM 704 that would be too weak (if not too small!) to power a wrist watch today. Its core storage units were tens of cubic feet in size, and each held 4K 36 bit words, or just over 32K bytes in modern terms. Even the "high speed" drum storage units (like a disk, but with no seeking needed) held only 16K of those 36 bit words. On this machine, they built optimizations that were considered sophisticated even decades later, when machines had gotten much bigger and faster. Quoting from that same article:

The computing field has lost someone very special.

Wow, that sure sounds like a lot. Oh, except that IBM has that beaten into a cocked hat.

I know that the general opinion here is that MS is evil, and (software) patents are evil, but IBM is still by far the largest patentee in this field, and some of us still remember when Big Blue was as evil and hated as MS is now.

Point being don't single MS out for criticism, as they're all doing it, even our "friends".

Before some computing history geek has a nerdgasm, I'll amend my comment to "1952", and the engineers of the IBM 701:

http://www-03.ibm.com/ibm/history/exhibits/701/701 _intro.html/

How do your opinions rank against:

IBM
Department of Energy,
Medical device OEMs,
university researchers
and so on...

opinion of the Cell processor's potential?

While I'll grant you the frame buffer access on the PS3 sucks, it would only take a driver from Nvidia or Sony to remove that restriction.

Really? I couldn't find any on their website and have never heard of IA-32/64 architecture being pushed that far. According to their products site only their POWER based machines are 64-way, their Intel/AMD units are four socket (16 cores at most).

Try the IBM System x3950. See also the Unisys ES7000/one.

To be fair, the aging bus archiecture of the current Xeons is definitely a hinderance onec you move beyond commodity servers. In terms of widely available machines, you're still generally looking at 16 core (four quad core Xeon or eight dual core Opterons). Howver, Intel is set to debut CSI (Common System Interface) to replace the front side bus and AMD is set to transition to Hypertransport 3.0, both of which will support at least sixteen quad core CPUs.

The Cell is being looked at by large banks and they are sufficiently interested to set up specialist teams to see how the architecture can be best used.

I never said it wasn't being looked at. So was the Itanium. :)

The Niagara is a toy with laughable floating point performance; the example unit we got sent ended up as a foot-rest.

A product isn't suitable for applications it wasn't designed for? Shock.

Rock is much more useful (each of the four cores having a dedicated FPU) but the IC design has only just been finalised and the first servers won't be shipping for another year.

There's also a FPU per-core in the UltraSparc T2, which should be available soon. Neither of the Niagara CPUs are a good replacement for the mainstream UltraSparc line, though, since they suffer from the same "weakness" as the Cell - they're good for the subset of problems they're deigned to solve, but mediocre to bad at things they're not designed for.

There's also the problem that it's an extension of the UltraSparc architecture rather than "cool" and new like the Cell. Sadly this is often the deciding factor with IT managers at the very large banks.

And the Cell is just an extension of the PowerPC architecture (yes, I know the SPE implements a new ISA, but that sort of nuance is lost on pointy-hairs) rather than "cool" and new like the Niagara. I mean, come on, the UltraSparc T2 can handle 64 simultaneous threads and the Cell can handle a piddling eight. Big numbers sell just as well as novelty (often better, since novelty comes with free "new and scary").

The Cell's designed, with one PPE and a number of SPEs is very suited to a number of pricing calculations. Many instruments are priced in an iterative manner or by use of monte-carlo. The lack of DMA for the SPEs is not really a problem in these cases as the inputs for each iteration/simulation don't change that much and (in most cases) could be wedged in to the 256K available to each element. You're assertion that Cell is best deployed only for a limited task set is correct, but banking contains such tasks and the Cell appears to be well suited to the role.

Ah, I read "The Cell processor is attracting a lot of attention as a potential replacement for Sparc and requires specialist development machines." as more of a general statement rather than being applicable specifically to banking. Would explain some of the disagreement.

I'm not intimately familiar with financial software, but I was under the impression fixed point arithmetic is generally prefered. I have no idea how the Cell would perform for that makes the performance hit of IEEE-754 mode out of the picture. :)

Computer Science != Software Development Maybe I'll grant software development as a subset of computer science, but the efficiencies of software-as-commodity, and the 'dumbing down' of software dev. practices in general shouldn't be construed as a lack of need for actual SCIENTISTS who study what will come NEXT for the industry. The advent of quantum computing is a prime example of why the world needs more researchers spending time in the lab despite how much more efficient the commercial development industry has become.

It matters because soon as a major PC manufacturer starts shipping machines without the Windows tax, we can finally get some real competition in the OS world (how ironic that if I want to try free Linux, I usually have to buy Windows - which comes with my PC - and I can't get a discount if I don't want Windows).

The SF.net CompileFarm was not there to provide 'power'.

Well, the reason why they want to wait for approval is because some big names are participating such as IBM and Novell. I really don't think they're too interested in a patent battle with Microsoft when Microsoft seems to have the upper hand. IBM, for one, does not like to lose in court.