On Sun, Oct 23, 2022 at 1:45 PM Jerome Shidel <jer...@shidel.net> wrote: > > Although there has not been a lot of feed back on what to do with the > excessively (nearly 1GB) BonusCD in T2210, I think the majority of > feedback has been in favor of splitting off the development packages > from the BonusCD on to their own DevelCD. > > And, we should do this instead of dropping packages for several > reasons. The main reason is for the convenience of users who may > be on older hardware or without network support. Those users might > experience some difficulty getting all of the programs they need into > their “DOS” machine. > > It has also been suggested to provide a “Developer Oriented” release > of FreeDOS. One that is specifically geared towards DOS development. > > Another suggestion has been to just slim down FreeDOS to basic > DOS. Leaving it up to the user to find, download and install what > they want after the OS has been installed. >[..]
I like the idea of having "developer" stuff on the BonusCD, and keeping the "user" stuff on the first CD. That's a logical way to divide it, and it's easy to explain. We could also put the "editor" packages on the BonusCD as well. I am also in favor of removing some old packages from the FreeDOS distribution. I think we have a lot of packages there that have minimal value. I think the graphical desktops are an obvious place to start. OpenGEM is the most stable, and thanks to Liam for pointing out the paths problem. But oZone and SEAL are incomplete and broken. When I recorded the video for oZone <https://www.youtube.com/watch?v=nw-Fx5k7Smg> on our YouTube channel, I had to avoid some broken parts of oZone. I know SEAL is similarly incomplete. I don't think oZone and SEAL are adding any value to FreeDOS. I vote we remove them. Also, the value of any graphical desktop is apps that support it. And neither SEAL nor oZone have much in the way of apps. OpenGEM has a stable API where interested developers could write new OpenGEM apps - although this has never happened as far as I remember, and we've included OpenGEM in FreeDOS for a long time. But maybe OpenGEM stays for now. I'm also in favor of changing out some of the games. We've discussed here before (I think around the time of FreeDOS 1.1) that DOS games were not "core" to FreeDOS, so we could change those out freely. I'd look for fun games that run well on the most popular platforms (on real hardware, and on VirtualBox). It's okay to require config tweaks to get a game to work well on VirtualBox or real hardware - such is the way with all classic DOS games. But if a game is known to *not* work at all on VirtualBox (for example) I recommend we discuss removing it. I think we have other packages in Util that could also be removed without anyone noticing, but I would like to go through the package list more closely before I comment on that. > I’m unsure of the best solution to the problem. > > I don’t think providing a Developer Oriented skew of the OS is a good > idea. With the LegacyCD, LiveCD, LiteUSB, FullUSB and Floppy Edition, > I think we provide to many OS skews already. Since we want to support > a wide range of DOS hardware, we really need to keep the Floppy and > CD version around. > > We could probably drop the LiteUSB for several reasons. I think > it’s direct usage is very limited and most users probably opt for > the FullUSB version. Also, every “how-to” and video I’ve seen > online that shows how to create a bootable USB stick for FreeDOS uses > the LiveCD to create it. However, occasionally, I do see questions on > how to write one of the USB media to a flash drive. > > We could also probably drop the LegacyCD as well. There is only a very > limited range of early hardware that cannot boot the LiveCD. But, > it can boot the LegacyCD. That hardware will most likely also have > a floppy drive. If their CD drive is supported by the drivers, they > could boot using the “Floppy Boot Image” included in the download > zip. Once that is done, they can install from CD. I keep meaning to test Rufus <https://rufus.ie/en/> to see if it will successfully create a bootable USB flash drive based on the FreeDOS LiveCD. If it does, I don't think we need to keep either the FullUSB or LiteUSB. Has anyone here used Rufus to create a bootable USB flash drive from the LiveCD image? > So where does that leave us? I think there are at least two practical > solutions at present. > > First, split off all development related packages that are on the > BonusCD onto a new DevelCD. This would require very little work. The > Release Build Environment (RBE) is already capable of creating multiple > extra package discs images. However, I will probably want to add some > functionality to use specific labels for them. At present, it would > generate BonusCD0 and BonusCD1. It will not be hard to update the RBE > to use custom labels for the discs. This first solution implies we may > eventually have a GamesCD, UtilsCD and others as well. If we go down > this path, perhaps we should start separating some other packages on > to their own media as well. > > The second option is to go big. On this path, we could do away with the > BonusCD. We could keep the LiveCD as-is. But, we could also provide > a LiveDVD. I do kind of like the idea of providing as much quality > software as we can on a single disc. On this path we may not need the > USB versions. Most users tend to use programs like Rufus to create > bootable USB drives from the LiveCD. > > I don’t know if there is a good solution to this issue. But, I am > certain we can not provide a "950Mb BonusCD.” > My thoughts: DOS was never a big operating system, so I'm not a fan of making FreeDOS bigger. Maybe others disagree. I like splitting the development packages into the BonusCD. But I'd suggest we keep the distribution to two CD images: "LiveCD" and "BonusCD." We shouldn't need to go to a third CD image. And we shouldn't need to go to a DVD image. Jim _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
