Few notes on web browsers (they all are shit)

SOCKS5

If you ever have to use a SOCKS5 proxy for a selected sites (like to bypass territorial restrictions) you might want to configure it in a manner it will be used by all web browsers, whatever you wanna use. So if you're KDE user you're doing that in your KDE System Settings app, on a tab called "Proxy". If you're GNOME user, I bet there should be an appropriate app for it. And all the rest applications are supposed to fetch these settings from your desktop environment or if you want to configure them on an individual basis - they should let you do so. In theory.

But after a closer inspection on practice it turned out that:

• Chromium doesn't give a shit about KDE settings. Even more, it doesn't give a shit about SOCKS5 configuration in UI. The only how you can make it to use SOCKS5 is to provide a cli parameter upon startup. But here goes the trick, if you already have a running instance of Chromium that other new process with SOCKS5 in cli won't give a shit about it.
   
•  Firefox does have SOCKS5 configuration, but it does that in a shit way - you can only specify which sites you don't want to use proxy. There's no nice checkbox like in KDE System Settings like "Use proxy settings only for those sites listed in exceptions". I tried to use a .pac file with a simple function which would always return my proxy (just as a matter of testing), but it's not going to work if you provide Firefox a path to it like file:///home/xxxx/yourfile.pac probably because it just doesn't support that. And running a whole web server just to give that Firefox an only file looks idiotic to me.
  
  This can be slightly mitigated by installing this firefox extension - Container Proxy but it's also non ideal.
  
  
• Konqueror is pretending that it can work with SOCKS5, but it has a nasty bug which resets the SOCKS5 proxy hostname and port. In the more recent version I tested (22.4) they're saying it explicitly in the proxy configuration that these settings won't be taken into consideration by web browsers. Why to show that form first of all?
  
  
• Opera - forget about it, it doesn't exist on ARM64/AARCH64

 

So in this round winner is Firefox.

 

Memory consumption

I did a very basic test to see what is memory consumed by different browsers when you just open them up, load the same web site in a single tab, scroll to the end of that page (to force browser to actually load every picture) and results are below. 

 

Needless to mention that I repeated my tests number of times with closing browser and killing all of its possible remainings, to ensure results are more or less stable. Measurements were made by running htop in a tty, comparing "memory used" before the browser was started with what it was when (a) browser just loaded the page (b) I scrolled that page all the way down.

Firefox

When just started showing empty page ~ 270 Mb

Opened a page - 320 Mb

Scrolled the page all way down - 370 Mb

Chromium

When just started showing empty page ~ 260 Mb

Opened a page - 310 Mb

Scrolled the page all way down -  360 Mb

Konqueror

For Konqueror I had to disable the setting to keep a preloaded instance of it, because it wasn't exiting clearly and there was always one process remained.

When just started showing empty page - 170 Mb

Opened a page - 210 Mb

Scrolled the page all way down - 260 Mb

 

Clearly Konqueror is a winner here. But to me they're all loosers. How come we ended up in a world, where the shitty page takes that much RAM? It would have been easier to render the whole fucking page into some kind of JPEG or PNG and show it like this in any picture viewer program.

Retropie Rearm.It edition - quick guide to make it bit more useful for something different, than retrogaming

In my previous post I tried to summarize all the quirks and issues I hit while trying to make RetroArch (and partially Higan) work in Orange PI OS 3.0.0 and Armbian. The long story short - I failed and stopped trying. The reason for that is lack of my own experience at that time and misunderstanding, of what was actually wrong.

But I discovered a much more straightforward way to do that, thanks to a youtube channel I found which lead me to this website - ReARM.it and this discord channel. In a short, the wonderful guy, Arnaldo Valente is keeping a number of github repos, from which he builds images of batocera and retropie for a large number of ARM SBC boards, like the one I have.

I downloaded the fresh image of RetroPie for my Orange Pi 4 LTS board, flashed it to a SD card with Balena Etcher and off we go - everything went smoothly from there. Many retroarch cores are there and working.

Given I needed not only the gaming distro but also something I could use for more generic purposes I went few steps further and installed a number of packages on a top of it (also had my chance to play with nala):

# install nala, so we could potentially easily "undo" all the additional packages I'm about to install
echo "deb https://deb.volian.org/volian/ scar main" | sudo tee /etc/apt/sources.list.d/volian-archive-scar-unstable.list
wget -qO - https://deb.volian.org/volian/scar.key | sudo tee /etc/apt/trusted.gpg.d/volian-archive-scar-unstable.gpg > /dev/null
sudo apt update
sudo install nala-legacy

# install KDE + few extra packages I want to play withnala install task-kde-desktop neofetch kde-full systemsettings /
kwin-x11 kscreen plasma-nm kitty chromium mesa-utils plasma-discover /
 locate konq-plugins libkf5khtml-bin ksysguard bluedevil /
kde-config-sddm kde-config-systemd kde-config-screenlocker

Just few words on why this list is so crazy long. 

At first I just installed task-kde-desktop and was very surprised to see that my KDE Plasma was missing all stuff in the world, even the companion application to configure itself. I tried to fix that by installing kde-full on a top of that, but that alone didn't help. The help came in form of installing systemsettings package.

Another very unexpected issue I've got, is that in KDE all the application windows were created in a top-left corner of the screen and they were missing usual window decorations, like a maximize/minimize/close buttons, window captions - all that stuff. I can't imagine what geniuses decided to call a metapackage kde-full with that -full prefix, given it was missing a window manager. So I had to add the kwin-x11 to the list and start it manually once. 

Small update here: later on I figured it out, that lots of recommended / suggested packages were not installed by default because the distro was disabling this in /etc/apt/apt.conf.d/71-orangepi-no-recommends file
I realized It actually makes a lot of sense, as it allows to install just bare minimum amount of packages, and whatever you find is missing - you just install that and only that

konq-plugins was required for Konqueror so it won't be that barefooted and have all the normal options and configurations like all the other browsers do. The libkf5khtml-bin package was also needed for Konqueror to enable KHTML "engine" (you can switch them in "View" -> "View mode"). The default "Web Engine" of Konqueror doesn't react on Proxy settings and all of the Konqueror plugins were written for KHTML.

ksysguard is a KDE System Monitor app, nice to have all this plots in front of your eyes during your first steps with weighty KDE on such a measly SBC as Orange PI 4 LTS, to see what exact your UI actions are causing system to freak out.

bluedevil is a KDE frontend for bluez (Bluetooth)

plasma-nm - I was  missing the wifi / bluetooth notification icons in a KDE taskbar. This package brought it.  

kde-config-sddm is a KDE' systemsettings plugin (aka KCM - KDE Configuration Module) which allows you to manipulate with sddm settings directly in "System Settings'. Off course you can always go and edit/create config files in /etc/sddm/sddm.conf.d/ I used it to enable autologin for pi user and hide users with UIDs under 3000 (I was experimenting with nix as package manager and it created a lot of extra users which were shown in sddm-greeter)

 

kde-config-systemd and kde-config-screenlocker are two KCMs to play with systemd and to configure timeout and rest settings for screenlock

Making X to start after EmulationStation quits

I wanted my system to follow this behavior:
- by default it should boot into EmulationStation, as most of the time it will be hooked to TV and I'll be only using bluethooth gamepads
- if I quit EmulationStation it should start X.Org with KDE (if I need to do something bigger than gaming)

