Borgification

From Organic Design wiki
Revision as of 22:59, 12 September 2006 by Rob (talk | contribs) (kernel for lunch)

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. Some services already offer this, such as flickr or Google maps.

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.

Borgifying Standards

This is the process of maintaining a class-instance relationship between a nodal context which specific implimentation, 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.

This process is a two way street. We expect that improvements we make to a source tree will also flow back to the originator. These changes are offered to the source project to accept or reject based on it's focus of development.

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
  • 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