The UPX issue would be irrelevant if we didn't ship binaries at all. Hear me out. :)
Repeatedly, I have seen stressed here the importance of making sure all packages we ship are 100% open source. And rightfully so - I don't disagree with that. However, shipping binaries could be seen as a form of bloat because they are completely redundant when each package is supposed to have complete source code included. What better way to ensure that the packages we ship both currently and in the future meet this crucial goal than to prefer that a package contain only source code, which the installer then builds into a functioning binary at install time? Source code, as it is simply text, has an extremely high compression ratio, with the only tradeoff being a (perhaps slight?) increase in install time on some older machines. And are any FreeDOS apps truly so large that they couldn't be built fairly quickly on all but the very oldest install targets out there? In my mind - and I realize others may disagree - a one-time "penalty" of a longer install is a worthwhile trade-off to make for an overall much smaller package size. Doing this would facilitate another nicety, too: dynamic compilation tailored to the user's machine. Have a modern machine? Cool, the installer will compile you a 386+ binary with no additional hassle from the user's point of view. Got an older PC? No sweat, one 8086-compatible binary, coming right up! All from the same code the package already contains. The only notable exception to this principle which comes to mind would be applications which are written in commercial languages, such as Borland Pascal and the like, which we could not install temporarily to facilitate installation. Applications written in such a way would need to have binaries shipped in the traditional manner. But I wonder how many applications written in the FreeDOS-preferred combo of Watcom C and NASM could be converted to this paradigm, and how much space could in turn be saved. Sent with Proton Mail secure email. On Friday, November 29th, 2024 at 6:52 PM, Jim Hall via Freedos-devel <freedos-devel@lists.sourceforge.net> wrote: > On Mon, Nov 25, 2024 at 7:04 PM Eric Auer via Freedos-devel > freedos-devel@lists.sourceforge.net wrote: > > > Hi! There is a new DOjS release, as mentioned on > > > > https://sourceforge.net/p/freedos/news/ > > > > unfortunately, the freedos zip is 61 MB in size :-o > > > > https://ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/js/dojs/1.13.0/ > > > Yes, this is a very large source package because SuperIlu includes the > 3rd party source code required to build DOjS (which is a Good Thing -- > but that also means it's big). > > > This made me wonder how it could be made smaller. > > > > The TL;DR answer is: Use 7Z, not ZIP, for the sources to > > shrink the download, but you can also save dozens of MB > > in the installed size by using a small set of tricks. > > > > A simple way to shrink the installed package is UPX: > > [..] > > > Except that you can't. From my other email (see "FreeDOS 1.4"): the > UPX "authors also note in the license file that 'compressing a program > is a special form of linking with [the UPX] stub' under the GNU > General Public License." > > And: > > > How that affects UPX: that means that the license for a program we've > > included in FreeDOS was never evaluated by the FSF so you won't know > > if these are acceptable (GPL compatible) to compress with UPX. Per the > > "compressing a program is a special form of linking with [the UPX] > > stub" that means a program's license must be compatible with the GNU > > GPL to compress it ("link") with UPX. > > > > The DOjS license file lists the licenses for each of the components > included in DOjS. I just went through them again, and they all look > like they appear on the FSF's list of "GPL-compatible" licenses .. > except OpenSSL: > > > The OpenSSL toolkit stays under a double license, i.e. both the conditions > > of the OpenSSL License and the original SSLeay license apply to the > > toolkit. > > > And per the FSF's "compatible licenses" page, they consider the > OpenSSL license is not compatible with the GNU GPL: > https://www.gnu.org/licenses/license-list.en.html#OpenSSL > > My interpretation is that you cannot compress this with UPX, because > the UPX developers consider compressing to be a form of linking .. and > the FSF folks say the OpenSSL license is not compatible with GPL, so > you can't link with it. > > IANAL. Licenses are tricky. > > > > jh > > > _______________________________________________ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
