Hacker News Reader

Comment by fka | Hacker News Reader

you're right, but local bash in the browser is technically not possible for now. (if you don't hack or bridge the chrome). It can be an emulator or a connector like the secure-shell app by Google in Chrome store. Terminal app provides a free and full terminal with Koding VM.

View on HN

ChromeOS has something, but I have a feeling that's the browser acting as a window manager and running the terminal from its underlying Linux OS. I do wonder what might be achievable with PNaCl...

Not saying what you've done ain't cool! Just wasn't quite what I expected from the headline :)

ChromeOS is able to show terminal in the browser because the feature is built into the browser. i.e terminal extension (crosh extension) on ChromeOS has special privileges to access the underlying system.

if you want to dig deeper (grep for terminal_private_api here):

http://git.chromium.org/gitweb/?p=git/chromium.git;a=commitd...

For whatever it is worth, I found ChromeOS's to be trash. I used it for a weekend on my Pixel and found it very unpleasant to use. If your environment isn't restricted such that a terminal in browser is really your only option, I don't know why you would do it that way. I don't see the use.

The one that's normally available (crosh) is pretty awful, yes. The dev-mode shell available by typing "shell" in crosh is more normal. All I really want it for is ssh anyway. If anything more hardcore is needed it gets rebooted into Ubuntu mode.

Haven't actually laid eyes on the pixel yet, I have a Samung ARM chromebook and I love it. Is the pixel worth the cash? And have you loaded an alternate OS yet?

Oh, I mean I wasn't impressed with the terminal emulator itself. At least when I tried it, it seemed to have problems with some ctrl-sequences (as in, other things would get them instead of whatever I was running in the terminal emulator). I also was not very impressed with the weird cursor fading thing it does.

Right now I'm running Debian Wheezy on my Pixel with a recent kernel that I built myself (the 3.0.whatever kernel Wheezy is on right now doesn't have touchpad support for the Pixel).

