Victor Chew wrote:_ One or at most two Work-spaces by default, instead of 4. If taking out the whole feature would reduce dependencies (required resources, size, RAM, etc.) I would suggest taking out the Workspaces feature altogether (after all, this is a special-purpose snapshot Live system, not a full-feature OS).
I don't think taking it out will reduce much of anything, since it is integral to icewm and not external. It will be easy to restrict to only one workspace though, but I'd like to KIV for now and get more feedback before acting.
IMHO, it is fine to allow the user to add more Workspaces, but the *default* doesn't need to be 4. A default of 1 Workspace should reduce required resources.
_ Clonezilla should also have its own Syslinux boot option, so to be able to skip the DE.
Don't quite understand this. Clonezilla is a Debian package that was included in the live build. What does that have to do with a syslinux boot option?
Since Clonezilla can run in text mode, PMagic added the option (in the Syslinux menu) to directly start Clonezilla without having to first start the DE. In fact Clonezilla Live does the same. I am suggesting to have an equivalent possibility in the Syslinux menu.
_ Almost all files under the "isolinux/" directory are either unnecessary, not used, or inadequate.
The files under "isolinux" are generated by live build. I edited some of those files by using "config/includes.binary".
I am suggesting similar improvements to what recently GParted and Clonezilla Live have done, which eliminates the "isolinux/" directory leaving "syslinux/" only and simplifies the procedure to use them from a bootable USB drive. In older versions, there was duplicity of files, and the procedure to build a GParted/Clonezilla Live USB implied renaming and editing directories and cfg files.
In fact, I would say Debian itself should do it too (so all its derivatives would benefit from the change too).
The latest versions of GParted/Clonezilla Live use "syslinux/" only (for both media types, optical and USB mass storage). If you need some direction to directly modify the ISO-building scripts for this particular purpose, perhaps you could contact Steven Shiau by email.
One additional advantage of this change would be that some scripts and tools already used by GParted and Clonezilla Live would be applicable for this distro too (e.g. makeboot.sh, makeboot.bat, Tuxboot, and even some of their tutorials).
Eliminating the unused c32 modules and the cfg files just makes sense. I could have suggested simplifying the "syslinux/" directory even further (while still keeping it user-friendly). But if more boot entries would be available (as that one for Clonezilla I mentioned before), then keeping menu.c32 could be useful. Thus, I "paused" my suggestion about it there.
Victor Chew wrote:_ vga=788 (or any particular value) is not adequate for distribution. I would suggest either:
_ using something similar to what GParted/Clonezilla Live does, prompting questions while booting; and/or,
_ having a visible "first" icon on the desktop so to adjust screen resolution; and/or,
_ having an initial "settings wizard" as Slacko and other Puppies have.
I have included lxrandr for the next release to adjust screen resolution.
Great. IMHO, any specific "vga=xyz" code included by default is still not adequate for distribution, and a clear icon at the left-upper corner of the desktop is very convenient (specially for newbies). Without an adequate screen resolution, the DE is useless (specially for newbies).
Regarding parted, fdisk, mtools, dosfstools,... For GParted to support different tasks for different filesystems, it requires some "background" packages. You can see the available / allowed tasks in one of the GParted menus, where it also lists the tools it uses / requires for each task. There might be some cases where GParted lists a set of alternative tools and can use just one of them.
Based on Debian's package system, I am pretty sure gparted pulls in all the necessary dependencies during build.
The key word would be "necessary" dependencies. For instance, if the adequate ntfs-related tools are not included, GParted can still be used, but the "supported fs tasks" would be reduced. See the respective menu in GParted.
For example, without the background packages, GParted could still create partitions, but it could not format them.
Packages such as dd_rescue, partclone, partimage, wiping tools... are most probably listed in SysRescueCD, PMagic, Finnix, GParted Live, 4MLinux,...
(BTW, since I just mentioned it, the latest SysRescueCD does not include the antivirus database in the ISO images any longer; it allows their download/update by the user, similarly to PMagic.)
Now, regarding the name... IMHO it shall not start with "Debian...", as you are not making a distro to be distributed by the Debian community. If not for anything else, at least for some potential legal issue? (who knows)
In that case, wouldn't FreeDOS UBCD (FDUBCD) have the same issue?
Maybe; but "FreeDOS" is the kernel (although clearly most people refer to it as the whole distribution of DOS-based tools, including the kernel). So here the parallel would be with "Linux" (the kernel), while "Debian" is the name of the distribution(s) (GNU/Linux distro, or GNU/Hurd for a different kernel).
This is why you would find names as "Linux Mint Debian Edition" (with "Debian" not being used before "Mint"), but also "Simplicity Linux" (with "Linux" after the name of the distro), and also "Linux Mint" (without mentioning "Ubuntu" as its base), or "Antix" (which uses "Linux" as kernel and it is related to "MEPIS", but it doesn't mention them as part of the name, only in its web/forum/announcements/news/credits...).
Note that "Debian" is the main (and only) name, and it supports multiple architectures, more than one kernel (Linux and Hurd, at least), more than one kernel type (i486, x86_64), multiple DE (say GNOME and XFCE or whichever else), CD media and DVD media, "old stable" / "stable" / "testing" / "unstable" / "experimental",... OTHO, UBCD ISOs need to be identified by date of snapshot and whether it is the traditional basic UBCD or the Linux distro ISO image.
So, as long as these are snapshots of "Debian testing", and only one base is used at a time, I would limit the name to an initial "UBCD", then perhaps "Linux" (so to reduce potential confusion with the traditional UBCD base ISO image) and a "yyyyMMdd" (similar to PMagic). They completely and clearly define the current ISOs, at least for now.
Thank you for taking the time to answer to my questions.