Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

Riskable writes "Version 1.1 of Gate One (HTML5 terminal emulator/SSH client) was just released (download). New features include security enhancements, major performance improvements, mobile browser support, improved terminal emulation, automatic syntax highlighting of syslog messages, PDFs can now be captured/displayed just like images, Python 3 support, Internet Explorer (10) support, and quite a lot more (full release notes). There's also a new demo where you can try out vim in your browser, play terminal games (nethack, vitetris, adventure, zangband, battlestar, greed, robotfindskitten, and hangman), surf the web in lynx, and a useful suite of IPv6-enabled network tools (ping, traceroute, nmap, dig, and a domain name checker)." Gate One is dual licensed (AGPLv3/Commercial Licensing); for individuals, it's pay-as-you-please.

The editor wars came to a standstill in the 90's! Why did you have to break the ceasefire?But if we're flaming anyway, I would like to remind you that Emacs Makes Any Computer Slow and that it is a very nice operating system; it just lacks a text editor (but it's still infinitely better than nano or pico or notepad).

Excuse me? I'm an MS person and I use VIM every day. I actually consider it obsolete, but I've been using Vi-like editors for 30 years and am too old to start over.

The Slashdot effect happens when somebody implements a simple-minded LAMP server and suddenly becomes popular. Modern web applications are more robust. They're implemented using lightweight frameworks that don't have such a high per-user cost and which can scale up quickly when unexpected demand appears. This is the sort of advance people overloo

A few years back, I experimented with a lot of editors (and terminal emulators), when I got seriously involved in i18n (internationalization) efforts. I was at that time unable to find any editor that handled UTF-8 encoding as sanely as vim, so I've stuck with that. It'd be interesting to know if there are other editors that do a good job with mixed writing systems these days. Others have to have worked on it, but I haven't found time to repeat my investigations (which were a really frustrating time sin

nano is by far the best, simplest, easiest choice there is for command line(curses) editing text files. Plus modern versions of nano do syntax highlighting for scripts and code.

emacs is hidelously over-complicated. emacs is also terribly overfeatured and violates the UNIX philosphy of "do one thing, do it well". Also 1975 called, they want vi back.

emacs X11 is also terrible and extremely awkward, clumbsy and unfeatured as a text editor. many modern heavy weight text editors like gnome's gedit are power powerful, as well as easier to use, and simply more intuitive.

How hard is it on a modern linux desktop to use gamin to read the shebang and auto highlight syntax??

Do I really need crypto, a calculator, a calender, or other text based anacronisms in my text editor when they've been replaced with really pretty, extremely functional X11+GTK/QT apps a very long time ago. (that all seems to inter-operate with eachother based on freedesktop.org open standards, accross all 4 desktop enviroments I have installed)

I poked around nano's website [nano-editor.org] and it seems pretty capable.
It sounds like nano does everything you need, so there is no reason to learn about other editors.
I have fond memories of pine and pico; maybe I will look at nano one of these days.

fwiw, I find some powertools worth learning to use well even if they have a non-easy learning curve (sed comes to mind). This also applies to text editors; they're just tools.
As for "1975 wants vi back", I actually get a lot of mileage from vim [vim.org] which is a bit closer to nano's era.
nano: born 1999 as TIP, inspired by pico.
(btw, the last item on the nano news page [gnu.org] is from 2009: "Now on Twitter and Facebook and Happy 10th Birthday nano". Is nano under active development these days?)
vim:born 1988, released 1991 (initially for amiga, much more widespread now), inspired by vi (note I do feel sorry for anyone stuck using "classic vi" in the same way I'd feel sorry for anyone stuck with edlin).
(side note: vi-style learning curve sucks. My first two weeks were Painful, but now that I have some skill (muscle memory) with the keys I find it very effective. Kind of like how touch-typing is harder to learn than "hunt & peck" but it is still well worthwhile to learn how to touch-type; it pays dividends. Most of vi-style power (for me) comes from the fast navigation+editing commands that are tied to a rather terse (and admittedly cryptic) "shorthand" language of key combinations... I remember actually being surprised at how clunky arrow key + mouse navigation felt when I first used conventional editors after driving vi-style for a while.)
One of the things I like about having learned Vim is it will be available pretty much wherever I might need to work: here are some of the targets from from wikipedia's vim page [wikipedia.org] (* indicates ports I have used):

(I've also found vim for aix; useful if one needs to spend time there.) Note that vim seems pretty consistently fully featured on the various platforms I've used it on (*'s above).
By comparison, nano seems pretty content to excel in linux distributions (redhat & debian).
And maybe, possibly, kind of sort of windows: from the nano faq, 3.9 How about in Win32 [nano-editor.org]

We're still working on documentation for enabling synax highlighting on Win32; please bear with us. Note that the nano.rc file must remain Unix formatted in order for nano to understand it. In other words, you should use probably only use nano to edit its config file. Other programs like Wordpad and Notepad will either convert the file to DOS format when saving, and the latter does not even properly read Unix-formatted files to begin with.

*shrug* I'm glad nano is working for you in the land of the modern linux desktop.

As for emacs: I sincerely believe that emacs users enjoy the capabilities they find; I may find a need for something emacs does well these days. I've never heard anyone say "Yeah,

Emacs also good for prototyping postscript pages and running postscript code while inside emacs with postscript mode inserting macros/subroutines/font selections as needed; c-code writing; lisp macro but also writing lisp code and eval-ing it without leaving the editor.

Nano is on knoppix live-boot stuff and that's where i play with it. Didn't know about pico... Of course, go older and use "ed" or "cat >" into files too, eh?

Complete rubbish. You can turn off the final carriage return in nanorc - it's there because a lot of scripted config file parsers require it. I bet you didn't even know nano can do regex search&replace either. ps: "real engineers don't blame their tools" *happily employed developer and sysadmin of 20+ years who uses nano*

--You sir, are a jackass. Cause for termination, indeed. Obviously you've never spent time without a job, scrambling to eat and try to survive - much less pay your bills. You arrogant idiot.

--I use nano, jstar, mcedit, whatever comes to hand and is installed on the box. Only use vi if there's nothing better. I stopped using EDLIN back when Xtree Pro Gold came out, because **it was a better tool.**

--Cause for a friendly warning, I would accept. Cause for termination? FU.

I will stick with nano. When I need to work in a terminal emacs and vi(m) just seem to much of a pain in the ass. Why would in need to have a text editor be my browser, my mail client, rss reader and chess opponent (emacs)? Why do I need to switch modes to move around text files when I have arrow keys on my keyboard(vi(m)) to do that? Nano is clean and simple. It edits text files. If I need to do something else I would use something else. Emacs seems to me in my humble opinion to have forgotten the Unix phi

1) I tried hangman but it wasn't working; Chrome 22.0.1229.94 on RHEL6. (It's slightly out of date -- see "RHEL6.":-))

2) I strongly dislike putting it into the browser (for a couple reasons, that just doesn't work with the way I use terminals); any plans for some stand-alone program (even if it's just a wrapper around a webkit widget or something)?

