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