This tumblog is now retired in favor of our G+ page. Just search there for “Firepear” and there we’ll be.
The command to make the Chrome OS filesystem writable has changed. It’s now:
chronos@localhost / $ sudo /usr/share/vboot/bin/make_dev_ssd.sh --remove_rootfs_verification --partitions 4
So the whole process now boils down to:
Why they persist in using a 12pt antialiased font, I’ll never know. It looks like crap.
Just some corrections and addenda from the last post.
Got my Cr-48 today. Immediately set about poking some of the things I’d been poking at in the Chromium source repository.
First things first, you need to root the device and make its filesystem readable.
'echo "chronos:$(openssl passwd -1)" > /mnt/stateful_partition/etc/devmode.passwd’ to set a password for that user (makes sudo require a password, everytime)'sudo /usr/share/vboot/bin/make_dev_ssd.sh --remove_rootfs_verification' to make the fs writableAt this point, the machine is modifiable, but there is no editor installed. Not even ed. To get one, you’re going to need another machine.
First, grab a simple editor with no deps other than, perhaps, ncurses. I prefer mg; the guy I cribbed this process from prefers nano. The Arch linux packages are very basic and good choices.
Download one of those to your other machine, then
xz -d FILE’)Now you can actualy go about modifying the system. All I’ve done so far is set up a hosts file, an ssh config, and (most interestingly), modified the settings of the terminal.
When you do C-M-t in ChromeOS, an executable named cros-term is run. This isn’t a binary, but is just a one-line shell script that fires off a urxvt with a lot of command-line options. I changed mine to this:
exec urxvt \ -fn 'xft:DejaVu Sans Mono:pixelsize=10:antialias=false' \ -fb 'xft:DejaVu Sans Mono:pixelsize=10:antialias=false' \ -tn xterm-256color -bg black -fg lightgrey -cr green +sb \ -e /bin/bash
The changes from the original are as follows:
Now when I invoke a terminal, I drop straight into a regular login session as chronos.
Confusingly, I don’t end up in chronos’s homedir. I end up sitting in /, though typing ‘cd’ will take me to my homedir. Said homedir, by the way, is not /home/chronos, but /home/chronos/user. There is an issue with ssh, which I suspect have something to do with this nonstandard state of affairs.
ssh on ChromeOS keeps the keys of known hosts exactly where you expect (~/.ssh/known_hosts), but it ignores ~/.ssh/config if you create it. According to the ssh_config manpage, ~/.ssh/config should be parsed before the system configuration, and it also says that ~/.ssh/known_hosts is, as we all know, the default host key file. But in ChromeOS’s system ssh config, the location of known_hosts is set explicitly. And due to user config being parsed before system config (in an unusual twist), it’s not possible to edit the system config to point at chronos’s ssh config file.
Why /home/chronos/user/.ssh/config isn’t being resolved by ssh as ~/.ssh/config is a question I can’t yet answer.
I’m very sleepy. More later.
I do. I think about it every day. I’ve more-or-less thought about it every day since 2002.
Today I did some housekeeping on its repo, to make way for the stuff which will come after Roundabout.
What sucks about finally giving in; about finally silencing that voice in the back of your head who tells you that it’s downright unreasonable to write so much software from scratch, and that if you just keep looking you’ll find something good enough that almost does what you need; what sucks about letting that go and deciding “Fuck it; no; no one else is ever going to write the tools I want to have, so that I can get done the things I want to get done”; what sucks about that, is this:
You need non-sucky software to support the writing of non-sucky software.
Either that, or you need a lot of quadrille paper. At least I do. And my handwriting also sucks.
Roundabout development has been moving very nicely over the past 2 weeks. I think it’s time for a temporary hold, though.
I need to generate a checklist from the spec, so that I can… well, you know what a checklist is for. And there’s a lot of things to be checked here. It’ll keep things much smoother once it’s done.
In the future, I plan to have software support for this (as a Tamarind app, likely), so that my project management is my dev notes is my spec is my checklist. So much work to do…
One further benefit of Carrot using Roundabout is that it will be possible to have amazingly specific and detailed error messages. Anytime an error is found in document processing, it will be easy to communicate that there was an error, what sort of error it was, where it happened, why it happened, and the full context of it happening.
Basically, I’ll be able to do stack traces of documents when a problem is found. I was really glad to realize this, because LLVM’s error messages make me jealous. They are the best (for now).
As I’m working on Roundabout and learning Go, new possibilities for Carrot keep springing into my mind. This is refreshing and relaxing, because for a long time I was concerned (it might be fair to say “obsessed”) with convincing myself that I was not simply, pointlessly reinventing the wheel — which is to say that I was simply reimplementing TeX with different markup characters. Eventually I quit caring about this.
These days I’m starting to see applications for Carrot-the-engine all over the place. Much as Emacs is a Lisp engine with an editor wrapped around it by default, Carrot will be a system for turning semi-structured text into structured data and manipulating it. So at the worst, I’ll be reimplementing TeX and XML and their respective toolchains :)
Anyway, I’m starting to see uses in the markup domain for things other than documents, like photo gallery generation (because I think I’m starting to swing back from “just let online services handle everything”), and serialization (it occurred to me that I could represent the thesaurus corpus as a Carrot document, both inside the machine for doing ops on it and outside the machine as a release format other than SQLite dump).
And this is without getting into the effects of the slightly-longer-range plans for a Carrot implementation which is more of a compiler-as-a-service, acting as a backend to other apps.
So yeah. Good stuff ahead.
I think I’m really digging on Go (the language, not the game). It’s significantly more interesting than Google — always bad at telling people why their stuff is awesome/interesting — made it sound at public release, when they basically positioned it as “C, only not, and it compiles sooooo fast!”
If I make it through the introductory material, I’ll synthesize a trip report from my notes. Until then I’ll just make an analogy:
Objective C is Apple’s rewrite of C to make it feasible for people who didn’t grow up writing device drivers in C to create modern, powerful applications. Go is Google’s rewrite of C to do the same thing for people want to write systems software.