Re: LiveCD Users
On Tue, 17 Jul 2007 21:29:52 -0600 Jeremy Huntwork [EMAIL PROTECTED] wrote: The LiveCD project rarely hears much back from its end users, unless Of course any other thoughts or comments are welcome. We really just need to get an idea of how useful our project is to the community. If it's too much work to answer the above, just a short reply saying you use the CD would be helpful, too. Whilst I applaud and support the LiveCD project, I don't use the 'product' myself, but I thought, for completeness, and out of respect for the developers, that I should say why. Read CLFS for LFS, I use them both on occasion, but mostly jhalfs+clfs-svn these days. 1) It ruins the fun of discovering if LFS will build on a new machine. This isn't true really, but it seems to me that some of the frison of that first boot is lost. 2) Once I've got a rudimentary LFS running, then I would use that to bootstrap the next model. Although LFS has gotten so good and reliable these days that it almost always: 'just works'. Is there an advantage to using the LiveCD as the base of the bootstrap? 3) Once, when I used a LiveCD (one of the original LiveCDs 2002-ish, I can't remember whose), all I did was copy it to the hard disk and then fiddle 'till it worked. I didn't then build a native LFS for it, but then it just ran the firewall - until last year! Where I think a LiveCD can be useful is to help find out the working baseline .config for the kernel, and maybe a starting position for xorg.conf, although that's less problematic these days. Of course if you've never run Linux before, and just have an Anti-trust (hint: starts with M) box, then the LiveCD would be a revelation. But, writing my memoirs, I recollect throwing all my Anti-trust stuff out after returning from a business trip to Redmond in 2001 - I remember showering a lot too. (unrestricted submarine warfare is not an acceptable business ethic) :-) R. LFS #207 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LiveCD Users
Jeremy Huntwork wrote:
William Harrington wrote:
I think it'd be a good idea to post this to all the mailing lists
than just this one.
Well, I did lfs-dev, lfs-chat, and livecd. You think there's bound to be
more users not covered on the other lists?
--
JH
I haven't used a LiveCD, so can't offer any feedback i'm afraid, but i
thought i'd suggest that posting to the lfs-support list strikes me as
the place most likely to draw attention (i'm only currently registered
on {,b}lfs-dev -support)...
hth, taipan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: LiveCD Users
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Jeremy Huntwork wrote: 1) What version of the CD do you use/have? Looks like 6.2-5. 2) What do you use the CD most for? Booting qemu to test the mkinitramfs package I'm doing. ;-) 3) What are the most useful parts of the CD to you? Support for dmraid / mdadm / LVM. Also mount.smbfs, so I can pull files from my normal machine into the qemu image (qemu runs a virtual network, with SMB/CIFS pass-through to the real host). 4) What is the most annoying or useless bits of the CD? Not annoying, but slightly useless: X and the entire system build setup. But that's just because I don't use X in qemu, and qemu is horribly slow at building anything. So I don't think it'd be a good idea to get rid of either of those for everybody (as my usage is a special case: I don't boot a real machine). 5) What would you change/add/improve? Not sure; at the moment, it works great for what I need it to do. :-) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGnfZnS5vET1Wea5wRA0CzAJ0dO0CyK81azzLxxPhwF/cqESL4agCfZoYo xLAcsIB/aq9+BXcTB9fAtus= =qepL -END PGP SIGNATURE- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: pidofproc function in functions script
On 7/4/07, Dennis J Perkins [EMAIL PROTECTED] wrote:
I played with pidofproc and this seems to work properly. I don't know
if it would integrate into your functions without any changes.
I've had a look, and I like what you've done. It may need to be
massaged a bit to maintain compatibility in the LFS bootscripts,
though. I also added lfs-dev in case some more eyes want to shine on
here.
I used getopts instead of your while loop. I discovered that t does not
detect options after a parameter.
That's probably true. I'm a little uncomfortable using getopts since
we don't use it anywhere else, but it is in the POSIX spec, so it's
safe to use.
I also included an exit code for a syntax error, but LSB doesn't call
for it. Since pidofproc is meant to be called by other functions, it
might not be that useful anyway.
I like errors on syntax abuse.
It also returns a list of found pids. LSB specifies exit codes but is
silent on return vaues.
I think that's the way to go.
pidofproc()
{
local base# basename of program
local opt # option currently being processed
local pid # pid from pidfile
local pids# list of pids to return to calling function
local pidfile # pidfile passed to pidofproc
local pidlist # list of pids to be returned to calling function
This is actually an important change. Currently the other functions
rely on the side effect that pidlist is global. We can change those
other functions (this way is much cleaner, IMO), but there may be
scripts out in the wild that depend on the current functionality. I
didn't find any in either of the current LFS or BLFS bootscripts,
though.
while getopts :p: opt
do
case $opt in
p ) pidfile=$OPTARG ;;
* ) log_error_msg $usage
exit 2 ;; # Syntax error
esac
done
shift $((OPTIND - 1 ))
You removed the -s option, which was kind of nice when you just wanted
to know if it was running and didn't care what the output was. I
suppose it's not LSB supported, but we may need it to be LFS supported
:) I haven't checked out the situation with the current scripts.
# If a pidfile was not passed, look for one in /var/run.
base=${process##*/}
${pidfile:=/var/run/$base.pid} 2 /dev/null
I would sort of like to kill this section since I think it's kind of
evil to guess a pidfile when it wasn't specifically asked for. This
would change existing behavior for current bootscripts. statusproc
currently does something like this, too.
if [ -f $pidfile ]; then
I think this is not quite right. If I asked you to look at
/var/run/dbus.pid (as opposed to it just being guessed above), then
that is exactly what I want to be looking at. If it doesn't exist,
then it's not running from my perspective. The whole reason I passed
in the pidfile is so we don't just go blindly searching for any
process named dbus.
So, there needs to be two tests: if the variable is set (assuming the
previous munging is removed), then if it exists.
if [ -n $pidfile ]; then
if [ -f $pidfile ]; then
...
# LSB specifies that only the first line of the pidfile should
be read.
read pidlist $pidfile
I see. We're not exactly LSB compliant, but that should be good enough.
else
# No pidfile. Try to find pid anyway.
pidlist=$(pidof -s $$ -o $PPID -x $process)
if [ -z $pidlist ]; then
return 3 # Not running
fi
fi
-
# Build list of pids of running processes.
for pid in $pidlist
pidlist can't be quoted here or it will result in a single argument
for all pids.
$ for pid in 1 2; do echo x$pid; done
x1 2
do
if kill -0 $pid 2 /dev/null ; then
pids=$pids $pid
fi
done
if [ -z $pids ]; then
return 1 # Not running, but pid found.
else
echo $pids
fi
}
The rest all looks good to me.
--
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Plans for LFS-6.3
On Tue, 2007-07-17 at 13:56 -0700, Dan Nicholson wrote: I'm pretty much in that boat :) I'll be out of town the July 25-30, but I'll be more than happy to give time when I can. I think we can pretty much push a package freeze right now and cut a branch. The only thing I'd be interested in seeing is glibc-2.5.1 if it happens. Also, I have a couple previously mentioned bootscript patches that I'd like to push in. Those are low priority, though. Without trying to sound ungrateful to people working on LFS: what about GCC 4.2? Any chance of seeing it in LFS any time soon? Dejan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: gettext troubles [possible solution]
Rob van Dam wrote: Hi Brian, I ran into the same problem, and I decided to skip Perl, but I am already regretting it. I think I put back a backup of the temporary system. Does it btw make sense to try your gettext patch on a system with an already patched uClibc? I made a backup of my temporary system with a patched uClibc. Rob Brian Cheeseman schreef: All, Has anyone managed to compile the Perl utils in chapter 5? I keep getting errors compiling toke.c. Searches on the internet show the same error, but no solutions. The build output I keep seeing is below. hlfs:/mnt/hlfs/sources/perl-5.8.8$ make perl utilities `sh cflags optimize='-O2' perlmain.o` perlmain.c CCCMD = cc -DPERL_CORE -c -fno-strict-aliasing -pipe -Wdeclaration-after-statement -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -Wall `sh cflags optimize='-O2' perl.o` perl.c CCCMD = cc -DPERL_CORE -c -fno-strict-aliasing -pipe -Wdeclaration-after-statement -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -Wall perl.c: In function 'perl_parse': perl.c:1586: warning: passing argument 1 of 'time' from incompatible pointer type `sh cflags optimize='-O2' gv.o` gv.c CCCMD = cc -DPERL_CORE -c -fno-strict-aliasing -pipe -Wdeclaration-after-statement -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -Wall `sh cflags optimize='-O2' toke.o` toke.c CCCMD = cc -DPERL_CORE -c -fno-strict-aliasing -pipe -Wdeclaration-after-statement -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -Wall toke.c: In function 'S_scan_formline': toke.c:10542: error: invalid operands to binary + toke.c:10542: error: invalid lvalue in unary '' toke.c:10542: error: invalid lvalue in unary '' make: *** [toke.o] Error 1 I have also tested this build under Glibc and it compiles correctly. Any and all help appreciated. Regards, Brian. Rob, I generated the patch for gettext after applying the uClibc patch you mailed to the list and it corrects the build for gettext so that the instructions in the book work. If the consensus of the list is to apply the patch this way, then I would push it to being added officially to the book. Basically it just adds a global variable to the msgfmt program which uClibc then uses to determine that all output directed to the error_print_progname handler is sent to STDERR. In all reality a developer could define this variable pointing to their own handler function. Sorry, got side tracked. In short, yes it is safe (in my opinion) to apply this patch in conjunction with the book and your patch. My patch is working on gettext not uClibc. If you are refering to another patch against uClibc would you mind specifying which one and I'll look at it. Cheers, Brian. -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LiveCD Users
Hi, 1) What version of the CD do you use/have? Some 6.2-x, when I last needed one, about half a year ago. 2) What do you use the CD most for? booting a box where no working current Linux is installed, i.e. prior Linux installations are damaged, too old for a certain purpose or just not existing. 3) What are the most useful parts of the CD to you? Having a known good Linux installation that 1) enables me to start building LFS on a box without having to care about prerequisites like kernel versions on that box and 2) can be used as fallback OS in case anything went wrong (boot sector overwritten or something like that). 4) What is the most annoying or useless bits of the CD? I never examined what I did not use of it... Well, the sources are not that important to me, because I tend to use the most current (and externally stored) versions (and not the ones from the last LiveCD at hand) if I decide to play with LFS again. On the other hand: if there is enough space its convenient to have a good starting set of packages available at no extra cost. Most annoying is probably having to specify the same parameters (like keyboard layout) every time when booting. But I'm not sure either whether storing that somewhere on HD or giving the user a certain time to press a key to enter such info instead of using a default would be better. 5) What would you change/add/improve? For me, having a current always works solution is the main benefit, but I dont have any idea at the moment how that could be improved further. Uwe -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Plans for LFS-6.3
On 7/18/07, Dejan Čabrilo [EMAIL PROTECTED] wrote: On Tue, 2007-07-17 at 13:56 -0700, Dan Nicholson wrote: I'm pretty much in that boat :) I'll be out of town the July 25-30, but I'll be more than happy to give time when I can. I think we can pretty much push a package freeze right now and cut a branch. The only thing I'd be interested in seeing is glibc-2.5.1 if it happens. Also, I have a couple previously mentioned bootscript patches that I'd like to push in. Those are low priority, though. Without trying to sound ungrateful to people working on LFS: what about GCC 4.2? Any chance of seeing it in LFS any time soon? Yes, but after 6.3. It's a rather large change that requires testing, so it'll have to wait until after the release. The sooner 6.3 is pushed out, the sooner we can start upgrading to gcc-4.2 and glibc-2.6. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Plans for LFS-6.3
On 7/17/07, Dan Nicholson [EMAIL PROTECTED] wrote: On 7/17/07, Ken Moffat [EMAIL PROTECTED] wrote: What do your bootscript patches do, and how do you view their risk ? Should be backwards compatible. A couple I have queued up but keep forgetting to commit them. Add an early script to quiet the kernel log level, then kill the level handling in init.d/modules. http://linuxfromscratch.org/pipermail/lfs-dev/2007-June/059501.html Second one would kill this bug: http://wiki.linuxfromscratch.org/lfs/ticket/2026 As warned previously, I've added a new script to set the printk level on the console: init.d/consolelog. This is linked at rcsysinit.d/S02consolelog. It reads the LOGLEVEL variable from /etc/sysconfig/console. I added a blurb in chapter07/console.xml about this. Holler if you have any problems. Here's the commit. http://linuxfromscratch.org/pipermail/lfs-book/2007-July/021153.html I also committed another change to clean up the modules script, which parses /etc/sysconfig/modules. There should be no change in behavior. http://linuxfromscratch.org/pipermail/lfs-book/2007-July/021154.html If these seem alright, I'll spin a new lfs-bootscripts snapshot. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
RE: LiveCD Users
I'll chime in and give a long overdue thanks to everyone in the *LFS community for a job well done. That especially includes the liveCD project. 1) What version of the CD do you use/have? 6.0-1 and 6.2-5 2) What do you use the CD most for? Installation of LFS on new systems. To date I've done 7 installs, including installing to a USB hard drive. To paraphrase Brian Fantana, 100 percent of the time, it works every time. 3) What are the most useful parts of the CD to you? ALFS (NALFS or JHALFS) 4) What is the most annoying or useless bits of the CD? Not really the CD's fault, but the lack of BLFS automation. (Why can't you guys create a CD that reads my mind and solves cyclic dependencies automatically?) 5) What would you change/add/improve? Speed of bootup ;-) J/K. The documentation on the website is a bit sparse. Perhaps just adding a statement that all you really need to know is included in the README on the liveCD would be sufficient. Also, we're just starting to look into creating our own liveCDs using the LFS liveCD as a starting point. I may have more to add on that topic in a month or two. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jeremy Huntwork Sent: Tuesday, July 17, 2007 10:30 PM To: [EMAIL PROTECTED]; lfs-dev@linuxfromscratch.org; [EMAIL PROTECTED] Subject: LiveCD Users Hello, I'm aware that this is perhaps a little off-topic for the -dev list, but I feel that this thread could really help future development of the CD, so please bear with me and help me out with as much feedback as you can muster. :) The LiveCD project rarely hears much back from its end users, unless someone has a problem booting, or understanding how to use the CD, or having trouble building LFS (in which case they're talking to the wrong list anyway). The effect is that we really have no idea who uses the CD, how useful certain features/aspects of it are, what things may need to be improved and so on. So please, if you use the LFS LiveCD, please reply to this thread (on whatever list you read it), and if possible, provide the following info: 1) What version of the CD do you use/have? 2) What do you use the CD most for? 3) What are the most useful parts of the CD to you? 4) What is the most annoying or useless bits of the CD? 5) What would you change/add/improve? Of course any other thoughts or comments are welcome. We really just need to get an idea of how useful our project is to the community. If it's too much work to answer the above, just a short reply saying you use the CD would be helpful, too. Thanks in advance, -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Plans for LFS-6.3
On Tue, Jul 17, 2007 at 07:57:08PM -0600, Jeremy Huntwork wrote: On Wed, Jul 18, 2007 at 12:50:45AM +0100, Ken Moffat wrote: I was going to say 'yes' to a package freeze (and if glibc-2.5.1 appears in a timely fashion you can knock me down with the proverbial feather!), except that (a) ISTR you weren't very confident about linux-2.6.21 (you quoted Dave Jones's comments, I think) and indeed Linus found its release somewhat painful, and (b) 2.6.22.1 is out (WFM!) and might last a little bit longer (by the time 6.3 comes out, 2.6.21 is unlikely to still be maintained). Matt seems to have solved this bit already. See http://wiki.linuxfromscratch.org/lfs/changeset/8219 Thanks, I hadn't seen an update on -book so I checked the online version and it was a few hours out of date. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LiveCD Users
On Tuesday 17 July 2007 11:29:52 pm Jeremy Huntwork wrote:
1) What version of the CD do you use/have?
I'm using 6.3-r1952 although I have 6.2.5 also
2) What do you use the CD most for?
I'm exploring jhalfs ... basically just learning {,b,c}LFS ... but mostly I am
just futzing around learning by making mistakes
3) What are the most useful parts of the CD to you?
Being able to boot into a known good environment to build within.
I ike being able to run X ... in particular, I've found the I really like xfce
as a working environment. Having a browser open along with a xterm makes for
very convenient cut and paste.
I have the LiveCD installed on a partition of the 2 systems I'm using with
LFS currently.
4) What is the most annoying or useless bits of the CD?
I don't have any ... although there are certainly things I haven't gotten
around to using yet such as distcc ... I did read a warning about parallel
compiling but I am wondering how booting a couple machines off the same CD
would affect things ... but what I do best is procrastinate.
5) What would you change/add/improve?
Just a minor quibble ... jhalfs-2.2 is listed as latest stable yet 2.1 is on
the r1952 CD ... takes about 15 sec to fix but it prolly ought to be updated
for consistency ... but, boy howdy, I'm a happy camper. I haven't looked for
anything later although I know Jeremy has been working on the no-source CD.
I am quite interested in getting X86_64 running but I'm not up-to-speed on
CLFS yet ... I am looking forward to learning what I can as the project moves
forward in that direction.
K
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Plans for LFS-6.3
El Miércoles, 18 de Julio de 2007 02:49, Bruce Dubbs escribió: What do you want for a target release date? I would think we could get a -rc1 out in a week if we don't make any changes to the tool chain. Looks good. I will start some ICA/farce and full-testsuites builds. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Plans for LFS-6.3
On Wed, 18 Jul 2007 19:55:50 +0200, M.Canales.es [EMAIL PROTECTED] wrote: I will start some ICA/farce and full-testsuites builds. I did a full final system testsuite run with the latest package updates (including a repackaged version of the latest iproute2 package). No failures there. I've not done an ICA/farce build though, so that would certainly be useful. Thanks, Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Plans for LFS-6.3
Bruce Dubbs wrote: Dan Nicholson wrote: Fixing pidofproc to actually do the right thing w.r.t pid files. Dennis Perkins actually put that part together. The other change he does there is make the pid list local and echo it back. This is slightly different and possibly not backwards compatible since the current behavior has the other *proc() functions just using the global pidlist variable created in pidofproc. I prefer Dennis' way and can fix the functions to catch the result in it's own variable, but it could break existing scripts which call pidofproc directly. In most cases, though, pidofproc is being called indirectly through loadproc or statusproc. I did a grep of the bootscripts in both BLFS and LFS and the only files that mention pidofproc are: [EMAIL PROTECTED]/LFS/trunk/bootscripts]$ grep -rl pidofproc *|grep -v svn ChangeLog contrib/lsb/lib/init-functions contrib/lsb-v3/lsb/init-functions contrib/lsb-v3/init.d/lfs-functions contrib/lsb-v3/init.d/template lfs/init.d/functions [EMAIL PROTECTED]/BLFS/trunk/bootscripts]$ grep -r pidofproc *|grep -v svn [EMAIL PROTECTED]/BLFS/trunk/bootscripts]$ So if these files are all made consistent, there shouldn't be any problem. As far as user's custom scripts go, I'd think a prudent user would check them all when upgrading to a new version of LFS. -- Bruce Well, the contrib/ versions shouldn't even be considered. They provide their own pidofproc() anyway, which already has this change because the spec says so. So the patch is a go already as far as anything within the LFS and BLFS. Another consideration is whether CH are still using the same/similar functions file and scripts. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LiveCD Users
On Tue, 17 Jul 2007 21:29:52 -0600, Jeremy Huntwork wrote: 2) What do you use the CD most for? Rescue. 3) What are the most useful parts of the CD to you? The shell. 4) What is the most annoying or useless bits of the CD? Every time I get a new LiveCD I always have some new piece of hardware whose module didn't make it into the kernel until the version which is one femtoversion after the one on the LiveCD. Every time I have a LiveCD which covers all of my hardware there's always a dependency on a /lib/ firmware/something which the LiveCD dev could not possibly have anticipated (without scraping the web for every possible firmware that might be needed). Everytime I get to the point where I have a LiveCD which addresses all of my hardware something happens in my life to keep me away from the project for six or ten months and I return to the first sentence of this paragraph. 5) What would you change/add/improve? I still don't know how to us iproute2 competently though I can sometimes bumble my way into creating a useable network. Is there a concise tutorial? Maybe I'll end up writing one... JH The LFS team is the best! Steven -- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Incremental upgrades
On Wed, 18 Jul 2007 01:14:52 +0100, Ken Moffat wrote: More to the point, I've long thought that we don't really cover the long-term care of your LFS system (e.g. I don't think we point out Care and maintenance of any complicated entity, a house, a garage, a method of building an OS, maintaining an OS, a car, a job, or writing near-bulletproof code is as much of an art as it is a procedure--and it varies from one person to the next. What we can do is try to gently encourage new users, who may not be familiar with Xen and the Art of LFS Maintenance, into habits which will lead them to be good admins (both for themselves and for others, if that applies). As always there is reading required: http://catb.org/~esr/writings/unix- koans/ OTOH, I think I can remember a large effort to prevent the book being dumbed-down, so maybe this is something that should be obvious to builders who intend to stay with LFS. That's also a very good point to recognize. It doesn't so much matter if we want people to stay, or if there are people who want to stay: what matters is if they do stay. If we involve ourselves deeply in every problem that they have then we will only frustrate ourselves and them. If we remain too aloof then the project will dwindle. There is a balance to be found by encouraging good practices and discouraging bad ones. Maintaining a system running a packaged distro on at least one machine will help the user to recognize things which need to be updated and give them insight how to go about it. When the set of packages that Debian Sid updates meshes nicely with the set of security alerts which I've seen in the last week then I know that I'm watching the right stuff. One last note on glibc updates: When Debian updates a glibc there aren't often many packages which need to be updated alongside of it. This must be due to a very careful watch by the devs on what changes are actually made in the glibc--and that may be related to social connections and manpower that LFS doesn't have (though I tend to believe that the LFS devs know how to stay on top of the bleeding edge of their respective areas of interest). The only consistent part of a glibc .deb update that I remember is that most (all?) active running services are restarted. That's about it. Yay for dynamic linking at runtime perhaps? -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
On Tue, 17 Jul 2007 17:36:40 -0600, Gerard Beekmans wrote: Or it will end up in an LFS Hint. Or we'll defer completely to CLFS. Long live pureLFS! When I was first introduced to CLFS it was indicated that some people indeed anticipated that, eventually, the cross method would become The Book. I had a few months to look at it before the last bombshell completely took out my base (think the first release of Red Alert). I didn't see anything, from a user's perspective, so extraordinarily advanced in it that made me think that it wouldn't become The Book. I can somewhat see how the CLFS method may be a bit harder on the devs to maintain but, if everything does finally merge together again, then it'll smooth itself out over time. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Preparing for 6.3 Release
I wrote: BTW, I have no 64-bit PC. This is no longer true. Now I have a system with Intel BLKDG965SSCK motherboard, Intel Core 2 Duo E6420 CPU, and 2 GB or RAM. My first task is to fix the LiveCD so that it works well on this computer (this means updating the kernel). -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
