Sonar GNU/Linux merges with Vinux

[Linux for blind general discussion]

My name is Tony Baechler. Since names aren't showing up, it makes it very 
hard to track discussions. If no one objects, I think I'll create a new list 
very soon. I've looked at groups.io and they look good enough. Besides, as I 
stated before, Red Hat has shown many times that they don't care about 
accessibility, so just on principle, I think it's time to move on. Sorry for 
my rant. See below.

On 4/23/2017 10:00 AM, Linux for blind general discussion wrote:
> 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.

Yes, this is true. Just do the usual ./configure;make;make install. However, 
we run into problems with testing and cross-compiling. I know ARM binaries 
can be compiled on x86_64, but it requires either an ARM toolchain or a 
virtual machine. Without having real hardware, it's impossible to know for 
sure that your binaries work. Case in point, ESpeak crashes on the Pi due to 
some sound card bug. There is some workaround, but I don't have a Pi and I 
haven't followed it.

That said, if you're only compiling for one or two distros, like Debian and 
Fedora, it might work and one person might be able to keep up. Just have 
Debian stable, testing, and oldstable containers. Then we have the issue of 
what distros do we support? Do we support Arch because it's bleeding edge or 
do we let the Arch Linux developers do that themselves? Do we support all 
supported versions of Ubuntu or only LTS? Do we support Debian Squeeze 
because it was the last version to work with serial ports, even though 
Debian doesn't support it anymore? What about security? How do we get the 
latest fix for the libespeak libraries out if the only person doing the 
compiling is sick?

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

Yes, but you're missing the point. You compiled that tool for systems that 
you use, presumably on those systems. Did you run the Debian binary on a Red 
Hat system? If you only need glibc, you might get lucky, but sooner or 
later, you're bound to run into shared library conflicts. The reason why you 
can't just switch your /etc/apt/sources.list on a Debian system to Ubuntu is 
due to this. Ubuntu often ships different library versions. Let's take a 
realistic example. Debian Stretch should be released very soon. Ubuntu 17.04 
has just been released. In six months, Ubuntu 17.10 will come out. Debian 
won't have another stable release for about 24 months. Well, if your binary 
is compiled on Ubuntu 17.10 or 18.04, it most certainly won't run on Debian 
Stretch, even though it's still supported. Likewise, while usually older 
glibc versions work, if Ubuntu switches to eglibc, it's likely your binary 
will break. Really, the only way you could do this is to compile everything 
statically which isn't usually a good idea. Even so, Orca is written in 
Python and depends very much on the latest Gnome, so you would still have 
breakage.

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

Yes, I thought of that and that has a decent chance of working. You can 
build pkgsrc ports from the NetBSD tree on Linux. It's a lot like Arch and 
Gentoo in that you can have the bleeding edge if you want and it's compiled 
on your hardware for your system. I would very much support an accessibility 
ports system like this. The problem is most users don't know how to install 
a ports tree, don't want to install a bunch of overhead tools, don't have 
the space for a bunch of source packages and, unless I'm mistaken, it's 
impossible to build ports in a GUI. That brings us back to a specialized 
distro based on Gentoo or Arch. Talking Arch already fills this need. I 
personally don't mind compiling the latest code from scratch. I even set 
aside an extra partition for testing Orca. However, I'm in the minority. 
Even I get tired of it after a while, especially since Orca is updated 
almost daily in git.

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

That would be me. I think a nonprofit Linux organization needs to be modeled 
after NV Access. They are a bit too pushy for my taste in fundraising as 
they force you to either donate or opt out, but I guess it works. If they 
would support Linux, that would be great. I don't think they would. First, 
they have far more to gain by not supporting it. There are many times more 
Windows users, so a lot more money. Second, I don't think that's their 
interest. The best you would likely get is a subproject under the NV Access 
umbrella with no official support from them. I hope I'm wrong though and 
hopefully someone reaches out to them. I think in the long run, a dedicated 
Linux, Unix and BSD organization is the better way to go. As I and someone 
else said, what we really need to do is get as many blind people as possible 
actually using Linux and as many developers as possible.

As much as I don't like social media, I think that's where the major support 
is coming from. Teens in particular don't do email. If you could get a blind 
teen interested in coding to start working on kernel hacking, as they grow 
into an adult, they are more likely to support Linux. For that matter, if 
you can educate sighted teens about the desperate need for accessibility in 
Linux and open source in general, they might want to help. I'm thinking of 
GSOC among other projects. Teens seem to be mostly on tumblr which is very 
far from accessible, but it can be managed.

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

I prefer BSD myself. My developer skills are about the same as yours. If it 
doesn't compile out of the box, I'm at a loss. I like FreeBSD and ran it for 
a while. I had to ssh into my machine and I couldn't install without sighted 
help. I'm not at all surprised that they aren't interested in accessibility. 
FreeBSD does have Orca and other tools, but who knows if they actually work. 
An accessible FreeBSD would be very interesting.

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

Yes, I agree. That's why we need a nonprofit to front development efforts. 
The days of a ragtag team of blind guys hacking on whatever distro to make 
it talk are over. The Linux community has grown up, but I don't think the 
blind Linux community followed. Yes, there are a few who have actual jobs in 
Linux, but they aren't the coders and developers. The list of what needs to 
be done to really modernize is endless. For now, get the existing software 
into a form which is easy to use for the non-programmer coming from Windows. 
As I said before, start by fixing bugs and submitting patches in the name of 
the nonprofit. Commercial support will happen once people know that our 
group is serious. The reason why Windows and web accessibility keep 
improving is due to the blindness advocacy organizations. The difference is 
KDE is open source and can be made accessible with or without upstream support.