[syslinux] isohybrid has 2 variants

dave madsen
Tue, 24 Jun 2014 19:23:26 -0000

> > When
> > information is too-technical, or the wording sounds too-technical,
> > most users won't even read it.

Although a "list lurker", I'd like to make a brief comment
(stating the
obvious).

Documentation will have different audiences, ranging from [sometimes
not-clueful] end-users to people trying to make distros bootable under
different conditions, to those who may want to learn enough background to
contribute to the project in some way.

Each will complain differently when they use the Wiki, not only because the
information they're looking for is different, but because the background
each brings with them is different.

I believe that reorganization of the documentation keeping this in mind
would be the "best" solution, rather than debating what to leave in or
cut
out.  There have been multiple times I've been interested in a piece of
software and wanted to find out its history so I could orient myself, and
some "helpful" soul had decided that all the old stuff was unnecessary
and
deleted it.  Conversations with long-time developers (when I could find
any) were required to learn things.  It wastes time and is painful for
everyone.

(No, I'm not volunteering -- I knew you were gonna ask.  I don't know
enough to be able to make good decisions, someone would have to review and
clean up after me.)

Please don't delete "old" or "useless" stuff.  It *will*
be useful to
*someone*.

Also, If I'm trying to learn more about booting, it makes sense to dig into
this project.  If you delete technical information that I need to know,
could I Google for it?  Sure -- but it would be a lot easier if the
information were already here.  It's a fine line between deciding what
information should be included in the docs here and what should be searched
for.  But remember that searching isn't free in cost of the user's time.
 If you delete information, at least insert a link to the information
elsewhere on the web (even knowing the link might go stale or missing).

As far as marking software frozen, I would suggest that "frozen" is a
value
judgement:  if I want to work on it, then it's not frozen anymore, right?
 If it's felt that it's deprecated or superseded for some reason, the
software should be annotated as such, together with the reason(s) why and
what would be required to make it up-to-date (if possible).  If I'm then
attracted to use it or (God forbid!) work on it :-), then I would know what
I'm getting into and be able to intelligently decide if it's worth it
and
how I might be hurt in the process.

Sorry to interrupt your conversation.  "Now back to our regularly scheduled
programming".  Thanks for reading.