Hyprland Starter and Dotfiles Installer on Arch Linux KDE Plasma 6.3.5

 Connect via ssh to Arch Linux Plasma KVM Guest and   issue series of commands following Stephan Raabe setup on minimal Arch Linux Instance  skipping Hyprland due to we already have alive Plasma DE been previously installed. We actually intend to run  `flatpak run com.ml4w.dotfilesinstaller`  inside KDE Plasma konsole.

   $ sudo pacman -S flatpak git curl wget firefox vim kitty

   $  git clone https://aur.archlinux.org/yay.git

   $  cd yay

   $  makepkg -si

   $  cd

   $  which yay

   Setup Dotfiles Installer (GUI based interface) as advised on github page of Stephan Raabe 

   $  bash -c "$(curl -s https://raw.githubusercontent.com/mylinuxforwork/dotfiles-installer/master/setup.sh)"

:: Adding flathub

:: Downloading Public Key

--2025-06-20 11:20:06--  https://mylinuxforwork.github.io/ml4w-flatpak-repo/ml4w-apps-public-key.asc

Loaded CA certificate '/etc/ssl/certs/ca-certificates.crt'

Resolving mylinuxforwork.github.io (mylinuxforwork.github.io)... 185.199.109.153, 185.199.110.153, 185.199.111.153, ...

Connecting to mylinuxforwork.github.io (mylinuxforwork.github.io)|185.199.109.153|:443... connected.

HTTP request sent, awaiting response... 200 OK

Length: 3159 (3.1K) [application/pgp-keys]

Saving to: ‘/home/boris/.cache/ml4w-apps-public-key.asc’

ml4w-apps-public-key.asc             100%[===================================================================>]   3.08K  --.-KB/s    in 0s

2025-06-20 11:20:07 (14.2 MB/s) - ‘/home/boris/.cache/ml4w-apps-public-key.asc’ saved [3159/3159]

:: Adding ml4w-repo

:: Installing com.ml4w.dotfilesinstaller

Looking for matches…

Required runtime for com.ml4w.dotfilesinstaller/x86_64/master (runtime/org.gnome.Platform/x86_64/47) found in remote flathub

com.ml4w.dotfilesinstaller permissions:

    ipc                   network      fallback-x11      wayland      x11      dri      file access [1]

    dbus access [2]

    [1] home

    [2] org.freedesktop.Flatpak, org.freedesktop.portal.*

        ID                                      Branch          Op      Remote       Download

 1. [✓] org.freedesktop.Platform.GL.default     24.08           i       flathub      154.9 MB / 155.4 MB

 2. [✓] org.freedesktop.Platform.GL.default     24.08extra      i       flathub      23.7 MB / 155.4 MB

 3. [✓] org.freedesktop.Platform.openh264       2.5.1           i       flathub      913.7 kB / 971.4 kB

 4. [✓] org.gnome.Platform.Locale               47              i       flathub      18.6 kB / 389.0 MB

 5. [✓] org.gnome.Platform                      47              i       flathub      336.5 MB / 392.8 MB

 6. [✓] com.ml4w.dotfilesinstaller              master          i       ml4w-repo    92.3 kB / 115.3 kB

 Installation complete.

:: Setup complete. Run the app with flatpak run com.ml4w.dotfilesinstaller

   Now switch to KDE Plasma DE and run :-

$  flatpak run com.ml4w.dotfilesinstaller

selecting kitty as preferable terminal also copying URL suggested by Stephan Raabe to  Dotfiles Installer from the page https://github.com/mylinuxforwork/hyprland-starter?tab=readme-ov-file

Then switch terminal resolution for Hyprland session manually

    $   vim monitor.conf

    [boris@localhost ~]$ cd ~/.config/hypr/conf/

    [boris@localhost conf]$ cat monitor.conf

     # See https://wiki.hyprland.org/Configuring/Monitors/

     # monitor=,preferred,auto,1

      monitor = ,1920x1080@144,0x0,1 

      At this point we are all set

Make several snapshots inside Hyperland with ML4W Dotfiles and make sure that resolution has been setup to 1920x1080 in Hyprland as second DE.

Verify switching back to KDE Plasma 6.3.5 as first DE been setup

References

NEW Hyprland Starter and Dotfiles Installer App for openSuse, Arch and Fedora PREVIEW

https://www.youtube.com/watch?v=JFBidsZOWgs&t=58s

NEW Hyprland Starter and Dotfiles Installer App for openSuse per Stephan Raabe

UPDATE as of 06/18/25 Tuning monitor resolution manually via updating monitor.conf file as follows

boris@localhost ~]$ cd ~/.config/hypr/conf/
[boris@localhost conf]$ cat monitor.conf
# See https://wiki.hyprland.org/Configuring/Monitors/
# monitor=,preferred,auto,1
monitor = ,1920x1080@144,0x0,1

