Re: [coLinux-devel] potentially bad idea

[Eric S. J. <es...@ha...>]

Gregory M. Turner wrote:

> On Tuesday 06 April 2004 05:53 pm, Eric S. Johansson wrote:
> 
>>I three-quarters understand what you mean.  What I am hearing is that I
>>can run the same kernel both as a guest and native.  
> 
> 
> Maybe, but I am not sure you would want to.  "Everything else" but the kernel 
> sounds more logical to me...  also remember that 2.4 means no NPTL-enabled 
> goodies allowed.

that's closer to what I thought was happening.  You would have all the 
commands and demons be the same and only the kernels would differ.  You 
would have two sets of kernel files in /boot and /lib/modules<kernel{1,2}>.

> Anyhow, there is no reason you couldn't still do something like you describe: 
> follow the standard Gentoo bootstrap instructions, but instead of creating a 
> raw filesystem partition, install to a loopback device which points to your 
> windows filesystem.
> 
> For example, it is possible to use Linux's built in NTFS "write" support 
...
> o Point the coLinux XML file at your ext3/gentoo install
> 
> It should work just fine.

very cool technique.  Trouble is I have a big old partition currently 
filled with mepis that I'm going to replace with gentoo.


>>but I will be paying attention.  This system has some exciting
>>possibilities for enhancing handicap accessibility for Linux.  The big
>>challenge I'm facing is "how do I make speech recognition work on/with
>>Linux".  Today, it's pretty primitive and requires two machines or a
>>continuing investment in VMware.  Cooperative Linux, holds out the
>>possibility of providing a platform where that is not such a big issue.
> 
> 
> Wow, I am extremely surprised there is no such software for Linux... can this 
> really be true?

there are rather primitive pieces out there like Sphinx and some very 
small vocabulary command and control toys.  Anyone who has been injured 
or has lost hand function to such a degree that they need to speak 
instead of type, needs a very large (hundred thousand word) vocabulary 
continuous recognition system.  Usually they also need the ability to 
create their own grammars and actions in order to customize the system 
to their way of working.  For example, I have a reasonably decent 
grammar set for Emacs and Python.  It's not as nice as I would like to 
because of my inability to extract fine detail information about python 
from my development environment.

For example, it would be nice to be able to have available what names 
would be appropriate in a given context so that as I am dictating 
something like:

Zodiac["top"] = inflatable.toy()["bottom"]
at the beginning of the sentence, the vocabulary should be limited to 
all of the known variables, classes, and functions.  Once I've stated 
one of them, based on the type information (i.e. dictionary, list, 
integer etc.) I should have a certain set of choices in this case 
"indexed" which would put me between the square brackets and set the 
vocabulary to list of known indices for that dictionary.  Then the next 
thing with the ether something relating to what is placed into the 
dictionary or "=" which would reset the grammar to the same as the start 
of the line.  I will go through the rest of the line but I think you can 
see that there's a lot of vocabulary shuffling going on and should be 
going on as you dictate the entire line.

this is possible in a primitive way today if only I could get the right 
information.  but this is way off the beaten path here.

> 
> 
>>Of course, ideally I should be able to run this crap under wine but the
>>installer problems are quite persistent.  So we're focusing on making a
>>bridge so that when speech recognition reaches Linux, the infrastructure
>>will be ready for real and not a system created by people whose hands
>>work and really don't understand the problems we face.
> 
> 
> Sorry to hear that wine is not working out for you... e-mail me with the 
> details of the software that you are using and I might be able to help you.

it's usual kernel 100 type errors.  I'm trying to get my other laptop 
running gentoo and something is weird with the CD-ROM set up.  I just 
haven't had enough time to wrestle with it.


>>np, startx works for me.
> 
> 
> "startx" is probably not going to work in coLinux, which has no framebuffer 
> support.  You will need to use a native X server like Cygwin X to get your 
> gui fix in coLinux.

sorry.  I should have said I was comfortable with the text only console 
and host resident Xserver.  and that when I booted native, I did not 
need a graphical console but could type startx all by my lonesome.  I'm 
a *all* grown up.. ;-) usually..

---eric