The Komodo project, of which I've posted looking for developers here before, is moving into the Alpha phase. Dated snapshots of the OS in the form of an installer CD image is available via BitTorrenting at out site, Komodoware.com
If you are interested, please give it a shot and tell us how it went on our forums at http://www.komodoware.com/forums
Komodo OS Alpha Testers Needed
Re: Komodo OS Alpha Testers Needed
I have seen so many "OS-Projects" which use linux as base. I dont know what I sould thinking about all this Projects.
Perhaps its a nice try to learn more about linux, but it isnt a new OS for me.
And yes I read the FAQ.
Creat a Distro. with Knoppix like hardware detection, finish ATI/NVIDIA GFX moduls, small install (~300-400MiB with Apps), and some ENDUSER Apps like MPlayer, XMMS, Firefox, small Office Apps and a SMALL usable Desktopmanager. (DO NOT USE KDE OR GNOME!!!!!!!!!!!!)
This would be nice, not flexibel, but nice for the ENDusers.
Perhaps its a nice try to learn more about linux, but it isnt a new OS for me.
And yes I read the FAQ.
Creat a Distro. with Knoppix like hardware detection, finish ATI/NVIDIA GFX moduls, small install (~300-400MiB with Apps), and some ENDUSER Apps like MPlayer, XMMS, Firefox, small Office Apps and a SMALL usable Desktopmanager. (DO NOT USE KDE OR GNOME!!!!!!!!!!!!)
This would be nice, not flexibel, but nice for the ENDusers.
dw 0xAA55
Re: Komodo OS Alpha Testers Needed
Maybe I should clarify this. Komodo is *based* on Linux, it is NOT a Linux distribution at all. The OS uses the Linux kernel, the GNU tools, and implements an entire new OS above that, with a set of system tools (KomodoCore) with an abstract low-level functional interface (CoreServices), a client library (Emotion) and a user interface (Dagon). All these components are unique to Komodo (at least now, I hope they become useful elsewhere).
The FAQ also was the wrong place to start reading. You should've read some of the other About stuff like Info for Users etc.
The main mission behind Komodo is bringing a next-generation API, interface, as well as security and software management and all those goodies. Another point to it is solidifying the available APIs into a single free toolkit (more than just your standard graphics and UI).
Specifically, about your stuff:
Hardware detection -- We've got preliminary hardware detection support. The OS does do hardware detection on it's own and doesn't bother the user about what driver to use. Those things are changeable later after the OS has booted.
Finish ATI/NVIDIA GFX modules -- I do think you mean that I should go and work on the open source graphics drivers. No. That's not what I'm good at and programmers can't just make code appear, it has to be thought out and written, as well as carefully debugged in many phases. Besides, Komodo includes the binary ones... NVIDIA doesn't really care that you provide support for their cards out of the box, they like it. There's no reason we can't get a hold of them and just ask them if it's alright. If it's not, we can reason with them for the sake of them being officially recommended (because we all know their binary drivers work pretty good--im using them now).
Small Install -- That's not a goal really, although the ISO for Komodo is only 350MB, so unpacked its prolly like 700MB altogether, which is great for a modern OS (Fedora sucks up like 2 gigs I think)
End user apps: Those tools will all be available and indeed supported officially by Komodoware. Software installation on Komodo is much different than other Linuces. One would download a packaged bundle and double click it, boom out pops a bundle and you can run it straight from your desktop with no installation at all. Dependencies are much less an issue when you can provide "fat packages" that contain some extra fat libraries and files which are required but might not be available on all boxen. Apart from those' availability, we will be introducing software which uses Emotion as it's toolkit. These most likely will be powered by Xine or Mplayer at the core (we have a pluggable framework for media engines already).
We have no fears about including proprietary plugins. MP3, yes we will support it. DVD, indeed we will devise a method to install a decoder from the web (and not actually include it in komodo) most likely via bittorrenting or something odd. WMA, WMV, AVI, AAC, FairPlay (optional "decent" kernel-level module to restrict it, so that an admin can just remove the module to stop it AS WELL AS PlayFair in the same method as DVD). How about Macromedia Flash and the Adobe Reader plugins? This will come with them, and in fact the licenses of each are open for OS redistribution so I'm sure I can get written permission too. If any of these options don't pan out legally, there are open source projects which we can throw what weight we can into getting them on the shelf and integrate those.
Small desktop manager: We've been thinking up ways to allow both bigness and smallness, because it's obvious that there's large groups of people behind both the KDE and GNOME ideologies. So we say, put in methods to allow the UI to expand to show more functionality according to configurable inputs from the user (not like the limited and annoying menu crap in Win ME, but something intuitive and simple).
The first place this decision is manifesting itself is an idea we have been discussing on our forums: preference visibility controlled by a reasoning engine with those user input methods (provided by plugins). The preferences can be drawn in any way the "zoomer" wants depending on the preferences visibility level (which ranges from 0 to 1.0).
Flexibility: This is a major goal of Komodo. A well-designed OS by nature is flexible. You don't need to expose complexity for flexibility, you simply need to design it more abstractly, so that more cases are covered.
The FAQ also was the wrong place to start reading. You should've read some of the other About stuff like Info for Users etc.
The main mission behind Komodo is bringing a next-generation API, interface, as well as security and software management and all those goodies. Another point to it is solidifying the available APIs into a single free toolkit (more than just your standard graphics and UI).
Specifically, about your stuff:
Hardware detection -- We've got preliminary hardware detection support. The OS does do hardware detection on it's own and doesn't bother the user about what driver to use. Those things are changeable later after the OS has booted.
Finish ATI/NVIDIA GFX modules -- I do think you mean that I should go and work on the open source graphics drivers. No. That's not what I'm good at and programmers can't just make code appear, it has to be thought out and written, as well as carefully debugged in many phases. Besides, Komodo includes the binary ones... NVIDIA doesn't really care that you provide support for their cards out of the box, they like it. There's no reason we can't get a hold of them and just ask them if it's alright. If it's not, we can reason with them for the sake of them being officially recommended (because we all know their binary drivers work pretty good--im using them now).
Small Install -- That's not a goal really, although the ISO for Komodo is only 350MB, so unpacked its prolly like 700MB altogether, which is great for a modern OS (Fedora sucks up like 2 gigs I think)
End user apps: Those tools will all be available and indeed supported officially by Komodoware. Software installation on Komodo is much different than other Linuces. One would download a packaged bundle and double click it, boom out pops a bundle and you can run it straight from your desktop with no installation at all. Dependencies are much less an issue when you can provide "fat packages" that contain some extra fat libraries and files which are required but might not be available on all boxen. Apart from those' availability, we will be introducing software which uses Emotion as it's toolkit. These most likely will be powered by Xine or Mplayer at the core (we have a pluggable framework for media engines already).
We have no fears about including proprietary plugins. MP3, yes we will support it. DVD, indeed we will devise a method to install a decoder from the web (and not actually include it in komodo) most likely via bittorrenting or something odd. WMA, WMV, AVI, AAC, FairPlay (optional "decent" kernel-level module to restrict it, so that an admin can just remove the module to stop it AS WELL AS PlayFair in the same method as DVD). How about Macromedia Flash and the Adobe Reader plugins? This will come with them, and in fact the licenses of each are open for OS redistribution so I'm sure I can get written permission too. If any of these options don't pan out legally, there are open source projects which we can throw what weight we can into getting them on the shelf and integrate those.
Small desktop manager: We've been thinking up ways to allow both bigness and smallness, because it's obvious that there's large groups of people behind both the KDE and GNOME ideologies. So we say, put in methods to allow the UI to expand to show more functionality according to configurable inputs from the user (not like the limited and annoying menu crap in Win ME, but something intuitive and simple).
The first place this decision is manifesting itself is an idea we have been discussing on our forums: preference visibility controlled by a reasoning engine with those user input methods (provided by plugins). The preferences can be drawn in any way the "zoomer" wants depending on the preferences visibility level (which ranges from 0 to 1.0).
Flexibility: This is a major goal of Komodo. A well-designed OS by nature is flexible. You don't need to expose complexity for flexibility, you simply need to design it more abstractly, so that more cases are covered.