no he visto
The other week, as I walked toward the CalTrain station, someone said to his friend, ¡no he visto una china tan flaca como este allí!.
Hum, thanks?
Working through Feller is going slowly but well. Once I read through more of it, we'll see if Motwani makes more sense, and after that, I'll have to figure out how to "prove" (show) things about the use of triple-u sampling in theory+practice.
My adviser asked me what I imagined as an application of VLSD. I see that one timeline could be as follows:
A- Simulate a Turing-ish machine that executes on a URI subspace (as a bootstrap until more of URI space supports read and write).
B- Simulate a LISP-y pointer machine that encourages object space flexibility.
(An object may live on local host as Ruby or MySQL, or may be addressed remotely as a URI, or may be remotely proxy balanced -- the point is, all can be addressed through a URI schema.
To avoid what follows from "worse is better", namely that it becomes difficult for a median human to estimate perf from code, I suggest that we adopt VLSI-styled strategies that map from large scale designs to an actual VLSD layout semi-automatically (!), where similar partitioning-type flow-minimizers can be applied on the pull-back space where we substitute TTL for virtual machines that talk YAML over HTTP.
Pulling back some more, I ask you to consider the following thought experiment. If, instead of your fancy Intel Core Duo on your supercooled lap, what if your MacBook Pro had ten thousand Intel Cores on it, each running a hundred virtual machines. How would you program and organize data on such a scale? Specifically, how would you execute Firefox running on Tiger? Googoo or Yoohoo? Hint: I would not suggest using a low-level language such as Java and a human-unreadable language such as XML.
VM as TTL promotes interop in another notable way. As long as your favorite OS (exokernel or whatnot) or VM (Squeak or Linus-written thingies) run on a virtual machine monitor, and simply support YAML over HTTP, people will actually be able to use your work without having to dedicate a non-virtual machine to your technology.
Is that not interesting? Rather than worrying about how to write the next Ruby VM, why not say simply that Linux /is/ the next Ruby VM, and assume that shortly, everyone who does data center design will be running paravirtually (through Xen or some hypothetical VMWare competitor)? Instead of running a bajillion line long Rake script to set up a non-virtual host to play with Squeak written for some (presently) obscure MIT exokernel, you simply download the VM image you want (which has said paravirtualized exokernel completely set up) and connect it up to your existing boxes through YAML over HTTP.
Yes, a VM image seems kind of large, but I'm sure it's possible to generalize the algorithms behind rsync to handle transferring sets of similar images in a spacetime efficient way, and deployment then becomes something that sucks a little less, once you figure out how to configure the VM per deployment stage, but you could always establish mappings between hostname regexps and stages etc.)
C- Support annotation of any global URI, at least through the lens of a local URI subspace that maintains a kind of VAT of Cells (virtual address table) to establish a kind of graph homomorphism between the Web at large and the URI subspace that we own.
D- Build a set of forums on top of said homomorphism. This has been done before, kind of, but our contribution should be in terms of intentional design of community space, with the thesis that you /can/ have a million people talking at once and have it make sense. Such a design must think carefully about statistical sampling, safe space, spam slash robot warfare, inappropriate ad content, the social semantics of exclusion and exclusionary space, and so on.
In other words, the hard part :)
Hum, thanks?
Working through Feller is going slowly but well. Once I read through more of it, we'll see if Motwani makes more sense, and after that, I'll have to figure out how to "prove" (show) things about the use of triple-u sampling in theory+practice.
My adviser asked me what I imagined as an application of VLSD. I see that one timeline could be as follows:
A- Simulate a Turing-ish machine that executes on a URI subspace (as a bootstrap until more of URI space supports read and write).
B- Simulate a LISP-y pointer machine that encourages object space flexibility.
(An object may live on local host as Ruby or MySQL, or may be addressed remotely as a URI, or may be remotely proxy balanced -- the point is, all can be addressed through a URI schema.
To avoid what follows from "worse is better", namely that it becomes difficult for a median human to estimate perf from code, I suggest that we adopt VLSI-styled strategies that map from large scale designs to an actual VLSD layout semi-automatically (!), where similar partitioning-type flow-minimizers can be applied on the pull-back space where we substitute TTL for virtual machines that talk YAML over HTTP.
Pulling back some more, I ask you to consider the following thought experiment. If, instead of your fancy Intel Core Duo on your supercooled lap, what if your MacBook Pro had ten thousand Intel Cores on it, each running a hundred virtual machines. How would you program and organize data on such a scale? Specifically, how would you execute Firefox running on Tiger? Googoo or Yoohoo? Hint: I would not suggest using a low-level language such as Java and a human-unreadable language such as XML.
VM as TTL promotes interop in another notable way. As long as your favorite OS (exokernel or whatnot) or VM (Squeak or Linus-written thingies) run on a virtual machine monitor, and simply support YAML over HTTP, people will actually be able to use your work without having to dedicate a non-virtual machine to your technology.
Is that not interesting? Rather than worrying about how to write the next Ruby VM, why not say simply that Linux /is/ the next Ruby VM, and assume that shortly, everyone who does data center design will be running paravirtually (through Xen or some hypothetical VMWare competitor)? Instead of running a bajillion line long Rake script to set up a non-virtual host to play with Squeak written for some (presently) obscure MIT exokernel, you simply download the VM image you want (which has said paravirtualized exokernel completely set up) and connect it up to your existing boxes through YAML over HTTP.
Yes, a VM image seems kind of large, but I'm sure it's possible to generalize the algorithms behind rsync to handle transferring sets of similar images in a spacetime efficient way, and deployment then becomes something that sucks a little less, once you figure out how to configure the VM per deployment stage, but you could always establish mappings between hostname regexps and stages etc.)
C- Support annotation of any global URI, at least through the lens of a local URI subspace that maintains a kind of VAT of Cells (virtual address table) to establish a kind of graph homomorphism between the Web at large and the URI subspace that we own.
D- Build a set of forums on top of said homomorphism. This has been done before, kind of, but our contribution should be in terms of intentional design of community space, with the thesis that you /can/ have a million people talking at once and have it make sense. Such a design must think carefully about statistical sampling, safe space, spam slash robot warfare, inappropriate ad content, the social semantics of exclusion and exclusionary space, and so on.
In other words, the hard part :)
posted by L. Wu @ 7:22 AM
0 Comments:
Post a Comment
<< Home