Showing posts with label tuning your system. Show all posts
Showing posts with label tuning your system. Show all posts

Ultimate cleanup of Debian/Ubuntu/POP OS/Elementary/whatever-is-using-APT and RPM based distros

In the previous exercise we have removed all the extra/unwanted/unneeded services from our distro, this time we are going to reclaim back some disk space.

First of all, why you might want to do this kind of cleanup?

We all know and laugh on Windows 10/11 disk requirements, right? But out-of-the-box Linux distros are becoming nothing better than it. And the reason for that is, distro teams are trying to squeeze as much as they can into the distribution, so most use cases will be covered. It might not sound like a bad idea, but what is the point for you, yes, specifically you, to have installed on your disk (and running as a daemon) such a thing as CUPS, if you don't even have a printer at home, right? Or having some graphical themes for your GRUB, when you don't care about bootloader beauty? Or having SNAP deamon installed and running, if you don't like vaping long-bearded hipsters and all the novelties and prefer your software to be installed from distro repo? Or why on earth you need to spare 300+ Mb on your hard drive to have "wireless-regdb" package (wireless regulatory database) for a system without WiFi?

As I mentioned, I do own an SBC which is running either off EMMC or off SD card. As you can imagine, the storage there is not endless. I wanted my OS to be as compact as it could be, without hurting much to its operation capabilities and not by paying a price of having a limited amount of applications. Quite the opposite - I want my free space to be used by the applications I use and by my own content (photos, music, videos). 

Secondly, the less free space you have on your solid state drive, no matter what generation it is, the less it will span. This might sound like a joke, unless you investigate that on your own, how SSD is operating and how writes are distributed across free blocks. Logic here is very simple, whenever you update something on your disk, the SSD controller will likely mark the storage cell occupied with your "old" data as clean, without actually cleaning it, and copy modified things around to a new storage cell. This approach is called "copy-on-write", and this is what all solid-state-drive controllers are doing, underneath the hood. So the less free space you have on your drive, the more pressure those free cells will get.

Before we begin

Your next best friend should be a tool like KDE Filelight or GNOME Baobab (recently was renamed to generic "Disk usage analyzer"). 

You open it up, and look very carefully what takes the most space on your drive. 

Delete apt cache

Unfortunately apt (a Debian-based distros package manager) has a bad habit of leaving the trash behind. It's just coded that way, so it first downloads the package to a local "cache"- your hard drive - and only then it installs it. And guess what? It doesn't give a shit to wipe out whatever remained after it. It's like if you never emptied your "Downloads" folder in Windows :) 

So we can do that manually:

apt-get autoclean
apt autoclean
apt clean


Compact the jorunal

Quite time ago, Linux distributions have switched from keeping a good old plain text log files under /var/log to something new and shiny. That something new was called journalctl. Basically that's a service which keeps up a binary log from whatever other service or software who wants to put something into system log. Binary here is a good thing in terms of space occupied, because it's using some kind of compression. But the bad thing about it, is that 90% of desktop Linux users don't even know how to look into those journalctl logs and they never do. 

If you're not a big fan of archeological digging into your old journalctl records from a month ago, I strongly suggest you to limit, how much logs can journalctl write to your hdd.

sudo journalctl --vacuum-size=100M

Delete extra locales

