Via the ReverseEngineering subreddit I found that vim's built in :X encryption mode can be pretty easily broken. I didn't know that vim had anything built in to encrypt files, in hindsight I should have expected some functionality.

Looking into the vim documentation on on Encryption shows that most of these methods aren't recommended for use. It also looks really easy to accidentally destroy a file using vim. If you do not decrypt the correctly you get a vim buffer filed with encrypted noise, if you save that buffer you destroy the original file.

I have been using vimwiki in a git repo since August last year. Vimwiki is a really simple markdown style wiki, the features are really limited. There is some markup, links and that is all. It has been filling all of my needs perfectly. I would like to be able to encrypt the wiki files so I could have a little more peace of mind, but with a little searching I haven't found anything that has the utility I need.

I could write something myself that worked well with both git and vimwiki, but I don't really want to subject my personal files to my own bugs. If you know of a solution to encrypting files in git repo or integrating with vimwiki that would be really helpful.

For some reason I have been recording a lot of audio on my desktop recently. I also saw a conversation in irc about how to simply record audio from a microphone on FreeBSD.

I hoped I was going to find a super simple OpenBSD style solution to capturing samples, but I wasn't able to dig anything out. I did play with cat for a little while, but nothing useful came from it.

Audacity is the tool I have been using to record long sessions the most. Audacity is now probably the foss standard for doing audio editing/production and it has been really stable for me. On FreeBSD it has been rock solid so far if a little heavy weight.

ffmpeg is an audio and video swiss army knife and can be used to capture video from webcams and audio from capture devices. The only issue I have had with ffmpeg on FreeBSD is that lame support is not built into the default packages.

ffmpeg can be used to caputure audio from a source:

ffmpeg -f oss -i /dev/dsp -vn -ab 128k test.wav

Sox is the ultimate tool for handling audio, a long with the two front ends play and rec you can do most operations on an audio stream. Sox can built with codec support for a ton of formats. It is quite simple to use sox to convert different bit formats of sdr capture files with sox.

Rec can be used to caputure audio from a source:

rec -c 2 test.wav

Yakamo and I have started a podcast , the first episode was released yesterday. The website is still very simple and I don't think there is an rss feed setup yet. But, we have managed to put out the first episode and the second episode is lined up to be released on Monday.

Give it a listen if you like podcasts, any feed back should be directed to stuff@yakamo.org or /dev/null. Thats where I send your emails anyway.

Great news today about David Miranda's Case , but I can't help but feel down with the direction of the country. I can see British law being deemed incompatible with the ECHR being used to strengthen arguments against being a signatory to ECHR and part of the EU.

At home we have GCHQ dismantling secure communications at every turn. The low price of oil is causing a down turn up here and it doesn't look like there is bright future. Sometimes it is hard to stay positive when you let the real world seep in.

While I sit numbly at my desk I like to restlessly fumble with anything at hand. This week it has been this awesome mind bending deck of cards . I have already had many visitors complain my cards are misprinted and hurt their head, this real world glitch is doing well. The glitch_art sub reddit contains many more examples of images like these. None quite as satisfying as holding these 'broken' playing cards.

The Raspberry Pi page on the FreeBSD Wiki links to a blogpost about setting up xorg on the Pi. That post was written back in 2013 and most of the information there seems to be out of date.

I set up X on a Pi at the end of December 2015, this information is up to date for r292413. pkg is now available on arm images so there is no need to build everything from ports, considering tools like tmux could take 6 hours to build on the pi itself this is a huge improvement. I installed the following packages to get X up and running on the Pi:

# pkg install xorg xf86-video-scfb i3

The Pi isn't able to auto detect the X configuration, I looked for a while for a config that would work. Eventually I dug the following one from a mailing list post. Place the following into /etc/xorg.conf:

Section "Device"
    Identifier "Generic FB"
    Driver "scfb"
EndSection

Section "Screen"
    Identifier "Screen"
    Device "Generic FB"
    Monitor "Monitor"
    SubSection "Display"
        Depth 16 #24 32
    EndSubsection
EndSection

With a minimal .xinitrc I was then able to start an X server with i3:

exec i3