h a l f b a k e r yThe Out-of-Focus Group.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
Net PC
A Realtime Collaboration Network Contraption Where the Network IS the Backplane. | |
This thing allows real-time collaboration and operation between networked PCs in a more complete way than anything before. No it isn't Citrix or VMWare or RDP or Bittorrent or Google Docs, but it is a lot like those things.
First boot into the NetOS to emulate your hardware and provide the underpinnings
for the next part.(I'm sure that name is trademarked by someone...). Next, boot your OS of choice on top. Everything at this point is running like any normal virtual machine.
Enter the collaboration stream subscription. Subscribe to or publish machine activities via a p2p protocol that is torrentish in it's architecture: seeds that anyone can access, and that are universally reachable, and that are broadcast amongst all members based on fastest rtt's. Of course, in typical application I imagine the published seeds are protected using some access/authorization mechanism.
Machine activities are most anything happening on a computer at the human-interface-layer and near-human-interface-layers: running an exe, copying a file, printing a document, receiving keyboard or mouse input, sending VGA output, or whatever.
In this way it is conceivable that an excel spreadsheet could be edited in true sub-1-second-realtime on two or more pcs, without the need for a lot of cloud resources. Any application could theoretically be shared: notepad, AutoCAD, Paint, Visio, toasters screen saver.
There would be collision event handling in the case that independent actions on two machines contradictory. Collision handler may or may not present a popup asking the user for remediation, depending on preferences and machine activity type.
Not sure about OS environmentals, versioning and file access The NetOS would abstract user, device and application input/output between machines. But there are certain assumptions about what files exist on the host computer, host OS versioning, etc. An host stream could be subscribed to where such items can be reconciled or even loaded as a new VM. Or, depending on the type of activity being seeded and the amount of Os environs that need reconciliation, maybe just a tiny subset of assumptions is loaded when a seed is run and/or machine requests are translated or dictated by NetOS between seeds.
Totally half baked. But the network can be the backplane.
it's called distributed computing
http://en.wikipedia...stributed_computing
which encompasses what you're talking about, as well as parallel computing, clustering, etc. etc. [FlyingToaster, Mar 12 2010]
"toasters screensaver"
MMORPG_20ScreenSaver
:D [FlyingToaster, Mar 12 2010]
Please log in.
If you're not logged in,
you can see what this page
looks like, but you will
not be able to add anything.
Destination URL.
E.g., https://www.coffee.com/
Description (displayed with the short name and URL.)
|
| |
One more time...? With a little more clarity... |
|
| |
How are you file locking if two people are editing the same spreadsheet? Are you "cell" locking? Where is the processing being done? Where are are programs being compiled? Where are the files stored? |
|
| |
I think this is a bit like my 'processing mist' idea, but glossing over all the bits I thought were important, and more details elsewhere. |
|
| |
It's not *quite* the same, though, because of that. |
|
| |
Well "distributed computing" is both too general a term, and as it works out in application (sharing cpus crunching datasets and return a new dataset for modeling, etc), too specific; it is not precisely what I'm talking about. |
|
| |
UNA and SubEthaEdit don't require file locking and are real time editors. Certainly Google Apps doesn't require file locking. Collisions in edits can be handled with popouts asking about reconciliation. Today, full real time edits done collaboratively also involve people talking with each other so this really isn't a problem. I've been editing a document with up to six others at a time with few collision issues. |
|
| |
Chrome OS, yes it seems kinda sorta like what I'm talking about, but "web based OS" screams client-server to me which is not what NetOS is about. |
|
| |
So the way I imagine the flow occurring for a machine event like opening a prexisting word doc, sharing is as a collab stream, and typing a sentence into it, is like this: 0) All applications and devices installed into the host OS are assigned an application type and environment based on a guess: the patterns in the binary of the executable/s, the file types used (file the application or host OS might associate with or declare that the executable can use), learned use over time (NetOS sees OS launching .doc files as self-associates), and many other guessing mechanisms 1a) Call Word by clicking on the Word doc. 2a) The user publishes or shares the document (or maybe all documents are automatically published at creation. 2b) This creates a machine event handle in NetOS wherein the binary contents of the document are pointed to (linked to) in NetOS, and the executable environment is documented. 3a) Someone subscribes to the share. 3b) If the contents of the handle don't exist on the subscriber's machine, the subscriber downloads the contents of the machine event (in this case the Word doc, the application type and environment variables) 3c) the subscriber PC tries to the load the document using the application that has been guessed (maybe the app is resident, maybe in a cloud, doesn't matter). 4a) the host uses a keyboard to type a letter into the document 4b) the letter is echoed into the document and into the machine event handler and hence across the subscription stream on the network 4c) the letter is echoed into the subscriber's machine event which is then directed as a keyboard event to the document and voila, the path is complete. 5a) three or more subscriptions to a machine event are propagated/seeded to each other, with updates unicasting to one or more machines simultaneously depending on a number of variables, in a torrentlike fashion. |
|
| |
//"web based OS" screams client-server to me// so it sounds like Net-BSD is what you're looking for, from the title. |
|
| |
Yes Loris, it kind of is. In fact it absolutely could be although I approached the idea from a different angle. While I think I'm describing a method for doing Processing Mist, I'm not sure you would usually want to share CPU usage because because maybe bandwidth delays with large amounts of data for processing might mitigate the benefits of distributed processing used for ray tracing or what have you. |
|
| |
And with that I contradict my first response in this thread. But I think that what I am describing is sufficiently different from distributed computing as used today so as to be unbaked enough to qualify. |
|
| |
Flying Toaster
// so it sounds like Net-BSD is what you're looking for, from the title.// |
|
| |
Maybe? I can't tell if it would be a good candidate for base OS, though it certainly seems like a good place to start. |
|
| |
I think the problem is that you're attempting to replace one limited resource (processing power) with another, currently even more limited resource (network bandwidth). |
|
| |
I attempted to get round this in my idea by proposing new local network links. For intensive tasks, suitable work units would be batched out to neighbours. |
|
| |
You, on the other hand, don't have that local, highly efficient communication. And even small jobs which a basic computer can currently easily handle are torrented out, never mind that torrenting is intensive. They're not even assigned jobs, so you may get back no replies, or many. You've mixed in collaborative editing concepts for a whole new world of pain, too. |
|
| |
I honestly can't imagine what business app you think would be good for a concurrent multiple cooks/broth interface that can't already be accomplished. |
|
| |
For instance I think in Excel you can make a spreadsheet that's made up of other spreadsheets. Now if each person has write permission on their own little spreadsheet and read permission on the main one then this is exactly what you're talking about: they can modify their own portion and it will show up on the conglomerate for everybody to read. There's no reason why two people would want to modify the same cell at the same time... unless you're using a spreadsheet for stuff that should be a database, which already handles record locking. |
|
| |
I think there are some videogames which can be played on a LAN without a dedicated server though... Quake ? |
|
| |
You mention Notepad: IRC has been called "Multiplayer Notepad": everybody types stuff in whenever they want and a server collates it and sends it back as well as everybody else's input, to be displayed. |
|
| |
Flying Toaster:
The business case for collaborative editing is huge, and the reason I want to get away from the client-server model is that today client/server RT applications rely on web-based applications like zoho Sheet (for example). You lose the power existing applications because, lets face it, online office suites SUCK compared to most of the MS Office suite, the only popular truly excellent product MS makes today. Could MS build true RT into Office? Yes, but they haven't and probably won't; they'll put it into the cloud instead. Which is fine, but why wait for them? And Office isn't the only application we have to wait for. The idea here is to not be vendor-application-dependent in order to share. You should be able to share documents without respect to the underlying executable. |
|
| |
Being able to modify a document while others also modify the same exact space in the same document is huge. |
|
| |
//Being able to modify a document while others also modify the same exact space in the same document is huge.//
It certainly is. Sisyphean huge. |
|
| |
I guess I don't really understand where you are proposing to store data. |
|
| |
1) A 'master copy' on a single client computer, like most personal documents are now. Changes can be merged in at the whim of the owner. |
|
| |
2) On 'the cloud' - a server, somewhere, which arbritrates which edits get applied, like wikis etc. |
|
| |
3) On lots of different client computers, all of which can edit independently, with no authorative copy. When two copies come into contact with each other, they are merged in some fashion. |
|
| |
[bammin]//The business case for collaborative editing is
huge, and the reason I want to get away from the client-
server mode//
[Loris] //On lots of different client computers, all of which
can edit independently, with no authorative copy. When two
copies come into contact with each other, they are merged
in some fashion.// |
|
| |
Am I missing something, or is this a description of distributed
version control? |
|
| |
//Am I missing something, or is this a description of distributed version control?// |
|
| |
It might be distributed, but it's anything but version control. It's version chaos. |
|
| |
I'm tempted to call "troll" on this pending an explanation that doesn't include null-content or random buzzwords: "collab" "publish/share" "subscribe" "seeded" "torrent" "virtual machine": even the ones that actually mean something are discontextual. |
|
| |
Yes, I know: technical language is a difficulty if you're not already immersed in the area. |
|
| |
It isn't my field either, though I can see it from where I occasionally perch. |
|
| |