Thanks Jeremy, Since the reply was mostly of the agree/disagree/interesting variation, I'll just comment on some random points.
> Thanks for this, this is exactly the sort of discussion I was after... That's good. > It's over 500 distinct email addresses. This implies that the list is alive in the sense that those subscribed actually read what is going on, which is a good sign. >> I'm risking insulting people, but it seems to me that the alfs, clfs, >> hlfs, and livecd >> projects are basically dead. > > Indeed. And an email I sent last night to the livecd list with the intent of > measuring interest of resurrection met with a rather interesting reply that > I still have to respond to. I'll risk answering you in the wrong list: Copied from livecd list: # 1. What future direction should the CD take and why (i.e., Stated Purpose, # build method, packages included, other features) Stated purpose: a clean build host, and "LFS livecd will give you the skeleton of a tent". Packages included: Basic level including LFS + host system requirement + image writer + LFS package sources. Full level including above and a basic desktop environment. Build method: LFS works well enough. # 2. How are we going to organize to achieve the answers to question 1? By incorporating the project into LFS. >> which I just noticed, >> which is next to a tiny link for #1 above. > > So you think these should be more prominent? Yes >> 5. I don't like the design of the main page of LFS holding news >> instead of content. The >> content of LFS is generally stable. It isn't a news site which needs > Heh, it's interesting that you should say that. That was, IIRC, one of the > things that was disliked about the old purple-y website. I think this is a > valid point, and if we get the above two things sorted, this should also > sort itself out. Of course I am somewhat old fashioned. > Except that the point was, if you recall, to see whether this would make a > good replacement for the main site. Obviously #5 above doesn't bother most people. Anyway, my impression was that the main issue was development, and revamping the website a side benefit. Either way, I stated my opinion. >> 3. Building a second time, possibly with personal "touches". I suspect >> management system can be used (or designed) for this. I suspect most LFS >> users >> install LFS once for the experience, and then forget about it due to this. > > I find this an interesting thought. Any further thoughts along this line as > to what would 'engage' readers more? 1. Better understandable automation, to allow the user varying levels of hands on control. 2. Giving the user specific examples with instructions how for different variations. 3. Live package management, to allow users to move back in the book. > Yes, you've hit what I think amounts to an attitude problem in LFS. > Sometimes it's very heavy. 'This is how we do it, because this is how we've > always done it. I see no reason to consider another solution because this This attitude, while understandable, can keep a stable and well maintained project from rejuvenating itself. > difficult when there are few hands lifting the load, but there could > definitely be a more sympathetic and welcoming atmosphere. True. But offering some help or guidance can in the long run add more helping hands for lifting the load. >> 4.e. Suggest "major" design updates for the book. The response is > Agreed and again, personally, I feel it's connected to the same reasons as > my comments above. Definitely, but with the same result. >> Finally, what do I think should be done? First, LFS needs to choose >> its direction. >> 1. At the moment there is usually no reason not to use the development >> version. >> I suggest releasing a stable "package update" release regularly, say >> 2. Include more automation options with LFS. Including making sure they >> work with the errata pages. >> 3. Include package management options, both for moving packages from >> installation to installation, and for keeping track of installations. >> 4. Include several BLFS installation paths up to date. >> 4a. LFS host system. Will include the host system requirements for >> installing LFS. 4b. I would add to the list a basic X system. >> 5. Integrating livecd project into lfs. Should be 4a with a program which >> creates/burns cd images. > I think all of the above are great suggestions, Yaakov. I challenge you now > to take the next step and develop some of these ideas with a little more > detail and see if you can get some momentum behind them. :-) Not a very easy I would probably start with #2 and #3. I'll try to develop these further, though as this requires more thought, it won't do this on the spot. As a start, I would like to know what method of automation the developers use, and definitely wouldn't mind seeing their scripts if possible. #4 and #5 would require coordination with BLFS, and could take advantage of #2 and #3, so I would wait with them. #1 is independent and is mostly a question of administration. Another task which could help keeping #4 and #5 up to date, (and ultimately all of blfs) would be a (partially) automated test system which will at least warn when updates to LFS cause the compiling of a later file to fail. > task, I know, but I'll help as I can. For example, I've done a lot of work First I have to do some work... > really be nice if LFS was a more dynamic and sharing community. Having a > more dynamic and sharing website might make that more of a possibility. Hopefully. Though I believe that - at the moment - a serious contributing factor is LFS being "too" stable. Thanks again, --yaacov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
