Archive for the ‘Webtechnology’ Category

2 Comments

The new Raspberry Pi 5 has arrived (in specs)

Saturday, September 30th, 2023

A new Raspberry Pi 5 is introduced, and contrary to earlier launches, the new device is not available yet for customers. It will be on the shelves around the 23rd of October.

This creates a period of time in which the new open-source software can be pushed into the open, and merged with existing repositories. When the boards are shipped in the end of October, the update free open source software is in place.

The new Pi is about twice as fast as the RPI4, memory bandwidth and latency have improved, the same for the I/O. For example WiFi speed is twice as fast, due to the new improved I/O, the WiFi chip itself is the same as in the Pi 4. SD-card speed is twice as fast.

Nearly all parts have been upgraded. A Real Time Clock is a new welcome addition. A fan socket. A power button has been added.

Key features include:

  • 2.4GHz quad-core 64-bit Arm Cortex-A76 CPU
  • VideoCore VII GPU, supporting OpenGLES 3.1, Vulkan 1.2
  • Dual 4Kp60 HDMI® display output
  • 4Kp60 HEVC decoder
  • Dual-band 802.11ac Wi-Fi®
  • Bluetooth 5.0 / Bluetooth Low Energy (BLE)
  • High-speed microSD card interface with SDR104 mode support
  • 2 × USB 3.0 ports, supporting simultaneous 5Gbps operation
  • 2 × USB 2.0 ports
  • Gigabit Ethernet, with PoE+ support (requires separate PoE+ HAT, coming soon)
  • 2 × 4-lane MIPI camera/display transceivers
  • PCIe 2.0 x1 interface for fast peripherals
  • Raspberry Pi standard 40-pin GPIO header
  • Real-time clock
  • Power button

SD-card transfer speed for Raspberry Pi’s

Let’s take a look at the new SD-card speed. A simple benchmark is hdparm for reading speed:

sudo hdparm -t --direct /dev/mmcblk0

So in this post we compare some benchmarks of the new Raspberry Pi 5 and earlier models.

Explaining Computers is getting this speed for a SD-card in the new RaspberryPi 5 (RPI5):

Raspberry Pi 5 SD-card transfer speed

/dev/mmcblk0:
Timing O_DIRECT disk reads: 258 MB in 3.01 seconds = 85.69 MB/sec

Raspberry Pi 4 SD-card transfer speed

/dev/mmcblk0:
Timing O_DIRECT disk reads: 258 MB in 3.01 seconds = 41.15 MB/sec

Raspberry Pi 400 SD-card transfer speed

We did our own test with a Raspberry Pi 400 and actually we achieved a similar speed:

/dev/mmcblk0:
Timing O_DIRECT disk reads: 126 MB in 3.02 seconds = 41.76 MB/sec

A Raspberry Pi 4 or 400 also doubled the SD-card speed compared to older models, so let’s test a RPI 2:

Raspberry Pi 2 SD-card transfer speed

/dev/mmcblk0:
Timing O_DIRECT disk reads: 66 MB in 3.08 seconds = 21.41 MB/sec

Raspberry Pi Zero SD-card transfer speed

/dev/mmcblk0:
Timing O_DIRECT disk reads: 64 MB in 3.04 seconds = 21.02 MB/sec

Raspberry Pi Zero 2 SD-card transfer speed

/dev/mmcblk0:
Timing O_DIRECT disk reads: 62 MB in 3.00 seconds = 20.65 MB/sec

SD-card RPI5 speed has quadrupled since the RPI2

An yes, the SD-Card speed has quadrupled moving from an original RPI to the new RPI5.

That is not bad.

We also tested the Compute Model 4 with eMMC:

Raspberry Compute Model 4 eMMC transfer speed

/dev/mmcblk0:
Timing O_DIRECT disk reads: 244 MB in 3.00 seconds = 81.22 MB/sec

So the new RPI5 is reading faster from an SD-card then the CM4 is reading from eMMC!

That is a surprise, and AFAICS, this is all related to the much improved I/O at the new RPI5.

Remember, WiFi is twice as fast, and it still has the same WiFi hardware.

USB speeds is now 5GB each on the USB ports, in the RPI4 5GB was shared.

So it seems the new Raspberry Pi 5 is a nice upgrade for just 5 dollars, a new Raspberry Pi 5 4GB/8GB is just 5 dollars more expensive than the Raspberry 4.

SD benchmark transfer speed various Raspberry Pi models

sudo hdparm -t --direct /dev/mmcblk0
Model SD card Speed
RPI 5 (Expl. Comp.) 85.69 MB/sec
CM 4 (eMMC) 81.22 MB/sec
RPI 400 41.76 MB/sec
RPI 4 41.15 MB/sec
RPI 2 21.41 MB/sec
RPI Zero 2 20.65 MB/sec
RPI Zero 21.02 MB/sec

