Scaleway's ARM64 VPS has been successfully depenguinated! :) Now you can run FreeBSD on four ThunderX cores, 2GB RAM and 50GB SSD for 3€/month. Awesome!

Also, in the process, I finally discovered the cause of GPT partitions sometimes disappearing on reboot. It was the size of the partition table. It's 128 by default, but sometimes it's not — e.g. on the FreeBSD installer memstick image, it's 2. Creating a third partition with gpart "succeeded", but the partition disappeared on reboot.

Building a reader on your website is not too hard when you already have webmention processing (so you have code to parse entries and whatnot). So I kinda have one now. There's even some Microsub support, but that's not complete yet.

There's a funny bug in my feed fetching though: OAuth for the open web is always on top of the feed (its published date gets set to feed fetch time every time) :D
Screenshot of htop with 96 CPU cores

For 0.5 dollars per hour (or currently 0.1/hr if you reserve for 24h?) on packet.net you can get access to a dedicated dual-socket Cavium ThunderX server with 128GB RAM and a 250GB SSD. I took it for a few hours and now lang/crystal, lang/mono and some other ports work on aarch64.

Ironically, these two builds have involved long single-threaded compile processes. In the mono case, parallelism had to be disabled for C# compilation to work around a concurrency bug.

At least building things like WebKitGTK+ (to test a one line patch) and Krita felt awesome :D

I was wondering why replies sent with the Omnibear Micropub browser extension ended up with the URL /replies/ instead of the auto generated slug. Turns out Omnibear sends mp-slug="" and my server happily accepted the empty slug :D

I rewrote micro-panel (the "admin panel" for this site) from scratch with LitElement and no material design components. It's really tiny now! The minified bundle is 57kb (and that still includes a code editor with syntax highlighting). The previous version was nearly 1mb.

Also, the new version is a bit simplified: no iframe mode, only cookie auth. And it doesn't wrap the whole page in an element, it's now more of a set of elements.

Check out this piece of code, by the way:

async close () {
  if ('animate' in this && 'finished' in Animation.prototype) {
    await this.animate({transform: ['none', 'translateY(100vh)']},
      {duration: 300, easing: 'ease-out'}).finished
  }
  this.hidden = true
}

I was wondering why a lot of Chinese spam was ending up in my inbox.

$ grep qq.com -lr . | uniq | xargs rspamc learn_spam

Turns out, because these spam mails don't really have bodies, most of them weren't learned as spam in rspamd's bayes classifier, and they weren't considered spammy enough:

HTTP error: 400, <...@qq.com> contains less tokens than required for bayes classifier: 2 < 11

BREAKING FreeBSD NEWS: AMDGPU DC works!

The 4.15 drm update apparently did not have amdgpu working yet... but I tried it anyway, since that's just an assertion failure.

Well... it does work. Even with DC (compat.linuxkpi.dc="1")! Weston didn't work at first, but commenting out its "Disable all the planes" section that was causing a kernel warning solved the problem.

So quite possibly we have Vega support?

lol, just as I set up Travis CI for a Swift project, swift.org went down and the CI script can't download the compiler binaries

Booted into FreeBSD, launched Epiphany (GNOME Web), noticed slowness. Opened htop: 800-1200% load in kernel! Ran dtrace to find hot kernel stacks: it's all ZFS write threads, trying to compress. WTF? I mean, my fault for choosing gzip (I have a tiny SSD for this system, want max compression), but I expect zero I/O right now?! Found a DTrace script to show file I/O.

Turns out Epiphany is constantly writing to and reading from ~/.config/epiphany/gsb-threats.db. Yeah, it was downloading the whole Google Safe Browsing database.

I guess that's the most privacy-friendly way to do Safe Browsing, but wow, that's a very surprising behavior. What if I had, like, a dial-up connection or something? :D

Wow, Lollypop is an excellent GTK+ music player. Album-oriented, just like I prefer. iTunes-inspired in some design elements. Nice. I just wish it was an MPD client.

Discovery of the day: Blender has an SDL2 backend, just build it with -DWITH_GHOST_SDL=ON. If you also have GLEW built for Wayland…

Blender will run on Wayland!

Well, "run" — the window is glitchy as hell. The best thing though is that these glitches showed Dungeon Crawl Stone Soup tiles to me (since I launched DCSS before to test SDL — for some reason I had to downgrade to 2.0.7 to run most apps on Wayland.)

It is well known that Enlightenment/EFL is pretty awful. But I had to build it on my FreeBSD box since I'm testing a LuaJIT update and EFL does include LuaJIT support. So while I'm at it, I decided to add Wayland support to the port.

So at least it works, but its behavior is indeed kinda funny. Running their terminal with GL acceleration (ELM_DISPLAY=wl ELM_ACCEL=opengl terminology) actually does work. Running it without acceleration (ELM_DISPLAY=wl ELM_ACCEL=no terminology) results in the surface not showing up and… this message:

DRM_IOCTL_I915_GEM_APERTURE failed: Invalid argument
Assuming 131072kB available aperture size.
May lead to reduced performance or incorrect rendering.
get chip id failed: -1 [2]
param: 4, val: 0

It's no "SPANK! SPANK! SPANK!" but how exactly did it decide to use an Intel GPU related system call? On my machine that has a Radeon card?!?! When I asked for software rendering??
Camera Canon EOS 600D Lens EF-S18-55mm f/3.5-5.6 IS II Photo parameters 1/200 ƒ/6.3 ISO 200 Software GIMP 2.8.22

I bricked my mainboard… and recovered it using a Raspberry Pi!

So yeah, this is an MSI X370 SLI PLUS. A new firmware update came out, so I unpacked it onto a USB stick and started the upgrade process. With an overclocking profile that sometimes takes a few tries to boot (memory training) and with the stick inserted into a front panel USB port.

The process almost completed (or maybe completed?), the board tried to reboot… and it didn't boot. As in, power comes on, the CPU and RAM debug LEDs turn on and off, then nothing. Clearing CMOS didn't help.

So I looked at this MSI forum thread that contains the pinout and people arguing whether 3.3V is safe for a 1.8V EEPROM chip. I took a 5V-3.3V level shifter (the only one I had), plugging 3.3V into the "5V" side got me down to 2.9V.

And then I tried to connect to the tiny pins of the SPI header (thanks MSI for providing one!) using my large wires. This was rather painful. Couldn't connect ground at all (because that was 3 pins next to each other, it didn't fit). But without GND or VCC, flashrom actually detected an unknown chip! With some random experimentation I found that setting a low speed (1024) and plugging in only VCC totally works! Writing this from the recovered computer :)