du -hs /usr/share/locale/*
find /usr/share/locale/ -type f -exec dpkg -S {} \; | sort -u

TODO https://serverfault.com/questions/394610/remove-a-locale-in-ubuntu/1037183#1037183


Delete extra kernels you don't need

First figure it out, what kernel you're running now:

uname -r

Check out what other kernels you have installed - the below directory usually gives a good indication about what amount of hdd is being used by kernel modules, so you can give it a second thought:

du -hs /usr/lib/modules/*

Then go ahead to remove all the kernels (and kernel-specific packages) you no longer need. Instead of 5.15.0-50 in the below example, use the kernel version from above, one by one:

apt list --installed "*5.15.0-50*"
# compose a list manually
apt purge <list of packages>

Delete snaps / flatpacks you don't use or alltogether


flatpak list
apt autoremove flatpak
rm -rf /var/lib/flatpak

snap list
apt autoremove snapd
rm -rf /usr/lib/snap

Remove the swapfile / swap partition

xxxx

Find and delete the fattest software

Unfortunately, I found no easy tool to use, how can you measure what is the storage impact of the packages you installed manually, considering all the dependencies it brought, when the dependencies are only needed to run that your package. All the GUI tools that are coming with various Desktop Environments are doing the same mistake - whenever they're calculating the size occupied by a package, they don't consider its dependencies.

So I had to make my own simple scrip: 

Debian-based distros


cat << EOF > /usr/local/bin/apt-space-used-by #!/bin/sh out=\$(apt-get --assume-no autoremove \$1 2>&1) ec=\$? if [ \$ec -eq 1 ] ; then size=\$(echo -n "\$out" | grep "After this operation" | cut -d' ' -f4-5) size=\$(echo \$size | sed -e "s/[^0-9kMG,.]//g" | tr 'k' 'K') echo -n "\$size\\t" else echo -n "0 (cannot delete)" fi echo -n "\$1\\t"
dpkg-query -W -f='\${binary:Summary}\\n' \$1
EOF
chmod a+x
/usr/local/bin/apt-space-used-by
# before we go any further we need to cleanout all the orphan pacakges, as they will be bothering our little script
apt autoremove


# now if you want to see what packages you installed manually will free what space
apt-mark showmanual | xargs -I % sh -c "apt-space-used-by %" | sort -h

# ... or whatever other packages which came with your distro
echo "" > /tmp/final_report.txt
dpkg-query -W -f='${binary:Package}\n' | xargs -I % sh -c "apt-space-used-by %" | tee -a /tmp/final_report.txt
cat /tmp/final_report.txt | sort -h

RHEL-based distros

cat << EOF > /usr/local/bin/yum-space-used-by
#!/bin/sh
out=$(yum --assumeno erase $1 2>&1)
echo -n "$out" | grep -qE "^Freed space:"
ec=$?
if [ $ec -eq 0 ] ; then
size=$(echo -n "$out" | grep -E "^Freed space:" | cut -d' ' -f3-4)
size=$(echo $size | sed -e "s/[^0-9kMG,.]//g" | tr 'k' 'K')
echo -ne "$size\t"
else
echo -ne "0 (cannot delete)"
fi
echo -ne "$1\t"
rpm -q --queryformat="%{SUMMARY}" $1
echo ""
EOF
chmod a+x /usr/local/bin/yum-space-used-by

# before we go any further we need to cleanout all the orphan pacakges, as they will be bothering our little script
yum autoremove


# now if you want to see what packages you installed manually will free what space
yum history userinstalled | grep -v "Packages installed by user" | xargs -I % sh -c "yum-space-used-by %" | sort -h

# ... or whatever other packages which came with your distro
echo "" > /tmp/final_report.txt
rpm -qa | xargs -I % sh -c "yum-space-used-by %" | tee -a /tmp/final_report.txt
cat /tmp/final_report.txt | sort -h

A word of caution regarding the last command. Imagine you have git installed. The "git" package brings with it a set of mandatory dependencies, it couldn't live without, like "git-man". So if you delete "git-man", it will also delete "git". This is why you will see some that both "git" and "git-man" packages will free up the same amount of disk space.

Once you figured out what you're ready to remove run:

apt autoremove <pacakgename>

Upsize your partitions

It might be the case, that you do have some unallocated space on your drive.  That's quite easy to fix. Imagine you have a disk (/dev/sda) with a single partition (/dev/sda1) and some free space after that partition. You first run lsblk to confirm what kind of layout you have, then you run parted and resize that 1st partition (/dev/sda1) to occupy 100% of remaining free space. And the cherry on a cake - you upsize the filesystem. That's it. Everything can be done online, without the need for reboot.

lsblk
parted /dev/sda
print all
resizepart 1 100%
resize2fs /dev/sda1


TODO

# remove dev packages you installed manually

apt-mark showmanual | grep -E "\-dev$" | awk '{system("sudo apt-get --dry-run purge "$1)}'

# remove 

It's safe to remove the content of your trashbin:
~/.local/share/Trash

See also what kind of programs you might have already deleted, but they left behind their traces:
~/.local/share

Like in my case I had some trails left by Konqueror (browser) I was experimenting with, and then used "apt remove" instead of "apt purge"
It's just me being not very carefull, but there's a good thing about it, we can pick up all such traces in one go:

dpkg --get-selections | awk '$2=="deinstall" {system("sudo apt-get --dry-run purge "$1)}'
dpkg --get-selections | awk '$2=="deinstall" {system("sudo apt-get -y purge "$1)}'


"Debloating" your Debian Linux even further

Why we need to do that?

Well, there're two main reasons for that. One is kinda important for everyone, who're running their SBCs out of SD cards, other is my own deep personal preference. 
 

Reason 1: save your SD card / EMMC chip from dying earlier

We're running Debian Linux, which was put together while keeping in mind desktop machines with HDD or SSD drives. What we have in our SBC are eMMC (at best) or SD card. 
 
The main difference between desktop-grade SSD disk and SD card is that SSD disk' controller is much more advanced. It protects the storage cells by distributing write operations evenly. SD card controllers also do that kind of thing, but not that good, because of obvious reasons (cost saving + smaller form factor).

And you need to know, the more you write to SD card, the less it lasts. So let's start. The idea of this exercise is to turn off as much write-heavy activities as we can while leaving system up and running. 
 

Reason 2: I don't like a lot of automation, which Linux offers out of the box

In this sense, Linux is becoming a sort of mini-me of Windows,  I hate so much. I can hardly stay calm when I see some windows service is eating up a lot of CPU / memory / doing some IO or sending something over the netwrok  and I can't even get to know what that service is doing.

- if it's doing something crucial for OS to live, and killing it will break Windows?
- is it something auxiliary  Windows can live without?
- does it mine some cryptocoins for Microsoft' benefit, but on my own hardware?

... because Windows is closed source, and you cannot get inside of it to see which of the above is true.

I also deeply hate Windows, when it decides it's time to apply some patches,  perform some kind of housekeeping for whatever built-in stuff or do a system reboot to make a system upgrade. Without asking me.


As I said, unfortunately in Linux (especially in Debian linux) I see it's drifting towards Windows behavior, and nobody cares about it. See the proof#1 and proof#2.

But fortunately, this is still Linux, and it's open soruce with tonns of documentation and questions being already asked and answered. So we can finetune it whatever we want, and do that knowingly, without any risk to get something broken in the completely distant part of the system. This is why I love Linux so much.

Disclaimer

 
A word of warning here. I'm going to turn off a lot of stuff here. You might hear it from others (probably they will even be screaming at you) that all the things I suggested to turn off here is crucial for your own existence. 
 
Make a pause there and take a deep breath. Think of the worst possible scenario. Like some critical security bug was found in Debian and given you turned off automatic updates,  your system still has that bug and potentially vulnerable, if ..
 
  • If you have your SBC connected directly to Internet with all ports exposed and you're running tons of software from 3rd parties / non official repos / snap which are exposing itslef by opening these ports to outer world, inviting hackers to come in

  • if you're using web browser of old version 

... this might be an issue, yeah. But, if you'll be doing apt update & apt upgrade time-to-timeyourself, it's nothing different to have this automatic update services running.

Remove cron jobs

 
Let's see what we have:
 
root@orangepi4-lts:~# ls /etc/cron.*
/etc/cron.d:
e2scrub_all  orangepi-truncate-logs  orangepi-updates  sysstat

/etc/cron.daily:
apt-compat  cracklib-runtime  locate     man-db                samba
aptitude    dpkg              logrotate  orangepi-ram-logging  sysstat

/etc/cron.hourly:
fake-hwclock

/etc/cron.monthly:

/etc/cron.weekly:
man-db  tor
 
A lot of things from there were moved to systemd timers, we'll deal with them just a bit later.
 
/etc/cron.d/e2scrub_all performs a check for ext2-4 file systems and marks corrupted filesystem with a tag, so fsck will fix that on next mount. Practically on next reboot. Leave that so far, but its existence is very questionable, given the actual fix could happen not earlier than upon next reboot.

TODO
: I want to see it myself, how can I get that tag/flag value as a result of e2scrub_all working. And probably get notified about that, rather than fsck will be silently fixing some issue

/etc/cron.d/orangepi-truncate-logs runs a shell script (/usr/lib/orangepi/orangepi-truncate-logs) every 15 minutes to truncate lot of logs. Looks good. But it somehow clashes with log2ram (described below). I'm gonna leave it so far.

/etc/cron.d/orangepi-updates calls shell script /usr/lib/orangepi/orangepi-apt-updates on a daily basis and after reboots to install updates silently. Part of orangepi-bsp-cli-orangepi4-lts package. Remove that file Some smartalek from OrangePi decided he knows it better than me.

/etc/cron.d/sysstat data collector for sysstat. Sysstat utilities are a collection of performance monitoring tools for Linux. These include sar, sadf, mpstat, iostat, tapestat, pidstat, cifsiostat and sa tools.
The cronjob is just a misery. It runs pretty much all the time /usr/lib/sysstat/debian-sa1 script, but that script exits if systemd is there - because sysstat was moved to systemd already. I've deleted that /etc/cron.d/sysstat
TODO: it's worth investigating where the raw statistics being put by systemd version of this grabber, to move that place to zram

/etc/cron.daily/apt-compat doesn't run if systemd is in place. Ho harm but I deleted that

/etc/cron.daily/aptitude a script that saves package states to a log file. Another logging/backup courtesy I never asked for. Deleting that

/etc/cron.daily/cracklib-runtime - part of cracklib-runtime for lame people who're using dictionary passwords. But we're not like them, right? Then purging the whole cracklib-runtime and libcrack2 packages together.

/etc/cron.daily/dpkg - part of dpkg. Backups the metadata from dpkg "database" about installed packages. Like if it could do something about it, if it finds something is broken. Hehe. Added "exit 0" to the top to disable it

/etc/cron.daily/locate - daily update to locate database. drop that. If you cannot find something with locate, and you're sure you have updated its index with updatedb recently and didn't change a bit since then - then the file is not there. No need to hammer your filesystem on a daily basis.

/etc/cron.daily/logrotate - is not doing anything when systemd is there. Can stay

/etc/cron.daily/man-db - also not doing anything when systemd is there (I'm assuming there's an appropriate timer, we'll look at them bit later).  Can stay

Looks like a lot of Debian packages are made with having this idea in mind that users might want to switch from systemd to initd, so all these crontabs will start to matter again.

/etc/cron.daily/orangepi-ram-logging - not doing anything. logrotate.timer is doing all the job instead. Can stay

/etc/cron.daily/samba - if you remember, we needed samba for our EmulationStation, so we could copy roms from our Windows machine with using its File Explorer. This job makes a backup of /etc/samba/smbpasswd file to /var/backup if it has changed. Really, the guy who wrote it is just a genius of proper backup strategy. Joking, he's not. Remove the job.

/etc/cron.daily/sysstat - doesn't do anything. All job was moved to systemd timers. Can stay

/etc/cron.weekly/man-db - not being executed with systemd. Can stay

 

Remove/disable unneeded systemd timers

As we seen above, a lot of things were migrated from cron to systemd timers. Cronned scripts are just silently existing if they see the systemd is there. So it's time to deal with systemd timers to see what we can safely disable:
 
systemctl list-timers --all
 
NEXT                        LEFT          LAST                        PASSED       UNIT                         ACTIVATES
Wed 2022-08-31 22:10:00 MSK 5min left     Wed 2022-08-31 22:00:59 MSK 3min 6s ago  sysstat-collect.timer        sysstat-collect.service
Thu 2022-09-01 00:00:00 MSK 1h 55min left Wed 2022-08-31 00:00:02 MSK 22h ago      logrotate.timer              logrotate.service
Thu 2022-09-01 00:00:00 MSK 1h 55min left Wed 2022-08-31 00:00:02 MSK 22h ago      man-db.timer                 man-db.service
Thu 2022-09-01 00:07:00 MSK 2h 2min left  n/a                         n/a          sysstat-summary.timer        sysstat-summary.service
Thu 2022-09-01 00:44:45 MSK 2h 40min left Wed 2022-08-31 00:44:45 MSK 21h ago      systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Thu 2022-09-01 06:44:30 MSK 8h left       Wed 2022-08-31 06:22:59 MSK 15h ago      apt-daily-upgrade.timer      apt-daily-upgrade.service
Thu 2022-09-01 17:18:53 MSK 19h left      Wed 2022-08-31 20:13:53 MSK 1h 50min ago apt-daily.timer              apt-daily.service
Sun 2022-09-04 03:10:13 MSK 3 days left   Sun 2022-08-28 03:10:50 MSK 3 days ago   e2scrub_all.timer            e2scrub_all.service
Mon 2022-09-05 01:26:35 MSK 4 days left   Mon 2022-08-29 00:23:07 MSK 2 days ago   fstrim.timer                 fstrim.service

 
Same bloatware. Let's get it cleaned:

xxxx

xxxx

xxxx

xxxx

xxxx

xxxx

xxxx

xxxx

xxxx

xxxx

xxxx


Monitor what remaining processes are writing heavily to SD card and deal with it, one-by-one

For that we're going to use some very nice software Linux can offer us for free. Here's the picture for attracting your attention:


What we can use here to accomplish our task:

  • "raw" tools like pcstat, pidstat, iostat, iotop and blkstat

  • we can attempt to find any higher-level tools with using apt-rdepends -r [rawpackage])

  • some random tools we found on internet (like fatrace and csysdig). 

So let's start rolling on with simple things

fatrace

I really fell in love with that tool. In the call below I asked it:
  • to look after only specific events (-f W to monitor writes to files)
  • to limit the scope to consider only one mounted device, from the current directory (-c), so I first walked into /
  • to add timestamps to its log (-t)

I left it running for a while, and then I examined the resulted log file.

cd / ; fatrace -c -t -f W | tee /tmp/fatrace.log | tee -a /tmp/fatrace.log

 


The only unfortunate thing about fatrace is that it does not provide you a bit of info about amounts of data being written and you cannot overcome that, because the system interfaces it's using are not giving these figures either.

In my case I see it already what processess were constantly writing their shit very important data to my precious SD card. Mainly it was Firefox and down below I'll to teach it how not to update its bolloks sqlite database files inside of ~/.mozilla/firefox/ 

The problem however is not only about Firefox alone. All the rest browsers I tested were doing the very same thing. But don't you worry. We'll deal with them as well.

Thanks to fatrace I also discoverd some some vnstat daemon was collecing networking statistics and putting that to its own file to /var/lib/
What was that idiot, who installed that? Was it me? Given no other package was depending on that vnstat, apart from its own mini-me vnstati. Go to hell, both of you:

apt purge vnstat

iotop

On a contrast to previous tool, now you can see amounts of data written, but you cannot limit it to see only on a specific partition (like the / - mounted to SD card). So applicability of this tool is limited to see only amounts of data written, but not knowing where exactly that data was written to. Here are few examples how can you run it:

iotop -bktoqqq


In this mode I found iotop has a bug - it was not capturing write events from short-lived processes, like the process of screenshot creation. So it might miss some important share of IO load from such processess.

iotop -obPat 


 

Same story here. Firefox is winning the race by pushing few Mb of its shitty cache to SD card within a matter of few minutes. Firefox, I hate you! Why you're doing that? I have plenty, you hear it, plenty of RAM free. You're ruining my precious SD card.

iostat 

Every tool is using its own unique way of tracking IOs. So from iostat you can expect IO breakdown per disk. If you run it like this:

iostat -dzphN 10

... it will first show you the accumulated report since the systemboot (on a screenshot it's appearing on the very top) and then will be showing deltas every 10 seconds: 


 

log2ram + zram

If you used distro from Rearm.IT, everything should be already configured. Just check that you do have /dev/zram devices and below filesystems are mounted from it:
 
root@orangepi4-lts:~# mount | grep zram
/dev/zram1 on /var/log type ext4 (rw,relatime,discard)
root@orangepi4-lts:~# df
Filesystem     1K-blocks     Used Available Use% Mounted on
udev             1904036        8   1904028   1% /dev
tmpfs             395600     2932    392668   1% /run
/dev/mmcblk2p1 122600084 86461672  34849544  72% /
tmpfs            1978000        0   1978000   0% /dev/shm
tmpfs               5120        8      5112   1% /run/lock
tmpfs            1978000       16   1977984   1% /tmp
/dev/zram1         49560    19796     26180  44% /var/log
tmpfs             395600       44    395556   1% /run/user/1000
 
In my case I can see that /var/tmp is not using zram so I need to fix it. Edit /etc/fstab and make sure you have these lines:

tmpfs /tmp tmpfs defaults,nosuid 0 0
tmpfs /var/tmp tmpfs size=10M,nosuid 0 0
tmpfs /var/cache/samba tmpfs size=5M,nosuid 0 0
 
If you modified any of those (or added missing ones, like I did), run mount -a to remount everything without the need of rebooting.

If you're using some other Linux distro, read how to configure log2ram here - https://ikarus.sg/extend-sd-card-lifespan-with-log2ram/

disable swap (makes sense for 4Gb+ RAM and higher models) or make sure swap is using zram

Even though I see in my Linux distro the swap is already mounted from zram0, to me it doesn't make much sense to have it like that. The only positive thing about it, is that zram uses a compression methods, so if your system will be swapping, the swap will be same in memory, but compressed. In the ohter hand:
  • I hardly seen my system was running out of memory. It was just once, due to the bug in Gwenview. But guys, I'm having luxurious 4 Gb of RAM

  • Using compression mechanisms on zram will definitely hurt CPU, when it comes to moving something to SWAP or reading it back
Here's how I have it:
 
root@orangepi4-lts:~# swapon
NAME       TYPE      SIZE USED PRIO
/dev/zram0 partition 1.9G 416M    5
 
I decided to keep this swap on zram so far, given it's still using memory and not the SD card. 

some further steps

https://raspberrypi.stackexchange.com/questions/169/how-can-i-extend-the-life-of-my-sd-card


Disable system.d services we don't need

Disclaimer: you really should know what you're doing and look into more details of what you're exactly disabling

In my case, I don't want any "automated" or "unattended" software upgrades / updates to happen, I don't want my computer to do something I can do myself. So I want all that disabled or even removed. 
 
Let's see what exactly we have running (I'm skipping some output from systemctl for the services I do want and I know what they're doing):

$ systemctl status

             ├─nfs-mountd.service
             │ └─119304 /usr/sbin/rpc.mountd --manage-gids

             ├─nfs-blkmap.service
             │ └─119752 /usr/sbin/blkmapd

             ├─nfs-idmapd.service
             │ └─119303 /usr/sbin/rpc.idmapd


             ├─packagekit.service
             │ └─16489 /usr/libexec/packagekitd

             ├─unattended-upgrades.service
             │ └─1123 /usr/bin/python3 /usr/share/unattended-upgrades/unattended-upgrade-shutdown

             ├─upower.service
             │ └─2296 /usr/libexec/upowerd

             ├─accounts-daemon.service
             │ └─2072 /usr/libexec/accounts-daemon

             ├─haveged.service
             │ └─745 /usr/sbin/haveged --Foreground --verbose=1

nfs-*.service

who needs nfs nowdays? drop that!

sudo nala remove nfs-common



packagekit.service

pi@orangepi4-lts:~ $ dpkg -S /usr/libexec/packagekitd
packagekit: /usr/libexec/packagekitd
pi@orangepi4-lts:~ $ apt info packagekit
Package: packagekit
Version: 1.2.2-2
Priority: optional
Section: admin
Maintainer: Matthias Klumpp <mak@debian.org>
Installed-Size: 2,857 kB
Depends: libglib2.0-bin, policykit-1, init-system-helpers (>= 1.52), libappstream4 (>= 0.10.0), libapt-pkg6.0 (>= 1.9.2), libc6 (>= 2.28), libgcc-s1 (>= 3.0), libglib2.0-0 (>= 2.54), libgstreamer1.0-0 (>= 1.0.0), libpackagekit-glib2-18 (>= 1.2.1), libpolkit-gobject-1-0 (>= 0.99), libsqlite3-0 (>= 3.5.9), libstdc++6 (>= 5.2), libsystemd0 (>= 214)
Recommends: packagekit-tools, systemd
Suggests: appstream
Breaks: libpackagekit-glib2-14 (<= 0.7.6-4), libpackagekit-qt2-2 (<= 0.7.6-4), packagekit-backend-apt (<< 1.0), packagekit-backend-aptcc (<< 1.0), packagekit-backend-smart (<< 1.0), packagekit-offline-update (<< 1.0), packagekit-plugin-click (<= 0.3.1), plymouth (<< 0.9.5)
Homepage: https://www.freedesktop.org/software/PackageKit/
Tag: admin::package-management, implemented-in::c, implemented-in::python,
 role::program
Download-Size: 575 kB
APT-Manual-Installed: no
APT-Sources: http://deb.debian.org/debian bullseye/main arm64 Packages
Description: Provides a package management service

This is the abstraction layer which makes it possible for applications like KDE Discover to work on any kind of distros, no matter what software packaging tools they're using - dpkg/apt, rpm/yum/dnf, pacman - whatever. 

If you want to keep using KDE Discover you'll need to keep that. I disabled it.


unattended-upgrades.service

pi@orangepi4-lts:~ $ dpkg -S /usr/share/unattended-upgrades/unattended-upgrade-shutdown
unattended-upgrades: /usr/share/unattended-upgrades/unattended-upgrade-shutdown
pi@orangepi4-lts:~ $ apt info unattended-upgrades
Package: unattended-upgrades
Version: 2.8
Priority: optional
Section: admin
Maintainer: Michael Vogt <mvo@debian.org>
Installed-Size: 334 kB
Depends: debconf (>= 0.5) | debconf-2.0, debconf, python3, python3-apt (>= 1.9.6~), python3-dbus, python3-distro-info, ucf, lsb-release, lsb-base, xz-utils
Recommends: systemd-sysv | cron | cron-daemon | anacron
Suggests: bsd-mailx, default-mta | mail-transport-agent, needrestart, powermgmt-base, python3-gi
Tag: admin::package-management, implemented-in::python, role::program,
 suite::debian, works-with::software:package
Download-Size: 88.6 kB
APT-Manual-Installed: yes
APT-Sources: http://deb.debian.org/debian bullseye/main arm64 Packages
Description: automatic installation of security upgrades 

Self explanatory. Remove that. I'll be able to install all my security updates myself!

apt purge unattended-upgrades

upower.service

pi@orangepi4-lts:~ $ dpkg -S /usr/libexec/upowerd
upower: /usr/libexec/upowerd
pi@orangepi4-lts:~ $ apt show upower
Package: upower
Version: 0.99.11-2
Priority: optional
Section: admin
Maintainer: Utopia Maintenance Team <pkg-utopia-maintainers@lists.alioth.debian.org>
Installed-Size: 420 kB
Depends: dbus, udev, libc6 (>= 2.17), libglib2.0-0 (>= 2.41.1), libgudev-1.0-0 (>= 147), libimobiledevice6 (>= 0.9.7), libplist3 (>= 1.11), libupower-glib3 (>= 0.99.8), libusb-1.0-0 (>= 2:1.0.8)
Recommends: policykit-1
Homepage: https://upower.freedesktop.org/
Tag: admin::power-management, hardware::power, hardware::power:acpi,
 hardware::power:ups, implemented-in::c, interface::daemon,
 role::program
Download-Size: 113 kB
APT-Manual-Installed: no
APT-Sources: http://deb.debian.org/debian bullseye/main arm64 Packages
Description: abstraction for power management

This service provides a various information about electrical power for your PC and linked devices, like remaining charge of a battery of your laptop or bluetooth mouse. I tried to remove it, but it also removes so many things with it (like sddm), so unfortunately you have to keep that beast. In my case, this service doesn't provide a correct information of remaining battery from connected bluethooth gamepads:
 
upower -d

Will raise a bug about this issue.

haveged.service

pi@orangepi4-lts:~ $ dpkg -S /usr/sbin/haveged
haveged: /usr/sbin/haveged
pi@orangepi4-lts:~ $ apt info haveged
Package: haveged
Version: 1.9.14-1
Priority: optional
Section: misc
Maintainer: Jérémy Bobbio <lunar@debian.org>
Installed-Size: 92.2 kB
Pre-Depends: init-system-helpers (>= 1.54~)
Depends: lsb-base (>= 3.2-14), libc6 (>= 2.17), libhavege2 (>= 1.9.13)
Suggests: apparmor
Homepage: https://issihosts.com/haveged/
Tag: implemented-in::c, interface::daemon, role::program, scope::utility,
 security::cryptography
Download-Size: 39.1 kB
APT-Manual-Installed: yes
APT-Sources: http://deb.debian.org/debian bullseye/main arm64 Packages
Description: Linux entropy source using the HAVEGE algorithm
 

Random number generation daemon. I'm not joking. And it's important part of distribution, as a lot of crypto things are depending on having a truely random number being generated. Don't touch it. I eats just 3 megs of ram but it provides a truly randomization for /dev/random

accounts-daemon.service

Coming soon

configure X to not generate huge .xsession-errors file (or move that file to /tmp


If you were following me with all the above steps, you might have noticed (with the help of fatrace) that a lot of stuff is written to ~/.xsession-errors file. This is how X.Org is configured by default in  /etc/X11/Xsession file:

...
ERRFILE=$HOME/.xsession-errors
...
# attempt to create an error file; abort if we cannot
if (umask 077 && touch "$ERRFILE") 2> /dev/null && [ -w "$ERRFILE" ] &&
  [ ! -L "$ERRFILE" ]; then
  chmod 600 "$ERRFILE"
elif ERRFILE=$(tempfile 2> /dev/null); then
  if ! ln -sf "$ERRFILE" "${TMPDIR:=/tmp}/xsession-$USER"; then
    message "warning: unable to symlink \"$TMPDIR/xsession-$USER\" to" \
             "\"$ERRFILE\"; look for session log/errors in" \
             "\"$TMPDIR/xsession-$USER\"."
  fi
else
  errormsg "unable to create X session log/error file; aborting."
fi

exec >>"$ERRFILE" 2>&1


 
Given our homedirs are on the SD card, we don't want these permanent writes being made to it with such logs. Let's fix that by changing that file to a symlink pointing somewhere to /tmp.  Tempdir is mounted as tmpfs (essentially - to memory) so we will avoid burden of constant writes to SD:

mv ~/.xsession-errors ~/.xsession-errors.bak
ln -s /tmp/$USER.xsession-errors ~/.xsession-errors

Another option will be to configure X to write only critical errors, but I'm fine with my current option now.

Disable journaling for ext4 filesystems

We're not running production server of a patients-life-critical application in hospital. If we loose a bit of info or some app will corrupt it's cache, if our SBC will be unexpectedly poweroff, we can survive that. We don't have such apps, who won't survive if. So let's go:


tune2fs -l /dev/mmcblk2p1
tune2fs -O ^has_journal /dev/mmcblk2p1
e2fsck -f /dev/mmcblk2p1
reboot

Configure your browsers to not write its cache that aggressively to your homedir

Same as above - as we figured it, browsers tend to write a lot of things to your ~/.cache or ~/.config or ~/.mozila or whatever else in your home dir. Some of the stuff we probably want to be written there, like cookies. But most of other stuff you'll see is written there is just lazy browser developers or plugin who didn't pay enough attention to such important details.

Firefox

In your address string put "about:config" and hit enter. Accept the warning and proceed. We need to modify these setitngs:

browser.cache.disk.enable = false
browser.cache.disk.smart_size.enabled = false
browser.cache.disk_cache_ssl = false


+ I'll need to search for more, as it still writes to number of its internal sqlite files like:

pi@orangepi4-lts:~ $ grep -oE "\/home[^ ]*" /tmp/fatrace.log | sort | uniq -c
     10 /home/pi/.mozilla/firefox/(x).default-esr/AlternateServices.txt
      1 /home/pi/.mozilla/firefox/(x).default-esr/broadcast-listeners.json
      1 /home/pi/.mozilla/firefox/(x).default-esr/broadcast-listeners.json.tmp
    325 /home/pi/.mozilla/firefox/(x).default-esr/cookies.sqlite
   2366 /home/pi/.mozilla/firefox/(x).default-esr/cookies.sqlite-wal
      4 /home/pi/.mozilla/firefox/(x).default-esr/datareporting/aborted-session-ping
      4 /home/pi/.mozilla/firefox/(x).default-esr/datareporting/aborted-session-ping.tmp
      1 /home/pi/.mozilla/firefox/(x).default-esr/datareporting/archived/2022-09/xxxmain.jsonlz4
      1 /home/pi/.mozilla/firefox/(x).default-esr/datareporting/archived/2022-09/xxxmain.jsonlz4.tmp
      1 /home/pi/.mozilla/firefox/(x).default-esr/datareporting/session-state.json
      1 /home/pi/.mozilla/firefox/(x).default-esr/datareporting/session-state.json.tmp
      5 /home/pi/.mozilla/firefox/(x).default-esr/favicons.sqlite
    123 /home/pi/.mozilla/firefox/(x).default-esr/favicons.sqlite-wal
     28 /home/pi/.mozilla/firefox/(x).default-esr/formhistory.sqlite
    122 /home/pi/.mozilla/firefox/(x).default-esr/formhistory.sqlite-journal
     50 /home/pi/.mozilla/firefox/(x).default-esr/permissions.sqlite
    135 /home/pi/.mozilla/firefox/(x).default-esr/permissions.sqlite-journal
     54 /home/pi/.mozilla/firefox/(x).default-esr/places.sqlite
    420 /home/pi/.mozilla/firefox/(x).default-esr/places.sqlite-wal
     15 /home/pi/.mozilla/firefox/(x).default-esr/prefs-1.js
      3 /home/pi/.mozilla/firefox/(x).default-esr/prefs.js
      3 /home/pi/.mozilla/firefox/(x).default-esr/protections.sqlite
      9 /home/pi/.mozilla/firefox/(x).default-esr/protections.sqlite-journal
      1 /home/pi/.mozilla/firefox/(x).default-esr/sessionstore-backups/recovery.jsonlz4
    121 /home/pi/.mozilla/firefox/(x).default-esr/sessionstore-backups/recovery.jsonlz4.tmp
      8 /home/pi/.mozilla/firefox/(x).default-esr/SiteSecurityServiceState.txt
     22 /home/pi/.mozilla/firefox/(x).default-esr/storage/default/moz-extensionxxx/idb/xxx-eengsairo.sqlite
     18 /home/pi/.mozilla/firefox/(x).default-esr/storage/default/moz-extensionxxx/idb/xxx-eengsairo.sqlite-wal
      4 /home/pi/.mozilla/firefox/(x).default-esr/storage/permanent/chrome/idb/xxxxAmcateirvtiSty.sqlite
      4 /home/pi/.mozilla/firefox/(x).default-esr/storage/permanent/chrome/idb/xxxxAmcateirvtiSty.sqlite-wal
      6 /home/pi/.mozilla/firefox/(x).default-esr/storage/permanent/chrome/idb/xxxxrsegmnoittet-es.sqlite
      5 /home/pi/.mozilla/firefox/(x).default-esr/storage/permanent/chrome/idb/xxxxrsegmnoittet-es.sqlite-wal
      4 /home/pi/.mozilla/firefox/(x).default-esr/webappsstore.sqlite
     42 /home/pi/.mozilla/firefox/(x).default-esr/webappsstore.sqlite-wal
      8 /home/pi/.mozilla/firefox/(x).default-esr/xulstore.json
      6 /home/pi/.mozilla/firefox/(x).default-esr/xulstore.json.tmp


Qutebrowser

tbc

Chromium


Mesuring our success

 
After all the above fixes being in place, we can run iostat again to see the accumulated IO stats from the very last boot. Behold, this is my system after 13 hours uptime:

Every 2.0s: iostat -dzphN ; uptime                                                                                                                      orangepi4-lts: Fri Sep  2 13:21:31 2022

Linux 5.18.5-rk3399 (orangepi4-lts)     09/02/2022      _aarch64_       (6 CPU)

      tps    kB_read/s    kB_wrtn/s    kB_dscd/s    kB_read    kB_wrtn    kB_dscd Device
     0.01         0.2k         0.0k         0.0k       5.3M       0.0k       0.0k mmcblk0
     0.00         0.1k         0.0k         0.0k       3.2M       0.0k       0.0k mmcblk0p1
     0.00         0.0k         0.0k         0.0k     348.0k       0.0k       0.0k mmcblk0boot0
     0.00         0.0k         0.0k         0.0k     348.0k       0.0k       0.0k mmcblk0boot1
     0.50        14.7k         0.9k         0.0k     499.5M      31.4M       0.0k mmcblk2
     0.50        14.6k         0.9k         0.0k     497.5M      31.4M       0.0k mmcblk2p1
     0.02         0.1k         0.0k         0.0k       2.3M       4.0k       0.0k zram0
     0.14         0.0k         1.5k         0.0k     476.0k      51.3M       0.0k zram1


 13:21:31 up  9:41,  2 users,  load average: 1.16, 1.24, 1.22
 
Just 30 Mb of writes for 13 hours and I do have a lot of daemons runnig. Launch of any web browser and few minutes serfing still adds to this picture like +30 Mb of data being written to SD, so this is something we still have to handle. But now it's way better than it was before.

Quick cheat sheet for strace

Today I've noticed that the gwenview (a GUI program to view images) was sitting on CPU even though I wasn't using that. This reminded me of an idea to practice my tracing skills.

For those, who don't know what am I talking about, in Linux you can use a very special kind of software, called debuggers or tracers, connect to any existing process (or spawn a new one) and see, what exactly it is doing! Not exactly like reading the source code of the program, but very close to that. Let's say some developer did a silly app, which does nothing rather opening some file, writing some bullshit into it and closing it. In a loop. So if you run that program with using strace you would be able to see, that it calls specific functions from Linux kernel like fopen / fclose / fwrite. I'm oversimplifying off course, but you get the idea.

So let's install strace and practice a bit:

apt install strace

And run it for some process (assuming you have a process with pid=70014):

sudo strace -p 70014 -r -o ./strace.log

Then after a short while press CTRL+C.
Let's break here for a while and see what options we used.

-p option tells strace to connect to an existing process
-r instructs it to add to the output a time difference between calls
-o <filename> redirects all the output to a file

Let's see what we've got in our log file. Interesting, huh? But it's a raw data, a lot of raw calls to some kernel functions. How can we get any additional use out of it?

We can ask strace to give us a summary report, like what kind of kernel functions were called and how long did all that took, in total for each function:

pi@orangepi4-lts:~$ sudo strace -c -p 70014
strace: Process 70014 attached
^Cstrace: Process 70014 detached
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 42.47    0.178028          11     15074     14139 openat
 21.86    0.091656          25      3615           read
 11.62    0.048727           8      5925         2 newfstatat
  7.75    0.032476          10      3068           write
  5.08    0.021315          24       862        22 faccessat
  4.28    0.017959          19       945           ppoll
  2.47    0.010357          11       935           close
  1.37    0.005738           9       614        59 statx
  1.32    0.005552           6       924           fstat
  1.10    0.004626          27       168           getdents64
  0.61    0.002575           9       271           ioctl
  0.03    0.000109          10        10           lseek
  0.01    0.000047           9         5           getuid
  0.01    0.000043           8         5           geteuid
  0.00    0.000012          12         1           clone
  0.00    0.000000           0         2           futex
------ ----------- ----------- --------- --------- ----------------
100.00    0.419220          12     32424     14222 total
 

Here you can see, the most time this program spent opening some files with openat function, then reading something out of them with read and then getting file info with newfsatat

Knowing these facts, we can return back to inspecting raw log, but giving this time more scrutiny to what kind of files this pesky gwenview is reading all the time:

grep -E "openat|read|newfstatat" strace.log | less

It now becomes clear, that gwenview spending a lot of CPU while  attempting to open some thumbnails, usually it does that more than once for every thumbnail file, but gets an error from Kernel each time, but it repeats to try that over and over again:

     0.000093 openat(AT_FDCWD, "/home/pi/.cache/thumbnails/large/cd736b031fc7750f7d7ee3ca307
cee8e.png.pgm", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

To me it's clearly a bug of gwenview it shouldn't act like this. It also consumed a lot of memory and went into swap. Sadly, I liked it much. But we can report this bug or check if the most recent version of that application behaves the same.

What could have bothered it, is that I opened it to display images in a folder, which was getting updated in a background - I do have an app on my android phone which syncs my images from Android gallery to my Linux PC over ssh.

I wanted you to look at this article - where a wonderful mate Raghu nailed that whole strace topic down

Update from future: I reported that bug and it was fix the very same day by magnificent The other behavior I was seeing (consuming a lot of memory first, then swap, then slowly making system to die) was  already fixed before But given Debian don't update packages all that often, a vast majority of its users (like me) won't see that fix.  

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 with
nala 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

Updating RetroPie - RetroPie Docs and FAQ - RetroPie Docs

Start here

Disable Firefox from updating itself and flash those annoying "Restart to Keep Using Firefox" messages on you

I recently switched from Brave to Firefox. Just because Brave appeared to be some proprietary shit, even though they're masking themselv...