Molecular0079

joined 1 year ago
[–] Molecular0079@lemmy.world 10 points 3 months ago

You're correct. While the stable version of KDE Wayland is usable right now with the new driver with no flickering issues, etc., it technically does not have the necessary patches needed for explicit sync. Nvidia has put some workarounds in the 555 driver code to prevent flickering without explicit sync, but they're slower code paths.

The AUR has a package called kwin-explicit-sync, which is just the latest stable kwin with the explicit sync patches applied. This combined with the 555 drivers makes explicit sync work, finally solving the flickering issues in a fast performant way.

I've tested with both kwin and kwin-explicit-sync and the latter has dramatically improved input latency. I am basically daily driving Wayland now and it is awesome.

[–] Molecular0079@lemmy.world 9 points 4 months ago (1 children)

The task manager is just another widget on the panel. Right click anywhere on the panel (except on the tray icons, those are special), and click Enter edit mode. Then you can drag the task manager along the panel and configure it how you like.

[–] Molecular0079@lemmy.world 1 points 4 months ago

Yeah that explains why you're not seeing the issue. Seems like drkonqi activates on logout and holds up the entire process.

[–] Molecular0079@lemmy.world 1 points 4 months ago (1 children)

I do not have this file at all. I think yours was a different issue.

[–] Molecular0079@lemmy.world 2 points 5 months ago

It will occasionally work so you may have just gotten lucky. It seems like its a drkonqi issue, see the linked upstream bug report for the workarounds. You can either uninstall drkonqi or just mask the systemd service for now.

[–] Molecular0079@lemmy.world 1 points 5 months ago (2 children)

Do you have drkonqi installed? According to this thread, it's an issue with drkonqi.

https://bbs.archlinux.org/viewtopic.php?pid=2163139#p2163139

[–] Molecular0079@lemmy.world 7 points 5 months ago* (last edited 5 months ago)

Oh come on, that camera bar sticks out so much. I am so tired of this design gimmick. Every Pixel phone with a case already looks ridiculously thick just so that the stupid bar is protected. With how thick it looks on the Pixel 9, the whole phone is just going to be a chonker by the time someone slaps a case on it.

All this coming at a time when my perfectly fine Pixel 5 just got EOLed is demoralizing.

[–] Molecular0079@lemmy.world 1 points 5 months ago

My main issue with it is that it is way too thick. Most lopsided camera bumps somehow are more compact and thinner. You'd think with the amount of real estate that visor takes up they'd be able to make it flush with the rest of the back somehow, or at least match the thickness of phone cameras

[–] Molecular0079@lemmy.world 2 points 5 months ago (3 children)

I really wish they'd ditch that stupid camera bar. Every phone case attempts to hide it and it just makes the whole thing needlessly thick.

[–] Molecular0079@lemmy.world 50 points 5 months ago (1 children)

No kidding. This solves a major issue with the Steam Deck as well, because now someone else can be playing on the Deck while you use your main PC for another game.

[–] Molecular0079@lemmy.world 10 points 5 months ago

I use podman with the podman-docker compatibility layer and native docker-compose. Podman + podman-docker is a drop-in replacement for actual docker. You can run all the regular docker commands and it will work. If you run it as rootful, it behaves in exactly the same way. Docker-compose will work right on top of it.

I prefer this over native Docker because I get the best of both worlds. All the tutorials and guides for Docker work just fine, but at the same time I can explore Podman's rootless containers. Plus I enjoy it's integration with Cockpit.

[–] Molecular0079@lemmy.world 1 points 5 months ago

Settings and internet are fine. I dunno what to tell you. Very frequently Windows update shows its head, like I'll randomly want to restart my computer because I installed a piece of software that required it, and then it kicks off a long round updates when I just want to use my computer.

I still think having to leave it on and let it run in the background is still just addressing the symptoms. An update process should be way faster than that so that such a thing isn't needed.

 

I tried both Mullvad and Mozilla VPN and when I do a dns test, both are still using my ISP's DNS instead of the VPN's. This only happens on my Arch systems, works fine on my phone.

EDIT: Turns out these VPN clients depend on systemd-resolved in order to change your DNS. Enabling the service makes it work properly. A bit scary that they don't give you a warning that you're leaking DNS if you don't have systemd-resolved enabled.

 

I am in the process of making a DIY NAS box and I am debating between mdadm + BTRFS and ZFS. What are your experiences with using ZFS on Arch? Have you run into any major issues? Does ZFS being an external kernel module cause any annoyances with the frequent Arch kernel updates?

Give me the dirty details! Any recommendations or pitfalls I should avoid?

Thanks!

 

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

Every time I plug in my Quadcast S USB mic into my Arch Linux box, I can't properly go into deep sleep. Unplugging it before attempting to sleep makes it work again, but its annoying to have to do that every time. How do I debug this and where do I even submit a bug report for this?

Here's the relevant journalctl:

