Is this thing on?
Looks like mobile blogging is a go.
Is this thing on?
Looks like mobile blogging is a go.
It’s been two weeks since I posted, which is a bit embarassing. I’ve been pretty busy with the new job, though, and generally sticking to Twitter to get the word out about how I’m doing.
The quick version is: the Project Kenai team is turning out to be just about as good a group to work with as I could hope for. We’ve got enough to do to keep things from getting boring, but it’s the good kind of work: interesting + challenging, but nothing that feels like a death march. Plus, every time I fire up an editor to look at a new piece of code and see the GPL license in the header comments, I feel a little better about the company as a whole. Being somewhere that open source is the default (rather than a special case for which you have to lobby) is a pretty cool feeling for a OSS nerd like me.
Otherwise, things are pretty normal. As my family and friends all give in to the gravitational pull of SE Portland, I also find that my social life is less and less about going out, and more about staying in for social meals + conversation, which suits me just fine, especially in the winter.
That’s it for now. Expect more on the technical side of the work I’m doing after Christmas, when I have some time to write up my impressions of doing JRuby on Rails, and working in a heterogenous Solaris/Linux/OS X environment.
Those who have followed this blog for a while (or have met me in person) already know that I’m a fan of home-made charcuterie: bacon, sausage, ham, pastrami, etc. Over the last few months, the quality and consistency of said DIY projects has gone up considerably from our initial wonderful-but-inconsistent results.
Behold:
While I didn’t actually prepare the cure for either of these batches, I did take at least my share of time at the smoker to insure their juicy-salty-goodness.
There’s been an persistent blog-wank-fest making the rounds over the last few weeks about the state of the Ruby community: whether it’s become more or less “fun”, “creative”, etc. I’m not going to reward any of the participants with a link, but I do offer the following balm if you, like me, are a bit sick of hearing about it:
%w(open-uri rss resolv uri rubygems hpricot).each {|lib| require lib }
blog_url = ARGV.shift
blog_hdoc = Hpricot.parse(open(blog_url))
rss_links = blog_hdoc / :head / 'link[@type="application/rss+xml"]'
feed_rss = RSS::Parser.parse(rss_links.first['href'])
rants = feed_rss.items.select {|i| t = i.title; t =~ /rant/i && t =~ /ruby/i }
if rants.empty?
puts "Okay, you get a pass."
else
puts "Bad blogger! No biscuit!"
hostname = URI.parse(blog_url).host
ip_addr = Resolv.getaddress(hostname)
`sudo route add -host #{hostname} gw 127.0.0.1`
end
(via Fredrick Jean)
Sometimes you have a group of users who need to run certain commands on a server, and no others. It’s not necessarily that you don’t trust them. The point is simply that they don’t need a full-blown shell account, and you’re understandably reluctant to give it to them.
There are countless ways to set up a restricted account that can use only certain commands, but most of them are either extremely special-purpose, or rather difficult to set up. (Locking down SSH sessions inside a chroot jail, for example, requires almost as work as just setting up a dedicated virtual machine for your untrusted users.)
Furthermore, none of the existing solutions were written by me, to address exactly the needs I have for such a “sandbox” environment. Most notably, I don’t want users to even have to remember which commands are available to them. In many cases, they may only be using these tools every few months, and remembering cryptic UNIX-y command paths and syntax is hard enough even when you use something every day.
And so, I give you menush, a simple shell replacement which presents users with a list of available commands from which the user may choose. It loops until the user exits via the menu (or uses Ctrl-C/Ctrl-D to end the session).
To set it up on your own server, you’ll need to copy the file into a known location (say, /usr/local/sbin), then add a line to your /etc/shells file pointing to it. For each user you want to lock into a sandbox, edit their password entry using vipw (or your passwd editing method of choice) and change the last field from /bin/bash or similar to the full path to menush.
Then, create the directory /etc/menush, and write your default menu file (/etc/menush/__default__). On startup, menush will look in that directory for a file with the same name as the user being logged in; if that file is absent, the default will be loaded instead. The format for the menu files is documented in the README, but it’s just a YAML file. (Also, bonus points for the first person to correctly identify the gaping security hole in the provided example.)
The code is written in a fairly portable, POSIX-y style, so it should work on Linux, BSD, or OS X. Feel free to send me suggestions, pull requests, or rants about the horrible security holes I left because I banged this whole thing out in like two hours and then spent a bunch of time blogging about it instead of reviewing my own code.
Things have been far too serious around here lately. Politics, smartphones, and programming are all well and good, but there’s been a notable lack of food pr0n in my posts since Twitter took over my impulse-blogging.
Well, no more. Look upon the awesome power of the “Heart Attack” sandwich, as proudly served during the Sunday brunch at the family BBQ restaurant:
You can click through to the Flickr page to see notes breaking down all the constituent parts, but suffice to say, everything on that sandwich, right down to the bun itself, is fried.
It was so good. I think I’ll probably only be able to eat one about once a year, but I will cherish that day.
After many frustrating delays, I finally managed to get my new G1 handset up and running on my T-Mobile account. It is, in short, a quirky but highly-promising device, and unless some major new deficiency rears its head in the coming days, I will count myself a happy Android user for some time to come.
I’ve been a BlackBerry user for the last year, and have also spent a decent amount of time messing with friends’ iPhones since the original 1st-gen release. In terms of polish and consistency, the Android UI lies somewhere between these two poles: you need to do a bit more context-switching in normal app operation than is required on the iPhone, but 3rd-party apps aren’t the unpredictable crapfest they are on the CrackBerry.
Performance is also somewhere between these two — while the entire system is quite stable, and response to hardware events (button presses, incoming calls, etc.) is good, some of the apps could obviously benefit from further performance optimization, as they tend to get bogged down on screens with a lot of redraw, or fail to offload as much processing into background tasks as they should to maintain UI responsiveness.
The keyboard is an almost-unmixed blessing. I’ve become a bit too accustomed to the layout of my BB Curve, so I’m not quite back to full “touch typing” mode on the G1, but I’m already far more proficient and confident in my typing than I’ve been able to get on the iPhone touchpad. Having the ability to close the keyboard and use the entire screen for text, images, or video is a definite win over the split-face Blackberry layout, as I’m one of those masochists who actually tends to read long-format text (blog posts, Wikipedia entries, and email) on my mobile device on a regular basis.
The Android platform application ecosystem is obviously far less mature and complete than the iPhone App Store. While I have a decent Twitter app (Twidroid) and SSH client (ConnectBot), there aren’t many compelling games or productivity apps available yet. Of course, I’m a coder, so there’s one obvious solution for this: write the damn things myself. Once things settle down a bit with the new job, I’m hoping to have some time to do just that.
Overall, though, I think the most interesting thing about Android is not what it offers in terms of competition for Apple, Microsoft, and Nokia (though that is a compelling argument in and of itself). What I see foreshadowed when poking around in this system is an absolutely kick-ass netbook or non-real-time embedded operating system. Given the performance Android is able to maintain on the ARM-based G1 hardware, I think it would scream on an Atom-based ultraportable like the ones Wind and Asus are manufacturing these days, especially if both a touchscreen and usably-large QWERTY keyboard were available on the system.
Android may not do much to stop Apple’s ascendence to smartphone domination, but it does offer a glimpse of how a truly usable, efficient Linux desktop environment might work.
The election is over. We (meaning the progressive youth vote) won. Time to lean back, relax, and enjoy the victory, right?
Wrong.
Now that we’ve elected Obama, increased the Democratic majority in the House and Senate, and (in Oregon, at least) added a bunch of smart, young, enthusiastic new legislators, it is incumbent upon the electorate to help set the policy agenda. We can’t afford to let our current momentum die down one iota if we want to insure that the promises of the campaign season are actually fulfilled.
For myself, that means moving into a “citizen lobbyist” role. I’ve started the groundwork for that (along with a few of my like-minded friends) with Policy in Motion, but we haven’t yet completely figured out how to sip from the massive firehose that is an active legislative body.
I definitely believe that having one party control most major offices + both legislative bodies in the state means that transparency and access to information will be especially critical. Working towards open government, using both technological and volunteer-driven tools, is going to be a huge part of that. (And it just so happens to be part of Obama’s transitional agenda, as well.)
Regardless of the issues we choose, our government is not magically going to serve us well, simply because we voted in the right column on Nov. 4th.
Update: Digby seems to agree, at least in principal.
Breaking news! The T-Mobile G1 has been jailbroken! Wired “broke” the story here. I was briefly interested, if only because I wasn’t aware jailbreaking was needed on an Android device to get full local access, but apparently, the fact that you have to download and run a local terminal emulator on the handset means that only 1337 h4x0rrz should attempt this epic hack.
The gist? Run an instance of telnetd, then find out the phone’s WiFi IP address, and connect from your desktop machine. Good God, what will those crafty hackers think of next!
Seriously, though, I just love how this combines an obvious chain of Linux commands with a total lack of warning about the fact that this little root-shell backdoor is completely unprotected, and will in fact give everyone else on your wireless network the same superuser access to the phone that you just set up for yourself.
Want to give a recent G1 “jailbreaker” fits? Do a quick nmap scan for devices with port 22 open on the local coffee shop network, telnet in, and go nuts — restart core UI services, disable the cell modem, or stuff a bunch of porn in their personal image folder.