Showing headlines posted by dba477

Per https://forum.manjaro.org/t/xz-package-contains-a-vulnerabil... Arch does not directly link openssh to liblzma, and thus this attack vector is not possible. You can confirm this by issuing the following command: $ ldd "$(command -v sshd)" . However, out of an abundance of caution, we advise users to remove the malicious code from their system by upgrading either way. This is because other yet-to-be discovered methods to exploit the backdoor could exist. – Arch Linux - News: The xz package has been backdoored

The main purpose of this post is to demonstrate that the cockpit.service is not required for deploying KVM guests in UEFI mode on AlmaLinux 9.3, which has binary-compatibility with RHEL. Linux bridge for VMs has been installed via nmcli to avoid any involvement of cockpit.service. See for detailis http://lxer.com/module/newswire/view/338368/index.html Everything works on AlmaLinux 9.3 as on openSUSE Tumbleweed. KVM Setup on AlmaLinux 9.(X) follows standard guide lines.

First of all I state, that I am not promoting Kingston's NVME SSD and SATA SSD . Personally, I've been using for a while 2x(WD Blue 500 NVMe SSD) . I've also been testing KDE Plasma 6.0 and Gnome 46 on several boxes equiped with NVMe drives and 32 GB RAM :- When it comes to superior storage technology, NVMe is in a league of its own. Even at a glance, the differences between NVMe and SATA in performance are impressive. The communication drivers and interface between NVMe and SATA are completely different. SATA uses AHCI drivers that are designed for hard disk drives (HDD) with spinning technology while the NVMe driver is specifically designed for SSDs with flash technology. In addition, NVMe is able to take advantage of the PCIe sockets to communicate between the storage interface and system’s CPU for even greater leverage.

Cockpit Client provides a graphical interface to your servers, containers, and virtual machines. Connections are made over SSH, using the SSH configuration of the local user (including aliases, known hosts, key files, hardware tokens, etc).

Porting KDE Plasma 6.0.2 to Manjaro 23.1 was performed by commands $ sudo pacman-mirrors --api --set-branch testing ; $ sudo pacman -Scc ; $ sudo pacman-mirrors --fasttrack 5 ; $ sudo pacman -Syyu . I may confirm the issue mentioned in https://forum.manjaro.org/t/i-tested-kde-6-oh-my-oh-my-you-w... . I've also tested with no problems opening *.webp files via Dolphin on the most recent fedora 40 KDE nightly build. See snapshot . . .

Deployment KVM Guest of openSUSE Tumbleweed was performed via the most recent ISO image dated 03/13/2024. Default disk layout was also updated with LVM Group. Following below are just several reports obtained by different GUI Tools

KDE Plasma 6.0.1 seems to work with no obvious issues on Fedora 40 WKS ( nightly build as of 03/06/24 ) . Looks like requirements for beta staging for Fedora 40 and openSUSE 15.6 are a bit different. Anaconda Blivet GUI on Fedora 40 WKS allows to create any desired disk layout even during deployment WorkStation. Spice console works just fine for L1 and L2 KVM Guests .

This post gives a detailed description of procedure creating network bridge via nmcli commands and virsh CLI. Same procedure was also tested with no issues on openSUSE Leap 15.5. Both tests have been performed in VENV and allow to avoid setup of Cockpit Web Console

A showstopping issue has come to light that has now led to this feature being diverted to Fedora 41 instead. The matter was raised over an important difference in behavior during the storage/disk setup between the existing installer and the new web UI solution.

Actually, what happens right now during deploying KVM Guest via Fedora-Workstation-Live-osb-40-20240301.n.0.x86_64.iso . At the time of writing I clearly saw Anconda Web UI behavior during installation via ISO image pointed above. Awareness of article https://www.phoronix.com/news/Fedora-Web-Installer-F41-Delay explains the reason why Anaconda Web UI was postponed until Fedora 41 and provide some light on why OSB image behaves the way described here in details .

KDE Neon KVM guest was deployed via neon-user-20240229-0716.iso. Python 3.12.2 installation has been performed per https://www.dedicatedcore.com/blog/install-pyenv-ubuntu/ , in particular case no upgrade of KDE Plasma up to 6.0 was required

This post is an immediate follow up on previous one http://lxer.com/module/newswire/view/337189/index.html to perform install Python 3.12.2 for particular user via pyenv in the same way as it was done in the link above. Then create new project in PyCharm with path to interpreter /home/boris/.pyenv/versions/3.12.2/bin/python3 .

Anaconda Web UI installer was tested step by step with encrypted root BTRFS volume and the most recent installer's interface. KDE Plasma 6 RC2 was installed as second DE and smooth switching between DEs was verified

First install pyenv on Tumbleweed. You may follow for instance http://lxer.com/module/newswire/view/337068/index.html. Then install Python3.13-dev (or Python3.13.0a2(3)) via pyenv . It won't affect system-wide Python 3.11.(X) . . . . Same way procedure would work on SparkyLinux2024.2 or Manjaro 23.1 and Manjaro Testing as well .

In order to access a branch, you need to change your pacman-mirrors configuration. You are supposed substitute the value colored in blue (for illustrative purposes only) to one of the following: stable, testing or unstable. Manjaro Testing is runing kernel 6.7.4, System-wide Python appears to be 3.12.1, libvirt version 10.0 . The libvirt version has been displayed via virsh console.

This option of Pycharm 2023.3 setup works for me with no issues so far. I am not quite sure that under any circumstances I am supposed to work via flatpak/flathub .

Pyenv is a tool for managing multiple Python versions. Once pyenv is installed you can easily switch between one project that uses Python 3.12 and a system-wide default Python 3.11. Same approach works fine on openSUSE Tumbleweed, SparkyLinux 7.2, SparkyLinux 2024.1

Pyenv is a tool for managing multiple Python versions. Once pyenv is installed you can easily switch between one project that uses Python 3.12 and a system-wide default Python 3.11, without any additional doubt. Same schema would work on SparkyLinux 2024.1

Following post is a compilation from several sources, which looked unexpectedly complicated due to I was unable to find out the way of installation like on the known Linux flavors (Fedora,Debian,Ubuntu). Actually "pyenv install 3.1X" appears to be the build via original python's tar ball. Before you can use a specific Python version, you need to install and configure pyenv.

On both Sparky releases (stable 7.2 and Seven-Sisters) kernel 6.7.2 may be installed via Synaptic Manager. Command "$ sudo apt install kde-standard" allows to switch from X11 to Wayland via relogin to Sparky instance. Just one more option comes up on SDDM login screen. Libvirt version 10.0 may be tested on SparkyLinux1024.1