From sheryljmoen4 at gmail.com Thu Aug 1 02:43:53 2013 From: sheryljmoen4 at gmail.com (Sheryl Moen) Date: Thu, 01 Aug 2013 06:43:53 +0000 Subject: [mosh-devel] www.mit.edu Message-ID: <001a11c1e4cc6386b504e2dd2a83@google.com>
Hi,

I came across your website and wanted to send you a quick note. With a few simple changes to make your site more SEO-friendly I?m sure you can convert more visitors into leads and get it placed higher in the organic search results, for keywords that matter to you the most.

We?re an Australian based company with a great in-house technical team who really know their stuff about search engine optimization.?

Would you like a bit more information about how to give your website a boost with better SEO? Please feel free to drop me an email or you can contact me via our website.

Best Regards
Sheryl Jones
SEO/Web Specialist
seo at immaculateseo.com
Inline image 2

AUS Headquarter
Australian Technology Park, Locomotive Street, Eveleigh
NSW 2015

International Headquarter
501 19th Street, N.W., Washington, D.C. 20431
Office Phone: 206-202-2907



-------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/mosh-devel/attachments/20130801/06b09956/attachment.html From nbad55 at gmx.us Sat Aug 3 01:39:55 2013 From: nbad55 at gmx.us (NBAD BANK) Date: Sat, 3 Aug 2013 07:39:55 +0200 (CEST) Subject: [mosh-devel] $60.6 MILLION USD TO CREDIT TO YOUR ACCOUNT Message-ID: <1629161138.51474.1375508395755.JavaMail.www-data@mafe02.dlan.cinetic.de> GMX File Storage The New Online Storage ------------------------------------------------------------------ NBAD BANK wants to share a file/folder with you in a GMX File Storage directory. This e-mail enables you to access NBAD BANK?s file share. NBAD BANK has added this personal message: Dear Friend,? This letter must come to you as a surprise, but I believe it is only a day that people meet and become great friends and business partners.? I am pleased to get across to you for a very urgent and profitable business proposal;? I am Mr. Abdulla Al Otaiba, Senior General Manager of Domestic Banking Division , National Bank of Abu-Dhabi, United Arab Emirates,? I am writing this letter to ask for your support and co-operation to carry out this business opportunity in my department,There are huge sum of money ($60.6 Million USD) by which i want to transfer out to your account as a foreginer The fund will be transfer to your any bank account of your choice and sharing shall be 50/50%, If you are interested and can do things confidential kindly get back to me for more details. send your reply to Pvt email : a.otaibabdulla at outlook.com Thanks God Bless,? Best Regards? ?Mr. Abdulla Al Otaiba To accept the invitation, just click the following link: NBAD (https://storage-eu.gmx.com/guest?path=NBAD%20from%20nbad55%40gmx.us&token=00BE44618E2F2B8C&mandant=04&product=gmxcom&locale=en_US&viewType=0) You may also enter this link directly into your browser by copying the following URL into the address field: https://storage-eu.gmx.com/guest?path=NBAD%20from%20nbad55%40gmx.us&token=00BE44618E2F2B8C&mandant=04&product=gmxcom&locale=en_US&viewType=0 ------------------------------------------------------------------ You don't have your own GMX File Storage? Discover all its exciting features. Free! http://filestorage.gmx.com/?mc=fs at mail.lp@fs -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/mosh-devel/attachments/20130803/999fd842/attachment.html From tom at sonelli.com Sat Aug 3 13:34:26 2013 From: tom at sonelli.com (Tom Maddox) Date: Sat, 3 Aug 2013 18:34:26 +0100 Subject: [mosh-devel] JuiceSSH STPClient Resuming Message-ID: Hi, We're currently beta testing MOSH integration with our Android SSH client, JuiceSSH, of which the progress can be followed in our G+ community . One issue that has been raised so far is battery usage. Currently when JuiceSSH has any active connections, there is a service running which holds a device wake lock and polls the connections for failures. Seeing as Mosh sessions should always be resumable, and as Keith pointed out, this shouldn't be necessary in the case of Mosh. Keith implied that he may be able to help us save the state of a mosh-client process, allowing for it to be resumed in the future. I've planned the majority of how to exclude Mosh sessions from wake locks and connection polling, and I'm confident that we'll be able to catch the point that the state should be saved and then finally I know how we could implement an "if-process-not-running-attempt-resume"-esque session. But the bit I'm not sure about is how to get the state, what form it will be in, and then how to reuse it. Having looked through the research paper and checking out the presentation, it would appear that this functionality is not yet in place. If so, and this functionality is new, then one solution I can think of would be the ability to run "mosh-client --resume-from-state [|]" to resume the process and perhaps a certain kill signal could result in mosh-client printing it's state just before it finishes. Any thoughts or help would be really appreciated. We're both very excited here about how convenient and nice this tool will be. As a couple of SysAdmins that wrote JuiceSSH mostly during our commutes on trains, we certainly appreciate the benefits! Thanks and regards, Tom Tom Maddox *Co-founder, Sonelli Ltd* tom at sonelli.com | https://sonelli.com JuiceSSH - Free SSH client for Android -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/mosh-devel/attachments/20130803/88709737/attachment.html From dave.taht at gmail.com Sat Aug 3 13:55:22 2013 From: dave.taht at gmail.com (Dave Taht) Date: Sat, 3 Aug 2013 10:55:22 -0700 Subject: [mosh-devel] JuiceSSH STPClient Resuming In-Reply-To: References: Message-ID: On Sat, Aug 3, 2013 at 10:34 AM, Tom Maddox wrote: > Hi, > > We're currently beta testing MOSH integration with our Android SSH client, > JuiceSSH, of which the progress can be followed in our G+ community. Groovy! Mosh has been a lifesaver for me in my environment. THANK YOU for taking this on! -- Dave T?ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html From keithw at MIT.EDU Sat Aug 3 23:57:02 2013 From: keithw at MIT.EDU (Keith Winstein) Date: Sat, 3 Aug 2013 23:57:02 -0400 Subject: [mosh-devel] JuiceSSH STPClient Resuming In-Reply-To: References: Message-ID: Hi Tom, Thanks for getting in touch. We can work with you to serialize the state of an STMClient object and restore it later. We are eager to see an Android Mosh client in the Play Store. The major major constraint here is that you can only restore from a serialized state *once*. We will want mosh-client to erase the serialized state before using it to make sure it can't be reused. The reason is that if you reuse a crypto sequence number (the nonce), that blows everything. How would you like to communicate with mosh-client that you want it to quit and dump state? You could just send us a SIGUSR1 or something and we could write it to stdout bracketed with something like BEGIN MOSH SAVED STATE if that works for you. And then if you give us a filename on startup (that we can erase), that would work fine to restore. I should ask -- are you running mosh-client as a separate binary or are you linking against it? (If linking against it, just to check, is your app under the GPL too?) Also, what sort of timeframe are you looking at for your release? Cheers, Keith On Sat, Aug 3, 2013 at 1:34 PM, Tom Maddox wrote: > Hi, > > We're currently beta testing MOSH integration with our Android SSH client, > JuiceSSH, of which the progress can be followed in our G+ community > . > > One issue that has been raised so far is battery usage. Currently when > JuiceSSH has any active connections, there is a service running which holds > a device wake lock and polls the connections for failures. Seeing as Mosh > sessions should always be resumable, and as Keith pointed out, this > shouldn't be necessary in the case of Mosh. > > Keith implied that he may be able to help us save the state of a > mosh-client process, allowing for it to be resumed in the future. > > I've planned the majority of how to exclude Mosh sessions from wake locks > and connection polling, and I'm confident that we'll be able to catch the > point that the state should be saved and then finally I know how we could > implement an "if-process-not-running-attempt-resume"-esque session. > > But the bit I'm not sure about is how to get the state, what form it will > be in, and then how to reuse it. > > Having looked through the research paper and checking out the > presentation, it would appear that this functionality is not yet in place. > If so, and this functionality is new, then one solution I can think of > would be the ability to run "mosh-client --resume-from-state > [|]" to resume the process and perhaps a > certain kill signal could result in mosh-client printing it's state just > before it finishes. > > Any thoughts or help would be really appreciated. We're both very excited > here about how convenient and nice this tool will be. As a couple of > SysAdmins that wrote JuiceSSH mostly during our commutes on trains, we > certainly appreciate the benefits! > > Thanks and regards, > Tom > > Tom Maddox > *Co-founder, Sonelli Ltd* > tom at sonelli.com | https://sonelli.com > JuiceSSH - Free SSH client for Android > > _______________________________________________ > mosh-devel mailing list > mosh-devel at mit.edu > http://mailman.mit.edu/mailman/listinfo/mosh-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/mosh-devel/attachments/20130803/7c6c6eb0/attachment.html From tom at sonelli.com Sun Aug 4 06:10:31 2013 From: tom at sonelli.com (Tom Maddox) Date: Sun, 4 Aug 2013 11:10:31 +0100 Subject: [mosh-devel] JuiceSSH STPClient Resuming In-Reply-To: References: Message-ID: Hi Keith, Brilliant, it looks like we're gonna be able to get this sussed out then. So, the licensing stuff. We're building mosh-client from source on a dedicated build server and then including that binary with our app to run as a subprocess. We've also included (as of this release) an About page in our Settings Menu which displays information and licenses of all open source projects used, including the GPL notice. Our application isn't open source as that would rather quickly make our in-app purchase worthless however, mosh and other open source dependent features are included within JuiceSSH's core functionality and will never require a purchase. Whilst we don't want or expect to ever make a huge sum of money through pro-pack purchases, we do have some hosting and test device costs we'd like to cover. If you feel that we're not meeting the requirements of mosh's license, we'll be happy to do our best to make changes to that end. I think I understand what you mean by only allowing a restore to happen once from a serialised state. But just to check, if a session had been restored in a new process successfully, would we then be able to repeat the save state and resume later procedure? The kill signal solution with the state printed stdout should definitely be workable. It'll take a bit of work to intercept the io streams before it reaches the terminal but it's certainly not impossible. A couple of ideas that come to mind with this functionality: 1. JuiceSSH has a pro feature called CloudSync which keeps devices in sync with AES-256 encrypted backups. There's the potential to use this or NFC to add some "Resume on tablet" functionality. 2. Is there anything server side that would prevent a state being reused more than once? For example, if a connection is made where the client's state is older than that of the last recorded client state, then the new client (in the older state) is denied updates. Thanks again, Tom Tom Maddox *Co-founder, Sonelli Ltd* tom at sonelli.com | https://sonelli.com JuiceSSH - Free SSH client for Android On 4 August 2013 04:57, Keith Winstein wrote: > Hi Tom, > > Thanks for getting in touch. We can work with you to serialize the state > of an STMClient object and restore it later. We are eager to see an Android > Mosh client in the Play Store. > > The major major constraint here is that you can only restore from a > serialized state *once*. We will want mosh-client to erase the serialized > state before using it to make sure it can't be reused. The reason is that > if you reuse a crypto sequence number (the nonce), that blows everything. > > How would you like to communicate with mosh-client that you want it to > quit and dump state? You could just send us a SIGUSR1 or something and we > could write it to stdout bracketed with something like BEGIN MOSH SAVED > STATE if that works for you. And then if you give us a filename on startup > (that we can erase), that would work fine to restore. > > I should ask -- are you running mosh-client as a separate binary or are > you linking against it? (If linking against it, just to check, is your app > under the GPL too?) > > Also, what sort of timeframe are you looking at for your release? > > Cheers, > Keith > > On Sat, Aug 3, 2013 at 1:34 PM, Tom Maddox wrote: > >> Hi, >> >> We're currently beta testing MOSH integration with our Android SSH >> client, JuiceSSH, of which the progress can be followed in our G+ >> community >> . >> >> One issue that has been raised so far is battery usage. Currently when >> JuiceSSH has any active connections, there is a service running which holds >> a device wake lock and polls the connections for failures. Seeing as Mosh >> sessions should always be resumable, and as Keith pointed out, this >> shouldn't be necessary in the case of Mosh. >> >> Keith implied that he may be able to help us save the state of a >> mosh-client process, allowing for it to be resumed in the future. >> >> I've planned the majority of how to exclude Mosh sessions from wake locks >> and connection polling, and I'm confident that we'll be able to catch the >> point that the state should be saved and then finally I know how we could >> implement an "if-process-not-running-attempt-resume"-esque session. >> >> But the bit I'm not sure about is how to get the state, what form it will >> be in, and then how to reuse it. >> >> Having looked through the research paper and checking out the >> presentation, it would appear that this functionality is not yet in place. >> If so, and this functionality is new, then one solution I can think of >> would be the ability to run "mosh-client --resume-from-state >> [|]" to resume the process and perhaps a >> certain kill signal could result in mosh-client printing it's state just >> before it finishes. >> >> Any thoughts or help would be really appreciated. We're both very excited >> here about how convenient and nice this tool will be. As a couple of >> SysAdmins that wrote JuiceSSH mostly during our commutes on trains, we >> certainly appreciate the benefits! >> >> Thanks and regards, >> Tom >> >> Tom Maddox >> *Co-founder, Sonelli Ltd* >> tom at sonelli.com | https://sonelli.com >> JuiceSSH - Free SSH client for Android >> >> _______________________________________________ >> mosh-devel mailing list >> mosh-devel at mit.edu >> http://mailman.mit.edu/mailman/listinfo/mosh-devel >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/mosh-devel/attachments/20130804/834cdeea/attachment.html From keithw at MIT.EDU Tue Aug 6 18:09:40 2013 From: keithw at MIT.EDU (Keith Winstein) Date: Tue, 6 Aug 2013 18:09:40 -0400 Subject: [mosh-devel] JuiceSSH STPClient Resuming In-Reply-To: References: Message-ID: Hi Tom, (1) Running mosh-client as a subprocess at arms length sounds fine to me. Just wanted to make sure we don't have to worry about it, e.g. if you were linking or doing a closer binding than that. (2) Yes, you would be able to repeat the operation of saving and restoring a session as many times as you like -- each time you save, you would create a new saved state. Each such state could only be restored once. (3) My guess of the way we would enforce this "use once" property is as follows. To resume mosh-client from a saved state, JuiceSSH would give it a filename where a different mosh-client had previously written out its saved state. mosh-client will open() this filename, check that the open succeeded, unlink() the filename, check that the unlink() succeeded, and then read and use the saved state. We should check to make sure this really does eliminate a race condition where two mosh-clients get started at nearly the same time with the same stored state. (4) Re: your ideas, once you start talking about copying the saved state around to different machines I get nervous! :-) We really do not have the crypto support to do this robustly, i.e. to prevent the same nonce from getting sent twice with different data. We may have to think about protocol modifications that allow the key to rotate if you are serious about wanting this. Otherwise it makes me uncomfortable. Having the server detect this and deny one of the clients updates doesn't help -- once there are two different ciphertexts out there with the same key, same nonce, and different plaintext, it's basically game over. And the server may not be able to detect it if an adversary can prevent one set of datagrams from reaching the server. Cheers, Keith On Sun, Aug 4, 2013 at 6:10 AM, Tom Maddox wrote: > Hi Keith, > > Brilliant, it looks like we're gonna be able to get this sussed out then. > > So, the licensing stuff. We're building mosh-client from source on a > dedicated build server and then including that binary with our app to run > as a subprocess. We've also included (as of this release) an About page in > our Settings Menu which displays information and licenses of all open > source projects used, including the GPL notice. > Our application isn't open source as that would rather quickly make our > in-app purchase worthless however, mosh and other open source dependent > features are included within JuiceSSH's core functionality and will never > require a purchase. Whilst we don't want or expect to ever make a huge sum > of money through pro-pack purchases, we do have some hosting and test > device costs we'd like to cover. > If you feel that we're not meeting the requirements of mosh's license, > we'll be happy to do our best to make changes to that end. > > I think I understand what you mean by only allowing a restore to happen > once from a serialised state. But just to check, if a session had been > restored in a new process successfully, would we then be able to repeat the > save state and resume later procedure? > > The kill signal solution with the state printed stdout should definitely > be workable. It'll take a bit of work to intercept the io streams before it > reaches the terminal but it's certainly not impossible. > > A couple of ideas that come to mind with this functionality: > > 1. JuiceSSH has a pro feature called CloudSync which keeps devices in > sync with AES-256 encrypted backups. There's the potential to use this or > NFC to add some "Resume on tablet" functionality. > 2. Is there anything server side that would prevent a state being > reused more than once? For example, if a connection is made where the > client's state is older than that of the last recorded client state, then > the new client (in the older state) is denied updates. > > Thanks again, > Tom > > > Tom Maddox > *Co-founder, Sonelli Ltd* > tom at sonelli.com | https://sonelli.com > JuiceSSH - Free SSH client for Android > > > On 4 August 2013 04:57, Keith Winstein wrote: > >> Hi Tom, >> >> Thanks for getting in touch. We can work with you to serialize the state >> of an STMClient object and restore it later. We are eager to see an Android >> Mosh client in the Play Store. >> >> The major major constraint here is that you can only restore from a >> serialized state *once*. We will want mosh-client to erase the serialized >> state before using it to make sure it can't be reused. The reason is that >> if you reuse a crypto sequence number (the nonce), that blows everything. >> >> How would you like to communicate with mosh-client that you want it to >> quit and dump state? You could just send us a SIGUSR1 or something and we >> could write it to stdout bracketed with something like BEGIN MOSH SAVED >> STATE if that works for you. And then if you give us a filename on startup >> (that we can erase), that would work fine to restore. >> >> I should ask -- are you running mosh-client as a separate binary or are >> you linking against it? (If linking against it, just to check, is your app >> under the GPL too?) >> >> Also, what sort of timeframe are you looking at for your release? >> >> Cheers, >> Keith >> >> On Sat, Aug 3, 2013 at 1:34 PM, Tom Maddox wrote: >> >>> Hi, >>> >>> We're currently beta testing MOSH integration with our Android SSH >>> client, JuiceSSH, of which the progress can be followed in our G+ >>> community >>> . >>> >>> One issue that has been raised so far is battery usage. Currently when >>> JuiceSSH has any active connections, there is a service running which holds >>> a device wake lock and polls the connections for failures. Seeing as Mosh >>> sessions should always be resumable, and as Keith pointed out, this >>> shouldn't be necessary in the case of Mosh. >>> >>> Keith implied that he may be able to help us save the state of a >>> mosh-client process, allowing for it to be resumed in the future. >>> >>> I've planned the majority of how to exclude Mosh sessions from wake >>> locks and connection polling, and I'm confident that we'll be able to catch >>> the point that the state should be saved and then finally I know how we >>> could implement an "if-process-not-running-attempt-resume"-esque session. >>> >>> But the bit I'm not sure about is how to get the state, what form it >>> will be in, and then how to reuse it. >>> >>> Having looked through the research paper and checking out the >>> presentation, it would appear that this functionality is not yet in place. >>> If so, and this functionality is new, then one solution I can think of >>> would be the ability to run "mosh-client --resume-from-state >>> [|]" to resume the process and perhaps a >>> certain kill signal could result in mosh-client printing it's state just >>> before it finishes. >>> >>> Any thoughts or help would be really appreciated. We're both very >>> excited here about how convenient and nice this tool will be. As a couple >>> of SysAdmins that wrote JuiceSSH mostly during our commutes on trains, we >>> certainly appreciate the benefits! >>> >>> Thanks and regards, >>> Tom >>> >>> Tom Maddox >>> *Co-founder, Sonelli Ltd* >>> tom at sonelli.com | https://sonelli.com >>> JuiceSSH - Free SSH client for Android >>> >>> _______________________________________________ >>> mosh-devel mailing list >>> mosh-devel at mit.edu >>> http://mailman.mit.edu/mailman/listinfo/mosh-devel >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/mosh-devel/attachments/20130806/ecf594c9/attachment.html From eternaleye at gmail.com Tue Aug 6 13:52:01 2013 From: eternaleye at gmail.com (Alex Elsayed) Date: Tue, 06 Aug 2013 17:52:01 +0000 Subject: [mosh-devel] JuiceSSH STPClient Resuming References: Message-ID: Keith Winstein wrote: > Hi Tom, > (3) My guess of the way we would enforce this "use once" property is as > follows. To resume mosh-client from a saved state, JuiceSSH would give it > a filename where a different mosh-client had previously written out its > saved state. mosh-client will open() this filename, check that the open > succeeded, unlink() the filename, check that the unlink() succeeded, and > then read and use the saved state. We should check to make sure this > really does eliminate a race condition where two mosh-clients get started > at nearly the same time with the same stored state. I'd recommend using O_EXCL on the open. Even without it you ought to be fine - then both open()'s could run before the unlink(), but the unlink should fail in that case. The second check would catch it, but better to prevent the other instance from getting an FD at all. That eliminates the potential for a mistake in checking the return code. > (4) Re: your ideas, once you start talking about copying the saved state > around to different machines I get nervous! :-) We really do not have the > crypto support to do this robustly, i.e. to prevent the same nonce from > getting sent twice with different data. We may have to think about > protocol modifications that allow the key to rotate if you are serious > about wanting this. Otherwise it makes me uncomfortable. > > Having the server detect this and deny one of the clients updates doesn't > help -- once there are two different ciphertexts out there with the same > key, same nonce, and different plaintext, it's basically game over. And > the server may not be able to detect it if an adversary can prevent one > set of datagrams from reaching the server. One solution here might be to have JuiceSSH mandate that doing this involves *moving* the state file, rather than copying it - do the same O_EXCL/unlink() dance in JuiceSSH to block mosh from starting up with it, then read the FD and send it to another JuiceSSH instance. There'd need to be some way to rendezvous and send it on-demand rather than simply putting it in cloud storage, though, which raises the complexity. From jkorfanty at acieu.co.uk Wed Aug 7 09:39:53 2013 From: jkorfanty at acieu.co.uk (CO2 Utilisation Summit 2013) Date: Wed, 07 Aug 2013 06:39:53 -0700 Subject: [mosh-devel] Methanex Joins as Sponsor Message-ID: <100.0.2.143.1CE93739914308C.5BC8A@me22564.mailengine1.com> Carbon Dioxide Utilisation Summit 2013 30th & 31st October Brussels, Belgium CO2 AS A FEEDSTOCK FOR FUELS & CHEMICALS __________________________________________________ LATEST UPDATES - NEW SPONOR We are pleased to announce Methanex as a new sponsor for Carbon Dioxide Utilisation Summit 2013 (30th & 31st October in Brussels) __________________________________________________ AGENDA DOWNLOAD For more information please download the latest agenda by clicking below: Alternatively, request the brochure >> and we will send you a copy by email. __________________________________________________ SPONSORS OF THE EVENT Virgin Management Ltd Carbon Engineering Ltd Climeworks AG ÉCOLE POLYTECHNIQUE FÉDÉRALE DE LAUSANNE Methanex __________________________________________________ EVENT PANEL MEMBERS Dr. Peter Radgen, Head of E.ON Innovation Center, E.ON Technology & Innovation Dr. Thibault Cantat, Associate Researcher, CEA Adrew Read, Manager - CCS Projects, Alberta Energy Peter H. Shepard, Chief Business Officer, Novomer Inc. John Williams, President of Public Relations, LanzaTech Tony Alderson, CCS Technical Lead, Power Generation, Parsons Brinckerhoff Dr. Gernot Klotz, Executive Director Research and Innovation, CEFIC AISBL (European Chemical Industry Council) Edward Rode, Principal Researcher, DNV Dr. Dennis Kramer, Engineer, Dechema e.V. Eryk Remiezowicz, Research and Development Manager, ACP Group Paul Snaith, Executive Vice President, Chief Business Officer, Joule Unlimited Technologies Inc. Dr. Thomas Haas, Vice President Biotechnology, Evonik Industries AG David Addison, Earth Challenge Manager, Virgin Management Ltd Christoph Gebald, Director & Founder, Climeworks AG Stijn Santen, Director, CO2-Net B.V. and many more For the full list of speakers please click here >> __________________________________________________ 3 EASY WAYS TO REGISTER Please contact Justyna Korfanty on: jkorfanty at acieu.co.uk +44 (0) 20 3141 0607 Registration Webpage > __________________________________________________ CONTACT Sponsorship Opportunities Gain access to your target audience. For more info on sponsorship opportunities please contact Mark Thomas >> on +44 (0)20 3141 0628 Speaking Opportunities If you would like to be considered as a speaker for Carbon Dioxide Utilisation Summit 2013 please let us know. Speaking slots are 30-45 minutes in duration. Please contact Tamas Joo >> on +44 (0)20 31 41 0643 Media Partnership If you would like to become a Media Partner for this event, please contact Justyna Korfanty >> on +44 (0) 20 3141 0607 __________________________________________________ DO NOT MISS OUT ON THE CO2 UTILISATION EVENT OF THE YEAR! SPACES ARE STRICTLY LIMITED. __________________________________________________ Reserve your seat now >> Forward to a Friend >> Unsubscribe >> __________________________________________________ ACI EUROPE, 5/13 Great Suffolk Street, SE1 0NS London E: jkorfanty at acieu.co.uk | T: + 44 (0) 20 3141 0607 | F: +44 (0) 20 7593 0071 Click here on http://server1.streamsend.com/streamsend/unsubscribe.php?cd=3896&md=2627&ud=de3832d0c30b2cabb4b5e10aef2a1b5f to update your profile or Unsubscribe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/mosh-devel/attachments/20130807/dfe727bb/attachment.html From jake at spaz.org Wed Aug 7 17:54:38 2013 From: jake at spaz.org (Jake) Date: Wed, 7 Aug 2013 14:54:38 -0700 (PDT) Subject: [mosh-devel] can't find version of mosh Message-ID: hi, I don't know if this is a bug or not but I was unable to determine what version of mosh i am running. I tried mosh, mosh-client and mosh-server with -v and --version and --help and none of them tell me what version. is this normal? how should i find out what version i'm running? thank you -jake jake at pe2950 ~]$ mosh --help Usage: /usr/local/bin/mosh [options] [--] [user@]host [command...] --client=PATH mosh client on local machine (default: "mosh-client") --server=COMMAND mosh server on remote machine (default: "mosh-server") --predict=adaptive local echo for slower links [default] -a --predict=always use local echo even on fast links -n --predict=never never use local echo --predict=experimental aggressively echo even when incorrect -p PORT[:PORT2] --port=PORT[:PORT2] server-side UDP port or range --ssh=COMMAND ssh command to run when setting up session (example: "ssh -p 2222") (default: "ssh") --no-init do not send terminal initialization string --help this message --version version and copyright information Please report bugs to mosh-devel at mit.edu. Mosh home page: http://mosh.mit.edu [jake at pe2950 ~]$ From hari at csail.mit.edu Wed Aug 7 17:58:27 2013 From: hari at csail.mit.edu (Hari Balakrishnan) Date: Wed, 7 Aug 2013 17:58:27 -0400 Subject: [mosh-devel] can't find version of mosh In-Reply-To: References: Message-ID: <9B0FB199-0373-4A15-AEBD-CE2578549BB0@csail.mit.edu> hari at tom:~$ mosh -v mosh 1.2.3 On Aug 7, 2013, at 5:54 PM, Jake wrote: > hi, > > I don't know if this is a bug or not but I was unable to determine what > version of mosh i am running. I tried mosh, mosh-client and mosh-server > with -v and --version and --help and none of them tell me what version. > > is this normal? how should i find out what version i'm running? > > thank you > -jake > > jake at pe2950 ~]$ mosh --help > Usage: /usr/local/bin/mosh [options] [--] [user@]host [command...] > --client=PATH mosh client on local machine > (default: "mosh-client") > --server=COMMAND mosh server on remote machine > (default: "mosh-server") > > --predict=adaptive local echo for slower links [default] > -a --predict=always use local echo even on fast links > -n --predict=never never use local echo > --predict=experimental aggressively echo even when incorrect > > -p PORT[:PORT2] > --port=PORT[:PORT2] server-side UDP port or range > > --ssh=COMMAND ssh command to run when setting up session > (example: "ssh -p 2222") > (default: "ssh") > > --no-init do not send terminal initialization string > > --help this message > --version version and copyright information > > Please report bugs to mosh-devel at mit.edu. > Mosh home page: http://mosh.mit.edu > [jake at pe2950 ~]$ > _______________________________________________ > mosh-devel mailing list > mosh-devel at mit.edu > http://mailman.mit.edu/mailman/listinfo/mosh-devel From jake at spaz.org Wed Aug 7 18:13:27 2013 From: jake at spaz.org (Jake) Date: Wed, 7 Aug 2013 15:13:27 -0700 (PDT) Subject: [mosh-devel] can't find version of mosh In-Reply-To: <9B0FB199-0373-4A15-AEBD-CE2578549BB0@csail.mit.edu> References: <9B0FB199-0373-4A15-AEBD-CE2578549BB0@csail.mit.edu> Message-ID: oh there it is! sorry i didn't find it by myself, i can be quite blind sometimes. it's even in the thing I pasted to you. thank you! -jake On Wed, 7 Aug 2013, Hari Balakrishnan wrote: > hari at tom:~$ mosh -v > mosh 1.2.3 > > On Aug 7, 2013, at 5:54 PM, Jake wrote: > >> hi, >> >> I don't know if this is a bug or not but I was unable to determine what >> version of mosh i am running. I tried mosh, mosh-client and mosh-server >> with -v and --version and --help and none of them tell me what version. >> >> is this normal? how should i find out what version i'm running? >> >> thank you >> -jake >> >> jake at pe2950 ~]$ mosh --help >> Usage: /usr/local/bin/mosh [options] [--] [user@]host [command...] >> --client=PATH mosh client on local machine >> (default: "mosh-client") >> --server=COMMAND mosh server on remote machine >> (default: "mosh-server") >> >> --predict=adaptive local echo for slower links [default] >> -a --predict=always use local echo even on fast links >> -n --predict=never never use local echo >> --predict=experimental aggressively echo even when incorrect >> >> -p PORT[:PORT2] >> --port=PORT[:PORT2] server-side UDP port or range >> >> --ssh=COMMAND ssh command to run when setting up session >> (example: "ssh -p 2222") >> (default: "ssh") >> >> --no-init do not send terminal initialization string >> >> --help this message >> --version version and copyright information >> >> Please report bugs to mosh-devel at mit.edu. >> Mosh home page: http://mosh.mit.edu >> [jake at pe2950 ~]$ >> _______________________________________________ >> mosh-devel mailing list >> mosh-devel at mit.edu >> http://mailman.mit.edu/mailman/listinfo/mosh-devel > From support at sonelli.com Thu Aug 8 11:28:10 2013 From: support at sonelli.com (Sonelli) Date: Thu, 8 Aug 2013 08:28:10 -0700 Subject: [mosh-devel] [#413] Re: JuiceSSH STPClient Resuming Message-ID: <5203b90aae8c5_58a846e9342192467@ip-10-10-234-139.tmail> Hi Keith, Apologies for the delayed reply. I've had a busy couple of days moving house. We can certainly make sure that JuiceSSH will only ever use a saved state only once. I enquired about server-side checks as I thought this may be necessary if you were adding the save/resume functionality to the general public mosh client. The send to other device idea was just a spitball idea. It certainly wouldn't need to be included any time soon, and definitely not with the first iteration of resumable processes. Apologies for making you uneasy about that. Paul and I are in the habit of shouting our ideas out to each other as we have them. That way they're written down and can be revisited if we want to. So how would you like to proceed? Whilst we're not C++ developers, we are happy to contribute however you see fit. Thanks, Tom Tom Maddox Co-founder, Sonelli Ltd tom at sonelli.com?|?https://sonelli.com JuiceSSH - Free SSH client for Android On Tue, Aug 6 at 11:10 PM , Keith Winstein wrote: Hi Tom, (1) Running mosh-client as a subprocess at arms length sounds fine to me. Just wanted to make sure we don't have to worry about it, e.g. if you were linking or doing a closer binding than that. (2) Yes, you would be able to repeat the operation of saving and restoring a session as many times as you like -- each time you save, you would create a new saved state. Each such state could only be restored once. (3) My guess of the way we would enforce this "use once" property is as follows. To resume mosh-client from a saved state, JuiceSSH would give it a filename where a different mosh-client had previously written out its saved state. mosh-client will open() this filename, check that the open succeeded, unlink() the filename, check that the unlink() succeeded, and then read and use the saved state. We should check to make sure this really does eliminate a race condition where two mosh-clients get started at nearly the same time with the same stored state. (4) Re: your ideas, once you start talking about copying the saved state around to different machines I get nervous! :-) We really do not have the crypto support to do this robustly, i.e. to prevent the same nonce from getting sent twice with different data. We may have to think about protocol modifications that allow the key to rotate if you are serious about wanting this. Otherwise it makes me uncomfortable. Having the server detect this and deny one of the clients updates doesn't help -- once there are two different ciphertexts out there with the same key, same nonce, and different plaintext, it's basically game over. And the server may not be able to detect it if an adversary can prevent one set of datagrams from reaching the server. Cheers, Keith On Sun, Aug 4, 2013 at 6:10 AM, Tom Maddox wrote: Hi Keith, Brilliant, it looks like we're gonna be able to get this sussed out then. So, the licensing stuff. We're building mosh-client from source on a dedicated build server and then including that binary with our app to run as a subprocess. We've also included (as of this release) an About page in our Settings Menu which displays information and licenses of all open source projects used, including the GPL notice. Our application isn't open source as that would rather quickly make our in-app purchase worthless however, mosh and other open source dependent features are included within JuiceSSH's core functionality and will never require a purchase. Whilst we don't want or expect to ever make a huge sum of money through pro-pack purchases, we do have some hosting and test device costs we'd like to cover. If you feel that we're not meeting the requirements of mosh's license, we'll be happy to do our best to make changes to that end. I think I understand what you mean by only allowing a restore to happen once from a serialised state. But just to check, if a session had been restored in a new process successfully, would we then be able to repeat the save state and resume later procedure? The kill signal solution with the state printed stdout should definitely be workable. It'll take a bit of work to intercept the io streams before it reaches the terminal but it's certainly not impossible. A couple of ideas that come to mind with this functionality: JuiceSSH has a pro feature called CloudSync which keeps devices in sync with AES-256 encrypted backups. There's the potential to use this or NFC to add some "Resume on tablet" functionality. Is there anything server side that would prevent a state being reused more than once? For example, if a connection is made where the client's state is older than that of the last recorded client state, then the new client (in the older state) is denied updates. Thanks again, Tom Tom Maddox Co-founder, Sonelli Ltd tom at sonelli.com?|?https://sonelli.com JuiceSSH - Free SSH client for Android On 4 August 2013 04:57, Keith Winstein wrote: Hi Tom, Thanks for getting in touch. We can work with you to serialize the state of an STMClient object and restore it later. We are eager to see an Android Mosh client in the Play Store. The major major constraint here is that you can only restore from a serialized state *once*. We will want mosh-client to erase the serialized state before using it to make sure it can't be reused. The reason is that if you reuse a crypto sequence number (the nonce), that blows everything. How would you like to communicate with mosh-client that you want it to quit and dump state? You could just send us a SIGUSR1 or something and we could write it to stdout bracketed with something like BEGIN MOSH SAVED STATE if that works for you. And then if you give us a filename on startup (that we can erase), that would work fine to restore. I should ask -- are you running mosh-client as a separate binary or are you linking against it? (If linking against it, just to check, is your app under the GPL too?) Also, what sort of timeframe are you looking at for your release? Cheers, Keith On Sat, Aug 3, 2013 at 1:34 PM, Tom Maddox wrote: Hi, We're currently beta testing MOSH integration with our Android SSH client, JuiceSSH, of which the progress can be followed in our?G+ community. One issue that has been raised so far is battery usage. Currently when JuiceSSH has any active connections, there is a service running which holds a device wake lock and polls the connections for failures. Seeing as Mosh sessions should always be resumable, and as Keith pointed out, this shouldn't be necessary in the case of Mosh. Keith implied that he may be able to help us save the state of a mosh-client process, allowing for it to be resumed in the future. I've planned the majority of how to exclude Mosh sessions from wake locks and connection polling, and I'm confident that we'll be able to catch the point that the state should be saved and then finally I know how we could implement an "if-process-not-running-attempt-resume"-esque session. But the bit I'm not sure about is how to get the state, what form it will be in, and then how to reuse it. Having looked through the research paper and checking out the presentation, it would appear that this functionality is not yet in place. If so, and this functionality is new, then one solution I can think of would be the ability to run "mosh-client --resume-from-state [|]" to resume the process and perhaps a certain kill signal could result in mosh-client printing it's state just before it finishes. Any thoughts or help would be really appreciated. We're both very excited here about how convenient and nice this tool will be. As a couple of SysAdmins that wrote JuiceSSH mostly during our commutes on trains, we certainly appreciate the benefits! Thanks and regards, Tom Tom Maddox Co-founder, Sonelli Ltd tom at sonelli.com?|?https://sonelli.com JuiceSSH - Free SSH client for Android _______________________________________________ mosh-devel mailing list mosh-devel at mit.edu http://mailman.mit.edu/mailman/listinfo/mosh-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/mosh-devel/attachments/20130808/67a51359/attachment.html From jca at wxcvbn.org Thu Aug 8 20:25:24 2013 From: jca at wxcvbn.org (=?utf-8?Q?J=C3=A9r=C3=A9mie_Courr=C3=A8ges-Anglas?=) Date: Fri, 09 Aug 2013 02:25:24 +0200 Subject: [mosh-devel] JuiceSSH STPClient Resuming References: Message-ID: <87a9krzp57.fsf@shannon.wxcvbn.org> Hi, Alex Elsayed writes: > Keith Winstein wrote: > >> Hi Tom, >> (3) My guess of the way we would enforce this "use once" property is as >> follows. To resume mosh-client from a saved state, JuiceSSH would give it >> a filename where a different mosh-client had previously written out its >> saved state. mosh-client will open() this filename, check that the open >> succeeded, unlink() the filename, check that the unlink() succeeded, and >> then read and use the saved state. We should check to make sure this >> really does eliminate a race condition where two mosh-clients get started >> at nearly the same time with the same stored state. > > I'd recommend using O_EXCL on the open. Perhaps O_CREAT|O_EXCL would be good for state writing, but not so much for reusing. Perhaps were you thinking of O_EXLOCK|O_NONBLOCK? > Even without it you ought to be fine > - then both open()'s could run before the unlink(), but the unlink should > fail in that case. The second check would catch it, but better to prevent > the other instance from getting an FD at all. Indeed..., > That eliminates the potential for a mistake in checking the return code. Say you have three mosh-client processes: A and B are attempting to use a session file, C is trying to write a session file with the same name as A and B. A opens "F" and succeeds B opens "F" and succeeds A unlinks "F" and succeeds C dumps state to "F.new.XYZ" C renames "F.new.XYZ" to "F" and succeeds B unlinks "F" and succeeds A and B use the same state and C's saved state is lost. Something stronger should be possible. Let's say mosh would implement session storing in a generic way, easily usable form the CLI. Thinking out loud... Storage a la Maildir: --------------------- .mosh/ sessions/ tmp/ new/ cur/ State file creation: -------------------- If a new session is successfully dumped in a file in .tmp/ then the file is renamed into .new/ State file reuse: ----------------- If the chosen state file is successfully renamed from .new/ to .cur/ it is opened for reading and restoring session information. If restoring session information succeeds, the file in .cur/ is unlinked. I did not think about this thoroughly, but this seems simpler than the possible portability issues and corner cases of file locking. Interface: ---------- $ mosh --state-file state-foo would consider only the session stored in .mosh/sessions/new/state-foo If the session name contains a slash, then it is taken as a full path to a session file; in that case it is assumed that mosh-client should not unlink the session file, since this would be useful for debugging and regular session files are stored in a well-known place. A --state-dir option could override .mosh/sessions/ in aliases and shell wrappers. I don't think I'd use that feature, but I'd probably implement it like that. Cheers, -- jca | PGP: 0x06A11494 / 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494 From horos11 at gmail.com Sat Aug 10 22:29:42 2013 From: horos11 at gmail.com (Edward Peschko) Date: Sat, 10 Aug 2013 19:29:42 -0700 Subject: [mosh-devel] tunneling using mosh Message-ID: All, This may be a long-shot, but I'll ask anyways.. Is there a way to use mosh as a tunnel, like you can with ssh? I'd like to be able to use it like remote desktop or logmein, ie: with a third party server hosting a service so I could connect from two private servers to the central service and have a shell login on the remote device - even if that device is behind a firewall. I'd love to use ssh in this context, but it has all the drawbacks that ssh usually has - ie: prone to failing, disconnects, etc. And of course, logmein and remote desktop have the drawback that the computer, when being controlled, shares mouse and screen between both users - wheras I want to have separate control. Mosh would really help me out in this instance, but I'm not sure if the protocol would support this mode. Thanks much for any help, Ed -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/mosh-devel/attachments/20130810/aba8c449/attachment.html From keithw at MIT.EDU Sat Aug 10 22:58:35 2013 From: keithw at MIT.EDU (Keith Winstein) Date: Sun, 11 Aug 2013 10:58:35 +0800 Subject: [mosh-devel] tunneling using mosh In-Reply-To: References: Message-ID: Hello Edward, I'm not quite sure I follow. Do you want an arbitrary tunnel of a byte-stream, or do you just want to be able to get a persistent, roamable shell login to a machine that's behind a firewall? Mosh doesn't support arbitrary tunnels (yet!), but if you just need a shell login from a central server to another machine behind a firewall, that can be arranged. (We might want to flip which side is the client and which is the server.) Cheers, Keith On Sun, Aug 11, 2013 at 10:29 AM, Edward Peschko wrote: > All, > > This may be a long-shot, but I'll ask anyways.. > > Is there a way to use mosh as a tunnel, like you can with ssh? I'd like to > be able to use it like remote desktop or logmein, ie: with a third party > server hosting a service so I could connect from two private servers to the > central service and have a shell login on the remote device - even if that > device is behind a firewall. > > I'd love to use ssh in this context, but it has all the drawbacks that ssh > usually has - ie: prone to failing, disconnects, etc. And of course, > logmein and remote desktop have the drawback that the computer, when being > controlled, shares mouse and screen between both users - wheras I want to > have separate control. > > Mosh would really help me out in this instance, but I'm not sure if the > protocol would support this mode. > > Thanks much for any help, > > Ed > > _______________________________________________ > mosh-devel mailing list > mosh-devel at mit.edu > http://mailman.mit.edu/mailman/listinfo/mosh-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/mosh-devel/attachments/20130810/7fcc83d0/attachment.html From keithw at MIT.EDU Sat Aug 10 23:13:25 2013 From: keithw at MIT.EDU (Keith Winstein) Date: Sun, 11 Aug 2013 11:13:25 +0800 Subject: [mosh-devel] tunneling using mosh In-Reply-To: References: Message-ID: Hello Edward, The simplest solution I can think of is to connect all three machines using OpenVPN and then just Mosh among them as you please. Good luck and please let me know if we can help further. Cheers, Keith On Sun, Aug 11, 2013 at 11:10 AM, Edward Peschko wrote: > Keith, > > Yes, that's basically it - from a central server, be able to log in to > another machine behind a firewall. If necessary, I could mosh to that > central server and then mosh to the machine behind the firewall in question. > > if you have any pointers to examples on how to do this, it'd be > appreciated. > > Ed > > > On Sat, Aug 10, 2013 at 7:58 PM, Keith Winstein wrote: > >> Hello Edward, >> >> I'm not quite sure I follow. Do you want an arbitrary tunnel of a >> byte-stream, or do you just want to be able to get a persistent, roamable >> shell login to a machine that's behind a firewall? >> >> Mosh doesn't support arbitrary tunnels (yet!), but if you just need a >> shell login from a central server to another machine behind a firewall, >> that can be arranged. (We might want to flip which side is the client and >> which is the server.) >> >> Cheers, >> Keith >> >> On Sun, Aug 11, 2013 at 10:29 AM, Edward Peschko wrote: >> >>> All, >>> >>> This may be a long-shot, but I'll ask anyways.. >>> >>> Is there a way to use mosh as a tunnel, like you can with ssh? I'd like >>> to be able to use it like remote desktop or logmein, ie: with a third party >>> server hosting a service so I could connect from two private servers to the >>> central service and have a shell login on the remote device - even if that >>> device is behind a firewall. >>> >>> I'd love to use ssh in this context, but it has all the drawbacks that >>> ssh usually has - ie: prone to failing, disconnects, etc. And of course, >>> logmein and remote desktop have the drawback that the computer, when being >>> controlled, shares mouse and screen between both users - wheras I want to >>> have separate control. >>> >>> Mosh would really help me out in this instance, but I'm not sure if the >>> protocol would support this mode. >>> >>> Thanks much for any help, >>> >>> Ed >>> >>> _______________________________________________ >>> mosh-devel mailing list >>> mosh-devel at mit.edu >>> http://mailman.mit.edu/mailman/listinfo/mosh-devel >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/mosh-devel/attachments/20130810/0eb485a7/attachment.html From istoselida at gmail.com Mon Aug 12 17:33:19 2013 From: istoselida at gmail.com (istoselida@gmail.com) Date: Mon, 12 Aug 2013 17:33:19 -0400 Subject: [mosh-devel] International Digital Photo Competition 2013 Message-ID: Dear all, with this email we would like to inform you that our photo competition salon is still open and awaiting your photographic entries at: http://326599.biz//lt.php?id=bUoEU1IDXg4ZVVdMAApWWAY%3D Section Info Only digital photos 4 per section Open (Color) Open (Monochrome) Photo Travel Calendar Closing Date:31.08.13 Judging: 14.09.13 Results out: 24.09.13 Projection / Public Showing: 05.10.13 & 12.10.13 Awards dispatch: 31.10.13 Entry & Specs Only online Submission Works must be in .jpg format Minimum file size: 2mb Best quality (compr/n 12) Winning photos will be printed Entry Fee Mandatory for all For all three sections ?20 Through : Visa or Paypal No refunds will be made Awards (Medals) FIAP (3 Gold, 3 Silver, 3 Bronze) & 1 blue badge PSA (3 Gold, 3 Silver, 3 Bronze) 3 ISF Medals 3 UPI Medals Jury Sammy Somekh (Israel) Andreas L Andreou (Cyprus) Erato Kantouna (Cyprus) ?assim Eloud (Cyprus) Michalis Georgiades (Cyprus) Contacts Support: istoselida at gmail.com General: info at cps-iodpc.com.cy 00357 7000 8001 Nicosia, Cyprus Best Regards, P. Panteli Cps-iodpc.com.cy administrator -- If you do not want to receive any more newsletters, send us an email here: istoselida at gmail specifying you want to unsubscribe Forward a Message to Someone http://326599.biz//lt.php?id=bUoEU1IDXwcZVVdMAApWWAY%3D -- powered by phpList, www.phplist.com -- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/mosh-devel/attachments/20130812/acb653fa/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: powerphplist.png Type: image/png Size: 2408 bytes Desc: not available Url : http://mailman.mit.edu/pipermail/mosh-devel/attachments/20130812/acb653fa/attachment.png From eletters37 at nionesecurity.com Wed Aug 14 23:45:38 2013 From: eletters37 at nionesecurity.com (Henry ) Date: Thu, 15 Aug 2013 11:45:38 +0800 Subject: [mosh-devel] Wholesale DAHUA/DALI/YAAN/RELONG CCTV Security Devices Message-ID: <0M7oxE-1W53mw0rWy-00vPCr@mrelay.perfora.net> Dear Sir/Madam Nione Security, the world wide wholesale trader. We are wholesale DAHUA,DALI,YAAN, RELONG and other CCTV Security devices. We provide products with better price, and fast delivery. ?Technology Leader in IP Surveillance Nione Security Technology Co. Ltd is one of the world's leading suppliers & trader of video security surveillance devices and solutions, focusing on multiple security surveillance market segments. Established in 2006, Nione Security has grown from a small company into a global enterprise. Nione Security offers extensive products including hybrid DVRs, NVRs, standalone DVRs, digital video servers, compression cards, high-definition IP cameras, and speed domes, which all of them meet the ONVIF & PSIA standards. These products are empowering more than 100 countries and secure various security applications around the world to enjoy best quality video performances. ?Solution Development and Integration The core value of Nione Security is the ability to search, develop, integrate and market complete end-to-end solutions for our clients in the IP surveillance market. Nione Security's technology advancements enable complete solution offerings to cover all segments of the security market. Not only offering the IP surveillance hardware such as IP cameras and video servers, all Nione Security products are bundled with free management iVMS software; in addition to the rich selection of management applications offered by leading Independent Software Vendors that support Nione Security hardware. ?Popular Compatibility of Security System Nione Security is a zealous supports of current most compatibility standards. The IP network surveillance devices all Nione Security is selling, have great support and compatibility with ONVIF & PSIA. We believe this will make the end user have convenient upgrade opportunity when them have the requirements. ?Flexible Business Model to Drive Industry Revolution Headquartered in Hangzhou, China, Nione Security has expanded into a global operation, partners with distributors, application developers worldwide in Los Angeles covering the Americas; Amsterdam covering Europe; and Dubai for the Middle East. There are joint ventures in India and Russia, as well as a maintenance center in Hong Kong. With flexible customization offerings to accommodate different business models. Nione Security's commitment to sales, marketing and technical support will empower his innovative IP surveillance technology to be thoroughly optimized and appreciated by Nione Security's strategic customers. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/mosh-devel/attachments/20130815/4ad6e704/attachment.html From slimkind7 at gmail.com Sun Aug 18 17:24:16 2013 From: slimkind7 at gmail.com (HannesJvV (alt email)) Date: Sun, 18 Aug 2013 23:24:16 +0200 Subject: [mosh-devel] Mosh for roguelike games? Message-ID: I understand Mosh uses a simplified model of server-side activity to give "intelligent local echo", but I'm not clear on the details. Can Mosh use application-specific local echo models? I'm asking because I would love to play Dungeon Crawl online but I live in Africa, far away from any server. Lag makes playing over SSH absolutely unbearable. I'm thinking that Mosh with crawl-specific local echo model could at least make the lag a lot more bearable and would be a big step forward for roguelikes in general. I understand that with roguelikes there would be many cases where Mosh wouldn't really help (just as with complex commands in Vim) and that this would be complicated to pull off. But simple things can go a long way: if I've been waiting for a response from the server for the past few seconds after giving a movement command, I might as well check out my spell list or inventory or examine a monster while I'm waiting for it. This is impossible with SSH, but I think it might well be doable with Mosh if it can take 'local echo plugins'. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/mosh-devel/attachments/20130818/ebd0e213/attachment.html From keithw at MIT.EDU Tue Aug 20 02:43:05 2013 From: keithw at MIT.EDU (Keith Winstein) Date: Tue, 20 Aug 2013 02:43:05 -0400 Subject: [mosh-devel] Mosh for roguelike games? In-Reply-To: References: Message-ID: Hello Hannes, There's no fundamental reason that Mosh couldn't support an application-specific local echo model. Look in src/frontend/terminaloverlay.cc ( https://github.com/keithw/mosh/blob/master/src/frontend/terminaloverlay.cc) for the current code. You *might* be better off just writing your thing as a separate wrapper program that the user would run before they run Mosh or SSH. (Look at our src/examples/termemu.cc for an example of this.) This could just interpret the user's keystrokes and do whatever you want with them, rather than trying to be another part of Mosh itself. Mosh itself benefits from having the prediction be tied in with the networking, because we want to know which user keystrokes have been seen by the server (in order to know whether our predictions were confirmed or rejected). But if you're really just making a local user interface for a particular application, there's a lot less ambiguity about trying to infer if your "predictions" are correct and you could do this as a straight-up wrapper program on the client side. Good luck! Cheers, Keith On Sun, Aug 18, 2013 at 5:24 PM, HannesJvV (alt email) wrote: > I understand Mosh uses a simplified model of server-side activity to give > "intelligent local echo", but I'm not clear on the details. Can Mosh use > application-specific local echo models? > > I'm asking because I would love to play Dungeon Crawl online but I live in > Africa, far away from any server. Lag makes playing over SSH absolutely > unbearable. I'm thinking that Mosh with crawl-specific local echo model > could at least make the lag a lot more bearable and would be a big step > forward for roguelikes in general. > > I understand that with roguelikes there would be many cases where Mosh > wouldn't really help (just as with complex commands in Vim) and that this > would be complicated to pull off. But simple things can go a long way: if > I've been waiting for a response from the server for the past few seconds > after giving a movement command, I might as well check out my spell list or > inventory or examine a monster while I'm waiting for it. This is impossible > with SSH, but I think it might well be doable with Mosh if it can take > 'local echo plugins'. > > _______________________________________________ > mosh-devel mailing list > mosh-devel at mit.edu > http://mailman.mit.edu/mailman/listinfo/mosh-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/mosh-devel/attachments/20130820/a445c347/attachment.html From slimkind7 at gmail.com Sat Aug 24 08:46:23 2013 From: slimkind7 at gmail.com (HannesJvV (alt email)) Date: Sat, 24 Aug 2013 14:46:23 +0200 Subject: [mosh-devel] Mosh for roguelike games? In-Reply-To: References: Message-ID: Thanks for your replies, guys. I reckon specific client and server programs would indeed be best for implementing 'anti-lag', but a seperate client/server/protocol has never been developed for any roguelike (AFAIK) because running over telnet or SSH is such a simple, well-working solution... as long as your latency is small. The way I see it, a specific client application for Crawl wouldn't hold up in the long run because the trouble to implement and keeping it up to date would outweigh the benefits for most users. That's why I wondered whether it might be possible to add some tweaks to Mosh to that end, but I realise that that could also become needlessly complex as Mosh would need to understand the way the game works. Still, simple things like echoing movement input on a specific line below the map display (instead of wherever the cursor happens to be) or constraining input during a Y/N choice during a lag spike might be useful, so I think I might look into it some time. If I actually manage to do something useful, I'll put it on Github or something and let you know ;) On Tue, Aug 20, 2013 at 8:43 AM, Keith Winstein wrote: > Hello Hannes, > > There's no fundamental reason that Mosh couldn't support an > application-specific local echo model. Look > in src/frontend/terminaloverlay.cc ( > https://github.com/keithw/mosh/blob/master/src/frontend/terminaloverlay.cc) > for the current code. > > You *might* be better off just writing your thing as a separate wrapper > program that the user would run before they run Mosh or SSH. (Look at > our src/examples/termemu.cc for an example of this.) This could just > interpret the user's keystrokes and do whatever you want with them, rather > than trying to be another part of Mosh itself. > > Mosh itself benefits from having the prediction be tied in with the > networking, because we want to know which user keystrokes have been seen by > the server (in order to know whether our predictions were confirmed or > rejected). But if you're really just making a local user interface for a > particular application, there's a lot less ambiguity about trying to infer > if your "predictions" are correct and you could do this as a straight-up > wrapper program on the client side. > > Good luck! > > Cheers, > Keith > > > On Sun, Aug 18, 2013 at 5:24 PM, HannesJvV (alt email) < > slimkind7 at gmail.com> wrote: > >> I understand Mosh uses a simplified model of server-side activity to give >> "intelligent local echo", but I'm not clear on the details. Can Mosh use >> application-specific local echo models? >> >> I'm asking because I would love to play Dungeon Crawl online but I live >> in Africa, far away from any server. Lag makes playing over SSH absolutely >> unbearable. I'm thinking that Mosh with crawl-specific local echo model >> could at least make the lag a lot more bearable and would be a big step >> forward for roguelikes in general. >> >> I understand that with roguelikes there would be many cases where Mosh >> wouldn't really help (just as with complex commands in Vim) and that this >> would be complicated to pull off. But simple things can go a long way: if >> I've been waiting for a response from the server for the past few seconds >> after giving a movement command, I might as well check out my spell list or >> inventory or examine a monster while I'm waiting for it. This is impossible >> with SSH, but I think it might well be doable with Mosh if it can take >> 'local echo plugins'. >> >> _______________________________________________ >> mosh-devel mailing list >> mosh-devel at mit.edu >> http://mailman.mit.edu/mailman/listinfo/mosh-devel >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/mosh-devel/attachments/20130824/1899c530/attachment.html From infoservicebr at infoservicebr.com.br Mon Aug 26 12:37:24 2013 From: infoservicebr at infoservicebr.com.br (=?ISO-8859-1?Q?NFS=20Professional=20Services?=) Date: Mon, 26 Aug 2013 13:37:24 -0300 (BRT) Subject: [mosh-devel] =?utf-8?q?NFS_Professional_Services_-_Repair_Center?= Message-ID: <20130826163724.1AF9764AD66DF@env01.mf0s.com.br> Centro de Reparos NFS - Reparamos todas as marcas e modelos de equipamentos com tecnologias Wireless, VoIP, Network, Telecom, Cameras e Dispositivos de Seguranca. Atendemos a fabricantes, revendas, distribuidores, usuarios corporativos e usuarios finais. Equipamentos VoIP, ATAs, Gateways VoIP, Gateways GSM, Routers E1, Telefones IP, Video-fones IP, IP-PBX. Equipamentos de Rede, Routerboard, Ubiquiti, AP, Backhaul, Equipamentos para Enlaces Ponto a Ponto e Multi-Ponto, Switches, Roteadores, Firewalls, Modem, Cable-Modem, Setup box, Audio e Video Conferencia. Equipamentos de Seguranca, Cameras IP, Cameras IP PTZ, Cameras Panoramicas, DVR, Video Encoders, IPTV, Placas de Captura CFTV e CFTV-IP, entre outros. Saiba que A NFS repara todas as marcas e modelos de equipamentos de conectividade Wireless, VoIP, Network, Telecom e Cameras de fabricacao, nacional e importados. Geralmente o valor do reparo de um equipamento fica entre 25 e 40 porcento do valor de um novo comercializado em mercado nacional e tem garantia absoluta de servico pelo periodo de 3 meses. Com a ampliacao de nossa estrutura e quantidade de colaboradores, garantimos um atendimento personalizado atraves de nossa equipe de atendentes comerciais. A NFS esta preparada para atender desde usuarios ate fabricantes, com total profissionalismo e garantia de satisfacao. Entre em contato conosco e conheca melhor as solucoes que a NFS lhe oferece. A NFS Cresceu e quer que voce e sua empresa participe de nossas conquistas. A NFS Professional Services e uma empresa solidamente estruturada na area de servicos de Reparo, Re-Manufatura, Suporte Tecnico Especializado e Autorizado da marca AudioCodes e Treinamentos com Certificacoes na area de TI. Sua ampla gama de atendimento percorre toda a cadeia na area de TI, desde Operadoras de Telecom (sejam elas moveis, fixas ou de TVs por assinatura), Provedores ISP e WISP, Distribuidores, Revendas, Integradores, Lojistas, Fabricantes ate usuarios Finais, assim como as demandas do mercado corporativo e governos. Os diferenciais da NFS Professional Services provem de sua capacidade tecnica produtiva, da utilizacao inovadora de tecnologia e engenharia na analise e correcao de falhas, de suas aliancas tecnologicas e da reconhecida qualificacao por sua excelencia de servicos, fazendo da execucao com excelencia profissional uma de suas principais caracteristicas. Central de Atendimento Endereco: Rua Serra de Botucatu, 627 - Tatuape - Sao Paulo - SP CEP: 03317-000 Telefones Central de Atendimento: 55 (11) 2093-9155 55 (11) 2385-3977 email: atendimento at nfs.net.br -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/mosh-devel/attachments/20130826/404dba26/attachment.html From sales02 at bag-manufactory.com Thu Aug 29 04:10:07 2013 From: sales02 at bag-manufactory.com (=?utf-8?B?SmFjaw==?=) Date: Thu, 29 Aug 2013 16:10:07 +0800 Subject: [mosh-devel] =?utf-8?q?Are_you_satisfy_with_your_present_supplier?= =?utf-8?q?_=3F?= Message-ID: <521F02DC.061F84.21452@m97134.qiye.163.com> Hi there? Guangzhou ShangLing Non woven Industrial CO.?Ltd here? specializing in all kinds of non woven bag category: -Shopping Bag -Drawstring Bag -Cooler Bag -Garment Suit -Cotton Bag Contact us and let?s talk detail. Best Regards Jack Sales Department Guangzhou Shangling Non-Woven Products Co., Ltd. Tel?0086-020-23326835?Fax?0086-020-23326835 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/mosh-devel/attachments/20130829/951a2b4b/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpg Size: 6671 bytes Desc: not available Url : http://mailman.mit.edu/pipermail/mosh-devel/attachments/20130829/951a2b4b/attachment.jpg From istoselida at gmail.com Thu Aug 29 05:55:52 2013 From: istoselida at gmail.com (istoselida@gmail.com) Date: Thu, 29 Aug 2013 05:55:52 -0400 Subject: [mosh-devel] Joomla! Services from Antici! Online Ltd Message-ID: <5668bea604e66dde835dd6ab3f78d524@www.326599.biz> **Antici! Online Ltd - http://326599.biz//lt.php?id=bUoLVVACVgQZVVJMAApWWAY%3D ** -- If you do not want to receive any more newsletters, send us an email here: unsubscribe at 326599.biz specifying you want to unsubscribe Forward a Message to Someone http://326599.biz//lt.php?id=bUoLVVACVgMZVVJMAApWWAY%3D -- powered by phpList, www.phplist.com -- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/mosh-devel/attachments/20130829/c70b01e6/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: powerphplist.png Type: image/png Size: 2408 bytes Desc: not available Url : http://mailman.mit.edu/pipermail/mosh-devel/attachments/20130829/c70b01e6/attachment.png From vijay.maranganti at xius.com Thu Aug 29 10:34:42 2013 From: vijay.maranganti at xius.com (=?utf-8?Q?XIUS?=) Date: Thu, 29 Aug 2013 14:34:42 +0000 Subject: [mosh-devel] =?utf-8?q?Enabling_MVNOs_to_rapidly_launch_quality_s?= =?utf-8?q?ervices?= Message-ID: <08f789fcbd4ec75977d1a1847e4815d35b2.20130829143437@mail129.wdc02.mcdlv.net> ? ? What You Need: ? ? ? ? XIUS Mobile Services Platform (MSP) offers: * Exclusive and flexible end-to-end next-gen infrastructure * Ability to launch and modify service offerings quickly * Custom configuration and enhancements for unique services launch * A solution that includes operational guidance and support throughout ? * Mission-critical and highly available components that can be used to create end-to-end next-gen core network infrastructure * A compelling value proposition to generate revenue through a spectrum of advanced mobile services network * Individual components that can be integrated, as needed, into existing infrastructure as well as with multiple third-party applications * Flexibility to ensure rapid and cost-effective deployment ? XIUS Mobile Services Platform is a flexible and modular infrastructure solution that meets your business needs. With decades of experience in launching new services across multiple continents, XIUS has the maturity to guide you through planning, launching and ongoing operations. Our approach assures initial speed to the market as well as the ability to gain first-mover advantage through ongoing service innovation. To enable you in putting your plans into action or if you would like more information on our solution offering, please email us at contactus at xius.com (mailto:contactus at xius.com) Please forward this email to the concerned individual / department if you are not the intended recipient. ? www.xius.com (http://www.xius.com/) This email was sent to mosh-devel at mit.edu why did I get this? (http://xius.us4.list-manage.com/about?u=08f789fcbd4ec75977d1a1847&id=a50b2ed44b&e=e4815d35b2&c=28b57aa8c3) ? ? ? ? unsubscribe from this list (http://xius.us4.list-manage.com/unsubscribe?u=08f789fcbd4ec75977d1a1847&id=a50b2ed44b&e=e4815d35b2&c=28b57aa8c3) ? ? ? ? update subscription preferences (http://xius.us4.list-manage.com/profile?u=08f789fcbd4ec75977d1a1847&id=a50b2ed44b&e=e4815d35b2) XIUS ? 500 West Cummings Park, ? Suite 2100, ? Woburn, MA 01801 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/mosh-devel/attachments/20130829/b446c223/attachment.html