Slashdot Mirror

Here

Link to IBM's history site

IBM started selling proportional typewriters in 1941. Link here to IBM's history site.

better link that actually might work and without the fark crap.

Proportional width typewriters from IBM circa 1941

(link from fark)

This Sybase move now means that I can download and play with a serious database. It's a smart move because it means that I will be gaining skills in programming for that database engine, skills which are seriously marketable.

I fact, I've been waiting for free-download Oracle/DB2 "personal database" or some limited opensource release of Oracle/DB2 for a while.

So, err, maybe you wanted this?

DB2 UDB Personal Developer Edition

Cheers,
Toby Haynes

I'd like to nominate Tridge, but not for his work on Samba specifically.

I was as Linux.conf.au and saw him sit down with a complete newbie who would have been maybe 17 years old. This guy was interested in writing some code for the AI competition that was running at the conference, but didn't seem to have much of a clue about how to start it off, let alone coding anything competetive.

Tridge, out of the blue began an informal AI 101 lesson in the courtyard. I sat in on it and can honestly say I learnt more about AI in 10 minutes with Tridge then I did in four years of a CS degree. His presentation of the material came so fluently, confidently and with a warm manner.

So, I nominate him for his *general* donation to the OS movement, and not for his Samba developments (though they are fantastic). It's because of people like him that others want to get involved and make a difference too, and that's the biggest influence we could ever want.

http://www.ibm.com/news/au/2004/04/2004043001.html

Ask IBM who Linux Torvaldes is.

Slashdotted already... alas, I can find no google cache.

If you believe that linux is less bloated and more stable, then it's THE natural OS for embedded systems.

Well, if you want to get your daily fix of "linux has been placed in something else" news... you can always visit linuxdevices.com

If you want to do-it yourself... ibm embedded.

Being Yaz's former cow-orker, Mandrake and Slackware were nowhere near the list.

To see what is tested, check http://www.ibm.com/db2/linux/validate - it's all right there.

Posting as AC for obvious reasons -
I lead a custom application development group within IBM, and I've found it very difficult to use "non-supported" versions of Linux with IBM's flagship products (DB2 products, WebSphere family, etc.)
Most of our installers perform a "supported OS" test, and while it is possible to hack those, IBM thoroughly tests against the supported versions and sometimes takes advantage of things only available in those versions.
Yes, it causes me pain sometimes not to run the latest/coolest/most idealistic distro, but I've found the performance to be rock-solid on the supported distros.
Check out for more info.
Good Luck!

IBM's don't need floppies for BIOS updates either:

BladeCenter HS20 (8832) BIOS update on Linux

BladeCenter HS20 (8832) BIOS update on Windows

These updates flash the BIOS from inside Linux or Windows (i.e., no rebooting into DOS or using a floppy).

IBM's don't need floppies for BIOS updates either:

BladeCenter HS20 (8832) BIOS update on Linux

BladeCenter HS20 (8832) BIOS update on Windows

These updates flash the BIOS from inside Linux or Windows (i.e., no rebooting into DOS or using a floppy).

Check out these links for details, there is a lot of work in this area. Comparing this to @Home type projects is the wrong way to go... each node on the grid can be a gatekeeper to a cluster, where a parallel job is run. The problems involved are more complex than what a centralized server/organization can take care of.

http://www.globus.org//
http://www.ggf.org//
http://www.globusworld.com//

Some details.. much more out there.
http://www.grids-center.org/news/clusterworld//
http://www-106.ibm.com/developerworks/grid/library /gr-design.html/
http://www.casa-sotomayor.net/gt3-tutorial//

Plus, lots of academic papers out there.. this is a pretty interesting subject.

Rational ClearCase is a proprietary version control system that does just this with it's mvfs filesystem.

Each user has it's own view on the versioned filesystem. File versions visible in the view are selected by the user himself by writing simple rules applied to the view.

At least in Wikipedia errors can get fixed by everyone noticing them. Look at my sig (Linux Torvaldes) and say if you would like to be able to fix that page or not. Do you consider IBM to be authoritive?

Google doesn't have much on Linux Torvaldos, but look what I got for Linux Torvaldes. That is .sig material.

