colinux-devel — Cooperative Linux development mailing list

Re: [coLinux-devel] XML configuration

[<ch...@to...>]

I have not tried it my self but I may give it a try to see what works.
I was just basing my responce on my experience with trying to make
programs that used other programs compiled with cyg.

IMHO vnc would probably be better for coknoppix because of the single file
viewer.

Another thing I was thinking about is that the colinux-daemon may need a
post boot command that you can add to the config file that will run after
it is up and ready to accept the connection.

Or have you already worked out a way to know when to run X so that it is
not coming up before coLinux is ready?

Is there a way to use the tap driver as a standalone program or will it
have to be installed for the live cd to work. It would be so cool if a gui
would just pop up and be ready to go the first time the cd is inserted
with no interaction.

chris

>
>
> Hello Chris and Kerver.
>
> thanks for advise.
>
> I want to confirm one thing -
>   in your env, you can run startx.zip without /cygwin/usr/bin/X11R6 ?
>   for example, you do
>       [Cygwin]$ mv /usr/bin/X11R6 /usr/bin/X11R6.notfound
>   then you can run XWin.exe from startx.zip?
>
> at least, it fails in my env.
> Windows does not complain. Just Xwin.exe fails without any message.
> and I found that font files in /usr/bin/X11R6/lib/X11/fonts are necessary.
> and it also requires /tmp.
>
> To make Cygwin/X installer, I have to fix what is really necessary.
>
> I hope you try it and send me the result.
>
>      thanks in advance, Okajima.
>
>
>>
>>>
>>> and Kerver, I found that your startx.zip needs full Cygwin/X install.
>>> if you dont understand, change your c:/cygwin/usr/bin/X11R6 to other
>>> name.
>>> your zip does not run. you have any idea?
>>>
>>>                  --- Okajima.
>>
>>
>>A little tip I found is that when adding cygwin directories to the
>> windows
>>path add them under user variables not under system variables. That way
>>you can have an account that does not have access to them for testing
>>unless the program finds the file without using PATH
>>
>>Okajima, does windows not complain that it cannot find a certian file?
>>
>>chris
>>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> coLinux-devel mailing list
> coL...@li...
> https://lists.sourceforge.net/lists/listinfo/colinux-devel
>

Re: [coLinux-devel] potentially bad idea

[<ch...@to...>]

> On Wednesday 07 April 2004 04:06, Gregory M. Turner wrote:
>> For example, it is possible to use Linux's built in NTFS "write" support
>> (which actually only supports writing to unencrypted, uncompressed files
>> without changing their size -- but is still just-good-enough for this
>> purpose) under native linux.  Just:
>
> AFAIK understood it it also can do "everything else" but that only
> modifing a
> file without changing its size is save

yes that is the only safe operation but the others are possible


>
>> o mount your NTFS partition in rw mode
>
> maybe the NTFS driver should need a read/modify mode?
>
that would be nice so that people who use it for loopbacks would be a
little safer

there is another project that uses the windows drivers for ntfs but is
kinda legally questionable depending on local laws it is aginst the MS
EULA so you need a local law that overides to use it legally. I have not
tried it but it sounds interesting
http://www.jankratochvil.net/project/captive/
>
>
> Another thing to do for this is modifing linux so fstab points to the
> right
> name depending on a colinux or linux boot. This can probably be done by
> modifing rc.sysinit.
>

check out the topologilinux howTo in the wiki the method of handling fstab
differences and other differences should be adaptable but you will need to
create a do nothing initrd for booting nativly

chris

[coLinux-devel] conoppix

[Digital I. Inc. <ok...@di...>]

I have not read whole thread (it is long!),
but if what you focus is about writing a loop back partition,
I already did it on conoppix.

it can write loop back partition on NTFS.
and probably next version of KNOPPIX has "captive",
which loads genie NTFS.dll on Linux from c:/windows/system32,
so you can write real NTFS, if you have real Windows installed on your C:.

and I have a plan to add a function which is writing read-only partion.
there are two techs for it - COW and Union FS.
I dont decided to which tech to use yet, but anyway,
I will add it in the near future.

                  --- Okajima.



