On 28-04-2012 18:33, Bruce Dubbs wrote: > Fernando de Oliveira wrote: >
[...] >> I do not yet feel confident enough to replace my host by LFS. Did it in >> another machime (LFS6.7), but it was a PITA, regarding NVidea, Broadcom and >> VMware, worse yet when upgrading the kernel, NV and VM had to be taken into >> account and reconfigured (this is not the best word, hope you understand) of >> course more a problem of these than LFS/BLFS. But I will try to learn jhalfs >> (remember?) in some days maybe weeks, make a partition in the host for LFS >> and then I will be able to help more. > The nice thing about LFS is that you don't have to upgrade. I still use my > system built in 2005 every day. I did upgrade the kernel, but it is still > 2.6.22.5. There is no need to update just because a new version of something > is > released. I think you need some kind of missing capability or indicated > error > before updating. My problem is "paranoia": security. Perhaps I am wrong, but it is easier to keep upgrading than finding out which upgrades are security related. [...] >> My intention and goal is to eventually leave other distribuitions just to >> follow and see what is happening, and rely entirelly in LFS/BLFS even as >> host. >> >> So, please, do not give up. People like me would have much more difficulty to >> achieve such a goal (see above) if packages so important as xsane/sane keep >> being dropped from the book. > I looked at http://www.sane-project.org/sane-mfgs.html. There's a lot of > support for old hw, but I'm not sure about newer hw. I have not yet thought about that. See it later. > There's a couple of problems with keeping packages in the book. First is hw > compatibility. If we don't have the hw to test, then how can we reasonably > keep > it in the book? Understand that. In order to contribute a little further, as said yesterday, will soon build a "physical" LFS. As 4GB of RAM is available, have to learn how to build a pae kernel, in order for it to be 32bit. > Your problem, for instance, is complicated by the fact you are > using virtual hosts. Accessing hw in virtual hosts really is going beyond > the > scope of BLFS. Yes, I understand. Even have written it in a previous message (I know you remember, but in case other read this...). > The second problem is with limited use and old software. If a package is no > longer being updated and it doesn't build with newer libraries, how can we > reasonably keep it in the book? Although I agree with you, what an "old package" means has to be decided with care. If most distributions use that package and have success building it, I think we should not name it "dead". After a package is in the book, somebody can be using it, and I feel myself ethically involved and have to allow that user some time (one year or sixmonths?), before "banning" the package. > Another example. We have three mail servers in the book: sendmail, postfix, > and > exim. How many people really need any mail server? My system has: For this case, don't have an opinion, but your reasoning sounds good for me [...] > Everyone doing updates to BLFS in the last 6 months has been doing a great job Without any doubt! Thank you all very much (again, never too much repeating this). I have since day 1 liked LFS and then BLFS, but from sometime, six months or one year, it feels like everybody editing and contributing have developped a great new enthusiasm. > [...] > I am, of course, open to other ideas, but I just don't know how to handle > these > problems right now. You know more than you think! -- []s, Fernando -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
