scott@dtscp1.UUCP (Scott Barman) (06/15/89)
In article <24@nx32s.anduk.co.uk> lee@nx32s.UUCP (0000-Liam R. Quin) writes: >>PLEASE STOP TRYING TO BREAK OUR *MEGABYTES* OF DOCUMENTATION!!! >No-one is doing this. You can stop shouting now [0.5 :-)]. >If you still need convincing, though, send me some mail! > >>*AND* we (read: me, >>the part-time sys admin., full time programmer) do not want to maintain >>N versions of troff! I did it once and it was not fun or easy! >No-one seems to be about to force you to use GNU troff. If you prefer >to walk, walk. We'll take the `plane. [:-) :-) :-)] Before I go on, these changes are effective in the product by SoftQuad Publishing as well (long names). I know I do not have to use gnu, but because of agreements that I understand exist (and I am sure I will hear about it if not true), there is a distinct possibility that I will be using these changes on future System V releases (through whatever botched up licensing procedures they have now). OK, I've received a number of email inquiries and a number of public comments that in effect say, "why in the #$%^& are you opposed to this?" So to satisfy some of you, I present for the net my *humble* opinion. Fundamentally, I am not opposed to any change that would improve not only the use, but performance of troff. I think long names are an interesting concept, but is a relativly minor issue compared to capabilites it does not have. Some of what I have seen that has been accomplished in what sounds like a re-write by SoftQuad Publishing sounds interesting and one day I will get it together and take a closer look at it. However (and you knew a "however" was due about now), I worry about what would happen to upward compatibility if one change is "allowed" to be entered in to stop that smooth transision. Until this change, documents that have been entered (and macros I have written) prior to the device independent versions work today with the Documentor's Workbench version. I have a small library (~10 Mb) of items that I and others have written I keep dragging from job to job as references. If I go elsewhere, I think I would still want to continue to use these and continue to pass then to friends and collegues without having to worry if they will work. Until these changes, there has been no problems. Now I worry about the future. I am not opposed to change (hey, I went from v7 to 4.2bsd!) but upward compatibility should be kept. I use, for example, the v7->4bsd->...->4.3bsd path. Personal tools I wrote under v7 (that have not been replaced by bsd programs) compile and work UNCHANGED! When I started working where I am, I dumpped my tape of goodies on a Sun (4.2bsd-based) and they compiled and worked with no problems. And I have never had to edit these programs because of incompatibilities (just to add features). Now try to take your v7 program that uses ioctl calls, curses from 4.1bsd, or shell scripts that expect certain programs to behave in a certain way (see pr as an example) and try to use them unaltered on System V and watch your house of cards fall in! Now let's turn the tables: will the documents I typed in 6-10 years ago still be able to be typeset 2-3 years, even 5 years from now? Someone brought up the directory differences starting with 4.1C. OK, I concede this point, but since 4.1C what else has changed that would prevent a v7 program from compiling under 4.[23]? How many additional changes are planned for troff? If *this* is the only change that will make my old documents incompatible with new versions, fine! A simple sed command as a filter to the programs is all right with me. Beyond that simple sed command makes me worry a bit. I do not know what is in store concening publishing/documentation software from SoftQuad and/or AT&T. But because AT&T is involved (isn't SoftQuad doing this on an agreement with AT&T?) I worry that this software will diverge away from its current form as System III diverged from Version 7! And THAT is why I am objecting. Questions, comments, and complaints are welcome in my asbestos-lined email box. :-) -- scott barman {gatech, emory}!dtscp1!scott
scott@dtscp1.UUCP (Scott Barman) (06/15/89)
In article <24@nx32s.anduk.co.uk> lee@nx32s.UUCP (0000-Liam R. Quin) writes: >>PLEASE STOP TRYING TO BREAK OUR *MEGABYTES* OF DOCUMENTATION!!! >No-one is doing this. You can stop shouting now [0.5 :-)]. >If you still need convincing, though, send me some mail! > >>*AND* we (read: me, >>the part-time sys admin., full time programmer) do not want to maintain >>N versions of troff! I did it once and it was not fun or easy! >No-one seems to be about to force you to use GNU troff. If you prefer >to walk, walk. We'll take the `plane. [:-) :-) :-)] Before I go on, these changes are effective in the product by SoftQuad Publishing as well (long names). I know I do not have to use gnu, but able toa of agreements that I understand exist (and I am sure I will hear about it if not true), there is a distinct possibility that I will be using these changes on future System V releases (through whatever botched up licensing procedures they have now). OK, I've received a number of email inquiries and a number of public comments that in effect say, "why in the #$%^& are you opposed to this?" So to satisfy some of you, I present for the net my *humble* opinion. Fundamentally, I am not opposed to any change that would improve not only the use, but performance of troff. I think long names are an interesting concept, but is a relativly minor issue compared to s tri.ailites it does not have. Some of what I have seen that has been accomplished in what sounds like a re-write by SoftQuad Publishing sounds interesting and one day I will get it together and take a closer look at it. However (and you knew a "weyor" was due about now), I worry about what would happen to upward compatibility if one change is "allowed" to be entered in to stop that smooth transision. Until this change, documents that have been entered (and macros I have writt: 4iprior to the device independent versions work today with the Documentor's Workbench version. I have a small library (~10 Mb) of items that I and others have written I keep dragging from job to job as references. If I go elsewhere, I think I would still want to continue to use these and continue to pass then to friends and collegues without having to worry if they will work. Until these changes, there has been no problems. Now I worry about the future. I am not opposed to change (hey, I went from v7 to 4.2bsd!) but upward compatibility should be kept. I use, for example, the v7->4bsd->...->4.3bsd path. Personal tools I wrote under v7 (that have not been replaced by bsd programs) compile and work UNCHANGED! When I started working where I am, I dumpped my tape of goodies on a Sun (4.2bsd-based)iand they compiled and worked with no problems. And I have never had to edit these programs because of incompatibilities (just to add features). Now try to take your v7 program that uses ioctl calls, curses from 4.1bsd, or shell scripts that expect certain programs to behave in a certain way (see pr as an example) and try to use them unaltered on System V and watch your house of cards fall in! Now let's turn the tables: will the documents I typed in 6-10 years ago still be able to es Suepeset 2-3 years, even 5 years from now? Someone brought up the directory differences starting with 4.1C. OK, I concede this point, but since 4.1C what else has changed that would prevent a v7 program from compiling under 4.[23]? How many additional changes are planned for troff? If *this* is the only change that will make my old documents incompatible with new versions, fine! A simple sed command as a filter to the programs is all right with me. Beyond that simple sed command makes me worry a bit. I do not know what is in store concening publishing/documentation software from SoftQuad and/or AT&T. But able toa AT&T is involved (isn't SoftQuad doing this on an agreement with AT&T?) I worry that this software will diverge away from its current form as System III diverged from Version 7! And THAT is why I am objecting. Questions, comments, and complaints are welcome in my asbestos-lined email box. :-) -- scott barman {gatech, emory}!dtscp1!scott #