Hi Eric, > On Jan 23, 2026, at 6:58 AM, Eric Auer via Freedos-devel > <[email protected]> wrote: > > > Hi Jerome and everybody, thanks for the verbose answers! > > *Download chances* > > First, could freedos.org/download/ switch to HTTP links > to Ibiblio when viewed as HTTP://freedos.org/download/ ?
There are a number of reasons why I do not think that is the proper solution. The most important of those is that the user may want to have a secure connection. It would be bad to try and force them into HTTP. Alternatively, it is rather easy to determine if the user Is viewing a page over HTTP or HTTPS. Then to simply provide any external site links with the same protocol. Then, no-one is forced into either a HTTP or a HTTPS connection. > > Second, probably even better: Could we list alternate > download servers on freedos.org? Then we could simply > ALWAYS list both HTTPS and HTTP for Ibiblio, plus your > server if it has enough bandwidth. While my server is very fast with a lot of bandwidth, I don’t really want to have it listed as an official download mirror for the OS on the FreeDOS website for a couple reasons. The main reason being, providing that server comes out of my pocket. I do not want a massive bill when a version of FreeDOS is released and thousands or tens of thousands of people decide to use my site to fetch the new version because the official server is a little slow. I have no problem with subscribers to the mailing lists fetching them from my server. Even pulling down all the files from a release by a few handful of individuals has a negligible impact on my server. > [..] > *Package and kernel updates* > > He also wrote that he feels with me and that our distro > could update the browsers for DOS. And antivirus, but I > know that ClamAV has become extremely large these days. > > According to Fritz, our KERNEL (or FREECOM?) has a bug > breaking the polarity of IF EXIST in batches, fixed by > Bernd B more than a year ago. As Tom had a problem with > some of the patches, any update somehow got stuck then? > There also is some pending fix related to CDROM support > and one related to LABEL, probably from the same period. There is a whole list of fixed bugs for both the Kernel and FreeCOM. While I don’t know which specific bug Fritz is referring, I know I personally submitted an IF EXIST bug report and demonstration. Also, a bunch of other FreeCOM bugs and help discover a some kernel bugs as well. See: https://fd.lod.bz/redist/testing/devNUL/result0.htm <https://fd.lod.bz/redist/testing/devNUL/result0.htm> https://fd.lod.bz/redist/testing/devNUL/result1.htm <https://fd.lod.bz/redist/testing/devNUL/result1.htm> > [..] > As mentioned, I was lucky and the generic "make bootable > USB thingy" tool in Linux did the trick, but people have > to KNOW that they have to use that kind of tool. On macOS, Linux, Unix, etc. the simplest and most reliable way to put the LiteUSB or FullUSB onto a flash drive is to simply use ‘dd’. It is what I use. Something akin to: sudo dd if=FullUSB.img of=/dev/sde I don’t even bother with block sizes or anything. > [..] > So we should probably recommend to use only the USB > images, not CD, when people plan to boot from USB? Absolutely. While I think I recall someone saying they successfully used one of the CD images, I do not recall what was involved to the tools required. From most of the comments I have heard, trying to use the various utilities to put the ISOs onto a flash drive 99.9% of the time does not work. Also, some of those utilities try to do something fancy and manage to make the USB images not bootable as well. It would be great to have a list and instruction guide on which ones work and don’t work for creating boot media. I’m not a Windows user. So, I have now idea on how to create them on that platform. As for macOS, the built-in stuff works fine. As for Linux, I don’t really burn discs. > I assume the same images could be used on SD cards? > If a BIOS only uses USB1 speed, SD might be faster. Yup. They are just hard disk images. Actually, if you have a 8GB USB stick or SD card, you can write the Lite/FullUSB image to it. Boot the Flash media and use FDISK to create another partition. Then, use the installer to install to that partition. Fun fact… My little ACER netbook works pretty good with DOS. It can even boot it from a USB or it’s internal SDHC card reader. I have even booted from one and installed on the other. It has been a while so I don’t recall if I booted USB or SD. But, it was a fun experiment. > [..] > I cannot search the mailing list on a netbook which > does not even have UNZIP, Jerome. And as normal guy > who just wants to fiddle around with DOS, I might > not even KNOW that a mailing list ever existed ;-) Very true. That’s why I said I posted about doing it. But, it is not documented anywhere. I don’t even think there is a YouTube video to demonstrate it. There are videos by users which have done it. But, those are all long and fairly complicated methods. > [..] > Usable FDIMPLES on DOS hardware: > [..] > Maybe > you could pre-load some basic data into RAM here? Actually, it already does that. But, there is a lot of that. Plus, a bunch of additional files and data it must correlate. > >> At present, while FDIMPLES can run on just about anything, >> It gets painfully slow on anything under a 686. > > I would accept it to be slow on PC XT, but if it > is too slow to bother using it on a 386, 486 or > Pentium, then a floppy distro seems pointless? > And: That netbook had WinXP. It is not DOS era. Then, that was most likely an I/O bottleneck and not FDIMPLES just being slow. (More below) One thing you can do which will likely help a lot: FDIMPLES /nofiles This turns of loading and displaying the list of files Inside packages. While this data is pre-extracted by the RBE, it still consumes a lot of memory and can take a while to load. While FDIMPLES does check to see if you navigated away from the current item and will abort loading that data, it is not multi-tasked and the system can be very sluggish. > >> I could improve this a lot, but my focus is on other things... > > Can you give others a hint on where bottlenecks are, > in case somebody wants to suggest FDIMPLES patches? The primary I/O bottlenecks are the OS and not in FDIMPLES itself. Since you were using an XP era machine, the slowness was likely caused by poor USB I/O performance. This is not to say that FDIMPLES cannot be improved. The opposite is true. There are many things which can be done to make it faster and more responsive on slower systems. However, a lot of that will need to wait until the RBE4 is ready and the next version of FDIMPLES. But, there are some things that can be done in the current version to make it more responsive. > > It is nice to use FDIMPLES to know which packages > exist and make a selection. It does not install, > though, which I initially had not realized, so Mostly, it is a UI that interacts with a package manager to install, remove or update packages. At this time, you must have FDINST installed and properly configured in order to use FDIMPLES to install or remove packages. > once more: Mentioning a README about where I have > ended up when aborting the "delete harddisk" part > of the installer would have been very helpful. > >> A future version of FDIMPLES is likely to have things like >> mouse support, online connectivity and ... repositories. > > You already have FDNPKG for online repositories, no? :-) Not really. And definitely not how I want it to be done. Plus, FDNPKG has been abandoned by its developer. > [..] > *Documentation needed* Very much so. :-) Jerome
_______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
