Difference between revisions of "Talk:Peerix"
(thoughts) |
m (→Current thinking) |
||
Line 7: | Line 7: | ||
With the large number of source packages needed to build even a simple OS, it is safe to assume that in even one development cycle ''something'' will change. Pre-built packages are out (debian etc) because they simply do not give us the flexability needed to create a cutting edge OS. Debian in particular is necessarcly conservative in their adoption of new software. | With the large number of source packages needed to build even a simple OS, it is safe to assume that in even one development cycle ''something'' will change. Pre-built packages are out (debian etc) because they simply do not give us the flexability needed to create a cutting edge OS. Debian in particular is necessarcly conservative in their adoption of new software. | ||
+ | |||
+ | My analysis of the GeeXbox build process has given me an insight into how a project comparable to the Peerix project would be maintained. More work is needed here to simplify the build process. This is ongoing. '''make''' seems significant to the logic behind any build system. The logical ''depends'' state machine is something that perhaps could work in a wiki way. | ||
+ | |||
+ | Perhaps wiki could be used to manage builds by interacting with svn/arch/cvs and in that way version not only the source, object and binary files, but the script logic that builds them. It seems that at present XML-wiki could not reasonably be expected to handle the array of documents required to build a linux kernel, for example. So some of this could be delegated to the versioning system. | ||
+ | |||
+ | Whether or not this is practical? Probably not at this stage. However, it seems some kind of system is required to collaborate on a build (svn or whatever). | ||
==Logo idea== | ==Logo idea== |
Revision as of 02:57, 26 May 2006
Current thinking
After reviewing this article I see that there is quite a bit that is inconsistent it does not really reflect my ideas. It does accurately reflect the rapidly shifting conceptual process that is my attempt to solve this problem.
Right now my feeling is summarised thus:
It is not enough to be able to generate an usable operating system once, it must be able to be built dynamically from source packages that are subject to change.
With the large number of source packages needed to build even a simple OS, it is safe to assume that in even one development cycle something will change. Pre-built packages are out (debian etc) because they simply do not give us the flexability needed to create a cutting edge OS. Debian in particular is necessarcly conservative in their adoption of new software.
My analysis of the GeeXbox build process has given me an insight into how a project comparable to the Peerix project would be maintained. More work is needed here to simplify the build process. This is ongoing. make seems significant to the logic behind any build system. The logical depends state machine is something that perhaps could work in a wiki way.
Perhaps wiki could be used to manage builds by interacting with svn/arch/cvs and in that way version not only the source, object and binary files, but the script logic that builds them. It seems that at present XML-wiki could not reasonably be expected to handle the array of documents required to build a linux kernel, for example. So some of this could be delegated to the versioning system.
Whether or not this is practical? Probably not at this stage. However, it seems some kind of system is required to collaborate on a build (svn or whatever).
Logo idea
Penguin logo made from a patchwork of fabrics each visually linking through use of colour to other distros. Eg yellow for linux, red for bsd, coffee for debian, etc.
See archive for line art of penguin stencil.