sdo@ursa.UUCP (03/26/87)
>> If SUN passed on a Berkeley bug it becomes >>SUN's bug, because they were the last to muck with it. > >Except that it's NOT A BUG. It's a FEATURE. It's SUPPOSED to work that >way. Since Sun 3.2 csh claims to be compatible with 4.3 csh, it would >have been a bug NOT to change the behavior. SunOS certainly has its share >of bugs, but let's be fair about finger pointing. Granted that the upgrade was necessary (and important, since it allows other arguments to be passed on the command line), I think the real point here not whether the change ought to have been made (it ought) but what Sun should have done about the fact that it was made. The only way to find out about the change was to do a man csh after the upgrade. This is a little unreasonable -- obviously no one is going to read 8 sections of UNIX manuals to find out if things are upward compatable. If Sun had made a section in the release notes about programs which are not iupward compataible, everyone would have made the change initially, and this discussion would have been avoided. Instead, a lot of things failed for a lot of people who had to put in a lot of extra hours to track down what is essentially a minor change. -- Scott Oaks Bear Stearns (212) 952-3164 {convex, sunrise, cuctr}!ursa!sdo
dce@mips.UUCP (03/27/87)
In article <185@teddy.ursa.UUCP> sdo@teddy.UUCP (Scott Oaks) writes: >The only way to find out about the change was to do a man csh after the >upgrade. This is a little unreasonable -- obviously no one is going to >read 8 sections of UNIX manuals to find out if things are upward compatable. >If Sun had made a section in the release notes about programs which are not >iupward compataible, everyone would have made the change initially, and this >discussion would have been avoided. Instead, a lot of things failed for >a lot of people who had to put in a lot of extra hours to track down what >is essentially a minor change. While I'm not defending Sun in this particular case, I am very sensitive to the issue of release notes and people reading them. Recent events have shown me that people that are "Unix-literate" will actually tend to not read release notes as carefully as beginners. Also, there are cases in which people do not pass the release notes on to all of their users. People tend to think "Unix is Unix". There are users that can't believe that our system would be different from 4.3BSD or System V.3, even though we call them by different names and point out that we supply an "enhanced" system, just as there are AT&T marketing folks that will try to create named pipes on a BSD-based system no matter how much you say "BSD doesn't have named pipes!". In our system release notes, we try to list everything that changed in the system, even those things that didn't change functionally, so that a customer will have a quick reference. We also try to provide automatic system file conversion (such as for the NFS version of /etc/fstab and the 4.2-4.3 change in /etc/ttys) so that the users don't have to worry about them. Even the best release notes and conversion tools don't help the poor system administrator that has inherited a whole slew of shell scripts (mostly written by people that never intended them to be used by anyone else) that start breaking just because they used a "feature" that wasn't explicitly documented. What can be done to really make getting new releases painless? -- David Elliott UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!dce, DDD: 408-720-1700