The computers were sold between January 1999 and August 2000

Note that IBM shipped a revised product under the SAME part number after August 2000... if you think you qualify, make sure to look at the details - it has to have HOLLOW pins look here to be part of the recall.

Taken from: (follow link for more info)
http://www.ibm.com/servers/eserver/bladecenter/bla de_servers/

"What are blade servers?
Slim, hotswappable blade servers fit in a single chassis like books in a bookshelf -- and each is an independent server, with its own processors, memory, storage, network controllers, operating system and applications. The blade server simply slides into a bay in the chassis and plugs into a mid- or backplane, sharing power, fans, floppy drives, switches, and ports with other blade servers.
The benefits of the blade approach will be obvious to anyone tasked with running down hundreds of cables strung through racks just to add and remove servers. With switches and power units shared, precious space is freed up -- and blade servers enable higher density with far greater ease."

But with a open game, there is no business to be done. No $$ is returned. This is why we probably will never see IBM and the likes contributing to an open game.

IBM had, what was to me, the best thin-client system on the planet. It was heavily OS/2-based, but there was a version for Windows as well! (First link above). Full fat clients running full fat operating systems, but served, managed and administered from a central server. Hardware dies? Use a different computer: get the same operating system, environment, etc. Roaming user? Get *your* OS from any computer. Need to deploy an app to 1000 users? Install once, and drag and drop an icon. Done.

To me, *that* is Network Computing. Not glorified VNC to a single computer...

IBM had, what was to me, the best thin-client system on the planet. It was heavily OS/2-based, but there was a version for Windows as well! (First link above). Full fat clients running full fat operating systems, but served, managed and administered from a central server. Hardware dies? Use a different computer: get the same operating system, environment, etc. Roaming user? Get *your* OS from any computer. Need to deploy an app to 1000 users? Install once, and drag and drop an icon. Done.

To me, *that* is Network Computing. Not glorified VNC to a single computer...

Chalk one up for Absolute's ComputraceComplete over zTrace. I don't beleive Absolute's "Laptop Retriever" (possibly the same package as "Computrace Personal Edition") is able to survive *any* harddrive formats. Thanks for providing the link to the article; I didn't know that IBM sells ComputraceComplete in quantities less than 10. When I called Absolute a few months ago, they indicated "Laptop Retriever" was the only option when buying less than 10 and suggested only the link at Toshiba to avoid Canadian taxes. Now I can bookmark: http://www.pc.ibm.com/us/accessories/services/inde x.html

It's as inexpensive as a IBM clone and worth more in value.

Indeed, forget clones, try pricing an IBM at around this spec. An A50 with a 2.8GHz P4 ($599) and 17" monitor ($459) is $1,058.00. "Aha!" I pretend to hear you cry, "It's not an AIO, and it doesn't have a decent graphics card!" Well, yeah, it's not an AIO (that's an advantage to the IBM, and it ought to mean the AIO is cheaper anyway), and you can buy a $100 graphics card for it and still be under.

You don't need a wheel at all to be able to scroll through any list without movming your fingers.

All you need is a small pointing device of some sort that can be pressed with a thumb in any direction and held while your list is scrolling.

I am sure there can be many other ways to do it.

Here are two that I've used in the past.

1. Linux Documentation Project
2. IBM Developer Works

I know that Novell has a "DeveloperNet" program, and IBM also has an Alpha works program. Though, Alpha works isn't devoted to only Linux technologies. Red Hat, also has a developer program and SuSE does as well.

No. You always need a classical channel (with speed of light limitation) to complete the teleportation. You need to know the measurement at location A to cast the state of entangled qubits at state B. Actually, "teleporting" classical information is easier. You copy the data and send it. With quantum states it is harder because you cannot copy the quantum state (no cloning theorem). You need to entangle qubits, distribute them, and send classical data. The whole process is at most as fast as the speed of light. A picture on this page is an excellent nonmathematical explanation of teleportation.

[...] But the six scientists found a way to make an end run around this logic, using a celebrated and paradoxical feature of quantum mechanics known as the Einstein-Podolsky-Rosen effect. Read just how this effect works, here.

