Hacker News Reader

Hacker News

Comment by pseudalopex | Hacker News Reader

Full thread

pseudalopex

Plasma/Wayland Known Significant Issues[1]

No ability to save and restore positions of native Wayland windows

Real-fake-session-restored apps don't remember which virtual desktop their windows were on

No full-screen aspect ratio correction

"Spare Layouts" feature not implemented

"Per-application Keyboard Layout" does not work

No way to change the gamma or manually adjust the colors without generating or finding an appropriate ICC profile

Can't switch between multiple touch strip modes

No headless RDP

Opening files using command-line binaries in Konsole doesn't raise existing windows

Global Menu is not supported for non-Qt apps

Some apps' non-maximizable windows are broken with placement policy set as maximized

[1] https://community.kde.org/Plasma/Wayland_Known_Significant_I...

View on HN

Also, I still haven't found a clipboard manager that works normally on Wayland.

And I rarely get it to recognize all my monitors first try. And it crashes semi-regularly.

Not sure how much is inherent to Wayland vs Gnome, but life is way better since I upgraded to Xlibre & Cinnamon.

> Also, I still haven't found a clipboard manager that works normally on Wayland.

I recommend Vicinae. https://docs.vicinae.com/clipboard

I've found the built-in clipboard manager on KDE Plasma 6 to be very reliable.

When I used GNOME, the Clipboard Indicator extension [1] served me well.

[1] https://extensions.gnome.org/extension/779/clipboard-indicat...

The Bluetooth integration needs work - missing features such as "never connect automatically."

Default lock screen experience still has a needless delay of 5 seconds when entering a wrong (even blank wrong) password, even on the first attempt.

+1 on the gamma controls

That sounds like tarpitting, or perhaps timing attacks protection, rather than anything wrong in the password check pipeline.

> Default lock screen experience still has a needless delay of 5 seconds when entering a wrong (even blank wrong) password, even on the first attempt.

I suspect that is not KDE's fault (or Wayland's) - it's probably PAM, which by default has a 2 second delay (+/- 50%). That default is extremely difficult to change, but you can configure it. See my instructions here: https://github.com/linux-pam/linux-pam/issues/778#issuecomme...

Also if you follow that issue you can see I've been trying to convince the PAM developers to fix it (by changing it to a 0.5 second delay, which is much more tolerable and no less secure). Unfortunately they have this weird idea that users want the delay, because it lets them recompose their thoughts after getting the password wrong or something like that.

Good lord that thread is a dumpster fire. Thanks for finding out wtf is causing this, it has annoyed me for two darn decades, but never enough to go as deep into finding the cause…

Wow, that has bugged me for years. Frustrating it's not easily configurable.

Well, seeing how systems are brute-forced and how much speed you can achieve today, these delays are more and more welcome on my end.

Authentication systems had lock out periods or increasing delays since decades. 1 attempt per 5 seconds and 12 attempts per minute would be equivalent for brute force. And 12 attempts per minute would be a very loose lock out policy.

However, it's a good starting point for any systems which might be user facing and reasonably secured by the network around the system.

There's such thing as bad defaults and starting too heavy-handed is starting with bad defaults.

In short, current default is a good compromise and a good default.

Bluetooth autoconnect configuration is a Wayland issue? I honestly would have never guessed. I always figured it was the responsibility of the DE or bluez service.

Pointer warp not generally supported so CAD programs fail in bizarre ways.

Although I think that there is FINALLY an actual spec for pointer warp. However, very few compositors support it.

The story of Wayland - restrict what applications can do in the name of "security" only to re-add the same thing in a compositor-specific way after years of pain inflicted on everyone. Wayland is fundamentally designed for the smartphone model and has no place on an open desktop.

I agree with the Wayland premise that having an old and hairy library everybody is afraid to touch is bad, but having those same capabilities implemented piecemeal and incompatibly by five (and counting!) compositor ecosystems in ways that aren't well-tested or well-integrated isn't better.

IMO Phoenix[0] is what Wayland should have been: a reimplementation of X11. We didn't need a new protocol.

https://git.dec05eba.com/phoenix

KDE on wayland doesn't let me roll up windows. I've been doing that for nearly 3 decades.

Also recently discovered KeepassXC can't do auto-type on Wayland for some reason. It seems to have a massive amount of limitations.

> KeepassXC can't do auto-type on Wayland

https://github.com/keepassxreboot/keepassxc/issues/2281

Though it looks like there's a recent PR for that:

https://github.com/keepassxreboot/keepassxc/pull/13359

Reply on news.ycombinator.com