Hi, > On Feb 7, 2025, at 11:48 AM, Darik Horn via Freedos-devel > <freedos-devel@lists.sourceforge.net> wrote: > > (Posting only because I enjoy compression and optimization; not > because I am asking for changes.) > > Repacking T2502 with a modern deflate32 implementation adds 45 MB of > usable payload space in the FreeDOS distribution media. These savings > are nearly zero-cost and do not require retooling. Details here: > > https://docs.google.com/spreadsheets/d/1f_6OqBynrWtStkOux13g3XiuzTku75l5/view > > The FD14LIVE and FD14BNS images can be combined into one 74-minute > compact disc master for bulk fabrication. > > Notes: > > * Using deflate64 instead of deflate32 adds 58 MB of payload space. > This zip variant is compatible with unzip-6.00 in FreeDOS, but is > incompatible with pkzip-2.04g. > > * The DOJS.ZIP and CURL.ZIP packages each contain a large SOURCES.7Z > file that skews distribution size. In the next FreeDOS release, using > 7z for all source code might obviate any more package removals. > > * Repacking everything as 7z adds 250 MB of usable payload space in > the distribution media. A baseline 80386/4MB machine can unpack 7z > archives having 1 MB dictionary sizes, which is slightly less than the > sweet spot for the FreeDOS dataset. > > * On the FreeDOS dataset, 7zip-24.09 significantly outperforms > rar-6.24, which is the last release that can create rar4 archives that > are compatible with rar-2.90 for DOS. >
If I were you, I would not waste my time getting fixated on trying to squeeze every byte out of the packages provided with the FreeDOS release. Packages come and packages go. It is possible that in the future, the FreeDOS community could want to provide a more bare-bones release. Maybe, something that would fit on one of those tiny 210Mb, 24 Minute 3.5 inch CD-ROM. Or possibly, the even smaller Business Card CD as a targeted size. I think it is more likely that the eventual inclusion of additional large packages will increase the size requirements. Possible the someday inclusion of PC-GEOS at 100Mb+. Or, the return of DJGPP and potentially 100’s of Mb. Possibly even multiple “BonusCDs” may be needed. Furthermore, anything not supported by the current package management tools (FDNPKG and FDINST) is a non-starter at present. During installation, packages are NOT simply unzipped. There is a lot more to the process. Primarily, that would be the remapping of special paths in the archive to directories in the installed system. Additionally, anything that requires more than an 8086/88 or standard base memory to extract the binary portion of the package is not going to happen. On top of all that, the packages must be able to extracted, compressed and processed with standard Linux utilities and still maintain DOS compatibility. This is needed for the FreeDOS GitLab Archive, Ibiblio Online Download and Update Repository and the RBE. While the GitLab Archive does not “need” to generate packages, it is useful. The update repositories need to perform some package validation and sometimes insert metadata into the LSM files. However, the RBE is another story. The amount of automated processing that occurs to generate a “release” would probably stun anyone who has not used it. It is not simply just take these packages and stick them on some disk image. Creating the media is a very complex process. Involving dozens of different aspects ranging from package analysis to creating the runtime version of the installers. Even when running in non-verbose mode, many thousands of status messages are displayed during a release build. In verbose mode, this can be measured in gigabytes worth of text messages for the different actions performed. While the current version of the RBE (version 3) is no where near perfect, cumbersome to modify and getting rather long in the tooth, it is still a marvel of automation to watch in action. All this is to say, I don’t see us moving away from ZIP as the package archive file format anytime soon. :-) Jerome _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
