Sonar GNU/Linux merges with Vinux

Mon Apr 24 12:32:15 UTC 2017

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 at redhat.com
> 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 at hypra.fr
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>