For that I changed the default systemd target to do not start X at system startup:

sudo systemctl set-default multi-user.target

... so it will launch EmulationStation. But if I quit ES, I want  to launch KDE - so I also modified /etc/profile.d/10-retropie.sh (this script is chain-called while booting into multi-user.target) to change the systemd target on a fly:







$ cat /etc/profile.d/10-retropie.sh  
# launch our autostart apps (if we are on the correct tty and not in X)
if [ "`tty`" = "/dev/tty1" ] && [ -z "$DISPLAY" ] && [ "$USER" = "pi" ]; then
    bash "/opt/retropie/configs/all/autostart.sh"
    sudo systemctl isolate graphical.target
fi

Probably later on I'll add some simple login menu with a timeout so I would be able to  bypass ES start and boot directly into KDE

Fixing some small bugs

Removing splash

There was just one thing which worried, me - is that the idiotic orangepi splash screen was showing up occasionally (when ES was launching RetroArch), so I disabled it at all  in /boot/orangepiEnv.txt

verbosity=1
bootlogo=false
overlay_prefix=rockchip
fdtfile=rockchip/rk3399-orangepi-4-lts.dtb
rootdev=UUID=30ae6b8c-ad3f-46b2-b323-4b9a05653ba9
rootfstype=ext4
extraargs="video=HDMI-A-1:1920x1080@60e"
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u

After all that was done, I noticed that there was a very high CPU usageby sddm-greeter, which is a welcome/login app which flashes up the first in the X session, where you can select what desktop environment to choose. Looks like it's a well known issue, probably related to missing MESA drivers (they were installed by distro creator to some local location), so I fixed it with using this first hit from google, e.g. added this line to /etc/security/pam_env.conf

QT_QUICK_BACKEND DEFAULT=software

Reinstall SDL2

There's also one more thing I found, the SDL2 library which was coming with the distro was compiled without X11 support, so whatever linux native games I tried to start in KDE (like openttd) were requiring it, were firing up "Error: Couldn't find any suitable video driver".

The easiest thing would be to make a backup of that lib (just in case if it breaks something in RetroPie) and install the version from the repo. First check what version is available out there:

apt list libsdl2-2.0-0 -a

And then make a backup of current lib and install the version from repo on a top:

cp /lib/aarch64-linux-gnu/libSDL2-2.0.so.0.18.2 /lib/aarch64-linux-gnu/libSDL2-2.0.so.0.18.2.bak
apt-get download libsdl2-2.0-0=2.0.14+dfsg2-3+deb11u1
dpkg -i ./libsdl2-2.0-0_2.0.14+dfsg2-3+deb11u1_arm64.deb 
cd /lib/aarch64-linux-gnu/
unlink libSDL2-2.0.so.0
ln -s libSDL2-2.0.so.0.14.0  libSDL2-2.0.so.0

The above is lame. Don't do that. I'll update it. You don't want to hack apt cache with "downgrading" just a single package. You want to properly switch to normal SDL2 from debian repo, as I already tested that and it doesn't break "retropie" part of a distro. It might only break some of the linux ports in retropie, but I don't care, since I now have full-fledged desktop environment.

 

getting rid of connect-bluetooth.service

After installing the bluez from repo, apt created a proper bluetooth.serivce fo systemd. In the same time we have a connect-bluetooth.service which was coming as a part of retropie. In order for these two guys to not clash one into another and complaining about that to dmesg and journald

So it's better to disable the service which was coming with RetroPi:

systemctl disable connect-bluetooth.service

Don't you worry, your bluetooth gamepads, keyboards and whatever else stuff will be still working in EmulationStation, they'll be just served by default bluetooth.service. In the worst case scenario, you can always enable it back.

Tweaking KDE to debloat it a bit

Even with this the abovementioned apt setting in place to not install any recommended / suggested packages, KDE brings a lot of extra stuff with it, which is started together with the desktop environment. Like I found I do have a mysql database running as a part of KDE, lol. It was needed for Akonadi. If you don't want that to start automatically (like you're not using messangers on KDE all the time) you can get it disabled it in ~/.config/akonadi/akonadiserverrc

[Debug]
Tracer=null

[%General]
Driver=QMYSQL

[QMYSQL]
Host=
Name=akonadi
Options="UNIX_SOCKET=/run/user/1000/akonadi/mysql.socket"
ServerPath=/usr/sbin/mysqld
StartServer=false

Speaking of myself, I don't have any plans to use any messengers on this system at all, so I just removed these Akonadi packages altogether:

apt remove akonadiconsole akonadi-server

Also I disabled a number of KDE services from starting up automatically. Go to System Settings -> Startup and shutdown -> Background services and figure it out yourself which you don't need. I disabled:

