Hi Eric, I don’t know why I’m even responding to this forwarded “review”. But, I’ll assume the author will eventually see it. So, I’ll share some of my personal thoughts on some of it.
Most of it comes down to user preference. As is always the case, any decision will nearly always have some who disagrees and would have preferred another choice. Many people run FreeDOS on bare metal and their experience of installing the OS is extremely important. However, the overwhelming vast majority of users do not do that. They install into one of the virtual machine platforms. Therefore, their experience should be prioritized. > On Apr 29, 2021, at 9:15 PM, Eric Auer <[email protected]> wrote: > > > Hi, forwarding a verbose update of the review from Laaca on BTTR :-) > > My summary: Better LFN, faster disk I/O, problem of opening many small > files on CD being slow (how about using more CACHE, Jerome? Maybe even > with read-ahead or similar speed tricks?), problem of the Live CD not > having apps pre-installed (it has to unzip them first), problem of the > Live CD having too few apps available, lack of progress/status info, > lack of analysis of existing system structure before install, lack > (?) of ability to select install size (base, full etc.), lack of a > mechanism to dual-boot on FAT (you know my opinion about that), > lack of "what has been done where" summary log on the target drive, > wish that running "help" should initially display an introduction > or readme about what can be found where on the installed system, > lack of utilities for manual installs and repairs in the live cd, > wish for image viewer and mpxplay on live cd and default install, > wish to add image editors, wish for descript.ion or similar method > to let people know what zip contains what in the on-CD repository, > wish to have separate directories for apps which are multiple files? Do you want a better FreeDOS or a perfect one? Active development resources dedicated to improving the OS are very limited. A better version (RC4) is coming any day now. (possibly even today or tomorrow) If you want to wait for a perfect one that solves everyones problems, it will be a while. Like maybe the in the spring of 2150. In other words, never. > The original update from Laaca on BTTR is below. Regards, Eric > Source: https://www.bttr-software.de/forum/forum_entry.php?id=17804 > > Well, I wrote quite crititical review about FreeDOS 1.3rc. It was > reposted into FreeDOS user forum and was few times commented and it is > of course commented also here. > Just to be clear - I don't complain about DOS as such but specificaly > about FreeDOS 1.3rc and mainly about installer. > I will try to summarize my criticism into several categories: > 1) Missing DOS/FreeDOS features > 2) FreeDOS live system from CD > 3) FreeDOS installation > 4) Help system > 5) Packages > > ad 1) Here is not much to say. I miss some feature in modern DOS system > but it is not fault of the FreeDOS community. I would like to see a > better LFN driver, better disk read/write/seek performance (much worse > than f.e. under Win98). We do not have a good ASPI driver we do not have > a good task switcher and so on and so on. But again, this is not the > point of my criticism. That is understandable and I completely agree. There are many such projects that the original authors brought to a certain point but for whatever reason stopped. Perhaps they lost interest and moved on to other things. Since they are open source, it doesn’t really matter. Someone who is interested in improving the software could pick up where the original author left off. As a developer of DOS related software, even the author of the original “review” post can do this. We can always use more help improving things. > > ad 2) Why the booting starts with unzipping of many basic utilities like > ATTRIB.ZIP, FORMAT.ZIP, COMP.ZIP and so on. Why it just does not unzip > something like BASE.ZIP which would contain all this basic utilities? > You forgot how slow is the file seeking on the CD on the real hardware? > Sure, the contiuous read is fast on most of CD drives but seeking and > opening the large amount of small files is a pain. There actually many reasons the LiveCD Environment does things the way it does. But, I’ll stick to only some of the key reasons. I’ve run it several times on real hardware. Yes it is slower. But with the current list of packages it makes “active", it isn’t actually that bad. The Live Environment actually was designed to do some of that already. If you pay close attention to the status of the packages as they are brought online, you will see a couple “skipped.” That status is displayed for packages that have already been made active by other means. Earlier versions of the LiveCD had many more “skipped” packages. During the startup process, an entire group was done by extracting a single zip. This has several issues. First, the amount of RAM available varies greatly making it an all or nothing prospect. Second, unzip requires DMPI and wants HD swap. Unless the binary is somehow modified at boot, it will complain about no C drive swap. Also with no swap and limited RAM constraints, it is potential point of failure. Third, for most users, there is not appreciable difference in speed between one big zip and multiple smaller ones. Yes, on real hardware it is slower. Fourth, There is no custom unzip that displays a progress bar. Sitting there and just watching a blinking cursor without any feedback for is egregiously painful. It makes the user feel like the system having disk read problems or has hung. On the other hand, watching zip extract files at boot is kinda ugly and off-putting. Fifth, In RC3 the disc was nearly full. To install the OS, the packages are needed. Then depending on hardware capabilities (ie low RAM), the Live Environment needed to have a Pre-installed version present on the disc to fall back on. Add to that another large zip for slightly faster extraction, oops...out of space. > And after this we have only very bare system with only few > applications/utilities. It is much worse than very ancient Live CD of > FreeDOS 0.9a which I have and occasionaly use (although it is also a > .BAT files complicated mess). Only the FreeDOS BASE and a couple other popular utilities are made active by default. But, this is a working Live OS. Assuming you have enough RAM, just unzip or install whatever else you want or need. Automatically bringing additional packages online that few people use at boot wastes most users time. That being said, RC4 is much slimmer than RC3. Since the Live Environment can fall back on the CD when there is insufficient RAM to bring all the default packages online, it is possible to have additional ones pre-extracted to CD. Perhaps more software will be pre-extracted on the CD and not made “active” on a RAM disk in 1.3-FINAL. However, this has some trade-offs. You really can’t remove the CD if the OS is going to be looking for stuff on it. Some programs cannot be run on a read-only filesystem. Testing would need to be done to verify any pre-extracted versions. > [..] > In case when some existing disk partitions are present it should offer > the installation of boot manager (preferably BootMGR by BTTR software). Interesting suggestion. > FDisk should be replaced by some better alternative. User preference. Long time DOS users may not like FDISK. But, they are familiar with it and know how to use it. They may not appreciate changing it out for a more “user friendly” partitioner they have never seen and must figure out. On the other hand, someone who is new to DOS would be more comfortable with an easier to use partitioning tool. Regardless, RC4 does a much better job than RC3 to auto partition blank hard disks. On a clean system or VM, most users will no longer even see FDISK. > Also - the user should be prompted to choose a variant of installation > (very basic, extended, full) and also a list of desired applications via > a expandable list for custom modifications of the options above. The installer has advanced mode with more customization of install settings. Including the ability to pick and choose what packages are installed. The easiest way to run in advanced mode is to exit the installer and run “setup adv”. But, you really don’t even need to quit the installer. At any point the installer is waiting for user input, you can press CTRL+C to bring up a menu to switch in-to or out-of advanced mode at that point. Pressing CTRL+C at other times can terminate the install. For example, you only want to customize the installed packages… Just run the installer normally. Then when you reach the “pick type of install BASE or FULL” screen, press CTRL+C, choose “switch to advanced mode”. You’ll now see “BASE and FULL” and additional choices for “CUSTOM”. The installer is modular and flexible. In fact, if someone is motivated enough, they can create custom plug-ins for it to ask additional questions and even preform completely new tasks during installation. Although, I must admit that I really need to get around to documenting that kind of stuff. Combine that with the new RBE (Release Build Environment 3rd Edition) and nearly anyone can create their own custom OS based on FreeDOS. > I like the point that current installer creates a multi configuration > FDCONFIG.SYS. It is important because on the tested notebook (Dell > Latitude 610) the first two options did not work for me and only the > other options were working. In addition to that, depending on a couple other factors like specific VMs or CPU support, it may install a completely different AUTOEXEC.BAT or CONFIG.SYS. > And finally - after the installation must be displayed (and also saved > into some protocol file) some summarization of whole process. There really is no way to store a log of “the whole process”. Anything prior to having a formatted hard disk will be lost. Some logging may eventually come to the installer. It would assist in troubleshooting install problems. But, there isn’t much point in logging everything that happens. It would be a good deal of overhead without much benefit. For the most part, once it starts installing packages, it tells you what it is doing. The exact details aren’t very important to most users. > ad 4) Help system must be totaly reworked. After writing "help" should > be displayed some overview like: > * FreeDOS core files and installed into C:\ and C:\FDOS\BIN. Other > available disks are: ..... > * For your convience are prepared these BAT scripts > - for filemanager write "dz" > - for system info write "sysinfo" > - for more info about applications in C:\EDITORS write "help editors" > - for more info about applications in C:\SOUND\ write "help sound" > ... > - for more info about DOS core utils and DOS batch language write "help dos” RC4 is using a different help system. What you suggest is not a bad idea. Just need to find someone with the time and motivation to make such additions. What I’d personally like to see is a completely different help system than that used by RC3 or RC4. Something that is far more dynamic. For example, if a user installs a new package it automatically integrates into help. Remove that package, it removes its help. Both of the current systems are just big static help documents. You’ll see many things in them that aren’t installed by default or even “shipped” with FreeDOS anymore. > ad 5) In harddisk mode and live CD mode must be easily available > utilities for system informations, disk/file recovery utilities, BIOS > tools and so on. Because it is still a traditional playfield for DOS > systems. If I understand what you trying to say here… You can easily install additional software to the HD. And with sufficient RAM on supported hardware, you can do the same to the Live Environment. > Also some picture viewer and converter should be available even in the > basic installations. Mpxplay also could be also in basic installations. Using programs like FDIMPLES it is not difficult to install such things afterwards. > It is also wise to have a special C:\KOMP\ directory (listed in PATH > variable) where are all file archivers like ZIPINFO, UNRAR, 7ZIP,…. RC4 has done a lot to clean up a bunch of install path related issues. But more work can still be done to make it even better. > I like the quite rich \UTIL\ directory on the installation CD but it > must be somehow sorted. Idealy combined with something like DESCRIPT.ION > files. You can use FDIMPLES to browse packages. However, you can also use type to view package metadata from the command line. All packages on the CD have a metadata file under \packages\pkg-info. For example, you are in the games dir on the cd and want to know more about senet.zip. Simply issue the command “type ..\pkg-info\senet.lsm” > There must be some discussion which programs are missing (some painting > programs like GrafX, PictView, SEA?...). And maybe some programs could > be removed from distro? (B64?) Packages that “ship” on the media are frequently reviewed. More could be added or removed in future versions. > Very controversal point is the mania to install all applications into > universal directories like \BIN\, \APPINFO\ etc. > If everything will be installed into C:\BIN, terrible mess will happen Yes. Far to many things get installed into %DOSDIR%\BIN. Jerome _______________________________________________ Freedos-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-user
