From 354e98325fe94f4834d360086a67d0032b83fa20 Mon Sep 17 00:00:00 2001 From: bnewbold Date: Sun, 24 Jan 2010 05:56:09 -0500 Subject: syntax fixes --- software/MOSS.page | 149 +++++++++++++++++++++++++++-------------------------- 1 file changed, 77 insertions(+), 72 deletions(-) (limited to 'software/MOSS.page') diff --git a/software/MOSS.page b/software/MOSS.page index 95f2d41..c0bba84 100644 --- a/software/MOSS.page +++ b/software/MOSS.page @@ -18,86 +18,91 @@ 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 +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. +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. +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/* +*Existing Projects:* Inferno, Xen, vmware, Java, GNU/* -.. topic:: Universal, distributed file system +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. +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:: +My dream path would look something like:: - /net/user@some.domain.tld/media/ledzep/tangerine.mp3 + /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``. +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. +Versioning, write locks, etc would have to be considered. - *Existing projects:* OpenAFS, freeNet, ssh, kerberos, git +*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 +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 + +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 + -- cgit v1.2.3