On Mon, Sep 23, 2024 at 7:59 PM Jerome Shidel via Freedos-devel
<freedos-devel@lists.sourceforge.net> wrote:
>
> Hi,
>
> Regarding moving V8POWER, FDIMPLES and a few others into a new package group…
>
> That’s fine :-) But, I don’t think the group should be called install or
> anything like that. For one, it greatly limits what can/should be placed in
> that group. Plus… Although V8 is critical to making the installer and many
> other things function as needed, it really does not belong in a INSTALL group.
>
> I think something like Add-ons, Essentials, Enhancements, CoreTools, Extras
> or some other generic group name would be better. It could show that even
> though not a BASE package, they are important. It also allows other packages
> to be placed in that group without restricting them to a specific type.
>
Sure. I am not picky on the name. I suggested something just to have
something, but the group that collects these could be called whatever
makes sense.
> > On Sep 23, 2024, at 6:18 PM, Jim Hall via Freedos-devel
> > <freedos-devel@lists.sourceforge.net> wrote:
> >
> > Summing up the discussion so far:
> >
> > Michael makes a good point about keeping Net in LiveCD, but I'd
> > recommend the "live" part on the CD (where you can boot into FreeDOS
> > without installing) should not try to load networking by default in
> > FDAUTO. This could cause problems and a bunch of "help me" emails if
> > the hardware isn't supported - but install the Net stuff in the "live"
> > part and let the user run them if they want/need it. For example, if I
> > wanted to run FreeDOS with networking in a virtual machine, I'd
> > probably set up the virtual machine with the LiveCD ISO as the CD and
> > a partitioned & formatted disk image as the hard disk .. then I'd boot
> > right into the LiveCD .. and to run network stuff, I'd probably create
> > a NET.BAT on the hard disk that was set up to support my virtual
> > machine's network.
>
> As a reminder…
>
> The default settings for FDNET (as on the LiveCD and installed OS) only
> attempts to bring up network support on known good virtual platforms. That is
> VMware, VirtualBox and some variants of DOSBox.
>
> When booting other virtual environments or real hardware, FDNET does not
> attempt to start any of the networking drivers. It simple displays a message
> that “networking is not supported on real hardware at this time” and exits.
>
> The user must either provide their own method of initialization or
> specifically tell FDNET to attempt to start networking anyway using the “try”
> command line option.
>
> Also when a user provides their own packet driver, they can create a
> FDNETPD.BAT file. That file will be automatically used to load the packet
> driver. It also eliminates the need to “try” and force FDNET to start on
> systems that are not known to be supported.
>
Ah, I didn't remember that - I don't usually set up networking on my
virtual machine because I don't need it. Sounds like the current
settings in FDNET would avoid problems anyway. So that seems like it's
already solved. :-)
> >
> > And I agree with Willi and Louis and others to include sbemu and
> > vsbhda (both in Drivers).
>
> Not sure about including them on the LiveCD.
>
> Most users will be booting a virtual platform and don’t need them.
>
> For those on real hardware, they will need to know they exist and how to
> configure them to work properly.
>
> But, if they are going to be in the driver group and we are including that
> group on the CD, then they should be there.
>
> As Jim mentioned, it is a good idea to have all or none of a group on the
> disc. Having some here and some there can be confusing for users.
>
> Although it is common for tools and such to be present on Install Media that
> do not get installed automatically (see numerous Windows releases), it would
> be better that a Full install did install everything on the CD.
>
I think there's some value in putting sbemu and vsbhda on the install
CD. We've heard from people here and on Facebook that they've booted
the install CD on Pentium or some other "newer than SB16" machine.
Providing these in Drivers would make it easy to get sound from DOS
games with AC97.
And I recall Drivers just installs the drivers so they are available
to the user, I don't think it actually loads them by default. So
installing them just makes them available.
> >
> > I also appreciate Willi's comments about using HTML Help, and not AMB
> > Help. But since no one else is commenting on that, maybe we should
> > "table" that discussion until we have a test release that has the
> > "balanced" packages. Then we can come back to focus on "HTML Help vs
> > AMB Help."
> >
> > Same for "adding FLTK stuff" or "dropping Clam AV." Let's make a test
> > release that has the "balanced" packages, then come back to the
> > discussion about dropping (Clam) or adding (FLTK) any other packages.
> > But I think sbemu and vsbhda are pretty obvious to include now, this
> > isn't the first time folks have discussed adding sbemu and vsbhda.
> >
> >
> > I'm not convinced to move Edit or the other stuff to the LiveCD, I
> > think it's best to think about what most people will want to use when
> > they boot FreeDOS (LiveCD) and what developers will want to use
> > (BonusCD) so my updated proposal is this:
> >
> > LiveCD should be Base + Apps (but not Sqlite) + Drivers (with sbemu
> > and vsbhda) + Games + Net. And Zip + Unzip (probably collected with
> > V8Power and Pkgtools)
>
> If the new group uses a generic name, Un/Zip could be moved there as well.
>
> Be advised, moving or changing a project to a different group name is a
> multiple step process. For starters, involves relocating it to a different
> group on GitLab. Making the changes in several package lists used by the RBE
> to create the media. Also, the download repositories should reflect the same
> changes which includes updating configuration files used by FDNPKG.
>
> None of that is difficult. It is just time consuming, tedious and easy to
> introduce typographical errors.
>
I suppose a "middle ground" is to put Archivers on the LiveCD for now,
and reevaluate that later. I really hesitate to add too much to the
LiveCD though. But if it helps us move forward - and if I'm the only
one with strong opinions to move Archivers to BonusCD - then maybe
Archivers on LiveCD is an option. Then it solves having to do all the
other "back end" admin stuff (GitLab, ..)
> >
> > BonusCD should be Archivers (except Zip and Unzip) + Devel (with
> > Sqlite) + Edit + GUI + Sound + Unix + Util
> >
> > *I don't know how big sbemu and vsbhda are, but I put each in my
> > spreadsheet as "100 kB" as a placeholder size (which is way too big,
> > but better to overestimate). With these and the other changes, the
> > total CD image sizes are:
> >
> > LiveCD = 231 MB (not incl. the "live" part)
> >
> > BonusCD = 418 MB
>
> When the BonusCD got to big, I arbitrarily removed DJGPP temporarily.
>
> At present, I think it is a little over 300MB. That would bring the BonusCD
> up to over 720MB. So, it will need to remain only in the online repositories
> or other projects will need removed.
>
I don't think we need to include DJGPP right now. Same as the FLTK
discussion, and the HTMLHelp/AMBHelp discussion, let's hold off adding
any other packages until after we have at least one test release that
has "balanced" ("reorganized") the packages.
>
> There is a completely different option that should also be discussed. As Eric
> hinted at in one of his messages. We could do away with the BonusCD. If the
> LiveCD only contained the binary portion of the packages, everything would
> fit on one CD. We would have a LiveCD and a SourceCD.
>
> My guess is that the majority of users have no interest in the source files.
> This would benefit users with lower bandwidth from being forced to download
> them.
>
> Also, it is not very different from downloading most open source projects.
> You can download the binaries from this zip. If you want the sources download
> this other gzipped tarball.
>
> But if all of the included project binaries were on one disc, we would
> probably not want to install everything with Full. It would take a while and
> most likely just be wasting drive space (assuming there is even enough).
>
> So, I think it is better to limit what is on the LiveCD. But, install every
> package from every group that is included on that media with the Full option.
>
I'm very strongly against splitting out source code from the packages
to create a "bin" CD and "src" CD. At least right now. I'm still
feeling burned from when we did that before and it caused headaches.
We ended up with "this package got installed but the source is not on
the 'src' CD" or "we install version X.2 in the 'bin' CD but the 'src'
CD has version X.1." Including the source in the package streamlines
things and has solved a lot of problems, at the expense of a bigger
CD. But for now, I still think that's a good tradeoff.
And as I said in my other reply: keeping the source with the package
means it's easier to stay in compliance with the license. Most open
source licenses (especially the GNU GPL) require that if you
distribute the binary, you also need to distribute the source code -
or make the source code available. Including the source in the package
makes that easy.
Jim
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