3) I like some of the recent efforts towards rethinking what it means to be a terminal emulator (embedded images and such), so kudos for that.

... I think made by Citrix, and it "runs" in your browser, but I would not really recommend it to anyone. Total steaming POS...

The maskhouse we deal with uses(d) that for customers to verify that the layers are what they expect. The program they run on the other end is something from Apollo workstations era, window manager in that session was TWM (we are talking now, a decade into 21st centiry!:) ), and it was slower than when I first tried running X over dial-up modem in 90s, without compression...;-)

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:).

Other than to offer to help. In the very least I can test the hell out of it...

I have been thinking of ways to make a HTML 5 or other web based "X11 server" for a while. The thinking has only gotten as far as a rough map of the most effective ways to do it so far. (Java and Flash are both non-starters in my book)Chrome + Native Client + websockets or inbuilt ssh tunnel over port 443 = most straitforward but a lot of work just to make an actual

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

I was fairly sure the best performance cross browser wise would be with canvas.

My motives for SVG were more compression & transform speed. Being able to do the Window Manager 'theme' stuff Motif/CDE/twm/etc, farmed out to the browsers CSS/XSLT, and any other tricks that can be performed using the SVG in order to avoid sending image data for performance. SVG is getting better with time, and I'll agree it has a long way to go compared to canvas, but at higher resolutions, it would have distinct advantages

In the past, people have recommended SSH and VNC clients as a workaround to run applications that Apple disapproves on a remote server and display them on an iPad. I just fear what will happen should reliance on remote desktop to work around Apple's policy becomes more widespread.

The main use of this is being able to access an environment from anywhere. This includes networks that do not allow you to ssh out of their networks, which is becoming a common security practice these days.

I have this installed on my server, as my company's netsense filter is far too aggressive and I can not access personal email or chat programs from work. I find from time to time I need to answer personal emails in a timely manner (like when I bought a house), and tapping out messages on a phone doesn't c

The main use of this is being able to access an environment from anywhere. This includes networks that do not allow you to ssh out of their networks, which is becoming a common security practice these days.

So the main use is to get fired for violating your employer's IT security policy? Brilliant!

Can you not conceive of a roaming consultant who does not wish to install his whole toolset on his client's machine?Also, browser -> remote ssh server -> remote network is still more secure than local ssh -> remote network.

