summaryrefslogtreecommitdiffstats
path: root/ideas/MOSS.page
blob: c0bba845bed022be8c8be11fea789d1a6372a3bd (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
---
format: rst
toc: no
...

====
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!

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/*

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