Re: GENERAL porting advice

[Don Y <dgy%caramail.com@localhost>]

On 12/5/2024 8:33 AM, Brian Buhrow wrote:
> since you've been a user of NetBSD as long as I have, you are doubtless
> familiar with the various user-level facilities available for driving
> external hardware and, you are also aware of the relative ease of making
> loadable kernel modules which let you add driver functionality to a working
>  system without changing the core distribution at all.

It's not a question of whether or not you COULD do these things but, rather,
how hard it is to convert the existing, working code TO a different design
as required by the target environment.

> The description you provide for analyzing a phone call's audio in real time
> seems very doable using NetBSD, with a variety of mechanisms available to
> you for allowing your different user level processes to talk with each
> other.

Again, as above.  For example, I have no file system visible in the API.
Any persistent storage takes the form of structured storage provided by
an SQL relational database.  (why do I need to support plain files if the
applications are then going to have to parse AND ENFORCE the form of their
contents?  why not use a service that can provide that FOR them?)

[E.g., "this is supposed to be a date; this is supposed to be an email
address; MAC address; name of a state/city; etc.  Why leave all of this
work to the application -- as the contents of files can't be guaranteed
on entry or extraction!]

So, when I place that call, for you, to "Penny", the speaker identification
algorithm has to make an educated guess as to who is speaking when the
called party answers the phone; is it Penny?  her husband?  one of her
kids?  It's not likely *me* who will answer!  :>  Nor, my doctor, lawyer
or dentist!

It does this by looking at statistics accumulated from calls to (and from)
that phone number.  Then, uses the parameterizations of those potential
candidates to come up with a potential fit.

Of course, the person answering the phone may not be the person you end up
speaking with.  And, that may change several times.  So, the diarilisation
algorithm can't assume there are only two interwoven audio streams and has
to keep its options open as it processes each new speech segment.

Because the speaker identification service is part of the authentication
service, it has to be able to vouch for its results and not be spoofable
by some other process on the machine.  The same constraints applied to
each of the various services on which it depends (are you sure that was
Penny's phone that you dialed?)

If there aren't enough resources available at the present time for any
of these activities (because of other concurrently running activities),
then additional resources have to be brought on-line to address them.

I.e., all of this is so interwoven that pulling it apart into USABLE
components isn't the same as porting a compiler, text editor, etc.

Finally, any time I make changes, going forward, you are faced with this
same "mess" to untangle.

> Your description of the home alarm telling its users which windows and doors
> are insecure is a very soluble problem, it just requires one to realize
> there are differences between the presentation layer of information and the
> information itself.

Exactly.  But, "solvable" isn't the issue:

> The challenge is getting developers and software designers, who, for the
> most part, think visually, to really think about what they're trying to
> present to the user and to give up any notions of how non-visual users
> process information and to talk with the users themselves.

Yes.  But, beyond getting them to think in more abstract ways, you
also need existing frameworks and toolkits to facilitate those efforts.
People tend to use existing frameworks instead of trying to invent
from scratch -- because of the effort (and planning) required.

So, a big part of the problem is SHOWING what you can do and PROVIDING
the environment in which to do it.

> All of this is to say that most of the issues you're discussing are OS
> agnostic and would be relevant whether we were discussing NetBSD, FreeBSD,
> Linux, Windows, Solaris or something else.

Yet none of them seem to be doing this "seriously".  It's always treated
as a "bolt on" activity and not one that is integral to the design of
the various applications hosted on them!