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 projects 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