I run a few websites that generate a small but growing amount of traffic (and hopefully one day, revenue), so its also nice to know that from any computer, I can log in to my jump server, and take a look if something goes down, with nothing more than a web browser. It could be a locked down computer only offering a web browser, or a friend's computer I don't want to be fumbling around and installing putty on, etc.

This isn't mission control, we are talking about a few blogs here. The security policies I am avoiding are intended to prevent data being sent out of the firm undetected, and I am not doing that, and I don't have the ability to do that in any reasonable way.

I don't consider loading up a web browser from a friend's house or wherever I am in an outage situation to log into my server "beyond stupid." I wouldn't even consider it mildly stupid, and its certainly not something to flame someone about.

There's Atomic OS [sourceforge.net], OS.js [github.com]...that building an OS is ECMAScript seemed like a good idea to multiple people makes me cry. For full buzzword bingo, run the local browser in a virtual machine, and host the browser OS code in the cloud.

If I can run a browser, I can run a SSH client. Bonus: The stand alone terminal emulator / SSH client doesn't come with the attack surface of a web browser, or security vulnerability baggage of JavaScript's JITs (marking data as code, then running it).

I really want to like this, I'm just not finding any use cases for it that something like PUTTY wouldn't be better for. (Well, I did, but they were really freakin' out there edge cases.)

Not to mention that ajaxterm sort of makes you want to pull your nails out with pliers as an alternative. I've been running GateOne for quite a while now, and I'll be upgrading to this version this weekend.

As someone who works on a product where support people routinely have to use remote-desktop with a customer and get them to SSH into systems, this seems like it might be a huge boon, since not all customers have SSH clients pre-installed.

The only thing I can think of is that I'm working on someone else's computer and can't install anything locally, but even then this won't work because you still have to download it. I guess this is just a "because I can" sort of project.

You don't download it on the client machine. You download and install it on the host machine. When you run it on the host, it runs a web server, which you then access from the client machine via the web browser.

So, assuming you already have it up and running on your server, all you need on your friends' computers is the web browser.

I use a free competitor called ajaxterm to get around firewall insanity. So if the local restaurant blocks all SSH connectivity as a hacking tool (idiots), in fact only lets thru 80 and 443, this is perfect. Well, if the target machine didn't have a web server on it I could run SSH on 443 and connect to it, but if the whole point of the machine is web serving then I can't very well remove the SSL web server and stuck sshd on port 443.

This is not a daily thing, but more an OMG emergency back door when all else fails thing. My advice is put it under a mysterious URL, its too easy to scan "whatever.com/ajaxterm" on a guess, and don't link to it.

I've also used it in presentations, all I need on the client machine connected to the projector is a standard web browser. No admin rights to install stuff, etc. Just go to this page.. which doesn't work... then ask why the heck they are using MSIE 5.0 or whatever in 2012.. etc. But it does work great with a "modern" "real" browser.

I guess that Gate One is windows-only, since on other OSes you have terminals by default. And on windows everyone that I know is using putty. So I wonder - is that going to be putty replacement, or too much hassle to get it to work?

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 capabilitie

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).

ok. So how do you solve keyboard support on tablets? Think: arrows, pg-up/pg-down, special characters

major hindrance is that tablets don't have arrows on their "keyboards"

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, whe

Does that mean, that in the browser window upper half of the screen will be a terminal, and bottom half will be a full keyboard - both embedded into the window? By this way you will not use the inferior tablet's keyboard, so this might work....

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.

Even desktop operating systems are a mixed bag. Most users don't get an ssh client with their operating system.

Speaking of connectbot, I complained previously about it not working on my rooted Nook Simple Touch. It does now. I used a different root method this time, but I imagine it's also had updates in the interim.

No, its not. It runs in a browser and is thus cross platform. The main point is that the ssh session runs on the server side, so you are essentially tunneling ssh through http. Very nice if you need ssh access in an environment that won't let you ssh out of the network.

There are multiple solutions already available for Web-based SSH [wikipedia.org]. GateOne says it needs a Python app installed on the server to support the tunnel. If that's hosted on their servers and this gets popular, expect that site to get blocked at the same sort of shops that block ssh. The main claims they seem to be making are for a higher quality of terminal emulation than the other ways around this issue that already exist.

Yeah there are. Most are pretty crappy. GateOne just performs far better, to the point where you can actually use it for useful work. I used to use ajaxterm, it worked, but had weird bugs. Later I moved to webshell, which was a big improvement. GateOne is an improvement further still. I use this on my personal server, so unless they are inspecting packets to see that this is an app, which currently my very paranoid company does not do, this won't get blocked.

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.

AFAIK, port 22 (ssh) is not allowed to be accessed from within a browser. This means that everything you do must go through a server, which means, big brother may be watching you, completely defeating the purpose of ssh. Please tell me I am wrong.

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!;)