Guest also inherits resolution 1920x1080

 Following below was attempt to reproduce instructions proposed in https://www.youtube.com/watch?v=JFBidsZOWgs   on openSUSE Tumbleweed installed via Agama Installer with Two DEs Gnome 48 and KDE Plasma. Originally setup was performed with Gnome along with YAST . Second KDE Plasma DE has been setup via YAST running in Gnome environment.

Here goes series of snapshots been done inside Hyprland session ( the third DE ) for openSUSE Tumbleweed instance as KVM Guest on Fedora 42 KDE Edition bare metal host.

  

I believe that approach above is utilizing flatpack software design Per Google's AI report ( in brief )

Flatpak is a system for distributing and running applications on Linux. It works by packaging applications and their dependencies into isolated environments called "sandboxes," preventing them from directly interacting with the host system's files and settings. This isolation enhances security and allows applications to run consistently across different Linux distributions. In essence, Flatpak provides a way to package and distribute applications independently of the underlying Linux distribution, ensuring consistency, security, and ease of updates

Description of Sandboxing in details is also provided on the same page by  Google's AI 

Key bindings to invoke hyprshot may be done per https://unix.stackexchange.com/questions/746377/how-do-i-take-screenshot-in-hyprland 

via updating file  ~/.config/hypr/conf/binds.conf

REFERECES

https://github.com/mylinuxforwork/hyprland-starter?tab=readme-ov-file

Setup Hyprland with ML4W 2.9.8.6 Dotfiles as second DE for CachyOS 053025 Gnome

 Installation was performed via paru, which appears to be preinstalled on  CachyOS 053025 (Gnome 48.2 as DM) . I have to notice that CachyOS 053025 with KDE Plasma and SDDM  caused trouble for me due to disappearing drop down login options in left down corner of SDDM login prompt . Thus I was forced to disable SDDM service and install and enable GDM service during  CachyOS KDE Plasma session . GDM is able to switch between CachyOS KDE Plasma DE and Hyprland with ML4W 2.9.8.6 Dotfiles DE with no issues . 

$ paru -S ml4w-hyprland-git

$ ml4w-hyprland-setup

Final screenshots during ml4w-hyprland-setup

GDM logging prompt up on reboot

Hyprland sessions snapshots

CachyOS 0530 Gnome 48 session

Why a cluster of 3-node controllers is important in the OpenStack cloud

This posting is just a brief extract from https://docs.redhat.com/en/documentation/red_hat_openstack_platform/10/single/understanding_red_hat_openstack_platform_high_availability/index

 

Following below is a kind of comment on the posts of Zen@yandex.com authors who write with enthusiasm about investments in cloud deployments due to the execution of virtual machines in the Cloud as cloud's major advantage according to the authors. Openstack's Cloud Fault Tolerance advantage vs traditional Client Server Unix/Lnux architecture seems to be completely ignored in writings mentioned above.

A three-node controller cluster is important in OpenStack because it provides high availability and fault tolerance for control plane services. With three nodes, the cluster can tolerate the failure of a single node without disrupting cloud functionality, according to Red Hat documentation.

This ensures that important services such as authentication, image storage, and networking remain operational even if one controller node experiences problems.

Here's a more detailed explanation:

High Availability (HA):

With three nodes, the cluster can maintain a quorum (majority vote) even if one node fails. This ensures that the remaining two nodes can continue to manage the cloud infrastructure.

Fault Tolerance:

If one controller node fails, the other two can take over its workload, preventing service disruption and data loss.

Redundancy:

The three nodes act as backups for each other, meaning if one node fails, another can immediately take over its responsibilities.

Quorum:

OpenStack high availability setup relies on quorum (majority voting) to ensure that the cluster can make decisions and maintain consistency even if some nodes are down or unavailable. A three-node cluster is ideal for achieving quorum.

Production Environments:

The Red Hat OpenStack platform requires three controller nodes for a production-grade environment to ensure high availability and reliability. In fact, a three-node controller cluster is essential for a reliable and fault-tolerant OpenStack cloud environment, especially in production environments where downtime is unacceptable.

This is the reason why you should seriously invest in Cloud deployments. Running virtual machines on Compute Nodes has nothing to do with the fault tolerance of a Cloud deployment.

Red Hat documentation is open source. Per. "Understanding Red Hat OpenStack Platform High Availability"

Most of the high availability (HA) coverage in this document pertains to controller nodes. There are two primary HA (High Availability) technologies used on Red Hat OpenStack Platform controller nodes:

Pacemaker: By configuring virtual IP addresses, services, and other functions as resources in a cluster, Pacemaker ensures that a specific set of OpenStack cluster resources are up and available. When a service or an entire node in a cluster fails, Pacemaker can restart the service, remove the node from the cluster, or reboot the node. Requests to most of these services are made through HAProxy.

