Borgification
|
|
Borgification is the assimilation of established external resources and organisational aspects into the network's holistic system of organisation. It extends the unified network into other foreign "legacy" informational environments such as operating systems, language environments, document repositories, applications and organisations.
Method
A major aspect of borgification is the unification of external resources with the time domain (linear and cycles). This gives history, scheduling, analysis and budgeting to the resources and allows them to be incorporated into the network so that they can be managed by the network or using the peer interface.
The network connects with the foreign services on behalf of the network users, as far as they're concerned they don't leave their own local peer environment, so they can change the way it looks and works just like anything else. This allows the network to act as a load-balancing and distributed backup solution for the external service without the service having to change anything. The service or organisation being used in this way could also support the process and make it more efficient still, for instance by offering an API, or representing their information and services with a common protocol like RDF or RSS. Some services already offer this, such as flickr or Google maps, and web applications combining content behind the scenes from external services are called mashups.
These features make it extremely easy to test out the network because it can be used alongside an existing solution and used as much or as little as desired without any concerns about migration.
Tools
- The Borg cube: Robust power and I/O box running peerix
- Infrastructure management
Borgifying Standards
This is the process of maintaining a class-instance relationship between a nodal context which specific implementation, or instance of an external standard (the class) such as POSIX. This is similar to the way that the GNU Unix-like components maintain their conformance to the POSIX standard
Borgifying Sources
With the increasing popularity of open-source projects there is a huge resource of source code available to the community. Re-use of source code is very important to achieve our goals. Wherever possible we will use existing source trees to provide live sources. In this way as an associated project improves the quality of it's software, we benefit also.
The process is a two way street, a dynamic, ongoing relationship exists between the peer environment and the external source tree. Changes made to sources by users within the peer interface are reflected in the external source tree too. The peer network integrates with external source trees the same way it integrates with other standard wiki's (of course the network user/group making the changes would need to be registered developers of the external project for this to work).
Automated aquisition of sources
Research points to a small number of commonly used technologies that may be used for managing source trees.
Many projects use versioning systems to keep track of code, just as we do with XML Wiki.
- Subversion (SVN)
- CVS
- GNU arch
There are also a large number of projects that publish their code in tar balls without giving access to individual files. In both cases it is a simple matter to create a small script that will automate the process of aquiring and extracting the information we need. Many of the CVS-type systems provide an http read-only interface to the tree. In this case a simple curl is all that is needed. Others require the use of a client program to talk to the repository. For tar balls the standard GNU utilities such as tar, zcat and bzip are all that is required to deal with the archive.
To flow back in the other direction, many projects post patches on their mailing lists for admins to commit, so diff and an email MTA is all that is required here.
Self containment
The system's ability to aquire the source code that is used to build itself is a fundemental concept. In practice this means being able to obtain the source to an operating system kernel such as Linux. Borgification of the Linux kernel tree is high on the list of priorities, in order to be able to implement the Peerix operating system.
Applications
- Pricespy style "scrapers"
- Bank statement retrieval and parsing and transfers etc
- Remote installation/upgrading over SSH or between peerd's
- Network monitoring and analysis
- Wikipedia and other wiki's (incl. other wiki-engines too)
- Borgifying dependencies - project integration with SVN-like env's (some project's are gcc, linux kernel, SDL etc, see also Self Containment)
- Multi OS/lang/hardware support (eg. iPod, XBox)
- flickr
- Google maps
- Borgifying languages from their EBNF definitions for syntax highlighting etc
- Mikoto Diaries - this guy likes the term ;-)
