DevFestMD 2017

I ditched work today and drove into Baltimore for DevFestMD instead…it was a blast! It took place at Betamore at City Garage, which is a really cool space in Port Covington, just across the Vietnam Veterans Memorial Bridge. There were lots of interesting talks, plus code labs (Go, Kotlin, and more!).

pic of Sarah Jennings

Sarah Jennings (@ThatOtherSarahJ) warned us that the Blockchain is coming for us!

pic of block chain slide

Danny Blue (@dee_bloo) talked about packaging Angular modules.

Mike Talbott (@MikeTalbott) told us about recent advances in augmented reality.

pic of Mike Talbott

His company, BaltiVirtual, is one of the occupants of City Garage and they generously offered tours of their spaces and demos of cool augmented and virtual reality things throughout the day.

Sal Hernandez (@clickclickonsal) expo-unded (Ha! See what I did there?) on React Native.

Chida Sadayappan (@schida) broke down machine learning opportunities.

Gavin Cannizzaro ranted about visibility in program design.

Shannon Foster (@SheCanTech) explained civic tech.

pic of Shannon Foster

At the end, they had a drawing for some cool gadgets. I didn’t win anything, but that’s okay. It was a fun day!

DevFestMD 2017

Autopsy in Xubuntu 17.10

Well, I’m happy to report that I upgraded to Xubuntu 17.10 and Autopsy still works. That’s not surprising (it’s just Java, after all), but it still might be worth mentioning.

And I managed to process some data. At first, I made a dd image of a thumb drive because Autopsy couldn’t access it directly. That worked. It was my Strawberry Perl stick and Autopsy found over 6000 email addresses (presumably all of the module authors and other contributors to Strawberry Perl), but nothing else of interest.

Next, I grabbed a random thumb drive from my backpack and ran Autopsy as root. That way it could process the thumb drive directly, without making an image first. That drive contained a Linux driver, a zip file of all the slides from last year’s Enfuse conference, a tarball containing an older version of dd_rescue, an /etc/hosts file from my home network, a directory of photos from a trip to Ottawa, a PDF of a boarding pass for a plane trip, and an empty directory.

$ ls /media/tim/oylenshpeegul
Ottawa 2013
System Volume Information

Autopsy found 110 email addresses from the zip file and one from the tarball. It found the EXIF data from the photos. The timeline showed a history for dd_rescue going back to the year 2000. It was easy to generate an HTML report

screenshot of Autopsy HTML report

and there were a half dozen other report formats as well. All in all, a pretty good experience! Now, how to write a plugin…

Autopsy in Xubuntu 17.10

Autopsy 4.5 works in Linux!

Ever since Autopsy 3.0 was released and right up through Autopsy 4.4.1, it only worked in Windows. I could get it to compile without error on my Linux machine, but running it would only display the splash screen of the little doggie and then immediately crash.

Screen shot of Autopsy 4.4.1 splash screen in Linux

But yesterday at OSDFCon, my friend Ben said he got the newly released Autopsy 4.5 to compile and run on his Ubuntu 16.04 machine! The weird part was that he said he didn’t do anything different, it just worked.

Today, I tried compiling it on my Xubuntu 17.04 machine and it did indeed work! It wasn’t completely straightforward, so here’s what I did:

First, get Sleuthkit 4.5…

$ cd ~/sleuthkit
$ tar xf ~/Downloads/sleuthkit-sleuthkit-4.5.0.tar.gz 
$ cd sleuthkit-sleuthkit-4.5.0

…and build it. It didn’t have a configure file included, so we’ll need need to run autoconf ourselves.

$ autoreconf --install
$ autoconf
$ ./configure
$ make
$ make check
$ sudo make install

Now we have to build the Java bindings for it.

$ cd bindings/java
$ ant dist-PostgreSQL

But Autopsy will be looking for Tsk_DataModel_PostgreSQL.jar rather than Tsk_DataModel.jar, so we’ll fake one of those.

$ cd dist
$ ln -s Tsk_DataModel.jar Tsk_DataModel_PostgreSQL.jar

Okay, now we’re ready to get and build Autopsy 4.5.

