Good luck. :)

The existing distro Neon has issues generally because of their choice to use Ubuntu LTS as a base. This is because KDE Plasma needs newer libraries usually than Ubuntu LTS can provide

In other words, they don’t have enough resources dedicated to doing it well. This is part of the problem I described.

Basing it on Arch means they’ll almost always have the latest libraries ready to go.

That could reduce the work required in one area, but would increase it in another. Arch fails the “doesn’t break” goal on its own, which means someone would have to do more work if they want to achieve it.

I think dropping loadable module support would severely limit what users can do when a driver misbehaves or doesn’t handle a particular device as well as an (in-tree) alternative.

Also, I wonder how they expect to achieve being “The KDE operating system” or “doesn’t break” when their existing distro has been more than a little rocky so far. Who do they think will do the long-term work of raising and maintaining the quality bar?

It would be kool to have a solid reference distro where Plasma could shine, especially for organisations and newer users who don’t know how to replace GNOME on existing distros. But this proposal gives me the impression that they underestimate the effort required, so I am skeptical.

You are correct. Traditional X middle-button behavior is to insert the primary selection, from any application. It is distinct from the cilpboard(s), has no “copy” step, and doesn’t behave the same as “paste” (it can’t paste over another primary selection).

Many people don’t notice the difference, though, especially if they’re used to an environment that lacks that functionality, like Windows. Some might even get confused or frustrated when the middle click doesn’t work quite as they expect (which, of course, is because it’s actually doing something different).

https://www.jwz.org/doc/x-cut-and-paste.html

It’s also possible that OP remapped their middle button to paste from the clipboard, although their phrasing makes it seem unlikely.

You can’t know with certainty on Signal that the client and the server are actually keeping your messages encrypted at rest, you have to trust them.

This is untrue. By design, messages are never decrypted on servers when end-to-end encryption is in use. They would have to break the encryption first, because they don’t have the keys.

Some advantages are listed in this /c/Technology comment:

https://lemmy.sdf.org/comment/15398090

Which KDE Neon download contains the current 6.2 beta?

(I ask because last time I tried to test a beta, none of them did.)

It might be interesting to determine whether the freezes are limited to Plasma or are happening within the kernel.

• Have you tried Control+Alt+F1/F2/F3 … F8, to see if switching virtual consoles still works while the freezes are happening?
• Do you have another machine on the same network? You could use it to ssh into your desktop machine, and when the freezes are happening, see if they affect ssh interactivity.

Plasma 6 bugs have only recently come down to the level of its predecessor, according to Nate.

What do you like about it that isn’t available in Plasma 5.27?

It appears so.

https://beehaw.org/comment/3686715

you can click on the “Explore projects” button in the corner and click on the huge search field in the middle of the screen: it will list the option “Language”.

I didn’t know it supported this mode of searching; thanks for pointing it out. I just wish there was a way to collapse all of a project’s forks into one entry. The search results take forever to sift through because there are about fifty bazillion forks of each project.

Sandboxing them, having a manual review process, would help. But that is a TON of work.

This is why it would make sense to have a restrictive and simple API that supports basic extensions with little oversight. Configuration only; no executable code.

For the small minority of add-ons that would require executable code, there could be a separate API with a more involved installation process, making it obvious to the user that the trust and risk levels are different from the above. A sandbox feature could perhaps be developed in the long run, but that is indeed a ton of work and hard to get right, and isn’t really necessary for this approach to be effective. Just having a software-style installation process (e.g. through a distro’s package manager) and different APIs would go a long way toward protecting users.

It’s probably worth noting that Plasma’s customization support is useful not only to people looking for a special look & feel, but also as a proving ground for new things (and new approaches to old things) that can eventually make their way into mainline Plasma. Making things harder to customize would mean fewer people experimenting, refining ideas, and solving problems. With that in mind, I think that removing customization in hopes of simplifying test cases would be a mistake.

However, it’s my understanding that some of Plasma’s customization hooks allow third-party theme components to run arbitrary code, without even a warning, sandbox, or reasonable way for the user to inspect it beforehand. (This was in the news a couple months back, IIRC.) That was more or less okay 20-25 years ago, when malware on Free operating systems was almost unheard of, but it’s dangerous and irresponsible in today’s world, where extensions/plugins have become common attack vectors. I wouldn’t mind a little loss of customization to shut down that vulnerability, at least until safer extension APIs can be built.

Indeed, protocol is independent from implementation language, but that isn’t the question at hand.

Do you know whether Beehaw will still federate with the lemmyverse (and therefore the rest of us) after moving to Sublinks?

That could also mean client API-compatible, so Lemmy apps would work with it, which doesn’t address federation.

Will it federate with Lemmy? I would miss you folks.

Who cares? It’s run by reactionary incels, transphobes, and racists.

Wait until you find out who runs Lemmy development.

Edit replacing my original comment:

Looks like that package has been superseded by org.gtk.Gtk3theme.Breeze. That’s what I’m using, and it is receiving updates.

$ flatpak remote-info flathub org.gtk.Gtk3theme.Breeze-Dark
         ID: org.gtk.Gtk3theme.Breeze-Dark
        Ref: runtime/org.gtk.Gtk3theme.Breeze-Dark/x86_64/3.22
       Arch: x86_64
     Branch: 3.22
 Collection: org.flathub.Stable
   Download: 156.9 kB
  Installed: 386.6 kB

     Commit: 5a19b0c0808f82290d1f64c95d2406a860329817e0f269b4aaf0a1bbba92323a
     Parent: 390f820d32df2f22e3a3165eb4d65071dcb93a357ae7730f4ca548b5d016b966
End-of-life: This theme has been replaced by org.gtk.Gtk3theme.Breeze, see README for workaround on using system color schemes. https://github.com/flathub/org.gtk.Gtk3theme.Breeze#workarounds
    Subject: Add EOL (fc4339ff)
       Date: 2022-02-22 00:21:51 +0000

How to turn them square?

I don’t think yt-dlp has built-in image cropping, so it’s just going to download thumbnails in the resolutions provided by the server. (See the --list-thumbnails option.) To crop what you download, consider a tool like (ImageMagick)(https://imagemagick.org/).

KDE Connect also runs on more operating systems. It’s worth mentioning to friends who run Windows.