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.

Don’t assume too much from the headline, folks. They’re not saying everything has to be rewritten by 2026. They’re saying new product lines serving critical infrastructure should be written in memory-safe languages, and existing ones should have a memory safety roadmap.

If you’re about to post about how you think that’s unreasonable, I think you should explain why.

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 could always test the waters by writing up a few of your workarounds in Lemmy posts, and seeing how much interaction they draw. If they’re well-received, the effort of building and maintaining a blog might be worthwhile.

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.

Thanks for sharing, and good luck to you both!

How old is the father?

Is he your husband?

What are the local laws around age gaps in sex and marriage?

What are the local cultural norms around the same?

Have either of those things made your relationship difficult?

The security provided by a browser is constantly changing, as the vulnerabilities, attacks, and countermeasures are constantly changing. It’s a cat-and-mouse game that never ends.

The privacy provided by a browser would be difficult to measure, since it depends a lot on browsing habits, extensions, code changes between versions, etc.

There’s no good way to calculate a metric for either type of protection, and even if there was, the metrics would be obsolete very quickly. For these reasons, I wouldn’t have tried what you attempted here.

However, there is a very simple way to compare the major browsers on privacy and reach a pretty accurate conclusion: Compare the developers’ incentives.

Check the other two dozen copies that they posted in other communities. Comments in this one explain why it’s being downvoted. (It’s not because anyone dislikes interactive fiction.)

Your account info says you joined Lemmy a couple of years ago. Could that have something to do with it? Could be that there are simply fewer of us here than wherever you were before.

Also, if Reddit is one of your haunts, keep in mind that a lot of communities there partially dispersed a little over a year ago, and not everyone has reappeared in the same place (or at all).

What are your future plans when it comes to smartphones?

Same as my current plans: I pick a smartphone that runs a privacy-friendly OS, and only use privacy-friendly apps.

Right now, that’s a de-googled Android phone running LineageOS, with F-Droid as the only app store. In future, it might be something else, like a non-Android Linux phone. My current model is 6+ years old, still gets OS updates, and still works great, so I imagine the open-source options will have improved by the time I need to replace it.

I care about things like data exfiltration, battery life, cost, and hardware longevity (important for minimising e-waste). I don’t care about AI unless it happens to impact one of those things, but since there’s nothing inherent to AI that does, the issue of whether a phone has AI capabilities is irrelevant.

By not using these AI features, you pay a lot for features you won’t be using.

Only if you’re an early adopter. Like all new tech, further research and production volume will make it relatively cheap.

Yes, it’s safe, because no, they don’t relay it. The brilliant thing about it is that it’s all done locally, on your machine.

Unfortunately, I don’t think D is good enough to prove your point. From your follow-up comment:

A language that for all intents and purposes is irrelevant despite being exactly what everyone wanted,

As someone who uses D, I can attest that it is not what everyone wanted; at least not yet. Despite all the great things in the language, the ergonomics around actually using it are mediocre at best: Several of its appealing features quickly turn it into a noisy language, error messages are often so obtuse as to be useless (especially with templates and contracts in play), and Phobos (the standard library) is practically made of paper cuts. Also, the only notable async support is a fragile mess, and garbage collection is too deeply embedded into both the stdlib and the ecosystem.

(To be fair, D could be vastly improved with better defaults and standard library. That might happen in time, as Walter and the other maintainers have shown interest, but it’s just wishful thinking for now.)

Also, D is an entirely different language from C++, and as such, would require code rewrites in order to bring safety to existing projects. It’s not really comparable to a C++ extension.

Is this going to be re-posted every month?

That was a different community.

Also: https://xkcd.com/1053/

Given how long and widely C++ has been a dominant language, I don’t think anyone can reasonably expect to get rid of all the unsafe code, regardless of approach. There is a lot of it.

However, changing the proposition from “get good at Rust and rewrite these projects from scratch” to “adopt some incremental changes using the existing tooling and skills you already have” would lower the barrier to entry considerably. I think this more practical approach would be likely to reach far more projects.

Cryptocurrencies are not reliably fungible, nor stable, nor widely accepted. They have their uses, but they are not suitable replacements for PayPal and not what OP asked for.

There is no privacy-focused PayPal alternative in the US, in part because US money transfer laws and policies (e.g. Know Your Customer) directly oppose privacy.

However, there are a couple of new projects that might eventually lead to something less bad for privacy than PayPal is:

• GNU Taler, if they ever get any exchanges, and they either figure out how to mitigate the high fees for wire transfers or use some other settlement method when people on different exchanges make small payments. (Their plan to use batch wire transfers won’t help until the exchanges get a lot of adoption and frequent use. Of course, high fees discourage adoption and use, so this might not ever happen.)
• FedNow, if banks ever use it to offer appealing person-to-person payment services instead of just using it for themselves and their business customers.

I don’t know if Element Web/Desktop was affected by the vulnerabilities in the title, but another one (also announced today) is fixed in Element Web/Desktop v1.11.81.

https://github.com/element-hq/element-web/security/advisories/GHSA-3jm3-x98c-r34x

I no longer consider any email app to be okay for privacy if I can’t build it from source code. There are just too many opportunities and incentives for someone to exploit it. That could be the developer, or the maintainer of some obscure code library, or a company that buys one of them out, or an attacker who found a vulnerability. We no longer live in a world where it’s reasonable to think we’ll get privacy from communications software that we can’t inspect.

Thankfully, we also no longer live in a world without options. There are more than a few email apps with nothing to hide. :)