Hi Eric, > On Mar 9, 2019, at 8:19 AM, Eric Auer <[email protected]> wrote: > > > Hi Jerome, thanks for the insights :-)
Your welcome. > > So what is the combined size of all "programs which have settings > or high scores" which the user would like to be updated? Remember > that high scores in ramdisk are lost at reboot anyway and it is > possible that games just continue without error when they fail to > write to their highscore file. [0] IDK. That require a lot of work to figure out. Also, consider packages like my PGME (Program Manager Eternity). You install it on a hard drive and it updatable menus, pre-processed high-speed data caches, user settings, etc. But, it was designed with read-only operation in mind. Runs without caching, locks menus and settings, no temp files and etc. > >> running the entire OS in RAM has some advantages. > > That depends. As the combined uncompressed size of ALL packages > is more than 1 GB, many computers of DOS fans would be excluded > from being able to run a Live CD with more than 1 GB RAMDISK. Agreed. In part, it is the one of the beautiful things about LiveCD1. FreeDOS based dynamic memory allocation for RAMDISK, Technically, it “could” operate with 16mb or less of RAM (at present 24MB+). The more RAM available, the larger the RAM disk (possibly up to 2GB). Packages are made “Live” at boot in order of priority. So with sufficient memory, BASE + some of FULL and some common EXTRAS come “online” automatically. Additional packages, like games and GUIs could be installed into the RAM drive. Unfortunately, LiveCD2 uses SYSLINUX/MEMDISK to expand a compressed pre-made filesystem into RAM. It’s size is fixed at the build time of the media. > > Also, even in Linux it is very uncommon to install uncompressed > source trees of large numbers of packages. People are more likely > to only install a few source trees while recompiling few packages. > In particular for a Live CD, I see no need to uncompress any of > the source trees at boot. As long as the sources are provided in > the compressed packages on the read-only part of the CD. Agreed. My personal belief is 99.99% of users will never even look at any of the source files. However, breaking the packages into uncompressed binaries and compressed sources adds even more complexity to several aspects to the release media. First, the builder would need to know break the packages into those parts. The LiveCD would need to know which ones to run read-only and which on a RAM drive. The Installer would need to also be able to use expanded packages + source zips as well as complete packages to do a system install. All of that is far from impossible. But, I don’t feel its benefits are enough to justify the extra work. > > As far as I understand, one would still need more than 682 MB > of ramdisk space for a Live CD in that case? > How much would > that go down if only packages which have to write to their > install directory get installed to ramdisk? Good question. (see above [0]) > And how big would > the 3 largest packages in that ramdisk be? Which 3 packages? I don’t know off-hand. But, things like FPC & DJGPP are enormous. However, both of those (once configured) may be capable of running read-only. > > Would it be, for example, possible to make a Live CD which > runs on PC with 500 MB RAM, which could be used as 64 MB > for the apps, a few dozen MB for caches and the rest for > a large ramdisk for only those apps which need writeable > install directories, possibly excluding a few large ones? > > For a stretch goal, how about 250 MB RAM? I think Win9x PC > which could boot from CD even had less than 100 MB and they > would have the advantage to have DOS game compatible sound. Although the packages on the LiveCD1 are compressed, I think it is similar to what happens with that media at boot. In theory, with sufficient memory that media could boot and make ‘Live” every package. But, it would be time-consuming.(Although, it may still boot faster than Vista). > > Thanks :-) Eric Here are a couple additional things to consider… LiveCD1 boots a floppy and builds everything from scratch and requires very little space on the CD. All packages are compressed. LiveCD2 requires a hard disk image on the Live CD. The user can boot to install only or to the Live OS. At present, this requires compressed packages on the CD and uncompressed versions on the hard disk image (Yes, I am aware that the boot menu can pass some data to the loading OS. But, this creates even more complexity) As long as compressed versions of the packages are on the CD, the LiveCD1 & LiveCD2 could be combined as just boot options on the CD without difficulty. (But, I don’t like the idea of having more than one style of LiveCD booting. ) Future releases may (probably will) require much more of the CD capacity. Think PC-GEOS and associated programs at 100-200MB. That alone does not bode well for the longevity of LiveCD2. > >> This is just information for RC1. Not disk space requirements > >> Total packages: 298 > >> All packages (compressed) 532 MB > >> All packages (uncompressed) 1.1 GB (30,806 files, >> some source trees contain LFNs and remain compressed) > >> All packages (uncompressed binaries) 682 MB + 227 MB >> (compressed sources) = 909 MB (17,653 files + 1 massive source zip) > Jerome _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
