Hi, If I don’t mention removing or keeping something, I don’t have much of an opinion on it.
> Over time, FreeDOS has grown to include lots of interesting programs. The > FreeDOS 1.2 and 1.3RCx distributions are very big. > > As we look to the next FreeDOS 1.3 Release Candidate, I think we should > consider removing some packages from the FreeDOS distribution. We will definitely need to do that eventually. As thing are now, it will continue to grow and grow and at some point we will be forced to ship it as a DVD or 2 CD set. Although, a FreeDOS cd that only contains BASE and FULL along with an EXTRA packages CD may actually be better than including uninstalled packages as EXTRAS on the install media. > Base > Keep everything Drop or update SAMCFG. It is extremely outdated. > Archivers > Do we really need all of those archivers? For example, who needs Zoo these > days? My suggestions: Just a point to note. Although you did not mention Slicer, it provides the install functionality for the Floppy Only version. Those needs caused are/were not met by any other archiver. When compared to others (like tar), it’s design and operation are very different. However practically speaking, (other than the Floppy Only version), no one else really needs it. Nor will any one else probably ever use it. > Boot Tools > *I don't have any strong feelings here. What are your thoughts? I don’t think we need them. Tools Booting FreeDOS from ROM? I don’t think 99.9% of the people who download FreeDOS would miss them. Syslinux? We use it on some of the install media. But, do most end-users need it on the release? > Development This is the section with some of the biggest offenders. We are talking HUGE packages. FPC roughly 70mb, DJGPP, almost as big. IA-GCC, no slouch either. OWC, nothing to sneeze at. Drop those and reduce the ISO by roughly 160mb. Drop all of the development tools and probably cut the ISO in half. > Emulators > I don't think that these are useful to include in the full distribution. > These all fall in the general category of "games," anyway. I'd recommend we > eliminate the entire "Emulators" package group. Since most are running probably running FreeDOS in a virtual machine to support their old DOS games, I’d agree. Running emulators within emulators can get rather slow. ( Personally, I think I’ve only gone 3 emulators deep. VM running VMware server, running Linux, running qemu. Talk about slow... ). > Games > I generally feel that we can add and remove games in the FreeDOS distribution > on a whim. If a game is interesting and open source, we can include it. When > a game stops being interesting, or doesn't interest a lot of people, we can > remove it. > > *I really enjoy Wing and a few others. I don't have strong opinions on the > other games. What are your thoughts? I think we need more “good” games. > > Graphical Desktop > We added GUIs a long time ago when people were still doing active development > on OpenGEM, oZone, and Seal. If you've been part of the discussion for a long > time, you also remember we included a few other graphical menus and things > that have since fallen out of the distribution. I think it's time to look at > these GUIs too. My recommendations: > 1. PC-GEOS was released as open source software. I haven't followed it, but > last I checked, they weren't able to compile it (missing libraries, I think - > requires some rewrites?) If they can get this to compile, I think we can > include it. If they still can't compile it, then do not include it. > 2. Remove SEAL and oZone. These haven't been worked on for a long time, and > they are still incomplete > 3. Keep OpenGEM. It's not under active development, but it's currently pretty > solid, if plain looking PC-GEOS is pretty big. > > Networking > I don't run FreeDOS with a network, so I don't have any opinions on these > packages. What do you think? Use networking a lot. ETHERDFS is very useful for transferring files and doing development. ( Side note… Eventually, I really need to add networking support to FDIMPLES. It would take a lot of worry out of the “should we keep or drop” discussion. Since most users are running in a VM, they could just browse the repo and fetch what they want. Only so many hours in the day. :-( ) > Unix > The wiki page lists a few packages to remove based on duplicates or license > concerns. > 1. Move bz2, gzip, and tar from "Archivers" to "Unix" > 2. Move perl from "Devel" to “Unix" I don’t think we need to “ship” perl. Just a thought… We are DOS not Unix... > > Utilities > We have a mix of things in this package group. I think some of these were > interesting long ago, but probably aren't used anymore and can be deleted. My > recommendations: > 1. Keep aefdisk, ansimat, bootfix, callver, cdrcache, cdrom2ui clamav + > clamdb, cpied, cwsdpmi, dialog, dn2, dog, dos32a, dosutil, doszip + dzemm, > fdimples + fdisrc, fdnpkg, fdshield, fdtui, foxcalc, foxtype, gcdrom, gnuchcp > + gnufonts, hexcomp, localize, lptdrv, memteste, ntfs, pcisleep, pdtree, pg, > rcal, rdisk, search, setlock, shareext, shsufdrv, slowdown, spool, srdisk, > stamp, switchar, udvd2, uhdd, uide, unrtf, usbdos, utf8tocp, V8power, wcd, > wde, xdel, xfdisk, xkeyb, xmgr > 2. Remove b64, blwcbc, bmp2png, bsum, daa2iso, edict, fdshell, finddisk, > flashrom, gifsicle, hip, hiram, pgme, pngcrush, sqlite, terminal, topspin, > wptail, zdir, zerofill Most of these I don’t use and have no opinion. However, I see two on the hit list I’m in favor of keeping. (Partially, because I wrote them) So, I’ll tell you why I think they should stay. EDICT. At present, it creates images of diskettes. Similar to raread (image files are compatible). However, unlike raread it is far more persistent and always creates appropriate sized images. EDICT came into existence because I had a bunch of really old and neglected floppies sitting around. I couldn’t get Linux/Mac’s dd to image them. Nor was raread able to do it. Some of the diskettes were very borderline, throwing read errors at different places on each attempt. So, EDICT was born and was able to pull good images from those diskettes. There are future plans to stop, resume, switch drives or computers and generally improve data extraction. (Only so much time). Eventually, it will also get support to create disks from images. Operate on hard drives and partitions, etc. Once diskette creation is added, it could replace raread + rawrite at a fraction of their size. Did I mention it also has multi-language support and is pure assembler? PGME. Fully customizable, text mode multi-language program launching multi-menu system on steroids and some associated utilities. Add the couple (or hundreds) of games and/or programs to one or more menus, then add it to your autoexec or fdauto. Never see or type anything at the command prompt again. You can even use some of the KIOSK features to lock the menus and keep a user from exiting to a command prompt. :-) Jerome
_______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