Very good article, but some people might find Einstein-Podolsky-Rosen paradox article on Wikipedia somewhat better for an introductory text, and at the same time richer in details:

The EPR paradox arises in a thought experiment which shows that quantum mechanics leads to very counter-intuitive and paradoxical consequences. It is named after Einstein, Podolsky, and Rosen, who published the idea in 1935. It is also referred to as the EPRB paradox after Bohm, who converted the idea into something that was nearer to being experimentally testable. The EPR paradox draws attention to a phenomenon predicted by quantum mechanics known as quantum entanglement, in which measurements on spatially separated quantum systems can instantaneously influence one another. As a result, quantum mechanics violates a principle formulated by Einstein, known as the principle of locality or local realism, which states that changes performed on one physical system should have no immediate effect on another spatially separated system. The principle of locality is persuasive, both in intuitive grounds and because it seems at first sight to be a natural outgrowth of the theory of special relativity. According to relativity, information can never be transmitted faster than the speed of light, or causality would be violated. Any theory which violates causality would be deeply unsatisfying, and probably internally inconsistent. However, a detailed analysis of the EPR scenario shows that quantum mechanics violates locality without violating causality, because no information can be transmitted using quantum entanglement. Nevertheless, the principle of locality appeals powerfully to physical intuition, and Einstein, Podolsky and Rosen were unwilling to abandon it. They suggested that quantum mechanics is not a complete theory, just an (admittedly successful) statistical approximation to some yet-undiscovered description of nature. Several such descriptions of quantum mechanics, known as "local hidden variable theories" were proposed. These deterministically assign definite values to all the physical quantities at all times, and explicitly preserve the principle of locality. Of the several objections to the prevailing interpretation of the quantum mechanics spearheaded by Einstein, the EPR paradox was the subtlest. It is at present considered to have been unsuccessful, the existence of hidden variables having been refuted experimentally and the EPR "paradox" taken to be fully resolved within the current interpretation of the theory. The belief that entanglement is a real phenomenon has led to a radical shift in thinking about 'what is reality' and what is a 'state of a physical system'. First, a review of the history: Before 1936, the generally accepted view was that a particle, such as an electron, has measurable properties such as a position and a momentum but 'we cannot know both' at the same time. This view is present in some explanations of the Heisenberg uncertainty principle. In such an explanation, the 'more exactly we measure the position', the 'more we disturb the particle' and its momentum becomes that much less certain. The numerical measure of uncertainty satisfies Heisenberg's principle, but this (local realistic) interpretation is rejected in professional circles, though it still lives in popular books. The shift was caused by the EPR thought experiment, which has shown how to measure the property of a particle, such as a position, without disturbing it. In to

In 1993 an international group of six scientists, including IBM Fellow Charles H. Bennett, confirmed the intuitions of the majority of science fiction writers by showing that perfect teleportation is indeed possible in principle, but only if the original is destroyed. In subsequent years, other scientists have demonstrated teleportation experimentally in a variety of systems, including single photons, coherent light fields, nuclear spins, and trapped ions. Teleportation promises to be quite useful as an information processing primitive, facilitating long range quantum communication (perhaps unltimately leading to a "quantum internet"), and making it much easier to build a working quantum computer. But science fiction fans will be disappointed to learn that no one expects to be able to teleport people or other macroscopic objects in the foreseeable future, for a variety of engineering reasons, even though it would not violate any fundamental law to do so.

In the past, the idea of teleportation was not taken very seriously by scientists, because it was thought to violate the uncertainty principle of quantum mechanics, which forbids any measuring or scanning process from extracting all the information in an atom or other object. According to the uncertainty principle, the more accurately an object is scanned, the more it is disturbed by the scanning process, until one reaches a point where the object's original state has been completely disrupted, still without having extracted enough information to make a perfect replica. This sounds like a solid argument against teleportation: if one cannot extract enough information from an object to make a perfect copy, it would seem that a perfect copy cannot be made. But the six scientists found a way to make an end run around this logic, using a celebrated and paradoxical feature of quantum mechanics known as the Einstein-Podolsky-Rosen effect.

Read just how this effect works, here.

