In my thesis, i search about the different distros that I could use to develop that tool. I supposed that the tool will be based on Slackware, and it will use the Slax structure, it means i will use squashfs, LZMA, aufs, etc, the live scripts that you find in www.linux-live.org.
Suppose, that if i will use other distro, i always use the live scripts. This is the restriction.
I need some ideas to write in my thesis, please answer the next questions?

QUESTIONS
1.It would be able to interest you to use that tool(Yes/No)? If your answer is Yes, explain Why?
2.Is it a good idea to do the tool to create Slackware Live CDs based? If your answer is Yes or not, explain why?
3.Is it a good Idea to do a slackware Live CD based?
4.If the tool is based on slackware(suppose that i will use the same programs to manage packages on slackware), list some advantages or list the disadvantages?
5.In your opinion, what should be the best distro to do a Live cd, and explain why?
6.Is a good idea to use the structure of the file system and the manage package system of Slax(Suppose that the distro use Slax Modules, see http://www.slax.org/modules.php) to make a Live CD?
7.List the advantages and disadvantages of the next programs to manage packages in your system:
A)Debian(apt-get,dpkg) B)Slackware(swaret,installpkg,slaptget,SlackBuild) C)Gentoo(emerge,ebuild) D)Redhat(rpm,yum)
Suppose that you will use those manage package programs to do the file system of a Live CD.

Thanks for answering my questions

If you don't mind me poking a hole in your bubble,

a script like this exists for Arch linux.
That being said:
1) Somewhat - I don't use live CDs much, but if it offered the ability to 'freeze' my distro as it is - I'd probably use it to make backups.
2) Yes - As long as slapt-get is set up at install to use a decent mirror or something similar (so that I could have decent package management)
3) Isn't this the same as number 2?
4) I don't understand this question.
5) I'd say Arch, if your hardware is relatively current. Reasons? 1)It's already i686 optimized (which means most of the speed boosts you get from Gentoo / Slackware but no compiling - unless you would like too)2) (IMO!) VASTLY superior package management 3) Good support for SquashFS etc. (Not sure how slackware is about that though) 4) ships with 2.6 kernel by default 5) Actively maintained (Slackware is getting a bit dated from what I can tell) 6) I like Slax, but its modules could be better solved through a 'real' package management system like pacman or apt-get
7) I'm biased - I hate RPM with a passion (and I hate slackware's old installpkg almost as much.) so all I would be doing is praising Debian or Arch here.

I always find it humorous to hear someone expressing hatred in a package formate. A package be it rpm tar or deb is no different than any other once installed. They are all about the same, the only difference being the tool that is used to install them. That tool is only as good as the repos and servers that contain the packages. I have had an equally good experience with suse's yast as ubuntu's or debian's apt. They all work about the same. and apt for rpm works the same as apt for .deb.
The best apt experience I have had is with pclinux's apt/synaptic rpm package system. Everything available from synaptic upon install.
Pclinux will also allow you to create a live cd iso of your installation with one simple command as root "remasterme". This is available with other distros but simply works without any pain with pclinux.

I understand that they are all the same - however, my dislike for the package formats having nothing to do with the actual package that is installed. I dislike the measures one has to go to to install packages. There's nothing WRONG with rpm packages, but I have had some bad experiences with them (when I started playing with linux, RPM didn't have any dependency checking at all and there were essentially zero package management systems that one could use with RPMs.) I understand that rpms, debs etc are defined essentially by their package management system, not the quality of the package.

The management abilities of RPM have increased as of late, essentially making my criticism of it largely unfounded any longer. Although, I still hold that arch has one of the best management systems in place in its install - despite it being largely command-line-only.

That must have been way before RHL4/5 then. I can't remember them *not* having RPM dependency checking.


I don't dig the "as of late" part. While the underlying functionality has matured over the years RPM's featureset has been more or less complete over versions and includes features I still have to find out if other (binary) package managers (not talking frontends or helper apps here) have, like rollback, relocation and per file verification with DAC rights, ownership and checksum.