>
>>> 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
>>>
>
>be shure to write only inside an already created loopback file and this
>file should not be a sparce file. Linux can create errors in the
>filesystem if creating a file or deleting it or changing it's size
>
>chris
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IBM Linux Tutorials
>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>GenToo technologies. Learn everything from fundamentals to system
>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>_______________________________________________
>coLinux-devel mailing list
>coL...@li...
>https://lists.sourceforge.net/lists/listinfo/colinux-devel
>

Re: [coLinux-devel] XML configuration

[Digital I. Inc. <ok...@di...>]

Hello Chris and Kerver.

thanks for advise.

I want to confirm one thing -
  in your env, you can run startx.zip without /cygwin/usr/bin/X11R6 ?
  for example, you do
      [Cygwin]$ mv /usr/bin/X11R6 /usr/bin/X11R6.notfound
  then you can run XWin.exe from startx.zip?

at least, it fails in my env.
Windows does not complain. Just Xwin.exe fails without any message.
and I found that font files in /usr/bin/X11R6/lib/X11/fonts are necessary.
and it also requires /tmp.

To make Cygwin/X installer, I have to fix what is really necessary.

I hope you try it and send me the result.

     thanks in advance, Okajima.


>
>>
>> and Kerver, I found that your startx.zip needs full Cygwin/X install.
>> if you dont understand, change your c:/cygwin/usr/bin/X11R6 to other name.
>> your zip does not run. you have any idea?
>>
>>                  --- Okajima.
>
>
>A little tip I found is that when adding cygwin directories to the windows
>path add them under user variables not under system variables. That way
>you can have an account that does not have access to them for testing
>unless the program finds the file without using PATH
>
>Okajima, does windows not complain that it cannot find a certian file?
>
>chris
>

[coLinux-devel] [PATCH] cobuild.sh-200407.patch

[gboutwel <gbo...@pr...>]

This is an minor enhancement on the one that Thomas Fritzsche
sent earlier.



1) it adds cygwin1.dll to the copied files to the newly create
bin directory

2) it allows CO_ROOT to be over-ridden.  I did this to keep the
colinux/bin directory 'clean', and to prepare for tweaking it
to do an colinux for 2.6 port.



Dan - I didn't yet have the cobuild.sh reference the patches
directory for it's patches.  There's a couple issues with this,
basically we have to decided between something like these two...



1) Assume the cobuild.sh is begin run from an bin directory and
../patches will get you to the patches.  No sure this is a 'safe'
or good assumption



2) Download and unpack the colinux-*.tar.gz, 'store' where it's
located.  Then have patches come from CO_SRC/patches directory.



Unless I'm missing something.



Thanks,



George



-------------------------------------------

Looking for Great Christian Shopping Ideas?

http://www.praize.com/shopping/

Re: [coLinux-devel] block device size bug fixed

[Dan A. <da...@co...>]

On Wed, Apr 07, 2004 at 09:47:17PM +0200, Ronald Pijnacker wrote:
> >>Hi Dan,
> >>
> >>Was the 20040406 binary supposed to include this fix? It didn't work for 
> >>me.
> >Yes, it was supposed to. Can you please send me an output by DebugView?
> 
> Gladly, if I only knew what you mean by that.

Extract kernel messages that coLinux emits using the tool at:

    http://www.sysinternals.com/files/dbgvnt.zip

-- 
Dan Aloni
da...@co...

Re: [coLinux-devel] block device size bug fixed

[Ronald P. <pij...@ds...>]

>>Hi Dan,
>>
>>Was the 20040406 binary supposed to include this fix? It didn't work for me.
> Yes, it was supposed to. Can you please send me an output by DebugView?

Gladly, if I only knew what you mean by that.

Ronald.

Re: [coLinux-devel] block device size bug fixed

[Dan A. <da...@co...>]

On Wed, Apr 07, 2004 at 09:20:26PM +0200, Ronald Pijnacker wrote:
> >Many of you who noticed that for cobd* devices which are mapped to raw 
> >partitions or CDROMs, the reported size is 0. Well, turns out that the
> >Windows ZwQueryInformationFile function wasn't behaving as you might 
> >expect.
> >
> >Anyway, I got this fixed today, so expect the next snapshot to include 
> >this fix. No need to patch resierfs anymore.
> >
> >I also changed cobd so that mounts and opens of these block devices 
> >invalidate the caches, so if the media is replaced, no corruption 
> >occurs. 
> 
> Hi Dan,
> 
> Was the 20040406 binary supposed to include this fix? It didn't work for me.

