On Mon, Jan 27, at 01:11 Αγαθοκλής wrote: > Hi Akira, > > On Mon, Jan 20, at 06:27 Akira Urushibata via lfs-dev wrote: > > I will talk about LFS on January 25th (Japan time, Saturday) in an > > open source event at Osaka. > > I'm sure everything went well, and hopefully you will send us some details > about the event. > > > There are a many topics to cover. I find it unfortunate that there > > is not enough time to discuss kernel compilation in detail. > > > > As I stated in an earlier post, a major shortcoming in the LFS Book > > is that it says nothing about project management. Building LFS is a > > significant project and without basic management skills, one is not > > likely to succeed. > > The main purpose for the book is to demystify and document the workings > of an Operating System, and possible through away any fears, which quite > logically exist. It covers this basic need for a human being that wants > to know and understand. > > Building an OS it is a composition of individual components of gluing them > together to produce an homogeneous usefull system, lets say like building > a house (borrowing Xi's Ruoyao phrase in another thread), where the foundation > is the kernel so rather important!, though the bricks share equally the same > importance. > > The nice thing about all this, is how one component need the others and how > a component can use others too to extend itself. If something is quite that > important to understand from this monotony ./configure is that that you can > activate or deactivate this extensibility, with the usual configure options, > --enable-*, --with-*, --disable-*, --without-*. This is the most fascinating > thing in all this procedure if you ask me, though at the same time can be a > headache, but both BOOKS are trying hard to document those dependencies and > relationships. > > Now, if someone, wants either to have her/his own OS, or wants to build a new > bright OS with some bright ideas, then of course needs to find a way to script > the building, because somehow in time at the very least, it will need to > rebuild > a package, lets say for a security related thing (the BLFS book speaks about > this > stuff and points to usefull sources btw).
> It was discussed in the past to enforce a way with some kind of a package > managment, > by lets say using DESTDIR in the building instructions. My opinion is that PM > is > also an essential thing to master and understand, especially with regards to > dependencies. As an updated package can be a dependency of other packages so > it > would be wise to rebuild this specific chain, so every package can benefit > from > the update. So what is this crucial information, that it has to be recorded > for > a package is: - to which package[s] i depend on - to which package[s] i'm a dependency this is twofold as if there is an sense of "someone needs me" also and "i need some others too", so this makes an environment (hopefully reasonable). This work belongs to a supervisor of the environment. The package manager is the one that branch that does, lets say "the actual/dirty work" (which is quite quite pleasant and fun (if you ask me), as i dit it twice, first in sh and then in vimL (which was a really nice, kinda of a reproduction of a system: with just one shot (though i didn't do the extra verification through step, which i know Κεν did it iirc (quite possible as there is a such recording in the memory, which i think i tried it once, but i guess myself belongs to a waterfall model type, as it conserns verification stuff)). Have a peacefull night, but special regards to the beloved people in Japan (i plead gilty for admiring your spirit and this exceptional style to express :-) - i see the Run again (maybe 10 times more), but where i really really plead gilty, is for your Kobayashi - which still imho, there haven't developed things to at least "mimic" his techniques). Bye, ag -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
