Re: GENERAL porting advice

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

Hi Brian,

> You mention embedded applications  which, I assume are the drivers for the
> display engines themselves, i.e. the low level driver which drives the
> wheels inside the Canut multi-line display from England, for example.  That
> code lives and works inside Linux, but there is no reason it couldn't run
> just as well inside NetBSD.

Of course!  But, in my world, it's a user-land process -- as are all
of the other drivers in the system.  To make similar use of it in
NetBSD (or any other mainstream OS) you would either have to migrate it
into the kernel or plumb it to vtys.

My implementation -- because it runs outside the (my) kernel -- has
different constraints on resources, permissions, etc.  E.g., I can
run these on a different processing node, somewhere else in the system,
without being constrained to *the* kernel running on a particular node.

I design "appliances" -- devices that perform specific actions for
the user.  In my present project, I have undertaken to ensure the
user interfaces do not rely on any particular set of physical
capabilities for their users (blind, deaf, cognitively impaired,
reduced mobility, etc.) without having to resort to a "bolt on" solution
(like a screen reader that has no idea what the application may be)

For example, imagine an alarm system for a home.  A typical solution
might visually display a floorplan of the house with indications of
windows or doors that are presently "not secured".  There's no easy
way to *bolt* an adapter onto that to make the information available
to someone visually impaired.

If, instead, you don't ASSUME that your user has the ability to see
(or hear or stand or move their arms or whatever), then you approach
the design of the system differently.

> While there is no accessibility category in the pkgsrc tree, access
> technology packages are in the pkgsrc repository and are known to be
> maintained.

Yes.  The point of publishing my implementation is to advance the PRACTICAL
state of the art and get folks to start thinking about the assumptions
that they implicitly bake into their designs.

> While NetBSD cannot be considered to be a "real time OS" per
> say, it does have facilities which allow applications and drivers which hav
> real time requirements to operate smoothly.

My solutions aren't directly portable because they are heavily
intertwined with each other.  E.g., if I place a phone call, for
you, I will listen in on the conversation, split the audio into
different streams based on who is speaking, identify each of those
voices, determine what each party is saying (based on knowledge
of their speech patterns) and update the models that are used for
each of these tasks.  And, (later) reprocess the recorded conversation
to determine how well the updated models are performing.

If these were all individual "desktop applications", plumbing them
together would be an issue.

Along with addressing the case when the machine is currently overloaded
while you are "talking on the phone" so some other resources have to be
found to perform these activities.

> As Greg pointed out, NetBSD
> strives to maintain API and ABI compatibility as much as possible as its
> releases progress.  What that means for application developers is that once
> an application is up and running on NetBSD, very little work needs to be
> done after that to keep it running going forward.  I've been working with
> NetBSD since it first came out in 1993 and I have some binary files which
> still run today on the latest version of NetBSD which were created long
> long ago on very old versions of NetBSD.

I started off with 0.8 (after throwing my hands up in dismay over 386BSD)
then moved to FreeBSD for a year or two.  Then, back again -- where I've
been for 30 years.

But, my use is primarily for software development of these appliances.
The bits of code that I've written to run under NetBSD are for very
specific uses and, generally, not the sorts of things others would
find use for.

For example, I designed an appliance to cleanse hard disks for a
non-profit that recycles donated computers and laptops.  Donors have
expectations that the data on their donated drives will be purged
and not fall into the hands of some other user.  Each may have
different requirements for how the drive is cleansed -- and whether
or not that is verified, etc.  Being able to show your commitment
to protecting their data goes a long way to encouraging them to
donate machines and not pull the drives (or, DRILL the drives!) out
of fear of their data leaking.

While doing so, it also benchmarks the drives (to decide if they are
worth reusing AFTER they have been cleansed) and installs an operating
system.  And, does this with the expectation that the person operating
the equipment isn't particularly skilled or motivated (volunteer labor).

How many people need this ability?  For *60* drives, concurrently??

> All of this is to say, NetBSD iis a fantastic OS to work with as a developer
> and its stability is a large part of that goodness.
>
> Hope that helps. -Brian