linux.techass.com
"Tell Bill where to go today!"

Home/What's New
Products
Projects

Technology Associates Homepage


eternaLight!
Alien Technology?





Powered by Linux!
(of course)

SourceForge Logo Phoenix Project
[ Status | Documentation | Downloads | CVS | Mailing Lists | Developer Info | License | Credits | Contact ]

What is it?

Welcome to the home of the Phoenix Project. The goal of this project is to develop the OS (Linux distribution?) that will rise out of the ashes of Unix. One problem, of course, is that Unix is not in ashes and isn't likely to be any time soon. In fact, it seems to gain popularity everyday, thanks to Linux and the BSD's.

This is not really a problem, however. The real problem is that all current Linux (and BSD) distributions are just like Unix. In the case of Linux, they just take the Linux kernel and use it as the kernel of a "unix-like" operating system (just as it was intended!). They are just as arcane and complicated as "real" Unix itself.

While I have no problem using Unix (Linux or *BSD) as it is, there is no reason for it to be as complicated as it is to setup, configure, and use as it is now. There is, in fact, no reason it has to look like Unix at all.

As any Unix wizard or guru knows, Unix is actually much more than a kernel and a set of system calls. It is defined not only by the kernel but by the shell and the various tools included (like grep, sed, awk, and now perl, etc.).

So, in short, the goal of this project is to create a new Linux distribution which is not based on Unix, but rather uses Linux as the kernel of a brand new "Operating Environment" based on the Linux kernel using newer, more up-to-date, and hopefully better ideas.

Why choose Linux

Why use Linux rather than one of the BSD variants? Well, the reason is the same as the reason I decided to use Linux rather than one of the BSD's myself. It has to do with with number of users and developers. There are (at least) hundreds, if not thousands, more developers working on Linux vs. all the BSD variants combined, and there are hundreds of thousands of more users using Linux vs. the BSD variants. BSD may well be better engineered and may have a better TCP/IP stack than Linux (for now), but Linux has the most users and the best hardware support and this is likely to continue. This is not to say that we couldn't develop our software to work with both Linux and *BSD, don't let this stop you from contributing. I don't have any prejudice either way.

What is the plan?

I don't have a complete plan for this project yet. I'm not sure exacty how to do this and make it work. I only know it needs to be done. Please join in and contribute your ideas.


Current Status

I am currently working on a replacement for "init". The current Unix/Linux system of using "rc scripts" is not only outdated, it is overly complex and difficult, if not impossible, to understand by those who have not spent years working with it. While it is possible to just read through the scripts and finally determine what and how things are happening, it takes days, weeks, and/or years. This is unacceptable!

While using shell scripts is the ultimate in flexibility, it is also the ultimate in uncontrollablility and uncertainity. This is also unacceptable!

We should be able to absolutely start or stop various services (like web, ftp, nfs, etc.), not just hope and/or wonder that they are either running or not. We should be able to modify the configuration and know that the various services are working as now configured.

This is the goal of the new init. My current design is similar to NT's services and uses a common configuration file (like a registry) and services (daemons) written as shared libraries with known access points. Note that is allows a simple wrapper to utilize current scripts, but this is only intended facilitate crossing over.

Beyond this, I think we need to:

  • think outside of Unix
  • rewrite or modify inetd to use a configuration system similar to the new init
  • come up with a new simplified directory layout
  • determine what packages to include (and what from those packages, for instance we don't need everything from X).
  • determine which package manager (if any) to use
  • just get started

Documentation

None yet, sorry.


Downloads

None yet, sorry.


CVS Access

Please see the SourceForge page for more info.


Mailing Lists

Please see the SourceForge page for more info.


Known Bugs and ToDo's

Please see the SourceForge page for more info.


Developer Info

We need developers! If you are interested please contact the project manager, Derry Bryson at derry@techass.com, directly. If you would like CVS write access, you will need a SourceForge ID and SSH/SSL support setup (see the documentation at SourceForge).

If you don't want to become an "official" developer, patches and bug reports are also welcomed.

If you want to become an official developer, I would suggest obtaining and familiarizing yourself with the current version from CVS and monitoring and reviewing the archives from the developers mailing list.


License

The license is undetermined at this point, but will probably (due to necessity) be GPL.


Credits

  • Linus Torvalds and the rest of the Linux developers: Thanks for Linux!

Contact

Please direct all questions, comments, bug reports, bug fixes, etc. to the appropriate mailing list.

All other correspondance (including problems with this web page) should be directed to Derry Bryson at derry@techass.com


Copyright © 2000-2002 Derry Bryson. All Rights Reserved.