Hacker News Reader

Comment by jdf | Hacker News Reader

I feel like the Chromebook is actually a better experience than a laptop.

As a programmer, I honestly only use 2 windows: browser and shell. Running crouton to create chroot Ubuntu "images" I can have my normal full (text-based) dev environment, and alt-tab back and forth with the browser. Honestly it feels easier to use than Ubuntu - I don't use any of the builtin Google services (e.g. Drive), but they manage to stay out of the way.

It's pretty cheap, looks pretty reasonable, and comes in at a pretty low weight. The screen's not the greatest, but I'm not doing anything where that matters. So all in all a great dev machine.

Only caveat for me is that Dropbox doesn't have an installable app for ARM. I need to find something else that does a good job of seamlessly syncing my workspaces and NFS, rsync, etc don't fit as nicely as Dropbox.

View on HN

What are you actually building that will run on this hardware? Are are you ssh'ing into a different machine?

I just can't see it possible to run anything that relies on the weight of the JVM or relies on external apps (Redis, etc). What web app can live without some sort of a data store (MySQL, PostgreSQL, MongoDB, etc)? Let's not even get into if you need to compile anything. (Even if you're not working in C, compilation is sometimes necessary with gems/npm/etc)

The default answer seems to be just ssh into a dev machine, using the Chromebook as a dumb terminal. While it works, that destroys a classic workflow used by many, relies on Internet access, and adds additional cost (especially if you're a consultant). Even a cheap VPS adds at least $300 a year in cost.

Am I incorrect about running a full dev environment on the Chromebook? I'd love to hear others' experiences.

For me, there are three potential types of applications:

a. Those that run fine on the Chromebook.

b. Those that would run fine on a larger laptop or desktop, but not on the Chromebook.

c. Those that need to be deployed to some sort of server.

I don't write anything that falls under (b). If a program is expecting to be run on 10 disks, or with 48gb of RAM, or across a cluster of 12 nodes, it's highly unlikely that my personal dev machine will work out, so (c) will be used. That's also how I'd want to test any production-level deployment.

The gap between (a) and (b) is actually quite small. The Samsung 3 Chromebook specs are a bit better than almost every smartphone, so pretty much any Android app could be placed under (a). Pretty much any unit test for a (c) app fits under (a).

Compiles would be faster with a beefier dev machine, but the fact that the Chromebook comes with an SSD already places it ahead of the default corporate machine (at least in my experience - perhaps employees get SSDs in their Dells nowadays). Certainly a MB Air has a faster CPU, but the difference isn't that dramatic for development purposes.

As one counterexample, I'll point out that my wife spends most of her work day in Photoshop and Illustrator. Even if those apps ran on Linux, my guess is that the resource needs would still make an Air or a MB Pro a much better choice.

SSD isn't automatically faster than a traditional HD, as people using SD cards to boot ARM boards have found out.

The SSD in the Chomebook for instance gets about 64 MB/s sequential read, 17 MB/s sequential write, 4 MB/s random 4k read and 1 MB/s random 4k write.

Which in practice is probably better than a 5400 RPM HD, but there's still a magnitude of difference from a most laptop SSDs.

I can't answer for jdf, but, in my case, I've built a lot of applications using Django and Google App Engine on very frugal hardware, probably less than a more recent Chromebook. On both cases, the development environment is very light and defaults to store data in SQLite. Working with Python allows me to skip compiling stuff most of the time. Of course, a JVM is off the table, as is using Eclipse for your IDE. This machine is one of the reasons I went back to Emacs.

I've always been a vim/screen/bash user rather than an IDE, so I can't speak to the experience of using Eclipse/IntelliJ on a Chromebook. The fact that I'm doing everything console based certainly lowers the resource needs since the chroot isn't running another windowing system.

I know the JVM isn't often associated with low memory applications, but it seems like it should be possible. As I mentioned in my other reply, the Chromebook has more resources than the average Android phone, so all those Java Android apps should run fine (albeit under Dalvik rather than Sun's JVM).

I would not dare to run Eclipse under Dalvik. Just the other day, when someone compared it to Emacs here, I wondered whether it should be called "Egacs" rather than Eclipse.

The real problem is IDEs; the JVM is also a resource hog; however, you can run lots of server software on small hardware; heck, my RaspberryPi runs mysql, postgresql and apache (and PHP), plus a django app, and has only 256MB RAM; it's not blazingly fast, and you wouldn't use this in production, but for development ...

I appreciate what you are saying, as I had a CR-48 and liked it a lot. That said, unless you absolutely do not want to perform any configuration or just don't want to spend more money, I feel that the DIY route is better.

For instance, I recently bought a Lenovo x230. I have Arch Linux on it, along with Firefox and Ratpoison. I get pretty much the same thing as I had ChromeOS: a full-screen web browser in one window and a full-screen terminal in another. This configuration has none of the privacy concerns I have about using a Google product and I don't need Google's permission just to create a user account.

(Backups are a breeze too: just a few dot files. I use Firefox Sync to back up my bookmarks.)

But if the x230 is broken or stolen, it costs ~1k to replace. A new Chromebook is ~200.

I personally love the design of the x230, and am looking to get one myself. The biggest sticking problem for me is price.

If price is an overriding issue, than the Chromebook would be a better choice.

Reply on news.ycombinator.com