I was planning on using JavaScript + canvas with the Gate One server acting as a pseudo X11 server. You'd forward your DISPLAY just like normal but Gate One would intercept the protocol and translate it into something more efficient before sending to the client. SVG doesn't perform as well as canvas.
Of course, I'd do my best to make sure it is fast and completely transparent to the user.
First things first though... An authorization framework, shared bookmarks, terminal session sharing, and a special secret surprise that will hopefully be cool enough to make the news again.
The package comes with an interactive tutorial on how to embed Gate One into other applications. It's in the tests directory, "hello_embedded".
Also, to answer your question directly, there's an argument you can pass to GateOne.init(), autoConnectURL that does exactly what you want (specify a complete ssh:// url). There's lots of info on it in the developer docs in the JavaScript section (hint: there's a search function:).
That's because the demo is inside of a chroot jail and the user it runs as only has read-only access to its home directory. Also, the version of vim running is actually rvim which doesn't let you execute shell commands (for good reason).
If you figure out a way to break out of the jail let me know so I can close that hole!;)
Just an FYI: You can't inspect SSL packets without a MitM attack. Some proxies support this (Blue Coat) but none of them work with WebSockets. So as it stands right now it is impossible to sniff your Gate One session unless you're using a very weak SSL certificate.
Whoever is looking at your Gate One traffic in a sniffer will only see a destination and a source IP. They won't even see the URLs you're hitting.
Yes, the terminal emulator in Gate One is server-side (terminal.py). It converts the terminal's screen to HTML before sending it to the client. Actually, it only sends lines to the client that have been updated but that part is handled separate from the terminal emulator.
Oh the pain of software keyboards! Believe me, it drives me crazy. Gate One will work in Mobile Firefox and Chrome for Android using a software keyboard but not very well. You're much better off using a hardware keyboard.
Having said that, here's how it currently works in Gate One with software keyboards: There's an invisible input element on the page that gets focus when you load the page or tap somewhere. When that happens the software keyboard comes up and you can enter your keystrokes. However, whenever you tap "go" the input element loses focus! This will drive you crazy. I have opened bugs for both Chrome and Firefox to get a workaround of some sort.
I am planning on writing a thin "native" client of sorts to use Gate One on mobile devices (probably using PhoneGap) just for the sole purpose of getting control over the software keyboard (make it stay open!).
Why would Gate One be Windows-only? It runs in a browser.
Don't think, "PuTTY replacement" or, "terminal replacement." Think, "I can use this from anywhere without having to install anything" or, "this could be embedded into an administration interface to provide a command line where previously there was none."
Though to be honest my end-goal with Gate One is to make it the best terminal emulator (and SSH client) ever. We've only begun to explore what's possible when you combine a terminal with capabilities of the browser (HTML5, specifically).
I am no fan of Apple but I have to point out that your problem has nothing to do with the fact that your ipad2 has a proprietary connector. Your USB charger just isn't supplying the 2.1 amps required to charge an iPad.
USB chargers may all have the same port but they are anything but equal. Look at the back of your charger... it probably says 5v @500mA. Almost all of the generic ones do. Especially if it is more than one year old.
The problem all of these HTTP 2.0 proposals are trying to work around is the fact that each resource fetched by the web browser is handled via a separate connection. By combining these elements into a single (compressed) stream you can save a TON of overhead. This is why sites that use nothing but data::URI images load so much faster--even--than sites using the fastest CDNs. These 'solutions' are just workarounds to the crap that is HTTP 1.1.
Of course, the problem with data::URIs is that they can't be cached if the page's content is dynamic. However, the fact that you don't have to open a hundred additional HTTP connections just to load the cached content (have to check if something changed!) more than makes up for the lack of caching.
The real solution here is to just ditch HTTP and replace it with something like SCTP which can keep the connection open to the server and maintain the session in a secure fashion (negating the need for session-tracking cookies, hurray!). Having said that, such a change to the web would completely break the popular, N-servers-behind-a-load-balancer architecture. It would also negate the need for CDNs (for the most part)... Which is probably why many of the big-name vendors are proposing solutions that maintain the status quo.
Your "friend" needs to get over it and stand up for herself. Seriously, I work from home 100% and this kind of crap happens all the time. Even to folks who work in the office. The only difference is that the folks in the office CANNOT get the work done while the person at home can.
This is the perfect example of, "just because you CAN doesn't mean you SHOULD." Just tell your boss or whoever that you were given two days to get a job done that takes five. Or do what I do: Convince them that the task doesn't need to happen in the first place. Works amazingly well!
Half the time the task they wanted me to do will change anyway. So if I started it right away I would have wasted my time. It is a perverse situation that rewards procrastination. Use it to your advantage and do things that ACTUALLY need to get done!
1, Because it'll break code when copypasting from a website.
This is pretty rare these days since everyone uses code pasting sites like codepad.org and github's gist but it is a valid point.
2, Because you can't use matching braces feature of your IDE if you don't have braces, and it's harder to see when blocks start or end when you have a method that's longer than your screen height.
What the heck?!? You've obviously never coded Python in an IDE that supports Python. Python has braces, parens, and brackets for a lot of things (dicts, tuples, and lists, respectively) and the matching braces feature works fine. Why would it be different? Not only that but most editors that support Python also offer code collapsing and indentation works better for this purpose since you don't need matching brackets features to find the end of a function or object.
3, Because your IDE could autoindent your code if you used braces.
Citation needed. Every IDE I've ever used to code Python auto-indents my code blocks just fine. Real simple rules too: If there's a colon that's not already inside braces, indent the next line. Compare this to other languages where a brace could indicate any number of things. Figuring out when to indent is a lot more complicated.
The most "Pythonic" way to handle your scenario is both efficient and chimes well with your readability standards: # Assuming you've got a threading.Lock or multiprocessing.Lock object called 'my_lock'... with my_lock:
code()
moreCode()
yetMoreCode() #...and that's it!
Note that there's no need to call something like releaseLock() since Lock() objects support the 'with statement' (aka context manager). The indentation rules mean that the lock is released at the end of the 'with' block. Another advantage of this solution ('with statements') is that if one of those functions causes an exception the lock will be released in an orderly fashion. This is very effective at:
1) Preventing deadlock situations. 2) Making code concise and easy-to-read.
Also, thanks to Python's dynamic nature you can extend your lock objects to make them perform additional actions in the event of an exception (among other things).
IE 9 doesn't support WebSockets but IE 10 will. Having said that, I do have plans to include friendlier error messages for browsers that lack support for certain things. Under normal circumstances I would have supported IE but Flash-based WebSockets and other workarounds were just too slow or too bandwidth-heavy in my testing to be worthwhile. They might be OK for a single terminal but for multiple terminals they're terrible. Having said that I *do* re-test such things from time to time to see if things have improved (i.e. Flash could get faster) so it might change in the future.
For reference, supporting IE adds twice the development time to any web project! It can also double the size of the code base and drastically increases the likelihood of bugs. It's THAT bad. Hopefully IE 10 will be better but I said that about IE 9 before it came out (sigh).
Also, if you don't need to support IE your JS code suddenly becomes easy to read and starts to make sense!
In regards to your comment I'd like to make the following statements:
1) This is why I setup the demo to run lynx instead of a the regular SSH client... So usernames and passwords wouldn't be a concern (and to avoid liability). Unless you had plans to surf the web all day in text mode at liftoffsoftware.com (logging into things) I can't fathom how this could be a real issue. 2) I would never record anyone's usernames/passwords. Of course, you'd just have to trust me and I definitely understand if you don't. I myself try not to trust 3rd party websites with much. For reference, I'm not even logging what sites users are visiting in lynx. It isn't the point so why would I? 3) By default Gate One doesn't log incoming keystrokes. In order for that to happen you have to set logging to debug (--logging=debug). If logging is set to debug Gate One will display a HUGE warning message to users whenever a terminal is opened, "WARNING: Logging is set to DEBUG. All keystrokes will be logged." Of course, being the developer I could just turn that off but at least I had the foresight to include a user-friendly message. 4) It is trivial to replace sshd with a malicious copy that records user's keystrokes. Gate One is no more or less secure than OpenSSH from that standpoint. Users wouldn't even see a message that the host key had changed.
I'm not sure what the age cutoff is but pre-toddlers haven't developed their immune systems to the point where they would reject organs. There are limitations of course but having an ignorant immune system has its advantages.
Slashdot Mirror
At that point I think most people would just quit their jobs.
When the world marches ahead while you stay behind you build technical debt. The further you fall behind the more effort it will take to catch up.
To put it another way, businesses (and individuals!) that can't stay current will become history. It's just a matter of time.
I was planning on using JavaScript + canvas with the Gate One server acting as a pseudo X11 server. You'd forward your DISPLAY just like normal but Gate One would intercept the protocol and translate it into something more efficient before sending to the client. SVG doesn't perform as well as canvas.
Of course, I'd do my best to make sure it is fast and completely transparent to the user.
First things first though... An authorization framework, shared bookmarks, terminal session sharing, and a special secret surprise that will hopefully be cool enough to make the news again.
The package comes with an interactive tutorial on how to embed Gate One into other applications. It's in the tests directory, "hello_embedded".
Also, to answer your question directly, there's an argument you can pass to GateOne.init(), autoConnectURL that does exactly what you want (specify a complete ssh:// url). There's lots of info on it in the developer docs in the JavaScript section (hint: there's a search function :).
UPDATE: Hangman is now working. Huzzah!
If you like the ADTD part you should run the demo and hit 'q' for a special surprise =D
So run Gate One locally: https://localhost/
I use it like that every day!
Hmmm... Not sure why Hangman isn't working. I'll fix it (not a priority). I suspect that I forgot to copy its word dictionary into the chroot jail.
That's because the demo is inside of a chroot jail and the user it runs as only has read-only access to its home directory. Also, the version of vim running is actually rvim which doesn't let you execute shell commands (for good reason).
If you figure out a way to break out of the jail let me know so I can close that hole! ;)
Just an FYI: You can't inspect SSL packets without a MitM attack. Some proxies support this (Blue Coat) but none of them work with WebSockets. So as it stands right now it is impossible to sniff your Gate One session unless you're using a very weak SSL certificate.
Whoever is looking at your Gate One traffic in a sniffer will only see a destination and a source IP. They won't even see the URLs you're hitting.
Yes, the terminal emulator in Gate One is server-side (terminal.py). It converts the terminal's screen to HTML before sending it to the client. Actually, it only sends lines to the client that have been updated but that part is handled separate from the terminal emulator.
There's actually a pretty good overview of the differences between server and client-side terminal emulation here: http://en.wikipedia.org/wiki/Web-based_SSH
Oh the pain of software keyboards! Believe me, it drives me crazy. Gate One will work in Mobile Firefox and Chrome for Android using a software keyboard but not very well. You're much better off using a hardware keyboard.
Having said that, here's how it currently works in Gate One with software keyboards: There's an invisible input element on the page that gets focus when you load the page or tap somewhere. When that happens the software keyboard comes up and you can enter your keystrokes. However, whenever you tap "go" the input element loses focus! This will drive you crazy. I have opened bugs for both Chrome and Firefox to get a workaround of some sort.
I am planning on writing a thin "native" client of sorts to use Gate One on mobile devices (probably using PhoneGap) just for the sole purpose of getting control over the software keyboard (make it stay open!).
Why would Gate One be Windows-only? It runs in a browser.
Don't think, "PuTTY replacement" or, "terminal replacement." Think, "I can use this from anywhere without having to install anything" or, "this could be embedded into an administration interface to provide a command line where previously there was none."
Though to be honest my end-goal with Gate One is to make it the best terminal emulator (and SSH client) ever. We've only begun to explore what's possible when you combine a terminal with capabilities of the browser (HTML5, specifically).
Now lets see an X11 implementation :-)
It's in the roadmap. It's just a matter of priorities and time.
Well, I'm monitoring it in real-time. If the demo servers start getting overloaded I'll add more.
In fact, I just added two extra servers: http://gateone3.rs.liftoffsoftware.com/ and http://gateone4.rs.liftoffsoftware.com/ just to be safe.
The two, 1GB Rackspace instances that were up when this news hit the front page are still running fine at this moment.
Adding the ability to support new file formats wouldn't gain them anything? How about the ability to support new file formats?
Tip: WebSockets don't have any cross-origin limitations. You can connect to anything from anywhere.
So there you go. Now you can make that key authority server :D
I am no fan of Apple but I have to point out that your problem has nothing to do with the fact that your ipad2 has a proprietary connector. Your USB charger just isn't supplying the 2.1 amps required to charge an iPad.
USB chargers may all have the same port but they are anything but equal. Look at the back of your charger... it probably says 5v @500mA. Almost all of the generic ones do. Especially if it is more than one year old.
The problem all of these HTTP 2.0 proposals are trying to work around is the fact that each resource fetched by the web browser is handled via a separate connection. By combining these elements into a single (compressed) stream you can save a TON of overhead. This is why sites that use nothing but data::URI images load so much faster--even--than sites using the fastest CDNs. These 'solutions' are just workarounds to the crap that is HTTP 1.1.
Of course, the problem with data::URIs is that they can't be cached if the page's content is dynamic. However, the fact that you don't have to open a hundred additional HTTP connections just to load the cached content (have to check if something changed!) more than makes up for the lack of caching.
The real solution here is to just ditch HTTP and replace it with something like SCTP which can keep the connection open to the server and maintain the session in a secure fashion (negating the need for session-tracking cookies, hurray!). Having said that, such a change to the web would completely break the popular, N-servers-behind-a-load-balancer architecture. It would also negate the need for CDNs (for the most part)... Which is probably why many of the big-name vendors are proposing solutions that maintain the status quo.
Your "friend" needs to get over it and stand up for herself. Seriously, I work from home 100% and this kind of crap happens all the time. Even to folks who work in the office. The only difference is that the folks in the office CANNOT get the work done while the person at home can.
This is the perfect example of, "just because you CAN doesn't mean you SHOULD." Just tell your boss or whoever that you were given two days to get a job done that takes five. Or do what I do: Convince them that the task doesn't need to happen in the first place. Works amazingly well!
Half the time the task they wanted me to do will change anyway. So if I started it right away I would have wasted my time. It is a perverse situation that rewards procrastination. Use it to your advantage and do things that ACTUALLY need to get done!
1, Because it'll break code when copypasting from a website.
This is pretty rare these days since everyone uses code pasting sites like codepad.org and github's gist but it is a valid point.
2, Because you can't use matching braces feature of your IDE if you don't have braces, and it's harder to see when blocks start or end when you have a method that's longer than your screen height.
What the heck?!? You've obviously never coded Python in an IDE that supports Python. Python has braces, parens, and brackets for a lot of things (dicts, tuples, and lists, respectively) and the matching braces feature works fine. Why would it be different? Not only that but most editors that support Python also offer code collapsing and indentation works better for this purpose since you don't need matching brackets features to find the end of a function or object.
3, Because your IDE could autoindent your code if you used braces.
Citation needed. Every IDE I've ever used to code Python auto-indents my code blocks just fine. Real simple rules too: If there's a colon that's not already inside braces, indent the next line. Compare this to other languages where a brace could indicate any number of things. Figuring out when to indent is a lot more complicated.
The most "Pythonic" way to handle your scenario is both efficient and chimes well with your readability standards:
...and that's it!
# Assuming you've got a threading.Lock or multiprocessing.Lock object called 'my_lock'...
with my_lock:
code()
moreCode()
yetMoreCode()
#
Note that there's no need to call something like releaseLock() since Lock() objects support the 'with statement' (aka context manager). The indentation rules mean that the lock is released at the end of the 'with' block. Another advantage of this solution ('with statements') is that if one of those functions causes an exception the lock will be released in an orderly fashion. This is very effective at:
1) Preventing deadlock situations.
2) Making code concise and easy-to-read.
Also, thanks to Python's dynamic nature you can extend your lock objects to make them perform additional actions in the event of an exception (among other things).
IE 9 doesn't support WebSockets but IE 10 will. Having said that, I do have plans to include friendlier error messages for browsers that lack support for certain things. Under normal circumstances I would have supported IE but Flash-based WebSockets and other workarounds were just too slow or too bandwidth-heavy in my testing to be worthwhile. They might be OK for a single terminal but for multiple terminals they're terrible. Having said that I *do* re-test such things from time to time to see if things have improved (i.e. Flash could get faster) so it might change in the future.
For reference, supporting IE adds twice the development time to any web project! It can also double the size of the code base and drastically increases the likelihood of bugs. It's THAT bad. Hopefully IE 10 will be better but I said that about IE 9 before it came out (sigh).
Also, if you don't need to support IE your JS code suddenly becomes easy to read and starts to make sense!
In regards to your comment I'd like to make the following statements:
1) This is why I setup the demo to run lynx instead of a the regular SSH client... So usernames and passwords wouldn't be a concern (and to avoid liability). Unless you had plans to surf the web all day in text mode at liftoffsoftware.com (logging into things) I can't fathom how this could be a real issue.
2) I would never record anyone's usernames/passwords. Of course, you'd just have to trust me and I definitely understand if you don't. I myself try not to trust 3rd party websites with much. For reference, I'm not even logging what sites users are visiting in lynx. It isn't the point so why would I?
3) By default Gate One doesn't log incoming keystrokes. In order for that to happen you have to set logging to debug (--logging=debug). If logging is set to debug Gate One will display a HUGE warning message to users whenever a terminal is opened, "WARNING: Logging is set to DEBUG. All keystrokes will be logged." Of course, being the developer I could just turn that off but at least I had the foresight to include a user-friendly message.
4) It is trivial to replace sshd with a malicious copy that records user's keystrokes. Gate One is no more or less secure than OpenSSH from that standpoint. Users wouldn't even see a message that the host key had changed.
I'm not sure what the age cutoff is but pre-toddlers haven't developed their immune systems to the point where they would reject organs. There are limitations of course but having an ignorant immune system has its advantages.