Isn't one of the goals of algorithm selection data access optimization/minimization? Isn't a major portion of code optimization optimizing memory usage?
Even today one of the BIG WIN optimizations (and this IS an optimization, even though it seems like code generation 101) your compiler performs is to avoid fetching data that is already in registers, thus avoiding reading from that big slow main memory. Things like caching are only hardware approximations of what direct optimization can achieve, though using a simple hardware technique instead of the highly complex algorithms needed for high quality code optimizations.
Re:On SCSI drives and RAID controllers
on
IDE RAID Examined
·
· Score: 1
I'd point out that RAID is used for more than just production servers where its uptime and data safety that are the priorities. I've been involved in situations where RAID is used solely for performance, exceeding the performance achievable with a single drive (even going with pure RAID 0 since its not the long term preservation of the data or even uptime that matters). I've also been involved in situations where it was pure capacity of a single filesystem spaning multiple drives that was the driver, though in this case we did not want to loose anything on a disk crash, so we went with 0+1.
I should note that all of this was independent of IDE vs. SCSI, though much was SCSI simply because IDE RAID either did not yet exist or was not supported on the systems involved. Much of it was done with software RAID as the setting was usually one where money was extremely tight but the need for performance and/or space was close behind.
The average consumer discovers products via marketing. It is through a company's concerted marketing effort that names become recognized and customers become aware of products.
Open Source/Free Software will become mainstream when it is just as easy to find and "purchase" an Open Source/Free Software product as it is today to buy a commercial software product.
Microsoft certainly works hard to ensure its software dominates. But, until there are Open Source products with concerted marketing campaigns, it isn't going to make it to the mainstream.
Long ago in a galaxy far far away...... it used to be that ALL software was distributed in source code form, and then built by the customer prior to installing and putting it into production. The industry would have left things that way were it not for the fact that we were increasingly running into a number of big problems not solvable in that model:
- Customers didn't follow directions, so they always were screwing up the build and/or install. These were very simple tasks back then, much simpler than they are today. And in theory customers were far more educated since they were the very few who could afford those multi-million dollar machines and the huge costs of the rooms and facilities they required. Somehow, though, they still were able to find ways to screw things up, and support organizations spent much of their time walking customers through these processes.
This would be worse today given many software users have no clue how to program.
- Support was a total nightmare as you never knew what source code customers were using.This was because customers would choose which patches to apply, and would add their own, leaving each customer with a totally unique piece of software. When something went wrong in it, it was impossible to know what the code was supposed to be doing, and what it was doing wrong.
While this might not be quite as bad today, since we no longer must rely on "core dumps" to diagnose bugs, there still is the basic problem of being asked to diagnose problems when you really don't know WHAT source code that customer might be using.
- the intellectual property problem... there were plenty of lawyers back then, but there really is a big problem with investing lots of money to build something, a unique set of code, and then making it easy for people to lift it. A variety of methods to secure it while still distributing it to all customers were attempted as there was tremendous cost associated with changing from a source distribution technique to a binary distribution technique, but none ever worked. If anything, today there is far more sophistication on the cracking side, so it seems even more doubtful that it is possible to secure code from mis-use when its considered IP. And there ARE valid arguments against giving away all code.
SO...
There were good reasons the computer industry turned away from distributing their software in the form of source code. I don't think they have been addressed, and thus I am unconvinced the equation has changed.
The problem that cities such as Seattle have is the attitude displayed in this posting. Government IS the agent of the community. There are times when it is appropriate for the community to act in its interests, and Mass Transit is absolutely one such area. "Competition" is a silly concept when it comes to Mass Transit. Take a look at Seattle and you see there are very few places where the geography provides for the needs lines, be they roads or Mass Transit. It is very much in the community interest to maximize the efficient use of those lines. Thus, it is in the community interest to build a comprehensive Mass Transit system.
Why has it not been built?
Because no one has the courage to invest in the future. Instead we measure success by the pennies in the short term. Everyone agrees that NYC, and Manhattan in particular, could not exist without its Mass Transit... in fact, since 9/11 there have been strict limits on who can drive into the city... yet, by the measures imposed on new projects, today the Mass Transit system in NYC would never be built.
What we need is to have the courage to invest in our future. To recognize that sometimes investment is about building the things needed by our communities. Over the long run, such investment forever change our communities for the better. And they frequently do not stand up to today's financial-only cost-benefit analysis. Not all benefits are financial, nor are reflected in these formulas.
Its sad but true that in today's computing job market it is not skills or knowledge that will land you a job. In a world where many hundreds of resumes/CVs get submitted for every listed opening, the "trick" to landing a job is getting yourself considered for a position. It does not matter what is in your resume if no one ever reads it, nor does it matter how tuned your resume is if its in the middle of a pile of 1000 other resumes.
You probably have heard this before, but the key truly is networking. And/. is not where you'll be meeting the people that will help you find a job. Network by attending all the professional meetings taking place in your area; make sure that everyone who knows you knows you are job hunting with intent; don't be shy... make sure the people you bump into as you go about your life know... I got a great lead while riding up a chair lift at my favorite ski area last spring... it didn't turning into an interview, but it was a quality lead.
Volunteer for stuff in your field... though make sure its something that will cause you contact with other people. Not only will you keep the rust off your skills, but people will see what you know and then if they know someone needing those skills, they will be instrumental in hooking you up.
SO, go do the things you like to do in your life. And all the time make sure you talk to the people around you and let them know you are looking. And, make sure you have a business card to hand them so they remember who you are and how to contact you. Its a lot easier to just hand someone a business card on a chair lift, or at a checkout at your favorite store, than having to pull out some paper and jot down contact info.
Absolutely. talk/ntalk is part of the original Unix networking application set... you know, those applications everyone forgot about and then disabled with their firewalls.
It is amazing to me how many "new ideas" are just the same old thing rediscovered. That alone doesn't bother me. It is that they don't remember the past that most irks me. That dooms us to repeating the same mistakes rather than improving on the original.
Whether it be IM, or the semantic web, its all been done before.
Please keep in mind that the reason we have the wide variety of shells is because each has their own stengths and weaknesses. For example, csh on the surface is more user friendly, but once you start doing non-trival things with you, you quickly run into "quoting hell" (long before dll hell existed there was quoting hell). The original shell sh was unforgiving and inflexible. Korn shell, ksh, was pretty nifty, but it was never as widely adopted as it should have been, probably because it did not propagate the problems of csh.
Anyway, my point here is to say that if one is going to work at the command line level, it really does matter which shell you use. And, combined shells, shells that try to be all shells in one always involve compromise, making some things less good and others better than they are in the un-mingled shells. Thus, I really don't see the value in yet another round of trying to merge the shells into a single shell, and then have everything split off again.
Some people argue that scripting is now dominated by the "higher level scripting languages" such as Perl, and thus it no longer matters which shell you use. I guess I could buy this IF all scripting was done in these languages AND they were universal in all Unix/Linux systems. But, I don't see it being there right now. Which is what really matters, because when I have to write my next portable shell script, I'm still going to have to pick my shell, and I'm going to end up going for the closest to ksh that I can find.
1 - Microsoft claims most APIs as security related. A reasonable seeming argument could probably be made for a significant number of APIs of interest, particularly given that every API is a potential buffer overrun attack target.
2 - US Government order Microsoft not to reveal APIs as a national security issue.
I hate to think about how much business with me AT&T has lost due to their poor record keeping or just plain sleezy tactics, though I doubt it is the latter.
My wife and I have been customers of local AT&T broadband phone as well as AT&T long distance. This is relevent because we have been getting solicitations to switch our local phone server to AT&T broadband at least twice a week for months. What have they to gain from selling me a service I already have? Even worse, when I tell them I'm already a customer THEY DON'T GET IT and continue their pitch.
If they do stop their pitch, I always stump them with the "If you can sell me a package with local, long distance, high speed internet (cable or DSL, don't care much), & cell". Every once in a while they answer that they can't do that as AT&T Wireless is not the same company, at which point I go into the circular argument about how AT&T Wireless couldn't use the AT&T name without being part of AT&T.
The bottom line is that the service we get from AT&T Broadband for our local telephone service is FAR better than the original carrier, but AT&T customer service is AWFUL, and that includes their telemarketing.
We have gotten quite accustomed to the very cool and efficient operation of our high density VLSI microprocessors. How soon we forget the days when computers were constructed not of VLSI devices, nor even discrete component semiconductors, but good old tubes! Those babies got HOT! I can't imagine cooling on the scale of a supercomputer is any more difficult than cooling the old discrete component and tube computers had been. I would guess the primary challenge is finding a cost efficient cooling technique that efficiently absorbs the heat from all of those CPU chips.
The problem lies in how a standard is developed more than the standard itself. In my 22+ years of experience, successful standards are those that are developed in response to a need perceived by multiple vendors for a standard to interconnect or interoperate a number of EXISTING products. The standard may take the form of something new, or it may take on the appearance of a one or more of the existing products. There are many examples of successful standards that have followed this path of development. I'd suggest that software language standards, EE CAD systems, and most communications standards followed this path.
A second path developed many years ago which I believe leads primarily to unsuccessful standards. In this case, customers who wish to use products built to comply with the standard define a standard before there are existing and tested products in that area. Vendors are then left to develop totally new product to comply with the standard, or be totally non-compliant. Frequently some form of leverage is applied to force vendors to comply, yet the content of the new standard is untested until compliance is forced, and thus lots of money goes into standardized yet untested products which generally quickly fail. My favorite example of this latter type of standard is X.400... this is a standard for a full email system that has never been built. It does continue in life as a sometimes used standard for interconnecting other email system. But it is considered a failure as a standard. Other examples would be CASE (remember that?), and now more controversially, many of the new XML standards that are ahead of the industries for which they are actually intended (note the problem is not XML itself, it is finding agreement what the content should be and its semantics, not its technical representation).
I believe we continue to see a growth in the percentage of standards that follow the second path. It thus is no surprise to me that we see more and more failed standards. I wish I knew how to encourage greater use of the former method as it sure would make for a more integrated computing environment.
There are numerous postings observing that warranty periods are being reduced to save money. This is absolutely correct as far as it goes, but there is a key piece missing.
It is not necessary to have drives fail for companies to have expense associated with warranties. Specifically, a company must account a certain amount for every potential liability represented by a drive sold and within its warranty period. For companies with high volume low margin businesses, such as the desktop disk drive market, this can represent a significant percentage of their cash on hand. This then has very significant impact on the other financial activity of the company, such as investing in R&D, or even paying salaries. Thus, reducing warranty period reduces the potential expense that must be budgeted independent of whether there are drive failures during that time.
I should note that I believe this WAS described in the original article, but many/. readers appear to have missed it.
There are costs and then there are costs. The problem with longer warranties that go unused is that the company must keep a certain amount of funds in the warranty account to cover the potential expense represented by the current set of drives currently covered by warranty. Thus, reducing the warranty period reduces costs to the company by freeing more of their cash on hand for other uses. It does not take drives failing in the second and third years for them to save money with shorter warranty periods.
A few years ago I worked as a consultant on an Air Force contract. The project was part of an effort to introduce "modern" software techniques into the Military's software development organization. Part of this work included bringing COTS (Commercial of the Shelf) products into compliance with various government and military standards. Our organization did a pretty reasonable job of meeting the Air Force's requirements for our specific projects on a reasonable budget, comparable to a commercial budget for equivalent projects.
My primary point in posting this, though, was that while the Air Force did a reasonable job of things, the Navy always seemed to be ahead of the other services. Inter-service projects being done jointly with the Navy were quite a challenge for our Air Force team as they were always well ahead of us, both in technology and budget efficiency. I can't imagine that things have changed dramatically in the relatively short time since I left that job.
Back in the "good-old-days", a primary benefit of the "newer", larger "bit" processors were the larger instructions. An 8-bit processor had small 8-bit instructions, with maybe some double-"word" instructions that were much slower to execute, along with an 8-bit integer math unit. Floating point, when you had it, was also constrained by the 8-bit size, though a bit less tightly. Thus, moving up in size, meant increases in performance on many fronts, but instruction width, integer math width, and addressing were the big ones.
I am wondering how this applies to these latest 64-bit processors. In the days of RISC, one would think that a reduced instruction set would easily fit in 32-bit instructions (those are rather huge and comfy compared to the old 8-bit days), though I would guess that a 64-bit instruction can include an opcode, register specification AND 32-bits of memory address, which would mean fewer multi-word instructions, which by old measures means faster execution. A 64-bit integer unit would have some real benefit. I find more and more cases where 32-bit integers are not sufficiently large to cover the range of values needed for problems, and that is without addressing over 32-bits of data.
I am curious if someone can compare these attributes of the current Pentium 4/Athlon XP processors with this PowerPC 970, the current SPARC from Sun (Ultra is it?), and the current HP/PA processor (though isn't that being dropped in favor of Itanium?)?
The problem as I see it is that the PC hardware platform is significantly less expensive. Thus, if the same software is available for both platforms short of the OS, this argument could actually appeal to businesses. That is not to buy into the Microsoft claims. It is simply the same argument as the Linux argument, short of the free OS... the hardware platform is a significant savings, so shouldn't we take advantage of that AND reduce the number of platforms we need to support?
I would recommend you read up on the legal issue of reverse engineering because it is under attack and it is not at all obvious that it will survive. I believe the latest issue of ACM Communications has an excellent article on the topic. Recent US Government laws are very disconcerting.
Preventing the copying of software media has been a goal of software distributors since the mainframe era, when all software was distributed as source code (note that this was long before the open source era, and ended because it proved impossible to support... but that's a different topic for another day). We have already been through at least one "copy-protection" cycle and appear to be heading into a new one. It could be educational to look at what happened the last time around.
I think we can all agree that the last coming of copy protection was not successful, if for no other reason than it vanished. It vanished because customers were constantly having problems caused by these copy protection schemes while "cracker" programs were abundant and in many cases easier to use than the copy-protection schemes themselves.
Given the past, will a new venture into copy-protection have the same problems?
I think that many of the problems of the old copy protection schemes that made it hard for users have not changed. Chaining down software to any specific piece of hardware introduces a single point of failure. Murphy's law continues to rule, so single points of failure fail. Maybe the physical media becomes unreadable. Or, the drive breaks with the media in it, or someone pours hot coffee on it and melts it, or leaves it laying on the heating coils, or... Additionally, I think the continuing problems with viruses demonstrates that cracker programs will once again become common place.
One last thought... has anyone else noticed that viruses, worms and relatives really stated appearing about the time the copy protection programs faded from sight? Maybe with the resurgence of copy protection, and thus cracker programs, the virus writers will get busy and write fewer infectious programs. One can only hope.
Please note that I am not taking a side here, mearly observing societal behavior and how it will manifest itself regarding the Internet. There is much talk about how the Internet shall be free, yet there are lots of people out there that have strong beliefs that this is wrong and work hard to act on those beliefs.
The one opinion I WILL give... I do not believe technology will ensure the freedom of the Internet. If the desire to filter and/or surpress is great enough, that WILL happen independent of the specifics of the technology.
This is where things get interesting. Pornography is content that society has deemed unacceptable and thus controlled. The reason why pre-Internet you had to be 18 was because society decided that you were not mature enough to consume the material until that age. And, before someone jumps in with "that evil government", note that it usually is NOT government, but those claiming moral authority in the community that work to impose these limits.
What is interesting is that the Internet has changed the meaning of community. And thus, while there are still voices screaming for the control of this material on the Internet, what is different is that it is not clear who comprises the community, and who can argue for restrictions and controls. There ARE a few examples of successful surpression... Holocost and Nazi issues in Germany come most quickly to mind. But these are few and far between.
I am sure there will be attempts at the Internet equivalent of book burnings to come, yet I have no idea what form they will take nor when that may happen. And that is when you'll see that Pornography is an issue on the Internet, just as it is in our neighborhoods and communities.
The movie explains how the series was cancelled. Wouldn't that be edgy enough for it to be worth doing? Throw in a dose of politics (Homer & Bart fight Saddam after Grandpa casts the deciding vote in the Florida election), the coming and going of global warming and an ice age or two, and I think they can easily fill a feature or two.
How does elimination of both PA-RISC and Alpha help HP? I presume the premise is that both lines loose money. But, how is it better to go with an Intel architecture that is unproven over two quality architectures that have shown good strength over the years. Note that HP does not own Alpha... Digital long ago sold that to... Intel, and now simply license it back. Wonder why there have been no major advances of Alpha in the past five years?
Slashdot Mirror
Isn't one of the goals of algorithm selection data access optimization/minimization? Isn't a major portion of code optimization optimizing memory usage?
Even today one of the BIG WIN optimizations (and this IS an optimization, even though it seems like code generation 101) your compiler performs is to avoid fetching data that is already in registers, thus avoiding reading from that big slow main memory. Things like caching are only hardware approximations of what direct optimization can achieve, though using a simple hardware technique instead of the highly complex algorithms needed for high quality code optimizations.
I'd point out that RAID is used for more than just production servers where its uptime and data safety that are the priorities. I've been involved in situations where RAID is used solely for performance, exceeding the performance achievable with a single drive (even going with pure RAID 0 since its not the long term preservation of the data or even uptime that matters). I've also been involved in situations where it was pure capacity of a single filesystem spaning multiple drives that was the driver, though in this case we did not want to loose anything on a disk crash, so we went with 0+1.
I should note that all of this was independent of IDE vs. SCSI, though much was SCSI simply because IDE RAID either did not yet exist or was not supported on the systems involved. Much of it was done with software RAID as the setting was usually one where money was extremely tight but the need for performance and/or space was close behind.
The average consumer discovers products via marketing. It is through a company's concerted marketing effort that names become recognized and customers become aware of products.
Open Source/Free Software will become mainstream when it is just as easy to find and "purchase" an Open Source/Free Software product as it is today to buy a commercial software product.
Microsoft certainly works hard to ensure its software dominates. But, until there are Open Source products with concerted marketing campaigns, it isn't going to make it to the mainstream.
Let's also remember what should be obvious:
Not all customers know how to program.
In fact, most do not.
Therefore, all shipping source code to the majority of non-programming customers will do only one thing, totally confuse them.
Long ago in a galaxy far far away... ... it used to be that ALL software was distributed in source code form, and then built by the customer prior to installing and putting it into production. The industry would have left things that way were it not for the fact that we were increasingly running into a number of big problems not solvable in that model:
- Customers didn't follow directions, so they always were screwing up the build and/or install. These were very simple tasks back then, much simpler than they are today. And in theory customers were far more educated since they were the very few who could afford those multi-million dollar machines and the huge costs of the rooms and facilities they required. Somehow, though, they still were able to find ways to screw things up, and support organizations spent much of their time walking
customers through these processes.
This would be worse today given many software users have no clue how to program.
- Support was a total nightmare as you never knew what source code customers were using.This was because customers would choose which patches to apply, and would add their own, leaving each customer with a totally unique piece of software. When something went wrong in it, it was impossible to know what the code was supposed to be doing, and what it was doing wrong.
While this might not be quite as bad today, since we no longer must rely on "core dumps" to diagnose bugs, there still is the basic problem of being asked to diagnose problems when you really don't know WHAT source code that customer might be using.
- the intellectual property problem... there were plenty of lawyers back then, but there really is a big problem with investing lots of money to build something, a unique set of code, and then making it easy for people to lift it. A variety of methods to secure it while still distributing it to all customers were attempted as there was tremendous cost associated with changing from a source distribution technique to a binary distribution technique, but none ever worked. If anything, today there is far more sophistication on the cracking side, so it seems even more doubtful that it is possible to secure code from mis-use when its considered IP. And there ARE valid arguments against giving away all code.
SO...
There were good reasons the computer industry turned away from distributing their software in the form of source code. I don't think they have been addressed, and thus I am unconvinced the equation has changed.
The problem that cities such as Seattle have is the attitude displayed in this posting. Government IS the agent of the community. There are times when it is appropriate for the community to act in its interests, and Mass Transit is absolutely one such area. "Competition" is a silly concept when it comes to Mass Transit. Take a look at Seattle and you see there are very few places where the geography provides for the needs lines, be they roads or Mass Transit. It is very much in the community interest to maximize the efficient use of those lines. Thus, it is in the community interest to build a comprehensive Mass Transit system.
Why has it not been built?
Because no one has the courage to invest in the future. Instead we measure success by the pennies in the short term. Everyone agrees that NYC, and Manhattan in particular, could not exist without its Mass Transit... in fact, since 9/11 there have been strict limits on who can drive into the city... yet, by the measures imposed on new projects, today the Mass Transit system in NYC would never be built.
What we need is to have the courage to invest in our future. To recognize that sometimes investment is about building the things needed by our communities. Over the long run, such investment forever change our communities for the better. And they frequently do not stand up to today's financial-only cost-benefit analysis. Not all benefits are financial, nor are reflected in these formulas.
Its sad but true that in today's computing job market it is not skills or knowledge that will land you a job. In a world where many hundreds of resumes/CVs get submitted for every listed opening, the "trick" to landing a job is getting yourself considered for a position. It does not matter what is in your resume if no one ever reads it, nor does it matter how tuned your resume is if its in the middle of a pile of 1000 other resumes.
/. is not where you'll be meeting the people that will help you find a job. Network by attending all the professional meetings taking place in your area; make sure that everyone who knows you knows you are job hunting with intent; don't be shy... make sure the people you bump into as you go about your life know... I got a great lead while riding up a chair lift at my favorite ski area last spring... it didn't turning into an interview, but it was a quality lead.
You probably have heard this before, but the key truly is networking. And
Volunteer for stuff in your field... though make sure its something that will cause you contact with other people. Not only will you keep the rust off your skills, but people will see what you know and then if they know someone needing those skills, they will be instrumental in hooking you up.
SO, go do the things you like to do in your life. And all the time make sure you talk to the people around you and let them know you are looking. And, make sure you have a business card to hand them so they remember who you are and how to contact you. Its a lot easier to just hand someone a business card on a chair lift, or at a checkout at your favorite store, than having to pull out some paper and jot down contact info.
Absolutely. talk/ntalk is part of the original Unix networking application set... you know, those applications everyone forgot about and then disabled with their firewalls.
It is amazing to me how many "new ideas" are just the same old thing rediscovered. That alone doesn't bother me. It is that they don't remember the past that most irks me. That dooms us to repeating the same mistakes rather than improving on the original.
Whether it be IM, or the semantic web, its all been done before.
Please keep in mind that the reason we have the wide variety of shells is because each has their own stengths and weaknesses. For example, csh on the surface is more user friendly, but once you start doing non-trival things with you, you quickly run into "quoting hell" (long before dll hell existed there was quoting hell). The original shell sh was unforgiving and inflexible. Korn shell, ksh, was pretty nifty, but it was never as widely adopted as it should have been, probably because it did not propagate the problems of csh.
Anyway, my point here is to say that if one is going to work at the command line level, it really does matter which shell you use. And, combined shells, shells that try to be all shells in one always involve compromise, making some things less good and others better than they are in the un-mingled shells. Thus, I really don't see the value in yet another round of trying to merge the shells into a single shell, and then have everything split off again.
Some people argue that scripting is now dominated by the "higher level scripting languages" such as Perl, and thus it no longer matters which shell you use. I guess I could buy this IF all scripting was done in these languages AND they were universal in all Unix/Linux systems. But, I don't see it being there right now. Which is what really matters, because when I have to write my next portable shell script, I'm still going to have to pick my shell, and I'm going to end up going for the closest to ksh that I can find.
There are two huge "outs" for this:
1 - Microsoft claims most APIs as security related. A reasonable seeming argument could probably be made for a significant number of APIs of interest, particularly given that every API is a potential buffer overrun attack target.
2 - US Government order Microsoft not to reveal APIs as a national security issue.
I hate to think about how much business with me AT&T has lost due to their poor record keeping or just plain sleezy tactics, though I doubt it is the latter.
My wife and I have been customers of local AT&T broadband phone as well as AT&T long distance. This is relevent because we have been getting solicitations to switch our local phone server to AT&T broadband at least twice a week for months. What have they to gain from selling me a service I already have? Even worse, when I tell them I'm already a customer THEY DON'T GET IT and continue their pitch.
If they do stop their pitch, I always stump them with the "If you can sell me a package with local, long distance, high speed internet (cable or DSL, don't care much), & cell". Every once in a while they answer that they can't do that as AT&T Wireless is not the same company, at which point I go into the circular argument about how AT&T Wireless couldn't use the AT&T name without being part of AT&T.
The bottom line is that the service we get from AT&T Broadband for our local telephone service is FAR better than the original carrier, but AT&T customer service is AWFUL, and that includes their telemarketing.
We have gotten quite accustomed to the very cool and efficient operation of our high density VLSI microprocessors. How soon we forget the days when computers were constructed not of VLSI devices, nor even discrete component semiconductors, but good old tubes! Those babies got HOT! I can't imagine cooling on the scale of a supercomputer is any more difficult than cooling the old discrete component and tube computers had been. I would guess the primary challenge is finding a cost efficient cooling technique that efficiently absorbs the heat from all of those CPU chips.
The problem lies in how a standard is developed more than the standard itself. In my 22+ years of experience, successful standards are those that are developed in response to a need perceived by multiple vendors for a standard to interconnect or interoperate a number of EXISTING products. The standard may take the form of something new, or it may take on the appearance of a one or more of the existing products. There are many examples of successful standards that have followed this path of development. I'd suggest that software language standards, EE CAD systems, and most communications standards followed this path.
A second path developed many years ago which I believe leads primarily to unsuccessful standards. In this case, customers who wish to use products built to comply with the standard define a standard before there are existing and tested products in that area. Vendors are then left to develop totally new product to comply with the standard, or be totally non-compliant. Frequently some form of leverage is applied to force vendors to comply, yet the content of the new standard is untested until compliance is forced, and thus lots of money goes into standardized yet untested products which generally quickly fail. My favorite example of this latter type of standard is X.400... this is a standard for a full email system that has never been built. It does continue in life as a sometimes used standard for interconnecting other email system. But it is considered a failure as a standard. Other examples would be CASE (remember that?), and now more controversially, many of the new XML standards that are ahead of the industries for which they are actually intended (note the problem is not XML itself, it is finding agreement what the content should be and its semantics, not its technical representation).
I believe we continue to see a growth in the percentage of standards that follow the second path. It thus is no surprise to me that we see more and more failed standards. I wish I knew how to encourage greater use of the former method as it sure would make for a more integrated computing environment.
There are numerous postings observing that warranty periods are being reduced to save money. This is absolutely correct as far as it goes, but there is a key piece missing.
/. readers appear to have missed it.
It is not necessary to have drives fail for companies to have expense associated with warranties. Specifically, a company must account a certain amount for every potential liability represented by a drive sold and within its warranty period. For companies with high volume low margin businesses, such as the desktop disk drive market, this can represent a significant percentage of their cash on hand. This then has very significant impact on the other financial activity of the company, such as investing in R&D, or even paying salaries. Thus, reducing warranty period reduces the potential expense that must be budgeted independent of whether there are drive failures during that time.
I should note that I believe this WAS described in the original article, but many
There are costs and then there are costs. The problem with longer warranties that go unused is that the company must keep a certain amount of funds in the warranty account to cover the potential expense represented by the current set of drives currently covered by warranty. Thus, reducing the warranty period reduces costs to the company by freeing more of their cash on hand for other uses. It does not take drives failing in the second and third years for them to save money with shorter warranty periods.
This is what the movie industry ALWAYS says.
When TV was launched, the movie industry cried that it would be the end of movies and it wasn't.
When color TV was launched, the movie industry cried that it would be the end of movies, and it wasn't.
When the VCR was launched, the movie industry cried that it would be the end of movies, and it wasn't.
And when DVD was launched, the movie industry cried that it would be the end of movies, and....
A few years ago I worked as a consultant on an Air Force contract. The project was part of an effort to introduce "modern" software techniques into the Military's software development organization. Part of this work included bringing COTS (Commercial of the Shelf) products into compliance with various government and military standards. Our organization did a pretty reasonable job of meeting the Air Force's requirements for our specific projects on a reasonable budget, comparable to a commercial budget for equivalent projects.
My primary point in posting this, though, was that while the Air Force did a reasonable job of things, the Navy always seemed to be ahead of the other services. Inter-service projects being done jointly with the Navy were quite a challenge for our Air Force team as they were always well ahead of us, both in technology and budget efficiency. I can't imagine that things have changed dramatically in the relatively short time since I left that job.
Back in the "good-old-days", a primary benefit of the "newer", larger "bit" processors were the larger instructions. An 8-bit processor had small 8-bit instructions, with maybe some double-"word" instructions that were much slower to execute, along with an 8-bit integer math unit. Floating point, when you had it, was also constrained by the 8-bit size, though a bit less tightly. Thus, moving up in size, meant increases in performance on many fronts, but instruction width, integer math width, and addressing were the big ones.
I am wondering how this applies to these latest 64-bit processors. In the days of RISC, one would think that a reduced instruction set would easily fit in 32-bit instructions (those are rather huge and comfy compared to the old 8-bit days), though I would guess that a 64-bit instruction can include an opcode, register specification AND 32-bits of memory address, which would mean fewer multi-word instructions, which by old measures means faster execution. A 64-bit integer unit would have some real benefit. I find more and more cases where 32-bit integers are not sufficiently large to cover the range of values needed for problems, and that is without addressing over 32-bits of data.
I am curious if someone can compare these attributes of the current Pentium 4/Athlon XP processors with this PowerPC 970, the current SPARC from Sun (Ultra is it?), and the current HP/PA processor (though isn't that being dropped in favor of Itanium?)?
The problem as I see it is that the PC hardware platform is significantly less expensive. Thus, if the same software is available for both platforms short of the OS, this argument could actually appeal to businesses. That is not to buy into the Microsoft claims. It is simply the same argument as the Linux argument, short of the free OS... the hardware platform is a significant savings, so shouldn't we take advantage of that AND reduce the number of platforms we need to support?
I would recommend you read up on the legal issue of reverse engineering because it is under attack and it is not at all obvious that it will survive. I believe the latest issue of ACM Communications has an excellent article on the topic. Recent US Government laws are very disconcerting.
Preventing the copying of software media has been a goal of software distributors since the mainframe era, when all software was distributed as source code (note that this was long before the open source era, and ended because it proved impossible to support... but that's a different topic for another day). We have already been through at least one "copy-protection" cycle and appear to be heading into a new one. It could be educational to look at what happened the last time around.
I think we can all agree that the last coming of copy protection was not successful, if for no other reason than it vanished. It vanished because customers were constantly having problems caused by these copy protection schemes while "cracker" programs were abundant and in many cases easier to use than the copy-protection schemes themselves.
Given the past, will a new venture into copy-protection have the same problems?
I think that many of the problems of the old copy protection schemes that made it hard for users have not changed. Chaining down software to any specific piece of hardware introduces a single point of failure. Murphy's law continues to rule, so single points of failure fail. Maybe the physical media becomes unreadable. Or, the drive breaks with the media in it, or someone pours hot coffee on it and melts it, or leaves it laying on the heating coils, or... Additionally, I think the continuing problems with viruses demonstrates that cracker programs will once again become common place.
One last thought... has anyone else noticed that viruses, worms and relatives really stated appearing about the time the copy protection programs faded from sight? Maybe with the resurgence of copy protection, and thus cracker programs, the virus writers will get busy and write fewer infectious programs. One can only hope.
Please note that I am not taking a side here, mearly observing societal behavior and how it will manifest itself regarding the Internet. There is much talk about how the Internet shall be free, yet there are lots of people out there that have strong beliefs that this is wrong and work hard to act on those beliefs.
The one opinion I WILL give... I do not believe technology will ensure the freedom of the Internet. If the desire to filter and/or surpress is great enough, that WILL happen independent of the specifics of the technology.
This is where things get interesting. Pornography is content that society has deemed unacceptable and thus controlled. The reason why pre-Internet you had to be 18 was because society decided that you were not mature enough to consume the material until that age. And, before someone jumps in with "that evil government", note that it usually is NOT government, but those claiming moral authority in the community that work to impose these limits.
What is interesting is that the Internet has changed the meaning of community. And thus, while there are still voices screaming for the control of this material on the Internet, what is different is that it is not clear who comprises the community, and who can argue for restrictions and controls. There ARE a few examples of successful surpression... Holocost and Nazi issues in Germany come most quickly to mind. But these are few and far between.
I am sure there will be attempts at the Internet equivalent of book burnings to come, yet I have no idea what form they will take nor when that may happen. And that is when you'll see that Pornography is an issue on the Internet, just as it is in our neighborhoods and communities.
The movie explains how the series was cancelled. Wouldn't that be edgy enough for it to be worth doing? Throw in a dose of politics (Homer & Bart fight Saddam after Grandpa casts the deciding vote in the Florida election), the coming and going of global warming and an ice age or two, and I think they can easily fill a feature or two.
How does elimination of both PA-RISC and Alpha help HP? I presume the premise is that both lines loose money. But, how is it better to go with an Intel architecture that is unproven over two quality architectures that have shown good strength over the years. Note that HP does not own Alpha... Digital long ago sold that to... Intel, and now simply license it back. Wonder why there have been no major advances of Alpha in the past five years?