linux music tools It is quite possible and was done all the time in the bad
hartmans at mit.edu
Tue Jul 28 22:14:54 UTC 2015
>>>>> "Hart" == Hart Larry <chime at hubert-humphrey.com> writes:
Hart> Good Afternoon Janina: I think Karen prefers useing a DOS
Hart> screen-reader, I think she says its Business Vision. Certainly
Hart> in that context, you remember years ago I inquired if I could
Hart> run Vocal-Eyes in a dos-emulation in Linux? Some of us become
Hart> quite comfortable in an envirenment. While I am certainly not
Hart> knowledgable in %95 of your experiences, I am not sure there
Hart> are right-and-wrong answers here. I have a dear friend who
Hart> used to fix TVs always said, "the customer's always right"
Absoluetly, there are no right or wrong answers.
However, you are responsible for the complexity that your constraints
force onto the solution.
A blind person can use Linux, Windows, Mac, Android or IOS basically out
of the box using screen readers that support the native GUI applications
that the majority of the world uses. As an example on Debian Linux, you
can do a GUI install with a screen reader, use the same desktop
environment, same web browser, one of the same mail readers, same
editors I'd recommend for a sighted person.
That's the path where all the effort is being spent making things
usable; there's a fair bit of development effort being spent on the
screen readers, and lots of effort being spent on the usability of the
You can do something else if you like. The Linux community supports a
lot of options for a lot of people.
however, when you add those additional constraints, you're going to need
to do more work yourself, you're going to find fewer people doing what
you do, you're going to find that you run into more bugs.
You're often going to find that you need to know more to get what
you're doing working.
If you're OK with all that more power to you. Certainly for myself, I
don't use the default mail reader, I tend to use more console apps than
many sighted folks I know, and I tend never to use the standard
installer except when I'm testing it. Sometimes I get to write really
interesting bug reports and patches.
I'm frustrated when I run across people who want it to work their way
but who don't seem to understand the costs of what they are asking. Or
who are taking a very non-standard path and who hope the world will
support it for better accessibility when they've added all sorts of
constraints on top of being blind.
I hope people would have a better appreciation for the effort required
to deliver what they want and think carefully about balancing their
constraints against the resources required to meet those constraints.
Let's take an example of lilypond.
OK, so it's 5 megabytes just for lilypond itself.
That's mostly code, so in all probability no matter how many overlays
you have it's not going to fit into 640 kb.
You might be able to get it to work with djgpp or some other protected
mode environment that allows you to use your computer's full memory
except let's take a look at all the software you need to have working
Depends: guile-1.8-libs, # A fairly unix-specific scheme environment
with lots of unix-ish dependencies
There may be a windows port, but that will depend on a bunch of
facilities not in DOS
libc6 (>= 2.14), # not a big problem hopefully
libfontconfig1 (>= 2.11),
These two aare a bunch of the Linux font machineary. DOS has nothing
like. It's possible that libfreetype6 is moderately portable, although
definitely not portable enough for DOS, but I suspect libfontconfig1 is
going to depend on all sorts of stuff not on DOS. It is available for
libgcc1 (>= 1:4.1.1), #probably not a big deal
libglib2.0-0 (>= 2.12.0),
Absolutely never going to happen for DOS. This is a unix-specific
utility library. Man years of work have gone into the Windows port, and
DOS would be much harder.
libgmp10, # probably not huge
(>= 2.4.2), #DOS doesn't even support shared libraries; non-starter
libpango-1.0-0 (>= 1.18.0), libpangoft2-1.0-0 (>= 1.14.0), #more font
stuff; Windows but not DOS
6 (>= 4.9), #Not a big deal
python, #Available for Windows, DOS port would be hugely hard.
There may be a djgpp port of something old.
guile-1.8, lilypond-data (= 2.18.2-4), #already covered
There are definitely DOS ports of ghostscript, but I suspect they are
quite out of date compared to modern ghostscript. You can probably get
away without ghostscript provided you never want to print or pdf your
I think that lilypond on Windows would likely be doable assuming that
there is GUILE for windows, but not easy. Lilypond on DOS would
basically involve writing much of a modern operating system for DOS.
More information about the Blinux-list