cross-posted from: https://discuss.tchncs.de/post/24467025

cross-posted from: https://discuss.tchncs.de/post/22673014

cross-posted from: https://lemm.ee/post/41570987

I was kinda surprised no one shared this here.

Konqi is KDE's mascot, lore here: https://community.kde.org/Konqi

Sauce: https://toot.finfur.net/@Neotheta/113074150288818364

🌈 🧦

Original text:

Ah.. I got distracted.

What if I drew Konqi in a similar style as Theo? Or both of them? Theo wouldn't understand anything since he lives in the wild but he would politely listen.

I been using KDE in the past year and been pretty happy with it.

Source: Furaffinity

cross-posted from: https://lemmy.ca/post/27784074

cross-posted from: https://lemmy.ca/post/27756512

(Apologies if the link doesn't work; Google are dicks)

cross-posted from: https://lemmy.ca/post/27447560

cross-posted from: https://lemmy.blahaj.zone/post/15137437

(not really pipewire itself but an interaction with wireplumber/libcamera/the kernel, but pipewire is what triggers the problem)

As seen in https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2669 and https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/4115

The camera's /dev/video file is kept open (without streaming), sadly causing the camera to be powered on what looks to be most devices. For some reason, this completely nullifies the soc power management on modern laptops and can result in increases from 3W to 8W at idle!

On Intel laptops it's a bit easier to debug because you can see the Cstates in powertop not going low but it also wrecks AMD ones. Some laptops can reach lower cstates, but the camera module wastes a few W anyway.

I can't believe this shipped in Ubuntu, Fedora etc without anyone noticing, and for so long. This bug is quite literally wasting GWh of power and destroys the user experience of distros in laptops.

If you have a laptop with a switch that detaches the camera from the usb bus you are probably out of the water, just plug it when you use it and the problem is sidestepped. Removing uvcvideo and modprobing it on demand can also work. Disabling the camera in Lenovo's UEFI is what I did for a year until I finally found the issue on the tracker. Some laptops also seem to not be affected, but for me it happens to every machine I've tested.

Thanks to this comment for another workaround that tells wireplumber to ignore cameras. ~/.config/wireplumber/wireplumber.conf.d/10-disable-camera.conf

wireplumber.profiles = { main = { monitor.libcamera = disabled } }

Software that only captures cameras using pipewire is rare and this hasn't given me any problem. This should probably be shipped by distros while the problem is sorted out.

Note that most laptops will have other problems stopping them from reaching deep cstates, borked pcie sd card readers, ancient ethernet nics that don't support pcie sleep properly, outdated nvme firwmare... those are separate issues that most of the time can also be tackled with some dose of tlp, but it's all for nothing if the usb camera is keeping the soc awake!

cross-posted from: https://feddit.nl/post/18702221

Hi all!

For most of my time with Linux I’ve just used vim on an ssh terminal from my MacBook. As such I’ve gotten used to the terminal management on Mac OS. Being able to cmd+c/v for copy, cmd+ for another terminal tab, etc.

However for doing graphics programming I’ve found it easier to just use my Linux box as a workstation directly. (I could use vnc or something but meh).

I could probably just set up my key bindings with a script but I thought I would ask if anyone knows of a good terminal emulator which has the MacOS vibes/keybindings.

(Post required photo so added cats)

Thanks!

cross-posted from: https://lemmy.ml/post/17747926

Back in June the developers of Fishards put out a bit of an ultimatum: fight them in-game and win to make the game open source, or they will nuke the game from orbit.

Thankfully, the community came together, and won. So now Fishards has been made open source, and it's still free to play on Steam too.

cross-posted from: https://discuss.tchncs.de/post/18099780

Bazzite comes ready to rock with Steam and Lutris pre-installed, HDR support, BORE CPU scheduler for smooth and responsive gameplay, and numerous community-developed tools for your gaming needs.

Would not recommend installing arch from scratch. It literally took me multiple hours and I still need to set my software up but I'm happy to get off fedora.

A new and bizarre issue has emerged on my Linux Mint server that seems specific to my Ender 3 and OctoPrint. Every night at midnight, regardless of whether a print is running or not, the USB connection to the Ender fails and restarts. (See screenshot from my Telegram OctoPrint plugin.) I’ve tried setting usb.autosuspend to -1 in GRUB, but that doesn’t seem to help.

I’m completely stumped and could use some advice. The failures are far too scheduled and predictable to be a random hardware failure. A relevant chunk of /var/log/syslog is included below for reference.

May 5 00:00:03 borgcube systemd[1]: logrotate.service: Succeeded. May 5 00:00:03 borgcube systemd[1]: Finished Rotate log files. May 5 00:00:03 borgcube kernel: [93921.837884] usb 1-5.4: new full-speed USB device number 9 us ing xhci_hcd May 5 00:00:03 borgcube systemd[1]: man-db.service: Succeeded. May 5 00:00:03 borgcube systemd[1]: Finished Daily man-db regeneration. May 5 00:00:03 borgcube kernel: [93922.059024] usb 1-5.4: New USB device found, idVendor=1a86, idProduct=7523, bcdDevice= 2.63 May 5 00:00:03 borgcube kernel: [93922.059026] usb 1-5.4: New USB device strings: Mfr=0, Produc t=2, SerialNumber=0 May 5 00:00:03 borgcube kernel: [93922.059027] usb 1-5.4: Product: USB2.0-Serial May 5 00:00:03 borgcube kernel: [93922.066323] ch341 1-5.4:1.0: ch341-uart converter detected May 5 00:00:03 borgcube kernel: [93922.066896] usb 1-5.4: ch341-uart converter now attached to ttyUSB0 May 5 00:00:03 borgcube mtp-probe: checking bus 1, device 9: "/sys/devices/pci0000:00/0000:00:1 4.0/usb1/1-5/1-5.4" May 5 00:00:03 borgcube mtp-probe: bus: 1, device: 9 was not an MTP device May 5 00:00:03 borgcube snapd[1104]: hotplug.go:200: hotplug device add event ignored, enable e xperimental.hotplug May 5 00:00:03 borgcube mtp-probe: checking bus 1, device 9: "/sys/devices/pci0000:00/0000:00:1 4.0/usb1/1-5/1-5.4" May 5 00:00:04 borgcube mtp-probe: bus: 1, device: 9 was not an MTP device

Original post here: https://pounced-on.me/@dancrescentwolf/112280924285356180

Quote from the Mastodon post:

I made a free wallpaper of Konqi

:3

You can download the 4k .png file on my ko-fi shop uwu Hope I'll be able to do more :3

cross-posted from: https://discuss.tchncs.de/post/13377347

openSUSE addresses supply chain attack against xz compression library

openSUSE maintainers received notification of a supply chain attack against the “xz” compression tool and “liblzma5” library.

Background

Security Researcher Andres Freund reported to Debian that the xz / liblzma library had been backdoored.

This backdoor was introduced in the upstream github xz project with release 5.6.0 in February 2024.

Our rolling release distribution openSUSE Tumbleweed and openSUSE MicroOS included this version between March 7th and March 28th.

SUSE Linux Enterprise and Leap are built in isolation from openSUSE. Code, functionality and characteristics of Tumbleweed are not automatically introduced in SUSE Linux Enterprise and/or Leap. It has been established that the malicious file introduced into Tumbleweed is not present in SUSE Linux Enterprise and/or Leap.

Impact

Current research indicates that the backdoor is active in the SSH Daemon, allowing malicious actors to access systems where SSH is exposed to the internet.

As of March 29th reverse engineering of the backdoor is still ongoing.

Mitigations

openSUSE Maintainers have rolled back the version of xz on Tumbleweed on March 28th and have released a new Tumbleweed snapshot (20240328 or later) that was built from a safe backup.

The reversed version is versioned 5.6.1.revertto5.4 and can be queried with rpm -q liblzma5.

User recommendation

For our openSUSE Tumbleweed users where SSH is exposed to the internet we recommend installing fresh, as it’s unknown if the backdoor has been exploited. Due to the sophisticated nature of the backdoor an on-system detection of a breach is likely not possible. Also rotation of any credentials that could have been fetched from the system is highly recommended. Otherwise, simply update to openSUSE Tumbleweed 20240328 or later and reboot the system.

• SUSE Security CVE-2024-3094 information page
• OSS Security disclosure of the vulnerability

More Information about openSUSE:

• https://news.opensuse.org/
• https://discuss.tchncs.de/c/openSUSE@kbin.social

Im using MX linux, my husband helped set it up. That is all :3

SomeOrdinaryGamer just gave one of the best 1st-time Linux tutorial videos I've seen in quite some time. The fact he did so with an audience of 3.7 million subscribers is even more incredible.

Great video, and while I'm not necessarily a huge fan of Mint, it's still a great starting out point for newbies. Definitely a good video to pass along to any potential/prospective Linux users so they can learn the ropes of things.

cross-posted from: https://sh.itjust.works/post/16308770

Proton Mail Finally Releases Desktop Apps With a Linux Beta Version

cross-posted from: https://lemmy.nz/post/7859245

The Great Linux Uprising

Bonus color version ft. Madagascar Penguins:

cross-posted from: https://lemmy.world/post/12722680

Died from reading this

Messing around with stardustxr. It is kind of hard setting up because of the lack of documentation so let me know if you have question trying it.