Yes, it was supposed to. Can you please send me an output by DebugView?

-- 
Dan Aloni
da...@co...

Re: [coLinux-devel] block device size bug fixed

[Ronald P. <pij...@ds...>]

Dan Aloni wrote:
> Hello all,
> 
> Many of you who noticed that for cobd* devices which are mapped to raw 
> partitions or CDROMs, the reported size is 0. Well, turns out that the
> Windows ZwQueryInformationFile function wasn't behaving as you might 
> expect.
> 
> Anyway, I got this fixed today, so expect the next snapshot to include 
> this fix. No need to patch resierfs anymore.
> 
> I also changed cobd so that mounts and opens of these block devices 
> invalidate the caches, so if the media is replaced, no corruption 
> occurs. 

Hi Dan,

Was the 20040406 binary supposed to include this fix? It didn't work for me.

Ronald.

Re: [coLinux-devel] potentially bad idea

[andre <avb...@gm...>]

On Wednesday 07 April 2004 04:06, Gregory M. Turner wrote:
> For example, it is possible to use Linux's built in NTFS "write" support
> (which actually only supports writing to unencrypted, uncompressed files
> without changing their size -- but is still just-good-enough for this
> purpose) under native linux.  Just:

AFAIK understood it it also can do "everything else" but that only modifing a 
file without changing its size is save

> o mount your NTFS partition in rw mode

maybe the NTFS driver should need a read/modify mode?



Another thing to do for this is modifing linux so fstab points to the right 
name depending on a colinux or linux boot. This can probably be done by 
modifing rc.sysinit.

Re: [coLinux-devel] potentially bad idea

[<ch...@to...>]

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

be shure to write only inside an already created loopback file and this
file should not be a sparce file. Linux can create errors in the
filesystem if creating a file or deleting it or changing it's size

chris

Re: [coLinux-devel] potentially bad idea

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

keksov wrote:


> Take a look here, may be you'll find something interesting:
> http://www.faqs.org/docs/Linux-HOWTO/Speech-Recognition-HOWTO.html
> 
> And pay closer attention to this one:
> http://www.speech.cs.cmu.edu/sphinx/Sphinx.html

been aware of them for years.  Unfortunately, things like the ViaVoice 
for Linux was a stinking pile of Pooh and Sphinx was far too much of a 
bag of parts that nobody could get really working except the grad 
students themselves.  Sphinx may be changing however.

---eric

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

Re: [coLinux-devel] XML configuration

[<ch...@to...>]

>
> and Kerver, I found that your startx.zip needs full Cygwin/X install.
> if you dont understand, change your c:/cygwin/usr/bin/X11R6 to other name.
> your zip does not run. you have any idea?
>
>                  --- Okajima.


A little tip I found is that when adding cygwin directories to the windows
path add them under user variables not under system variables. That way
you can have an account that does not have access to them for testing
unless the program finds the file without using PATH

Okajima, does windows not complain that it cannot find a certian file?

chris

Re[2]: [coLinux-devel] potentially bad idea

[keksov <ke...@gm...>]

ESJ> What I am hearing is that I can run the same kernel both as a guest and native.

If  you  mean  under the word "same" the version number then yes, you are right.
Actually  it's  very  simple-  the  main part of coLinux is kernel 2.4 with some
patches  applied. You may run it under Windows and native Linux as well. But you
can't boot the native Linux with the same vmlinux file which is used by coLinux.

ESJ> The  only  difference is the device drivers. This is what gets puzzling. It
ESJ> sounds  like  under  cooperative  Linux,  I  use  a different set of device
ESJ> drivers  than  under  native  operations.  Is that correct? For example, to
ESJ> access the CD-ROM, I would use two different sets of drivers.

AFAIK, under coLinux all IDE block devices are accessed via cobd driver. I
remember reports that it's even possible to mount CDROM under Windows as soon as
it's not in use by Windows itself, i.e. no one files opened from it.

