Filter packages based on hardware requirements (CPU, graphic card, RAM...)

[evan]

I have installed a bunch of random packages on my 8088 only to find out they don’t support my CPU. The larger ones, that took longer to unpack, are the least likely to work.

I understand most people are not using 8088s, but It would be nice if the CPU (and maybe EMS/XMS) requirements were tracked as package metadata so that pkgnet search could filter for supported software and pkg install could warn/fail when the package is mismatched.

[mateuszviste]

I agree, on the principle, and I did think about it myself a few times already. Adding some filter is relatively easy, but let's not forget that 8088/8086 is no the only thing that matters. I have a 386SX and I'd like to see which packages are compatible with it (ie. no 486 opcodes and no FPU required). I also have a 286, same story. And what about people having limited amount of RAM? My T1200 laptop has only 256K of RAM, what packages can I run with it? Same goes for MDA/CGA/EGA/VGA, lots of packages assume VGA, hence they are useless to owners of CGA machines.

So one thing would be to design the metadata system so it makes practical sense for most situations, and then another subject is the huge work that it would be to manually analyze each package to figure out what its requirements exactly are - and then update every package with relevant extra information in its LSM file.

Designing a metadata system that is used by the repository as a filter list is something I can handle without much trouble, it's easy stuff. But examination of all packages and populating said metadata is something I do not have enough lifetime for - I'm busy enough already with enforcing 8086 compatibility on CORE packages. :-)

[evan]

Understood; maybe you can crowdsource it? Just an idea after a few minutes thought. Maybe a few commands:

• pkg compat (shows metadata from svp file, maybe also encourages you to run pkgnet compat for more)
• pkgnet compat (shows svp file metadata, if any, and votes from repository, if any)
• pkgnet report (answer a set of compatibility questions and update repository votes)

When you run pkg install, it can encourage you to report via pkgnet report on exit.

I'm not sure how reliably you can inspect the machine hardware, and software can support multiple video modes/ram types, machines can contain multiple video cards, etc., so I think manual reporting is fine for now. However, if nobody is bothering to make reports, you could generate a machine hardware report and list of installed packages every time somebody runs pkgnet and submit that automatically, on the assumption that people won't leave packages installed that don't work.

I agree we would want:

• CPU
• FPU
• RAM (conventional, EMS, XMS)
• Text/MDA/CGA/CGA-composite/EGA/VGA
• PC Speaker/Adlib/SoundBlaster/GUS
• Network present
• Mouse present
• Is a Tandy/is a PCJr? I don't know if anybody is using SvarDOS with these

Then if something gets a bunch of votes, the maintainer or a volunteer could update the svp file to include whichever requirements are clearly known (shouldn't have to be comprehensive).

That T1200 is cool; my dad borrowed a Compaq luggable for a while when I was a kid.

[mateuszviste]

The idea is neat, but I do not think the amount of SvarDOS packages (currently 360) and the number of SvarDOS users (maybe 4) make this a good use case for "big data" stats. :-D It is more a matter of someone willing to spend a dozen of hours (or maybe couple of days) to go over all the packages and set up some listing of hardware requirements, either by testing the software or going through whatever documentation that comes with packages.

That being said, the mechanism of storing hardware requirements metadata within packages (and the ability to filter it afterwards) is definitely a useful feature. I will think about how to implement it and will flag a few packages. And maybe in the future someone will update/flag more packages.

[evan]

I was hoping we had users in the dozens :-)

All makes sense; if you add the manifest/metadata feature I will at least file tickets for the requirements I encounter.

[mateuszviste]

Added initial provision for hardware-req filtering. A filter form is visible now at http://svardos.org/?p=repo

For now only the "zboy" package has hardware metadata (visible when moving the mouse over the package).

How?

The LSM of a package may contain now a "hwreq" line that contains a list of hardware identifiers. Possible values are:

vga, mcga, ega, cga, mda, hgc, 8086, 186, 286, 386, 486, 586, fpu

The LSM file should mention only the minimum requirements (for example if a game may run either in CGA or EGA mode, then the LSM should mention only "cga").

Left to do:

• integrate somehow with pkgnet
• add validation of hwreq values so bad values are reported to packagers
• update help documentation about the package format
• implement OR-ing of same-family tags: if a package mentions both "ega" and "hgc", then the package should be proposed for systems that have either EGA or HGC cards (currently all tags are ANDed together). In the end a "hwreq: 386 fpu cga hgc" line should be understood as "a 386+ machine with a co-processor and either CGA or Hercules graphic"

[mateuszviste]

documentation updated http://svardos.org/phpamb.php?fname=help/help-en&f=pkgfmt.ama

[evan]

FWIW, I don't see the tooltip yet.

Edit: Tooltip only shows up if you hit "apply" on the filter.

[mateuszviste]

tooltip fixed hwreq validation added hgc token removed to avoid unnecessary complication

left to do: integration with pkgnet

[bttrx]

For now only the "zboy" package has hardware metadata (visible when moving the mouse over the package).

1. How could I place the mouse over a package on my smartphone?
2. What about blind people?

Quoting Accessible Tooltips – The Admin Bar:

One thing worth asking yourself when building websites is, “Does this content truly belong in a tooltip?”

If content is really important, then it should be visible on the page without requiring a hover or focus action. Likewise, tooltips are supposed to be short: 2-4 words max, not multiple sentences or paragraphs.

Sometimes, the easiest way to make something accessible is to avoid the “fancy” or complex user interactions and go with a more straightforward design. Basic can be beautiful, so if a tooltip isn’t absolutely necessary, you might be able to provide a more accessible experience with less work by leaving them out.

[bttrx]

It is more a matter of someone willing to spend a dozen of hours (or maybe couple of days) to go over all the packages and set up some listing of hardware requirements, either by testing the software or going through whatever documentation that comes with packages.

Maybe this testing could be assisted by some automation tool driving DOSBox or some virtual machine.

1. At first, it creates a machine with a quite modern configuration.
2. Then it starts this machine and you do check test of the result for this package.
3. Record the result and stop the machine.
4. The tool will now reconfigure the machine from, e.g., pentium to 486.
5. Repeat from step 2 until the package fails to run properly.

Beware: I have no knowledge about this stuff. It's just an idea I had.