DistOS-2011W FWR: Difference between revisions
Created page with "=Introduction= Describe the system(s) that you examined or compared. Why did you choose them? Be sure to specify a thesis that you argue in the rest of the document. Since th…" |
|||
Line 1: | Line 1: | ||
=Introduction= | =Introduction= | ||
The idea behind FWR (First Webocratic Republic) is simple: to create a self-governed community on the web. | |||
The first approach was natural: write a CMS where users can register (become citizens of FWR), communicate freely, elect leaders and be elected. The main goal of such a community is to survive, so some source of income is needed to pay hosting provider. CMS needed to have two parts – public and for-citizens-only. Citizens elect leaders, who decide on the strategy of content-generation, then everybody work on public part (tourist site) to attract visitors and get money by ads, referral links, etc. This approach can't be described as fully democratic, since the owner of root-password on the server is still in complete, god-like power over the FWR. | |||
To fix this issue, another idea was added: distribute the copy of the world (filesystem and DB) to all citizens in some p2p fashion (torrent, probably) every time government changes, so that if new government screws things up, everyone has a "backup world". This also contributes to overall distribution of FWR – every copy is fully-functional and can be set as a separate "country". | |||
But this all wasn't distributed enough. | |||
Here is the final structure: | |||
[[File:FWR Scheme.png]] | |||
CMS is running on the main server, but in read-only mode. The data (files, databases, etc) is synced by rsync from client machines. Clients are citizens, and only they can write to synced directories. | |||
Local http server on client machine runs fully-functional CMS which can be accessed locally. There is also a set of scripts to work with files, databases and rsync. Clients can sync with each other too. | |||
So, even though we still have main server for public access, the system does not depend on it. Main server can be easily changed. | |||
System still runs being offline and tries to sync everything as soon as it gets back online. | |||
Amount of governance needed has also changed: in the previous model elected leaders had access to server-files and databases, but now everyone has access to it. The only essential thing left is to moderate content being synced. This can be done by adding personal or global filters, not allowing particular people to sync with main server or with clients. Also, local and server-storage can be set as version control system, so that vandalism can be dealt with as in wikis. Moreover, every citizen can separate at any moment and run their own world. | |||
This scheme can be a base of some collaboration system. | |||
=Systems/Programs in the Space= | =Systems/Programs in the Space= |
Revision as of 23:08, 23 February 2011
Introduction
The idea behind FWR (First Webocratic Republic) is simple: to create a self-governed community on the web.
The first approach was natural: write a CMS where users can register (become citizens of FWR), communicate freely, elect leaders and be elected. The main goal of such a community is to survive, so some source of income is needed to pay hosting provider. CMS needed to have two parts – public and for-citizens-only. Citizens elect leaders, who decide on the strategy of content-generation, then everybody work on public part (tourist site) to attract visitors and get money by ads, referral links, etc. This approach can't be described as fully democratic, since the owner of root-password on the server is still in complete, god-like power over the FWR.
To fix this issue, another idea was added: distribute the copy of the world (filesystem and DB) to all citizens in some p2p fashion (torrent, probably) every time government changes, so that if new government screws things up, everyone has a "backup world". This also contributes to overall distribution of FWR – every copy is fully-functional and can be set as a separate "country".
But this all wasn't distributed enough.
Here is the final structure:
CMS is running on the main server, but in read-only mode. The data (files, databases, etc) is synced by rsync from client machines. Clients are citizens, and only they can write to synced directories. Local http server on client machine runs fully-functional CMS which can be accessed locally. There is also a set of scripts to work with files, databases and rsync. Clients can sync with each other too.
So, even though we still have main server for public access, the system does not depend on it. Main server can be easily changed. System still runs being offline and tries to sync everything as soon as it gets back online.
Amount of governance needed has also changed: in the previous model elected leaders had access to server-files and databases, but now everyone has access to it. The only essential thing left is to moderate content being synced. This can be done by adding personal or global filters, not allowing particular people to sync with main server or with clients. Also, local and server-storage can be set as version control system, so that vandalism can be dealt with as in wikis. Moreover, every citizen can separate at any moment and run their own world.
This scheme can be a base of some collaboration system.
Systems/Programs in the Space
Give an overview of the area you are examining. What systems/programs are out there?
Evaluated Systems/Programs
Describe the systems individually here - their key properties, etc. Use subsections to describe different implementations if you wish. Briefly explain why you made the selections you did.
Experiences/Comparison (multiple sections)
In multiple sections, describe what you learned.
Discussion
What was interesting? What was surprising? Here you can go out on tangents relating to your work
Conclusion
Summarize the report, point to future work.
References
Give references in proper form (not just URLs if possible, give dates of access).