Let's remember the importance of keeping the permissions right for the root user. A regular user should not have the ability to change settings in /etc or alter /var/cache -- I do like the idea of using the home= boot option, though. My idea is this: lets make a /home/root folder and just symlink /root to it. In the /home/root folder, we can have a cache directory, as well as the slitaz directory (only a root user should be able to generate a new iso from the existing filesystem, anyway) -- the permissions could remain root:root, and this could facilitate a writable place for changes in the root filesystem. By this, I mean that the root user could make a custom /etc/network.conf, or whatever, and have it persistent for the next boot. We could do away with /etc/skel also, as I suggested before, and have one place for customizations that wouldn't affect $user directories or the rootfs... this would mean that a user could reboot into a completely different flavor, or custom package list, and not lose display settings or wireless configs.
On Tue, Dec 14, 2010 at 3:00 PM, Christopher Rogers <[email protected]> wrote: >>The goal of home= boot option is precisely to use an external devide >>instead of having a home in RAM, so I don't see how it will make grow >>the RAM requirement to 2GB. It's the exact opposite : Having the cache >>folder on /home will avoid keeping all downloaded packages in RAM ! and >>will avoid re-download them at each session. And you can mount >>absolutely what you want as home (i.e: liveCD+home on hdd; usb+home >>from an encrypted file; etc). > > I was talking when you were said that the livecd could be 700mb. (Like puppy > linux multisession or something.) This is without the home= option. Even > with home= option your still not going to have your custom packages that you > installed to system. Also since its only saving to home folder everything > else is still in RAM. You will not save /etc folder. You will not save any > other folder other than /home. > >> I also use my modular-slitaz that has changes boot option. This saves >> everything that is not from the livecd into changes folder on my hard >> drive. >> The home= boot option you also don't have system settings from /etc folder >> too. >> >> With the way sitaz works the make a full 700mb cd would take over 2gb of >> ram >> just for the filesystem. This is cause everything is uncompressed from >> initramfs file into ram. Also this would cause slitaz to be slow to boot >> and >> buidl the iso. > > I said in the quote uncompressed 700mb cd/rootfs.gz = OVER 2GB. I was not > talking about home= option in 3rd paragraph. > > I hope this helps. > > PS I can talk to you better in irc then email. Sorry about my confusion. > > > > On Tue, Dec 14, 2010 at 10:37 PM, GoKhlaYeh <[email protected]> wrote: >> >> On Tue, 14 Dec 2010 20:44:55 +0000 >> Christopher Rogers <[email protected]> wrote: >> >> > The /home/slitaz folder is a bad idea since most development folders on >> > tank >> > go there. That could cause confinct with there being to many folders >> > there. >> >> As you know, I made some changes recently in tazpkg. Before that, >> tazpkg copied packages info files from local repository >> (/home/slitaz/$release/packages) into the /var/lib/tazpkg; and copied >> packages from local repository to cache dir (/var/cache/tazpkg). Now, >> it uses symlinks instead; so virtually cache and local repository **are >> already merged**. It doesn't complexify anything and save a lot of >> ressources. Then, about undigest : as you push the m5sum verification >> in tazpkg, here's whats going on : if names overlaps, it replace the >> symlink to a repository (lets >> say /home/slitaz/cooking/packages/pkg.tazpkg) by a symlink to the >> desired one (i.e. : /home/slitaz/undigest/packages/pkg.tazpkg). So once >> again, all run as cache dir and local repo are merged actually; and >> it's precisely based on tank directory structure = no problem here, >> even with multiple repositories using the same cache. I was talking >> about desirable changes to make things better, because there's really >> no problem with actual behavior. About info files : the side-effect of >> using symlink is that tazpkg recharge is needed only once time; then >> info files linked from local repository are always up-to-date :) >> >> > Also this would require a rewrite of most tools that look at CACHE_DIR >> > path. >> So : tazpkg, as the only other occurence to CACHE_DIR in SliTaz tools >> is a line in tazlito which try to link packages from cache directory to >> the local directory... >> >> > I also use my modular-slitaz that has changes boot option. This saves >> > everything that is not from the livecd into changes folder on my hard >> > drive. >> > The home= boot option you also don't have system settings from /etc >> > folder >> > too. >> > >> > With the way sitaz works the make a full 700mb cd would take over 2gb of >> > ram >> > just for the filesystem. This is cause everything is uncompressed from >> > initramfs file into ram. Also this would cause slitaz to be slow to boot >> > and >> > buidl the iso. >> >> The goal of home= boot option is precisely to use an external devide >> instead of having a home in RAM, so I don't see how it will make grow >> the RAM requirement to 2GB. It's the exact opposite : Having the cache >> folder on /home will avoid keeping all downloaded packages in RAM ! and >> will avoid re-download them at each session. And you can mount >> absolutely what you want as home (i.e: liveCD+home on hdd; usb+home >> from an encrypted file; etc). >> >> > I just think its better to use the /var/cache/tazpkg/undigest/$repo path >> > for >> > undigest for now. We should just work on make home= boot option work >> > more >> > like changes boot option in modular-slitaz. >> >> I don't see the point about home= boot option. I disagree with your >> criticals but obviously you can proceed to this change if you want to. >> Hoverwhere, I think having the cache on a peristent home will be a >> great improvement and I intend to code this someday. >> >> Peace, >> >> -- >> GoKhlaYeh <[email protected]> >> >> >> --- >> SliTaz GNU/Linux Mailing list - http://www.slitaz.org/ >> > > --- SliTaz GNU/Linux Mailing list - http://www.slitaz.org/
