Yeah I'm not too sure on the finer points of the implementation. No other 
people have comments?

On Mar 15, 2011, at 2:33 AM, Graham Cantin <[email protected]> wrote:

> Most of this doesn't apply to Wayland directly, but to the ecosystem 
> surrounding it.
> 
> However, you did touch upon one feature there that has some merit within 
> Wayland, in my opinion.
> 
> Some way to serialize an application's set of windows to suspend and restore 
> them.
> 
> Right now, with X, you need to use some kind of proxy holding the 
> windows/desktop open if you want to be able to detach and reattach.
> 
> Since it sounds like the window toolkits are implementing wayland 
> communications paths, that would be the place to shim this in.
> 
> Wayland, supporting a generic capture of window objects, and QT and such 
> knowing how to restore the rest of the graphical state (like a repaint after 
> resize) itself after a window object was restored/deserialized.
> 
> So, one would serialize the window objects, transfer the package, deserialize 
> (which would recreate the window and properties on the new output device, and 
> then inform the application/toolkit the window was resized and it needs to 
> redraw.
> 
> This should also apply to wayland 'fullscreen' windows.
> 
> Note that there are several very advanced checkpoint systems for linux that 
> can freeze and restore processes, or the whole machine. 
> Collaborate with them to develop the proper hooks early so that 
> hibernate/restore and standby work as well, since the process has many 
> similarities.
> 
> On the other side of it; Rackspace and Amazon both have APIs you can spawn 
> new machines with. 
> Systemd brings up a system to multiuser in seconds. It is completely feasible 
> to spawn a machine in ten seconds, and during that time pack up the local 
> application state for transfer.
> 
> Really, I wouldn't mind a 25c Quarter Slot icon next to my Maximize icon.
> 
> http://www.priglmeier.com/arcade_projects/wiring_coin_doors_files/25-cents-coin-door-label-small-02172010.jpg
> Doubleclicking it shoves the app off to the cloud, state and all, in 15 
> seconds to a minute.
> Right clicking it gives you the context menu containing the VM size and cost.
> 
> 
> Josh, you're a guy after my own heart.
> I've got two ramdisk 780G hexcore machines with 16GB that act as my terminals 
> to my cheap supermicro dual E5620 with 64GB.
> They're blazingly speedy, and not too hard to set up! The trick is to get 
> 16GB sandisk Cruzer U3 drives and overwrite their ISO portion with 
> u3-tool.sf.net with an ubuntu livecd. Edit the boot options to turn on 
> persistent mode and TORAM=Yes. With a little bit of magic in your persistent 
> /home/ you can also use sshfs to mount other machines on the network.
> 
> Systemd, will of course, make this nasty hack obsolete since you can specify 
> automount points of /home/<username> as type sshfs.
> 
> If you don't want any disks, not even a USB key, booting over the network 
> with gpxe is pretty easy to set up these days and uses HTTP or HTTPS instead 
> of tftp. It's really easy on DD-WRT or OpenWRT, or any system with dnsmasq.
> 
> On Mon, Mar 14, 2011 at 4:24 PM, Josh Leverette <[email protected]> wrote:
> HPC (High Performance Compute) Architecture
> 
> ...the means by which we can make the Lion tremble.
> 
> I have hung around in the shadows of Wayland's development since it was an 
> infant, reading the different discussions that have taken place. I've 
> commented occasionally, but not very often. I don't believe I've ever 
> requested a feature, but this afternoon I was mowing my grandfather's lawn 
> and had plenty of time to think about what feature Wayland could provide to 
> catapult Linux to the top of the Operating System Wars. This is the idea I 
> came up with, please give it consideration. I think it is well within the 
> abilities of the people who have been contributing to Wayland so far, and 
> could attract other skilled developers to this project, and that's without 
> mentioning all of the long term impacts it could have. I've recently been 
> thinking about how difficult it will be for Linux to compete with Mac OS X 
> Lion, and this feature came to me as one that would make Linux a very 
> desirable option.
> 
> In Mac OS X Lion a variety of features are coming which make it extremely 
> competitive with Linux in ways that are very attractive to consumers and 
> enterprises alike. Among these are the inclusion of Apple's very friendly 
> server software in regular Mac OS X, the presence of the lucrative App Store, 
> the Mission Control interface, and very advanced and effective use of 
> multitouch from the trackpad.
> 
> Windows is dying, this will just be breaking already shattered glass, so no 
> need to discuss this here really.
> 
> Here's the gist of the idea, something that would give Ubuntu and other 
> Linuxes a step up on the other operating systems if implemented well inside 
> of Wayland from the start. I was recently on my iPad and discovered an app 
> called iSwifter which allows you to browse the web with fully enabled flash 
> content. What it does is it renders these pages on (as far as i can tell) an 
> Ubuntu server/desktop thing and streams it by using ffmpeg in a compressed 
> stream. Any input is sent back to the server for processing and the page is 
> manipulated accordingly and the result is returned to the iPad. This creates 
> the illusion of actually browsing the flash-enabled web on an iPad. 
> Occasionally you will see compression artifacts, but not very often.
> 
> Take this idea, but have it implemented in Wayland. Ideally this could be 
> negotiated with the window manager so that it could be done on a per-program 
> basis. When an application, such as Blender, is being used on a slow computer 
> or a netbook, it might be desirable to have it run faster. There would be a 
> button on each program's primary window which would allow you to transition 
> it to a remote High Performance Compute server. The application would write 
> down everything that it needs to in order to open back up to exactly where it 
> was before, this information would get compressed and sent to the server. The 
> server would start an instance of this application in a sandboxed virtual 
> machine (with resources limited based on the type of account the end user is 
> using, whether its a free account or a partially limited account, or a high 
> paying account with access to lots of resources) and this application would 
> load up the saved state information to resume where it left off. Preferably 
> the entire virtual machine would be running from a RAMDisk in order to 
> increase performance and security (as the memory would forget what had been 
> going on as soon as the copy of the virtual machine is shut down). Whenever 
> access to a file is requested, it gets compressed and sent over to the 
> virtual machine. The file would then be kept in sync between the two 
> computers. The application would be streaming its interface in a compressed 
> fashion to windows that are of the correct sizes so that the interface 
> appears to still be local. Each window would have its own stream. User input, 
> such as keyboard, mouse, or window resize/minimize events would all be 
> streamed back to the server for processing.
> 
> Before the transition would occur, it would need to check the integrity of 
> the internet connection, if it doesn't meet certain latency requirements and 
> bandwidth requirements, it might have to warn the user against running 
> remotely, but it could still work it out on a slow connection, it just might 
> not be as amazing of an experience. During the transition time from client to 
> server, or server to client the window would be greyed out and a nice looking 
> rounded box could be displayed showing a message that says the application is 
> being transported and it could show a progress bar representative of the 
> status (including compressing the app, uploading the app, and resuming the 
> app on the server) and a cancel button (for when transitioning to the 
> server). When the application is running on the remote server, the title bar 
> of each window of that application would ideally be a different color. If we 
> were using the Dark ambiance theme from Ubuntu, a nice glowing blue color 
> would still look good but clearly mark that this is a remote application. The 
> largest forseeable problem would be keeping a synchronous copy of the app as 
> it is on the server with the user on the local machine in case of a sudden 
> termination of the connection so that the program would hopefully not crash. 
> The files would already be syncronized though.
> 
> The final feature that would make this a killer feature for everyone from 
> consumers to enterprisers would be being able to easily set up your own HPC 
> service on your own hardware. It would have a user friendly interface, and it 
> could set up accounts with limited resource access. However, this interface 
> would have to be manipulated locally and manually. For a small fee they could 
> purchase a package which would allow for end users to enter payment methods 
> and control their account settings from anywhere in order to create an HPC 
> business. By default a copy of wayland would connect to either a service 
> hosted by Wayland or by the individual distribution, such as Canonical. This 
> service could generate revenue to fund Wayland development or each 
> distribution's development or just give revenue to third parties if the user 
> chose. In order for this feature to be a winner, there should be a free 
> account which would give say 1GB of RAMDisk space and 1GB of virtual machine 
> RAM (total of 2GB real RAM) and limited access to a graphics card, perhaps 
> also limiting the amount of server time they could have access to. This would 
> give them a taste of the product, and for a small amount of money ($5/month, 
> or whatever) they could upgrade to greater resources. As far as the end user 
> is concerned, this would mean they could play really intense games on a 
> netbook with the graphics settings at maximum, or they could encode a movie 
> project a lot faster, or they could make their own animated movies or short 
> films much faster. All of this without having to pay for a $1000+ machine. 
> For this feature to truly work, it would have to be implemented either in the 
> core of Wayland, or in a window manager on Wayland. I'm not too sure how it 
> would be done, but only that I have faith it can and should be done. Thank 
> you for considering this idea.
> 
> -- 
> Sincerely,
>     Josh
> 
> _______________________________________________
> wayland-devel mailing list
> [email protected]
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
> 
> 
> 
> 
> -- 
> [     Graham Cantin      ] | (408) 890-7463 - Google Voice FindME
> "Never feel stupid for asking questions, feel stupid for ignoring answers."
> [  System Administrator  ] | (XXX) XXX-XXXX xXXX - IT & Office PBX
> "You're arrogant for thinking you can, ignorant for thinking you cannot."
> [ RFSpot Mobile Services ] | (XXX) XXX-XXXX - Main Office Direct
> "Asking questions is important,
> because that's when intuition gets converted into inspiration."
> [   NASA Ames Research   ] | Building 19, Moffett Field, CA
> "As living spies we must recruit men who are intelligent but appear
> to be stupid; who seem to be dull but are strong in heart; men who are
> agile, vigorous, hardy, and brave; well-versed in lowly matters and able
> to endure hunger, cold, filth, and humiliation." - Tu Mu (803-825) 
> 
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Reply via email to