Jul 10 11:59:39 systemd[1]: Starting System Suspend...
Jul 10 11:59:39 systemd-sleep[70254]: Entering sleep state 'suspend'...
Jul 10 11:59:39 kernel: PM: suspend entry (deep)
Jul 10 11:59:39 kernel: Filesystems sync: 0.066 seconds
Jul 10 11:59:42 kernel: Freezing user space processes
Jul 10 11:59:42 kernel: Freezing user space processes completed (elapsed 0.001 seconds)
Jul 10 11:59:42 kernel: OOM killer disabled.
Jul 10 11:59:42 kernel: Freezing remaining freezable tasks
Jul 10 11:59:42 kernel: Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
Jul 10 11:59:42 kernel: printk: Suspending console(s) (use no_console_suspend to debug)
Jul 10 11:59:42 kernel: serial 00:04: disabled
Jul 10 11:59:42 kernel: sd 2:0:0:0: [sdb] Synchronizing SCSI cache
Jul 10 11:59:42 kernel: sd 1:0:0:0: [sda] Synchronizing SCSI cache
Jul 10 11:59:42 kernel: sd 5:0:0:0: [sdc] Synchronizing SCSI cache
Jul 10 11:59:42 kernel: sd 1:0:0:0: [sda] Stopping disk
Jul 10 11:59:42 kernel: sd 2:0:0:0: [sdb] Stopping disk
Jul 10 11:59:42 kernel: sd 5:0:0:0: [sdc] Stopping disk
Jul 10 11:59:42 kernel: ACPI: PM: Preparing to enter system sleep state S3
Jul 10 11:59:42 kernel: ACPI: PM: Saving platform NVS memory
Jul 10 11:59:42 kernel: Disabling non-boot CPUs ...
Jul 10 11:59:42 kernel: Wakeup pending. Abort CPU freeze
Jul 10 11:59:42 kernel: Non-boot CPUs are not disabled
Jul 10 11:59:42 kernel: ACPI: PM: Waking up from system sleep state S3
Jul 10 11:59:42 kernel: sd 5:0:0:0: [sdc] Starting disk
Jul 10 11:59:42 kernel: sd 2:0:0:0: [sdb] Starting disk
Jul 10 11:59:42 kernel: sd 1:0:0:0: [sda] Starting disk
Jul 10 11:59:42 kernel: serial 00:04: activated

Thanks in advance!

 

Every time I plug in my Quadcast S USB mic into my Arch Linux box, I can't properly go into deep sleep. Unplugging it before attempting to sleep makes it work again, but its annoying to have to do that every time. How do I debug this and where do I even submit a bug report for this?

Here's the relevant journalctl:

Jul 10 11:59:39 systemd[1]: Starting System Suspend...
Jul 10 11:59:39 systemd-sleep[70254]: Entering sleep state 'suspend'...
Jul 10 11:59:39 kernel: PM: suspend entry (deep)
Jul 10 11:59:39 kernel: Filesystems sync: 0.066 seconds
Jul 10 11:59:42 kernel: Freezing user space processes
Jul 10 11:59:42 kernel: Freezing user space processes completed (elapsed 0.001 seconds)
Jul 10 11:59:42 kernel: OOM killer disabled.
Jul 10 11:59:42 kernel: Freezing remaining freezable tasks
Jul 10 11:59:42 kernel: Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
Jul 10 11:59:42 kernel: printk: Suspending console(s) (use no_console_suspend to debug)
Jul 10 11:59:42 kernel: serial 00:04: disabled
Jul 10 11:59:42 kernel: sd 2:0:0:0: [sdb] Synchronizing SCSI cache
Jul 10 11:59:42 kernel: sd 1:0:0:0: [sda] Synchronizing SCSI cache
Jul 10 11:59:42 kernel: sd 5:0:0:0: [sdc] Synchronizing SCSI cache
Jul 10 11:59:42 kernel: sd 1:0:0:0: [sda] Stopping disk
Jul 10 11:59:42 kernel: sd 2:0:0:0: [sdb] Stopping disk
Jul 10 11:59:42 kernel: sd 5:0:0:0: [sdc] Stopping disk
Jul 10 11:59:42 kernel: ACPI: PM: Preparing to enter system sleep state S3
Jul 10 11:59:42 kernel: ACPI: PM: Saving platform NVS memory
Jul 10 11:59:42 kernel: Disabling non-boot CPUs ...
Jul 10 11:59:42 kernel: Wakeup pending. Abort CPU freeze
Jul 10 11:59:42 kernel: Non-boot CPUs are not disabled
Jul 10 11:59:42 kernel: ACPI: PM: Waking up from system sleep state S3
Jul 10 11:59:42 kernel: sd 5:0:0:0: [sdc] Starting disk
Jul 10 11:59:42 kernel: sd 2:0:0:0: [sdb] Starting disk
Jul 10 11:59:42 kernel: sd 1:0:0:0: [sda] Starting disk
Jul 10 11:59:42 kernel: serial 00:04: activated

Thanks in advance!

 

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

I commented on a post a while back and thought I'd check it out again to see if there was any additional discussion. When I clicked into my comment to get to the original post, I realized the post itself had been removed. I'd like to go into the modlog and see why it was deleted but I can only filter by user. Is there a way I could download a text version of the modlog and search for the post id there?

 

I commented on a post a while back and thought I'd check it out again to see if there was any additional discussion. When I clicked into my comment to get to the original post, I realized the post itself had been removed. I'd like to go into the modlog and see why it was deleted but I can only filter by user. Is there a way I could download a text version of the modlog and search for the post id there?

 

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

Linux Unplugged had a pretty good discussion IMHO about some of the more nuanced details behind the RedHat drama that I haven't seen being covered elsewhere as much. The final opinion about RedHat I leave as an exercise to the listener.

view more: ‹ prev next ›