This message is from the T13 list server.
Sergio, If you will notice, the merits of your suggestion was not discussed. You could write the proposal up and bring it into the committee, but you will receive the same treatment at the committee. Hence the cynicism. Hence the emails that the committee is not responsive to the community. But when they want to get something done, it goes pretty fast and you will have difficulty noticing that it occurred. Regardless of what they say. The only way that this will be fixed is if enough people who would like to see these things acted upon come and are able to surmount the politics that will ensue. don clay 3/22/02 2:48:42 PM, "McGrath, Jim" <[EMAIL PROTECTED]> wrote: >This message is from the T13 list server. > > > >S�rgio, > >Companies strive to serve customers, and that's what the market is for. Any >company, identifying the market opportunity you cited, is free to service >it. They can do that without the leave of anyone else in the universe. > >None of that has anything to do with standards. > >Standards require an extraordinary level of agreement from all of the >affected parties. Or at least the lack of serious disagreement. Which is >why they take so long to do, and proposals are reviewed in so much detail, >and are revised so many times. A small minority has the ability (and >indeed, must have the ability) to block something in the standards process >if they feel they have a real problem with it. > >Put another way, it is not sufficient for a few people (or even many people) >to want to put something into a standard. It requires none or few people to >oppose its inclusion. That's why people who work in standards spend a lot >of time working with their counterparts trying to reach agreements that >everyone can live with. I'm always amazed at how people, often representing >direct competitors, can work together so well to the interests of everyone. > >On this particular issue, many people oppose inclusion of these commands in >the standard. Whether anyone thinks they are right or wrong, they have a >right to be heard and considered. And given the nature of the standards >process, probably the ability to block their inclusion. > >People of the opposite persuasion either have to listen to their objections >and address them constructively (i.e. with the aim of getting them to change >their mind), or take another tack to the problem (e.g. perhaps new commands >for new purposes that would get a more receptive hearing). This is what >people on the standards committee do all of the time, and I know its hard >work (I've done it). Some people, encountering this for the first time and >maybe not understanding why people act in this manner, get discouraged or >cynical. That's why I've spent a lot of time trying to explain this, so >people can engage more constructively in the future. > >Jim > > >-----Original Message----- >From: sraposo [mailto:[EMAIL PROTECTED]] >Sent: Friday, March 22, 2002 2:15 AM >To: ata reflector >Subject: Re: [t13] R/W Long Redux bonus for seek and Recalibrate > > >This message is from the T13 list server. > > >In march, 3rd 2002 I posted a question that timidly asked someone who had >the patience and time to answer, why read/write long commands were discarded >from AT/A-4 on and if it could become available again. >Today, 10 days after, people discussed a lot and even argued about this. It >seems that some people see that a HDD exists to serve people. A feature >already developed and tested should costs less to be kept than the >consequences of discarding it, as Don properly said. >Not all the real world computers are brand-new using the ultimate BIOS and >the most modern HDD. There is some inertia that makes a lot of not-new >computers over the world still useful running still useful applications that >could rely on some not-modern feature. >Those ones who work on software development know how stressing is write a >code that has to consider several versions, some has such features and lacks >of others, other versions has others features and lack other and so on. >I am not able to see the problems that someone who works at HDD development >sees, so I should not criticise anyone, but I agree with Don and others who >thinks that the other end of the line, that end where users are, should be >considered. It's not a battle between makers and users. Sure HDD and AT/A >should evolve, but I modestly suggest to consider real world people needs. > >Regards, > >S�rgio Raposo - Brazil > >>Reasons to keep the seek command >> 1. Provides backward compatibility. >> a. For older BIOS's. >> b. Costs nothing if you don't want to >> support it. >> c. Some people actually use it even if >> you don't. This is an entirely new >> concept to this reflector, acknowledging >> that if you don't use a command, maybe >> others do. I know it seems >> hard to believe.... >> 2. Provides diagnostic capability for the Host. >> a. Verify seek times. >> b. Verify mechanical soundness. >> c. Yes, this can be done in spite of the >> fact that the drive translates CHS, >> the fact that LBA's are issued, or zones, >> or other layouts make this difficult. >> >>Reasons why I will keep "crying" about these obsoleted commands. >> 1. It is apparently only "crying" if you are part of the immoral >> minority of this reflector. If you constantly harrangue two >> specific companies, one of which is in Redmond, and you're >> part of the moral majority of this reflector, that's ok. >> 2. The T13 committee screwed up when they obsoleted these >> commands. It makes it impossible for people with older systems >> to replace a hard drive that goes bad. Jim McGrath only >> enumerated one issue with backward compatibilty, >> but he said that it was fixed. But there are many older BIOS's >> that don't have this problem, So people might also have to >> upgrade their BIOS. A much better option than having to >> buy a completely new computer and facing a new OS and >> the potential of having to upgrade a significant portion of >> your software that you will now have to rent and trying to >> find new drivers for your hardware. Obsoletion is a practice >> that the company in Redmond has done profitably for years >> 3. It doesn't matter how many years go by. If a screw-up has >> occurred, it should be fixed. If companies are still putting the >> command in as a NOP (per Hale), and other companies are >> actually using it, isn't it kind of really still active? Doesn't it >> help the user community if the command is in the STANDARD? >> 4. If the committee didn't do due diligence on this, then shouldn't >> they be called on it. No, I don't have the emails for earlier >> than mid 96, nor do I think that it's relevant. There were people >> who posted to the reflector in 2002 saying that they were using >> these commands. That's what's important. Getting it >> right is important. >> 5. People who are the committee should be responsible for the >> whole of the community. They should act for the good of the >> whole. If they can't, they ought to step aside and let others >> run the show. But I repeat myself. But only because I haven't >> heard a valid argument yet on why the committee isn't >> responsible for the whole of the community. >> >> >> >> >> >> >> >> >> >
