coLinux roadmap?

  • Clemmitt Sigler

    Clemmitt Sigler - 2004-03-30


    I thought I'd start a thread over here rather than on the developer's mailing list.  This Open Discussion forum is so quiet, I'm thinking fewer people monitor it and I don't want to create a huge brou-ha-ha :^)

    coLinux seems to me to be amazingly mature.  cL runs under Windows and Linux host OSes now.  This means it's time to start looking at stuff like benchmarking and stress testing.  Before long cL will be ready for 1.0rcX :^)

    So, I thought I'd ask folks if there were any thoughts on a target(s) and a roadmap for cL.  There are so many projects I've seen with roadmaps that never produce any usable code.  Dreams are great.  But cL is just the opposite.  cL has already turned dreams into reality!

    Even as a dumb and inexperienced non-developer, I can think of some points and ideas.  Here are a few:

    1.) Graphical subsystem simulation.  I guess to make this worthwhile it'll require an input daemon for "true" keyboard and pointer input a la VMware's Tools(?).  Then the X server would run on the VM.

    2.) Additional general hardware support.  For multimedia development, sound (to go along with graphics) would be important.  USB or IEEE1394 hardware daemons might allow plug-in devices to work.  Is there other hardware stuff that's feasible to consider?

    3.) "Native" CD-ROM and floppy support, which would allow a cL VM to boot off these hardware devices.  Mind you, I haven't spent much time groking the bootstrapping of cL, but since it requires a patched vmlinux kernel I can see that this might not be feasible within the bounds of the project.  (Blue-sky alert: Could a type of binary patch be developed that might allow the kernel from a bootable floppy or CD to be extracted and patched, with cL then booting that patched kernel?)

    4.) Achieve some level of parity with VMware -- I guess this is a combination of 1.), 2.), and 3.)???

    5.) Porting the driver daemon subsystem(s) to other host OSes:
    - BSDes
    - OS X
    - Xen (I don't have enough time to work with Xen, but it looks to me to be "the" Open Source answer for bare-metal virtualization in the old IBM OS/390-type sense; they've even ported Windows onto it via Cambridge U's non-disclosure MS source code license; mind you, it doesn't have cL's advantage of being small/lightweight; I think they're addressing some philosophical questions of archetecture and design right now that will determine Xen's long-term fate, FWIW)
    - ReactOS
    - (Insert your favorite OS here ;^)

    6.) Porting other guest OSes to a cL-type framework:
    - BSDes
    - OS X/Darwin
    - ReactOS
    - (Are there any other Open Source OSes that would be of interest as guest OSes?)

    I'm also wondering about the long-term target(s) for cL.  Is the goal to remain lightweight and narrowly focused instead of becoming a be-all and end-all VM system?  I think that would be a most worthy goal, because it would allow outstanding virtual server deployment under the host OSes.  Or would it be reasonable to consider multiple project targets, such as one focused on virtual server deployment and another on VMware-type functionality?  Perhaps parallel development of separate branches would work (or maybe this isn't ever a good idea?).

    If anybody has other ideas or feedback on mine, please post here to let me know.  And please flame away if I "just don't get it."  Thanks for listening :^)


    • Matus Horvath

      Matus Horvath - 2004-03-30

      I would really like to see a version of colinux which could run (almost) completely invisible to the user. Current version always shows at least one console window. It would be great if there was only a tray icon visible. User could right click on the tray icon and display a window with kernel messages similar to the window shown now. This would be very useful to users who want to use just the services running on linux, e.g. apache or openssh, or perhaps for running a distributed colinux cluster on office w2k computers.

      Other interesting tray icon menu command would be "shut down colinux" which would perhaps run user-supplied .bat file to log in to the running coLinux instance (over ssh perhaps) and run /sbin/shutdown -h now. Or it could be implemented using some sort of windows signalling mechanism to send the shutdown signal to colinux and colinux kernel would then communicate the signal to the init process. It would work in a similar way to todays ctrl-alt-del handling in conventional linux (i.e. a record in inittab would call /etc/shutdown -h now).

      One other idea: would it be possible to set lower priority for colinux, so it would run only when windows is idle? That would also be interesting for running a colinux cluster in background...

      I was in fact trying to start implementing some of these ideas, but I did not succeed in compiling the cross-cygwin toolchain and now I do not have time to spend on this project. But perhaps someone else does...

      • Vijay Velusamy

        Vijay Velusamy - 2004-05-05

        I believe this is an interesting feature that I would be interested in

      • Chris Friedl

        Chris Friedl - 2004-06-11

        I guess you could pass a shutdown message from windows to CL via text file as suggested here.

    • Robert Citek

      Robert Citek - 2004-04-20

      IMHO, the biggest challenge facing coLinux (and many other OSS projects) is not technical, it's social: what plan does the current coLinux team have to attract and retain both users and developers?

      - Robert

    • Ken Hillier

      Ken Hillier - 2004-04-23

      I would like coLinux to continue to decouple the driver from the kernel.  I would like to be able to replace vmlinuz and use any kernel with any distribution within a given framework of coLinux.

      As for Social :)  I think it just needs to get itself out there in front of other linux users.  It is already mature enough that I don't need to repartition and install linux on my system to get base functioniality.  The rest will follow it appears.

    • Robert Citek

      Robert Citek - 2004-04-25

      - what "it" do you want to get in front of linux users?
      - why not Windows users?
      - how would you recommend getting "it" out there?

      I would define "it" as a complete install package that installs a functioning program, containing both the colinux executables and a root filesystem.  As an almost-there example, see:

    • Anonymous

      Anonymous - 2004-06-10

      First and primarily, I am not a Garu in any sense or form.  I
      a business person and not a programmer.  I understand 80%
      to 90% of what I read in regards to Linux.
      I have several machines on an ipcop box attached to cable.
      My wife's machine (one) is running Windows XP Client.  My
      primary machine (two) has several hard drives, one a 120 GB
      and the other a 40GB, with a DVD, CD and Debian on both hd's.  Currently running vmlinuz-2.4.20-idepci but there is a 2.6.6 kernel running around someplace but not loaded.
      My other deskside PC has Windows XP Pro on hda and Debian on hdb.  The Windows hda drive is rather full and most likely should be either changed or re-installed on a larger hard drive.
      I have messed with Knoppix and Lindows but do not really like to use either one.  I am searching for something, maybe CoLinux(?) that will permit me to use both Windows and Linux applications with a minimum of fiddling around.  I do not mind writing some simple script but have no interest or abilities in writing code.  I prefer loading binaries and not source.
      All that said, is CoLinux something that someone such as myself would fit into easily (no sweat, no pain, not much tweeking)?
      If so where and what is the best download for what I think  I want?
      Homer Whittaker

    • Anonymous

      Anonymous - 2004-06-11

      I see a very good use in running it on a server where you need both windows & unix functionality but where you lack the budget (or other constraint) to go for 2 boxes.
      e.g. on an AD-controler

      But I did some tests with iperf on the bridging setup (which will be the prefered setup on internal servers) and the performance could be better.

      The upside is that it just dropped packets but kept running without problems.

    • Bjorn Asmul

      Bjorn Asmul - 2004-10-29

      I would like to see a USB driver that would work with Asterisk. So that Asterisk could trunk with other Asterisk server. Asterisk trunking requires either a Digium Zaptel card or a USB device to do (hardware) timing.


Log in to post a comment.