Skip to main content

Dart: My Quest to Program Dart on a Chromebook

They gave me a cool new Chromebook at work. Now, the sensible thing to do is to use it as a convenient web browser and nothing more. However, I'm not a very sensible person, and for some reason, I dislike having more than one computer at a time. Since I'm a member of the Dart team, I figured I should be prepared to use Dart Editor at any time of the day or night. Hence, I embarked on a multi-day journey, driven by my own obsessive compulsive disorder, to somehow figure out a way to run Dart Editor on a Chromebook.

By far, the easiest approach is probably to install Ubuntu on it. I didn't want to take that approach since I really wanted to use ChromeOS as well, and I hate dual booting.

The next approach is to put the machine in developer mode and install various things within the existing Linux distro. There are some pretty good instructions on that here. They involve setting up a build server, etc., which I balked at--I want fewer computers, not more computers!

My next idea was to install a full Linux distro in a directory and chroot into it. I thought I was the first one to come up with this idea, but apparently, several other people have had this idea as well (which is the way ideas usually work). There are pretty good instructions on how to do that here. By the way, that page covers the other approaches as well. I spent a couple days with this approach, and I made a lot of progress. However, I never got things to work just right. I faced a few major hurdles:

  • The Chromebook is already running a window manager, but it doesn't work as a normal X11 window manager. Dart Editor doesn't behave very well without a normal X11 window manager. Furthermore, getting another window manager installed and running is non-trivial, and it makes ChromeOS look ugly.
  • There's a lot of confusion about 32-bit vs. 64-bit binaries. If I understand correctly, the Chromebook is a 64-bit device running 32-bit binaries. There's also some confusion about 32-bit vs. 64-bit in the Dart Editor world which threw me off.
  • I was having a hard time getting all the right dependencies to get Dart Editor and Dartium running.

Eventually, I discovered that some companies...ahem...don't like it if you put a Chromebook into developer mode and then try to connect to the corporate network. That kind of makes sense since putting a Chromebook in developer mode circumvents many of the nice security features the Chromebook provides. Hence, even if I did manage to get any of the above approaches working, I wouldn't be able to use it at work.

My next approach was to look at Cloud9 IDE. It looks interesting, but it doesn't support Dart, and it definitely doesn't support Dart Editor.

My next approach was to try "Chromoting" into a Linux box in the cloud using the "Chrome Remote Desktop" extension. I figured that would be easy to get working. Best of all, this doesn't require any hacking of the Chromebook. However, it has a few major drawbacks:

  • It doesn't work when I'm on a train (which is one day a week).
  • It doesn't work when I'm on a plane. It may sound strange, but almost all of the time I've spent learning Dart was while on planes flying around to give various YouTube API talks.
  • If I use chromoting to give a talk on Dart, and my network connection goes down (which tends to happen every time you give a talk), I wouldn't be able to use Dart Editor.
  • Chromebooks don't currently have a VPN solution.
  • Chromebooks do support SPDY Proxy, but that doesn't currently work with Chromoting.

Even with all those drawbacks, I knew Chromoting was the only solution likely to work for my particular set of constraints, so that's what I got to work. I had to install a 64-bit JDK and the 64-bit version of Dart Editor, but I eventually got things working. Hence, the picture above is a picture of me Chromoting into my Linux box and running Dart Editor.

Ok, now that I've spent way too much time on this, and it's still not something I'd want to use on a daily basis, maybe it's time I get back to work ;)

Update September 11, 2012: I tried installing ChrUbuntu 12.04 on it using these instructions. I got Dart Editor working, but my wireless wouldn't work reliably.

I've heard that there are occasional driver issues when running 64-bit Linux on this device, so next I tried following these instructions. They walk you through installing ChrUbuntu 11.04 and upgrading twice to 12.04. Sure enough, this fixed my wireless problems. It temporarily broke my trackpad, but plugging in a mouse and rebooting fixed that problem. However, after following those instructions, I couldn't get Dart Editor to work. Whenever I tried to run it (from the command line), it would say, "Cannot find DartEditor". This is despite the fact that I was specifying the path to the executable. I think this is yet another weird 32-bit vs. 64-bit problem in the JRE.

The fact that Chromebooks have a funky EFF BIOS makes them really great for running ChromeOS securely but not so convenient when you're trying to run a normal version of Linux. Having been defeated twice more, I got a USB drive and installed ChromeOS from scratch and exited developer mode.

Update February 26, 2013: I was hoping that "emerge chromeos-dev" was going to be the path to success, but it turns out that it probably won't be, at least in the short term. See this forum post. Right now, Crouton looks to be the most viable approach. Also see this blog post.

Update February 27, 2013: Success! I got it to work, thanks to Crouton, which is based on using a chroot. See my newer blog post.

Comments

Popular posts from this blog

Ubuntu 20.04 on a 2015 15" MacBook Pro

I decided to give Ubuntu 20.04 a try on my 2015 15" MacBook Pro. I didn't actually install it; I just live booted from a USB thumb drive which was enough to try out everything I wanted. In summary, it's not perfect, and issues with my camera would prevent me from switching, but given the right hardware, I think it's a really viable option. The first thing I wanted to try was what would happen if I plugged in a non-HiDPI screen given that my laptop has a HiDPI screen. Without sub-pixel scaling, whatever scale rate I picked for one screen would apply to the other. However, once I turned on sub-pixel scaling, I was able to pick different scale rates for the internal and external displays. That looked ok. I tried plugging in and unplugging multiple times, and it didn't crash. I doubt it'd work with my Thunderbolt display at work, but it worked fine for my HDMI displays at home. I even plugged it into my TV, and it stuck to the 100% scaling I picked for the othe

ERNOS: Erlang Networked Operating System

I've been reading Dreaming in Code lately, and I really like it. If you're not a dreamer, you may safely skip the rest of this post ;) In Chapter 10, "Engineers and Artists", Alan Kay, John Backus, and Jaron Lanier really got me thinking. I've also been thinking a lot about Minix 3 , Erlang , and the original Lisp machine . The ideas are beginning to synthesize into something cohesive--more than just the sum of their parts. Now, I'm sure that many of these ideas have already been envisioned within Tunes.org , LLVM , Microsoft's Singularity project, or in some other place that I haven't managed to discover or fully read, but I'm going to blog them anyway. Rather than wax philosophical, let me just dump out some ideas: Start with Minix 3. It's a new microkernel, and it's meant for real use, unlike the original Minix. "This new OS is extremely small, with the part that runs in kernel mode under 4000 lines of executable code.&quo

Haskell or Erlang?

I've coded in both Erlang and Haskell. Erlang is practical, efficient, and useful. It's got a wonderful niche in the distributed world, and it has some real success stories such as CouchDB and jabber.org. Haskell is elegant and beautiful. It's been successful in various programming language competitions. I have some experience in both, but I'm thinking it's time to really commit to learning one of them on a professional level. They both have good books out now, and it's probably time I read one of those books cover to cover. My question is which? Back in 2000, Perl had established a real niche for systems administration, CGI, and text processing. The syntax wasn't exactly beautiful (unless you're into that sort of thing), but it was popular and mature. Python hadn't really become popular, nor did it really have a strong niche (at least as far as I could see). I went with Python because of its elegance, but since then, I've coded both p