Building raised beds

After a year in containers, it’s time to put some of the plants we got last year into the ground.

After making some plans, changing some plans, getting suggestions from friends, we decided to try the raised bed route so I built some boxes. Gardener Scott has some great YouTube videos covering raised bed gardening.

A trip to the nearby big box home improvement store (and a call to the wife after I discovered the boards I just bought wouldn’t all fit into the car) got me what I needed to build two 8 foot x 4 foot boxes for the raised beds.

Two wooden boxes on the lawn to be used for raised bed gardening

We’ll dig up the grass down to the “dirt” (heavy clay stuff) underneath and fill up the boxes with other dirt that the plants will hopefully like. Haven’t figured out where the new dirt is coming from yet. It will either be lots and lots of bags and several trips from the nearby big box hardware store, or maybe get a few cubic yards of dirt dumped on the driveway from somewhere.

The plan is to eventually have six raised bed boxes (three on either side of the tree). Four of them we’ll use for the blueberry and raspberry plants that are in pots right now. The other two we’ll use to try our hand at growing some veggies.

Teaching file: Mammography artifact

This artifact showed up at one of our mammography sites when the daily artifact evaluation was being performed.

On the left is the full artifact evaluation image. On the right is the cropped in view of the artifact. Try to guess what’s going on.

Continue reading “Teaching file: Mammography artifact”

New tablet

For an upcoming trip, I decided I needed a new tablet to replace the old Transformer Prime. After all this time, the battery doesn’t hold much of a charge anymore, and it’s become really slow and difficult to use.

This time, I wanted something that I could use for reading my growing e-book collection without all the distractions of extra apps on an Android or iOS tablet. I also wanted something that was e-paper/e-ink based. Looked at the Amazon Kindle tablets, but I felt they were too small. I finally settled on the reMarkable tablet.

I’ve been using it for about a week now, and it’s a pretty slick device. It’s a fairly open device which lends itself pretty well to hacking on and customizing. On the other hand, if you don’t know what you’re doing, it’s also not hard to brick. There’s a whole ecosystem of software, “paper” templates, and splash screens created by other reMarkable tablet users. There’s a wiki to collect a lot of those projects and information in one place.

I had a new mammography unit to acceptance test today, so naturally I took an x-ray image of the reMarkable.

X-ray image of the reMarkable 2 tablet. 1404x1872 pixel PNG suitable for using with the Remarkable 2.
X-ray image of the reMarkable 2 tablet. 1404×1872 pixel PNG suitable for using with the reMarkable 2.

Turning it into power-off and sleep splash screens for the reMarkable was pretty easy. Resize the image to 1404×1872 pixels, save it as an appropriately named PNG file, and copy it over to the Remarkable. Reboot and the new splash screens were there.

reMarkable tablet with an x-ray of the tablet as the power-off splash screen

The Remarkable also fits nicely into the leather sleeve I bought for the Transformer Prime.

I’ve loaded it up with EPUB books and I already have a few ideas for some paper templates to create. I’m going to enjoy using this tablet.

Update: Oh, I forgot the pen! The reMarkable Marker looks pretty simple inside. Tough to tell, but at the tip is a coil of wire and a few other bits that help to inform the digitizer in the Remarkable where the tip of the pen is. The other solid dense objects I think are the magnets used to clip the Marker to the side of the reMarkable.

reMarkable Marker pen x-ray. 1404x1872 pixel PNG suitable for using with the Remarkable 2.
reMarkable Marker pen x-ray. 1404×1872 pixel PNG suitable for using with the reMarkable 2.

Another update: Embiggened versions of the reMarkable and reMarkable Marker.

452: Out of range pointer error

For the last couple weeks, my computer has been up and down, spitting out an error when booting up:

452: out of range pointer: 0x100010
Backgrace (.text 0xa058 .data 0x15a6c):
Aborted. Press any key to exit.

It started happening after rebooting following an update. Internet searches I did brought up some older forum posts that pointed to grub being the cause. Since it had been several Fedora versions (before Fedora 30 I think) since I last reinstalled and the system was feeling a bit crusty, I figured I’d just start fresh with a new install.

Wrestled with getting a Fedora 37 live image to boot off, did a reinstall and updates, rebooted, and ended up with the same message. Did this a couple times and started investigating the hardware.

Several iterations of testing the DDR3 memory modules and pulling out hard drives, I managed to get my computer back up and running with 8GB less memory, two 500 GB drives and a 250 GB SSD (the original boot drive) removed. All of the memory tested fine individually but with all of them installed, memtest consistently gave errors when performing one test the 21-22 GB range. Not sure if something’s happened to one of the memory slots, but the system stayed pretty stable for a few days.

Then, after reinstalling some software, running some updates, and rebooting, the error came back.

Ugh.

At this point, rather than reinstall again, I tried reinstalling the bootloader and rebuilt the grub config file. Rebooted and the system came back up without any issues.

Still don’t know what caused the breakage, but it’s been pretty stable so far the past few days. Let’s hope it stays that way. It’s running a bit slower because now I’m back to booting off a regular hard drive (1 TB) rather than an SSD. At some point I might try to put the other 8 GB back in to see how stable the system stays. I’d been having some problems with the computer intermittently freezing up at random points, so I’ll just leave it like this for a while. The 500 GB drives will go into a couple other systems that I inherited a while back. I think one of them will be put to work in the garage, probably on the CNC mill. The other one might end up being used with the radio in the shack.

I tried to reinstall Fedora on the 250 GB SSD drive, but the install would always freeze in the middle of doing something. Even though the drive’s SMART status shows it’s fine, I suspect it has started to develop some issues somewhere.

Fedora KDE, Plasma Wayland, and Emacs

My previous attempts at using Fedora KDE with Wayland were pretty miserable, and KDE was pretty much unusable under Wayland with the nVidia drivers. Never tried it with the nouveau drivers at the time, but after dumping the nVidia drivers a while back, I thought I’d give KDE Plasma Wayland another shot.

I don’t know if Wayland support under KDE got better or if it’s because I’m not using the nVidia drivers anymore (probably both), but I’m finding Plasma is pretty snappy under Wayland.

I normally have emacs started as a systemd service (systemd --user start emacs) which runs emacs in daemon mode. Then I can just run emacsclient and have it connect to the already running emacs. One big issue I came across was not being able to run emacsclient and getting an *ERROR*: Display :0 can't be opened when I ran emacsclient -c from the command line.

The general consensus I found after searching the web for a while seemed to be that with systemd, the emacs daemon was starting before the graphical environment (Plasma), so display related environment variables weren’t available to emacs. Why this only happened with Plasma Wayland and not with Plasma X11, I don’t know.

When the emacs systemd service is enabled (systemd --user enable emacs), /usr/lib/systemd/user/emacs.service is symlinked into ~/.config/systemd/user/default.target.wants. My first attempt to fix the issue was to move emacs.service to graphical-session.target.wants, but that didn’t help.

Thinking about the apparent root cause of the issue, I found a Unix StackExchange post about how to have systemd services start in a particular order. I copied /usr/lib/systemd/user/emacs.service to ~/.config/systemd/user and linked it into graphical-session.target.wants. Then I added two lines to the [Unit] section:

Requires=plasma-kwin_wayland.service
After=plasma-kwin_wayland.service

This makes emacs.service a dependency of plasma-kwin_wayland.service and delays starting until after plasma-kwin_wayland.service has finished starting.

After rebooting and logging back in, I verified that the emacs daemon was still starting up (systemd --user status emacs) and was able to get emacsclient -c to bring up the emacs window. Everything was back to working the way I expected.