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.
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
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?
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
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: 0It’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??
haha, Phoronix wrote about the stuff I posted on wayland-devel@. So yeah, I’m working on Rust bindings for libweston that would eventually allow me to write the best Wayland compositor ever :)
And fractional HiDPI scaling was pretty easy to add. Wayland apps look awesome. However, X11 apps are blurry now, and bypassing the scaling for Xwayland is not as easy… So I made some changes to my Ports fork to enable Wayland support in more apps. Turns out a lot of complex applications run fine — LibreOffice (!), Inkscape, MyPaint, RawTherapee, Darktable.
The Firefox Wayland support though… is not usable yet :( It looks awesome but EGL isn’t working and, even worse, the screen doesn’t refresh when it needs to — so you’re typing and letters don’t appear until you scroll or some time passes. Hopefully this will be fixed soon.
So there’s no support in pretty much all Wayland compositors for fancy keyboard mapping utilities like xcape because no one wants a keylogging protocol extension. (Even an access-controlled one!! Why.)
Turns out it’s better to just solve this on the evdev level. And I’ve done it in the coolest way possible: with a tiny sandboxed scripting environment. Meet evscript! It runs Dyon scripts in an environment with evdev, uinput, stdout and nothing else. xcape functionality is already provided in the “standard library” :)
Ported a recent version of the Weston compositor to FreeBSD. Using this as my actual desktop for two days now — works fine. I miss window tiling and a good info bar, but this thing, this thing lets you just rotate windows arbitrarily!! :D
So I was reading the OpenBSD Chromebook Pixel post: it did not wake up from suspend without the TPM driver. Hmm.
Disabled TPM on my Thinkpad X240 and FreeBSD RESUMES FROM SUSPEND!!! Wow. I guess I’ll stop using the TPM then (I was using it for SSH keys. And I did unload the tpm kernel module before suspend!)
Managed to get [Servo to run with Capsicum sandboxing on FreeBSD](https://github.com/servo/servo/issues/11625#issuecomment-342243384)!