deleted by creator
deleted by creator
zsh, because of highly customizable.
I use Yubikey 5 NFC and Canokey Pigeon, both works out of box on Linux.
I don’t think Sidebery is a great implementation unless the developers fix this bug. It can be reproduced stably and is important for users who opened many tabs and keep them between session.
It’s better to integrate Tree Style Tab addon instead. It’s not a good idea to re-implement a function which already has a great implementation…
Konsole, because I can use it in editor(Kate), file manager(Dolphin), IDE(KDevelop), standalone window and Quake style window.
Use a git repo and stow
tool. For updating, you only need run git pull
(and stow
if you create config for a new software). If you modify some config, just git add && git commit && git push.
With this way, you can also record change history of your config.
Oh, my bad. But OpenGL ES 3.1 and Vulkan 1.2 is also not suitable to 2023. Hope the developers can make driver support Vulkan 1.3.
OpenGL 3.1 and Vulkan 1.2 in 2023? It’s so terrible!
The way to support Nvidia 20x 30x 40x series GPU.
I use Porkbun.com. It has modern interface.
Usually in /usr/lib/systemd/user/plasma-plasmashell.service
, but you can edit with systemctl --user edit plasma-plasmashell.service
directly.
Firefox only uses wayland by default in nightly. You can enable it in stable version by setting environment variable MOZ_ENABLE_WAYLAND=1.
There is a benchmark use https://webglsamples.org/aquarium/aquarium.html
https://blog.lilydjwg.me/2021/11/12/display-tearing.215968.html
- X11 + Intel card, 1080p 60fps, GPU fully utilized, one third of frames dropped! 4k 60fps is about the same. It turns out that the focus is not on the resolution (the GPU isn’t used to its full capacity anyway), it’s on the frame rate of the video.
- Wayland + Intel cards, 4k 60fps, not even dropping frames, let alone anything else, and the GPU is used for about half of the graphics calculations.
For hardware decode, when I switched to wayland, it was only implemented in Wayland. After they implememted EGL on X11, they implemented hardware decode on X11 as well.
For mixed DPI, applications can implement it use screen information, but not all applictions will do this. But wayland ask them to implement this feature.
It’s reference implementation, but isn’t suitable for daily use. Because it lacks some convenient features. It’s used as a behavior reference when some one develop a new compositor.
It may be related to Nvidia. Most bugs I met in Wayland is related to it. Such as no dmabuf export support, and vulkan init will fail because a bug in nvidia prime implementation…
As Linus said, so Nvidia, fuck you…
You should, I think. You don’t have Nvidia GPU, so you can avoid almost bugs and get better performance.
Advantages:
Disadvantages:
I don’t know which DE/WM you use. If you use Plasma/GNOME, migration is simple, just switch in SDDM/GDM. If you use i3, you can try sway, it’s compatible with i3 config. If you use others, you can try hyprland or wayfire. Wayfire has fantastic animations.
I switch to wayland because I buy a new screen with different DPI… But when I switched, I found I got better performance and video hardware acceleration in Firefox (this feature was introduced to Firefox Wayland first).
Yeah, it works well with my Wacom CTL-671.
In my opinion, that’s because X11 lacks proper abstract for many things like screenshot, screencast, color managerment and etc, so the applications have to use many X11 implementation details to implement these features. It leads to high-coupling code with X11 so move their code to wayland and ensuring it works correctly and is consistent with the old behavior is difficult.