Re: GENERAL porting advice

[Brian Buhrow <buhrow%nfbcal.org@localhost>]

	Hello Don.  I am a long time NetBSD developer who happens to be blind.  I use speech
output on a daily basis under NetBSD.  You talk about refreshable braille displays and drivers
for them.  I've built and used brltty under NetBSD and I know folks who are using it with
FreeBSD.  I've written kernel drivers for the DECTalk PC under NetBSD and done a good amount of
kernel development work with NetBSD and some with FreeBSD.  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.   
	While there is no accessibility category in the pkgsrc tree, access technology packages
are in the pkgsrc repository and are known to be maintained.
	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.
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.


	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


On Dec 4,  5:30pm, Don Y wrote:
} Subject: Re: GENERAL porting advice
} On 12/4/2024 7:56 AM, Greg Troxel wrote:
} In my case (embedded), those applications tend to be designed to
} continuously interact with each other and the environment so how
} they do that is a key part of their utility /in my application/.
} 
} But, others could opt to run batch versions -- if only to understand
} how the algorithms work OR adapt them to their own needs.  E.g., I
} have a set of applications that interact with "braille terminals"
} (refreshable braille displays) to accept input from and drive
} output -- translating" on the fly.
} 
} It would be hard for me to imagine using them in a batch mode
} (a braille note taker?) instead of as the *interactive* input
} and output devices they were designed to be.  I.e., they'd want
} to be wired INTO a user session atop a vty.
} 
} Likewise, speech I/O, speaker identification, diarisation, etc.
} for exactly similar reasons.  I don't think pkgsrc even has a category
} to address "accessibility" applications!
} 
} I would have to evaluate how the utility of the applications can
} best benefit folks constrained to an environment like *BSD, etc.
} (or, just publish and let others sort out how to make it run on
} their platform of choice -- admittedly a higher bar to reach)