kent@sparky.IMD.Sterling.COM (Kent Landfield) (05/26/91)
Its time to get serious about this. I *need* your input. Please jump in
with suggestions and ideas.
The Environment: auxilary header will be used in the comp.sources.misc
newsgroup in the very near future.
Why is this being added ?
I have been shown that in a newsgroup not restricted to one type of
operating system, one type of machine or one type of architecture that
there is a need for this type of information in the header. The intent
is to provide you more external information about the package contained
within the posting. This allows you to determine if the package has
special requirements that may prevent you from using it. It is extremely
irritating to take the time to unpack something just to find out that you
can't use it.
The Environment: auxiliary header is currently in use in comp.sources.games.
What follows is a description of the Environment: header as Bill has been
using it. It seems quite reasonable so... :-)
The Environment: auxiliary header line is used to allow the moderators
a way of giving the readership a quick indication of what resources are
required to use a particular issue.
Environment: syntax
Environment: Keyword [, keyword ..]
Environment: example
Environment: SunView, XView, X11R4, termcap
The keywords usage is case insensitive. I am extending Bill's usage
by adding a NOT indicator (e.g. !AIX) so that I can specify that a
package runs on everything "but" the specified keyword.
Now here is the part where I need your help...
1. When should the Environment: header be used ? Always or just when the
moderator is alerted to a limiting condition ? Something in between ?
2. The environment information could get quite lengthy for some packages,
perl comes to mind... :-) Would it be acceptable to have more than
one line of Environment: headers if needed ?
3. A set of Keywords needs to be generated. The following list of keywords
is used only as a starting pont for discussion. *Much* help is needed
here. This was a quick and dirty list so suggest additions and changes...
Keyword Meaning
------- ----------------------------
Operating Systems:
UNIX - Will operate on any unix system... (right...)
SYSV - Will operate on any System 5.0 or greater system.
SYSV2 - Will operate on any System 5.2
SYSV4 - Will operate on any System 5.4
BSD - Will operate on any version of BSD
BSD42 - Will operate on BSD 4.2
BSD43 - Will operate on BSD 4.3
SUNOS - Will operate on Sun OS
SUNOS4.1 - Will operate on Sun OS 4.1
ULTRIX - Will operate on Ultrix
AIX - Will operate on AIX
VMS - Will operate on VMS
MSDOS - Will operate on MSDOS
XENIX - Will operate on Xenix
MINIX - Will operate on Minix
MACOS - Will operate on Macintosh OS
AMIGA - Will operate on AMIGA OS
COHERENT - Will operate on Mark Williams Coherent OS
OS/2 - Will operate on half an OS
Window Environments:
Curses - Uses the curses library
Termcap - Uses the termcap library
SunView - Uses Sunview windowing Facilities
X11 - Uses X Windows
X11R3 - Uses X Windows Release 11.3
X11R4 - Uses X Windows Release 11.4
XView - Uses XView toolkit
Motif - Uses Motif toolkit
XVT - Uses XVT toolkit
(There is a few more that go here... )
System/Language Support: (C is the default so not specified)
Dirent - Uses the dirent directory access routines
Sockets - Uses the network socket library
RPC - Remote Procedure Call facilities
ANSI-C - Requires ANSI C compiler
Turbo-C - Requires Turbo C
Pascal - Written in Pascal
Fortran - Written in Fortran
Perl - Written in Perl
Lisp - Written in Lisp
yacc - Requires yacc/bison
lex - Uses lex
MSGQ - Uses System V Message Queues
SHM - Uses System V Shared Memory
Shell Support: (sh is the default so not specified)
CSH - C Shell required
KSH - Korn Shell required
BASH - Bash Shell required
ZSH - Z Shell required
RC - Plan 9 Shell required
Hardware Support:
PC - IBM PC or compatible
VGA - VGA video support needed
EGA - EGA video support needed
Architecture: sparc, risc, vax .. ??
There are many things missing from this list... I am hoping we can
come up with good definition of how the Environment: header is to be
used and a set of keywords to use with it.
Your turn...
-Kent+
--
Kent Landfield INTERNET: kent@sparky.IMD.Sterling.COM
Sterling Software, IMD UUCP: uunet!sparky!kent
Phone: (402) 291-8300 FAX: (402) 291-4362
Please send comp.sources.misc-related mail to kent@uunet.uu.net.cmf851@anu.oz.au (Albert Langer) (05/26/91)
Kent, Thanks for organizing comp.sources.misc and for taking the trouble to improve it as with the Environment header. In response to your questions. 1. I think it should be used ALWAYS (or almost :-) 2. As many lines as it takes. (People who don't agree with 1 or 2 can set their newsreaders to show only header lines they want to see). 3. One classification I noticed missing was POSIX (unless that was meant to be the "works on all Unix" :-) Also there might be scope for including named software packages that the item requires even when they are not operating systems, shells or libraries. (e.g. various graphics packages use pbm). Perhaps a separate header line for Requires: to include any package name and version number without controls, while Environment: is restricted to a controlled thesaurus of keywords that are listed monthly. Finally I would suggest you get in touch the Library of Congress or some local research library and ask for advice about the methods used and proposed for cataloging computer software (or "computer data files"). There is also a mailing list PACS-L%UHUPVM1.bitnet@RICEVM1.RICE.EDU for a public access computer systems forum that would have relevant contacts, which published a paper on cataloging of online information resources and included the following address: Sally H McCallum, Chief Network Development and MARC Standards Office, LM 639 Library of Congress Washington DC 2050 smcc@seq1.loc.gov -- Opinions disclaimed (Authoritative answer from opinion server) Header reply address wrong. Use cmf851@csc2.anu.edu.au
wht@n4hgf.Mt-Park.GA.US (Warren Tucker) (05/26/91)
In article <1991May26.122801.4205@newshost.anu.edu.au> cmf851@anu.oz.au (Albert Langer) writes: >3. One classification I noticed missing was POSIX (unless that was >meant to be the "works on all Unix" :-) More like, works on some POSIX boxes (1/2 ;->). ------------------------------------------------------------------------ Warren Tucker, TuckerWare emory!n4hgf!wht or wht@n4hgf.Mt-Park.GA.US "An ANSI C elephant: just like the real one, but the position, shape and length of the trunk and tail are left to the vendor's discretion." -- me
andrew@calvin.doc.ca (Andrew Patrick) (05/27/91)
In article <1991May26.041741.22210@sparky.IMD.Sterling.COM> kent@sparky.IMD.Sterling.COM (Kent Landfield) writes: >Its time to get serious about this. I *need* your input. Please jump in >with suggestions and ideas. > >The Environment: auxilary header will be used in the comp.sources.misc >newsgroup in the very near future. ... I should point out that comp.sources.reviewed, the new kid on the block, will also be using an Environment Header. We would also like to see your ideas discussed here, and will try to ensure that the same scheme is used in CSR and CSM. -- Andrew Patrick, Ph.D. Department of Communications, Ottawa, CANADA andrew@calvin.doc.CA "The interface IS the program."
kent@sparky.IMD.Sterling.COM (Kent Landfield) (05/29/91)
In article <1991May26.122801.4205@newshost.anu.edu.au> cmf851@anu.oz.au (Albert Langer) writes: >Also there might be scope for including named software packages >that the item requires even when they are not operating systems, >shells or libraries. (e.g. various graphics packages use pbm). This was overlooked. Boy could the list of keywords grow long here... :-) A couple of people have said in email that making a small core list was the important starting point. The list of keywords would be expanded as needed. This approach makes sense to me. External named software packages would probably fit into the category of "on first encounter". >Perhaps a separate header line for Requires: to include any >package name and version number without controls, while >Environment: is restricted to a controlled thesaurus of keywords >that are listed monthly. This might be useful in comp.sources.reviewed but for comp.sources.misc, the Requires: would be placing a lot of up-front communication requirements on the authors and myself... I do agree that the keyword list will need to be made available on a timely basis, such as part of an INF posting at the beginning of a new volume. >Finally I would suggest you get in touch the Library of Congress >or some local research library and ask for advice about the >methods used and proposed for cataloging computer software >(or "computer data files"). There is also a mailing list >PACS-L%UHUPVM1.bitnet@RICEVM1.RICE.EDU for a public access >computer systems forum that would have relevant contacts, >which published a paper on cataloging of online information >resources and included the following address: > >Sally H McCallum, Chief >Network Development and MARC Standards Office, LM 639 >Library of Congress >Washington DC 2050 > >smcc@seq1.loc.gov Again, this might be overkill for comp.sources.misc (I could be wrong.. :-)) but the archivist in me will check it out... Thanks for the pointers... -Kent+ -- Kent Landfield INTERNET: kent@sparky.IMD.Sterling.COM Sterling Software, IMD UUCP: uunet!sparky!kent Phone: (402) 291-8300 FAX: (402) 291-4362 Please send comp.sources.misc-related mail to kent@uunet.uu.net.
barrett@Daisy.EE.UND.AC.ZA (Alan P Barrett) (05/30/91)
In article <1991May26.041741.22210@sparky.IMD.Sterling.COM>, kent@sparky.IMD.Sterling.COM (Kent Landfield) writes: The Environment: auxiliary header line is used to allow the moderators a way of giving the readership a quick indication of what resources are required to use a particular issue. Environment: syntax Environment: Keyword [, keyword ..] Environment: example Environment: SunView, XView, X11R4, termcap The keywords usage is case insensitive. I am extending Bill's usage by adding a NOT indicator (e.g. !AIX) so that I can specify that a package runs on everything "but" the specified keyword. Doesn't it really need a richer syntax, like arbitrarily complex boolean expressions? Environment: ((ThisOs & ThatOption) | OtherOS) & (ThisPackage | ThatPackage) --apb Alan Barrett, Dept. of Electronic Eng., Univ. of Natal, Durban, South Africa RFC822: barrett@ee.und.ac.za Bang: m2xenix!quagga!undeed!barrett
wirzeniu@klaava.Helsinki.FI (Lars Wirzenius) (05/30/91)
In article <1991May26.041741.22210@sparky.IMD.Sterling.COM> kent@sparky.IMD.Sterling.COM (Kent Landfield) writes: > Environment: syntax > Environment: Keyword [, keyword ..] I think that some version information should be included in cases where it matters. SVR3 vs SVR4, X11R3 vs X11R3 and MS-DOS3.0 vs MS-DOS4.0 are some examples. This could be done with version specific keywords, but I think this is a bad idea. Instead, the syntax for keywords might be extended with an optional '=version' part, for example MS-DOS=4.0, SYSV=R3, X=R3, BSD=4.3-tahoe. -- Lars Wirzenius wirzeniu@cc.helsinki.fi
net@opal.cs.tu-berlin.de (Oliver Laumann) (05/30/91)
wirzeniu@klaava.Helsinki.FI (Lars Wirzenius) writes: > > Environment: Keyword [, keyword ..] > > I think that some version information should be included in cases where > it matters. SVR3 vs SVR4, X11R3 vs X11R3 and MS-DOS3.0 vs MS-DOS4.0 are > some examples. This could be done with version specific keywords, but I > think this is a bad idea. Instead, the syntax for keywords might be > extended with an optional '=version' part, for example MS-DOS=4.0, > SYSV=R3, X=R3, BSD=4.3-tahoe. I find the whole idea of listing the required versions in a header of the news article absurd. Suppose I have a software package that runs under SunOS X, where X >= 3.4 and X <= 4.1.1, 4.[23] BSD, System V Release 3, Ultrix, HP-UX, and several others; it requires X11 Release 3 or X11 Release 4, OSF/Motif 1.0 or Motif 1.1, but Motif 1.1 only together with X11 Release 4, further OpenWindows 2.0 with HyperNeWS 1.4 or later (but optionally), and so on. So what exactly would I have to put in the `Environment:' header? The requirements on the environment are rarely so simple that they can be expressed in a single header line with only a handful of predefined symbols. -- Oliver Laumann, Technical University of Berlin, Germany. net@tub.cs.tu-berlin.de net@tub.UUCP ol@gnu.ai.mit.edu
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (06/03/91)
In article <3524@kraftbus.cs.tu-berlin.de> net@opal.cs.tu-berlin.de (Oliver Laumann) writes: > Suppose I have a software package that runs under SunOS X, where > X >= 3.4 and X <= 4.1.1, 4.[23] BSD, System V Release 3, Ultrix, HP-UX, > and several others; it requires X11 Release 3 or X11 Release 4, > OSF/Motif 1.0 or Motif 1.1, but Motif 1.1 only together with X11 > Release 4, further OpenWindows 2.0 with HyperNeWS 1.4 or later (but > optionally), and so on. I don't think the point of an Environment line is to express exactly which systems the package will run under. What's important is that it say where the package *won't* run, so that people avoid downloading the package if they won't be able to use it. So: Environment: !SunOS<3.4, !SVR<3, !(Motif 1.1 & X11R3), ?!UNIX Translation: Won't run under SunOS before 3.4, won't run under System V release 2, won't run under Motif 1.1 with X11R3, probably won't run under any non-UNIX systems. Similarly, pure-Sun packages would have Environment: !!SunOS. Packages for just Suns and SGIs would have Environment: !(!SunOS & !SGI). Most of my packages would have Environment: !(!BSD-derived). This won't necessarily provide full information. So what? What's important is that every bit of information added to an environment line lets some people know that they shouldn't bother with the package. Conversely, as the package is ported to more systems, the environment restrictions will slowly disappear. ---Dan
wirzeniu@klaava.Helsinki.FI (Lars Wirzenius) (06/03/91)
In article <3524@kraftbus.cs.tu-berlin.de> net@opal.cs.tu-berlin.de (Oliver Laumann) writes: >I find the whole idea of listing the required versions in a header of >the news article absurd. >[ an example of lots of required versions ] A good point. The version numbers shouldn't be specified except when they are 'really' required, for instance, when the software makes heavy use of a feature available only in one version of the OS. An example of this might be disk editors for MS-DOS that won't work with version 4.01. >The requirements on the environment are rarely so simple that they can >be expressed in a single header line with only a handful of predefined >symbols. On the other hand, it might be enough just to specify the environments in a 'grand scale' in the header line (and, presumably, the meticulous detail in the body the article, in the README or whatever) even in these 'radical' cases. A simpler syntax for the header line would mean less work for the moderator, and therefore (for comp.sources.misc) shorter turnaround time. Even a simple 'Environments:' would make it easier to skip programs that won't run in one's own environment. The more I think about it, the more agree with you that the version number idea isn't so good. -- Lars Wirzenius wirzeniu@cc.helsinki.fi
jfh@rpp386.cactus.org (John F Haugh II) (06/05/91)
In article <2088:Jun309:46:2191@kramden.acf.nyu.edu>, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > I don't think the point of an Environment line is to express exactly > which systems the package will run under. What's important is that it > say where the package *won't* run, so that people avoid downloading the > package if they won't be able to use it. So: > > Environment: !SunOS<3.4, !SVR<3, !(Motif 1.1 & X11R3), ?!UNIX The abundance of !'s in your examples lead me to believe that you've not thought about this very hard. This seems like an argument saying the primary arithimetic operation is subtraction, therefore we will always specify operations as subtractions, starting with 2 - (0 - 2) = 4. What is clear is that the Environment: header must =concisely= state what the environment is required to be (or not to be ...). That is, if BSD is straight out, the most concise expression would be Environment: !BSD Whereas if just about any POSIX compliant UNIX with BSD enhancements is likely to work, it would be Environment: POSIX && BSD not some obfuscated Environment: !(! POSIX || !BSD) > Similarly, pure-Sun packages would have Environment: !!SunOS. Packages > for just Suns and SGIs would have Environment: !(!SunOS & !SGI). Most of > my packages would have Environment: !(!BSD-derived). as the above cited example leads one to suspect it may become ... Remember, the goal is to be =human= readable, not =machine= readable. -- John F. Haugh II | Distribution to | UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 255-8251 | GEnie PROHIBITED :-) | Domain: jfh@rpp386.cactus.org "If liberals interpreted the 2nd Amendment the same way they interpret the rest of the Constitution, gun ownership would be mandatory."
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (06/12/91)
In article <19359@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: > In article <2088:Jun309:46:2191@kramden.acf.nyu.edu>, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > > I don't think the point of an Environment line is to express exactly > > which systems the package will run under. What's important is that it > > say where the package *won't* run, so that people avoid downloading the > > package if they won't be able to use it. So: > > Environment: !SunOS<3.4, !SVR<3, !(Motif 1.1 & X11R3), ?!UNIX > The abundance of !'s in your examples lead me to believe that you've > not thought about this very hard. You're right; in the three years I've been adding X-Context headers to my postings, I haven't thought one bit about the number of exclamation points. Since the real purpose of the line is to keep people from wasting effort on packages they won't get to use, it should be titled appropriately: Wont-Work-With: non-UNIX, SunOS<3.4, SVR<3, Motif 1.1 & X11R<4 That's about as simple as it can get for that set of requirements. > Whereas if just about any POSIX compliant UNIX with BSD enhancements > is likely to work, it would be > Environment: POSIX && BSD Again, the point of this line is for people (not your C compiler---what's this && stuff?) to avoid bothering with a package that they can't use. It should read like a set of danger signs: Wont-Work-With: non-POSIX, non-BSD The first danger sign you hit, you get off the road. ---Dan
jfh@rpp386.cactus.org (John F Haugh II) (06/12/91)
In article <20585:Jun1203:03:5491@kramden.acf.nyu.edu>, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > > Whereas if just about any POSIX compliant UNIX with BSD enhancements > > is likely to work, it would be > > Environment: POSIX && BSD > > Again, the point of this line is for people (not your C compiler---what's > this && stuff?) to avoid bothering with a package that they can't use. It > should read like a set of danger signs: Gee, I don't know Dan, What's the deal with the "!"s and "<", ">", and "="'s in yours? > Wont-Work-With: non-POSIX, non-BSD Which is the same as Works-With: POSIX Compliant BSD Systems. I won't try to make this argument using the linguistic point that many non-English languages have trouble with the English concept of negation, as it exists in English. That would be cheating, since it would point to a non-computer related reason that unneeded negation of the sense of the information is confusing. Instead I'll point out how silly a double negative looks in English, which before was how silly a double negative looked in computerese ... The set of environments that the software is likley to execute on is far smaller than the set of environment that it will execute on. [ There are simply too many weird environments, like "Won't run on an HP-41 handheld programmable calculator", to name every incompatible platform using non-negated language. That is, if it runs on UNIX and VMS, the set of other operating systems is best described as "not UNIX and not VMS", rather than "RT/11, RSTS, RSX, TENEX, TWENIX, ..." [ and those were just the popular DEC O/S's - ignore the popular IBM ones for the time being ... ] Since the set of all known operating system is quite large, your scheme practically requires that every specification be given as "not this system, not that system, not some other system", rather than just dragging all the not's out and getting rid of that "Wont-" at the beginning. Now it is "this system, that system, some other system". Which does, coincidentally, have the linguistic property of being simplier to understand. And it doesn't contain a single double negative either. [ Or in Dan-ese "Doesn't contain not none double negatives." ] -- John F. Haugh II | Distribution to | UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 255-8251 | GEnie PROHIBITED :-) | Domain: jfh@rpp386.cactus.org "If liberals interpreted the 2nd Amendment the same way they interpret the rest of the Constitution, gun ownership would be mandatory."
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (06/16/91)
In article <19379@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: > > Wont-Work-With: non-POSIX, non-BSD > Which is the same as > Works-With: POSIX Compliant BSD Systems. But I thought the idea was to have at least some semi-standard keywords, not a mishmash of ``compliant'' and ``system'' and so on created anew for each package. > The set of environments that the software is likley to execute on is > far smaller than the set of environment that it will execute on. That's not important. What's important is the size of the *description* of the set of unsupported environments. How about a compromise: Requires: POSIX & BSD-derived, or Interactive, or 3B2 But-Wont-Work-With: SunOS<4.0.3, Convex UNIX<8.0 (Note that we have to distinguish between BSD and BSD-derived.) ---Dan