This is the kind of thing we created the International Association Of
Visually Impaired Technologists for. It has donated server space and is
incorporated legally as a nonprofit (501C3) in the USA. The
infrastructure is available if you care to put it to use.
--
John Heim
On 04/23/2017 12:00 PM, Linux for blind general discussion wrote:
ok,
differing arches all have the same source in common. So, maintaining for them
is actually easier than you might think. All that would really be required to
make an arch specific package is the proper scripts that patch and package for
that arch. Otherwise, the source code, itself, is pretty common across all
arches.
Now, I have done this in the past. Used a source tar ball and compiled on a
debian based system and also compiled on a RedHat based system and in both
cases, the utility that I compiled functioned the same and required the same
libraries and development tools.
THere is also the use of a ports tree (As seen in the BSD ecology). I have been
able to compile some linux tools over there, but the ports tree is a bit
limited and still depends on developer support. So, in that case, it could be
problematic.
Someone else pointed out that we may need an organization fronting some
development as a means to get patches and packages reviewed faster. Perhaps we
need to take a look at the guys at the NV Association (the makers of NVDA, the
free windows screen reader). THey have a fairly sizable fundraising network and
do a lot of work with some paid developers. Also, the guys running the
organization are a pair of blind programers. Now, if we could get them
involved, it might help to enhance operations in creating a standardized
accessibility package set that can be arch independent.
Now, mind you, I am not a coder. I can operate a compiler, even make some
simple changes to get a compile working, but thats about as far as my developer
skills go. My forte is security, intrusion detection, firewall scripting and
auditing as well as advanced system administration. And yes, my preferred OS in
a secure environment is in the BSD ecology. However, as a recent exchange with
Theo DeRaadt demonstrates, there are just some folks who won't even consider
supporting the idea of making an OS accessible. In fact (as that recent
exchange demonstrated), they might just go out of their way to impede progress
in this area.
anyway, given all that we are striving for, some good help can be had out there
(like the aforementioned NV association). It's just a matter of getting them
onboard.
-eric
On Apr 23, 2017, at 4:13 AM, Linux for blind general discussion wrote:
On 4/18/2017 8:23 AM, Eric Oyen wrote:
here is one thing that might be distro independent: create an accessibility
package set. This would include the required libs, scripts, binaries and config
files needed to make any distro accessible. It would include emacspeak, BrlTTY,
ORCA, the appropriate audio drivers and libraries and even access to the kernel
modules required to make it all work.
While great in principle, it's impossible and wouldn't work. First, how do you
maintain binaries for the different arches? The Raspberry Pi runs on ARM, I'm
running amd64, some old machines are 32-bit x86, etc. Again, speaking of very
limited resources, it would be impossible to maintain the latest versions of
all of these packages and build binaries for all of the arches. Also, what
about memory? A small ARMEL system isn't going to run Orca very well, although
I've read of people doing it. The list goes on.
The other problem is you'd have massive system breakage. If I run a Fedora
binary on Debian, there is probably a shared library conflict. That means
everything has to be compiled statically, slowing down execution and increasing
memory. Even at that, you can't mix and match kernel modules in most cases. My
4.3.3 Speakup modules probably won't run on my 4.6.4 kernel. Finally, every
distro puts files in different places. Do you have /usr/bin/orca which
overwrites the distro package or /usr/local/bin/orca? If the later, what if
/usr/local/bin/orca breaks, leaving you without speech? You have to delete it
to get /usr/bin/orca to run. What if the version of Gnome supplied doesn't
match Orca? The list goes on and on.
There is a possible solution, however. It would be to create a list of as many
config files as possible for as many programs as possible, roughly divided into
console and GUI. My thought would be, for example, special configs for Lynx the
cat, Links the chain and whatever other console programs people have
customized. For graphical, you would have Orca plugins, weather scripts like
Vinux has, etc. They could be supplied as generic tarballs which could be
extracted on any OS, any platform and any distro. The only thing special would
be a custom installer or support in the existing upstream installer. It could
fetch the tarballs from a central place and extract them on installation.
Failing that, drop a script which runs at first boot to do the same thing.
Failing that, distribute a bash script which could be run without speech once
you're logged in as root. That would still require the accessibility packages
to be installed, but the script could do that automatically. Lots of proje
c
ts do that already, mostly on servers. They autodetect the distro, make sure
the latest package lists are downloaded and install from either a central repo
or the distro's repos. You could even ship a static .wav player and include
spoken prompts. I've thought of designing a talking menu system that way.
Getting back to your point, you could have two sets of central repos, one for
RPM and one for .deb as those are the two most popular. The script could figure
out which distro you're running, fetch from the central repo, install and
that's it. The user can pick what they want and whether they want console or
GUI. You would still have to compile everything statically, but you could
support Debian stable, testing, oldstable, Ubuntu, Fedora, maybe RHEL, etc.
That would let you ship custom RHEL kernels with working Speakup modules. That
is not only very doable but is already being done with webmin and lots of other
projects. It could easily be maintained by a few developers. You have one for
RPM, one for .deb and one for security and support.
Even better, you could have a live CD which does this. I don't mean like Vinux
or Ubuntu. I mean after you install your favorite distro, you boot the live CD
and it runs the script to install accessibility on the already installed
distro. You could run that CD on hundreds of machines and in theory, all could
be made accessible. Then again, that makes me think if all upstream distros
made their installers accessible, this would all be a waste of time.
_______________________________________________
Blinux-list mailing list
Blinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/blinux-list
_______________________________________________
Blinux-list mailing list
Blinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/blinux-list
_______________________________________________
Blinux-list mailing list
Blinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/blinux-list
