Kurt's Weblog

I had never really used pkg-config before today. Turns out to be reasonably simple. I read through the man page an here is me messing with it.

type -a pkg-config
pkg-config is /sw/bin/pkg-config

dpkg -S /sw/bin/pkg-config
pkgconfig: /sw/bin/pkg-config

fink list -i pkgconfig | grep -v virtual
 i  pkgconfig                0.25-2  Manager for library compile/link flags

pkg-config --help
pkg-config --list-all
pkg-config --list-all | wc -l
    300
pkg-config --list-all | head -4
gstreamer-tag-0.10 GStreamer Tag Library - Tag base classes and helper functions
libmetalink libmetalink - Metalink library
xf86rushproto XF86RushProto - XF86Rush extension headers
fontsproto FontsProto - Fonts extension headers

pkg-config x11 && echo 'yes'
yes

pkg-config missing && echo 'yes'
pkg-config missing || echo 'do not have "missing"'
do not have "missing"

pkg-config --print-variables x11
xthreadlib
exec_prefix
prefix
includedir
libdir

pkg-config --print-provides x11
x11 = 1.6.2

pkg-config --print-requires x11
xproto
kbproto

pkg-config --cflags x11
-I/opt/X11/include

pkg-config --libs x11
-L/opt/X11/lib -lX11

This is the first of a series of posts I hope to write.

https://xkcd.com/927/



See also: Toils of AIS by Eric S. Raymond and Kurt Schwehr.

I am frustrated that each sub-community of marine related sensors has their own data formats for raw logging. Even worse, each vendor has their own format (with many different messages as they innovate over the years). Those formats require a wide range of support libraries and often not easily extensible. We have formats for multibeam sonars, seismic systems, acoustic recorders (hydro and geo-phones), seismic stations (really just a 3-axis, 3-channel geo-phone), lidar, ships' and GPS sensors, magnetometers, radar, grids, images, vectors, metadata, and more. Those formats treat data in other formats as orthogonal. Most of encodings used for those formats are not even described in the Wikipedia article on Comparison of data serialization formats. Worse yet, some key standards are behind paywalls, which greatly hampers adoption (e.g. try pricing all the ISO standards related to metadata). On top of that, some of these standards are so confusing that it is nearly impossible to create conformant data streams.

In this series, I will be arguing that the sonar community needs to get away from systems like the Generic Sensor Format (gsf) and move to a unified machine and human readable specification system for the data stream at the lower levels. I will be pushing for using ProtoBuffers (protobuf). Protobufs were created by Google and are heavily used within Google. I have a fair bit of experience with them as I have been working for Google for the last 2 years. However, there are other formats, such as BSON, that could work. I do feel like I'm repeating myself with this. I argued for a custom XML representation of AIS messages starting in 2006 and declaring defeat in 2010 as the AIS community opted to stick with their amazingly terrible status quo.

An additional concern is that people have proposed formats or tools that are either only used in a small community, are not tested across a number of key programming languages or revert to defining the raw bit level packaging such that the software engineers of every piece of code that will touch this format will have to understand the low level details.

In this first post, I'd like to explore the use cases. What are the range of problems that we are trying to solve? I'm attempting to think about 50 or so years into the future, a near impossible task, but some things will most certainly be correct. Storage of data will become more affordable in terms of cost, power required, volume/mass required. Compute power for an available budget will increase. Sensors will become more affordable and their diversity will increase.

I have not had a chance to flush out these use cases, but I do not want to wait any longer to get this starter post on line.

* Single beam echo sounder from a ship

* Multibeam echo sounder ship

* Multi-channel seismic vessel

* Lidar from an aircraft

* An AUV, Glider, Argos style device with IMU

* Super cheap land sensor networks without GPS

* ADCP mounted on the sea floor

- without external intervention for long periods - event based time corrections

* An array of sea floor devices

- down for an extended period with slow intermittent acoustic connections

* Ping editing a multibeam sonar

* Post processing to get time and location

* Post collection indexing to allow fast access

* Later splicing of multiple platforms into a single stream

- inlining of forward and backwards index messages

* Non-survey ship underway

For my desktop, I have linux (I gave up on macs for the desktop), but for my mobile devices, I've been using Mac devices. Mac OSX is really frustrating at a low level compared to Linux, but I like the hardware (minus the lack of easily fixing). Here is what I do to survive in the Mac OS X world. I've given up Microsoft Office, Photoshop and Illustrator now that I'm not a full time professor making posters and living in the painful UNH IT environment. I used to do this in MediaWiki format inside of CCOM, but I don't want to have to tunnel into CCOM for this and I'd like it to get more eyeballs. I rarely got feedback from others, so why would I keep it closed? I will be leaving out stuff specific to the places I work in a lot of cases, but I will share a bit when it doesn't expose confidential business practices.

At the time of this post, the document is hardly even a Work-In-Progress (WIP).

Mac OSX 10.9 Setup

AutoAwesome on G+ is often just cheesy, but I really like this one.