$ lsusb | grep -i mediatek Bus 003 Device 002: ID 0e8d:7925 MediaTek Inc. Wireless_Device
$ rfkill list 0: hci0: Bluetooth Soft blocked: no Hard blocked: no 1: phy0: Wireless LAN Soft blocked: no Hard blocked: no
$ ls -al /lib/firmware/mediatek/mt7925/ ... -rw-r--r-- 1 root root 459528 Mar 19 23:32 BT_RAM_CODE_MT7925_1_1_hdr.bin.zst -rw-r--r-- 1 root root 197811 Mar 19 23:32 WIFI_MT7925_PATCH_MCU_1_1_hdr.bin.zst -rw-r--r-- 1 root root 1152702 Mar 19 23:32 WIFI_RAM_CODE_MT7925_1_1.bin.zst
MT7925 BlueTooth is usually exposed via USB (even though WiFi is PCIe).
1 2 3 4
$ dmesg | grep -i -E "bluetooth|mt7925|btmtk|firmware" ... Bluetooth: hci0: Failed to get device id (-108) [ 11.847463] ...
Failed to get device id (-108) is an ENOTUNIQ error from the USB/MMIO ID lookup in btusb/btmtk, often a known issue with MT7925 where the BlueTooth function doesn’t enumerate correctly or there’s a race during probe. This is a fairly common bug on MT7925 / 7925e cards on newer kernels.
The -108 error sometimes is caused by the BT USB device not being reset properly at boot. Try a full module reload in correct order:
Kilo Codedoesn't natively read **.github-based** Copilot skill/prompt/workflow/convention files — that format is specific toGitHub Copilot`’s custom instructions/prompts system.
Latest Ubuntu 26.04 LTS has dropped the support of X11 Server and xRDP and moved to the adoption of Wayland Display Server. Old approach with xRDP doesn’t work anymore. The solution / fix is the new Gnome Remote Desktop.
Generate Remote Desktop Server self-signed certificate:
When connect from Windows App (Microsoft Remote Desktop), error thrown in log:
1 2 3 4 5
$ sudo journalctl -u gnome-remote-desktop.service -f ... Jun 02 12:40:22 NucBox gnome-remote-desktop-daemon[58071]: [RDP] Sending server redirection Jun 02 12:40:22 NucBox gnome-remote-desktop-daemon[58071]: [12:40:22:884] [58071:0004752e] [ERROR][com.freerdp.core.peer] - [rdp_set_error_info]: ERRINFO_LOGOFF_BY_USER [0x0001000C] Jun 02 12:40:22 NucBox gnome-remote-desktop-daemon[58071]: [RDP] Network or intentional disconnect, stopping session
NOTE: According to A.I., GNOME Remote Desktop –system mode uses Server Redirection — after you authenticate at the system level, it redirects the RDP client to your actual user session on a different internal port. Microsoft Remote Desktop on Mac sometimes rejects this redirection for self-signed certificates because the certificate on the redirected session doesn’t match what it expects. And use user-level approach instead.
Extract data from the production tables and prepare JSON files for the test environment
1 2 3 4 5 6 7 8
for table in dashboard-tile-publisher-prod-group dashboard-tile-publisher-prod-tile dashboard-tile-publisher-prod-tile-event; do aws --profile production dynamodb scan \ --table-name $table \ --output json \ --max-items 10000 \ | jq --arg t "$table" '{ ($t): [ .Items[] | { "PutRequest": { "Item": . } } ] }' \ > $table.json done
Copy and modify the JSON files for the test environment
1 2 3 4
for suffix in group tile tile-event; do cp "dashboard-tile-publisher-prod-${suffix}.json" "dashboard-tile-publisher-ptest-${suffix}.json" sed -i '' "s/dashboard-tile-publisher-prod-${suffix}/dashboard-tile-publisher-ptest-${suffix}/g" "dashboard-tile-publisher-ptest-${suffix}.json" done
Update the content in the JSON files for the test environment
1 2 3
for suffix in tile tile-event; do sed -i '' 's/dashboard-tile-publisher-images-prod/dashboard-tile-publisher-images-ptest/g' "dashboard-tile-publisher-ptest-${suffix}.json" done
Import the modified JSON files into the test environment DynamoDB tables
1 2 3 4 5 6 7 8 9
for table in dashboard-tile-publisher-ptest-group dashboard-tile-publisher-ptest-tile dashboard-tile-publisher-ptest-tile-event; do jq -c --arg t "$table" '.[$t] | _nwise(25) | {($t): .}' "${table}.json" \ | while IFS='' read -r chunk; do aws --profile test dynamodb batch-write-item \ --no-cli-pager \ --request-items "$chunk"; \ sleep 10; # Add a small delay to avoid throttling done done
utcNow(): Grabs the current date and time in UTC (e.g., 2026-04-30T00:30:00Z).
addToTime(…, 1, ‘Month’): Jumps forward exactly one month into the future (e.g., May 30th, 2026).
startOfMonth(…): Takes that future date and rewinds it to the very first day of that month (e.g., May 1st, 2026).
addDays(…, -1, ‘yyyy-MM-dd’): Subtracts exactly one day from the first of next month, landing perfectly on the last day of the current month. The ‘yyyy-MM-dd’ at the end formats the output neatly (e.g., 2026-04-30).
formatDateTime(…, ‘dd’): Extract just the day
The output of above compose is: “30”
Compose (get today’s weekday number) expression
1
dayOfWeek(convertTimeZone(utcNow(), 'UTC', 'AUS Eastern Standard Time'))
The output of above compose is: 4
Condition
Output of Compose (get today’s day number) is equal to Compose (calculate last day of current month)
Output of Compose (get today’s weekday number) is greater or equal to 1 (Monday)
Output of Compose (get today’s weekday number) is less or equal to 5 (Friday)
“Local AI should be a default, not a privilege: private data, no per-token bill, no vendor lock-in. The hardware to run capable models already sits on desks. The software to run those chips well doesn’t.“
From time to time, not always, getting DNS_PROBE_FINISHED_NXDOMAIN error in browser especially when visit Chinese AI sites e.g. https://chat.qwen.ai/ and https://chat.z.ai/
The root reason is because some ISPs have slower or inconsistent DNS resolution.
The fix is switching to a faster public resolver like Google (8.8.8.8/8.8.4.4) or Cloudflare (1.1.1.1/1.0.0.1) in network settings.
[ec2-user@ip-10-215-240-19 ~]$ tic -x /tmp/ghostty.terminfo "/tmp/ghostty.terminfo", line 2, col 31, terminal 'xterm-ghostty': older tic versions may treat the description field as an alias
Ghostty uses TERM=xterm-ghostty which requires a terminfo entry on the remote system. Older Linux servers/macOS servers simply don’t have that entry in their terminfo database, so the other terminal utilities throw this “unknown terminal type“ error.
SAME issue also happens when run asitop in Ghostty. Error thrown:
1 2
'xterm-ghostty': unknown terminal type. /opt/homebrew/Cellar/asitop/0.0.24/libexec/lib/python3.14/site-packages/blessed/terminal.py:186: UserWarning: Failed to setupterm(kind='xterm-ghostty'): setupterm: could not find terminal
This is because asitop (via the blessed library) doesn’t recognize Ghostty‘s terminal type xterm-ghostty.
Either run as:
1
TERM=xterm-256color sudo asitop
or, add an alias to the shell config (~/.zshrc or ~/.bashrc):
1
alias asitop='TERM=xterm-256color sudo asitop'
Ghostty uses xterm-ghostty as its $TERM value, which isn’t in the terminfo database that blessed checks against. Falling back to xterm-256color gives it a fully compatible terminal description while keeping all the color/formatting support asitop needs.
root@mini:~# lsusb Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 006: ID 8087:0036 Intel Corp. Bus 003 Device 003: ID 0461:4e04 Primax Electronics, Ltd Lenovo Keyboard KB1021 Bus 003 Device 002: ID 17ef:600e Lenovo Optical Mouse Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