HAProxy: When you configure more than one controller node with a director in Red Hat OpenStack Platform, HAProxy is configured on those nodes to load balance traffic to some of the OpenStack services running on those nodes.

Galera: Red Hat OpenStack Platform uses the MariaDB Galera cluster to manage database replication.

Highly available services in OpenStack operate in one of two modes:

Active/active: In this mode, the same service is started on multiple controller nodes using Pacemaker, then traffic can either be distributed among the nodes running the requested service using HAProxy, or directed to a specific controller via a single IP address. In some cases, HAProxy distributes traffic among active/active services on a round-robin basis. Performance can be improved by adding more controller nodes.

Active/passive: Services that are not capable or reliable enough to operate in active/active mode operate in active/passive mode. This means that only one instance of the service is active at a time. For Galera, HAProxy uses stick-table settings to ensure that incoming connections are directed to a single backend service. Galera master-master mode can become blocked when services access the same data from multiple Galera nodes at the same time.

As you begin exploring the high availability services described in this document, keep in mind that "the director system (called the undercloud) itself runs OpenStack. The purpose of the undercloud is to create and maintain the systems that will become your OpenStack running environment." The environment you create from the undercloud is called the overcloud. To get into your overcloud, this document asks you to log into your undercloud, then select which overcloud node you want to explore.

Setup KDE Plasma 6.5 Dev on openSUSE Tumbleweed

 First step would be to enable required repos, so run as root following script and reboot instance . Versions of some packages have been installed were verified via commands

$ sudo zypper search -s plasma*desktop*

$ sudo zypper search -s plasma*workspace*

localhost:/home/boris # cat instRepo.sh
zypper ar -fp 75 \ https://download.opensuse.org/repositories/KDE:/Unstable:/Qt/openSUSE_Tumbleweed/ KDE:Unstable:Qt ;
zypper ar -fp 75 \ https://download.opensuse.org/repositories/KDE:/Unstable:/Frameworks/openSUSE_Factory/ KDE:Unstable:Frameworks ;
zypper ar -fp 75 \ https://download.opensuse.org/repositories/KDE:/Unstable:/Applications/KDE_Unstable_Frameworks_openSUSE_Factory/ KDE:Unstable:Applications ;
zypper ar -fp 75 \ https://download.opensuse.org/repositories/KDE:/Unstable:/Extra/KDE_Unstable_Frameworks_openSUSE_Factory/ KDE:Unstable:Extra ;
zypper -v dup --allow-vendor-change

.   .   .   .   .   .

The following 9 patterns are going to change vendor:
kde                20240311-2.4 -> 20231206-142.3  openSUSE -> obs://build.opensuse.org/KDE:Unstable
 kde_games          20240311-2.4 -> 20231206-142.3  openSUSE -> obs://build.opensuse.org/KDE:Unstable
 kde_internet       20240311-2.4 -> 20231206-142.3  openSUSE -> obs://build.opensuse.org/KDE:Unstable
 kde_multimedia     20240311-2.4 -> 20231206-142.3  openSUSE -> obs://build.opensuse.org/KDE:Unstable
 kde_office         20240311-2.4 -> 20231206-142.3  openSUSE -> obs://build.opensuse.org/KDE:Unstable
 kde_pim            20240311-2.4 -> 20231206-142.3  openSUSE -> obs://build.opensuse.org/KDE:Unstable
 kde_utilities      20240311-2.4 -> 20231206-142.3  openSUSE -> obs://build.opensuse.org/KDE:Unstable
 kde_utilities_opt  20240311-2.4 -> 20231206-142.3  openSUSE -> obs://build.opensuse.org/KDE:Unstable
 kde_yast           20240311-2.4 -> 20231206-142.3  openSUSE -> obs://build.opensuse.org/KDE:Unstable

The following 7 NEW packages are going to be installed:
 libKPim6AkonadiAgentWidgetBase6  25.07.70git.20250519T185713~6aa21297-ku.12.1
 libKPim6AkonadiCalendarCore6     25.07.70git.20250518T014117~d41da6f-ku.6.1
 libkwin-x11-6                    6.3.80git.20250519T183312~72d6ff38-ku.45.1
 libQt5OpenGL5                    5.15.16+kde130-ku.1.35
 libQt6Location6                  6.9.0-1.1
 phonon4qt5-backend-gstreamer     4.11.60git24~2bfadef-ku.106.13
 qt6-location                     6.9.0-1.1

495 packages to upgrade, 100 to downgrade, 7 new, 595  to change vendor.

Package download size:   339.9 MiB

Package install size change:
             |     873.1 MiB  required by packages that will be installed
   56.1 MiB  |  -  817.0 MiB  released by packages that will be removed

Backend:  classic_rpmtrans
Continue? [y/n/v/...? shows all options] (y): y