The Pixel is only worth the cash if you have very specific use cases. First off, I don't consider it worth the price with ChromeOS at all, so you've got to put a regular distro on it. ChromeOS might be tolerable with cheaper hardware, but for what I paid for the Pixel I just can't stomach it. The hardware itself is underpowered (i5, little ram, runs hot as all hell if you start running a long build or something (seriously, I've burnt myself.)) and has very little storage, so your usage pattern should be lightweight (I've used tiling window managers instead of fancy DEs for years so that is a-okay for me.) The screen is absolutely fantastic; best thing I have ever seen, and the real reason I bought it. The screen is so good that, despite the downsides I've listed, I am very pleased with my purchase.

In short:

  Upsides: Fantastic screen.  Linus uses one, so shit works.  Solid build quality.

  Downsides: Expensive, underpowered, can get hot as all fuck.

I think Google missed the mark with the Pixel. It makes a nice tech-demo for the screen and their ability to make things out of aluminum, but it isn't something I could recommend to anyone with 'normal' usage patterns. Don't buy one unless you absolutely know a high DPI screen is what you want, and know that the specs will accommodate you.

>> Oh, I mean I wasn't impressed with the terminal emulator itself. At least when I tried it, it seemed to have problems with some ctrl-sequences (as in, other things would get them instead of whatever I was running in the terminal emulator).

This is true, my go-to text mode editor (yes you can laugh) nano has Ctrl-O for write-out and that brings up the ChromeOS open dialog instead. It's most irritating.

I might wait for the next-gen pixel then, if there is one. I would like a high-dpi screen and I do usually work on remote systems, but it sounds like there's a problem if it gets that hot when you put any load on it.

Heat is absolutely a problem with the current Pixel. My suspicion is that the Pixel can probably cool itself well under loads you would expect in ChromeOS, but if you fall outside of that usage pattern it becomes problematic. (There probably aren't a lot of ways to peg the CPU at 100% for minutes on end in ChromeOS while not in dev-mode.)

> if there is one.

Yeah, that is a big if. I don't have any sort of sales figures for the current Pixel, but I haven't encountered many other people with one... I suspect it isn't selling well.

> There probably aren't a lot of ways to peg the CPU at 100% for minutes on end in ChromeOS while not in dev-mode.

Load a webpage with just one or two screenshot-sized animated GIFs. Browsers are really bad at this; I wonder how many years it's been since the GIF rendering code was touched in most implementations.

Interesting. On my phone pages loaded with animated GIFs are slow as molasses but on my regular ol' Linux (Core i7, Intel graphics) desktop I don't think I've been to a page where I experienced any sort of slowness.

For example, this page: http://imgur.com/a/Htgmq (Animals Staring, SFW)

That'll bring my Samsung Galaxy S4 (a very current quad-core phone) to a crawl but my desktop won't even get the chrome process above 10%. Maybe it's GPU-related? I wonder if Chrome for Android even uses the GPU, hmm...

Those aren't nearly big enough! See instead: http://rainbowdivider.com/, or better yet http://totallytransparent.tumblr.com/ (note that in the latter one only the animated images are GIFs)

But now, a trick, to make browsers even angrier (which is starting to come up as a use-case in, e.g., forum signatures and avatars):

1. set the GIF to a non-native scale (e.g. width="100" height="100");

2. apply a CSS animation to it, where the CSS animation loops a filter() value on the GIF. For example, filter: hue-rotate() the GIF through a 360 degree cycle every 2s. For maximum pain, apply a filter: blur(). (Warning: this last one may actually crash your browser, or at least cause severe artifacting on random parts of the page. I've been intending to report it to Chrome's bug-tracker for a while...)

I believe this causes as much havoc as it does, because GIFs are always decoded on the CPU, and the results of decoding GIF frames and scaling them to display size are never cached; instead, each time a GIF transitions to a new frame, it writes the frame-delta directly on top of the previous frame's video memory. So, when you apply a GPU-bound filter to a CPU-bound write-heavy texture, you give the GPU's pipeline a pessimal case.

> There probably aren't a lot of ways to peg the CPU at 100% for minutes on end in ChromeOS while not in dev-mode.

Hahaha! Have you even used Gmail?

Lots of games (Running Fred, I'm looking at you!) will also peg the CPU at 100%, obviously. Then there's the fact that there's a lot of bad code (JavaScript) out there that does things like downloading 50MB worth of email addresses into an Array :)

This is interesting. I am the author of Gate One (https://github.com/liftoff/GateOne) and I learned early on that Chrome doesn't let JavaScript override Ctrl-T, Ctrl-W, and Ctrl-Tab but Ctrl-O? That's silly. There's no reason why they couldn't override that.

Note: You can work around the Ctrl key override problem by opening up any web app via an "application shortcut". Menu-Tools->Create application shortcut.

There's actually an app called "Crosh Window" to fix the Ctrl issue. It opens in a separate window and can take Ctrl sequences without Chrome picking them up.

https://chrome.google.com/webstore/detail/crosh-window/nhbmp...

Interesting, I was thinking about getting one for browsing/webapp use and remote development over ssh. In addition to the screen, I also like that ChromeOS sounds like it handles OS updates much better than anything else - free, seamless, automatic OS updates for life apparently. Better than Windows 8 trying to turn the computer into a giant tablet or OS X creeping further towards being a giant iOS device. Or linux distro updates breaking things (at least that's been my experience with linux). And all have a lot of overhead as far as installation time.

I have a Samsung ARM Chromebook and I use it all the time. Way more than I thought I'd use it. I bought it as a testing platform for Gate One (https://github.com/liftoff/GateOne) but I end up using it most when, "someone on the Internet is wrong." (haha).

So I'll be chilling out in my Lay-Z-Boy with my family watching a kids movie (that we've watched like six times), surfing the web on my phone and lo and behold someone will say something that needs an old fashioned Internet whomping--with references, snide remarks, and lots of puns. The type of thing for which a phone (software) keyboard isn't suited. As in, "I cannot let this person's false statement go unchallenged!"

So I dash to the office ("Honey, where's my super suit?") and I have a choice to make: Un-cable and remove my nicely-mounted (on a cool swiveling arm!) dual-SSD Acer S5 laptop and haul it back to the living room (you know, so I can share the experience with my family =) or I could grab the Chromebook which is conveniently located near the door and has only a single, tiny power connector.

In less than 60 seconds (maybe 30 if I don't grab a drink on the way back!) I will be back in my Lay-Z-Boy, furiously typing away on the Chromebook. Saving the world from the ignorant, shills, and Microsoft fanboys.

If ChromeOS is the sort of thing that you can be satisfied with, then the Pixel may or may not be worth it; it is hard for me to judge that since I'm not really a fan of ChromeOS.

If you're running the browser think you might want this instead: https://chrome.google.com/webstore/detail/secure-shell/pnhec...

> local bash in the browser is technically not possible for now.

Yes it is, and I've seen it. It was posted to HN a while (like about a year or two) ago, and could run emacs etc. It was done by emulating x86 in Javascript and then running Linux on the emulator.

You are probably referring to the work of Fabrice Bellard?

http://bellard.org/jslinux/

This is an emulator. Not a real one. This 'looks like a terminal'

Yes I am, thank you for the link!

local bash in the browser technically is possible without any hacks. You need to write an NPAPI browser plugin to do forkpty() and the browser-javascript can access the pseudo terminal through the NPAPI plugin.

It's certainly possible to run a GNU userland on top of NaCl, though it would be highly nontrivial.

i already told that it's possible but "connecting to local terminal from chrome" is not that possible. maybe you can do it over local SSH connection.

Well, if you're using Chrome on Linux you can just run Gate One (https://github.com/liftoff/GateOne) on your desktop and connect to https://localhost/. That'll let you access SSH or whatever terminal program you like. I use it every day!

(full disclosure: I wrote Gate One =D )

> (if you don't hack or bridge the chrome)

i already said that. can you serve Gate One as Chrome Extension? No.

Reply on news.ycombinator.com