Sonar GNU/Linux merges with Vinux

Sun Apr 23 23:20:03 UTC 2017

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 projec
>   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 at redhat.com
>> https://www.redhat.com/mailman/listinfo/blinux-list
>
> _______________________________________________
> Blinux-list mailing list
> Blinux-list at redhat.com
> https://www.redhat.com/mailman/listinfo/blinux-list