Greetings.

No Comments

Improving accessibility in Ubuntu for the visually impaired with a narrow field of vision

Thursday, August 24th, 2023

For a visually impaired person with a very narrow field of vision it can be difficult to locate the mouse on the screen.

Imagine someone with glaucoma, they are looking through a straw, so they have to scan the screen from left top to right bottom (or sometimes even a sentence character by character).

So what you want sometimes is to move the mouse to the center of the screen or some other easy to spot location.

Historically you could use xdotool for that, but xdotool doesn’t work with Wayland,  and in Wayland there is no out-of-the-box tool to do it.

There a a few options as an alternative:

  • wtype
  • ydotool
  • dotool

wtype is available in the deb repository, so it can be installed with

sudo apt install wtype

BUT

it doesn’t work with Gnome.

`Compositor does not support the virtual keyboard protocol`

I’m not sure if that’s a lacking Gnome feature that will be resolved sooner or later, but IMHO it makes wtype useless for the common Ubuntu user.

Second is ydotool, but that is quite a hassle to install, although there are detailed instructions, so I decided to give the alternative dotool a try.

Follow the instructions (Clone the repo and run install).

Next I created a small bash script


#!/usr/bin/bash
echo "mouseto .5 .5" | dotool

Then simple add a custom shortcut to your script with absolute path and you’re done.

Open Settings -> Keyboard

Choose View and Customize shortcuts -> Custom Shortcuts

 

And add your shortcut.

 

That is all. Now you can easily center the mouse with pressing CTRL SUPER Z.

Remember SUPER is the windows key, normally next to the left CTRL key.

Actually the script will center on the total desktop, so when you use two monitors with extended desktop it won’t center on your screen. 😉

No Comments

Permitting a device to join Zigbee2MQTT in Home Assistant temporarily

Wednesday, June 28th, 2023

The config setting for letting a new device join the Zigbee network is found in Zigbee2MQTT”s configuration.yaml

For security reasons it’s important that permit_join: is set to falseOtherwise rogue devices are able to join allowing them to send and receive Zigbee traffic.

When you want to add a new device editing this setting manually in the config file is a hassle.

Luckily you can issue this CLI command from any connected computer on the LAN to open the network temporarily:

mosquitto_pub -h <hostname> -t zigbee2mqtt/bridge/request/permit_join -m ‘{“value”: true, “time”: 20}’

This will open the network for 20 seconds, enough time to add your device, and when the 20 seconds have passed the network is secure again.

Just keep an eye that no additional rogue devices are added.

No Comments

Using an external AOC touchscreen on Ubuntu

Wednesday, March 1st, 2023

TL;DR

Using an external portable AOC 16T2 monitor as a secondary screen works well on a Ubuntu laptop, but it needs a bit of tweaking.

xinput map-to-output 14 HDMI-A-0

Connecting a touchscreen to an Ubuntu Laptop

One of the first things you’ll do when connecting an USB device, getting info about the device. Is it recognized? Issue an lsusb before and after connecting the device and watch the difference. In this case:

Check connected USB-devices in Linux

lsusb
Bus 001 Device 011: ID 1fd2:9004 Melfas LGDisplay Incell Touch

So Ubuntu does recognize the AOC 16T2 monitor as a touch-device.

For that of course an USB-C (3.0) display cable is necessary, touch information is not transferred over an HDMI cable, in that case you’ll need another USB-C cable, a USB-C 2.0 version is sufficiant.

Another check if the screen is recognized as a touchscreen, issue the xinput command, before and after

Check input devices in Linux

xinput
Melfas LGDisplay Incell Touch id=14 [slave pointer (2)]

Check connected screens in Linux

To check screen use xrandr.

xrandr
HDMI-A-0 connected

Using a touchscreen on Ubuntu, and using a touchpad at the same time causes some confusion. At the moment you use the touchscreen your mouse disappears. That does make some sense, otherwise you feel urged to move the mouse, which is of course not needed on a touchscreen.

Tip: enable locate pointer when using touchscreen

Enable the locate pointer settting in the accessibilty settings, helps you to find you’re invisible mouse. Press CTRL and you can find your mouse-position again.

Once you’re used to that, an external touchscreen works rather strange out of the box, when you’re using join display, extended desktop as a default for attaching an external monitor, which is wanted in most cases.

Strange default in Ubuntu using secondary touchscreen.

Visual the desktop is extended, but for touch-input it is not. SO the visual-desktop is different than the (touch) input-desktop. That means when you click on the second monitor, the gesture is interpreted like you touch on the first monitor.

 

 