I for one would never allow my self to be "teleported". Quantum teleportation http://www.research.ibm.com/quantuminfo/teleportat ion// is a misleading title. In short, you end up with a "copy" of the original. If a human were to travel this way, it is likely the result would be an exact copy of the original (you would die).

IBM just doesn't do a good job of marketing their more interesting products, I think. =)

What does make a moderate difference is that PNG is not bound to 256 colours. You can use a 16-colour palette, in which case pixels are packed in 4 bits each. You can use a 4-colour palette, in which case pixels are packed in 2 bits each. Pixels can be of many different depths between 1 bit and 48 bits. GIF does not have this flexibility.

Just FYI, GIFs can have 4-color or 16-color palettes.

And here is an article on ibm.com about how to do the trick where the kernel is booted from a floppy/CD, finds the USB mass storage device, mounts it, and uses it as the root filesystems. And another article here. Looks pretty straightforward.

IBM has a prototype of a mouse with trackpoint scroll stick. Because the trackpoint nubbin is a rate-device, like a joystick, it apparently offers superior productivity to a scrollwheel according to IBM's research (PDF of slides).

Has anyone seen any devices like this? As much as I love the scrollwheel, my finger gets tired scrolling through a long document -- I'd rather just pull on a stick/nubbin and zoom along.

IBM has a prototype of a mouse with trackpoint scroll stick. Because the trackpoint nubbin is a rate-device, like a joystick, it apparently offers superior productivity to a scrollwheel according to IBM's research (PDF of slides).

Has anyone seen any devices like this? As much as I love the scrollwheel, my finger gets tired scrolling through a long document -- I'd rather just pull on a stick/nubbin and zoom along.

I'm not sure that makes this less cool, since
(1) it's a freekin' cash register
(2) it's definitely isn't your typical slashdot-geek's video subsystem.

The 'found in a dumpster' bit is pretty cool, too. As is the 'retooled industrial equipment as art' spin. I like it.

But, no, it's not something from the mid-80's or anything. It's 'just' a cash register.

Do you notice anything in common?

Perhaps Microsoft is making some deals under the table to prevent Linux from getting into the laptop market.

You mean, like this guy ? BlueGene

The components of the POWER4 chip are shown in Figure 1. The chip has two processors on board. Included in what we are referring to as the processor are the various execution units and the split first level instruction and data caches. The two processors share a unified second level cache, also onboard the chip, through a Core Interface Unit (CIU) in Figure 1. The CIU is a crossbar switch between the L2, implemented as three separate, autonomous cache controllers, and the two processors. Each L2 cache controller can operate concurrently and feed 32 bytes of data per cycle. The CUI connects each of the three L2 controllers to either the data cache or the instruction cache in either of the two processors. Additionally, the CUI accepts stores from the processors across 8-byte wide buses and sequences them to the L2 controllers. Each processor has associated with it a Noncacheable (NC) Unit, the NC Unit in Figure 1, responsible for handling instruction serializing functions and performing any noncacheable operations in the storage hierarchy. Logically, this is part of the L2.

Figure 1: POWER4 Chip Logical View

The directory for a third level cache, L3, and logically its controller are also located on the POWER4 chip. The actual L3 is on a separate chip. A separate functional unit, referred to as the Fabric Controller, is responsible for controlling data flow between the L2 and L3 controller for the chip and for POWER4 communication. The GX controller is responsible for controlling the flow of information in and out of the system. Typically, this would be the interface to an I/O drawer attached to the system. But, with the POWER4 architecture, this is also where we would natively attach an interface to a switch for clustering multiple POWER4 nodes together.

In case it's not obvious to those who didn't read the article all the way through, it's a better thing when the memory is shared (single cache) rather than separate (dual cache). But that is harder to design, so for these first-generation dual-core chips from Intel and AMD, they are using separate caches for each core. (IBM's dual core Power4 processor has a unified cache.) At some point down the road, they will likely unify them to increase performance.

What IBM is doing is good for business, but not to sell hardware. IBM primarily sells three things: hardware, software and services. They saw their profits begin to errode in hardware, so they began to move to software. They are starting to see their profits erode in software, so they are selling services, in particular consulting service, and that is where the money's at. Based on their '03 financial statement http://www.ibm.com/annualreport/2003/noflash/fr_cf s_cse.shtml, their Global Services rose from $34.9 billion in '01 to $42.6 billion in '03 while hardware slid from $30.6 billion in '01 to $28.2 billion in '03. Hardware is still up their, but it is slowly declining.

