Mailing List ArchiveSupport open source code!
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]Re: GNU-Linux vs Linux naming [was RE: LAM/MPI Parallel processing]
- To: tlug@example.com
- Subject: Re: GNU-Linux vs Linux naming [was RE: LAM/MPI Parallel processing]
- From: "Stephen J. Turnbull" <turnbull@example.com>
- Date: Fri, 8 Sep 2000 11:42:24 +0900 (JST)
- Content-Transfer-Encoding: 7bit
- Content-Type: text/plain; charset=us-ascii
- In-Reply-To: <20000907131838.A2791@example.com>
- References: <FOEBIKDLMFBGOKGGBGDEAENPCEAA.jshore@example.com><m2u2bu84tz.fsf@example.com><20000906100813.A15622@example.com><m2n1hk6hfx.fsf@example.com><14775.4589.886336.421908@example.com><20000907105314.A27774@example.com><14775.29695.536967.913439@example.com><20000907131838.A2791@example.com>
- Reply-To: tlug@example.com
- Resent-From: tlug@example.com
- Resent-Message-ID: <OcdVhB.A.GeF.pSFu5@example.com>
- Resent-Sender: tlug-request@example.com
>>>>> "Simon" == Simon Cozens <simon@example.com> writes: Simon> So what's this: Implicit in --version being present, which is implicit in the fact that I knew what the version string said? >> but the "author" managed to put his name into the version >> string. Simon> To be honest, I did omit 46 lines of copyright info and Simon> version strings. Huh? That doesn't show up on my box! Oh, you mean in the _BSD sources_, not in the output of GNU `sync --help'! :-P Simon> But on average, BSD binaries appear to be half the size of Simon> GNU equivalents. You mean I could get my XEmacs down from 10MB to 5? :-) On my Linux/glibc/gcc 2.95.2 system, your version of sync is 4803 bytes, 3040 stripped. How big is it on a BSD? The Debian/GNU version is 9340 stripped, of which 660 is string data. GNU sync also includes a reference to "write error", which confuses me since I thought sync(2) always succeeds (or hangs). One thing that evidently takes up a lot of space in that binary is localization code (setlocale, gettext, and friends). You sure aren't going to catch me admitting that is wasted space!! (In syscall wrappers that can't error, OK. How many of those are there?) Here's what I think sync.c should look like. /* GNU sync - flush buffered filesystem info to disk ... short copyright notice goes here; if you must have a long one, put it at the end ...[1] */ #define __GNU_POLITICALLY_CORRECT__ #include <gnu_policy.h> #ifdef __GNU_POLITICALLY_CORRECT__ /* [2] */ static struct gnu_required_options sync_options = { /* Copyright */ "Copyright (C) 2000 Free Software Foundation, Inc.", /* Version [3] */ "$Id$", /* Usage [4] */ "Usage: %s %s", /* Help [5] */ "Usage: %s [GNU documentation option]\n\ System call wrapper: forces changed blocks to disk, updates the super block.\n\ \n\ Version: %s\n\ \n\ For GNU documentation options, see the manual for gnu_process_options.\n\ \n\ Report bugs to <bug-fileutils@example.com>.\n" }; #else /* Minimal version described in [2] goes here */ #endif #include <unistd.h> int main (int argc, char *argv[]) { /* [6] */ gnu_policy_initialize_locale (); gnu_policy_process_required (&argc, argv, sync_options); sync (); exit (0); } /* ------------------------------------------------------------------ */ ... Long copyright, if any, goes here. AFAICT _moving_ the copyright material does NOT violate the GPL. /* ------------------------------------------------------------------ */ [1] *No* description, theory of operation, etc. goes here. Nor in the end material. Toplevel description in help string, lower level algorithms etc in comments to functions implementing them. [2] There's gotta be a better way than a preprocessor conditional to prevent inclusion of (possibly very long) help strings. Distribution of binaries created with __GNU_POLITICALLY_CORRECT__ undefined would violate GPL; there should be a minimal version to satisfy GPL. Actually, this struct should be in some standard format (there's an options processing library) for autogenerating usage and help. [3] Use RCS key to tweak RMS. [4] The usage string is cryptic because libgnuoptions will fill in name (from argv[0]) and the list of required documentation options. But see [2]. [5] Actually this is a fallback. Should be autogenerated (see [2]). [6] gnu_policy_process_required is a macro defined in gnu_policy.h, defined to nothing if __GNU_POLITICALLY_CORRECT__ is not defined. When it produces output, it automatically prefixes the copyright string. Requires linking to libgnupoliticallycorrect.a. gnu_policy_initialize_locale is similar, with the obvious function. In order for this to make sense as generic policy, there would have to be helper functions to accomplish locale setup and options processing more flexibly. But for most small utilities, the above should be enough. Binaries would be a lot smaller since a lot of I18N boilerplate would end up in the libraries. Other options might be included; eg, --man might try to exec man, --info to exec info, etc. But instead I think that there ought to be a GNU_DOC_PRIORITY environment variable, naming different kinds of documentation browsers, and the library would try to invoke info, man, a web browser, whatever, trying different help browsers in order of the env variable. If that didn't exist or was empty or didn't make parse, the default would probably be info, man, fallback string. The library would have to check whether stdout was a tty, and if not use the fallback string for help, of course. (So as not to screw up zsh, eg.) Two other options that might be appropriate would be --about and --license. Both of these would look for appropriate files installed in a standard place. But all of this would be handled in libgnupoliticallycorrect.a. >> Still, sync is an extreme case. Programs should be >> self-documenting. (And not by reading source, either.) Simon> Self-documenting without reading the source? Hmm, are you Simon> advocating literate programming, or something like POD or Simon> Javadoc? What I meant by "self-documenting" was to the _user_. So I guess I'm talking about POD. Self-documenting to programmers without reading the source is an oxymoron. I think literate programming is a good idea, yes. Damn shame there's only one programmer in the world who can _write_, and he's too busy fingering his organ to finish ACP. :-) Simon> Look. I connect to Cable and Wireless. It doesn't get Simon> *much* worse. No, it doesn't. I shouldn't tease you. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."
- References:
- RE: GNU-Linux vs Linux naming [was RE: LAM/MPI Parallel processing]
- From: "Jonathan Shore" <jshore@example.com>
- Re: GNU-Linux vs Linux naming [was RE: LAM/MPI Parallel processing]
- From: SL Baur <steve@example.com>
- Re: GNU-Linux vs Linux naming [was RE: LAM/MPI Parallel processing]
- From: Simon Cozens <simon@example.com>
- Re: GNU-Linux vs Linux naming [was RE: LAM/MPI Parallel processing]
- From: SL Baur <steve@example.com>
- Re: GNU-Linux vs Linux naming [was RE: LAM/MPI Parallel processing]
- From: "Stephen J. Turnbull" <turnbull@example.com>
- Re: GNU-Linux vs Linux naming [was RE: LAM/MPI Parallel processing]
- From: Simon Cozens <simon@example.com>
- Re: GNU-Linux vs Linux naming [was RE: LAM/MPI Parallel processing]
- From: "Stephen J. Turnbull" <turnbull@example.com>
- Re: GNU-Linux vs Linux naming [was RE: LAM/MPI Parallel processing]
- From: Simon Cozens <simon@example.com>
Home | Main Index | Thread Index
- Prev by Date: Re: [shimpei@example.com: web maintenance tool for Linux]
- Next by Date: Re: help needed with emacs. mule, euc-japan
- Prev by thread: Re: GNU-Linux vs Linux naming [was RE: LAM/MPI Parallel processing]
- Next by thread: Re: GNU-Linux vs Linux naming [was RE: LAM/MPI Parallel processing]
- Index(es):
Home Page Mailing List Linux and Japan TLUG Members Links