linux music tools It is quite possible and was done all the time in the bad

[Sam Hartman]

>>>>> "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
GUI software.

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.


Installed-Size: 5770

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
for lilypond:

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),
libfreetype6 

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
 Windows.


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


 libltdl7
 (>= 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

 libstdc++
 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

ghostscript

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
music.

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.