Future format of the book
thekevinday at gmail.com
Thu Jun 5 07:23:21 PDT 2008
On Tue, Jun 3, 2008 at 9:08 PM, Robert Connolly
<robert at linuxfromscratch.org> wrote:
> Hello. Recently the lfs-dev mailing list seems to have decided to flip from
> xml to php, and to add rpm spec files for all packages so that a package
> manager can optionally be dropped in. Boot and Udev scripts have also been
> integrated into the book.
> I may have mentioned it before... I hate xml. It's nice to look at the html,
> it stores information well, but despite the generous help and maintenance
> from Manuel, I hate maintaining an xml book and I seriously doubt I will like
> php any better.
Applause for the "I hate xml", that makes me smile.
> I want to bring us back to 1969, with a plain text book. In a single tarball
> have the book, boot scripts, maybe patches too, separated by directories
> instead of links. Pages for packages can be written with #comments so they
> can be run as shell scripts to install packages. Each package has a
> directory, with it's patches (if any), grsecurity policy for the programs,
> and file lists for tripwire (and/or package manager).
> So the Inetutils package could have a chap6 directory like:
> chap6/inetutils/chap6-inetutils.txt (shell script)
> Or some variation of this. This is the most robust approach I see. It has what
> everyone needs, maybe not in the way they want it but in a way that's
> perfectly usable.
> A book like this would make me much much happier. It's easy to maintain, and
> practical. It's not very easy to read from an html browser, but maybe a
> simple index.html page could be done to keep things browsable, and easy on
> svn if a new package is added or if packages are moved around.
> The way I have been editing xml, with Vim, is extremely prone to errors. The
> pages are not usable, easily, as scripts. And adding more stuff like file
> lists will just make things worse. Xml is perfectly capable of handling all
> of this, but it's overkill and I'm more happy as a system developer than a
> book developer (I do not want to learn xml).
> I know a lot of people will not like a flip to plain text, and to be honest
> that doesn't bother me one bit. If anyone has a suggestion that doesn't
> involve me or other editors taking a six month course in web programing then
> I would like to hear it.
This sounds a lot like my installation script system I use for my own system.
In it's current state it is probably not exactly what you need, but
with enough hands it can be formed into exactly what you need.
I generally try to keep my personal & separate works out of this list,
but the bait you threw is just too tempting.
(considering how much of a deviant I am in the linux world..)
I have a working example of a complete build system based around pure
& simple text, with '#' comments:
And the file-format/text-format specifications that it follows:
It can be restructured pretty easily so that your particular
design/structure can be used.
> This idea is harder on book readers and users, and easier on editors, which is
> less efficient, but I think it's a fair compromise if extra hours are spent
> on systems development.
I see this as a fallacy because plain text can _very easily_ be
converted immediately before being visible to the user, via some
Take Windows for example, what a user see's rarely has anything to do
with what is going on.
Plain text can be converted to html on the fly into a webpage for them
to easily read.
In fact, the scripting system is run entirely off _very_ basic regular
expression commands via grep & awk
> I want to thank Manuel very very much for converting the original plain text
> book to xml/html, and for doing ongoing maintenance and changes, but I want
> to go back like it was originally. This has been bugging me for a long time.
> I'm curious to hear opinions about this. My mind is open.
If you have any more questions about my scripts, let me know.
More information about the hlfs-dev