Re: [H-source-users] generalize (or eliminate) the distros white-list

[bill-auger]

On Fri, 05 Nov 2021 22:56:55 +1100 Yuchen wrote:
> It may not be 
> accurate, but probably won't lose much information compared to 
> what we have, with added benefits that existing record won't need 
> to be clobbered.

it wont be perfectly accurate; but probably more accurate than
it is now; because any guesses would probably be correct, where
now, known-working devices may appear as "no result", and
known-broken devices may appear as "works with free software",
merely because it worked for one person, 10 years ago - so:
"it worked 10 years ago OOTB" acquires extra accuracy alongside
"but it does not work today OOTB"

i dont suppose that any records are clobbered - just the
presentation of the singular: "works with free software" for each
device, seems to have only one value; and its not clear which
record(s) that value derives from - is it the most recent post
for that device? - is it the 'OR' union (eg: any_satisfy? in
OOP-speak)? - i suspect it is the latter

to the meat of this issue, i am imagining that the DB could be
distributed somehow (rsync, IPFS, activity-pub, whatever) -
decentralization is a strong trend for libre web "apps" these
days - people would probably appreciate that - with any publicly
distributed/p2p/replicated data-set, it is not possible to
prevent erroneous data from entering the store - each host must
validate each record, and filter out unwanted valid records from
the presentation - this is not without drawbacks o/c - it
entails that all spam probably stays in the data-set forever -
but as we discussed previously, spam could be prevented if the
website insists that all new reports originate only from the
h-client; and perhaps on the web, may be edited only, or maybe
only the notes/comments may be edited by users

in any case, the distros white-list could simply be a
presentation filter; yet the DB could accept any well-formed
posts into the global data-set - each host could decide which
data to expose to the website user - h-node.org would never need
to show reports from ubuntu systems; although they may be in the
DB - a non-free ubuntu derivative may want to present them on
their instance; and i dont think GNU has any policy such that
their software must be useless on non-free OSes

for example, all of the debian, gnewsense, and pureos records
would be 100% relevant to another fork of debian - in fact, they
could be folded into one; because all of those distros
(corresponding to the same debian release) probably have
identical hardware support - the fork could simply change the
presentation to consolidate all results for: debian8, gnewsense8,
and pureos8, into one value: "Tested on MyDebianDerivative 8";
and it would probably be quite accurate - so why the extra
hurdle? - these distro distinctions are irrelevant

after-all, reports of linux-libre running on any distro
are probably relevant to any distro with that same kernel
version - so, this is generalizing what could be more specific
(focus on distro support vs kernel support), and specifying what
could be generic (certain distros are hard-coded as acceptable)
- if a report for some non-free hardware is posted from a
non-free kernel or OS, h-node could easily filter that; because
the kernel would not be on its kernels white-list:
  [ 'linux-libre' , 'debian-style' ]

the kernels white-list could also be made configurable, so that
someone could simply add 'linux' or 'bsd', or it could be
eliminated, so that no one needs to bother - there is no
practical reason to keep records for those kernels out of the DB
o/c - that is merely a political motivation of the authors and
original host, but constrained in the source code (incidentally)
rather than as configuration, where it should be - the only
effect (other than saving some DB bytes) is to artificially
over-specialize the service, and the client and server binaries,
such that they are all useless to people using upstream linux,
and to those using linux-libre on an unknown distro

only laziness would compel someone to hard-code those
validations/filters in that way permanently, without the
political motivation; because there is no technical benefit - the
generalizations i am proposing are just good design practice -
they change nothing WRT the user experience on h-node.org - the
political goals can be satisfied by the GUI presentation filters
(web templates, whatever), regardless of what is in the DB - yet
the service and data-set could be federated/distributed; which
would impress many people as forward-thinking, at the
libre-frontier