Under coLinux It looks like that:
userApp -> coLinux virtualisation driver -> native OS driver (1) -> hardware
Where (1) is either Linux driver or Windows one.

ESJ> somewhat more clarification is needed.  For example, I want to use 
ESJ> gentoo.  Would I start the installation in native mode or in host/guest 
ESJ> mode?  I suspect I would need to install native and then convert to 
ESJ> cooperative Linux.

I have two disks in my system. In pre coLinux times I've installed gentoo as
alternative OS. After discovering coLinux I put the line
<block_device index="0" path="\DEVICE\Harddisk2\Partition1" enabled="true"/>
( /root ) into default.colinux.xml and start coLinux under Windows.

So, it have to be defined what OS is by itself- a kernel only or
a kernel + all daemons and user apps.

ESJ> I also suspect I will need to wait given what I've heard about 2.6 
ESJ> support.  Unfortunately, I really need the sound system support.

As I've mentioned above all devices should be wrapped by coLinux visualization
driver. Please correct me if is's wrong.

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

Take a look here, may be you'll find something interesting:
http://www.faqs.org/docs/Linux-HOWTO/Speech-Recognition-HOWTO.html

And pay closer attention to this one:
http://www.speech.cs.cmu.edu/sphinx/Sphinx.html

>> Sure,  under coLinux you'll not get native graphical console but there were some
>> workarounds mentioned here in the list not far from now, just search archive.

ESJ> np, startx works for me.
Oops... how it looks like? Can you post a screenshot, please?

Regards,
Dim

Re: [coLinux-devel] potentially bad idea

[Gregory M. T. <gmt...@am...>]

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.

> The only difference 
> is the device drivers.  This is what gets puzzling.  It sounds like
> under cooperative Linux, I use a different set of device drivers than
> under native operations.  Is that correct?  For example, to access the
> CD-ROM, I would use two different sets of drivers.

Dunno about CD-ROM access in coLinux; I haven't tried it yet (samba<->NT 
filesharing does all I need there).

> >From technical point of view it's possible, e.g. I have tried exactly the
> > same configuration and it worked fine. In other words - dual boot of your
> > raw Linux installation is possible. The rest depends on your needs.
>
> somewhat more clarification is needed.  For example, I want to use
> gentoo.  Would I start the installation in native mode or in host/guest
> mode?  I suspect I would need to install native and then convert to
> cooperative Linux.

It's too bad, there used to be an image at

http://killashandra.magenet.com/~s0be/

which was custom-made for this purpose.  I used that as a starting point and 
am scooting along happily with gentoo.

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 
(which actually only supports writing to unencrypted, uncompressed files 
without changing their size -- but is still just-good-enough for this 
purpose) under native linux.  Just:

o create a big empty file with cygwin's "dd" or some other technique.

o boot into native Linux

o mount your NTFS partition in rw mode

o create your loopback device pointing at the big empty file

o format the loopback device as ext3

o mount it as /mnt/tmp/

o follow gentoo install instructions from there to the end (except kernel 
parts)

o Boot back into windows

o Point the coLinux XML file at your ext3/gentoo install

It should work just fine.

> I also suspect I will need to wait given what I've heard about 2.6
> support.  Unfortunately, I really need the sound system support.
>
> 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?

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

> > Sure,  under coLinux you'll not get native graphical console but there
> > were some workarounds mentioned here in the list not far from now, just
> > search archive.
>
> 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.

> thanks for the information.

HTH

-- 
gmt

Re: [coLinux-devel] 2.6 kernel ?

[Gregory M. T. <gmt...@am...>]

On Tuesday 06 April 2004 04:37 pm, Dan Aloni wrote:
> On Tue, Apr 06, 2004 at 01:11:04PM -0500, Gregory M. Turner wrote:
> > Looks like I may have been wrong anyhow; the latest snapshots claim 2.6
> > support; looking into it...
> I have to correct you; The latest snapshot can run *under* Linux 2.6.x as
> the host operating system, not *run* Linux 2.6.x as guest.

Aha, thanks for this clarification, which is sure to save me some 
head-scratching time!

