Recently I acquired a Monoprice Select Mini v2 3D Printer and I’ve been having a great time learning and experimenting with 3D Printing on it. It’s a wonderful little printer that is inexpensive (At around $220), puts out great quality prints, it’s easy to work with and to work on. That said, it has a fatal flaw in its design: The wiring for the bed heater and thermistor is routed along a horrible path that lets the wires rub against the gears moving the bed, and these two pairs of wires are zip tied in a place that makes them kink as the bed moves. Between these two problems, the wiring is prone to short, fray, or break entirely. Unsurprisingly, I had to repair mine, read on to find how how.
My FreeBSD desktop workstation has been on 8.x since I built it just over two years ago. When I made it, I bought two 1TB HDDs and setup a RAID-1 volume with gmirror, following what was at the time the recommended instructions from the FreeBSD Handbook. After delaying the upgrade to 9.x repeatedly over the last several months I finally decided to give it a try after 9.1-RC1 was announced. Read on for how it went wrong, since FreeBSD 9.x more correctly handles partition integrity checks.
According to discussions on the FreeBSD-stable list, CVS support for FreeBSD sources is not just dying, it’s practically dead. (I’ll skip over the jokes about Netcraft confirming it…) So I setup an SVN mirror of the FreeBSD base and ports repositories and documented the process a little. I did this mainly because there are a lot of servers in two locations that need frequent access to the base and ports repositories, and there are currently cvsup mirrors running (one at each place) to keep the load off the upstream servers and for faster local access.
The other day I found that the Tweetdeck Chrome extension worked on FreeBSD (With Chromium 18.0.1025.142, probably earlier as well). I had been missing a full GUI to monitor some things on Twitter on my FreeBSD box. I have a much larger monitor on my FreeBSD workstation than on my Windows laptop, so I’d rather use the extra screen space there to keep a search column up (For pfSense, mainly).
Seeing as I was one of the lucky few to get their hands on an Asus Transformer Prime so soon, a couple people have asked me to write up a short review of the device.
Having never possessed a tablet before I do not have any baseline for comparison so there may be some skew in my opinions due to that fact. Some of my positives and negatives may be true for all tablets — or at least those of this size/form factor.
A quick note that I moved my site from an aging server to a fast VM at a data center, and in the process gained not only a much newer version of FreeBSD, but also native IPv6 connectivity. A few days too late for World IPv6 Day, but it’s still great to see IPv6 happening finally.
I’ve also got IPv6 going at home using he.net’s tunnelbroker service from my home router running pfSense 2.0’s IPv6 branch. All things considered it’s pretty easy. All of my PCs in the house are using IPv6 happily, even my Droid X running Gingerbread is using IPv6 without problems.
It’s no secret that I work with pfSense a lot, and a while back support was added to pfSense for Growl alerts over the network. Tired of being jealous of everyone else with a Mac (and even Windows!) who could get growl alerts, and not having any growl servers available for FreeBSD, I decided to dive in a little deeper.
After searches for a stand-alone growl server came up empty, I started looking for anyone who had implemented a server in another language like python, ruby or perl. Lo and behold, I found one in python! Just one problem: I use KDE, and that one was for gnome/dbus. Luckily the code is quite easy to follow and it was easy to modify. The kdialog program in KDE already supports growl style alerts by using kdialog –passivepopup, so it was just a matter of ripping out the gnome/dbus bits and replacing them with a call to kdialog.
Without further ado, I present: kdegrowl.py:
On a mail filter I maintain, there is a site-wide bayes database that is periodically trained by hand. It sits quietly and doesn’t change much over time. That is, until the Bayes database was moved to a new server. The SpamAssassin configuration was identical between the old system and the new system, there was just one problem: On the new server, the bayes_toks file was rapidly growing until it was quite large. Huge, in fact. Its size was expanding by several gigabytes per hour.
I checked all the usual things: auto learning was off, auto expiration was off, the permissions and user were set correctly, and so on. And yet it grew, constantly and swiftly.
After hours of searching and not finding anything, and various methods of tinkering, I found the answer. I backed up and restored the bayes database like so:
sa-learn --backup > bayes_backup.txt sa-learn --restore bayes_backup.txt
After that, the toks file was once again left alone and didn’t grow. I suspect the problem was due to moving from a 32-bit platform to a 64-bit platform but that’s just speculation really, or it could be some other difference in the perl versions and libraries on the two servers.
In case you couldn’t tell, I was trying to use a bunch of different ways to word this problem, going off of the various Google searches I did trying to track it down. Hopefully others will hit this post in the future and it will save them some time. :-)