comparing Item sets in PowerShell

Once I needed to write a not-that-complex script, which should copy "new" files from source folder into destination one, where "new" meant that files of the same name should be absent in both dest.folder, and backup folder, into which these files were moved after processing them by other software.
In Unix/Linux&sh/bash, the tool of choice would of course be comm(1), while in Windows&PowerShell, Compare-Object is most often used. So I made these functions,

function union { Compare-object @( $args[0] ) @( $args[1] ) -PassThru -IncludeEqual }

function difference { Compare-Object @( $args[0] ) @( $args[1] ) |
                      where {$_.sideIndicator -eq '<='} |
                      select -ExpandProperty InputObject }

, and shortly, after some experiments, I discovered that PS Item Objects, being kind of maps of named properties to their values, are not comparable by equality ($O1 -eq $O2) or by inclusion of an object into a list ($L -contains $O).
you may check that by yourself in some non-empty folder:

$a=(Get-ChildItem -File)
$b=(Get-ChildItem -File) # should be the same list, right ? wrong !
$a # their printout would look the same
$b # but this only confuses you more
$a[0] -eq $b[0] # False
$a -contains $b[0] # False

you may select only a single property from these Item lists, like:

$a=(Get-ChildItem -File | Select-Object -Property Name )
$b=(Get-ChildItem -File | Select-Object -Property Name )

but this would not improve your results as well.
What is worse, for Item lists taken from the same folder, Compare-Object would return properly-looking results, that is, "no difference between lists, all items are equal". But when you compare file lists taken from different folders, reviewing Compare-Object results would make you ask "What the hell?" (especially when you only select Name property from these Items).

In short, to compare file name lists successfully, you should get them as honest list of strings, that is:

function filelist { Get-ChildItem -Path $args[0] -File -Filter $args[1] |
                    select -ExpandProperty Name }

file lists formed in this way finally were able to be properly unioned and differenced with the above functions.

Upgrading Ubuntu 18.04 from 32 to 64 bit (i386->amd64) , to Debian 12, and back to lubuntu-desktop

In Aug 2018, I got a technical support side-job where I needed to maintain a "fleet" of 40+ moderately-to-quite old PCs with Linux.
When I started reviewing and inventorying what I have got, most of them had "UALinux LUbuntu Pack 14.04" installed.
As I understood, UALinux was supposed to provide some improvements in Ukrainian&Russian language support compared to "plain" [L]Ubuntu, but even as of 14.04, most of their changes were, to my experience, only branding-related.
On top of Lubuntu LXDE desktop, most used software included: Remmina for RDP access to Windows servers, PCManFM for access to local and networked file shares (using cifs-utils), LibreOffice, Firefox, simple-scan or other scanning software.
Hardware included mostly socket-775 motherboards with i945G/G31/G41 chipset and DDR2 or (less often) DDR3 RAM, typically 2 GB per host.
Some MoBos were really old, with socket 478 and DDR RAM, and some of them did not even have SATA ports.
Some were newer, with H61/B65 and even H81/B85 chipsets and appropriate CPUs (and still with DDR3 RAM).
All this stuff I managed to upgrade to LUbuntu 16.04, then to 18.04, keeping their OS and software packages 32-bit (i386) to save RAM with shorter pointer sizes, and enjoying the fact that LUbuntu LXDE environment did not have essential changes since probably LUbuntu 12.04.

Then, a number of unwanted changes were made from Ubuntu side.
First, LUbuntu 18.10 decided to switch from LXDE to LXQt.
Which could disappoint users and make them learn new less-familiar interface.
At these times, LXQt and PCManFM-Qt were less stable and displayed some unfamiliar and unwanted behavior to an inexperienced user.
Then, Ubuntu 19.10 dropped i386 support.
That is, [L]Ubuntu 18.04 i386 was now left without a clear upgrade path.

In this conservative mode, we stayed on LUbuntu 18.04 i386 for more than 5 years, up till early 2024.
During that time, new hardware appeared which was not supported by old HPLIP.
As well, lot of users demanded to have Viber or Skype on their desktops, which by then started to be provided in 64-bit(amd64) versions only.
Also, Ubuntu started more aggressively promoting their money-making technologies such as snaps, ESM, and so on.
Also they stopped building .deb-based Firefox and updating their 4.15 kernel, despite having promised to extend 18.04 support lifetime from 5 to 10 years (probably this was related only to Ubuntu Server parts, with paid Ubuntu Pro / ESM services).