> On Tue, Apr 06, 2004 at 07:41:20PM +0200, Jaroslaw Kowalski wrote:
> > Question to Dan: do you plan to port colinux to 2.6?
> That port is just waiting to be done by either me or anyone who volunteer.

I shouldn't volunteer for anything, since I am already slacking at my existing 
volunteer projects.  So, for the moment, I will just stick to heaping praise 
upon the contributing coLinux developers (i.e.: thanks! you are studs!).

A more pressing project might be to fix the known deficiencies in 2.4 coLinux, 
such as the limitations with reiserfs, "raw" partition access, entropy 
gathering for /dev/random, etc., or to help the ReactOS folks with their 
ongoing efforts to make coLinux a Windows subsystem... not that I am 
volunteering for any of those either :-P  Perhaps a good use for the Wiki 
would be to begin sketching out the landscape of un-finished coLinux 
projects....  hmmm...  well, I'd better shut up before I start volunteering 
for things!

virtual beer,

-- 
gmt

Re: [coLinux-devel] conoppix

[Christophe T. <ch...@ae...>]

That's a great idea. About the domain name, I think registering only the
.org would make sense since it's an opensource/GPL initiative. Also, you
could get the "conoppix" project registered on SourceForge for hosting.

-Christophe

----- Original Message ----- 
From: "Digital Infra, Inc." <ok...@di...>
To: "Eric S. Johansson" <es...@ha...>
Cc: <col...@li...>
Sent: Tuesday, April 06, 2004 5:29 PM
Subject: Re: [coLinux-devel] conoppix


>
> I am working on conoppix.
>
> it is KNOPPIX ( CD boot linux) based new linux distribution.
>
> it has three ways to boot -
>
>  1. CD boot
>  2. loop back boot
>  3. coLinux virtual boot
>
> loop back boot is, you can boot from c:/linux/conoppix.compressed.img by
NTLDR.
> and the CD has cygwin/X Japanese installer forked by autorun.inf.
> ( Of course, it can display English).
>
> you put a CD to your Windows box, then a splash screen comes, everything
installed,
> and runs coLinux. any problem?
> I think if you are newbie of Linux,
> you dont have to install gentoo on a raw partition.
>
> and it is easy to make "conoGentoo" or "conoFedra".
> somebody would try it.
>
> BTW, conoppix is just a working title, named by Aloni.
> what name is good?
> luckyly, conoppix.(com|net|org) and conoppix.jp are vacant.
>
>
>             --- Okajima.
>
>
> >I am very intrigued by cooperative Linux at and I would like to try it
> >if I can have the same machine dual boot into Linux for Windows and if I
> >am running on windows, run cooperative Linux off of the dual boot
partition.
> >
> >it seems to me that in order to do this, you would need two kernels and
> >the boot loaders would be configured to load either one or the other
> >depending a context.
> >
> >I will admit that my original thought was to try and install gentoo on
> >the system via a cooperative Linux installed base.  From what I've
> >learned so far, I would say it is possible but not advisable.
> >
> >in any case, the two OS/triple boot model is intriguing for variety of
> >reasons and I'm wondering just how practical is it?
> >
> >---eric
> >
> >
> >
> >-------------------------------------------------------
> >This SF.Net email is sponsored by: IBM Linux Tutorials
> >Free Linux tutorial presented by Daniel Robbins, President and CEO of
> >GenToo technologies. Learn everything from fundamentals to system
> >administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> >_______________________________________________
> >coLinux-devel mailing list
> >coL...@li...
> >https://lists.sourceforge.net/lists/listinfo/colinux-devel
> >
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> coLinux-devel mailing list
> coL...@li...
> https://lists.sourceforge.net/lists/listinfo/colinux-devel

Re: [coLinux-devel] XML configuration

[Digital I. Inc. <ok...@di...>]

I plan to add "extension linkage" ( <- is this right Windows term?).
I will link .elf to coLinux loader.
this is very easy "syntax sugar", but would be useful.

I mean, if there is Apache.img and Apache.xml.elf, 
you can run "real" apache by double clicking Apache.xml.elf.
Probably people think Windows runs Linux binary directly.

is this enough for your demand?

and Kerver, I found that your startx.zip needs full Cygwin/X install.
if you dont understand, change your c:/cygwin/usr/bin/X11R6 to other name.
your zip does not run. you have any idea?

                 --- Okajima.


>
>It would be nice if this tool would have an option to be simular to a 
>'bootloader' (lilo eg) too - so it creates XML files and gives an option 
>to "boot" coLinux based on a dynamic/statically created XML, this would 
>enable to start with different kernels and network/disk configs from 
>within ONE cL folder.
>
>
>Bart
>
>
>>>Would anyone like to volunteer and create a GUI-based .colinux.xml
>>>generator/editor ? It could help new users of coLinux and It doesn't 
>>>require any kernel programming experience in order to be developed.
>>>
>>>I'd prefer if you use the FLTK toolkit. We can later merge it into
>>>the FLTK console so it would appear more like VMware from the aspect
>>>of editing the currently used configuration.
>>>
>>>I'd also thank anyone who can send a patch for the colinux.nsi script
>>>that points the users to the rootfs image download location and 
>>>Wiki site.
>
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IBM Linux Tutorials
>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>GenToo technologies. Learn everything from fundamentals to system
>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>_______________________________________________
>coLinux-devel mailing list
>coL...@li...
>https://lists.sourceforge.net/lists/listinfo/colinux-devel
>

Re: [coLinux-devel] conoppix

[Digital I. Inc. <ok...@di...>]

I am working on conoppix.

it is KNOPPIX ( CD boot linux) based new linux distribution.

it has three ways to boot -

 1. CD boot
 2. loop back boot
 3. coLinux virtual boot

loop back boot is, you can boot from c:/linux/conoppix.compressed.img by NTLDR.
and the CD has cygwin/X Japanese installer forked by autorun.inf.
( Of course, it can display English).

you put a CD to your Windows box, then a splash screen comes, everything installed,
and runs coLinux. any problem?
I think if you are newbie of Linux,
you dont have to install gentoo on a raw partition.

and it is easy to make "conoGentoo" or "conoFedra".
somebody would try it.

BTW, conoppix is just a working title, named by Aloni.
what name is good?
luckyly, conoppix.(com|net|org) and conoppix.jp are vacant.


            --- Okajima.


>I am very intrigued by cooperative Linux at and I would like to try it 
>if I can have the same machine dual boot into Linux for Windows and if I 
>am running on windows, run cooperative Linux off of the dual boot partition.
>
>it seems to me that in order to do this, you would need two kernels and 
>the boot loaders would be configured to load either one or the other 
>depending a context.
>
>I will admit that my original thought was to try and install gentoo on 
>the system via a cooperative Linux installed base.  From what I've 
>learned so far, I would say it is possible but not advisable.
>
>in any case, the two OS/triple boot model is intriguing for variety of 
>reasons and I'm wondering just how practical is it?
>
>---eric
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IBM Linux Tutorials
>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>GenToo technologies. Learn everything from fundamentals to system
>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>_______________________________________________
>coLinux-devel mailing list
>coL...@li...
>https://lists.sourceforge.net/lists/listinfo/colinux-devel
>

Re: [coLinux-devel] TAP - setting interface IP from within XML

[Digital I. Inc. <ok...@di...>]

Come on... Nobody replies. you guys dont want to contribute to the community?
Okay,  I will do it.

           --- Okajima.

>Hello,
>
>For the ease of configuration, in Win32-TAP mode, I'd like coLinux to 
>be able to set the host properties of the network interface: IP address
>netmask, MAC address, etc., according to configuration from the XML.
>
>Any patches are welcomed.
>
>-- 
>Dan Aloni
>da...@co...
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IBM Linux Tutorials
>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>GenToo technologies. Learn everything from fundamentals to system
>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>_______________________________________________
>coLinux-devel mailing list
>coL...@li...
>https://lists.sourceforge.net/lists/listinfo/colinux-devel
>

Re: [coLinux-devel] potentially bad idea

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

keksov wrote:

> IMHO,  as soon as you have the same kernel version under real Linux and may live
> without  device  drivers  apart  bare  minimum  under coLinux/Windows you'll not
> notice  any  significant  difference under both instances of your Linux's boots.

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.  The only difference 
is the device drivers.  This is what gets puzzling.  It sounds like 
under cooperative Linux, I use a different set of device drivers than 
under native operations.  Is that correct?  For example, to access the 
CD-ROM, I would use two different sets of drivers.

> 
>>From technical point of view it's possible, e.g. I have tried exactly the same
> configuration and it worked fine. In other words - dual boot of your raw Linux
> installation is possible. The rest depends on your needs.

somewhat more clarification is needed.  For example, I want to use 
gentoo.  Would I start the installation in native mode or in host/guest 
mode?  I suspect I would need to install native and then convert to 
cooperative Linux.

I also suspect I will need to wait given what I've heard about 2.6 
support.  Unfortunately, I really need the sound system support.

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.

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.

> Sure,  under coLinux you'll not get native graphical console but there were some
> workarounds mentioned here in the list not far from now, just search archive.

np, startx works for me.

thanks for the information.

--- eric

Re: [coLinux-devel] fltk console feature request

[Dan A. <da...@co...>]

On Tue, Apr 06, 2004 at 05:19:42PM +0200, ch...@to... wrote:
> Would it be possible to add a send ctrl alt delete to the Monitor menu of
> the fltk console? I noticed that terminate is a dirty shutdown. Most
> distro's have a ctrl alt delete handler in inittab.

Done. Next snapshot has this.

Ultimately, when I'd get the time to make colinux-daemon comply with the 
Windows Service API, it would do so automatically on Stop.

-- 
Dan Aloni
da...@co...

Re: [coLinux-devel] potentially bad idea

[keksov <ke...@gm...>]

IMHO,  as soon as you have the same kernel version under real Linux and may=
 live
without  device  drivers  apart  bare  minimum  under coLinux/Windows you'l=
l not
notice  any  significant  difference under both instances of your Linux's b=
oots.

From=20technical point of view it's possible, e.g. I have tried exactly the=
 same
configuration and it worked fine. In other words - dual boot of your raw Li=
nux
installation is possible. The rest depends on your needs.

Sure,  under coLinux you'll not get native graphical console but there were=
 some
workarounds mentioned here in the list not far from now, just search archiv=
e.

Regards,
Dim



Tuesday, April 6, 2004, 11:15:07 PM, you wrote:

ESJ> I am very intrigued by cooperative Linux at and I would like to try it=
=20
ESJ> if I can have the same machine dual boot into Linux for Windows and if=
 I=20
ESJ> am running on windows, run cooperative Linux off of the dual boot part=
ition.

ESJ> it seems to me that in order to do this, you would need two kernels an=
d=20
ESJ> the boot loaders would be configured to load either one or the other=
=20
ESJ> depending a context.

ESJ> I will admit that my original thought was to try and install gentoo on=
=20
ESJ> the system via a cooperative Linux installed base.  From what I've=20
ESJ> learned so far, I would say it is possible but not advisable.

ESJ> in any case, the two OS/triple boot model is intriguing for variety of=
=20
ESJ> reasons and I'm wondering just how practical is it?

ESJ> ---eric



ESJ> -------------------------------------------------------
ESJ> This SF.Net email is sponsored by: IBM Linux Tutorials
ESJ> Free Linux tutorial presented by Daniel Robbins, President and CEO of
ESJ> GenToo technologies. Learn everything from fundamentals to system
ESJ> administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3D=
click
ESJ> _______________________________________________
ESJ> coLinux-devel mailing list
ESJ> coL...@li...
ESJ> https://lists.sourceforge.net/lists/listinfo/colinux-devel

Re: [coLinux-devel] Re: Two networking issues

[Dan A. <da...@co...>]

On Tue, Apr 06, 2004 at 10:41:23AM -0700, Robert Pang wrote:
> Hi all
> 
> Just an update. I downloaded and built "pump" in FC1 in coLinux. With pump,
> I can now set up FC1 to talk DHCP. It looks like the kernel that comes with
> 0.6.0 either wasn't compiled with packet filtering that dhclient needs
> (dhclient is what FC1 uses for DHCP), or there is a bug somewhere.

BTW, if you feel that anything rather important is missing from
the default kernel, please send patches against conf/linux-config.

-- 
Dan Aloni
da...@co...