Hi, Don't forget GNU homes an a11y list (fsf). It can be used if you are not pleased with this one. Regards, Le 24/04/2017 à 11:14, Linux for blind general discussion a écrit : > 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@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/blinux-list > -- Logo Hypra Photo Jean-Philippe MENGUAL *JEAN-PHILIPPE MENGUAL** DIRECTEUR TECHNIQUE ET QUALITÉ* adresse84, quai de Jemappes, 75010, Paris téléphone+331 84 71 06 61 <tel:+33%201%2000%2000%2000%2000> courieljpmengual@xxxxxxxx site webwww.hypra.fr Facebook Hypra <https://www.facebook.com/hyprasoftware/>Twitter Hypra <https://twitter.com/Hypra_>Linkedin <https://fr.linkedin.com/in/jean-philippe-mengual-800133135> _______________________________________________ Blinux-list mailing list Blinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/blinux-list