for x in /tmp/mail/\*; do echo $x; procmail < $x; done
07 June 2017
on my server
had apparently shutdown,
and I hadn’t noticed
until I logged in
to check email and found thousands
of emails in my inbox,
instead of having been properly filtered
I cleaned up about 100 messages by hand,
but I quickly realized I didn’t want to do this anymore.
I found a
tip at the Unix StackExchange
could be run again
on each message file
as it sits in the
and each would be processed
through spamassassin normally
to the correct mailbox.
To be safe,
I moved all the new mail files
mutt to see them all gone,
and then piped each file into
for x in /tmp/mail/\*; do echo $x; procmail < $x; done
I could see mail starting
to appear again in my inbox
and in my spam folders.
When the loop was done,
and I was sure my inbox looked good,
and I was back in business.
27 November 2016
I picked up a very-slightly-used 34-inch LG 34UM67 display to use on my Debian Linux workstation that I use for processing photos. It’s an IPS display with 2560x1080 pixels, so that should fit nicely with photo work.
The built-in graphics on my Dell T20 only supports VGA, so I also needed to buy a new video card to support HDMI. My needs are modest, so I picked out an Asus ATI Radeon HD6450. I’ve always gone for ATI/AMD and Intel when I could, since their fully open-source versions of drivers have worked well in the past. I’m also not a gamer, so I can skip over Nvidia.
Upon plugging it all together, I needed to ensure I had all the "amdgpu" packages installed from Debian Unstable, so I could get higher resolutions beyond VGA.
It still didn’t recognize the crazy-wide 21:9 aspect ratio out of the box, so I still had some work to do. By default, the display awkwardly stretched the card’s 1920x1080 across the whole screen. That can be fixed in the display: Menu → Quick Settings → Ratio → 1:1, and then you’ll have letter boxes on the sides, but no stretching.
That left me still needing to convince my Xorg xserver to use the rest of the screen, all 2560x1080 pixels. I found a stackexchange article which provided me just about everything I needed.
Generate a modeline for the new resolution: 
cvt 2560 1080 30
Create that new modeline dynamically. In my case mine, looked like this:
xrandr --newmode "2560x1080_30.00" 106.75 2560 2640 2896 3232 1080 1083 1093 1102 -hsync +vsync
Add the mode to the HDMI interface.
In my case it was named
xrandr --addmode HDMI-0 2560x1080_30.00
Then switch to it:
xrandr --output HDMI-0 --mode 2560x1080_30.00
Once I had proven these settings to work nicely,
I obviously wanted to keep them,
so I persisted them by creating a file for them
in the xorg config directory along-side the existing configs
that Debian provides.
I called my file
Section "Monitor" Identifier "HDMI-0" Modeline "2560x1080_30.00" 106.75 2560 2640 2896 3232 1080 1083 1093 1102 -hsync +vsync Option "PreferredMode" "2560x1080_30.00" EndSection
everything was working,
and I was happy for a week or 2,
but I noticed performance wasn’t great during fast 2D updates.
I was seeing some tearing
when I’d play a video in full-screen
or even a large window.
I dug around a little in the
amdgpu(4) man page
and found a couple more options to add to my
Section "Device" Identifier "AMDgpu" Option "TearFree" "on" Option "ShadowPrimary" "on" EndSection
Those final adjustments solved the performance problem for me. I expect those adjustments may only be specific to the cheap card I bought, though.
Next I’ll need to figure out how to speed up my mouse, since it’s such a long way from one side of the screen to the other. I’ll also further rethink the windows I keep beside one another.
I bought the display figuring Linux can be made to do anything, and I was right. I just needed to figure out how.
12 February 2016
The kids got a little M3D Micro for Christmas, and so started our adventures into 3D printing.
I intended to let the kids learn the whole thing from scratch, but I knew I was throwing them a little bit of a curve ball by only having Linux netbooks to drive it, so I ended up getting a headstart setting up OctoPrint and the M3D-Fio driver.
At the end of December 2015 when I was starting, the M3D-Fio driver had some configurations in the repository that might not have been optimal, so I was fighting a bit with a few problems:
adhesion to the bed
gaps and lines in the bottom layers
other quality issues
I thrashed around for quite some time changing settings I didn’t really understand, and Matthew spent a night helping me and showing me what his much larger printer could do — that helped immensely, since it gave me some hints as to what I should be expecting from my printer. I also learned what the different settings should be doing for me.
For an entire Sunday, about 18 hours, I printed 1cm test cubes and experimented with settings. I quickly decided I should have my settings and profiles tracked in my own local git repository, so I can always rollback to previous settings.
After a week or so, some updates from the M3D-Fio repository brought us more success with more default settings that matched the defaults found in the original software from Micro. The conservative settings also added rafts and slowed down the print a bit.
I was able to take those conservative settings and speed them up a bit and remove the rafts — the BuildTak holds a print pretty well even without the raft. I based my customizations on the stock profile that prints at 0.25mm layer thickness to get even more speed out of the printer.
I also found keeping a -0.4mm bed offset on my printer helped get just enough squish in the first layer to help get a more solid bottom layre and good adhesion to the bed.
Another notable configuration tip I had picked up was to set the wall thickness to a multiple of the nozzle size. In the case of the M3D, the nozzle thickness is 0.35mm, so I’m using a thickness of 0.70mm. Before I had learned that, a couple of my initial chachkies came out with thin gaps where the slicer should have decided to fill.
I’m at the point now that I have pretty reasonable expectations for what the printer can do, and I can start up the machine after a week or 2 of sitting, and run a print through reliably without needing to make adjustments. That’s great for letting the kids just make whatever they want. Both kids have been able to get into Tinkercad and produce some printable designs. Ben’s doing Nerf rail accessories, and Marie is designing a new cap for my growler.
Finally, I’ve pushed my configurations to a public git repository to serve as reference for anyone else who cares.
An update added a slicker settings dialog to allow more intuitive adjustments to a profile, so I’ve been testing relatively successfully with using the stock PLA profile and just flipping options. I did find that using a raft in "medium quality" mode fused my little 10mm test cube to the raft in a way that I can’t remove it. I usually avoid the raft anyway, though, since it sticks so well to the buildtak already.
13 December 2012
I realized upon trying to replace a drive in my Linux software RAID, that I had never previously documented this process.
The power failed a couple days ago, and sitting around for 10 hours not spinning was bad for my one Western Digital 500GB drive, so it never came back online, but the computer booted up just fine with 2 of the 3 drives. I ordered a new 1GB drive to replace it within 2 hours of the problem.
When the new drive arrived, I shutdown the computer, unplugged the failing SATA drive, and replaced it with the new one. Linux again booted up with only 2 drives active.
To ensure that the partitions matched, I did an
sfdisk -d /dev/sda | sfdisk /dev/sdb.
cfdisk was unhappy with the drive initially, but
fdisk was happy to read the table and write it back cleanly. Then I could open it again in
cfdisk and add one more primary partition to use the extra non-redundant 500G on the new drive.
With the partitions in place, it was time to insert the new
partitions back into the RAID devices:
mdadm /dev/md0 --add /dev/sdb1,
mdadm /dev/md2 --add /dev/sdb5, etc, until all the drives were re-established. Watching
/proc/mdstat, I could see that the RAID started recovering the devices, and I could go to bed.
I did manage to do something wrong at one point, so a quick
mdadm /dev/md0 --fail /dev/sdb1
mdadm /dev/md0 --remove /dev/sdb1 allowed me to fail and remove a partition, fix it up, then add it back when I was done. All this could be done with the system up and running—that's pretty convenient.