Testing Buster

Hello random websurfer.

I've started to test the next Debian release on my desktop: codename Buster.

"Buster, the pet dachshund"

I would say that it's reassuringly boring, no major bugs to report in the few days that I've used it, at least from the Debian front.

From the 3rd party providers' front tho, I've found out that Docker CE fails to install even if they have an official Debian Buster repository, no mention on their installation notes of special requirements. After some digging, the reason is iptables was replaced with nftables on Debian Buster and they don't share the same "API" so containerd fails to start and it doesn't complete the upgrade or installation. One possible solution is to invoke update-alternatives to force the "legacy" version:

$sudo update-alternatives --config iptables
There are 2 choices for the alternative iptables (providing /usr/sbin/iptables).

  Selection    Path                       Priority   Status
------------------------------------------------------------
  0            /usr/sbin/iptables-nft      20        auto mode
* 1            /usr/sbin/iptables-legacy   10        manual mode
  2            /usr/sbin/iptables-nft      20        manual mode

Press <enter> to keep the current choice[*], or type selection number:

Another thing that I've noticed, I get the software updates' notifications but I don't get the requester to install them at shutdown time. I haven't yet asked in the IRC channel tho. Also, it seems I can't select the buttons on Gnome Header bars anymore.

About the desktop, at the moment Gnome uses Wayland as default instead of Xorg, I didn't noticed glitches or artifacts, but some minor issues are still present to ruin its prime-time, in my humble opinion.

For starting, it breaks the "focus follow mouse" option or at least it breaks the way I expect it to works. Next it's the title-bar actions, apparently it's missing in the Wayland protocol, in particular the possibility of a window to "lower/upper" itself, as a result clicking a window toolbar with the central mouse button to "lower", as it's configured here, it doesn't work.

Finally, the are some drag&drop issue to and from different application windows, like for example from the file manager to the web browser or the archive manager.

Also, no Wayland Emacs yet. Yeah I know, patches are welcome.

So I reverted to Xorg for the time being.

Speaking of the applications, Flatpak support seems in better shape and the incompatibilities with Debian packages were solved. As a result, I've decided to replace all the desktop applications with their Flatpak equivalent to see if they can be a viable solution. There's the disadvantage of more storage space required as it's not so uncommon to have more that a couple of runtimes installed, but in exchange it would bring applications not tied to the distribution and hopefully sandboxing for increased security¹.

Another drawback is it complicates the devices' access from the application front, in particular devices hot-plug, as it's designed to not provide direct access to dBus for example. To interact with the system from the sandbox in a secure fashion, it was introduced the Portals mechanism, but not all use cases are covered at the moment.

Anyway, I for one, would welcome a full flatpak-ed Gnome.

Bluetooth Mouse Lag

Hello Internauts!

I have a motherboard with an Intel WiFi/Bluetooth combo wireless card so I started to use a wireless mouse again but this time using the internal Bluetooth instead of the usual proprietary receiver that usually wastes an USB port.

I think to understand why the majority avoid Bluetooth as mice protocol.

At the beginning I was quite disappointed, it worked erratically with frequent disconnections, even if I disabled the power-saving option¹ and sometimes, after a disconnection, the mouse wasn't able to connect anymore.

Silly me, I didn't verified if there was a newer firmware for the Bluetooth stack, and yes after installing the latest version the mouse continues to turn itself off, but the update at least seems to have fixed the reconnecting problem and I'm not assuming all the times if the AA battery is depleted.

Another issue that I didn't found out immediately and not firmware related was the pointer horribly lagging when downloading something via WiFi on the LAN.

I tried to search something relevant on-line, but the issue seems a little too generic. At first I thought that being both services, WiFi and Bluetooth, on the same network adapter, maybe it was the result of a resource exhaustion or contention, like bus or the NIC CPU, even somewhat unreasonable with today's multi GHz and multi core CPU*s.

A more plausible hypothesis was a driver bug.

Scouring public mailing-lists and forum messages, I found out an option available on the WiFi Intel driver, bt_coex_active, off by default. Yeah, I somewhat forgot that WiFi and Bluetooth² share the same 2.4 GHz portion of the spectrum.

Shared Medium Coexistence

Coexistence is a somewhat ugly affair because the two technologies use the same medium but quite different protocols. In few words, FHSS (frequency hopping spread spectrum) used on Bluetooth consists on a signal transmitted on a narrow band but constantly "hopping" between different frequencies, while on WiFi is used DSSS (direct sequence spread spectrum) where the available spectrum is divided in bigger chunks of frequencies, so the Bluetooth signal that fall on the spectrum segment used by WiFi is seen as noise that in the best outcome requires packets re-transmission or, in the worst cases, a dropped connection.

