Read the damn constitution, moron: Article 1, Section 10, only applies to states. (It is entitled, in the annotated version "Powers Denied to the States".)
Section 10.
No State shall enter into any Treaty, Alliance, or Confederation; grant Letters of Marque and Reprisal; coin Money; emit Bills of Credit; make any Thing but gold and silver Coin a Tender in Payment of Debts; pass any Bill of Attainder, ex
post facto Law, or Law impairing the Obligation of Contracts, or grant any Title of Nobility.
BTW, gold is not inflation free. What do you think comes out of gold mines, genius?
Listen, genius... Unless some boneheaded sysadmin for some bizarre reason decided to physically connect the admin systems to the "outside world", (this would have to be explicitly configued in the I/O Control Program), the security is foolproof, period. End of story. A breach of the control systems by user images is physically impossible. The system hardware simply would not allow it, no matter how the program was written.
I did not say, "provided the security is good enough." The security already is impenetrable, right out of the box (er... crate). No OS patches, no BugTraq-reading. The trusted sysadmin would have to break it on purpose to do anything. And if you can't trust your sysadmin, clustering won't help.
It is far more likely that a clustered system would utterly collapse than this one "basket" would. Here is an anology: Let's say you have one billion dollars to move from point A to point B, in $20 bills. You can either load the bills into a fleet of NYC street taxi's (with the doors locked), or into a truck armored (and weaponed) like an M1A1 tank, and four completely redundant engines. Which would you choose? Multiple, unreliable, boxes that have been proven notoriously hard to secure; or one single, easy to administer, rock-solid box, with security that has been proven over decades to be bullet-proof.
This is more than just creating a new directory. When a new "server" is set up, it will get separate instance of Linux, completely separated from all other images. From the point of view of the customer, they will have the whole machine to themselves. If they want to rm -rf/, it isn't a problem for any other image. This is the big strength of a VM-based system. Also, the unbelivably flexible load balancing software can be configured to give a certain image an absolute allocation of system resources, (I/O bandwidth, CPU cycles, memory, whatever) and you can be positive that you will always have it. Any shortage of capacity can be anticipated far ahead of time and fixed in short order by setting up a Parallel Sysplex of multiple boxes. (After you have somehow exhausted the huge amount of internal on-the-fly expansion capacity.)
Also, it is FAR more likely that something like the power company or the outside net connection will go down before the mainframe itself fails. These are designed for ZERO downtime. So a company deploying one of these is far more likely to lose sleep worrying about external systems than the mainframe itself.
Different images in an S/390 / z900 are separated from each other in hardware and the VM software. The only way to circumvent this would be to somehow gain access to the VM control programs. You can be damn sure that these folks will be air-gapping the console and admin systems from public networks. VM controls cannot be accessed from the systems VM runs, period. (IIRC, this restriction is enforced in hardware.) In addition, the images cannot access the resources (storage or memory) of each other unless explicitly configured to do so in VM. The restrictions are good enough that mainframes have been running the same OS architecture for decades and I do not recall a single security breach of this nature.
SirWired
Re:Finally Kilby gets the recognition he deserves.
on
Nobel Prizes
·
· Score: 2
1) I concede that Robert Noyce did come up with the same idea shortly afterwards.
2) I also admit that Kilby's prototype was not feasible for mass production (I did not know that it never worked.) However, he did plan on using a solid-state process for the interconnects, independent of his original idea for having multiple components on a single piece of silicon. (If I remember correctly he even considered contacting Fairchild eventually about licensing their process for interconnects.)
3) The patent fight only occured because of some vague wording and a bad diagram in the TI patent. IIRC, specifically, the meaning of the words "laid down", and the meaning of Kilby's famous "flying wire" diagram.
Intel could possibly claim credit for a computer on every desk, since they were the first to develop the general purpose processor, but the first "embedded" application for IC's was the TI pocket calculator, for which Kilby was one of the engineers. While this was only a significant (as opposed to revolutionary) device, it served as an effective demonstration of what IC's were capable of.
If Robert Noyce were still alive today, I have no doubt that he would have shared the Nobel Prize.
On the other hand, the reason I have great respect for Jack Kilby is because he never sought a great fortune or fame for his discovery. AFAIK, he remained on the engineering staff from TI. That is not to say that seeking riches is ignoble, just that neither is not seeking them.
Perhaps I should have changed the wording of my post somewhat recognize the fact that Robert Noyce developed it at about the same time, and later won the patent. I did not mean to take anything away from anyone else.
Finally Kilby gets the recognition he deserves...
on
Nobel Prizes
·
· Score: 3
Since I first started reading computer history, Jack Kilby has been the computer person I admire most. His discovery (the Integrated Circuit) has more or less created modern technology as we know it today, and without it, we arguably could still be using discrete components. What is more interesting is even though he revolutionized technology, he received (until now) no great public recognition. Since he created the IC as a staff engineer for TI, he was not entitled to royalties or anything of that nature. Sure the IEEE has named a medal after him, and he figures prominently in computer history books, but he is a virtual unknown to the public.
In other words, it couldn't have happed to a better guy.
1) Um, IBM is making oodles of money off the internet. A massive portion of the services business comes from "e-business" stuff sold to Fortune 500 companies. (IBM's traditional customers.) Also, DB2 and WebSphere are getting to be pretty popular among enterprise customers.
2) IBM doesn't make any money off of AIX. Yes, they do charge licensing fees, but mainly it is sold as something you need to buy to run your RS/6000.
IBM makes it's big money from the holy trinity of high-end hardware, industrial-strength software applications, and services/solutions. Low-end hardware (like 1U servers and PC's) and commodity software (like OS's) are only provided because they need to be if IBM wants to sell a "solution" instead of merely products.
IBM's other major profit streams are Technology (patent portfolio, Chip fab services, etc.), ThinkPads (simply because they kick ass and can take advantage of IBM's research in displays, hard drives, etc.), and leases/loans so customers can afford all this stuff.
If Linux could do what IBM needs, (more reliability, better I/O, etc.) they would likely drop AIX like a hot potato, because developing it ain't cheap.
Bzzzt! Wrong! IBM wants to sell everything...
on
IBM Releases SashXB
·
· Score: 2
IBM actually makes more money selling software than any company in the world. (Through stock option tricks, M$ loses money selling software, and makes bucketloads selling stock) IBM simply doesn't want to waste it's time on $60/copy client software and client operating systems. The real money is in the mega-buck server software. Think about it, what would you rather support:
A) One zillion badly-built, non-standard PC'S, with similarly badly configured OS's? (at $60/copy) OR
B) Ten thousand badly-built, badly-configured, servers at many kilo-bucks per copy, per year.
And oh yes, services to maintain and run all those servers. If bits run through it, IBM wants to sell it to you.
Well duh!, of course IBM will take the best changes and put them into the "official" release. Of course they will try to sell service and support for their supported version of the product. How is this different from what RedHat does? If you make your own major changes to the Linux kernel, don't expect RedHat to help you if your changes break things.
Next, is there even one example of IBM stealing Open Source Software and touting it as their own? While you can't expect that they will issue a press release for every little bug fix, I really don't think that they would steal any kind of major dev. effort. Remember that Sun tried this with the Blackdown fiasco.
I think IBM's new religion on Linux is genuine. You really think IBM enjoys writing DB2 over and over again for seven different operting systems? (Palm, Win16, Win32, WinNT/2000, AIX, OS/400 and OS/390) If IBM has a standard base to build value-added services and custom software, it sure makes their lives a lot easier. If WebSphere becomes a defacto standard (or at least widely used) application server, IBM can now sell services contracts (big $) that much easier. If the open version is a stepping stone, customers are more likely to buy the full (not-so-open) version.
Will IBM ever go totally open-source? No. IBM currently makes more money selling software licenses than any other company on the planet (including Microsoft and Oracle) It would be suicide for the Board of Directors (i.e. shareholder lawsuits) if they decided to give all that up. However, IBM would love to have commodity parts of the system open-source (i.e. web browsers) so it can spend precious dev. dollars on more lucrative packages. (What would you rather sell, a $60 OS (i.e. Windows), or a multi-million $ transaction processing package?) How can you say IBM's intentions are not clear. They have not once said that they want all software to be open. They have merely committed to keeping open standards open, and getting as much of their software ported to Linux as possible. IBM doesn't think like RMS, and it would be unreasonable to expect them to do so.
OK, I am a little confused here... The "Open Source Community" begs companies to release open source software. IBM then announces the opening of the source for a major product. Next, I read crap like this with all sorts of conspiracy theories. What the hell?!?!
Of course IBM wants to dominate the industry. Every public company has a fiduciary duty to it's stockholders to attempt to gain a monopoly position in every market it enters. (Remember having a monopoly is not illegal, just using illegal means to maintain it.)
Next, who cares what IBM's intentions are? So what if they want to dominate hardware and services? Take the source and run! Ignore IBM's pleas to pay them to integrate. Hang up on the marketing rep when he tries to sell you hardware. Once you have the source, what the hell do you need IBM for? If you don't want IBM to be a focal point for change, fork the code!
Don't like "Tivoli Ready Modules"? Don't use 'em! Don't want to use VisualAge? Fine, who is going to stop you?
Actually, in case anyone cares, this group was spun off from the mother company several years ago and is no longer an IBM dept.
Another interesting fact about this group is that the Capability Maturity Model was built around the processes that this group implemented, and they are the only software organization to hold a CMM of five for a sustained period of time.
However, their supreme reliability comes at the price of a cost-per-line almost double that of your average delivered software project. I guess you could say that their process is overkill for projects that don't require this kind of reliability.
Why do you say that IBM is not giving away anything substantial? Have you even looked at what they are giving out? When commercial, low-level, products are "opened", it is quite common for some parts to be witheld because the company simply does not exclusively own the rights to everything in the code. It probably has nothing to do with corporate treachery or evil PR minions, just simple licensing rights over which the IBM Software Group has no control.
In all states that charge a sales tax, you are obligated to pay the tax on goods purchased out of state. You must pay the tax yourself, as states are prohibited from forcing out-of-state businesses (meaning businesses with no physical presence in the state) to collect the tax themselves. The moratorium on "Internet" taxes only applies to tax laws that singled out internet transactions for special treatment.
The enforcement for out-of-state purchases has been somewhat lax, but nevertheless, you are leagally obligated to pay it. (Voluntary compliance is the backbone of the American system of taxation.)
Um... IBM already has machines with copper interconnects, and now SOI, shipping right now. The chips that IBM is shoving out the door are POWER 4 architecture chips (closely related, but not identical to the PowerPC), (used in the RS/6000 and AS/400 not PowerPC chips. IBM was shipping copper (about a year now) even before anyone else had demo units available. Now the SOI is shipping, and again, no one else is even close. Just because it doesn't exist on PC's doesn't mean it doesn't exist.
1) IBM is rolling these new technologies (copper interconnects, SOI, etc.) into their own, proprietary, platforms (RS/6000, AS/400, S/390) first for what should be obvious reasons. They are competing with the Intel server chips by producing non-intel servers. Why just make a profit selling the chip when you can really rake in the dough selling the chip, system, software, and services? You can be sure that it would take a $hitload of Athlons to match the profit produced by a single S/390 or big AS/400.
2) IBM also directly competes with Intel on several other fronts, namely communications chips. Intel makes more than x86 chips, even though those are Intel's cash cow. IBM is more than willing to license these technologies to Intel's competitors in the semi market on the theory that "the enemy of my enemy is my friend."
I do work for Big Blue, and I can tell you that what you probably heard was that IBM was going to roll out Linux so it will run on each of its four server platforms. (NetFinity, AS/400, RS/6000, and S/390) There is simply no way that OS/390 will disappear, ever. Remember that OS/390 is a direct descendent of the OS that IBM "bet the company" on in the early '70's. (Software Eng. students will recall that that masssive, ugly project spawned the book, "The Mythical Man-Month".) You can be pretty sure that most of the bugs have been squashed flat by three decades of field use. IBM's goal is to have zero downtime by the end of next year, (I'm not sure, I am not in the )S/390 division) when a client uses a geographically distributed parallel sysplex setup. (That means two S/390s spread far apart working concurrently.) In addition, as another poster pointed out, OS/390 is tightly coupled to many of the unique features of the hardware, including parallel sysplex, a load balancing system so powerful that it makes Solaris look about as advanced as DOS, the partitioning system that provides rock-solid security by partitioning the system in hardware, all source of complex resource-sharing mechanisms, etc. In conclusion: When hell freezes over and Big Blue, and every one of our big clients goes bankrupt.
Hey, you are preaching to the choir here. I know that software done right the first time is always cheaper and better than software fixed later. However, even software done the right way WILL have defects. Remember that software defects can come from more than just coding errors. Vague documentation, a misunderstood spec, etc. are all defects which can result in catastrophe. Bad docs are something no testing program can detect, and they are subject to the whims of the English language.
A safety design defect free car is far eaiser to make than defect-free software. This is because for a car to be considered free of defects, it only must meet defined safety standards, and pass a certain set of well-defined tests. An entire car consists of a few thousand parts (most of which do not interact with each other), and costs hundreds of millions to design. The properties of those parts are well understood and easily testable.
With a skyscraper, I can run the design of a building through a streightforward analysis program an see if it will meet acceptable margins for safety. Keep in mind that a building is ususally several times as strong as the load it is supposed to carry. After all, you can make a building stronger by adding more steel, brick, concrete, etc. This can cover up design defects that make the builiding less strong than anticipated. (This is the whole reason for the safety margin.) Other than blanketing your program with assert statements and cumbersome exception handling, there is really no way to "add more steel" to a program design.
An everyday moderately complex non-commercial program can run 200,000 lines, and are usually developed for far less money than a car. There is simply no way those 200,000 lines will not have any bugs that will result in failure. The best you can hope for is that when it dies, it will die gracefully.
There are techinques to minimize defects, perhaps whittling them down to one or less defects per 1000 lines of delivered code, but without spending a forturne that number will never be zero without a fortune in testing. This is the simple reality of software development.
1) As other posters have pointed out, large, complex, software is almost impossible to write with zero defects. If most production software had to be bug free, there is no way anybody could afford it.
2) Limiting you from recovering consequential damages, etc. is something you see in almost all products for sale. And you almost never get to read the warranty before you buy pretty much everything. Just check the manual with your VCR, refridgerator, lawn mower, etc. They all, without exception, disclaim themselves from liability for incidental and consequential damages. (Except in such states that prohibit said exclusions.) Note that while this does not absolve them from gross negligence or intentional malice, but bugs in software generally would not fall into that category.
3) Put yourself in, say, a software writer's seat. If you are writing shareware with a $5 licensing fee, do you want to make yourself open to $1M+ lawsuits if someone relies on your software to do something important, and it breaks? Hell no!
The way I see it, you have one and only one of three choices: 1) Cheap/free(speech/beer) software. 2) Almost no software. (That is how much software would be written if it all had to be bug free, or else.) 3) Expensive software where you pay for the privledge of suing the pants off of the scmuck who wrote it.
Actually, IBM already uses EBL in the production of some specialized mainframe chips. I would provide a link to the article that goes over this, but it is on IBM's intranet.:(
Ed Foster over at InfoWorld has pointed out that a bill legitimizing electronic signitures could also have the effect of making valid the "click-wrap" licenses and agreements that we have all come to know and hate. Now you might have to actually read the page of dense fine print sigining over your first born child in return for being able to access the useless content of xyz.com. Before, it could be easily argued that the "I Agree" button did not constitute a signiture, and therefore no legally binding contract. Now, all those clauses ablsolving them of liability in case bad things happen to your data could "stick". (They might be unenforcable for other reasons, but this is beside the point.) This scares me infinately more than the security of these things.
Um... No. The "commerce clause" of the constitution only applies to the regulation of interstate commerce. The tax powers appear in separate clauses, and have nothing to do with commerce regulation. The proposed expansion of FDA administrative regulations do not need to be, (and are not) "disguised" as a tax law. (Indeed the FDA as an agency has no tax powers, so it would be impossible to do so.)
Um... Article I, Section 8, Clause 3: "[Congress shall have the power to] regulate Commerce with foreign Nations, and among the several States, and with the Indian Tribes;"
IBM is rolling this stuff out for several reasons:
1) Processors for network equipment need REALLY fast processors to handle ever faster network links intelligently. (i.e. handling packets at the IP layer and above, instead of acting as switches)
2) IBM believes in practical business applications for supercomputing. This is another step toward ever-faster machines for that purpose. This is part of Lou's "Pervasive Computing" initiatives.
3) Some of these new innovations cut heat production and reduce power requirements, this makes them useful for mobile applications. (Another part of "pervasive computing".)
No, these things aren't really needed for PC's. and IBM is not in the PC processor Biz. (Although they do perform a lot of fab work for those who are.)
All federal regulatory agencies are restrained under the congressional laws which created them. If congress wishes to override their actions, they may do so at will. All regulatory agencies have mandated public comment periods, which also give congress time to act. The reason that not all federal rules are spelled out in laws is that many of them take large amounts of specific technical knowledge and years of experience that would be impossible for congress to accrue.
It is true that a price must be attacted to human life, but the cost in this case is not that great. Every billion that the regulation costs is approx. $5 per worker. (Assuming approx. 200 million jobs in the U.S.) If the ergo requirements end up costing $100 billion, that is only $500 per employee. I don't think this is going to have a catastrophic effect on American business. This is epecially true considering how many millions of workers have a significant liklihood of devloping RSI unless ergonomics are taken into account.
Slashdot Mirror
Read the damn constitution, moron: Article 1, Section 10, only applies to states. (It is entitled, in the annotated version "Powers Denied to the States".)
Section 10.
No State shall enter into any Treaty, Alliance, or Confederation; grant Letters of Marque and Reprisal; coin Money; emit Bills of Credit; make any Thing but gold and silver Coin a Tender in Payment of Debts; pass any Bill of Attainder, ex
post facto Law, or Law impairing the Obligation of Contracts, or grant any Title of Nobility.
BTW, gold is not inflation free. What do you think comes out of gold mines, genius?
SirWired
Listen, genius... Unless some boneheaded sysadmin for some bizarre reason decided to physically connect the admin systems to the "outside world", (this would have to be explicitly configued in the I/O Control Program), the security is foolproof, period. End of story. A breach of the control systems by user images is physically impossible. The system hardware simply would not allow it, no matter how the program was written.
I did not say, "provided the security is good enough." The security already is impenetrable, right out of the box (er... crate). No OS patches, no BugTraq-reading. The trusted sysadmin would have to break it on purpose to do anything. And if you can't trust your sysadmin, clustering won't help.
It is far more likely that a clustered system would utterly collapse than this one "basket" would. Here is an anology: Let's say you have one billion dollars to move from point A to point B, in $20 bills. You can either load the bills into a fleet of NYC street taxi's (with the doors locked), or into a truck armored (and weaponed) like an M1A1 tank, and four completely redundant engines. Which would you choose? Multiple, unreliable, boxes that have been proven notoriously hard to secure; or one single, easy to administer, rock-solid box, with security that has been proven over decades to be bullet-proof.
This is more than just creating a new directory. When a new "server" is set up, it will get separate instance of Linux, completely separated from all other images. From the point of view of the customer, they will have the whole machine to themselves. If they want to rm -rf /, it isn't a problem for any other image. This is the big strength of a VM-based system. Also, the unbelivably flexible load balancing software can be configured to give a certain image an absolute allocation of system resources, (I/O bandwidth, CPU cycles, memory, whatever) and you can be positive that you will always have it. Any shortage of capacity can be anticipated far ahead of time and fixed in short order by setting up a Parallel Sysplex of multiple boxes. (After you have somehow exhausted the huge amount of internal on-the-fly expansion capacity.)
Also, it is FAR more likely that something like the power company or the outside net connection will go down before the mainframe itself fails. These are designed for ZERO downtime. So a company deploying one of these is far more likely to lose sleep worrying about external systems than the mainframe itself.
Different images in an S/390 / z900 are separated from each other in hardware and the VM software. The only way to circumvent this would be to somehow gain access to the VM control programs. You can be damn sure that these folks will be air-gapping the console and admin systems from public networks. VM controls cannot be accessed from the systems VM runs, period. (IIRC, this restriction is enforced in hardware.) In addition, the images cannot access the resources (storage or memory) of each other unless explicitly configured to do so in VM. The restrictions are good enough that mainframes have been running the same OS architecture for decades and I do not recall a single security breach of this nature.
SirWired
1) I concede that Robert Noyce did come up with the same idea shortly afterwards.
2) I also admit that Kilby's prototype was not feasible for mass production (I did not know that it never worked.) However, he did plan on using a solid-state process for the interconnects, independent of his original idea for having multiple components on a single piece of silicon. (If I remember correctly he even considered contacting Fairchild eventually about licensing their process for interconnects.)
3) The patent fight only occured because of some vague wording and a bad diagram in the TI patent. IIRC, specifically, the meaning of the words "laid down", and the meaning of Kilby's famous "flying wire" diagram.
Intel could possibly claim credit for a computer on every desk, since they were the first to develop the general purpose processor, but the first "embedded" application for IC's was the TI pocket calculator, for which Kilby was one of the engineers. While this was only a significant (as opposed to revolutionary) device, it served as an effective demonstration of what IC's were capable of.
If Robert Noyce were still alive today, I have no doubt that he would have shared the Nobel Prize.
On the other hand, the reason I have great respect for Jack Kilby is because he never sought a great fortune or fame for his discovery. AFAIK, he remained on the engineering staff from TI. That is not to say that seeking riches is ignoble, just that neither is not seeking them.
Perhaps I should have changed the wording of my post somewhat recognize the fact that Robert Noyce developed it at about the same time, and later won the patent. I did not mean to take anything away from anyone else.
In other words, it couldn't have happed to a better guy.
1) Um, IBM is making oodles of money off the internet. A massive portion of the services business comes from "e-business" stuff sold to Fortune 500 companies. (IBM's traditional customers.) Also, DB2 and WebSphere are getting to be pretty popular among enterprise customers.
2) IBM doesn't make any money off of AIX. Yes, they do charge licensing fees, but mainly it is sold as something you need to buy to run your RS/6000.
IBM makes it's big money from the holy trinity of high-end hardware, industrial-strength software applications, and services/solutions. Low-end hardware (like 1U servers and PC's) and commodity software (like OS's) are only provided because they need to be if IBM wants to sell a "solution" instead of merely products.
IBM's other major profit streams are Technology (patent portfolio, Chip fab services, etc.), ThinkPads (simply because they kick ass and can take advantage of IBM's research in displays, hard drives, etc.), and leases/loans so customers can afford all this stuff.
If Linux could do what IBM needs, (more reliability, better I/O, etc.) they would likely drop AIX like a hot potato, because developing it ain't cheap.
IBM actually makes more money selling software than any company in the world. (Through stock option tricks, M$ loses money selling software, and makes bucketloads selling stock) IBM simply doesn't want to waste it's time on $60/copy client software and client operating systems. The real money is in the mega-buck server software. Think about it, what would you rather support:
A) One zillion badly-built, non-standard PC'S, with similarly badly configured OS's? (at $60/copy) OR
B) Ten thousand badly-built, badly-configured, servers at many kilo-bucks per copy, per year.
And oh yes, services to maintain and run all those servers. If bits run through it, IBM wants to sell it to you.
SirWired
Well duh!, of course IBM will take the best changes and put them into the "official" release. Of course they will try to sell service and support for their supported version of the product. How is this different from what RedHat does? If you make your own major changes to the Linux kernel, don't expect RedHat to help you if your changes break things.
Next, is there even one example of IBM stealing Open Source Software and touting it as their own? While you can't expect that they will issue a press release for every little bug fix, I really don't think that they would steal any kind of major dev. effort. Remember that Sun tried this with the Blackdown fiasco.
I think IBM's new religion on Linux is genuine. You really think IBM enjoys writing DB2 over and over again for seven different operting systems? (Palm, Win16, Win32, WinNT/2000, AIX, OS/400 and OS/390) If IBM has a standard base to build value-added services and custom software, it sure makes their lives a lot easier. If WebSphere becomes a defacto standard (or at least widely used) application server, IBM can now sell services contracts (big $) that much easier. If the open version is a stepping stone, customers are more likely to buy the full (not-so-open) version.
Will IBM ever go totally open-source? No. IBM currently makes more money selling software licenses than any other company on the planet (including Microsoft and Oracle) It would be suicide for the Board of Directors (i.e. shareholder lawsuits) if they decided to give all that up. However, IBM would love to have commodity parts of the system open-source (i.e. web browsers) so it can spend precious dev. dollars on more lucrative packages. (What would you rather sell, a $60 OS (i.e. Windows), or a multi-million $ transaction processing package?) How can you say IBM's intentions are not clear. They have not once said that they want all software to be open. They have merely committed to keeping open standards open, and getting as much of their software ported to Linux as possible. IBM doesn't think like RMS, and it would be unreasonable to expect them to do so.
SirWired
OK, I am a little confused here... The "Open Source Community" begs companies to release open source software. IBM then announces the opening of the source for a major product. Next, I read crap like this with all sorts of conspiracy theories. What the hell?!?!
Of course IBM wants to dominate the industry. Every public company has a fiduciary duty to it's stockholders to attempt to gain a monopoly position in every market it enters. (Remember having a monopoly is not illegal, just using illegal means to maintain it.)
Next, who cares what IBM's intentions are? So what if they want to dominate hardware and services? Take the source and run! Ignore IBM's pleas to pay them to integrate. Hang up on the marketing rep when he tries to sell you hardware. Once you have the source, what the hell do you need IBM for? If you don't want IBM to be a focal point for change, fork the code!
Don't like "Tivoli Ready Modules"? Don't use 'em! Don't want to use VisualAge? Fine, who is going to stop you?
Exasperated at hair-trigger morons,
SirWired
Actually, in case anyone cares, this group was spun off from the mother company several years ago and is no longer an IBM dept.
Another interesting fact about this group is that the Capability Maturity Model was built around the processes that this group implemented, and they are the only software organization to hold a CMM of five for a sustained period of time.
However, their supreme reliability comes at the price of a cost-per-line almost double that of your average delivered software project. I guess you could say that their process is overkill for projects that don't require this kind of reliability.
Why do you say that IBM is not giving away anything substantial? Have you even looked at what they are giving out? When commercial, low-level, products are "opened", it is quite common for some parts to be witheld because the company simply does not exclusively own the rights to everything in the code. It probably has nothing to do with corporate treachery or evil PR minions, just simple licensing rights over which the IBM Software Group has no control.
In all states that charge a sales tax, you are obligated to pay the tax on goods purchased out of state. You must pay the tax yourself, as states are prohibited from forcing out-of-state businesses (meaning businesses with no physical presence in the state) to collect the tax themselves. The moratorium on "Internet" taxes only applies to tax laws that singled out internet transactions for special treatment.
The enforcement for out-of-state purchases has been somewhat lax, but nevertheless, you are leagally obligated to pay it. (Voluntary compliance is the backbone of the American system of taxation.)
SirWired
Um... IBM already has machines with copper interconnects, and now SOI, shipping right now. The chips that IBM is shoving out the door are POWER 4 architecture chips (closely related, but not identical to the PowerPC), (used in the RS/6000 and AS/400 not PowerPC chips. IBM was shipping copper (about a year now) even before anyone else had demo units available. Now the SOI is shipping, and again, no one else is even close. Just because it doesn't exist on PC's doesn't mean it doesn't exist.
SirWired
1) IBM is rolling these new technologies (copper interconnects, SOI, etc.) into their own, proprietary, platforms (RS/6000, AS/400, S/390) first for what should be obvious reasons. They are competing with the Intel server chips by producing non-intel servers. Why just make a profit selling the chip when you can really rake in the dough selling the chip, system, software, and services? You can be sure that it would take a $hitload of Athlons to match the profit produced by a single S/390 or big AS/400.
2) IBM also directly competes with Intel on several other fronts, namely communications chips. Intel makes more than x86 chips, even though those are Intel's cash cow. IBM is more than willing to license these technologies to Intel's competitors in the semi market on the theory that "the enemy of my enemy is my friend."
SirWired
Um... IBM has about a 50% marketshare for 2.5" laptop drives... nobody does component miniturzation better than IBM STD.
SirWired
I do work for Big Blue, and I can tell you that what you probably heard was that IBM was going to roll out Linux so it will run on each of its four server platforms. (NetFinity, AS/400, RS/6000, and S/390) There is simply no way that OS/390 will disappear, ever. Remember that OS/390 is a direct descendent of the OS that IBM "bet the company" on in the early '70's. (Software Eng. students will recall that that masssive, ugly project spawned the book, "The Mythical Man-Month".) You can be pretty sure that most of the bugs have been squashed flat by three decades of field use. IBM's goal is to have zero downtime by the end of next year, (I'm not sure, I am not in the )S/390 division) when a client uses a geographically distributed parallel sysplex setup. (That means two S/390s spread far apart working concurrently.) In addition, as another poster pointed out, OS/390 is tightly coupled to many of the unique features of the hardware, including parallel sysplex, a load balancing system so powerful that it makes Solaris look about as advanced as DOS, the partitioning system that provides rock-solid security by partitioning the system in hardware, all source of complex resource-sharing mechanisms, etc. In conclusion: When hell freezes over and Big Blue, and every one of our big clients goes bankrupt.
Hey, you are preaching to the choir here. I know that software done right the first time is always cheaper and better than software fixed later. However, even software done the right way WILL have defects. Remember that software defects can come from more than just coding errors. Vague documentation, a misunderstood spec, etc. are all defects which can result in catastrophe. Bad docs are something no testing program can detect, and they are subject to the whims of the English language.
A safety design defect free car is far eaiser to make than defect-free software. This is because for a car to be considered free of defects, it only must meet defined safety standards, and pass a certain set of well-defined tests. An entire car consists of a few thousand parts (most of which do not interact with each other), and costs hundreds of millions to design. The properties of those parts are well understood and easily testable.
With a skyscraper, I can run the design of a building through a streightforward analysis program an see if it will meet acceptable margins for safety. Keep in mind that a building is ususally several times as strong as the load it is supposed to carry. After all, you can make a building stronger by adding more steel, brick, concrete, etc. This can cover up design defects that make the builiding less strong than anticipated. (This is the whole reason for the safety margin.) Other than blanketing your program with assert statements and cumbersome exception handling, there is really no way to "add more steel" to a program design.
An everyday moderately complex non-commercial program can run 200,000 lines, and are usually developed for far less money than a car. There is simply no way those 200,000 lines will not have any bugs that will result in failure. The best you can hope for is that when it dies, it will die gracefully.
There are techinques to minimize defects, perhaps whittling them down to one or less defects per 1000 lines of delivered code, but without spending a forturne that number will never be zero without a fortune in testing. This is the simple reality of software development.
SirWired
1) As other posters have pointed out, large, complex, software is almost impossible to write with zero defects. If most production software had to be bug free, there is no way anybody could afford it.
2) Limiting you from recovering consequential damages, etc. is something you see in almost all products for sale. And you almost never get to read the warranty before you buy pretty much everything. Just check the manual with your VCR, refridgerator, lawn mower, etc. They all, without exception, disclaim themselves from liability for incidental and consequential damages. (Except in such states that prohibit said exclusions.) Note that while this does not absolve them from gross negligence or intentional malice, but bugs in software generally would not fall into that category.
3) Put yourself in, say, a software writer's seat. If you are writing shareware with a $5 licensing fee, do you want to make yourself open to $1M+ lawsuits if someone relies on your software to do something important, and it breaks? Hell no!
The way I see it, you have one and only one of three choices:
1) Cheap/free(speech/beer) software.
2) Almost no software. (That is how much software would be written if it all had to be bug free, or else.)
3) Expensive software where you pay for the privledge of suing the pants off of the scmuck who wrote it.
Actually, IBM already uses EBL in the production of some specialized mainframe chips. I would provide a link to the article that goes over this, but it is on IBM's intranet. :(
Ed Foster over at InfoWorld has pointed out that a bill legitimizing electronic signitures could also have the effect of making valid the "click-wrap" licenses and agreements that we have all come to know and hate. Now you might have to actually read the page of dense fine print sigining over your first born child in return for being able to access the useless content of xyz.com. Before, it could be easily argued that the "I Agree" button did not constitute a signiture, and therefore no legally binding contract. Now, all those clauses ablsolving them of liability in case bad things happen to your data could "stick". (They might be unenforcable for other reasons, but this is beside the point.) This scares me infinately more than the security of these things.
Um... No. The "commerce clause" of the constitution only applies to the regulation of interstate commerce. The tax powers appear in separate clauses, and have nothing to do with commerce regulation. The proposed expansion of FDA administrative regulations do not need to be, (and are not) "disguised" as a tax law. (Indeed the FDA as an agency has no tax powers, so it would be impossible to do so.)
Um... Article I, Section 8, Clause 3:
"[Congress shall have the power to] regulate Commerce with foreign Nations, and among the several States, and with the Indian Tribes;"
IBM is rolling this stuff out for several reasons:
1) Processors for network equipment need REALLY fast processors to handle ever faster network links intelligently. (i.e. handling packets at the IP layer and above, instead of acting as switches)
2) IBM believes in practical business applications for supercomputing. This is another step toward ever-faster machines for that purpose. This is part of Lou's "Pervasive Computing" initiatives.
3) Some of these new innovations cut heat production and reduce power requirements, this makes them useful for mobile applications. (Another part of "pervasive computing".)
No, these things aren't really needed for PC's. and IBM is not in the PC processor Biz. (Although they do perform a lot of fab work for those who are.)
All federal regulatory agencies are restrained under the congressional laws which created them. If congress wishes to override their actions, they may do so at will. All regulatory agencies have mandated public comment periods, which also give congress time to act. The reason that not all federal rules are spelled out in laws is that many of them take large amounts of specific technical knowledge and years of experience that would be impossible for congress to accrue.
It is true that a price must be attacted to human life, but the cost in this case is not that great. Every billion that the regulation costs is approx. $5 per worker. (Assuming approx. 200 million jobs in the U.S.) If the ergo requirements end up costing $100 billion, that is only $500 per employee. I don't think this is going to have a catastrophic effect on American business. This is epecially true considering how many millions of workers have a significant liklihood of devloping RSI unless ergonomics are taken into account.
BTW, $500M/person / 300M US pop. != $2,000