summaryrefslogtreecommitdiffstats
path: root/software/MOSS
diff options
context:
space:
mode:
authorUser <bnewbold@daemon.robocracy.org>2009-10-13 02:52:09 +0000
committerUser <bnewbold@daemon.robocracy.org>2009-10-13 02:52:09 +0000
commitf61026119df4700f69eb73e95620bc5928ca0fcb (patch)
treef17127cff9fec40f4207d9fa449b9692644ce6db /software/MOSS
parent9d431740a3e6a7caa09a57504856b5d1a4710a14 (diff)
downloadknowledge-f61026119df4700f69eb73e95620bc5928ca0fcb.tar.gz
knowledge-f61026119df4700f69eb73e95620bc5928ca0fcb.zip
Grand rename for gitit transfer
Diffstat (limited to 'software/MOSS')
-rw-r--r--software/MOSS98
1 files changed, 0 insertions, 98 deletions
diff --git a/software/MOSS b/software/MOSS
deleted file mode 100644
index 4de6d23..0000000
--- a/software/MOSS
+++ /dev/null
@@ -1,98 +0,0 @@
-====
-MOSS
-====
---------------------------------
-Many User Operating System Stuff
---------------------------------
-
-:Author: Bryan Newbold
-
-Moss is a vague concept I have for an operating-system-like-system that
-attempts to realize some of the promises of distributed universal computing
-and user management, continuation-based serializable programming, persistent
-data accessibility, file and process versioning, central foreign function
-management, and code/content distribution. It'll be easy!
-
-.. topic:: Implementation
-
- Moss would probably start as "stuff": middleware, userland applications,
- utilities, and native shell and GUI interfaces. It could also be a
- separate hosted virtual machine, a monolithic application, a kernel
- extension, or ultimately run alone over a high performance shim host OS.
-
- Distribution would be self hosting and viral: users would replicate a copy
- of the system from a friend instead of from a central server, patches
- and applications would be distributed word-of-mouth, and trust networks
- would form naturally via this distribution. Customization and feature sets
- would be passed on, which makes it likely that a user would receive a
- system already tweaked for their own needs and computing knowledge level.
-
- *Existing Projects:* Inferno, Xen, vmware, Java, GNU/*
-
-.. topic:: Universal, distributed file system
-
- The core of the system would be a universally accessible identity-based
- operating system. Some authoritive domain would probably be required, but
- public identity brokers would allow anonymous identities. "Strong
- Cryptography" is a goal, allowing a user's content to be hosted/cached
- on third party machines in an encrypted form. The real challenge of course
- is a flexible crypto system than can be transitioned or upgraded if a flaw
- is discovered without total data loss.
-
- My dream path would look something like::
-
- /net/user@some.domain.tld/media/ledzep/tangerine.mp3
-
- From the application end there would be no concept of "local" or "remote"
- files to a particular machine, though perhaps some feedback on access time.
- So, for instance, once tokens/authentication is handled, user utilities
- like ``mv`` or ``cat`` could be applied, instead of ``scp`` or ``rcat``.
-
- Versioning, write locks, etc would have to be considered.
-
- *Existing projects:* OpenAFS, freeNet, ssh, kerberos, git
-
-.. topic:: Serializable Programs
-
- The state/continuation/environment of a running program or chain of
- programs should be a "first level object": a bundle of data like any other
- that can be transmitted, copied, and stored away for later. A user should
- be able to drag an entire application running on a desktop computer
- onto their laptop when then need to travel, or from laptop to workstation
- if then need additional computing power. Distributed computing could be
- implemented by bundling up applets that are shot off to a cluster or
- higher performance computer for processing, and the result state of the
- program would simply be bundled back to the requesting client. Such bundles
- wouldn't be very large: data would be stored on the distributed filesystem,
- which appears identical (*exactly?*) to every node on the network.
-
- Properly written, such a serializable system could also lead to performance
- and power consumption savings by swapping idle programs and processes to
- disk, or let low-usage nodes shift their processes off to other nodes
- and power down.
-
- *Existing Projects:* Lisp, Stackless
-
-.. topic:: Foreign Function Management
-
- It would be nice to see a move away from the library model for shared
- code to a more flexible/dynamic foreign function interface that would
- allow any appropriate code to announce its availability to other
- applications regardless of version, platform, coding language, etc.
- This would be a high-level feature, not intended to replace kernel level
- operations (read/write) but to make package/library management easier
- (it doesn't matter if an image conversion function is coming from a video
- editing package or libpng as long as it reads a raw array and returns
- a binary stream).
-
- There's room for dynamic optimization here: if program
- realizes it's native string manipulation library sucks for 5meg+ datasets
- it could look through the library and see if there's a better one.
-
- *And,* this too could be distributed, allowing super easy access to
- distributed computing resources; underutilized nodes could make their
- functions available to nearby nodes, or a machine with tons of matrix
- crunching silicon (eg high end video cards) could swap work units
- with a machine with a dedicated crypto chip or 64bit+ processor.
-
- *Existing Projects:* Script-fu from the Gimp