Log into updated Tumbleweed instance and invoke "Info system"

 Verify enabled repos via `zypper repos`

Verification repos enabled via YAST

Obtain versions of some plasma packages been installed and which repositories they belong

Reports above show up

plasma6-desktop    | package    | 6.3.5-1.1                                    | x86_64 | repo-oss

plasma6-desktop    | srcpackage | 6.3.80git.20250520T080957~18b56dbb-ku.101.1  | noarch | KDE:Unstable:Frameworks

plasma6-workspace  | package    | 6.3.5-1.1                                   | x86_64 | repo-oss

plasma6-workspace  | srcpackage | 6.3.80git.20250520T111850~3d998e62-ku.101.1 | noarch | KDE:Unstable:Frameworks

On instance deployed via openSUSE_Krypton.x86_64-16.0-Build13.391.iso

Same reports look as follows

REFERENCES

https://en.opensuse.org/SDB:KDE_repositories

Setup firewalld and KVM on openSUSE Leap 16 Beta manually

UPDATE as of 05/10/2025

Per https://www.theregister.com/2025/05/09/opensuse_ditches_deepin/ 

You beta, you beta, you bet

Aside from the retreat on the Eastern front, where is openSUSE going next? Well, there is a roadmap to give the general direction. We looked at the plans for Leap 16 at the start of last year, and now the beta is here.

It sounds startlingly different from the openSUSE of old. The announcement delivers several shocks. It says it is "expected to be Wayland-only," although "some Xorg remnants remain for now." That will dramatically cut the range of desktops for a start – and eliminate most of this vulture's favorites.

But there's more sad news. "The traditional YaST stack is retired." Instead, users will get the Red Hat-backed Cockpit for web-based server management, and the new Myrlyn graphical package manager as a replacement for YaST's software tool.

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

Finally I had decided to skip deployment templates for KVM Host and Cockpit Web Console for openSUSE Leap 16 Beta KVM Guest.  Due to absence of YAST on  openSUSE Leap 16 Beta guest I just issued following sequence of CLI directives which brought me to success with linux bridge been setup via Cockpit Web Console.

     $ sudo zypper ref

     $ sudo zypper update

     $ sudo zypper install firewalld

     $ sudo systemctl enable firewalld

     $ sudo systemctl start firewalld

     $ sudo systemctl status firewalld

     $ ls -l /usr/lib/firewalld/zones/

     $ sudo firewall-cmd --get-zones

     $ sudo grep -i DefaultZone /etc/firewalld/firewalld.conf

     $ sudo firewall-cmd --get-active-zones

     $ sudo firewall-cmd --zone=public --add-port=9090/tcp --permanent

     $ sudo firewall-cmd --zone=public --add-port=22/tcp --permanent

     $ sudo zypper install libvirt virt-manager

     $ sudo systemctl start libvirtd.service

     $ sudo systemctl enable libvirtd.service

     $ sudo systemctl status libvirtd.service

     $ sudo usermod -aG libvirt boris

     $ grep libvirt /etc/group

           libvirt:x:108:boris

     $ sudo reboot

     $ sudo zypper install net-tools-deprecated

     $ sudo zypper install cockpit cockpit-machines

     $ sudo systemctl enable cockpit.socket

     $  sudo systemctl start cockpit.socket

     $  sudo netstat -antp | grep 9090

      Launched Cockpit Web console and brought up bridge0 attached to enp1s0

     

Troubleshooting status of port 9090 via `sudo netstat -antp | grep 9090`

F42 running as L2 KVM Guest inside openSUSE Leap 16 Beta virtual machine

Attempt to setup openSUSE Tumbleweed via Agama Installer

UPDATE as of 04/24/2025  Agama Installer is flexible enough to accept any desired LVM's names. See screenshots at the bottom

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

My major concern during this test was to customize virtual disk layout with LVM support during partitioning phase. Everything worked fine for me when I kept names of LVMs  as was suggested by Agama installer. Classical Tumbleweed installer does allow to assign any desired LVMs names . In meantime time it seems to me that Agama doesn't inherit this feature. VM deployed with updated default LVMs names for root "/" and "/home" file-systems failed to reboot. I don't insist that it was a bug it might be some wrong step on my side.

Installation with shown above virtual disk layout completed successfully.  Following below is a couple of snapshots been done during KVM Guest runtime phase

 Linux bridge setup was performed via Cockpit Web Console

Ports 9090 and 22 where opened via enabled "ufw" service  rather then YaST graphic interface. However, YaST Control center works fine as well as appeared latter.

Download location for Agama Installer was selected via link

https://download.opensuse.org/repositories/systemsmanagement:/Agama:/Devel/images/iso/

I selected agama-installer.x86_64-14pre.0.0-openSUSE-Build106.9.iso

Update as of 04/24/2025

Kernel update up to 6.14.3 just arrived