Garrett D'Amore wrote: > Alan Coopersmith wrote: > > Garrett D'Amore wrote: > >> 1) The commands increase the size of the text segment. Not only does > >> it add new parsing requirements (you have to at least have enough code > >> to handle --man, for example), but you also have the text of the man > >> pages themselves. While you might like to maintain the fiction that > >> this comes for free, it *is* a fiction. Run sum --man or some of the > >> other commands and you'll see content that was not automatically generated. > > > > The minimum memory requirement for the release this is integrating into > > is 512Mb. A few k of memory, in a shared library that can be shared > > amongst > > all processes using it, is far down in the noise. > > This attitude, spread across dozens, or hundreds of projects, is part of > the reason why software still struggles even in the face of Moore's > law. Nobody cares about a few kB, but those kB add up in aggregate.
Actually I _do_ care. That's why we came up with the AST-based busybox design - to save memory and disk space _and_ make the commands faster at the same time. The whole stuff should fully scale from 8MB ARM-based machines upto SF25k class machines > >> 2) We also have traditional manual pages. On a normal system, the > >> default installation will include now *two* copies of the manual page. > >> This is wasted space. > > > > We also install commands users never use, drivers for hardware they don't > > have (and could possibly never have), sample audio files they'll never > > listen to, etc. Text that helps them use a command is far more useful > > than any of those. > > Yes, but *two* copies of the text? And in many cases those drivers > *can* be easily removed, as can the audio files. They are > uninstallable. (In fact, I recently pushed a change to delete a 300k > audio file that nobody listens to anymore. The remaining audio files > are much smaller, and *may* be used by various applications or user > configs.) Did you actually notice my comment that it in the mid-term (not long-term but not for the next putback) we may simple generate both the normal manual pages and the getopts strings put into libcmd/libshell/libbusybox from a DocBook/XML master file ? That was actually my "truce offer" (e.g. let this case pass as-is and then let me work in _peace_ on the DocBook/XML--->getopts XSLT stylesheet stuff (as already said this puts a huge strain on my resources but I would be willing to push this as a priority project)) ... and I'm very very unhappy that this was completely ignored and moved forward and de-railed the case (which will now likely lead to a wishdrawl of the case) ... > >> 3) Worse, the pages can be out of synch with each other. (The sum man > >> pages are again a good example of this.) Which is correct? (*Probably* > >> the --man command output.) > > > > This documentation is less likely to be out of sync with the implementation > > than the traditional man page. That's an improvement to the architecture, > > making sure the user always has at least a correct, if less detailed, source > > of documentation of the options. It will also always document the version > > the user is using - I've seen far too many questions on OpenSolaris e-mail > > and IRC from users confused because their PATH & MANPATH don't match and > > they're seeing /usr/gnu man pages but running /usr/bin commands, or vice > > versa. > > I agree that this is likely to be an improvement (although it turns out > that the documentation in the command still has to be maintained.) Does > that mean we abandon traditional man pages? No, that was _never_ intended. The idea was simply to re-use some of the information which is already present in the "getopts" string and format it a bit like a ASCII rendering of a man page (I'm still stunned that we have so many emails about this). > >> 4) Furthermore, the --man output doesn't reflect standards required for > >> Sun man pages. For example, there is no > >> ATTRIBUTES table. > > > > That's a good reason why there should also be a traditional man page, and > > --man shouldn't replace it, just supplement it. > > Your response here conflicts with your response to point #3 above. > Either we have one canonical copy of the documentation that should > always be correct and maintained, or we risk having the two copies get > out of sync or become inaccurate. Which should it be? The out-of-sync can never be avoided since this stuff is done in two seperate departments within Sun. The the man-like ASCII rendering and the output for "--help" is obviously _always_ in sync because it uses exactly the same information as the |getopts()| function uses for the actual parsing but we have two "safeguards" in place to make sure that the real manual page is updated (the current large lag was caused by the lay-off of April Chin and the resulting havoc). > >> 5) Some users elect to *remove* manual pages (or not install them) to > >> save space. We've long offered this choice. However, putting the man > >> pages in the binary effectively removes this choice from the user. > > > > That choice was added when we shipped workstations with 105Mb hard disks. > > That choice makes no sense on today's computers and decreases system > > usability. Many of the install options added for 105Mb hard disks will > > be gone in the installer for the Solaris release this integrates to, since > > they make no sense in the day of 1Tb hard disks costing $100, and even > > embedded systems, like the cell phone in my pocket, having many times the > > disk space of that 105Mb SPARCstation 1. > > > > I seem to recall we are also struggling to find room on the LiveCD. You realise that the new code actually _saves_ space on the LiveCD ? > Space constraints are *not* a thing of the past. Right... on the other side an ISO9660 CDROM has (J?rg may correct me) a block size of 2048 bytes and that's much longer than the largest builtin strings we pass to |getopts()| > This attitude -- memory is cheap so it doesn't matter -- is why systems > that should be fully capable of performing the same basic tasks we did 5 > years ago, are now no longer able to boot an operating system even > though the end user is really just interested in doing the same basic task. I agree with you. However this is only a disk footprint concern - the strings are in read-only memory, shared between processes (unlike the current versions of the utilities who do _not_ share their strings) and are paged-in on demand like normal code. This is a _huge_ improvement over the _current_ situation. > Yes, I believe in tight code. Yes I believe memory should still be > treated as a precious resource. No, I don't think it is unreasonable to > ask to be able to use an operating system with 128 MB of RAM. I agree. And the current code works on an 8MB ARM-based embedded system. > As far as I'm concerned, this "fight" is the "good fight", and I'll > stand my ground on it. I may well be overruled, but I refused to just > take the easy and lazy path of considering system resources an > infinitely wasteable resource. Technically I agree with you that the resources should be saved as much as possible. But.... we're doing exactly that with our work and now get punished for it. [snip] > > Translators don't have to translate every string in the application. > > Since when? I thought that pretty much every human interaction had to > be l10n'd in order to be qualified as localized. This is the first time > I've heard of "partially" localizing an application. Are there any > other precedents for this? Yes, AFAIK many of the applications shipped with Solaris use "sparse catalogs" or simply none (because there is no funding or the funding only covered the application's main windows but not a far-away option window hiddent behind lots of menu items). Please ask in i18n-discuss at opensolaris.org ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;)
