On 7/25/09, Garrett D'Amore <gdamore at sun.com> 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.
>
>
> >
> >
> > > 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.
This is not wasted space. The string is used for parsing the
arguments. You would see that if you'd ever took a look at the *code*.
> > >
> > >
> >
> > 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.)
>
>
> >
> >
> > > 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.)
Garrett, would you take a look at the implementation, please? It would
answer your question.
> Does
> that mean we abandon traditional man pages?
>
>
> >
> >
> > > 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?
>
>
> >
> >
> > > 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. Space
> constraints are *not* a thing of the past.
>
> 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.
>
> 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.
>
> 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.
I think a couple of people who work on the project will consider your
comments as *offense*. Much time was spend in *reducing* memory usage
and the commands which are used as replacements are tuned for
*embedded* environments, i.e. low memory usage and low footprint. This
was always the goal and will be the goal for the Opensolaris busybox
project.
Chris
(who feels offended)
--
^---^
(@)v(@) Chris Pickett
| / IT consultant
===m==m=== pkchris at users.sourceforge.net
