Oct 272011

I knew Linux had capability bits, but I had never used them until a friend figured out a way to run wireshark as a normal user and still capture packets. For a Network Engineer, this is really handy. I think distributions should make this standard.

sudo groupadd wireshark
sudo usermod -a -G wireshark YOUR_USER_NAME
sudo chgrp wireshark /usr/bin/dumpcap
sudo chmod 750 /usr/bin/dumpcap
sudo setcap cap_net_raw,cap_net_admin=eip /usr/bin/dumpcap
sudo getcap /usr/bin/dumpcap

The shell snippet is really trimmed down. For more details, check out tavshed’s blog post.

 Posted by at 10:41
Jul 192011

A friend offered to take me dirt biking last weekend. After battling the flood road closures, we finally got there and it was a blast. After killing the engine about 30 times and getting drenched in my own sweat, we called it quits at about 1pm. That was about right too, the 95F / 80% humidity was getting to be a bit much. I would have to guess that we each drank about a gallon of water.

Continue reading »

 Posted by at 16:29
Jul 102011
Brandon making some aluminum ingots.

Did some aluminum casting with Dave and Brandon a couple weekends ago (and just fixed media upload on my blog, hence the post delay). We learned a couple of important lessons about letting our furnace get too hot as well as avoiding casting on hot+humid days. Dave already has distilled down the photos and written a bit about it, so read more on Dave’s Tech Blog.

 Posted by at 16:01
May 152011

I’ve been doing a lot with GWT Generators work and fun. Generators are Google’s answer to not having Java’s runtime reflection. The big difference is that they run at compile time and have to generate an implementation for an interface or a superclass to use in a class’s place. This is all really cool (also kind of a pain to debug), but it’s not why I’m here to rant. I’m here for logging.

Admittedly, good logging is important for debugging, especially postmortem debugging. Providing context for the message, catching errors close to where they happen in code, logging in a format that can be parsed (JSON anyone?), etc. — These are all things that are good to get right at the beginning of a project. So why do so many projects get it wrong? I think part of it has to do with the fact that logging introduces code people see as tedious and not very useful. With time and enough pain, people overcome their lazy tendencies to not log or log poorly. I think we can do better and make logging as easy as commenting code.

Mozilla Rust has a really good idea to provide logging in the language itself. Chew on that while I talk about TreeLogger, I’ll circle back around to this in a bit.

So what does GWT’s TreeLogger get right? Context. Its notion of branching a logger makes it really easy to provide context when something goes wrong without having to drag that context with you around the call stack and then format it every time you want to log something. Consider this code:

void foo(TreeLogger logger, String user) {
  TreeLogger sub = logger.branch(TRACE, "Handling request for user=" + user);
void bar(TreeLogger logger) {
  try { ... }
  catch (DBException err) {
    logger.log(ERROR, "Database error: " + err);
    throw new UnableToBarException(err);

Let’s say we’re running with log level of WARN. Under normal circumstances, nothing is logged here. However, when the DBException is thrown, both the TRACE and ERROR message will show up. The important bit here is that TRACE message provides some vital context (maybe the ‘user’ was Little Bobby Tables), but it will only show up in the log when that context is needed. In other words, TreeLogger makes sure that all the context information back to the root is shown when you need it. You get a full view of the logging stack down to the error.

What this means is that when you’re at the leaf functions in your call stack and something goes wrong, you don’t have to worry about digging around for bits of context to put into your error or exception, the logger already knows about them and will log them when you write the context when you provide a severe enough message to log. This is extremely useful for programs with deep call stacks — like compilers.

Now for the downsides:

  1. Dragging the TreeLogger around the stack with you is annoying.
  2. There’s some memory overhead to tracking all these messages until we know they’re not needed anymore.
  3. GWT’s compiler is single threaded, applying this to concurrent/threaded applications would be tricky, but not unsolvable.

#1 is the real tough one to solve with current language constructs. You might be able to maintain some global state with thread local storage, but this seems messy. This where Rust comes back in. Rust has built in logging. It’s not this sophisticated, but I also don’t want my language doing something this sophisticated. Sophisticated things tend to change over time as we find out they either don’t work or something works better. I’d rather sophisticated things in my standard library with the language providing the construct for implementing it. So what can a language do to help out?

What if a language permitted implicit passing of values through the call stack? Not only would this be useful for logging, but it could be useful for passing around other objects like GeneratorContexts, DB transaction/session objects, factories, or other objects that tend to follow the execution stack around.

Here’s my unimaginative code example with what I’d like to see for implicit value passing.

static void main(String[] args) {
  // Initial injection
  @Pass(TreeLogger.create(level=INFO)) {
    foo(" ';DROP ALL TABLES;' ");
@ImplicitPass(TreeLogger log)
void foo(String user) {
  // Based on bar's @ImplicitPass signature
  // Branch the logger and pass it along
  @log.branch(TRACE, "Handling request for user=" + user)
  // Or branch off with multiple calls.
  // Similar to python's "with" statement.
  @Pass(log.branch(TRACE, "Doing a bunch of things")) {
  // This would again pass the original, unbranched logger
@ImplicitPass(TreeLogger log)
void bar() {
  try { ... }
  catch (DBException err) {
    log.log(ERROR, "Database error: " + error);
    throw new UnableToBarException(err);

Now imagine that with 10 methods on the stack between main() and bar() that don’t even know a TreeLogger is being passed.

It certainly needs more thought — language masters aren’t likely to put something that bizarre into the grammar and semantics. I know one thing, I’d write a lot more log statements if I didn’t have to clutter my method calls with another parameter. If there was a library that got rid of that aspect while handling branching, I’d definitely investigate using it for pretty much everything I do.

 Posted by at 13:56