Run Crouton in a Chrome OS Window | Hacker News Reader

Run Crouton in a Chrome OS Window

plus.google.com

155 pointsT-A17 comments

For those of you looking to get this going here's a tip: At the moment there is a bug in Crouton where you need to put "wixi" first in the list of targets when building a new chroot to get the extension to bind correctly.

Typo: I meant "xiwi".

  sudo sh -e ~/Downloads/crouton -t xiwi,extension,core -r trusty

My experience getting this to actually work on my Chomebooks (didn't work at first), and then turning it off. I turned it off because at this point 3d acceleration isn't enabled in the Chrome window, so games like Minecraft are not performant enough. A dev environment should work great though.

This is copied from the g + thread.

I have tried this and initially had some issues getting it to work, maybe my experience can help others to get this working:

For me I already had a crouton chroot running Ubuntu Trusty on 2 different Chromebook so I did not want to wipe and start over (after all in unix everything is a file).

so to update my chroots I did this after installing the chrome browser extension:

$ sudo sh ~/Downloads/crouton -u -e -t xiwi,extension -n trusty

this loads the new targets and the '-e' encrypts the chroot and forces me to make a root password for the Chromebook which seems like a good idea.

So on one machine this is all I had to do ... .If I run $ sudo startxfce4 it pops up a window, however for the other machine it would continue to open full screen.

the reason for this is wrong symbolic link at /etc/X11/xinit/xserverrc

basically if it is linked to /etc/crouton/xserverrc-x11 you get the full screen version, if it is linked to /etc/crouton/xserverrc-xiwi you get the windowed linux.

to change this simply:

$ ln -s /etc/crouton/xserverrc-[xiwi|x11] /etc/x11/xinit/xserverrc

edit: Google plus's markup syntax is jacked with no apparent way to escape a "-"; so the strikethrough is artifactual.

broken up: $ ln -s /etc/crouton/xserverrc-[xiwi|x11] /etc/x11/xinit/xserverrc

(the brackets [] with the | indicate choose one)

These computers are used by my kids and the linux partition is primarily used to play Minecraft. As there is not currently hardware graphics acceleration in the xiwi linux chrome window the performance is quite poor with Minecraft so I switched back to the xserverrc-x11 config. This will be much better once GPU acceleration is supported in window (whispers of which can be seen on the github PR), until then I guess we will have to <Ctl>+<alt>+<shift> + forward and back to use linux on our Chromebooks.

Sounds great.

I would like to read about your experience using ChromeOS/ChromiumOS on a dev PC. What's your workflow (text editor, dev-IDE, web stack)?

My preferred method is to run 90% of my stuff in a digitalocean coreos-based docker container, with the mosh-chrome extension to access it. The only things I don't run in the cloud is my browser (use the chromebook chrome browser, naturally) and a tiny number of cases where I have to run a tool on a full linux machine (use crouton, as per OP).

In this way, I can switch dev machines without missing a beat... just need to paste in my ssh key into the new chromebook's mosh-chrome, and I have a 100% functional dev machine again (sans the crouton-based stuff, of course, which is why I avoid using crouton as much as possible).

My ChromeOS machine is a thin client that's used for SSH, connecting to either a server somewhere, or a beefier computer at home, so I can work from the couch.

Originally had crouton set up for some local dev (CLI tools only to save RAM; vim and a compiler are all I need), but it kept trashing SD cards. Everything was run off SD cards, because my particular chromebook (Acer C720) doesn't have that much onboard storage, only 16GB or so. But SSH is really all that I need.

If you dont want ChromeOS but a real laptop, why not just get a proper laptop instead?

People want the Chromebook device without the ChromeOS.

The Chromebook is a good piece of hardware for the price. And it's not a laptop but a Linux laptop which you don't just pick up at the local Best Buy. It's a mess putting Linux on a Windows 8 laptop.

> It's a mess putting Linux on a Windows 8 laptop.

I can see how it affects the price and things gets a bit more expensive due to the Windows-license, but how on earth is it "a mess" installing Linux on a laptop which previously had Windows on it?

Especially given all the loopholes and workarounds people have to resort to to actually get Linux running on these locked down so-called "Linux" laptops?

I mean... This article itself is proof that Chromebooks are worse than Windows-laptops, right?

Speaking of things running in places where they were not necessarily meant to run, I have pretty much ported all of Unix to run as an HTML5 app in a browser tab. The whole thing is just a steaming pile of javascripty goodness.

It currently just copies OSX for the GUI, but I just wanted to do that to get people interested in helping me develop it, rather than trying to confuse end users. I've been hacking on it pretty constantly, all alone, for the past ~2.5 years, so if anyone wants to start working with me, let's talk! You can find my email on the site by clicking on the Pac Man icon and then "About".

First mission: work on a new GUI look and feel so big bad Apple doesn't come with their lawyer armies...

Try it at http://urdesk.net

You have "ported all of Unix"?

Yeah, what does that mean? You've hacked together a POSIX-ish layer in Javascript? Or you've actually ported one of the many open source Unixen?

nice :)

care to share the unminified source? From what I can see in my inspector it looks like you've just made some HTML UIs that look like a couple specific Mac apps, which alone would be a far cry from "porting Unix" and not that original of an endeavor

You probably don't want to see the unminified source. He has reimplemented CSS as well as ASCII conversion in JavaScript. Oh, and he's mutilating prototypes left and right with extremely necessary functions like

  HTMLElement.prototype.add = function (a) {
    this.appendChild(a)
  };

There's code for asymmetric encryption and some sort of mail client buried in there... As well as a very faithful almost-Bash parser... and I can't for the life of me find where `ls`, `ln`, and `pwd` are executing from. Because this terminal has them apparently.

A lot of work was put into this, a lot of very interesting work. But I feel like a lot of this could be done a little more easily now with the invention of Emscripten... and even then, why would we have native apps ported to JS when we could just have JS apps?

If you have some free time, pop open the Chrome Devtools and click the Sources tab, paste that JS right into http://jsbeautifier.org/. It is truly interesting. Just don't know if I'd have written it myself.

I feel like UNIX works well enough right where it is. And if you really need a true UNIX in-browser, http://bellard.org/jslinux/ can help you out.

Nice work although I'd expect at least "cd home; mkdir test" to work in the terminal before claiming to have ported "all of unix" :)

Edit: just noticed it does work in /tmp though! Difficult to know as "ls -l" doesn't print any perms... a little more porting work may be required I think ;)

Reply on news.ycombinator.com