On Sat, Oct 24, 2020 at 6:06 PM Jerome Shidel <[email protected]> wrote:
> 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. > Yeah, I'm trying to avoid turning FreeDOS into a multi-CD software set. It's DOS. It should be small. :-) > > 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. > > As we shoot for FreeDOS 1.3, I want to get away from the "Extras" thing. When people do a "Full" install of FreeDOS 1.3, they really should get *everything* that's available in the distribution. There shouldn't be "extras" that they can also install afterwards. >From the user perspective, "doing a 'Full' install" means "install everything." So it's confusing to have "extras" that they could install via FDIMPLES afterwards. If a package isn't really necessary (i.e. not used by many people, etc) then I think it shouldn't be in the FreeDOS 1.3 distribution. They can get it from the Files Archive at ibiblio and install it separately if they like to. *Base* > Keep everything > > > Drop or update SAMCFG. It is extremely outdated. > Missed that one. Thanks. > > *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. > Good point. I should clarify: there may be tools listed on my "remove" lists that are used during the install process. In that case, "remove" doesn't mean "don't use it" but rather "this doesn't need to be installed as part of the Full install." It doesn't need a separate package. That said, those tools that are used during the install process need to have source code available for them somewhere, preferably on the install CD. (Doesn't need to be included on the install boot floppy, since that's limited space. But "from the same place" in the GNU GPL could refer to the install CD - in my opinion.) > > *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? > Agree. (See also my point above [in this reply] about tools in the install process.) > > *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. > I'd assumed the compilers and assemblers were quite big, but I didn't do the math. Wow. > *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. > > Agree! I also like DrMind - and of course, Simple Senet. :-) I think we should also watch the DOS Games Jam and see what interesting DOS games come out of that. (I don't think it literally has to be a "DOS" game to be part of the DOS Games Jam - it just has to feel part of the DOS era. But I'd be interested in actual DOS games. The Spring Jam winner was Post-Apocalyptic Petra, which was a DOS game.) > > *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. > > Anyone know if they can fully compile PC-GEOS yet? I tried looking on their GitHub, but I didn't see a status on that. Seems like the "how to compile" instructions are still incomplete? > *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... > > Another thought: how outdated is this DOS version of perl? I know it's Perl 5.8.8 and the current version is 5.32.x. But how "far apart" are those two versions? (It's been years since I intentionally wrote a perl script, so I don't know.) > > *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? > If it makes sense to include EDICT, then it can stay. Just putting out ideas for people to respond to. :-) > > 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. > > I haven't used PGME. Is it similar to the text-mode DOS shell from MS-DOS 4? Jim
_______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