Anyway, enabling the option eliminated the lag and I thought the case was closed, unless after a few days I found out that LAN WiFi connection was unbearably slow.

ヽ(´□｀。)ﾉ

Yup, Bluetooth coexistence crippled the WiFi's bandwidth.

Pondering between an unusable lagging mouse or a frustratingly slow WiFi³, by the way I was leaning for the latter, I spotted arguments available with the bt_coex_active option and started to experiment with them. I haven't tried all the combinations, but using the "enable agg TX" parameter it turns out that the bandwidth loss is lower than an acceptable 30% according to a few tests done with iperf3.

So for the moment, I'm satisfied.⁴

For the records, the Intel WiFi card is the Dual Band Wireless-AC 3168 model.

New Desktop

Good day random Websurfer!

I think I've mentioned before my aging desktop¹, anywho after learning a few months ago that recent mainline kernels have support for the new AMD's Ryzen APUs² I proceeded to an impulse purchase, so I'm here describing my new shiny SSFF PC (seriously small form factor personal computer).

Instead of my last desktop, this one is a real desktop in the literal sense of the word. I would never dare to put the old behemoth on any desk, it's a metal box of nearly 54 liters of volume, but inside it's basically empty. The chassis contains only a really under-powered passively cooled Nvidia GPU, a 2.5 inches SSD and a DVD writer, but nonetheless it still weights a lot.

The new case instead is really tiny, around 3.5 liters of volume, for comparison the volume is sensibly smaller than a Sony's first generation PS4³.

Case not closed

The case pictured above is only sold by shops in China, so other than the shipping time I had to wait five weeks before it was cleared by customs, with included request of proof of purchase. That was quite an hassle.

It's manufactured by a firm named Metalfish and the model is the "Metal Gear Plus", a name not easily searchable on the Interweb, so for the interested reader I'll add a link to their shop on TaoBao. Unfortunately the only color available is silver.

I should add that the impulse purchase resulted in a very slick but unsuitable HTPC anodized black aluminium case, a Streacom F1CWS. I've put a few pictures of it on the gallery below. Looking at the specs the case should been compatible with a Ryzen 5 2400G, but I should had known better than to take specs at a face value. When all the cores switch to burst mode, there's no way that the APU is producing only 65 W of heat.

On the other hand, the case manufacturer was quite optimistic of the cooling capacity of a single 60 mm case fan.

The cautionary tale is, the Streacom case without modifications isn't adequate for housing that CPU model, and I can't find a laser cutter or a CNC router to cut a grid on the top lid to install a 120 mm chassis fan, as it seems no one want to lend me high-power tools. Listen people, that incident with the soldering iron happened long time ago⁴. Anywho, the F1CWS is too fine looking to get rid of it so I've decided to keep it for an eventual future project.

I should also add that the Cryorig C7, a small profile CPU cooler, isn't compatible with either case: the nuts that are used to anchor the cooler to the motherboard are too high for the motherboard's stands used on the Streacom F1CWS and the heatsink and fan are a couple of millimeters too high for the Metalfish MetalGear Pro.

The quest for silence

I'm quite happy with the external 160 Watt PSU as it's fanless and without coiling whine of any sort, has enough headroom to power the components plus the eventual external peripherals that I would attach.

On idle and light usage the PC is completely inaudible in a really quiet room, I can't hear the CPU's fan at all. Unfortunately it became quite noisy when the four cores go full tilt for more than ten minutes, like when compiling a big application, because there isn't enough air circulation inside the case and the fans need to spin at maximum speed to avoid thermal throttling. With a room temperature around 21°C they barely keep the CPU core sensor below 77°C.

The future plan is to mod the chassis, carving an opening at the bottom to create clearance for the slightly bigger Cryorig C7 CPU cooler, to reduce air turbulence and increase fresh air intake. If it's not clear from the pictures, the motherboard is installed upside down. To be honest I have some concerns that fluid bearings fans aren't designed to work face down.

On the software front, only beginning with vanilla kernels 4.17 and using the new AMD GC - Graphic Core - drivers the system started to work with the integrated GPU, but it still randomly froze on boot nearly 3 times out of 5, it was really frustrating. According to what I read online, it's mostly related to the motherboard firmware, or better which version of AMD's AGESA the BIOS includes. I'm not sure if a later motherboard firmware update solved the boot issue or it was a driver revision, but nowadays the system is working rock solid, no complaints from my part.

Finally, the mandatory photo gallery is available below; I've thrown a PS4's DualShock controller to give an idea of the scale and also put the two desktop side by side for comparison.