• ColorCorrect Geolocation Updater (and these ppl are telling me Windows is full of bloatware?)
• Free Space Notifier (I'm able to watch after free space myself)
• KScreen2 (for this I just didn't find any reasonable description at all)
• KSysguard (I don't need a fucking deamon to lunch KSysguard! I can lunch it myself)  
• Remote URL change notifier
• Search Folder Updater (I'm an oldfag still using locate) 
• Touchpad (I don't have it).

If you're alike me and hate this modern trend of all operation systems (iOS, Android, Windows, Linux) to splash a whole bulk of alerts / notifications on you, then go to System Settings -> Startup and shutdown -> Autostart and disable KAlert

I also went to System Settings -> File Search and disabled it, as I'm more love to decide it myself when I want to run updatedb to reindex all files for my occasional uses of locate. 

It's kind of strange that the same file indexing option is appearing in two places on System Settings. Might be a UX bug. Will raise it

Go to System Settings -> Workspace behaviour -> Desktop effects and turn as much effects as you can. 

Go to System Settings -> Windows management -> Kwin scripts and disable all scripts   

System Settings ->Display and monitor -> Compositor select XRender until we fix OpenGL drivers

How to debloat your system even further

What I really love about Linux, is that you can configure or fix here almost everything and you really should develop this kind of skills into yourself.

Like in my case, when I brought the KDE I knew what kind of contract with devil I'm signing, with all it's zillion of modules, binaries an apps. But really I don't want  to spend hours understanding them all and carefully select only the ones I need and remove the rest ones. My favorite approach is - bring the default, and then fine tune it.  So what you can do is to make periodical manual system monitoring lookups to see what is running on your machine and what is consuming resources.  

The easiest way to to that is with using KSysGuard or htop. It makes sense to look at the list of running processes, sort them by memory and investigate top ones. Then sort them by CPU time used and do the same. If you find something odd there, lookup to see what package brought that binary.

I'll give you this simple example: I saw some odd cnf-update-db process was spinning on CPU a lot. I decided to see what package brought it to my system. For that it's better to have to update the locate' internal database first and then to find that file in our filesystem: 

$ updatedb
$ locate cnf-update-db
/usr/lib/cnf-update-db
/usr/share/command-not-found/cnf-update-db
$ ls -la /usr/lib/cnf-update-db 
lrwxrwxrwx 1 root root 40 Jan  6  2021 /usr/lib/cnf-update-db -> ../share/command-not-found/cnf-update-db
$ ls -la  /usr/share/command-not-found/cnf-update-db
-rwxr-xr-x 1 root root 683 Jan  6  2021 /usr/share/command-not-found/cnf-update-db

So you see, the first is just a symlink for the second. What package brought the actual file? 

$ dpkg -S  /usr/share/command-not-found/cnf-update-db
command-not-found: /usr/share/command-not-found/cnf-update-db

What other files this package brought?

$ dpkg -L command-not-found
/.
/etc
/etc/apt
/etc/apt/apt.conf.d
/etc/apt/apt.conf.d/50command-not-found
/etc/zsh_command_not_found
/usr
/usr/bin
/usr/lib
/usr/sbin
/usr/share
/usr/share/command-not-found
/usr/share/command-not-found/CommandNotFound
/usr/share/command-not-found/CommandNotFound/CommandNotFound.py
/usr/share/command-not-found/CommandNotFound/__init__.py
/usr/share/command-not-found/CommandNotFound/db
/usr/share/command-not-found/CommandNotFound/db/__init__.py
/usr/share/command-not-found/CommandNotFound/db/creator.py
/usr/share/command-not-found/CommandNotFound/db/db.py
/usr/share/command-not-found/CommandNotFound/util.py
/usr/share/command-not-found/cnf-update-db
/usr/share/command-not-found/command-not-found
/usr/share/command-not-found/command_not_found-0.3.egg-info
/usr/share/doc
/usr/share/doc/command-not-found
/usr/share/doc/command-not-found/README.Debian
/usr/share/doc/command-not-found/README.md
/usr/share/doc/command-not-found/changelog.Debian.gz
/usr/share/doc/command-not-found/copyright
/usr/share/locale
/usr/share/locale/de
/usr/share/locale/de/LC_MESSAGES
/usr/share/locale/de/LC_MESSAGES/command-not-found.mo
/usr/share/locale/fr
/usr/share/locale/fr/LC_MESSAGES
/usr/share/locale/fr/LC_MESSAGES/command-not-found.mo
/usr/share/locale/pl
/usr/share/locale/pl/LC_MESSAGES
/usr/share/locale/pl/LC_MESSAGES/command-not-found.mo
/usr/share/man
/usr/share/man/man8
/usr/share/man/man8/update-command-not-found.8.gz
/usr/share/python3
/usr/share/python3/runtime.d
/usr/share/python3/runtime.d/command-not-found.rtupdate
/var
/var/lib
/var/lib/command-not-found
/usr/bin/command-not-found
/usr/lib/cnf-update-db
/usr/lib/command-not-found
/usr/sbin/update-command-not-found

What this package is about?

$ apt show command-not-found
Package: command-not-found
Version: 20.10.1-1
Priority: optional
Section: admin
Maintainer: Julian Andres Klode <jak@debian.org>
Installed-Size: 105 kB
Depends: apt-file (>= 3.0~exp1~), lsb-release, python3-apt, python3:any
Suggests: snapd
Tag: implemented-in::python, interface::shell, role::program, scope::utility
Download-Size: 26.2 kB
APT-Manual-Installed: yes
APT-Sources: http://deb.debian.org/debian bullseye/main arm64 Packages
Description: Suggest installation of packages in interactive bash sessions

Reading all that I can make quite a precise educated guess what was happening. Do you need this kind of courtesy of bash to give you the package you need to install, when you type some bullshit? If you're new to Linux then probably, in my case - I just better drop that package altogether, so it won't start its reindexing process when I don't expect it.

In some cases you might want to investigate it bit deeper, like some packages might be just buggy and overconsuming resources when they should not. Every case is unique, but the common approach is above. 

 

At the end of the day I'm having a nice looking desktop and together with all other services I'm running (like tor, ) it takes just below 500 Mb of RAM. I think it's kinda nice. 

We can always go beyond and switch KDE to something more light-weight, like dwm, bspwm or even awesome

Debloat it all!

Read a continuation of this story in another post - https://orange-pi-4-lts.blogspot.com/2022/08/debloating-your-linux-even-further.html

From it, you'll learn what important things you need to do, so the SD card you put into your SBC won't die in next year or so.

Some useful links

- Display manager - ArchWiki (archlinux.org)

- Updating RetroPie - RetroPie Docs and FAQ - RetroPie Docs

Total failure: trying to run Retroarch on Orange Pi 4 LTS using stock Linux "OrangePi OS 3.0.0" and Armbian

Retro Gaming on Orange Pi 4 LTS?

I was misfortune enough to buy a SBC (single board computer) called "Orange PI 4 LTS". At first, it looked very promissing - it was having quite a powerfull multicore cpu and built-in BT, WiFi, Ethernet, HDMI and had onboard 16 Gb eMMC chip flashed with some debian (or ARMbian) based linux called "Orange PI OS", but the vendor also provides custom builds of Debian, Ubuntu and Android. What could go wrong? I thought of myself as of experienced linux user, knowing my ways around and knowing how to google things.

The idea behind the purchase was to try this machine out for few simple tasks:

• self hosted photo service like Photoprism, Piwigo, Lychee, Plex, Librephotos or Nextcloud
• retro gaming device, so I could hook up couple of cheap bluetooth gamepads and play along with my little wee in console games I never played, because I had a PC from my first grade in school :)

The unfortunate thing I discovered, that most of the "retro gaming distros" (like Batocera, Recallbox, RetrOrangePi, Lakka) are not supporting this board, which is having ARM CPU Rockchip RK3399. To be entirely honest, some of them are having custom builds to support a very close SBC - RockPro64, which is also RK3399 based, but given it's having a different chip which implements Wifi and Bluetooth - I won't have thouse on my board. I also seen URLs for Orange PI 4 LTS builds on some forums/email threads, so I was bit optimistic.

I decided to start with retroarch, as essentially it's used in number of gaming distros, but eventually I don't like dedicated distros, like game dedicated distros, and having a general purpose distro which I can occasionally use for gaming was looking like a better option to me.

In this post i tried to summarize all the pain you have to walk through to get something like Retroarch working on this shitty machine.

Some Orange PI 4 LTS Specs

CPU RK3399 
4 Gb DDR4 RAM
16 Gb EMMC
WiFi 5 + Bluetooth provided by some rare chip CDW.20U5622-00
GPU Mali T860
• Supports OpenGL ES1.1/2.0/3.0/3.1,OpenVG1.1,OpenCL,DX11
• Support for AFBC

More specs here - http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/orange-pi-4-LTS.html

Official wiki - http://www.orangepi.org/orangepiwiki/index.php/Orange_Pi_4_LTS

Official PDF documentation - https://drive.google.com/file/d/1VnZOfpgrmUapTpcx77PhwJ808eCvkGrE/view?usp=sharing

Official linux images (and other downloads) - http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/service-and-support/Orange-pi-4-LTS.html

Stop reading it here

Hello there. It's older and wiser me speaking to you from future. Please don't take it close to heart whatever you'll read below. It was me just gaining my own experience with Linux @ desktop after a very very very long break of 15 years. 

 

Most of the problems I was having were eventually solved. Just read other posts from this blog, especially this and this.

An attempt to make it straightforward - "Retroarch on Orange Pi OS 3.0.0" - FAILED

At first I just installed Retroarch with APT and it didn't work. I mean it started up but then right after it was crashing. I had to play a bit and ran it from terminal with --verbose option to see what is going wrong. The trick was - that shitty Retroarch had installed its one config file to usual to me location like /etc/retroarch/retroarch.cfg but when I was running it under my own non-root user, it was generating a fucking new config file under ~/.config/retroarch/retroarch.cfg. So whatever changes I was trying under /etc/ were all wasted, because it wasn't even looking them up. Great job, retroarch developers! Why to bother to deploy that pesky config file in /etc/ with package first of all, if it's not even being used?

Anyways the issues with the retroarch running on out-of-box Orange Pi OS 3.0.0. were more or less overcame by:

• changing the default "skin" from "xmb" to "rgui". That was really unexpected thing
• setting the videodriver from "gl" to "sdl2"  (for some reason OpenGL drivers didn't quite work in that bollocks "Orange PI OS")

So I got at my hands very nice looking Retroarch, which appeared to me just a useless menu . No matter what librerto cores I tried - from internet, from apt - nothing worked. Every time it was the same shit - "segmentation fault", whenever I tried to run some game using retroarch core. I gave up trying

Another attempt to make it - other conventional emulators ("Higan on Orange PI OS") - SUCCEEDED

I was damned pissed off to see Higan and few other emulators I installed through apt were working just fine. Oh those retroarch developers, I love you. I don't know what kind of shit you were smoking, but its ain't for good.

So what then? I don't like the idea of using old-facioned window of Higan with my keyboard and mouse to start the game first, so I can use bluetooth gamepad for gaming. It's like I need to have 3 devices nearby after switching on the PC instead of having just one. So I still needed to make that shitty Retroarch (or any suitable replacement) to work

Retroarch flatpak on Orange PI OS - FAILED

At this point I started to think it might be something wrong with the retroarch package itself, given higan was working just fine. As I already learnt there were some signs to it, like not all the "skins" were working. I decided to give it a try and install it via modern blows-and-whistles thing called  "flatpack". By the way I love the idea, it's much more advanced compared to all regular package managers in distros and it's really a future of software distribution because it solves all this integration hell of ordinary linux distros. Here's what you need to do (see https://github.com/flathub/org.libretro.RetroArch):

flatpak remote-add --user --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
flatpak install --user -y flathub org.libretro.RetroArch
flatpak run org.libretro.RetroArch

./.var/app/org.libretro.RetroArch/config/retroarch/retroarch.cfg
core_updater_buildbot_cores_url = "https://buildbot.libretro.com/nightly/linux/armhf/latest/"
https://buildbot.libretro.com/nightly/android/latest/arm64-v8a/

The funny thing is, this version works just fine, but it also missing "cores". I tried few repos with retroarch cores, but coudln't find cores for ARM64 working with my linux anywhere on internet yet. 

Welcome to the fucking world of ARM, which is told to be a future of computer industry, but it's all again down to missing software and pesky linux compatibilities issues. I know exactly why ppl are stick to x86 - because of all this shit.

GLXInfo on Orange PI

orangepi@orangepi4-lts:~$ glxinfo | grep version

server glx version string: 1.4

client glx version string: 1.4

GLX version: 1.4

    Max core profile version: 4.5

    Max compat profile version: 3.1

    Max GLES1 profile version: 1.1

    Max GLES[23] profile version: 3.2

OpenGL core profile version string: 4.5 (Core Profile) Mesa 20.3.5

OpenGL core profile shading language version string: 4.50

OpenGL version string: 3.1 Mesa 20.3.5

OpenGL shading language version string: 1.40

OpenGL ES profile version string: OpenGL ES 3.2 Mesa 20.3.5

OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

    GL_EXT_shader_implicit_conversions, GL_EXT_shader_integer_mix, 

Upgrade Mesa3d by building them from the very last source - FAILED

At some point I spoiled something with my videodrivers. Mesa drivers there kind a worked at the beginning, but then I started to have problems with them after a number of  experiments and additional packages being installed. Like initially glmark2-es2 tool was working, but then it stopped:

orangepi@orangepi4-lts:~$ glmark2-es2 
arm_release_ver of this libmali is 'r18p0-01rel0', rk_so_ver is '4'.Error: eglInitialize() failed with error: 0x3001
Error: eglInitialize() failed with error: 0x3001
Error: main: Could not initialize canvas

I thought there might be some relation to my failed attempts to make any of the libretro cores working in RetroArch (they all were failing with segfault), so I decided to attempt to upgrade that whole shitty Mesa3d drivers (follow https://docs.mesa3d.org/install.html for full instructions):
Install prereq:

apt install meson ninja-build
meson --version
ninja --version

Download and build mesa: (there might be newer version already)

cd
mkdir MESA
cd MESA
wget https://archive.mesa3d.org//mesa-22.1.5.tar.xz
tar xf mesa-22.1.5.tar.xz
rm mesa-22.1.5.tar.xz
# uncomment mnaually deb-src lines in /etc/apt/sources.list
apt-update
apt-get build-dep mesa
cd mesa-22.1.5/
mkdir installdir
export MESA_INSTALLDIR=`pwd`/installdir

# originally it was just
# meson builddir/ -Dprefix="$MESA_INSTALLDIR"
# but then I looked for panfrost support page - https://docs.mesa3d.org/drivers/panfrost.html
meson setup --wipe builddir/ -Dprefix="$MESA_INSTALLDIR" -Ddri-drivers= -Dvulkan-drivers= -Dgallium-drivers=panfrost -Dllvm=disabled
ninja -C builddir/ install
LD_LIBRARY_PATH="$MESA_INSTALLDIR/lib64" glxinfo

So the above fails on running "meson" (a kinda replacement for ./configure scripts in other open source projects) with this:

Dependency libdrm_nouveau found: NO found 2.4.104 but need: '>=2.4.109'
Run-time dependency libdrm_nouveau found: NO (tried cmake)

meson.build:1620:4: ERROR: Invalid version of dependency, need 'libdrm_nouveau' ['>=2.4.109'] found '2.4.104'.

A full log can be found at /home/orangepi/MESA/mesa-22.1.5/builddir/meson-logs/meson-log.txt

So in my shitty distro, the latest version of libdrm_nouveau is indeed 2.4.104 and given it's some kind of interface library of the actual shit which is compiled into kernel I cannot move ahead without updating kernel. I hate linux.

An attempt to install the most recent Armbian - SUCCESS

I have given up the idea of making that "Orange Pi OS 3.0.0" frankenstain to work, so I decided to flash an SD card with this armbian image to see if things are working fine there - https://www.armbian.com/orange-pi-4-lts/

It worked just fine, I managed to boot my Orange PI 4 LTS from SD card, to which I flashed the Armbian XFCE image with "balena etcher" exactly how instruction says. Te original "Orange PI OS" stayed on EMMC. I'll prob return to it bit later. The first thing I did is usual apt upgrade ; apt upgrade . Interestingly though, that the distro is having like zillion of different APT repos connected by default, and packages are coming to it from all over the place, like from Ubutntu, Armbian and handful of personal package archives (PPAs). So during that "apt upgrade" phase, some package attempted to override /etc/issue and /etc/issue.net files. Funny.

But now I got Armbian 22.05.4 running linux kernel 5.15-52

Checking OpenGL drivers on Armbian until I  mess with it

export DISPLAY=:0.0 glmark2 - works perfectly

root@orangepi4-lts:~# glxinfo | grep -i version
server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
    Version: 22.3.0
    Max core profile version: 3.1
    Max compat profile version: 3.1
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.1
OpenGL core profile version string: 3.1 Mesa 22.3.0-devel (git-b731be2 2022-08-06 jammy-oibaf-ppa)
OpenGL core profile shading language version string: 1.40
OpenGL version string: 3.1 Mesa 22.3.0-devel (git-b731be2 2022-08-06 jammy-oibaf-ppa)
OpenGL shading language version string: 1.40
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 22.3.0-devel (git-b731be2 2022-08-06 jammy-oibaf-ppa)
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10
    GL_EXT_shader_implicit_conversions, GL_EXT_shader_integer_mix, 

Running RetroArch on Armbian - FAILED

It's not an entire failure thought. I manged to apt install it right from connected ubuntu repo, and it did startup even with that default "skin" (they call it "menu driver") which didn't work on "Orange PI OS". I installed some cores with apt:

$ apt list --installed | grep libretro-

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

libretro-bsnes-mercury-accuracy/jammy,now 094+git20160126-3build1 arm64 [installed]
libretro-bsnes-mercury-performance/jammy,now 094+git20160126-3build1 arm64 [installed]
libretro-core-info/jammy,jammy,now 1.4.1+git20170210-1 all [installed]
libretro-snes9x/jammy,now 1.53+git20160522-1build1 arm64 [installed]

... but none of them working properly. It looks like this, whenver you attempt to run any game from retroarch, the app shuts down with this shit printed to console:

retroarch --verbose
...
[INFO] [GL]: VSync => on
[INFO] [EGL]: eglSwapInterval(1)
[INFO] Written to playlist file: /home/bugman/.config/retroarch/content_history.lpl
*** longjmp causes uninitialized stack frame ***: terminated
Aborted (core dumped)

Given the very last message in the log is related to VSync - I tried to switch that beast off, but it still getting printed like it's own. Oh those RetroArch developers. Another fucking bug. Did I tell you how I hate all that already?

Running Higan on Armbian - FAILED

This shit was very unexpected, because higan was working just perfectly in Orange PI OS. I installed it from apt and whenever I try to open a game ROM with it I get:

$ higan 

*** longjmp causes uninitialized stack frame ***: terminated

Aborted (core dumped)

I definitely need to investigate it further. Looks like on this Armbian the error message "longjmp causes uninitialized stack frame" is just the same as "segmentation  fault" on  Orange PI OS

I ran it under gdb and when it's about to crash the gdb prints this:

Thread 1 "higan" received signal SIGUSR1, User defined signal 1.

0x0000fffff6baf200 in ?? () from /lib/aarch64-linux-gnu/libc.so.6

And just in case, I tried to turn off audio and all possible combinations of Video driver (some of them were not working at all, like OpenGL).

Raised this one - https://github.com/higan-emu/higan/issues/190

The version I have on Armbian is:

$ apt policy higan

higan:

  Installed: 106-2build2

  Candidate: 106-2build2

  Version table:

 *** 106-2build2 500

        500 http://ports.ubuntu.com jammy/universe arm64 Packages

        100 /var/lib/dpkg/status

Building higan from sources - IN PROGRESS

wget https://github.com/higan-emu/higan/archive/refs/tags/v110.zip

unzip v110.zip

apt-get install build-essential libgtk2.0-dev libpulse-dev \

    mesa-common-dev libgtksourceview-3.0-dev libcairo2-dev libsdl1.2-dev \

    libxv-dev libao-dev libopenal-dev libudev-dev

(it actually requires gtksourceview-2.0 - but it's not in APT repos, so with 3rd version it doesn't compile)

root@orangepi4-lts:~# cd /tmp/higan-110/

root@orangepi4-lts:/tmp/higan-110# make -C higan

make: Entering directory '/tmp/higan-110/higan'

Targeting higan ...

make: sdl2-config: No such file or directory

make: sdl2-config: No such file or directory

Compiling ../hiro/hiro.cpp ...

Package gtksourceview-2.0 was not found in the pkg-config search path.

Perhaps you should add the directory containing `gtksourceview-2.0.pc'

to the PKG_CONFIG_PATH environment variable

No package 'gtksourceview-2.0' found

In file included from ../hiro/core/core.cpp:8,

                 from ../hiro/hiro.cpp:5:

../hiro/core/../gtk/header.hpp:34:12: fatal error: cairo.h: No such file or directory

   34 |   #include <cairo.h>

      |            ^~~~~~~~~

compilation terminated.

make: *** [../hiro/GNUmakefile:73: obj/hiro-gtk2.o] Error 1

make: Leaving directory '/tmp/higan-110/higan'

Need to find that lib or its replacement, or to take the same version installed to my system (v106 instead of v110). This is also what I got as a reply to my https://github.com/higan-emu/higan/issues/190 ticket - to build it myself

Building MESA/panfrost on Armbian

As days are passing by, I'm getting more and more knowledge about all this videodrivers topic. I was given with a good lead, that Orange PI OS is using Mali drivers in MESA, not the Panfrost ones. I checked what kind of drivers are used now in Armbian - and it was Panfrost, but the version of Mali itself was bit worrying 22.3.0-devel 

Thus I decided to take my chance and build Mesa once again, this time all libraries were there and I managed to do that. Here're the comparison results of Mesa 22.3.0-devel (the  one, which came out of the box) and the version I've built - 22.1.5:

bugman@orangepi4-lts:~/MESA/mesa-22.1.5$ LD_LIBRARY_PATH="$MESA_INSTALLDIR/lib/aarch64-linux-gnu/" glmark2 

=======================================================

    glmark2 2021.02

=======================================================

    OpenGL Information

    GL_VENDOR:     Panfrost

    GL_RENDERER:   Mali-T860 (Panfrost)

    GL_VERSION:    3.1 Mesa 22.1.5

=======================================================

[build] use-vbo=false: FPS: 114 FrameTime: 8.772 ms

[build] use-vbo=true: FPS: 129 FrameTime: 7.752 ms

[texture] texture-filter=nearest: FPS: 144 FrameTime: 6.944 ms

[texture] texture-filter=linear: FPS: 119 FrameTime: 8.403 ms

[texture] texture-filter=mipmap: FPS: 126 FrameTime: 7.937 ms

[shading] shading=gouraud: FPS: 125 FrameTime: 8.000 ms

[shading] shading=blinn-phong-inf: FPS: 131 FrameTime: 7.634 ms

[shading] shading=phong: FPS: 114 FrameTime: 8.772 ms

[shading] shading=cel: FPS: 146 FrameTime: 6.849 ms

[bump] bump-render=high-poly: FPS: 138 FrameTime: 7.246 ms

[bump] bump-render=normals: FPS: 143 FrameTime: 6.993 ms

[bump] bump-render=height: FPS: 166 FrameTime: 6.024 ms

[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 141 FrameTime: 7.092 ms

[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 131 FrameTime: 7.634 ms

[pulsar] light=false:quads=5:texture=false: FPS: 139 FrameTime: 7.194 ms

[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 119 FrameTime: 8.403 ms

[desktop] effect=shadow:windows=4: FPS: 126 FrameTime: 7.937 ms

[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 118 FrameTime: 8.475 ms

[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 119 FrameTime: 8.403 ms

[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 119 FrameTime: 8.403 ms

[ideas] speed=duration: FPS: 120 FrameTime: 8.333 ms

[jellyfish] <default>: FPS: 132 FrameTime: 7.576 ms

[terrain] <default>: FPS: 27 FrameTime: 37.037 ms

[shadow] <default>: FPS: 126 FrameTime: 7.937 ms

[refract] <default>: FPS: 57 FrameTime: 17.544 ms

[conditionals] fragment-steps=0:vertex-steps=0: FPS: 175 FrameTime: 5.714 ms

[conditionals] fragment-steps=5:vertex-steps=0: FPS: 160 FrameTime: 6.250 ms

[conditionals] fragment-steps=0:vertex-steps=5: FPS: 164 FrameTime: 6.098 ms

[function] fragment-complexity=low:fragment-steps=5: FPS: 156 FrameTime: 6.410 ms

[function] fragment-complexity=medium:fragment-steps=5: FPS: 123 FrameTime: 8.130 ms

[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 135 FrameTime: 7.407 ms

[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 154 FrameTime: 6.494 ms

[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 119 FrameTime: 8.403 ms

=======================================================

                                  glmark2 Score: 128 

=======================================================

bugman@orangepi4-lts:~/MESA/mesa-22.1.5$ glmark2 

=======================================================

    glmark2 2021.02

=======================================================

    OpenGL Information

    GL_VENDOR:     Panfrost

    GL_RENDERER:   Mali-T860 (Panfrost)

    GL_VERSION:    3.1 Mesa 22.3.0-devel (git-8bffd60 2022-08-08 jammy-oibaf-ppa)

=======================================================

[build] use-vbo=false: FPS: 114 FrameTime: 8.772 ms

[build] use-vbo=true: FPS: 136 FrameTime: 7.353 ms

[texture] texture-filter=nearest: FPS: 185 FrameTime: 5.405 ms

[texture] texture-filter=linear: FPS: 170 FrameTime: 5.882 ms

[texture] texture-filter=mipmap: FPS: 158 FrameTime: 6.329 ms

[shading] shading=gouraud: FPS: 148 FrameTime: 6.757 ms

[shading] shading=blinn-phong-inf: FPS: 141 FrameTime: 7.092 ms

[shading] shading=phong: FPS: 142 FrameTime: 7.042 ms

[shading] shading=cel: FPS: 150 FrameTime: 6.667 ms

[bump] bump-render=high-poly: FPS: 149 FrameTime: 6.711 ms

[bump] bump-render=normals: FPS: 140 FrameTime: 7.143 ms

[bump] bump-render=height: FPS: 120 FrameTime: 8.333 ms

[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 134 FrameTime: 7.463 ms

[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 160 FrameTime: 6.250 ms

[pulsar] light=false:quads=5:texture=false: FPS: 124 FrameTime: 8.065 ms

[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 119 FrameTime: 8.403 ms

[desktop] effect=shadow:windows=4: FPS: 119 FrameTime: 8.403 ms

[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 119 FrameTime: 8.403 ms

[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 119 FrameTime: 8.403 ms

[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 119 FrameTime: 8.403 ms

[ideas] speed=duration: FPS: 120 FrameTime: 8.333 ms

[jellyfish] <default>: FPS: 129 FrameTime: 7.752 ms

[terrain] <default>: FPS: 27 FrameTime: 37.037 ms

[shadow] <default>: FPS: 114 FrameTime: 8.772 ms

[refract] <default>: FPS: 59 FrameTime: 16.949 ms

[conditionals] fragment-steps=0:vertex-steps=0: FPS: 119 FrameTime: 8.403 ms

[conditionals] fragment-steps=5:vertex-steps=0: FPS: 123 FrameTime: 8.130 ms

[conditionals] fragment-steps=0:vertex-steps=5: FPS: 153 FrameTime: 6.536 ms

[function] fragment-complexity=low:fragment-steps=5: FPS: 151 FrameTime: 6.623 ms

[function] fragment-complexity=medium:fragment-steps=5: FPS: 152 FrameTime: 6.579 ms

[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 135 FrameTime: 7.407 ms

[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 160 FrameTime: 6.250 ms

[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 153 FrameTime: 6.536 ms

=======================================================

                                  glmark2 Score: 132 

=======================================================

As you can see, -devel drivers are giving slightly better performance, but it was just a single run of benchmark. But from the outcome perspective, it didn't change a bit - both higan and retroarch are keep failing the same way they did with "longjmp causes uninitialized stack frame".

Sidenote - some flags you can affect MESA drivers

https://docs.mesa3d.org/envvars.html

Sidenote on using Bluetooth joystick/gamepad on Linux

evtest - can be installed from packages, a handy tool to make sure your Bluetooth joystick / gamepad works fine. Mine was working fine and was found under /dev/input/event10

I prefer to test hardware in some lightweight dedicated testing tools like this, to make sure at least it can be detected and works normally, before moving to something bigger. I quite frequent google things like "how to ensure X is working?" or "how can I get to know B is being detected". This whole topic is very new to me, as I was running Linux on servers for a couple decades, but my desktop experience with all the desktop grade hardware like printers, scanners, usb camers, videocards, bluetooth and wifi is very limited

Surprisingly my own Bluetooth gamepads (some $15 cheap Defenders) were successfully paired in linux and were working just fine.

retrorangepi

https://pcminipro.ru/os/pervyj-zapusk-i-pervaya-nastrojka-retrorangepi/ [ERROR] [XVideo]: Failed to find valid XvPort or format. libmali-midgard-t86x-r18p0-x11/now 1.9-1 arm64 [installed,local]

Sidenote on why I hate APT so much or accidental removal of important packages I cannot reinstall

Be careful while using shity debian-based distros with its shitty apt. I installed some package (can't even remember what) via apt and installed all the dependencies. They all were listed in apt log on a screen. So far so good. But later I decided to remove that package, but dependencies it installed before were not removed. I took them from the log and ran "apt remove xxx xxx" command. What happened then, it started to remove some extra packages I didn't ask him to, like below mentioned "orangepi-config". The issue was is that the shitty "Orange Pi OS" distro doesn't have all its packages in the repo, so there's no chance to restore it back with using apt again.

root@orangepi4-lts:~# apt remove libsdl2-dev libboost-system-dev libboost-filesystem-dev libboost-date-time-dev libboost-locale-dev libfreeimage-dev libfreetype6-dev libeigen3-dev libcurl4-openssl-dev libasound2-dev libgl1-mesa-dev build-essential cmake fonts-droid-fallback
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer required:
  cmake-data g++ g++-10 gir1.2-ibus-1.0 libblkid-dev libboost-atomic1.74-dev libboost-atomic1.74.0 libboost-chrono1.74-dev libboost-chrono1.74.0 libboost-date-time1.74-dev libboost-date-time1.74.0 libboost-filesystem1.74-dev
  libboost-filesystem1.74.0 libboost-locale1.74-dev libboost-locale1.74.0 libboost-serialization1.74-dev libboost-serialization1.74.0 libboost-system1.74-dev libboost-system1.74.0 libboost-thread1.74-dev libboost-thread1.74.0
  libboost1.74-dev libbrotli-dev libdbus-1-dev libegl1-mesa-dev libffi-dev libfreeimage3 libfreetype-dev libgles-dev libgles1 libglib2.0-dev libglib2.0-dev-bin libglvnd-dev libibus-1.0-5 libibus-1.0-dev libice-dev libilmbase25
  libirrlicht1.8 libjxr0 libleveldb1d liblua5.1-0 libmount-dev libopenexr25 libopengl-dev libopengl0 libpcre16-3 libpcre2-dev libpcre2-posix2 libpcre3-dev libpcre32-3 libpcrecpp0v5 libpng-dev libpq5 libpulse-dev libraw20 librhash0
  libselinux1-dev libsepol1-dev libsm-dev libsndio-dev libspatialindex6 libstdc++-10-dev libudev-dev libwayland-bin libwayland-dev libxcursor-dev libxfixes-dev libxi-dev libxinerama-dev libxkbcommon-dev libxrandr-dev libxrender-dev
  libxss-dev libxt-dev libxv-dev libxxf86vm-dev python3-distutils python3-lib2to3 uuid-dev x11proto-input-dev x11proto-randr-dev x11proto-scrnsaver-dev x11proto-xf86vidmode-dev x11proto-xinerama-dev zlib1g-dev
Use 'apt autoremove' to remove them.
The following packages will be REMOVED:
  build-essential cmake fonts-droid-fallback libasound2-dev libboost-date-time-dev libboost-filesystem-dev libboost-locale-dev libboost-system-dev libcurl4-openssl-dev libeigen3-dev libfreeimage-dev libfreetype6-dev libgl1-mesa-dev
  libsdl2-dev minetest minetest-data orangepi-config
0 upgraded, 0 newly installed, 17 to remove and 0 not upgraded.
After this operation, 73.3 MB disk space will be freed.
Do you want to continue? [Y/n] y
(Reading database ... 205716 files and directories currently installed.)
Removing orangepi-config (3.0.0) ...
Removing build-essential (12.9) ...
Removing cmake (3.18.4-2+deb11u1) ...
Removing minetest (5.3.0+repack-2.1+deb11u1) ...
Removing minetest-data (5.3.0+repack-2.1+deb11u1) ...
Removing fonts-droid-fallback (1:6.0.1r16-1.1) ...
Removing libsdl2-dev:arm64 (2.0.14+dfsg2-3+deb11u1) ...
Removing libasound2-dev:arm64 (1.2.4-1.1) ...
Removing libboost-date-time-dev:arm64 (1.74.0.3) ...
Removing libboost-filesystem-dev:arm64 (1.74.0.3) ...
Removing libboost-locale-dev:arm64 (1.74.0.3) ...
Removing libboost-system-dev:arm64 (1.74.0.3) ...
Removing libcurl4-openssl-dev:arm64 (7.74.0-1.3+deb11u2) ...
Removing libeigen3-dev (3.3.9-2) ...
Removing libfreeimage-dev (3.18.0+ds2-6) ...
Removing libfreetype6-dev:arm64 (2.10.4+dfsg-1+deb11u1) ...
Removing libgl1-mesa-dev:arm64 (20.3.5-1) ...
Processing triggers for bamfdaemon (0.5.4-2) ...
Rebuilding /usr/share/applications/bamf-2.index...
Processing triggers for desktop-file-utils (0.26-1) ...
Processing triggers for hicolor-icon-theme (0.17-2) ...
Processing triggers for gnome-menus (3.36.0-1) ...
Processing triggers for man-db (2.9.4-2) ...
Processing triggers for mailcap (3.69) ...
Processing triggers for fontconfig (2.13.1-4.2) ...
^C

Adding keys for PPA

If your apt is complaining on not being able to verify the key of the repo you just added to /etc/apt/sources.list or /etc/apt/sources.list.d/ like this:

GPG error: http://armbian.12z.eu/apt buster InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 93D6889F9F0E78D5

... the easiest would be to open that repo in your web browser to see if there's a key file lying around somewhere on a top, it should be named like something.key. Download that file and run:

apt-key add ~orangepi/Downloads/armbian.key

Now you're free to run your apt command once again.

Using box64

https://github.com/ptitSeb/box64

https://box64.debian.ryanfortner.dev/

https://box86.org/2022/02/box86-box64-are-easy-to-use/

https://box86.org/2022/03/box86-box64-vs-qemu-vs-fex-vs-rosetta2/

 

Install directly from repo:

sudo wget https://ryanfortner.github.io/box64-debs/box64.list -O /etc/apt/sources.list.d/box64.list
wget -O- https://ryanfortner.github.io/box64-debs/KEY.gpg | gpg --dearmor | sudo tee /usr/share/keyrings/box64-debs-archive-keyring.gpg 
sudo apt update && sudo apt install box64 -y

 

or build it yourself:

 

git clone https://github.com/ptitSeb/box64
cd box64
mkdir build; cd build; cmake .. -DRPI4ARM64=1 -DCMAKE_BUILD_TYPE=RelWithDebInfo
make -j4
sudo make install

 

Everything is systemd now

The last time I was running linux on my desktop was back in 2011 or so. That time having things like:

• ntpd, crond 
• runlevels and all the init.d scripts 
• conf.d scripts

 ... was a normal and straightforward thing to use. Just google for "systemV" or "System5"

But things had changed since then. In favor for fewer seconds less of the wait time for a system boot up (which was probably one and only downside of having things starting sequentially), Linux distros have moved to systemd with its cumbersome configs with units, targets, timers and all that stuff.

And yeah, ntpd is also gone, it's now chrony.service.

"Fuck, I hate changes" - I thought at first. But then, after a while, I realized the new scheme of things brings much more flexibility, if you use it in a right way.

So instead of runlevels we now have some.targets. Targets can include (aka require) other targets. Like for your graphical.target where you have X.Org started you might want to have network.target to be reached as well. It makes a lot of sense as it gives you more clear nesting of service groups

Here's the quick cheat sheet.

What is the default target Linux will try to boot into	systemctl get-default
Change default target	systemctl set-default <target_name>
List all units (services, targets, timers) including disabled	systemctl list-unit-files
What is current target(s)	with systemd it  can be more than one: systemctl list-units --type target --state active
Change current target	systemctl isolate <target_name>
Show dependency tree of what default target requires / specific target requires	systemctl list-dependencies [<target_name>]
See status and other details about specific unit (service, target, ...)	systemctl status <unit>
See the whole system journal logs in "tail" mode	journalctl -f
See specific unit journal logs in "tail" mode	journalctl -f -u sshd.service

 

Quick guide to Tor

Installation

The apt takes care of everything, including creation of proper systemd units and starting the service up. The only additional thing we install on a top of tor is torify which makes it super easy to wrap all the network traffic from any binary to be tunneled into SOCKS5 proxy created by tor: 

apt install tor torify

Using torify wrapper

torify curl icanhazip.com
torify lynx rutracker.org
torify --shell

Configure Tor as https proxy (skip that)

In some rare cases you might want to use HTTP proxy instead of SOCKS5.
Tor can create you a local one out of the box for you. For that modify tor config and restart the service:

echo "HTTPTunnelPort 9080" >> /etc/tor/torrc
service tor restart

Be careful while using it, it's not "normal" HTTP proxy, as doc is suggesting it's HTTP CONNECT type of proxy. Don't know exactly what that is, need to google that, but my simple test worked just fine:

https_proxy=localhost:9080 curl https://icanhazip.com

Configure SOCKS5 proxy in KDE

For some weird reason Chromium is too limited in terms of how can you configure it from UI side, proxy-wise. Like in my case it can only "nest" proxy settings from the system - in my case from KDE systemsettings. 

1) open "System Settings" KDE app or run it /usr/bin/systemsettings5

2) navigate yourself to "proxy" configuration. Just type "proxy" in a top left search

3) select "Use manually specified proxy configuration option"

4) leave all the fields blank apart from "SOCKS5 proxy", where you put localhost port 9050

5) if you want that proxy (tor) to be used only for specific domains, specify them in the "Exceptions" list, comma separated and tick the checkbox "Use proxy settings only for addresses in the Exception list". If you want to include some domain with all its subdomains you'll need to precede it with dot: ".domain.com"
6) hit apply it should be picked up immediately by Chromium - just go there and test, no need for relaunch 

Create another application link for Chromium to run it under Tor SOCKS5 proxy

As an alternative option  I have just created another "application link" for Chromium but this time it starts the browser with CLI option to use SOCKS5 for everything:

root@orangepi4-lts:/usr/share/applications# diff chromium-tor.desktop chromium.desktop  
3c3
< Name=Chromium over Tor
---
> Name=Chromium Web Browser
131c131
< Exec=/usr/bin/chromium --proxy-server="socks5://localhost:9050" --user-data-dir=/tmp %U

---
> Exec=/usr/bin/chromium %U

And that's it. Now if I need to open some website which is blocked in my country I just open that "Chromium over tor" link. 

If you gonna make any further modifications to this .desktop file, make sure to delete the app from "favorites" and add it again. The trick is, when you add the app to "favorites" in KDE, it looks like it silently copies that .desktop file from /usr/share/applications to somewhat else location, so whatever changes you're making to original .desktop file from /usr are not getting reflected on your shortcut from Favorites tab.  

The  --user-data-dir trick was needed to actually launch a second Chromium instance, if you already have an instance of browser running without SOCKS proxy. Without it, Chromium just launch an additional process to existing group of processes, where that --proxy-server parameter wasn't set. 

https://superuser.com/questions/1281208/command-line-option-to-open-new-chrome-process-group 

Much better option - use Firefox + plugins

Firefox also a bit lazy one in terms of properly fetching KDE system settings and it requires its own configuration. But there're plenty of plugins you can use.
See here for more details - https://orange-pi-4-lts.blogspot.com/2022/08/few-notes-on-web-browsers-they-all-are.html

So I have Tor up and running. And I configured my browser to use it as SOCKS5 proxy. What's next?

Well if you want to bypass territorial restrictions, like if your government is blocking some websites - you can use Tor as a transport for your traffic to bypass all those your local firewalls and visit web sites you want. It works like that:

1) Your web browser will be connecting to SOCKS5 proxy, which is also running on your machine, created by Tor.

2) Tor's SOCKS5 proxy will be taking your traffic and route it through number (usually 3) of Tor network relay until it exits tor network and goes back to public internet via one of the Tor's network exit nodes. 

 

3) You can affect tor to tell it what exit node to use. Or rather what country that exit node should belong to. Because if you're living in country A which is blocking a website B located in C, it doesn't make sense to route your HTTP requests from browser via Tor in a way they will exit from tor network to Public Internet via exit node located in country A :)

If you want to access your home PC from eveywhere, even though it might be located behind your router's NAT, which might be located behind your internet service provider' NAT (Carrier Grade NAT - or CGNAT) you can spin up a tor hidden service. It's a pretty straighforward thing to do:

1) choice how you want to access your home pc, like by the means of what service - sshd? xrdp? vnc? set that up and make sure it's working in your LAN (nmap localhost, try to make a local connection from other device within the same network).

Make sure you set your service up in a secured manner, which means no simple passwords, no logins under root, traffic should be encrypted - all that stuff. Check /etc/shadow just to see you don't have any extra users with defined passwords. Check /etc/passwd to ensure you don't have any unknown local user records allowing someone to log in:

cat /etc/shadow
cat /etc/passwd | grep -v nologin

2) edit /etc/tor/torrc to add (or uncomment) these lines:

HiddenServiceDir /var/lib/tor/hidden_service/
HiddenServicePort 2222 127.0.0.1:22

What it means is that within the Tor network your host will be exposing a port number 2222 (just for the sake of obfuscating things a bit). Whatever connections will be made to it will go to your localhost' 22 port (which is my SSHD port). Adjust it to your taste if you want to. Like if you want to use different method of accessing you will

3) restart tor and see what onion hostname you've got

systemctl restart tor

cat /var/lib/tor/hidden_service/hostname

4) that's it! now you can go to some other host in any remote place in the world, configure Tor there and establish a connection to your h82ufjjd293kd29fj.onion:2222 port via SSH. Just make sure the client program you'll be using (ssh client, rdp client, vnc client) will be routing its traffic to that host local SOCKS5 proxy provided by tor

Using tor bridges

It might be the case, that your local tor service won't be able to connect to Tor network. This happens in countries which are attempting to ban Tor - so they force their ISPs (internet service providers) to block connections to tor entry nodes.

But the great thing is, community is helping us in form of running additional entry nodes, aka tor bridges. In order to configure them you'll need to do the following:

1) install obfs4proxy:

apt install obfs4proxy

2) go to https://bridges.torproject.org/bridges/?transport=obfs4 enter the CAPTCHA and get some bridges for you. They will be in a format like:

obfs4 123.45.67.89:1234 JISJGOSESDFOKF3 cert=F3g9j29jfxxx/UUIJN3d8Qf77NQw iat-mode=0

The more you get - the better.

 

3) add the below lines to your /etc/tor/torrc:

UseBridges 1
ClientTransportPlugin obfs4 exec /usr/bin/obfs4proxy
Bridge obfs4 123.45.67.89:1234 JISJGOSESDFOKF3 cert=F3g9j29jfxxx/UUIJN3d8Qf77NQw iat-mode=0 

 

4) restart tor and see how it goes now:

/etc/init.d/tor restart
journalctl -u tor@default -a -f

 

Homework

- modify tor config even more to accept connections from anyone in my home WiFi network, limit the relay traffic, get to know how can I monitor network activity coming through tor.service

- to read more about tor, torify, SOCKS5

- why does Tor officially publishes list of IPs for their exit nodes (https://check.torproject.org/torbulkexitlist)? It doesn't make any sense. Answer

- how does the tor service on my PC know where to connect? Does it have any list of IPs or something? Just curious if these IPs will be blocked in my country and what will be the workaround

- speaking of HTTP_PROXY, if I can use http_proxy to access https resources?

Disable mouse support in Vim

For long decades I was using Vim while being connected to a linux/unix server from windows machine via Putty. Then I was having Fedora 4 (or 5) as my main desktop for a 5 more years. And now, when I return back to Linux as a desktop os on my SBC it just drives me crazy, what kind of stupid mouse integration Vim is having by default. Good news is, it's really easy to fix:

echo "set mouse=" >> /etc/vim/vimrc 

echo "set ttymouse=" >> /etc/vim/vimrc

Missing all appplication links and icons in KDE Plasma launcher?

This might happen because of failed / unfinished update. The fix is quick and easy, run the below as user, in which session you're experiencing this:

$ kbuildsycoca5