> Either way, I'd like to hear feedback about this issue. I feel it's an audit > issue... a bug. Actually it's just a universal lack of regard. *** No program should maintain any large amount of unencrypted data in a temporary disk file for any indeterminate time. *** I think GNU needs to hear that message, and move in that direction.
I agree that tmp files are a nuisance, and should be more manageable. I would also like to see some better thought for log files and .conf files. Spool files might also be an issue. And I must also mention that SWAP space might need attention. I learned that programs using priv-sep can't always recreate their private dirs in /tmp. The /tmp/private dirs need to be created by root. This gets old really fast when the entire /tmp dir gets wiped. Vim makes it's stupid.swp files in the PWD or where the original lives, and Gedit leaves mouse droppings~ everywhere. It's a mess, but temporary files and the like are very problematic, and guidelines need to come from way upstream or you risk creating untold conflicts. Probably safer to write a script to locate all those goofy outdated files and delete them periodically. > The variable here is the goals for HLFS-1.0. Either keep plowing ahead, or > settle down and use what we have. > Whoa, if it is build-able and working it's probably not broken, so don't change anything and freeze that release as -stable. My HLFS has been online 24/7 >30 days without any problems, and I added a lot of things that tax it. ( Mine is as stable as any Fedora release;-) You can always bravely run the LTP suite on it ... > but it can't be automated for ALFS. > Next they will want binary installers and bypass reading the book altogether. Simple; if you can't build it you shouldn't have it. Marty B
smime.p7s
Description: S/MIME Cryptographic Signature
-- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
