M.Canales.es wrote: > El Martes, 31 de Octubre de 2006 22:52, George Makrydakis escribió: > >> With jhalfs being "the" tool for autobuilding LFS something alternative >> should not simply be an option but a much more versatile solution. And >> that, as you very well know, takes time - will aside. Some people could >> see this as competition for "the" tool, something it is not at all. > > I think that yuou know that we are thinking on changing how jhalfs is > coded to do it more versatile and cunstomizable via pluggable modules. > > Maybe several of your code and ideas could help creating such new code. >
Yes but based on what and why? I cannot but compliment you for the work you are doing so far, and i wish to stress that out. I would be very happy to discuss my view of things when I will be asked to and the setting allows it; I would really be honored. Thank you for the vote :). That said, I would not like to interfere with the _current_ state of affairs. Past comments have taught me enough regarding policies that should be followed in _this_ particular mailing list. Discussing things that are not in the _current_ jhalfs codebase will only bring forth irrelevant "point the obvious" attitudes that is best to completely avoid because of their high entropy. As a prelude, I would like to address you directly, knowing that you are the XSL/XML architect of the book so far. The book does require a new form to present the critical content and non critical content. It has required so for quite some time. If we are to assume that LFS is to be a distribution system of its own, then there is a definite need for overhauling and, at times, abrupt changes. I hardly think that it is the case to discuss them without a public production ready solution, both because of the average result expected from readers and "interpreters" of this mailing list. The use of the word overhauling (and even in gargantual doses) is the target of this paragraph. CLFS is the base and the example that represents the prototype for the n-level solution of this equation. BLFS is an ancillary problem once a more flexible and water fluid layout for CLFS is achieved. I stress the fact that CLFS is the major winner in what the LFS project has to offer to anyone because of the sheer power of the concept itself. I do think that what jhalfs has done, asides its obvious goal, is to challenge the fate of lfs itself. I also think that any automation system should not just "build" the thing. It should make you build it with something more than "optimization" or "package manager support". It should be tighted deeply into even how the system handles its self - hosting character and internal structure and dependencies, and more... _much_ more that only lfs - derived can achieve by a versatile automation core. All of the above may seem incomplete but definitely not confusing or even partial to the people who require extreme tailor made suits for their hardware. Most of all it is what some users like yours truly _require_. I have the moto "your distro, your rules" from the end user's view to be more like "no rules is your rules" from a developer p.o.v. Also take note that offering a yottabyte - level number of packages in an end user "distribution" is usually a source of getting out of the right QA and inner core innovation necessary to push things forward. This is why most if not _all_ distros look and work alike, despite their will to take care of different "needs" they all face the same problems, and not solving them in really, _really_ different manners. (Most ) Distributions have ended up becoming _huge_ junkyards of "depended" binaries nowadays. Any "common core" initiatives quickly fall into oblivion because of this mentality. This is my personal opinion of course. *LFS is/are not a simple educational project since end users are to be deploying in larger scale as production ready systems from the very day Jeremy introduced the Live CD, _officially_ bringing it to its self - hosting age. With this in mind, the lfs family of projects, should they accept that bit of extra firepower they deserve, can be extremely more antagonistic than Gentoo, the T2 project ( _the_ major lfs competitor imvho), Debian, Fedora, Ubuntu <favorite distribution meta - source or non here>, because it/they _can_ and _should_ and _must_ be any of them and none of them if you are to use it as an everyday system. I tend to think of this variant way of implementing a production ready, dependable and services oriented meta source system out of *lfs / diy-linux / (homegrown specified system) as something similar to Jeet Kune Do (http://en.wikipedia.org/wiki/Jeet_kune_do). This requires patience, study and most of all targeted interventions in parts that can cause entropy if promptly discussed without seeing a _valid_ result _first_. I will be available as a helping hand should a task appear, but because of the path chosen, I have to stick to the principles above. It is not just a tool for me, it is a concept, a design and a _framework_. In any other case, the wheel is reinvented when you do not need anything more than to swim. This is one of the reasons why I quickly decided to switch to a completely C++ self hosted way of resolving the problem. This may serve as a response as to how I wish to implement my current variant, and indeed implementing it. Time is coming for it, despite my original concerns. But for starters, and for what concerns the current status of the mailing list I will limit myself to monitoring and posting when absolutely necessary. As for the implementation in hand, I will open it up soon enough when I believe that I can further add things on top to it without eventually reaching a point of having to redesign it soon enough for it to be pointless to even start with. Complete self - hosting features are taken for granted. Disclosing parts of a bigger design without explaining he extent where they are eventually to evolve leads to misunderstandings, of which a gargantual dose is already present in this timespace setting. I am always available under the right light of things, here, elsewhere and _elsewhere_. Keep up the excellent work, especially in the redesign of the book structure, you being the major XML/XSL architect for it. I believe that this preludial post is serving its purpose in clearing my stance in the overall issue(s). Thank you for lending me your time by reading this. Count me in for the ride. Best Regards, George M. -- http://linuxfromscratch.org/mailman/listinfo/alfs-discuss FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