And I tried but this cannot be solved by changing the order of screens in the display-setting, moving the external monitor to the left.

To get it working you’ll need to issue a command in the terminal.

Making a external touchscreen working in Ubuntu

To map the touch.input-desktop to the visual-desktop:

xinput map-to-output 14 HDMI-A-0

This will map the touch-desktop to the secondary AOC touchscreen.

You do wonder why this is not the default in Ubuntu. I’m not sure, maybe it was in earlier days.

But this is not working in Wayland

And there is a bigger problem. This solution works only in X11 window server, not in the new Wayland environment, which is the default nowadays in nearly all modern Linux desktop, including Ubuntu 22.04 LTS.

As it seems xinput does not find your touchscreen annymore, so no mapping can be done.

Wayland does recognize the touchscreen, there is no option yet to map  it to the right screen.

That is plain stupid a pity.

So that means you have to logout/login and switch to X11 to use your external touchscreen.

Hopefully this will fixed soon.

No Comments

How to make dmarc-cat read compressed DMARCS reports

Thursday, February 16th, 2023

Dmarc reports are send as attachments by several email-services.

DMARC reports are in the XML format, so of course the reports are compressed before sending.

For example, OUTLOOK is sending them as gzip compressed:

protection.outlook.com!<domain>!<timestamp-start>!<timestamp-end>.xml.gz

Other email-servers are sending zipped attachments.

Once the report are saved dmarc-cat seems to be able to decompress .zip reports on the fly, but it fails on gz files.

So this works:

dmrac-cat protection.outlook.com!<domain>!<timestamp-start>!<timestamp-end>.xml
dmrac-cat protection.outlook.com!<domain>!<timestamp-start>!<timestamp-end>.xml.zip

But this fails:

dmrac-cat protection.outlook.com!<domain>!<timestamp-start>!<timestamp-end>.xml.gz

How to make dmarc-cat parse gz dmarc reports?

There is a poorly documented -t switch


dmarc-cat -h

Usage of dmarc-cat:
-D Debug mode
-N Do not resolve IPs
-S string
Sort results (default "\"Count\" \"dsc\"")
-j int
Parallel jobs (default 12)
-t string
File type for stdin mode
-v Verbose mode
-version
Display version

It’s a bit unclear how it should work, but this will do the trick:

dmrac-cat -t .gz protection.outlook.com!<domain>!<timestamp-start>!<timestamp-end>.xml.gz

And it also miraculously parses zip files, so this works also:

dmrac-cat -t .gz protection.outlook.com!<domain>!<timestamp-start>!<timestamp-end>.xml.zip

Add dmarc-cat as an alias for dmarc-cat -t .gz

So just add dmarc-cat as an alias in dmrac-cat -t .gz to .bash_aliases and your good to go:

echo "alias dmarc-cat='dmarc-cat -t .gz'" >> ~/.bash_aliases

This will save you some keystrokes the rest of you life!

dmrac-cat protection.outlook.com!<domain>!<timestamp-start>!<timestamp-end>.xml.gz
dmrac-cat protection.outlook.com!<domain>!<timestamp-start>!<timestamp-end>.xml.zip
No Comments

Trouble updating some packages in Ubuntu 22.04, because they are kept back

Tuesday, January 17th, 2023

Maybe you have seen this message more often then before, while updating your computer manually through the terminal:

The following packages have been kept back:
<package-name>
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.

Historically that could be the case with the classic commands

sudo apt update && sudo apt upgrade

Because that command is careful (doesn’t update) about packages that can introduce dependency conflicts

But that update command has been superseded by

sudo apt update && sudo apt full-upgrade -y

The latter commands also remove packages to resolve dependency conflicts, and in most cases that is everything you want.

But now upgraded to Ubuntu 22.04 I see the kept back message more and more, even when I did a sudo apt update && sudo apt full-upgrade -y

And as it seems, that is absolutely OK, it’s part of the new phased roll-out mechanism. Packages that can break things are introduced in batches. First only a small percentage of users are getting the new version, so if there are bugs, only a small number of people are hit, and the bugs can be fixed before it is introduced on a bigger scale.

How to check if packages are `phased`

apt-cache policy <package-name>

e.g. gnome-remote-desktop

apt-cache policy gnome-remote-desktop 
gnome-remote-desktop:
Installed: 42.4-0ubuntu1
Candidate: 42.7-0ubuntu1
Version table:
42.7-0ubuntu1 500 (phased 0%)
500 http://nl.archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages
*** 42.4-0ubuntu1 100
100 /var/lib/dpkg/status
42.0-4ubuntu1 500
500 http://nl.archive.ubuntu.com/ubuntu jammy/main amd64 Packages

Just be a little patient. The update will normally come in a few days.