About the future format for LFS (reworded)

[Ken Moffat]

On Mon, Sep 01, 2008 at 01:57:10PM -0400, William Immendorf wrote:
> 
> 
> Bruce Dubbs wrote:
> 
> >> the biggest
> >> barrier I think we have, is the fact that xmllint and xsltproc couldn't
> >> handle RNG documents correctly.  
> 
> >To me this is a show stopper.  We need those or the equivalent programs to 
> >generate the book in its various forms, wget-list, etc.
> 
> Then try both Saxon and Sun MSV (Multi-Schema XML Validator). However, they need Java, so be preapred for that.
> 

 So far, I've managed without java, and I see absolutely zero reason
to install it on my machines.

 At the moment, you haven't bothered to reply to my questions and
comments.  I have noted that the dynamic book will be able to provide
different package managers for different users, but I'm still in the
"I came here because I loathe the overhead of package managers" camp.

  That still leaves the majority of my post unanswered.  To paraphrase
(bearing in mind that I mostly ignored the noise about package
management and dynamic books earlier this year, waiting for something
that was in a fit state to comment on):

 Who the hell are you to say "this is the way forward" without
providing argued reasons ?  (Valid answers might include "Gerard's
nominee", or perhaps you have some existing position in the LFS
projects of which I'm unaware.)  If you merely intend to _propose_ a
change, you _have_to_ provide better justification for it.

 What changes does it mean for individual editors ?

 Why is adding packages such as php to the LFS webserver (when we
appear to be extremely slow to update for known vulnerabilities) a
good idea ?
> >> After spending all this effort, just to get us to the same state as we're in
> >> currently (i.e. can validate and render the book sources), what, definitively
> >> do we gain?
> 
> >I asked this question yesterday too.  Until that is answered satisfactorily, I 
> >don't think the current build method will be changed.  As of right now, I just 
> >don't see any significant benefit, but a lot of effort.
> 
> The advantage is that we can create elements that we want. Rember, XML is eXtendible. Like a code element that replases the tired old screen and userinput combo.
> We can also remove useless elements. 

 So, how does that help ?  When I've made edits, I've never felt the
need for an element that isn't available.  Certainly, I often think
there are too many elements, but that is because some of the people
here care more deeply than I do about some of the nuances of how the
book is rendered - so, the elements I think are not particularly
important are indeed useful and ought to be retained.

 You refer to the "tired old screen and userinput combo" - where is
the problem with it ?  Maybe you are caught up in the "web 2.0"
buzzphrases ?

 At the moment, I don't have a killfile.  People _discussing_ the
development of the book have a right to be heard, even if I dislike
what they say.  But you apparently come out of nowhere with a
statement of "Что делать"(1) and no explanations of why you think
this will improve  anything.  You are trying my patience.

ĸen

1. - the original title, in Russian of "What Is To Be Done ?" by
Lenin - at least according to wikipedia - I've dropped the question
mark because you aren't asking, you are proclaiming.
-- 
das eine Mal als Tragödie, das andere Mal als Farce