$ cd ~/sleuthkit
$ tar xf ../Downloads/autopsy-autopsy-4.5.0.tar.gz
$ cd autopsy-autopsy-4.5.0
$ export TSK_HOME=$HOME/sleuthkit/sleuthkit-sleuthkit-4.5.0
$ ant

Now when we run it…

$ ant run
Total time: 19 minutes 25 seconds

…we eventually get an Autopsy window!

Screen shot of Autopsy 4.5 in Linux

We can try to create a new case…

Screen shot of Autopsy 4.5 create case

…and process it.

Screen shot of Autopsy 4.5 processing

Hrm. The default settings apparently include things that only work in Windows.

So it’s still pretty aggressively single-platform, but at least it runs without crashing! To be fair, they describe it as “a Windows-based desktop digital forensics tool” right on the tin. But it’s written in Java, so there’s no good reason that it shouldn’t just work everyhere.

Assuming I can get it to actually process some data for me, next I want to try writing a plug-in for it in Clojure. I bounced that idea off of Brian Carrier and Richard Cordovano at OSDFCon yesterday. Both seemed skeptical.

Autopsy 4.5 works in Linux!

Clojure/conj 2017 in Baltimore

pic of 10th anniversary cake

I just got back from Clojure/conj and wow, was it great! I don’t use Clojure professionally, but the conference was right here in Baltimore this year, so I couldn’t pass it up.

Clojure 1.0 came out in 2009, but they’re calling this the 10th anniversary because it had actually gone public a couple of years before that. In fact, one of the highlights of the conj was this morning’s talk by fogus and Chouser, where they reminisced about the whole ten years. This included details from 2007 and 2008 which were new to many of us.

At the party last night, I was able to meet Rich Hickey. I shook his hand and said, “thank you.” I’m not sure if I said anything coherent after that, so he probably thinks I’m an idiot, but I’m grateful for the opportunity nonetheless. He has done so much for programmers everywhere! He didn’t just create Clojure, he challenged the status quo. Object-oriented programming dominated our collective thinking for decades, almost to the exclusion of everything else. Now it’s common to hear people speak about alternatives.

I met lots of other Clojurists from near (Baltimore, Brooklyn, &c.) and far (Toronto, Tokyo, &c.) and every one was super nice. I’m not sure if programming Clojure makes you a nicer person or if nice people are just attracted to Clojure, but either way it made for a very pleasant conference.

Clojure/conj 2017 in Baltimore

Command-not-found in Debian

pic of fortune cookie

I wrote this up years ago, but with the demise of CrunchBang those bits are rotting away. The URL is still good, but my post is mostly gone. I just installed Debian Stretch on my Mom’s old MacBook and the issue is still there, so here it is again.

If you invoke a command that doesn’t exist, most shells will simply tell you so.

$ play
play: command not found

Ubuntu has a utility called command-not-found. If you invoke a command that is not installed, but is available, it will tell you how to install it.

$ play
The program 'play' is currently not installed. You can install it by typing:
sudo apt install play


This command is now available in other Debian systems too, including the latest stable: stretch.

sudo apt install command-not-found
sudo apt update
sudo update-command-not-found

But it doesn’t quite work right, as is.

$ play
The program 'play' is currently not installed. To run 'play'
please ask your administrator to install package 'play'

But I am the administrator! Why doesn’t it think so? It seems that Ubuntu uses different groups than Debian. In particular, command-not-found is looking for membership in group “admin”, but Debian doesn’t use that. We want it to check for membership in group “sudo” instead. We can fix that!

sudoedit /usr/share/command-not-found/CommandNotFound/
# change "admin" to "sudo" on line 93

Most programs transition from Debian to Ubuntu. This one transitioned the other way. I guess the trip isn’t as smooth, since this was years ago and it’s still not fixed (indeed, it’s still line 93). I think this affects at least Debian wheezy, jessie, and stretch. It looks like it’s fixed on github and in Ubuntu (checks for either “admin” or “sudo”), but has not been backported to Debian yet.

Command-not-found in Debian

Free Pascal on Hanselminutes!

Hey, they mentioned Free Pascal on Hanselminutes! Part of a fascinating interview with Ariya Hidayat, the author of PhantomJS among other things.