Once, I decided that it is a time to "move the chip" and to implement my long-imagined plan.

First, I created, tested and improved a script to upgrade i386 Ubuntu 18.04 to amd64, which can be had from https://raw.githubusercontent.com/muwlgr/scripts/main/upgrade-lubuntu3264.sh .
This script will update your i386 system after a few iterations (restarts).
However, in complex situations you will notice that it is restarting the same operations and failing in the same way again and again.
Then you will probably need to intervene and to remove/upgrade problematic packages manually.
As well, if you turn off checking the release name, this script could upgrade your i386 LinuxMint 19.3 "tricia" setup which was based on Ubuntu "bionic", and which was the last LinuxMint version with i386 build.

Next script https://raw.githubusercontent.com/muwlgr/scripts/main/upgrade-bionic-to-bookworm.sh will upgrade Ubuntu Bionic 18.04 to Debian 10/Buster, 11/Bullseye and 12/Bookworm.
One problem with this script is that it may cut you off the DNS when resolvconf package is removed but systemd-resolved is not yet installed.
I just could not track down the exact place where this happens - it varied depending on what packages were installed.
Hope, you know how to fix the situation.

My next step was to rebuild lubuntu-meta 0.94.1 source package from Ubuntu Bionic under Debian 12/Bookworm.
The script can be had from https://raw.githubusercontent.com/muwlgr/scripts/main/build-lubuntu-on-bookworm.sh .
It will drop or replace some Ubuntu-specific dependencies, build needed packages (lubuntu-desktop, lubuntu-gtk-core, lubuntu-gtk-desktop) and pack them into an archive lubuntu-bookworm.tgz , which you then may reuse to install familiar-looking LUbuntu 18.04 themes/icons/sessions on Debian 12/Bookworm.
That is, you don't need to run this script anew on every system you have upgraded to Bookworm - just transfer and unpack this .tgz archive to any newly-upgraded Bookworm system.

And the last step, is to install rebuilt LUbuntu root packages on Debian Bookworm.
The script is at https://raw.githubusercontent.com/muwlgr/scripts/main/install-lubuntu-on-bookworm.sh .
Be sure to unpack your .tgz archive from the previous step so it could conclude its actions.
The script is mostly problem-free, only sometimes it could autoremove cifs-utils.
Hope you know how to reinstall them back.

 After these steps, the upgraded Debian 12 systems will look and behave surprisingly similar to the original LUbuntu 18.04.
However, some problems could be heard from users, which, fortunately, could be easily fixed.

• we had cifs records in fstab with option sec=ntlm from previous setups.
  under kernel 6.1, this option had to be removed from the option list.
• Ubuntu's language-pack* and *language-selector packages are not provided by Debian, so you have to run dpkg-reconfigure locales and to select all required locales to be generated (in our case, they were en_US, ru_RU, ru_UA, uk_UA, all with .UTF-8 encoding), as well as default LANG value for your runtime. This step I included into upgrade-bionic* script.
• For certain versions of Windows RDP server (2012R2 at least), connection properties in Remmina should be changed to set "Advanced/Security protocol negotiation" from "Automatic" to "RDP". For xfreerdp, be sure to add "/sec:rdp" to its command line
• we had to reinstall Canon CUPS drivers after i386->amd64 upgrade, and in most cases, to remove and rediscover/reinstall the printer, as its backend file name was changed.
  Same actions had to be repeated for Kyocera printers/scanners
• for HP printers and scanners handled by HPLIP/HPAIO, we had to reinstall HP Plugin by running hp-plugin -i
• Debian provides Firefox-ESR package which creates default-esr Firefox profile on its first run.
  To select former/existing profile, run firefox -P from the command line.
• PCManFM started to ask if we want to open "untrusted" .desktop shortcuts.
  This can be turned off in PCManFM preferences.
  Or, "bad" desktop shortcuts can be removed from the Desktop and re-created from the Start Menu shortcuts (right-click on them to show the menu)

Among our current "fleet" we still have 2 or 3 32-bit-only CPUs, and 2 or 3 MoBos with 1 ot 1.5 GB of RAM.
As only the first of my scripts is dependent on i386/amd64 architecture , the rest of them could probably be applied to i386 Ubuntu to upgrade it to i386 Bookworm and to install Lubuntu packages on it.
I did not check this scenario but I believe it could work without additional issues.
Hope, we would receive needed hardware upgrades earlier that this would be needed for real.