Future of LFS

Jeremy Huntwork jhuntwork at linuxfromscratch.org
Sun May 18 13:49:41 PDT 2008

Gerard Beekmans wrote:
> For us to be able to use an online tool to write the book, that tool 
> needs to support every kind of tag we'd use for book editing; including 
> tags like <sectx>, <itemizedlist>/<listitem>, all the structures 
> surrounding chapter setup, entities, section info tags, the sometimes 
> tricky internal XML links, and the list goes on for a while.

I understand. However, many of our current tags, and our current 
structure, can be simplified or improved, I believe. But yes, what you 
see in the POC is only a handful of what would need to be supported.

> I'm afraid that in the end an online tool gives a user buttons/links to 
> click on that insert the proper start and end tags. After doing it a few 
> times, you may as well type them out. If one is a reasonable fast typer, 
> it is faster to type out the start and close tags as you type the rest 
> of your sentence of paragraph (compared to grabbing the mouse, find the 
> button, click on it, then click somewhere in the text edit field to 
> start typing between the just inserted tags).

Not necessarily, but that comes down to user preference. Of course, with 
a new format, an editor should still be able to edit manually with vim, 
if he desires. One advantage to having a gui with buttons and controls 
that generate tags is that it helps to reduce tag typos and validation 
errors. (As an aside, I don't know if you tried it, but I believe my POC 
will show you if there is an error validating the document when you hit 

> This may be a bit exaggerated (though often it's simply the truth) but 
> the point is, I've never been convinced a WYSIWYG (what you see is what 
> you get) editor is the right tool for us.

It may not be the right tool for _you_. :) But it may very well be the 
right tool for someone else, and make it easier for new contributors to 
add changes to the book.

> On the other hand, it would be nice to be able to see the formatted page 
> as you're typing without having to render it every time a change is made 
> and then having to open it in another program (ie: web browser).

Yes, that was another advantage.

> Rather than re-invent the wheel, would a program like BlueFish be a 
> possible candidate? I haven't used this program in over half a decade 
> but I hear it supports XML. It may be a possible alternative to at least 
> look into before deciding on a custom "in-house" application.

Sure, you could look. Often, though, I feel it is just as much work to 
get full-featured applications such as BlueFish to work with a custom 
setup as it is to write our own simple app.

Even so, the code-editing aspect was just one portion of the POC. Part 
of the main focus of the POC is still to allow custom, dynamic 
renderings of the book.

> Also keep the following in mind: we don't need to necessarily change the 
> XML structure to make it easier for other people to contribute.

I respectfully disagree. Our current XML syntax isn't the easiest to 
work with and it doesn't do all we would like to do (such as define PM 
type). I'm glad you mentioned 'itemizedlist' and 'listitem'. Those are 
two of my least favorite tags, partly because they are so long and 
unwieldly. Another is the whole <screen><userinput> combination.

> In fact, anybody can contribute textual changes. That doesn't mean we 
> need or even want people to submit XML code. Editors should review all 
> submissions and edit for content, correctness, style, grammer, etc. The 
> last thing we want is to copy and paste contributed XML into the book.

I agree with the desire to keep the book 'pristine', correct and 
reliable. On the other hand, I think being too restrictive keeps us with 
a low active editor count and a high workload. I think we need to find a 
way to open up more opportunities for contribution while keeping the 
quality of the book intact.

> Before long, the book will develop an inconsistent format because 
> everybody has a different style of writing, or English isn't their first 
> language. In the end we want a book that has a professional feel to itt 
> with one style of writing that is consistent throughout.

Wikipedia. There is an example of an online resource that in theory 
shouldn't work, but in practice actually accomplishes something worthy 
of note. How do they manage to allow Everyday Joe to edit their book and 
yet keep a fairly reliable and quality resource? Because they have 
guidelines and a community that helps keep those guidelines in place.

I'm not saying that we should do exactly as Wikipedia does, but I don't 
opening up the book will produce as much of a nightmare as you think.

Let's say we have the task of adding a new section to the book. If one 
person who doesn't have the right writing style or expertise in English 
draws it up and is able to convey the right ideas, they've done 80-90% 
of the work. Others, perhaps with less time on their hands, can now 
tweak up the text or fix minor technical issues. The point is that the 
book has now moved forward, instead of stalling while waiting for 
someone 'approved' to have the time to write it up or make changes.

> That is near impossible to accomplish unless only a handful of people 
> actually update the text - those people will have worked together for a 
> while and know the right styles to use while writing. And they can be 
> the XML experts and translate a contribution into the proper XML format 
> used by us.

This is exactly what we have been doing up to now. And it doesn't 
address the issue that I raised, namely, we need to get more people 
interested and willing to contribute.


More information about the lfs-dev mailing list