EOF - Consider Accessibility
Is Linux accessible? In other words, how well does Linux work for persons with disabilities? The answer today depends, in great degree, on which disability we're talking about. However, several factors have begun driving Linux to become a friendlier environment for users who are persons with disabilities.
Perhaps the most fundamental factor spurring Linux toward a more cohesive response to the accessibility challenge is the Linux ethos itself. The communitarian values that undergird free and open-source software simply cannot tolerate the notion that Linux should exclude anyone. Doesn't everyone have the right to run the program? Isn't everyone free to study and improve the source? It goes against the grain to leave anyone out simply because they can't read text on a video display or press both the meta key and F1 simultaneously. Linux always has valued and encouraged active participation from its community of users. We pride ourselves that quality contributions, whether code or documentation, float to the top and become incorporated in the next release. And, indeed, much in Linux exemplifies accessibility. Unfortunately, it is generally incidental accessibility—a by-product of the fact that Linux is deeply rooted in ASCII on the one hand, and on Linux's stellar ability to accept input from most any kind of device on the other. Not that developers intentionally would exclude support for accessibility—it just hasn't been a design criterion in the code review process.
Another potent contributory factor is the emergence of laws and policies giving preferences to software and systems that are accessible. Chief among the examples of such factors is the legal mandate in the US government procurement known as Section 508. This recently strengthened US law requires the US government to procure accessible “electronic and information technology” for use in the federal workplace and in systems that provide information and services electronically to the public if accessible technology is commercially available. Section 508 has expanded interest in accessibility greatly simply because the US government is a big IT customer, currently spending about $40 billion annually on technology—a number expected to grow by 50% in merely five years. Clearly, most vendors that bundle Linux products and services might find Uncle Sam a customer to court. Coupled with the high esteem Linux people have for Linux communitarian values, it rankles one to think that Linux itself might, just might, not measure up against this social performance yardstick.
Over the past few years several developers, funded principally by Sun Microsystems, but also by IBM, Red Hat and Ximian, among others, systematically have been putting the new GNOME 2.0 desktop accessibility framework together. Frankly, it is hard to believe this would have happened had it not been for Section 508, but the benefits of these efforts will extend well beyond the US. The GNOME Accessibility web page (developer.gnome.org/projects/gap) is possibly the best current source of information, in a Linux context, of what constitutes accessibility and how it can be achieved.
However, we might summarize accessibility as an I/O issue. The fundamental problem, though varied and complex in its myriad permutations, is simple. For every way by which a computer can accept input from a human user, there is someone who can't do things that way. Likewise, for every output modality intended for human consumption, there are users who cannot accept that particular medium as input. So, the challenge, the subject of articles to come, is simply how we get this intrinsically binary instrument to accept input from whatever device might be needed. And, how do we reformat and re-purpose output to encompass the rest of the user base?
The ethical imperative is clear. The software commons must be for everyone if it is to be a true commons. Even those whose software isn't directly related to providing interface support to users with disabilities must help, at some point and in some manner, to make their applications work for the widest possible user base. It is indeed possible this demand will prove disruptive in some areas. For the most part, however, it should prove minimally invasive, simply because of the socketed nature of Linux. Clearly, much of the work will be performed by specialists, because there is a good deal of specialized knowledge involved in getting solutions that work well. Ultimately, of course, the various communities of users with disabilities will determine for themselves how to do things. But, what they will want to do are the same things the rest of us want to do—which takes us back full circle to the communitarian ethos.
Janina Sajka is the director of Technology Research and Development, at the American Foundation for the Blind (AFB).
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Control Your Linux Desktop with D-Bus
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide