colinux-users — coLinux users mailing list

Re: [coLinux-users] Where is Debian Etch Root Image?

[Henry N. <Hen...@Ar...>]

Hello,

Pooka wrote:
> Recently, Debian's etch stable released but colinux's root
> file system isn't found anywhere. Moreover kernel version
> seems to be different from current coLinux's kernel
> version too. I heard kernel can work with some patch.
> 
>  So Someone please make colinux's etch root FS and kernel,
> and please post them to SourceForge.

Janjaap created a fresh installation.  Many thanks to him!
"Root FS for Debian Release 4 (Etch)
Made using debian-40r0-i386-netinst.iso in Qemu (standard basic
installation) and converted to partition image file for use with coLinux"

I have cleaned and trimmed it down to smaller size (39MB):
http://www.henrynestler.com/colinux/images/Debian-4.0r0-etch.ext3.1gb.bz2

If this is OK, I upload it to SourceForge.  Please give an feedback!

The image was tested on coLinux 0.6.4, 0.7.1 and 0.8.0.
On the older coLinux (<= 0.7.1) you will see an error for udev and
fallback to static directory /dev, that is normal.
Slirp is the first network eth0, users of tap-win32 should edit
/etc/network/interfaces.

Users should run
   apt-get install console-tools
   apt-get install dselect  and/or   apt-get install aptitude
to get a fontend for installing packages.

Janjaap`s, was running under 0.8.0 only and I thought, 170MB was to big
for the compresed file.  I removed a lot:
o Removed all non-essential packages. Compaired the list "dpkg
--get-selections" from Debian 3.0 with 4.0 and removed allmost, that not
exist in the older
(console-common console-data console-tools, busybox, bind9-host,
dictionaries-common, dmidecode, grub, finger, ftp, mpack, mtools, mutt,
openssh-client, patch, portmap, python, tcsh, time, traceroute, ucf,
vim-common, w3m, wget, ...)
o Removed all unused libraries
o Removed all non usable devices from /dev/*
o Removed directories /boot, /lib/modules/*-co-*
o "apt-get clean"
o clean /var/log and directory /root

Some basic fixies have made for coLinux:
o Removed /etc/environment and /etc/default/locale
   (console has no utf-8)
o Comment out all SCREEN_FONT* from /etc/console-tools/config
   (don't support for setfont)
o Added a line "HWCLOCKACCESS=no" to /etc/default/rcS
   (don't support for hwclock)
o eth0 (Slirp) as auto (hotplug is not usable for coLinux <= 0.7.1)
o Slirp with static addresses (works more stable and faster as dhcp)
o Added /dev/cobd[0-7] as fallback for coLinux without udev.
o Changed in /etc/inittab "shutdown ... -h" for halt on CTRL-ALT-DEL

-- 
Henry

Re: [coLinux-users] Xming/XDMPC with SLIRP

[Holger K. <hol...@gm...>]

Brendan Simon schrieb:
> Can I use Xming to connect to gdm on colinux via xdmcp ???

Yes.

> If so, how?

Xming -query your.colinux.ip

>  I can't ping 10.0.2.15 from my DOS prompt.  I don't think 
> the 10.0.2.15 address is visible to Windows is it?

XDMCP uses udp for initial connection. So you will need at least
udp:177:177 to work. The connection to the X-server is done on a
different port (with tcp), i have never used slirp so i don't know what
you will need. Tunneling through ssh may be an option.

[coLinux-users] Xming/XDMPC with SLIRP

[Brendan S. <Br...@Br...>]

Can I use Xming to connect to gdm on colinux via xdmcp ???

If so, how?  I can't ping 10.0.2.15 from my DOS prompt.  I don't think 
the 10.0.2.15 address is visible to Windows is it?

Do I have to modify my eth0 setting in the colinux.conf file?
eg. change:
    eth0=slirp,00:D0:1F:99:88:99,tcp:22:22/tcp:5901:5901
to:
    eth0=slirp,00:D0:1F:99:88:99,tcp:22:22/tcp:5901:5901/tcp:177:177

Thanks, Brendan.

Re: [coLinux-users] How to speed up coLinux

[Mark W. <mar...@gm...>]

I've found VNC pathetically slow compared to X using Xming as a server
(on the Windows side). Using gentoo with the compiler optimizers
cranked up, I've been very happy with the performance of the 0.7.1,
although I've had an unresolved problem of intermittent blue screens
(with days to weeks inbetween).

On 4/22/07, Brendan Simon <Br...@br...> wrote:
> I'm using coLinux and finding the GUI performance painfully slow.  I'd
> like to find some ways to improve the performance, particularly as
> coLinux supposed to execute at "native" speeds.
>
> My configuration is as follows:
>
>     * 0.8.0-devel-20070302 (2.6.17-co-0.8.0)
>     * mem=512
>     * kernel=vmlinux
>     * mem=512
>     * cofs0=c:\
>     * root=/dev/cobd0
>     * ro
>     * eth0=slirp,00:D0:1f:99:88:99,tcp:22:22/tcp:5901:5901
>
>     * Debian Etch distro installed on a real ext3 hard disk partition
>       (ie. not on windows file)
>     * TightVNC with depth 24 and running a gnome session.
>
>     * Laptop, Pentium M, 2GHz, 2GB RAM.
>
>
> Is there any way to speed things up?
> Is SLIRP just terribly slow?
> How much difference would changing the vnc depth to 16 or 8 make?  I'd
> like to avoid that if possible :)
>
> Thanks, Brendan.
>
>
>
>
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> coLinux-users mailing list
> coL...@li...
> https://lists.sourceforge.net/lists/listinfo/colinux-users
>

Re: [coLinux-users] How to speed up coLinux

[Holger K. <hol...@gm...>]

Brendan Simon schrieb:
> 
> One of the things I really like about VNC is that if I loose network 
> connectivity, I can reconnect and not loose my session.  X does not 
> support this as it is session based (maybe things have changed?).  This 
> may not be an issue if using SLIRP or other fixed network addresses ?  I 
> did had this issue when using TAP and DHCP and getting different 
> addresses when taking laptop to and from work.
> 
> But I still don't understand why coLinux or VNC is sooooo slow.  My 
> understanding may be flawed?  Here is my thinking:

If you want to reconnect to a lost X Session use freenx. It keeps the
session and compresses the X11 protocol and reduces the amount of
exchanged packets between client and server. This is extremely useful
with the higher network latency on colinux.

VNC is slow as the X11 Server runs on colinux and the picture gets
transfered to windows as group of pixels. It helps to reduce amount of
possible colors but that is not really a solution. Just try Xming with
xdmcp on Windows to see the difference.

Re: [coLinux-users] How to speed up coLinux

[Michael L. <gm...@cm...>]

Brendan Simon <Br...@Br...>
writes:

> Is SLIRP just terribly slow?

slirp is just terribly slow, yes, and I don't think its speed can
really be improved.

if TAP works for you (it never did for me, but perhaps other people
are luckier?), by all means use that.  I'd hazard a guess that all the
slowness you perceive is down to the network overhead, at least as
long as you are not trying to play movies or something.

hth,
--m

Re: [coLinux-users] How to speed up coLinux

[Sam M. <pa...@gm...>]

There is an X server implementation that does that but I'm not sure
how it would go performance wise, NXHost or something like that.  VNC
is handy like that but again you get a performance hit, but to a point
we expect that and its the trade off (since all your applications are
speaking X to VNC and then VNC translates this to bitmap and shunts it
over the network, speaking straight X cuts out the VNC layer).

wrt to network I/O there are some good threads historically about
makng coLinux shift the bytes faster, have to remember that even
though there is no real networking hardware involved you're still
creating and decoding a packet on the same box, so in a way you have
twice the CPU cost on top of the obvious cost in using virtual
interfaces (and the relevant context switches). The numbers really
start to add up quickly all over the place and a lot of it is
unfortunately unavoidable.

Sam

On 22/04/07, Brendan Simon <Br...@br...> wrote:
> Thanks Sam.  I will take a look at Xming.
>
> One of the things I really like about VNC is that if I loose network
> connectivity, I can reconnect and not loose my session.  X does not
> support this as it is session based (maybe things have changed?).  This
> may not be an issue if using SLIRP or other fixed network addresses ?  I
> did had this issue when using TAP and DHCP and getting different
> addresses when taking laptop to and from work.
>
> But I still don't understand why coLinux or VNC is sooooo slow.  My
> understanding may be flawed?  Here is my thinking:
>
>     If I have a second PC running Linux and a VNC server, and connect
>     from a MSW box using a VNC server over a 100Mbps network, I get much
>     much better performance than if I use MSW/Colinux.  I'd expect
>     coLinux to get similar performance (or at least close).
>
>     Assumption: given the two OSes are on the same machine I would
>     expect network throughput would be better than two separate
>     machines.  However, I think the using the network support
>     (particulary slirp) in coLinux is as slow, if not slower, than a
>     real network
>
>     Maybe because both host OS and guess OS are so resource intensive
>     that the performance hit is extremely noticeable.  If that is the
>     case, then using any virtual OS would seem to useful only for
>     playing and doing basic things.
>
>
> Thanks, Brendan.
>
>
> Sam Moffatt wrote:
> > First of all ditch TightVNC, you're not going to get decent
> > performance out of that and I'd suggest moving to an X server. Not
> > only will it improve network items, it will improve over all
> > performance.
> >
> > Xming is one I use that doesn't have too many issues. You can either
> > use XDMCP to connect in or use PuTTY with X forwarding. Again, you're
> > not going to get full native speeds from any GUI app as VNC has its
> > own repaint events (since it sends bitmaps) and Xming does a large
> > amount of context switches but network transfers are far more
> > efficient.
> >
> > Sam
> >
> > On 22/04/07, Brendan Simon <Br...@br...> wrote:
> >> I'm using coLinux and finding the GUI performance painfully slow.  I'd
> >> like to find some ways to improve the performance, particularly as
> >> coLinux supposed to execute at "native" speeds.
> >>
> >> My configuration is as follows:
> >>
> >>     * 0.8.0-devel-20070302 (2.6.17-co-0.8.0)
> >>     * mem=512
> >>     * kernel=vmlinux
> >>     * mem=512
> >>     * cofs0=c:\
> >>     * root=/dev/cobd0
> >>     * ro
> >>     * eth0=slirp,00:D0:1f:99:88:99,tcp:22:22/tcp:5901:5901
> >>
> >>     * Debian Etch distro installed on a real ext3 hard disk partition
> >>       (ie. not on windows file)
> >>     * TightVNC with depth 24 and running a gnome session.
> >>
> >>     * Laptop, Pentium M, 2GHz, 2GB RAM.
> >>
> >>
> >> Is there any way to speed things up?
> >> Is SLIRP just terribly slow?
> >> How much difference would changing the vnc depth to 16 or 8 make?  I'd
> >> like to avoid that if possible :)
> >>
> >> Thanks, Brendan.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> -------------------------------------------------------------------------
> >>
> >> This SF.net email is sponsored by DB2 Express
> >> Download DB2 Express C - the FREE version of DB2 express and take
> >> control of your XML. No limits. Just data. Click to get it now.
> >> http://sourceforge.net/powerbar/db2/
> >> _______________________________________________
> >> coLinux-users mailing list
> >> coL...@li...
> >> https://lists.sourceforge.net/lists/listinfo/colinux-users
> >>
>
>

Re: [coLinux-users] How to speed up coLinux

[Brendan S. <Br...@Br...>]

Thanks Sam.  I will take a look at Xming.

One of the things I really like about VNC is that if I loose network 
connectivity, I can reconnect and not loose my session.  X does not 
support this as it is session based (maybe things have changed?).  This 
may not be an issue if using SLIRP or other fixed network addresses ?  I 
did had this issue when using TAP and DHCP and getting different 
addresses when taking laptop to and from work.

But I still don't understand why coLinux or VNC is sooooo slow.  My 
understanding may be flawed?  Here is my thinking:

    If I have a second PC running Linux and a VNC server, and connect
    from a MSW box using a VNC server over a 100Mbps network, I get much
    much better performance than if I use MSW/Colinux.  I'd expect
    coLinux to get similar performance (or at least close).

    Assumption: given the two OSes are on the same machine I would
    expect network throughput would be better than two separate
    machines.  However, I think the using the network support
    (particulary slirp) in coLinux is as slow, if not slower, than a
    real network

    Maybe because both host OS and guess OS are so resource intensive
    that the performance hit is extremely noticeable.  If that is the
    case, then using any virtual OS would seem to useful only for
    playing and doing basic things.


Thanks, Brendan.


Sam Moffatt wrote:
> First of all ditch TightVNC, you're not going to get decent
> performance out of that and I'd suggest moving to an X server. Not
> only will it improve network items, it will improve over all
> performance.
>
> Xming is one I use that doesn't have too many issues. You can either
> use XDMCP to connect in or use PuTTY with X forwarding. Again, you're
> not going to get full native speeds from any GUI app as VNC has its
> own repaint events (since it sends bitmaps) and Xming does a large
> amount of context switches but network transfers are far more
> efficient.
>
> Sam
>
> On 22/04/07, Brendan Simon <Br...@br...> wrote:
>> I'm using coLinux and finding the GUI performance painfully slow.  I'd
>> like to find some ways to improve the performance, particularly as
>> coLinux supposed to execute at "native" speeds.
>>
>> My configuration is as follows:
>>
>>     * 0.8.0-devel-20070302 (2.6.17-co-0.8.0)
>>     * mem=512
>>     * kernel=vmlinux
>>     * mem=512
>>     * cofs0=c:\
>>     * root=/dev/cobd0
>>     * ro
>>     * eth0=slirp,00:D0:1f:99:88:99,tcp:22:22/tcp:5901:5901
>>
>>     * Debian Etch distro installed on a real ext3 hard disk partition
>>       (ie. not on windows file)
>>     * TightVNC with depth 24 and running a gnome session.
>>
>>     * Laptop, Pentium M, 2GHz, 2GB RAM.
>>
>>
>> Is there any way to speed things up?
>> Is SLIRP just terribly slow?
>> How much difference would changing the vnc depth to 16 or 8 make?  I'd
>> like to avoid that if possible :)
>>
>> Thanks, Brendan.
>>
>>
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------- 
>>
>> This SF.net email is sponsored by DB2 Express
>> Download DB2 Express C - the FREE version of DB2 express and take
>> control of your XML. No limits. Just data. Click to get it now.
>> http://sourceforge.net/powerbar/db2/
>> _______________________________________________
>> coLinux-users mailing list
>> coL...@li...
>> https://lists.sourceforge.net/lists/listinfo/colinux-users
>>

Re: [coLinux-users] How to speed up coLinux

[Sam M. <pa...@gm...>]

First of all ditch TightVNC, you're not going to get decent
performance out of that and I'd suggest moving to an X server. Not
only will it improve network items, it will improve over all
performance.

Xming is one I use that doesn't have too many issues. You can either
use XDMCP to connect in or use PuTTY with X forwarding. Again, you're
not going to get full native speeds from any GUI app as VNC has its
own repaint events (since it sends bitmaps) and Xming does a large
amount of context switches but network transfers are far more
efficient.

Sam

On 22/04/07, Brendan Simon <Br...@br...> wrote:
> I'm using coLinux and finding the GUI performance painfully slow.  I'd
> like to find some ways to improve the performance, particularly as
> coLinux supposed to execute at "native" speeds.
>
> My configuration is as follows:
>
>     * 0.8.0-devel-20070302 (2.6.17-co-0.8.0)
>     * mem=512
>     * kernel=vmlinux
>     * mem=512
>     * cofs0=c:\
>     * root=/dev/cobd0
>     * ro
>     * eth0=slirp,00:D0:1f:99:88:99,tcp:22:22/tcp:5901:5901
>
>     * Debian Etch distro installed on a real ext3 hard disk partition
>       (ie. not on windows file)
>     * TightVNC with depth 24 and running a gnome session.
>
>     * Laptop, Pentium M, 2GHz, 2GB RAM.
>
>
> Is there any way to speed things up?
> Is SLIRP just terribly slow?
> How much difference would changing the vnc depth to 16 or 8 make?  I'd
> like to avoid that if possible :)
>
> Thanks, Brendan.
>
>
>
>
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> coLinux-users mailing list
> coL...@li...
> https://lists.sourceforge.net/lists/listinfo/colinux-users
>

[coLinux-users] How to speed up coLinux

[Brendan S. <Br...@Br...>]

I'm using coLinux and finding the GUI performance painfully slow.  I'd 
like to find some ways to improve the performance, particularly as 
coLinux supposed to execute at "native" speeds.

My configuration is as follows:

    * 0.8.0-devel-20070302 (2.6.17-co-0.8.0)
    * mem=512
    * kernel=vmlinux
    * mem=512
    * cofs0=c:\
    * root=/dev/cobd0
    * ro
    * eth0=slirp,00:D0:1f:99:88:99,tcp:22:22/tcp:5901:5901

    * Debian Etch distro installed on a real ext3 hard disk partition
      (ie. not on windows file)
    * TightVNC with depth 24 and running a gnome session.

    * Laptop, Pentium M, 2GHz, 2GB RAM.


Is there any way to speed things up?
Is SLIRP just terribly slow?
How much difference would changing the vnc depth to 16 or 8 make?  I'd 
like to avoid that if possible :)

Thanks, Brendan.

[coLinux-users] Etch from scratch directions

[George P B. <geo...@gm...>]

I've updated/modified the building Sarge from scratch instructions on
the wiki for Etch.  I've got an 768Mb 'base' Etch install, I'll be using
it to create an larger (1g-2gish) and to add some more packages to this
minimal version.  But if you can't wait or want to do it yourself the
guide at the wiki should get you started.

George

[coLinux-users] CoLinux logo

[David H. L. Jr. <dh...@dl...>]

    I am completing an article on coLinux for embedded developers.

    I would like to include the coLinux Ying/Yang image in the article.
    Where would I find a reasonable resolution version of the image
    as well as some notice a publish would consider sufficient as
permission to use ?


Thanks.
   




-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.627.3770 	       dh...@dl... 	  http://www.dlasys.net
fax: 1.253.369.9244 			           Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.

"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein

Re: [coLinux-users] Sound

[Robert I. <and...@ho...>]

 > Yes, I've already done all of that and it reduce latency but it's not> r=
eal time ...
I think at the present time thats about the best your gonna get!
=20
> Yes ! With if the VNCaudio can ctach a stream from a virtual sound> card,=
 why does forward it throught the network .... If the colinux> process can =
mount win dir (cofs) into linux, it can catch this stream> to play on Windo=
ws ....
=20
I'm thinking less like cofs, more like the networking and console support. =
 I would imagine using cofs would generate a lot of disk through-put.  My u=
nderstanding at present, as I've never really looked at the source ;), is t=
hat the daemon catches serial output to display on the console.  What we re=
ally would want is a daemon which catches the line-out to receive pure anal=
og? output or a digital output to receive PCM data which could be sent stra=
ight to the real sound card on the host.
=20
I downloaded the source code of a recent snapshot, coLinux-0.7.1-20070326-s=
rc.tar.gz, from SourceForge and the, rather old, source code to VNCAudio an=
d in opening one file, vncsound.c in the viewer there is a tiny little prob=
lem...it's all for a linux client.  I'm going to have a look at the actual =
virtual sound card side of things to see how it is done first to firstly se=
e how it is done and secondly to see if my skills are up to the job.  I'm s=
till pretty new to programming :( and even newer to coding anything for Lin=
ux. > VNCAudio, if it can work with recent kernel and vnc version, is just =
a> way for me. Not a real solution ! In Colinux, the VNCserver is just> one=
 of the possible solution to have a display. But there are many> more : Xse=
rver on windows in one windows, multiple windows, ssh -X ...> And if someon=
e wan't to run an app in console to play sound (mpg123,> mpd ...) ? It must=
 a solution not depending on the VNCAudio. But it> can be a good temporary =
solution
Yeah, VNC was my original solution, then Cygwin/X using XDMCP and then Cygw=
in/X using X over SSH using Putty.
_________________________________________________________________
Try Live.com - your fast, personalized homepage with all the things you car=
e about in one place.
http://www.live.com/getstarted=

Re: [coLinux-users] Sound

[Julien L. <jul...@gm...>]

2007/4/18, Robert Irvin <and...@ho...>:
>
>  I would have posted this through the lists, but hotmails fudged up my
> preferences and as a result I only receive bounce announcement :( I would=
 be
> grateful if you could forward this to the lists so everyone else can read
> it.

Ok I'll forward it to the ml. But if you want a long time solution,
you can easily create a Google Mail account : it's free and more
useful and secure than Microsoft emails ....

>  Anyway, I'm pretty sure I was the person who originally wrote the bit on
> the http://colinux.wikia.com/wiki/Sound_support_in_Colinux
> page about getting artsd to work, when the original wiki was hosted on
> colinux.org, before the wiki software was updated to MoinMoin? if I
> remember.  Point is...it was a long time ago.

Ok, I ws sure of that :D

>  Arts configuration was always a pain in the neck.  Different distributio=
ns
> provide different output plugins for Arts, and in some cases esd output
> support was not compiled into arts.  This I only found out after getting
> each distro configured and up and running, which is why I stuck to Gentoo=
.
> You appear to have been lucky in your distro choice!

It's a kunbuntu based distro ... Arts is correctly set up.


>  There are a few different I tried to achieve better performance.  Firstl=
y,
> in the KDE Control Centre there is an option for Skip Prevention, basical=
ly
> the buffer size.  This, if I remember correctly is the amount of informat=
ion
> stored before playback is started.  Bigger buffer =3D bigger delay.  You =
could
> try reducing this value to see if you could reduce the latency a little.
> Best pic of the screen I could find, unfortunately with options greyed ou=
t:
>  http://www.tomahawkcomputers.com/images/Sound-System.png
>
>  Under the hardware tab there are some options for changing the sample ra=
te,
> can't remember if these settings work or not.  If not there is an option =
for
> ESD you can set.  Lowering the sample rate will lower the amount of data
> being transferred, but it will also lower the sound quality.  Same for th=
e
> -b ESD option which causes 8 bits per sample rather than 16.

Yes, I've already done all of that and it reduce latency but it's not
real time ...


>  Your idea about CoLinux "catching" the stream isn't really that much
> different to the ideas used for implementing a frame buffer in CoLinux.  =
The
> stream I suppose could be written to a predefined portion of shared memor=
y
> by the Guest OS and then read and processed by the host OS.

Yes ! With if the VNCaudio can ctach a stream from a virtual sound
card, why does forward it throught the network ....  If the colinux
process can mount win dir (cofs) into linux, it can catch this stream
to play on Windows ....

>  This is the first time I've heard of VNCAudio, and to be perfectly hones=
t,
> I like the idea.  I'm only a beginner when it comes to programming and th=
is
> is a little above my head, but surely having a virtual soundcard as oppos=
ed
> to a daemon running in the host has to be much better.  Latency wise, I h=
ave
> no idea how it would fare, probably not much different.  Compatibility wi=
se
> I can only think it would be greatly improved.  It does however state tha=
t
> it is a virtual OSS soundcard.  How this would relate to ALSA I'm not sur=
e.
> As long as an ALSA driver worked then the majority of audio applications
> could work as opposed to the limited amount that use ESD, NAS or ARTS.

VNCAudio, if it can work with recent kernel and vnc version, is just a
way for me. Not a real solution ! In Colinux, the VNCserver is just
one of the possible solution to have a display. But there are many
more : Xserver on windows in one windows, multiple windows, ssh -X ...
And if someone wan't to run an app in console to play sound (mpg123,
mpd ...) ? It must a solution not depending on the VNCAudio. But it
can be a good temporary solution


>  I don't know if any of this will be of any use but maybe it will.  I kee=
p
> meaning to get back into CoLinux to see how much it has improved.  I left=
 of
> using it when it moved to 2.6.10/2.6.11 kernel, opting to stick to a earl=
ier
> 2.6.8.1 snapshot because of performance issues.  When XP killed it own
> kernel? I didn't re-install it but have been looking at possible installi=
ng
> CoLinux and andLinux lately.
>

>
> > Date: Wed, 18 Apr 2007 10:44:03 +0200
> > From: jul...@gm...
> > To: col...@li...
> > Subject: [coLinux-users] Sound
> >
> > Hi,
> >
> > I'm trying to deploy a colinux service with a specific distro. And
> > i've some problem with sound.
> >
> > As it's write on the wiki as
> > http://colinux.wikia.com/wiki/Sound_support_in_Colinux,
> there are 3
> > means to have a sound support into colinux :
> >
> > - ESD server on Windows and redirect sound into colinux with
> > ESPEAKER env var. In my system, all the sound is managed with arts. So
> > I configured arts to set ouput on ESD and in /etc/environnement, I
> > declared ESPEAKER=3Dip:port. After a reboot (or a env update), all my
> > sound system is redirect on my Windows, so I launched an ESD server
> > and i listened music and alert sound system. But I've too much
> > latency ! There is more than 2 seconds ...
> >
> > - Icecast/shoutcast : this solution is more interessant cause the
> > stream is in OGG/MP3. So i tested : arts -> local esd server -> esdmon
> > to catch the esd sound | ices ------> icecast ----> windows ogg/mp3
> > player. Result : I've more and more lantecy : I've same latency cause
> > the esd redirect plus the icecast management which is not designed to
> > do Real Time transport.
> >
> > - I don't wan't use the NX solution because NX utilisation is
> > difficult and there are not full open sources solution. But when i
> > tested, there was latency too. And this is not a surprise cause NX use
> > esd /arts redirection ...
> >
> > So I explored all solution of the wiki and there are none usefull.
> >
> > Is there anyone who has less latency than me ?
> >
> > Others ways :
> >
> > - VNCAudio : there is an old implementation project here :
> > http://linux-workshop.com/bybell/vnc/vncaudio.html. It's
> based of a
> > virtual sound card (oss driver) which allow to a vnc process to easily
> > catch the stream. I'm trying to use it.
> >
> > - what's it's not possible to have native sound into colinux ? If we
> > can catch the stream, does the colinux process can see it and listen
> > into the windows ? (excuse this naive question, I've not any knowledge
> > about how colinux works...).
> > My last naive question : is it not possible to stream sound into a
> > pipe file placed in a cofs dir to allow to a Windows process to cactch
> > and listen it ?
> >
> > thanks a lot, i apologize for my English ... (I'm french)
> > --
> > _____________________________________________
> > Julien LANGLOIS
> > - page web : http://julienlanglois.free.fr
> > - cl=E9 gpg : http://julienlanglois.free.fr/julien.gpg
> > _____________________________________________
> >
> >
> -------------------------------------------------------------------------
> > This SF.net email is sponsored by DB2 Express
> > Download DB2 Express C - the FREE version of DB2 express and take
> > control of your XML. No limits. Just data. Click to get it now.
> > http://sourceforge.net/powerbar/db2/
> > _______________________________________________
> > coLinux-users mailing list
> > coL...@li...
> >
> https://lists.sourceforge.net/lists/listinfo/colinux-users
>
>
> ________________________________
> With Live Spaces email straight to your blog. Upload jokes, photos and mo=
re.
> It's free! It's free!


--=20
_____________________________________________
Julien LANGLOIS
 - page web : http://julienlanglois.free.fr
 - cl=E9 gpg : http://julienlanglois.free.fr/julien.gpg
_____________________________________________

Re: [coLinux-users] colinux & debian etch

[George P B. <geo...@gm...>]

baldyeti wrote:
> Pretty mysterious to me too, hence my questions here ;-)
> I think I read that etch will only use udev for fresh installs,
> not when upgrading, which would explain what you're seeing.
> Ideally I'd do a fresh install to say hdc11. But then how do
> I find the proper device alias for colinux (the wiki instructions
> are kinda hazy). Other than that, i'll try to backup, then simply
> let the upgrade run and see what happens...
>   

At the risk of getting way off-topic here...  and with this
'disclaimer':  this is MY UNDERSTANDING of it and it may not be complete
or 100% accurate...

  udev is a replacement for devfs, which was weighed and found wanting. 
udev like devfs determines device nodes more or less dynamically by what
the device drivers in the Linux kernel report or register back with the
kernel.  The major difference between devfs and udev is that udev is
largely a user program with a much, much smaller kernel footprint (ie
code that runs in the kernel/as a module).  There where bugs in the
early forms of udev, such that only more recent kernels (I believe magic
kernel that most have settled on for 'proper' udev support is anything
beyond 2.6.16).  You need not only udev support in the kernel, but a
udev program that runs early in the boot process.  I believe that unless
you particularly want udev, you can always bypass it/get around it by
manually creating the device nodes that you need.  Additionally, most
the udev configurations allow 'static' or force devices, although those
shouldn't be necessary for coLinux dives as they generally make the
necessary calls to the kernel to 'register' with devfs and/or udev.

  How this all this relates to coLinux... newer distros that are
requiring udev & forcing an reasonable kernel version will require
coLinux 0.8.0-based kernels or the udev daemon (if they don't do a
kernel version check) be configured to have the same device nodes as
you'd have if you weren't using udev, or udev disabled.  If they do
kernel version checks, you will need to work around this (if possible)
if not, then you have to use 0.8.0-based experimental version of your uses.

  Again this is my basic understanding of things and not a complete
anthology, there is lots of information on the web on udev, configuring
it, etc.  For the real scoop, do a little light digging in this
information and be enlightened. :)

George

[coLinux-users] RE colinux & debian etch

[peter g. <plu...@p1...>]

> message from apt-get install <package>:
> E: This installation run will require temporarily removing the =
essential=20
> package e2fsprogs due to a Conflicts/Pre-Depends loop. This is often =
bad,=20
> but if you really want to do it, activate the APT::Force-LoopBreak =
option.
> E: Internal Error, Could not early remove e2fsprogs
> shoudn't be the e2fsprogs after the update/upgrade to etch the=20
> right version?
try doing

apt-get -o 'APT::Force-LoopBreak=3D1' dist-upgrade

--=20
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.446 / Virus Database: 269.5.2/766 - Release Date: =
18/04/2007 07:39

Re: [coLinux-users] colinux & debian etch

[David K. <da...@gi...>]

Hi Wolfram,

Wolfram Wadepohl <Wol...@ek...> wrote:
>> I [...] replaced "stable" with "sarge", ran "apt-get update" and
>> "apt-get upgrade" [...] washed rinsed and repeated....
>
> so do i. but ... i get the error message:
> E: This installation run will require temporarily removing the
> essential package e2fsprogs due to a Conflicts/Pre-Depends loop. This
> is often bad, but if you really want to do it, activate the
> APT::Force-LoopBreak option. E: Internal Error, Could not early
> remove e2fsprogs shoudn't be the e2fsprogs after the update/upgrade
> to etch the right version?

I got that too.

The coLinux Wiki mentioned a workaround that worked around for me, too:
http://colinux.wikia.com/wiki/DebianRootFsImages

Also, the Debian etch Release Notes has a (very long but very 
informative) page on upgrade issues that helps with problems such as 
this:
http://www.debian.org/releases/etch/i386/release-notes/ch-upgrading.en.html#s-trouble

Hope this helps!

-dave 

[coLinux-users] Sound

[Julien L. <jul...@gm...>]

Hi,

I'm trying to deploy a colinux service with a specific distro. And
i've some problem with sound.

As it's write on the wiki as
http://colinux.wikia.com/wiki/Sound_support_in_Colinux, there are 3
means to have a sound support into colinux :

 - ESD server on Windows and redirect sound into colinux  with
ESPEAKER env var. In my system, all the sound is managed with arts. So
I configured arts to set ouput on ESD and in /etc/environnement, I
declared ESPEAKER=3Dip:port. After a reboot (or a env update), all my
sound system is redirect on my Windows, so I launched an ESD server
and i listened music and alert sound system.  But I've too much
latency ! There is more than 2 seconds ...

 - Icecast/shoutcast : this solution is more interessant cause the
stream is in OGG/MP3. So i tested : arts -> local esd server -> esdmon
to catch the esd sound | ices ------> icecast ----> windows ogg/mp3
player. Result : I've more and more lantecy : I've same latency cause
the esd redirect plus the icecast management which is not designed to
do Real Time transport.

 - I don't wan't use the NX solution because NX utilisation is
difficult and there are not full open sources solution. But when i
tested, there was latency too. And this is not a surprise cause NX use
esd /arts redirection ...

So I explored all solution of the wiki and there are none usefull.

Is there anyone who has less latency than me ?

Others ways :

 - VNCAudio : there is an old implementation project here :
http://linux-workshop.com/bybell/vnc/vncaudio.html. It's based of a
virtual sound card (oss driver) which allow to a vnc process to easily
catch the stream. I'm trying to use it.

 - what's it's not possible to have native sound into colinux ? If we
can catch the stream, does the colinux process can see it and listen
into the windows ? (excuse this naive question, I've not any knowledge
about how colinux works...).
My last naive question : is it not possible to stream sound into a
pipe file placed in a cofs dir to allow to a Windows process to cactch
and listen it ?

thanks a lot,  i apologize for my English ... (I'm french)
--=20
_____________________________________________
Julien LANGLOIS
 - page web : http://julienlanglois.free.fr
 - cl=E9 gpg : http://julienlanglois.free.fr/julien.gpg
_____________________________________________

Re: [coLinux-users] colinux & debian etch

[baldyeti <e_...@ho...>]

> I don't know how to make a snapshot out of this installation or 
> otherwise share it with others, but it is *apparently* working just fne 
> with the older kernel and no "udevs".  I confess that I don't know what 
> exactly a udev is though, or if mine is or isn't working :-) 

Pretty mysterious to me too, hence my questions here ;-)
I think I read that etch will only use udev for fresh installs,
not when upgrading, which would explain what you're seeing.
Ideally I'd do a fresh install to say hdc11. But then how do
I find the proper device alias for colinux (the wiki instructions
are kinda hazy). Other than that, i'll try to backup, then simply
let the upgrade run and see what happens...

Re: [coLinux-users] colinux & debian etch

[Wolfram W. <Wol...@ek...>]

David Kaufman schrieb:
> I changed /etc/apt/sources.list, commented out the backports lines,=20
> replaced "stable" with "sarge", ran "apt-get update" and "apt-get=20
> upgrade".  This brought sarge up-to-date.  Then I changed=20
> /etc/apt/sources.list again, replacing "sarge" with "etch", washed=20
> rinsed and repeated ("apt-get update" and "apt-get upgrade" again).

so do i. but the result did not satisfy me.
every time i want to install a new package (mc for example) i get the err=
or=20
message from apt-get install <package>:
E: This installation run will require temporarily removing the essential =

package e2fsprogs due to a Conflicts/Pre-Depends loop. This is often bad,=
=20
but if you really want to do it, activate the APT::Force-LoopBreak option=
=2E
E: Internal Error, Could not early remove e2fsprogs
shoudn't be the e2fsprogs after the update/upgrade to etch the right vers=
ion?


--=20
Sch=F6ne Gr=FC=DFe aus Reutlingen

Wolfram Wadepohl
Forschung & Entwicklung

E&K AUTOMATION
Indumat GmbH & Co. KG
Siemensstra=DFe 3
72766 Reutlingen
Deutschland

Tel.  +49 7121 514-289
Fax   +49 7121 514-299
eMail Wol...@ek...
       W.W...@in...
       W.W...@ie...
WWW   http://www.ek-automation.com
       http://www.indumat.de

Diese Nachricht ist keine gesch=E4ftliche Mitteilung i. S. des EHUG.

Bitte senden Sie mir keine Word- oder PowerPoint- (tm Microsoft) Anh=E4ng=
e.
Senden Sie mir einfachen Text, HTML oder PDF.
Siehe http://www.gnu.org/philosophy/no-word-attachments.de.html

Re: [coLinux-users] colinux & debian etch

[Henry N. <Hen...@Ar...>]

George P Boutwell wrote:
> Henry Nestler wrote:
>> CoLinux versions 0.6.4, 0.7.1 and 0.8.0 runs also on my SuSE 9.0 dual 
>> boot with an original 2.4.21 kernel.  From my SuSE I know, that you can 
>> run every coLinux on an older distry.  For very old distries with kernel 
>> 2.4.x you need to upgrade only the module-init-tools with fallback for 
>> 2.4-kernels.
>>   
> You saying that he SuSE original kernel was 2.4.21 or that you have an
> unofficial colinux patched 2.4.21 kernel?

no, no. ;-)
I'm running only the coLinux 2.6.x kernels from 2.6.12 to 2.6.17 there.
The module-init-tools have updated for my SuSE.

The fallback is for native Linux boot with suSE kernel 2.4.21-default.

-- 
Henry

Re: [coLinux-users] colinux & debian etch

[David K. <da...@gi...>]

Hi George,

George P Boutwell <geo...@gm...> wrote:
> I recently tried to follow the debian install steps from the wiki to
> create a new etch image, but apparently there are additional
> requirements to get it to work for installing.  I don't know at this
> point what those requirements are.  I don't know if there's some
> command-line we can give it that will allow it to run without udev or
> if udev is going to be needed, or if it's an file system that we need
> support but don't have.  I haven't gotten that far.  I just know I
> wasn't able to follow the steps there to get it working.  I was able
> to start with the iso and initrd set, but I wasn't able to mount them
> (I tried with aliases and without and I wasn't able to mount them, but
> haven't gotten so far as to creating the block devices necessary to
> see if that gets around that problem).  This is for trying to great
> an etch image file, not for dual-booting, of course.

I'm running Debian etch on colinux -- last night I installed a fresh 
0.7.1 colinux (with its 2.6.12-co-0.7.1 kernel) and the old debian image 
Debian-3.0r2.ext3-mit-backports.1gb.bz2 and then updated it to sarge 
(the old stable) and then to etch (the new stable).

I changed /etc/apt/sources.list, commented out the backports lines, 
replaced "stable" with "sarge", ran "apt-get update" and "apt-get 
upgrade".  This brought sarge up-to-date.  Then I changed 
/etc/apt/sources.list again, replacing "sarge" with "etch", washed 
rinsed and repeated ("apt-get update" and "apt-get upgrade" again).

I don't know how to make a snapshot out of this installation or 
otherwise share it with others, but it is *apparently* working just fne 
with the older kernel and no "udevs".  I confess that I don't know what 
exactly a udev is though, or if mine is or isn't working :-) ...but the 
webserver, ssh and mysql all all working fine for me (I don't run X, 
access any of my windows USB devices from colinux or dual-boot though, 
if that matters).

If someone could help me help others by creating a snapshot... I'd be 
glad to pitch in and share!

-dave

Re: [coLinux-users] colinux & debian etch

[Jun O. <ok...@di...>]

Long time no see, folks.
Sorry if I dont understand the matter correctly,
but why you dont use debootstrap( or cdebootstrap) ?
                 
                --- Okajima, Jun. Tokyo, Japan.

Re: [coLinux-users] colinux & debian etch

[George P B. <geo...@gm...>]

Henry Nestler wrote:
> I'm not known about Debian versions and kernel depencies.
>  From my installations I know coLinux 0.6.4, 0.7.1 and 0.8.x runs on a 
> Debian Woody.
>   
I recently tried to follow the debian install steps from the wiki to
create a new etch image, but apparently there are additional
requirements to get it to work for installing.  I don't know at this
point what those requirements are.  I don't know if there's some
command-line we can give it that will allow it to run without udev or if
udev is going to be needed, or if it's an file system that we need
support but don't have.  I haven't gotten that far.  I just know I
wasn't able to follow the steps there to get it working.  I was able to
start with the iso and initrd set, but I wasn't able to mount them (I
tried with aliases and without and I wasn't able to mount them, but
haven't gotten so far as to creating the block devices necessary to see
if that gets around that problem).  This is for trying to great an etch
image file, not for dual-booting, of course.
> CoLinux versions 0.6.4, 0.7.1 and 0.8.0 runs also on my SuSE 9.0 dual 
> boot with an original 2.4.21 kernel.  From my SuSE I know, that you can 
> run every coLinux on an older distry.  For very old distries with kernel 
> 2.4.x you need to upgrade only the module-init-tools with fallback for 
> 2.4-kernels.
>   
You saying that he SuSE original kernel was 2.4.21 or that you have an
unofficial colinux patched 2.4.21 kernel?

George

Re: [coLinux-users] colinux & debian etch

[Henry N. <Hen...@Ar...>]

Hello,

baldyeti wrote:
> Thanks Henri. But Woody and 2.4.x kernels are definitely
> even older than the sarge I want to replace! Etch comes with
> a 2.6.18 kernel and uses udev - that was my primary concern.
> So I if read you correctly, colinux 0.7.0 will come with a
> 2.6.12 kernel

that's true.
colinux 0.7.1 has kernel 2.6.12, udev is not enabled.

> - what does colinux 0.8.x use? Can I expect
> 2.6.12 to play nicely with the debian 4 startup sequence,
> and udev on the fly device creation

You should use coLinux 0.8.0, from snapshot 20070302
http://www.colinux.org/snapshots  or
http://www.henrynestler.com/colinux/testing/devel-0.8.0/20070302-Snapshot/

This is kernel 2.6.17 and udev is enabled.
Newer kernel are not available.

> Also here there tentative release dates for the upcoming 0.7
> and 0.8 versions?

The 0.7.1 release hangs on a liddle bug while shutting down ('halt'). 
This is typicaly under Vista or some times under heavy memory usage in 
XP (XP with 256MB and coLinux configured mem=128 or more).  Mostly if 
using initrd.  The condition for the bug is very clear, I have no idea 
to fix.  Grep in the devel list to read more.

The 0.8.0 has very long time before release.  You can still use the 
snapshots from http://www.colinux.org/snapshots, they tends to run good.

-- 
Henry