Gerard Beekmans wrote:
> As everybody has their own ideas and wishes, you'll find the document is
> not comprehensive and complete by any means. That's where the
> discussions here come in, to make sure it *becomes* complete.
>
> Looking forward to reading you guys' comments.
I wanted to wait a
> You can view it here:
>
> http://lightcubesolutions.com/~jhuntwork/dLFS/
I realize it's a proof-of-concept, not a finished product. I would like
to point out a few things. I don't mean to be sounding negative or seem
to be against the idea.
For us to be able to use an online tool to write
> I wanted to wait a bit before commenting to see if anyone else would
> comment first. But perhaps the lack of comments is in part because
> people feel it has all been said already? Maybe it is time that we just
> pick a general direction based on the comments we've already received
> and start m
Jeremy Huntwork wrote:
> The basic idea is multi-part:
>
> 1) Continue to use XML as the source (because it is a standard for
> defining data and is easily parsed) _but_ to use, as much as possible,
> fewer and simpler tags.
>
> 2) PHP renders the pages based on a choice of PM or architect
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 , /, all the structures
> surrounding chapter setup, entities, section info tags, the sometimes
> tricky internal X
Gerard Beekmans wrote:
> Take a look at http://wiki.linuxfromscratch.org/lfs/wiki/LFSFuture
In some cases, the changes proposed only require general agreement of what to
do
and the accomplishment of the task would be relatively easy. In others, the
changes would be pervasive throughout the bo
Bruce Dubbs wrote:
> It seems that your idea is for a look and feel change along with a dynamic
> change of the book depending on the type if PM chosen by the user.
No, not really, sorry if it came across that way. The page layout was a
product of some other work I had been doing in unrelated (n
Julio Meca Hansen wrote:
> But can you explain a bit more what kind of data editing are you thinking
> about? I'm not sure
> if letting people edit the contents would be a wise idea, unless you were
> thinking in the people involved
> in LFS (I was kinda thinking ala wikipedia, edit for all)
In
> It may not be the right tool for _you_. :) But it may very well be the
As long as a GUI tool can produce the code we currently have (it may be
complex but that's in part due the syntax of DocBook) then it would be a
tool, definitely.
If the tool forces a simplification and lessening of tags
I'm just curious what the code looks like. It looks a LOT like a parser
I wrote working on a project with Jeremy almost a year ago. Link below.
Obviously the concept is the same. If it is the same base code, all I
ask is for attribution of the original idea, No more.
http://cross-lfs.org/~jciccone
Joe Ciccone wrote:
> I'm just curious what the code looks like. It looks a LOT like a parser
> I wrote working on a project with Jeremy almost a year ago. Link below.
> Obviously the concept is the same. If it is the same base code, all I
> ask is for attribution of the original idea, No more.
>
>
> This is still the most important aspect of the book. Adding more educational
Bruce, could you make a collection of the educational items you
mentioned. We should record this in a Trac ticket (or multiple tickets)
so we can find it again. I fear it will end up buried in this thread
otherwi
Jeremy Huntwork wrote:
> Joe Ciccone wrote:
>
>> I'm just curious what the code looks like. It looks a LOT like a parser
>> I wrote working on a project with Jeremy almost a year ago. Link below.
>> Obviously the concept is the same. If it is the same base code, all I
>> ask is for attribution o
> Bruce, could you make a collection of the educational items you
Never mind that. I'm working on it right now.
Gerard
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
This continues the emails Alexander sent a while back (March 5).
Alexander, am I correct in my assumption that you would consider RPM a
good choice and DEB a bad choice for LFS purposes.
Your emails made it sound (to me) that deb would be a lot harder to
implement, maintain and understand (config
Sorry to be so indecisive. Bruce, I was going to add your comments to
track tickets but realized more information is needed to make them
meaningful.
> elaboration of the meaning of what the configuration of packages mean
> with the emphasis on udev and the kernel.
Can you elaborate on that p
Gerard Beekmans wrote:
> > I would also like to add the boot scripts to the book as appendices
>
> Do you mean the source code of them as-is? I can see this become a bit
> of a hassle as the actual scripts are updated. We'd then have to
> remember to copy each change into the appendix as well
Bruce Dubbs wrote:
> Gerard Beekmans wrote:
>
>> > I would also like to add the boot scripts to the book as appendices
>>
>> Do you mean the source code of them as-is? I can see this become a bit
>> of a hassle as the actual scripts are updated. We'd then have to
>> remember to copy each change
Jeremy Huntwork wrote:
> 1) Continue to use XML as the source (because it is a standard for
> defining data and is easily parsed) _but_ to use, as much as possible,
> fewer and simpler tags.
This is not the only standard for defining textual data, and some people think
that XML is too verbos
> Do you want me to start on adding this to the book as Appendix D?
Can I see a finished renderring not quite part of SVN yet.
You mentioned you had to pre-process the scripts (ampersands,
greater-than symbols and the like). This'll of course need to be
automated as you also mentioned.
This wo
Alexander E. Patrakov wrote:
> Jeremy Huntwork wrote:
>
>> 1) Continue to use XML as the source (because it is a standard for
>> defining data and is easily parsed) _but_ to use, as much as possible,
>> fewer and simpler tags.
>
> This is not the only standard for defining textual data, and s
Gerard Beekmans wrote:
> This continues the emails Alexander sent a while back (March 5).
>
> Alexander, am I correct in my assumption that you would consider RPM a
> good choice and DEB a bad choice for LFS purposes.
Yes. Note that I have not evaluated pacman.
> Your emails made it sound (to me
Gerard Beekmans wrote:
>> Do you want me to start on adding this to the book as Appendix D?
>
> Can I see a finished renderring not quite part of SVN yet.
It will take a couple of days, but yes, I can do that.
> You mentioned you had to pre-process the scripts (ampersands,
> greater-than symbol
Bruce Dubbs wrote:
> The XML is used for generating the book in chunked and non-chunked versions,
> populating and verifying completeness of the patch directory, generating a
> wget
> list, generating pdf, and checking for the completeness of files on anduin.
>
> It is *much* more flexible than
> I'd do the automation in conjunction with the new appendix as that would make
> the development easier.
Great, looking forward to see what a finished product may look like.
I'd also like to put the following considerations forward.
Rather than pulling in the bootscripts into the book and docu
> Yes. Note that I have not evaluated pacman.
Do you by chance have any plans or desire to do so in the near future?
> What's even more important for educational purposes, Debian rules are
> incoherent
> between various Debian packages.
How does RPM differ in that regard? Couldn't RPM spec fil
Gerard Beekmans wrote:
>> Yes. Note that I have not evaluated pacman.
>
> Do you by chance have any plans or desire to do so in the near future?
Not in the nearest future--too busy with bureaucracy that surrounds presenting
the dissertation (scheduled for July, 3).
>> What's even more important
Gerard Beekmans wrote:
>> I'd do the automation in conjunction with the new appendix as that would
>> make
>> the development easier.
>
> Great, looking forward to see what a finished product may look like.
>
> I'd also like to put the following considerations forward.
>
> Rather than pulling
Alexander E. Patrakov wrote:
> Yes, that's the point, and you describe the purpose of the _current_ XML in
> the
> book precisely.
>
> The problem with Jeremy's approach is that his XML is different and
> unsuitable
> for PDF generation, and the rest of the tasks can be done with a simpler
>
Jeremy Huntwork wrote:
> It continues to amaze me... I show a Proof Of Concept as _potential_ for
> a direction that LFS could take, it's purpose being illustrative and to
> show potential. And yet, each time, it is judged solely by what is seen
> as if it is supposed to be a complete picture. I
On Sun, 18 May 2008 16:03:36 -0500, Bruce Dubbs wrote:
> Gerard Beekmans wrote:
>
>> Take a look at http://wiki.linuxfromscratch.org/lfs/wiki/LFSFuture
>
> In some cases, the changes proposed only require general agreement of
> what to do and the accomplishment of the task would be relatively ea
31 matches
Mail list logo