I used Pascal in my CS-101 class, some thirty-mumble years ago. I’ve often said, I think it’s a really good language for that. For practical reasons, it lost out to C in industry. But for teaching, I think it’s perfect. CS-101 classes eventually replaced Pascal with C++. I think that was a mistake. Not because I think C++ is a bad language, but because I think it’s not as good for the things we want to teach in CS-101. Later, CS-101 classes replaced C++ with Java. I think that was an even bigger mistake. If you took CS-101 in Java, you probably have to go back and learn all sorts of things. In any case, I think it’s misguided to try to use the trendiest language in industry to teach CS-101. We’re not training people to be software engineers, we’re teaching them computer science. It’s the concepts, not the particulars. It’s not important that it be done in the language that currently has a lot of job openings. If we do it right, students will have no trouble switching to another language.

Anyway, on my Xubuntu machine, installing Free Pascal was just a matter of

sudo apt install fp-compiler

And away we go! Here’s “hello world”…

program Hello;
  writeln ('Hello, World!')

We can compile it…

pc hello.p

…and run it

$ ./hello
Hello, World!

As I said, I think Pascal is still perfect for teaching, but I don’t think about it for writing GUIs and such. It was nice to hear that Free Pascal has a few tricks up its sleeve!

Free Pascal on Hanselminutes!

Epoch fail, Clojure edition

A while back, I wrote about doing epoch calculations in Elixir. Recently, I tried the same sort of thing in Clojure. Since Clojure sits on top of Java, I was not optimistic. Historically, Java has not had a good story to tell when it comes to date-time manipulation. But Java 1.8 added a new java.time package, so maybe it’s better now?

Clojure has clj-time, which wraps joda-time. Joda Time is the third-party library that most Java folks used before version 1.8 (and still do, I guess, if they’re stuck on 1.7 or 1.6 for some reason). Perhaps clj-time will move to java.time eventually, but for now at least they are still on joda-time. Maybe it would have been more sensible for me to just have used clj-time, but I wanted to use the java.time package.

I discovered there is a Clojure java-time (with a dash) that wraps java.time (with a period) and I started out doing that, but eventually abandoned it. When I got to the google-calendar calculation, I needed the .toInstant method, and java-time didn’t seem to supply it.

So, I changed to using java.time directly (if you look back in the git history of Epochs-clojure, you can see where I switched). Since Clojure’s Java interop is so seamless, it turned out pretty nice! Here is that google-calendar portion:

(defn google-calendar
  "Google Calendar time seems to count 32-day months from the day
  before the Unix epoch. @noppers worked out how to do this."
  (let [seconds-per-day (* 24 60 60)
        utc (java.time.ZoneOffset/UTC)
        n-days (quot n seconds-per-day)
        n-seconds (rem n seconds-per-day)
        g-months (quot n-days 32)
        g-days (rem n-days 32)]
    (-> (java.time.LocalDateTime/ofEpochSecond (- seconds-per-day) 0 utc)
        (.plusDays g-days)
        (.plusMonths g-months)
        (.toInstant utc)
        (.plusSeconds n-seconds))))

Java time has Instants, which are the naive date-times that I want to do everything with. Similar to Elixir, java.time won’t let me add days or months to an Instant. So I create a LocalDateTime, add the days and months, then convert to an Instant and add the seconds.

Not bad. Not as nice as the Perl version, but better than the Elixir version. At least java.time gives me the .plusMonths method I need, even if it does make me choose a timezone to get it. And, remarkably, it’s just Java. I usually can’t bear to look at Java code, but Clojure makes it almost pretty.

I look forward to clj-time or java-time supplying more Clojure-like access to java.time in the future. But in the meantime, accessing it directly isn’t that bad!

(Update: 2017-08-06) I went to see if I could add .toInstant support for LocalDateTimes in java-time. I figured rather than just complain, I’d send a pull request. In so doing, I discovered it is already there! If I have a LocalDateTime in ldt, then this Java interop code

(.toInstant ldt java.time.ZoneOffset/UTC)

can be written as this java-time code

(instant ldt (zone-offset 0))

I think I’m going to leave Epochs-clojure as Java interop for now, but maybe I’ll switch back to java-time in the future if things start to get too Java-y.

Epoch fail, Clojure edition