Original audio available at bsdtalk.blogspot.com. This document is available in other formats at http://derek.trideja.com/bsdtalk/.
BSDTalk: Hello and welcome to BSDTalk #63. It's Thursday, August 31, 2006. The interview that I have for you today was recorded last week, and then I went to Mexico for five days, and when I came back, I received an e-mail from Mitchell Smith saying that he's made some progress on his screen reader for the command line and tested it on NetBSD and OpenBSD. So during the interview, you hear him say that he's trying to work on that project, but apparently there's been some good progress, and I intend on having him back on the show as soon as I can to hear his update. Anyway, here's the interview.
Today on BSDTalk, we're speaking with Mitchell Smith, and I wanted to speak with you because I had some questions about your use of BSD, and also your use of accessibility options and how you work with BSD, so welcome to the podcast.
MS: Thank you.
BSDTalk: So perhaps you could give us a brief description of who you are, what you do, and how you use BSD.
MS: Uh, I've been using BSD since probably, less than five years now, both OpenBSD and NetBSD. Before that, I was using Linux since about '96, I guess. The Debian operating system. Mainly I do work with hosting companies and other small businesses, so I currently admin somewhere in the vicinity of 70 NetBSD and Linux boxes. Web servers, mail server, firewalls, file servers, that sort of thing. I mainly switched to BSD because there was some issues in the early 2.6 series kernels when they were released that they were releasing frequent security updates and I thought I need to find something that … you can sort of install and leave and not have to worry about it, so OpenBSD ended up being my, uh, my choice there. And of course, later, NetBSD for Xen support and operating system virtualization. So, that's really a bit of my background with BSD.
BSDTalk: And another part of your use of computers in general involves some accessibility challenges, so perhaps you could describe those and how easy or difficult it is to work with Unix variants and the BSDs specifically.
MS: As far as Linux goes, there's several options available to you in terms of screen reading access, uhm, magnification, braille terminals if you use braille terminals. So that sort of thing's widely available under Linux, and so far under BSD it's, it's a little bit limited. I tend to use mainly serial console access, you know, if you're doing installations and stuff like that, otherwise I use either a Linux or Windows screen reader, and SSH, obviously, into the various BSD systems.
So yeah, either serial console access or SSH is your main point of access currently under the BSD operating systems. In terms of screen reading access, currently, uhm, I have had some success with Orca, which is a, uh, a screen reader for the GNOME desktop which is mainly written for Solaris and Linux, but it does work with quite a degree of success under NetBSD. So that's obviously, if you're willing to have a full GUI installed on your servers, you can use Orca which, uh, does work rather successfully.
BSDTalk: I think what's fairly common, you know, from the people I interact with, it's Windows with something like JAWS and, you know, a terminal or secure shell application.
MS: Sure, yeah, JAWS or Window-Eyes being the two leading screen readers for Windows, and use a terminal application, SecureCRT is the one I use, but most SSH clients or terminal clients work quite well.
BSDTalk: As far as screen readers in the open source world, one of the few available text-to-speech engines might be Festival. I don't know what you're using on the Linux side or the BSD side…
MS: Sure, well, first of all, developed at CMU, I believe, is also a stripped-down version of Festival called F-Light which is what I was testing with Orca and GNOME, which does work quite well under NetBSD. Compiles and runs under NetBSD quite successfully.
BSDTalk: Do you ever use any external text-to-speech engines like a DECTalk?
MS: Under the BSDs at the moment they're not supported. I'm currently working on a port of an application called BrailleTTY which is a Linux application, well, a Linux kernel module and applications. I'm trying to get that ported across to NetBSD which'll give access to obviously Braille terminals and external synthesizers like the DECTalk, DoubleTalk, most other such general serial synthesizers.
BSDTalk: Will this be a kernel-level access or will it be userland.
MS: Uhm, userland is what I'm aiming for because obviously it's a lot easier to implement, and, you know, the fewer modifications to the kernel, the easier it is to just drop on a system and run, rather than having to add modules to a currently-running stable server.
BSDTalk: Yeah, 'cause I guess at least in the Linux world, kernel modifications like SpeakUp at least allow you to see the boot messages and also get through some installs.
MS: Sure, exactly, which is why serial console access is really the best option should you need, obviously, access before SSH comes up. You know, you can get serial console access, depending on what you're using, even down to the BIOS level on some architectures.
BSDTalk: And I don't know how much interaction you have with other people who are interested in technology and people who are also using screen readers. Is there a perception that people would love to try them out but the support isn't as nice as they would like?
MS: Uhm, in a way it does. It seems to be a big barrier, even so far as getting in and trying things like Orca and SpeakUp under Linux, you know, a lot of people either aren't aware that the open-source options are out there, and if they are, then they're just too daunting, so they tend to fall back on something like JAWS or Window-Eyes which is a commercially-supported solution, obviously, with training and stuff available. I think that will get better. I mean, Orca is really developing quite well. You can use it under GNOME for Firefox access so you can access e-mail. So I mean, it's coming along, it's certainly not to the degree of, say, JAWS or Window-Eyes, but, you know, it's certainly further than it's ever been before on an open-source platform. And being an open-source screen reader as well, it's written primarily in Python, it's, it's wonderfully scriptable and if something doesn't behave the way you want it to, you can just modify it and, you know, get it to read things how you like.
BSDTalk: Does Orca rely on the applications having hooks for accessibility, or does it do a pretty good job of applications that weren't written with accessibility in mind?
MS: Well, it works quite well with applications that use standard GTK frameworks, but obviously programmers like to build their own widgets and things like that, which makes screen reader access, even under the Windows environment, quite difficult if you're not using Windows controls. That makes it very difficult for a screen reader to get access to that application, which is why having a scriptable screen reader like Orca, it makes it a lot easier to modify the screen reader, as it were, to interact with that application.
BSDTalk: And do you feel that the command line nature of BSD, Linux and other Unix variants, makes it a better platform for people with screen readers, given that it's a much more linear interface?
MS: Sure, definitely, yeah, I mean I originally started using a computer with DOS, obviously with a DOS screen reader, and a command line interface is a lot easier to use for visually impaired people. Because with a screen reader, obviously, it's got to try to give you feedback from a visual environment, and if it was a command-line application, you're getting primarily text feedback, which makes it a lot easier for a screen reader to interact with your environment because it's just reading back straight text, rather than, you know, trying to interpret dialog boxes, check buttons, drop-down lists and menus, and all that sort of stuff.
BSDTalk: And do you think that the available command line applications are on par with what you have in the graphical world? I'm a frequent user of the Links web browser—love it!—there's obviously some things it doesn't do, the mutt e-mail client, things like that… but are there some applications in the GUI world that you wish you had on the command line?
MS: As you said, Links does an incredible job of web browsing, except, obviously, with, you know, web sites using JavaScript, AJAX, that sort of thing. I personally use vim as an editor, and I far prefer that to using Microsoft Word, but someone who's maybe coming to computers for the first time with a screen reader might find vim a bit daunting, obviously, rather than the sort of point-and-click nature of Word.
Once you're familiar with a command-line environment, you can certainly do things a lot faster than you can with a graphical environment with a screen reader, simply because, obviously with a graphical environment, you still have to memorize all the keyboard shortcuts anyway. And so, quite often I find the command line interface is a lot faster.
Uh, as to applications that are available in a graphical environment, uhm—no. You can play MP3s, read e-mail, write documents, you can do just about anything from a command like that you can do in a graphical environment.
BSDTalk: Yeah, I'm a creature of habit when it comes to the command line, even if I'm in a graphical environment. Even when I need to edit a configuration file, I'm more likely to open up a console and use vi or vim than to use one of the graphical editors.
Uhm, another thing about BSD and the other Unix variants is that the administration of them is traditionally command line-driven, which I actually prefer. Do you think that it makes it easier to administer? Usually here, people say that Unix is difficult to administer because it doesn't have that magical checkbox that solves all your problems, but I actually prefer the command line environment.
MS: It's interesting that you say that actually, because I was doing an installation of Windows 2003 Small Business Server last week, and obviously, Exchange and all those other applications that go with it, and I was thinking to myself as I'm doing this, you know, I could have had it done in a tenth of the time with OpenBSD, Postfix and a similar Unix environment simply because it's just a matter of popping up a couple of configuration files and making changes, rather than searching for an elusive checkbox which, you know, often's buried under twenty different menus. But I suppose it depends on what environment you're familiar with, but certainly if you're familiar with command line interfaces and configuration files, you can get stuff done so much faster, you know, in a command line environment, in terms of administration. It also makes it a lot easier to automate. I'm a big fan of automation—CFengine, puppet, all those wonderful tools just make administration so much quicker. And, uh, quite often, trying to script that in a Windows environment is … a bit more challenging.
BSDTalk: Yeah, I think we could actually do, probably an entire hour just talking about CFengine and other configuration management systems which are just wonderful.
MS: Yeah. Sure.
BSDTalk: And you must do a lot of that kind of stuff, given the number of machines that you're administering.
MS: Yeah, absolutely, and I think that automation is the way to go. It reduces human error, it makes systems easier to replicate, provides an audit trail… it certainly reduces administration time as well, and far less room for failure, you know. Something fails, you just, you make sure that it, that the configuration is up to date with your CFengine configuration, and it will usually resolve a lot of the issues you might have from manually editing configuration files.
BSDTalk: So are a lot of the machines that you administer similar? Or are they unique machines?
MS: A lot of them are similar simply because a file is … a file server, no matter which office. So, yes, size of client… you, you, […] obviously, you know, different file servers will have different file shares available, but essentially you're going to have the same packages installed. Samba, or whatever file or, you have, or you know, uh, access control you have on that server, and uh, I find the similarities depending on what the machine's going to be used for, be it a web server, mail server, file server, firewall… your configuration is mostly the same just with some minor changes which is why tools such as CFengine and puppet work so well because you can start out with a base image and, and just fine tune for your client's specific needs.
BSDTalk: And are you using Linux usually because of a client request, or is it something that you're also gravitating towards, or is it mostly BSD by your choice? I'm just trying to figure out your mix of operating system.
MS: I would've said, three years ago, Linux primarily simply because that's what I started out with and you just get so used to using that environment, but of late, I have been migrating more towards OpenBSD, NetBSD, I've got probably half, half BSD, half Linux at this stage and becoming more BSD-based because I find BSD, it's a lot more stable, it's a lot more integrated if you like. And it's just… it's, it's easier to, you know, you can say, well, this is a NetBSD 3.0.1 system and you can know roughly what it is, whereas using something like a Debian, you know, there can be so many variations because of, you know, package, different packages installed on systems and so on. I mean, you can, the same applies to NetBSD where if you make major customizations to a system then, it's going to vary, but I find it provides a far more solid base to work from.
BSDTalk: And speaking of packages and variations and stuff like that, what are your thoughts about the relative strengths and weaknesses of the BSD packaging system and update mechanisms?
MS: Uhm, I like Debian's package, package system. There's no way of getting around that. It's just easy, you know, apt-get install whatever, and it's done. But having said that, using a binary packaging system does limit you in some ways. Quite often, if you want Postfix recompiled with various options enabled that maybe aren't enabled by the package maintainers, you'll have to build your own custom packages, and that can get tedious depending on how customized you want them to be.
pkgsrc under NetBSD is wonderful. It's quite easy to build packages and roll them out to systems with CFengine or other automation tools, just from pkgsrc. So I find that works really well.
BSDTalk: I want to thank you very much for agreeing to come on this podcast and talking about your use of BSD and the options for accessibility.
MS: Yeah, no problem! Thank you!
BSDTalk: All right.
If you'd like to leave comments on the website or reach the show archives, you can find them at bsdtalk.blogspot.com, or if you'd like to send me an e-mail, you can reach me at bitgeist@yahoo.com.
[transcribed 04-Sep-2006 by Derek Warren - derek@trideja.com - http://derek.trideja.com/]