They certainly would have gotten away with it too, if it wasn't for those meddling kids

Me neither.

I'd agree that was an initial marketing blunder, although I don't recall the confusion. I probably adopted OS/2 prior to the introduction of the PS/2 series of computers. However, did you know that OS/2 apparently is still alive? Shocked me, that did.

Link to a TCO study by IBM

Well, there is the alternative

Expensive when new, yes. But it supports open source and open standards without the elitist image.And there are other places if you cant stand the expense.

One of the reasons that some consider Java uncool, is because of the myth that Java is slow. I call it a myth, and I will try to explain why it is a myth. (Actually, in theory, Java will outperform C++ soon).

Just to take a swing at another myth, while we're at it: When it comes to size of the stack, how you want the garbage collector to use memory etc., you CAN in fact give the JVM parameters to control this stuff.

Java isn't slow anymore. It may be true, that (small) Java applications generally takes a little longer to start up, if you didn't use an AOT compiler (like for instance the "free as in freedom" compiler GCJ or the more mature but proprietary Excelsior JET). Its true that early versions of Java were slow, but 1.4.x isn't generally slower than C++, in fact, I wouldn't be surprised if it outperformed C++ on general terms one of these days.

One of the things that makes Java "not slow", is actually the way memory is allocated. Its rather cheap to allocate memory in Java, compared to other languages, and its even cheaper to "free" memory, since you don't do it, you have the cost of the garbage collector instead. The garbage collector in Java is very fast, compared to older garbage collectors.

(For the interested, IBM has an article on "garbage collection in the HotSpot JVM", and another article that explains various garbage collection techniques, and finally they have an article that covers performance concerning garbage collection. They have a lot of other interesting articles, but I don't want to list all I know, if you like to check it out, here is the search I used to "refind" these articles.)

I make the claim that Java isn't slow, but don't just take my worth for it. (Not that I think you would). Go search on google or whatever. A word of warning though .. since older Java's were indeed slow, do note the version of the Java tested. It should be (at least) 1.4.x. I don't think 1.5.x is stable yet and I dunno if its faster or slower, but 1.4.x have a real nice enhanced garbage collecting subsystem. (Esp. 1.4.2 and above).

(On purpose, I didn't go for SUN benchmarks, as they might be (considered) biased, but sun does have a word to say about "Java Performance".)

Here is a couple of quotes from an article that considers performance of Java vs. C++, analysing some benchmarks of Java, C++ and other languages. While the article was updated this year, I was still unable to find a link to a benchmark diagram of the current 1.4.x JVM. It seems though, that the 1.3.x wasn't too slow, even without latest optimised GC-subsystem, which is one of the key factors that makes 1.4.2 faster.

Here are the quotes:

"Five composite benchmarks listed below show that modern Java has acceptable performance, being nearly equal to (and in many cases faster than) C/C++ across a number of benchmarks."

"Java is now nearly equal to (or faster than) C++ on low-level and numeric benchmarks. This should not be surprising: Java is a compiled language (albeit JIT compiled)."

One of the reasons that some consider Java uncool, is because of the myth that Java is slow. I call it a myth, and I will try to explain why it is a myth. (Actually, in theory, Java will outperform C++ soon).

Just to take a swing at another myth, while we're at it: When it comes to size of the stack, how you want the garbage collector to use memory etc., you CAN in fact give the JVM parameters to control this stuff.

Java isn't slow anymore. It may be true, that (small) Java applications generally takes a little longer to start up, if you didn't use an AOT compiler (like for instance the "free as in freedom" compiler GCJ or the more mature but proprietary Excelsior JET). Its true that early versions of Java were slow, but 1.4.x isn't generally slower than C++, in fact, I wouldn't be surprised if it outperformed C++ on general terms one of these days.

One of the things that makes Java "not slow", is actually the way memory is allocated. Its rather cheap to allocate memory in Java, compared to other languages, and its even cheaper to "free" memory, since you don't do it, you have the cost of the garbage collector instead. The garbage collector in Java is very fast, compared to older garbage collectors.

(For the interested, IBM has an article on "garbage collection in the HotSpot JVM", and another article that explains various garbage collection techniques, and finally they have an article that covers performance concerning garbage collection. They have a lot of other interesting articles, but I don't want to list all I know, if you like to check it out, here is the search I used to "refind" these articles.)

I make the claim that Java isn't slow, but don't just take my worth for it. (Not that I think you would). Go search on google or whatever. A word of warning though .. since older Java's were indeed slow, do note the version of the Java tested. It should be (at least) 1.4.x. I don't think 1.5.x is stable yet and I dunno if its faster or slower, but 1.4.x have a real nice enhanced garbage collecting subsystem. (Esp. 1.4.2 and above).

(On purpose, I didn't go for SUN benchmarks, as they might be (considered) biased, but sun does have a word to say about "Java Performance".)

Here is a couple of quotes from an article that considers performance of Java vs. C++, analysing some benchmarks of Java, C++ and other languages. While the article was updated this year, I was still unable to find a link to a benchmark diagram of the current 1.4.x JVM. It seems though, that the 1.3.x wasn't too slow, even without latest optimised GC-subsystem, which is one of the key factors that makes 1.4.2 faster.

Here are the quotes:

"Five composite benchmarks listed below show that modern Java has acceptable performance, being nearly equal to (and in many cases faster than) C/C++ across a number of benchmarks."

"Java is now nearly equal to (or faster than) C++ on low-level and numeric benchmarks. This should not be surprising: Java is a compiled language (albeit JIT compiled)."

One of the reasons that some consider Java uncool, is because of the myth that Java is slow. I call it a myth, and I will try to explain why it is a myth. (Actually, in theory, Java will outperform C++ soon).

Just to take a swing at another myth, while we're at it: When it comes to size of the stack, how you want the garbage collector to use memory etc., you CAN in fact give the JVM parameters to control this stuff.

Java isn't slow anymore. It may be true, that (small) Java applications generally takes a little longer to start up, if you didn't use an AOT compiler (like for instance the "free as in freedom" compiler GCJ or the more mature but proprietary Excelsior JET). Its true that early versions of Java were slow, but 1.4.x isn't generally slower than C++, in fact, I wouldn't be surprised if it outperformed C++ on general terms one of these days.

One of the things that makes Java "not slow", is actually the way memory is allocated. Its rather cheap to allocate memory in Java, compared to other languages, and its even cheaper to "free" memory, since you don't do it, you have the cost of the garbage collector instead. The garbage collector in Java is very fast, compared to older garbage collectors.

(For the interested, IBM has an article on "garbage collection in the HotSpot JVM", and another article that explains various garbage collection techniques, and finally they have an article that covers performance concerning garbage collection. They have a lot of other interesting articles, but I don't want to list all I know, if you like to check it out, here is the search I used to "refind" these articles.)

I make the claim that Java isn't slow, but don't just take my worth for it. (Not that I think you would). Go search on google or whatever. A word of warning though .. since older Java's were indeed slow, do note the version of the Java tested. It should be (at least) 1.4.x. I don't think 1.5.x is stable yet and I dunno if its faster or slower, but 1.4.x have a real nice enhanced garbage collecting subsystem. (Esp. 1.4.2 and above).

(On purpose, I didn't go for SUN benchmarks, as they might be (considered) biased, but sun does have a word to say about "Java Performance".)

Here is a couple of quotes from an article that considers performance of Java vs. C++, analysing some benchmarks of Java, C++ and other languages. While the article was updated this year, I was still unable to find a link to a benchmark diagram of the current 1.4.x JVM. It seems though, that the 1.3.x wasn't too slow, even without latest optimised GC-subsystem, which is one of the key factors that makes 1.4.2 faster.

Here are the quotes:

"Five composite benchmarks listed below show that modern Java has acceptable performance, being nearly equal to (and in many cases faster than) C/C++ across a number of benchmarks."

"Java is now nearly equal to (or faster than) C++ on low-level and numeric benchmarks. This should not be surprising: Java is a compiled language (albeit JIT compiled)."