Hi, > On Mar 3, 2022, at 1:13 AM, Jim Hall <jh...@freedos.org> wrote: > > On Sun, Feb 20, 2022 at 4:16 PM Jim Hall <jh...@freedos.org> wrote: > [..] >> I'm sure we'll want to discuss "1.4" or "2.0" or whatever version >> comes after 1.3. (I can start a new conversation next week to talk >> about that.) > > > Now that FreeDOS 1.3 has been out for a little while, I wanted to > start thinking about what comes next. Let's use this thread to discuss > it. > > What would you like to see changed or added (or removed) in the next > distribution? > > My top three ideas: > > > 1. Move to a "rolling release" > > It's taken several years* to release a new version of FreeDOS. Yes, > DOS is pretty stable, so we don't need a new distribution very often > anyway. But for many folks, the new official distribution is the only > way they get the updated tools (most people don't download individual > tools to update a running FreeDOS system.) > > *Not counting Release Candidates, the last few releases were: > 1.0 (2006) - 1.1 (2012) - 1.2 (2016) - 1.3 (2022) > > I think it would be interesting to set up a system that builds a new > FreeDOS "test" distribution whenever we update packages on the FreeDOS > Files Archive at Ibiblio. That doesn't need to be a new build every > night, but maybe every month.
Since the RBE (Release Build Environment) is fully automated, the is nothing prevent throwing a copy into a virtual machine that can run once a week week, month, quarterly or whenever. Just a side note… The previous version of the RBE used would pull down a copy of the packages from the Official Software Repo on ibibio. However with the improvements to package staging, update and deployment, it makes more sense to pull them from the GitLab archive. This also permits making test branches of projects that can be used during the release build process. Such changes are temporary and can be permanently included or discarded prior to committing those packages to the Software Repository on ibiblio. This can include updates to metadata, translations, configuration or any other part of a package and is great for “testing” things before fully committing to a change. > > I think these distributions would come in only two versions: a "full" > FreeDOS that looks like the LiveCD (see also #3 below) and a "mini" > FreeDOS that contains just the FreeDOS "Base" packages, without source > code. (The "mini" should be very tiny, and basically the same as a > "floppy" FreeDOS install .. I guess "floppy" is a third distro > version, but I think it could be derived from the "mini.”) The RBE can be told to only bother making specific skews. LiveCD. No problem. Mini CD? Well, wouldn’t take much to add that. Floppy Edition. No problem. However, you cannot really derive the Floppy Edition from the the install process used by the LiveCD. The installers are completely different. Although, the end result of an install is more or less the same on most VM’s and Hardware. The work in completely different ways, using different process and methods and are not compatible with each other. The process used by the LiveCD (FDI) requires a 386+ and cannot be split across floppy diskettes. The Floppy Edition (FDI-x86) only requires an 8088/86 and is made to span diskettes. So practically speaking. That leaves three choices for a MiniCD. 1) Since it is on CD, requiring a 386+ is not a problem. It can use FDI (the primary installer). FDI is already capable of having a source media that only contains a BASE package set. (no FULL set). This can if desired include extra packages that don’t get installed. Or, just BASE and nothing else. It will automatically, limit the package selection choices to just (BASE and BASE w/sources). 2) Create a MiniCD based on the Floppy Edition using the FDI-x86 installer. Basically, create an ISO of the “Install using floppy edition” that exists on the LiveCD. That ISO would probably not have a menu. Just boot straight to the FE installer. 3) Similar to 2, except instead of using the HD image, create a modified version that boots a floppy image with CD support and install from the CD portion. This is similar to booting into the Live Environment, going to the FDI_X86 subdirectory on the CD and running setup. All that being said. I don’t think we need to worry about doing a MiniCD. I think it is probably to small a subset of users to worry about making for every “test” release. The Floppy Edition is very flexible and they could just use it. Either from the LiveCD, the Floppy Edition Diskettes or even copy it to a subdirectory on there hard drive and run it from there. I think that doing interval LiveCD + FloppyEdition should be sufficient. If you want to keep each around, they will use a lot of disk space as it is. We may want to consider only just releasing the LiveCD at intervals. My guess is that probably what 99% of users want. Although, there may be a large portion who want the BonusCD. This reminds me of something that most probably forget about. Whenever there have been packages updated on the Online Software Repository at ibiblio (and my personal one as well), the Repo will build a new ISO of all packages once per day. This ISO is bootable and was able to install FreeDOS. It is currently using the installer from FreeDOS 1.2 with a different theme (green) and slight variation in settings. However, there have been so many directory and package changes, I need to update the installer there. Without testing, I’m fairly sure it probably won’t work right now. This ISO is also huge and may require a DVD. But, it is there and could substitute for doing interval BonusCD releases. The RepoCD is different than the other CDs. It is a snapshot of all the latest versions of packages in the Repository. It also includes HTML files for browsing. It is the Repo on CD/DVD. > > Folks can try out the new "test" distribution and always be on the > latest version. When things are stable, we can choose a "snapshot" > that works well, and make that the next official distribution. That > might happen on some interval (every 6 months? 12 months?). We could do 6 months. But, I’m not sure if we have enough updates to warrant a 6 or 12 month schedule. I guess we could decide that later. We could initially just wait until we feel “that’s plenty” for a new release. Then try to stick to that interval wether that is 6, 12, 24 months or every February 29th. > 2. Simplify FreeDOS > > The FreeDOS distribution has grown. We've added a bunch of packages > over the years, and FreeDOS has become quite large. We added the > BonusCD (634MB) because we couldn't fit everything on the LiveCD > (401MB). Yup, and if at some time we include the open source PC/GEOS add another 80-100MB. That would require Multiple BonusCD’s (which the RBE can do already). Or, dropping things. > Over time, we added some things because they were useful at the time, > but we added others because they were a neat thing to have. Are these > useful in 2022? I think we should re-evaluate what's in FreeDOS, and > trim down what we include. DOS should not be that big. > > For example: I think the Unix-like utilities should go. I thought the > Unix-like tools might generate interest from new developers, but I > think the Unix-like tools just confuse things and make FreeDOS look > like a "mini Linux." Let's just be DOS. > > I think we can also remove some packages from Editors, Archivers, and > Utilities. We might remove all of the Graphical Desktops, since these > are of limited usefulness and not maintained anyway. > > What packages to keep and remove is probably a larger discussion that > we could move into a dedicated thread. I don’t know. Since I don’t use most of that other stuff, I don’t really care. But, I don’t think end-users will go for removing things. As a general rule, people tend to get really upset when you take away something they want provided. I think we might be ok if we move a lot of things onto the “BonusCD(s)” and don’t "remove them” per se. A good example is FDNET. “out of the box” it basically only works in VirtualBox and VMware. When we pulled it do to licensing confusion, it took a little while but the complaints were numerous and quite upset. If we start taking away user’s favorite text editors, games, GUIs, etc. , we may get hammered with complaints. > > The full list of packages (LiveCD and BonusCD) is in the FreeDOS 1.3 > report document: > https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.3/official/report.html > > > 3. Make LiveCD the default > > We know from the 2021 user survey** that a lot of people run FreeDOS > in a virtual machine. Why require an "installation" if you just want > to boot FreeDOS and run it in a VM? I think we could set up the LiveCD > so that you can just boot it and run FreeDOS. > > **Here's the user survey: > http://wiki.freedos.org/wiki/index.php/Survey/2021 > > Imagine setting up a new VM with FreeDOS. You download the LiveCD, > define a new VM, point the VM at the LiveCD (or the "mini" FreeDOS > CD), and boot. Now you're running FreeDOS. You don't have to *install* > to a hard drive to run FreeDOS; run everything from the LiveCD. Maybe. However, if it is strictly a Live Environment, I don’t think a MiniCD would be much use to most users. > If you want workspace to edit files, set up a virtual disk in your VM, > then use FDISK and FORMAT so you can use it. You don't have to install > it to the disk; you can just use the disk for files. But I think we > should still have some kind of "install" available for those who > really do want to install FreeDOS to the hard drive, such as folks who > want to run on real hardware. If we move to a Rolling Release, along with setup/install. We should probable include a simpler, upgrade. One that will just update the packages, command, kernel, etc. Technically, FDI will do it. But, a simpler upgrade processes would probably be more user friendly compared to needing to navigate the installer screens. Just a simple “are you sure you want to upgrade (y/n)”, then do it. On a side note, FDIMPLES can mostly do it already. Either when launched through a option or at runtime through a keypress, it can select to upgrade packages that are newer than those installed. This works well for most stuff (command/kernel require a couple more steps) using the RepoCD or other media that contains newer packages than previously installed. > Using the LiveCD this way probably also means looking closely at the > packages we include. We'd need to be able to run everything from that > read-only media, so programs that require updating files in their > "home" directory will not work here. Makes sense. It will need a very close look. Many programs will be fine. Some may surprise us with not being compatible. While others may surprise you by working. For example, PGME can be configured to run from read-only media, with simultaneous locked (read-only) and unlocked menus scattered across different drives (some writeable, some not). The same may be the case for other complex programs. However, we may discover a popular game fails to launch because it cannot open a resource in r/w mode even though it only reads those files. It will require a lot of testing. :-) > I think all of these changes suggest the next FreeDOS should be > "FreeDOS 2.0" instead of something like "1.4." It's a big change to > how we set up FreeDOS in the 1.x series, so it deserves a bump up to > "2.0.” Possibly. > > What do you think? > > > Jim Jerome _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
