Isn’t Codeberg self-hostable?
Worst pirate you never heard of.
That’s why I have disabeled it for vim. Infact I disabled mouse support alltogether.
still using apt? try winget instead!
Usee those lips for something worth while and suck my dick instead of yapping
Then make a better alternative. You obviously “haven’t drunk the koolaid”.
“Write the code I want, free of charge, in your own time. I demand it. Recognition for your efforts? Nah, I won’t even know of you, but if anything ever goes wrong, I will find your repo and complain about how Microslop did it better with hundreds of engineers!”
That’s what you sound like. If you don’t contribute code, money, documentation, detailed bug reports, community guidance, moderating, etc., then IMO, that opinion is worthless.
Devs aren’t your code monkeys, shackled to computers to do your bidding. A lot of thankless, unpaid time went into writing most of opensource code out there. To sit there and demand options is, to me, appallingly ignorant behaviour.
I contributed money, translations and properly filed bug reports to various open-source projects. But I don’t think people who don’t shouldn’t speak out. Being unhappy with a certain change signals the direction for the devs to make their code better.
Besides, KDE is no hobby project; it’s a nonprofit with full-time workers on a wage. Nonprofits are always kept to a high standard of accountability, and are resilient enough to turn negative feedback into directions for growth. It is in part this feedback that led it to develop the best DE out there.
Exactly
As someone who relies on systemd, but wants to have alternatives:
While it is good othat other login managers will still be able to start Plasma, making the default new login manager reliant on systemd is bad. It means that non-standard installations of KDE will now require more manual labor to make it work just right. And while installing sddm is not big of a hassle, this sets a precedent that can later be expanded, making it a death by a thousand cuts for everything that dares not use systemd in its operation.
Maybe you already figured this out but I think it’s a common gotcha:
Wireguard AllowedIPs means just that: IPs that are allowed to be routed over the tunnel.
There is nothing that says that you need to have 1-to-1 mapping between that and actual routes. Most of the time it’s what you want but there are situations where you want it different.
wg-quick additionally adds corresponding ip routes as a convenience. systemd-networkd did at some point but don’t anymore. I’m not sure what NetworkManager does there these days.
Anyway, it’s an understandable source of confusion and the tools don’t always help.
You found the right workaround.
The Arch Wiki calls this “Loop routing,” where NetworkManager attempts to route traffic to the WireGuard peer’s endpoint through the tunnel itself, creating a routing loop. This occurs because the endpoint IP gets matched by the AllowedIPs ranges, causing the kernel to send handshakes over the tunnel interface instead of the physical interface. Excluding the peer endpoint from AllowedIPs is the standard fix.
Here’s the ArchWiki link (for future readers mostly, you already got it :P): https://wiki.archlinux.org/title/WireGuard#Loop_routing
Juicy list of features, very excited to update
It was but a mere example
Fair enough.
It could help, but it’s not a problem that any one solution is the solution. There’s going to be some combination of solutions to actually solve it.
Also reasonable
Not really, I might have a lot of accounts, but it’s still only 1 per instance so it’s not really inflating the numbers. Besides most go by monthly active users for gauging the Threadiverse health which because of my pattern I might not even make up 1 MAU lol
Reasonable again.
I don’t just make them, I do my best to actively contribute to them, like I said I also post “organically sourced” content and not just crossposts for this very reason.
I missed that, if that’s whats happening i retract my implication.
Um I’m not sure how that would be a user education error? I’m talking about someone maliciously making an imposter account and posting heinous crap “in their name” But there is currently no technical solution on the Threadiverse afaik for it
I think imposter account is a misnomer, two accounts with the same name on different instances are distinct entities afaik,
like mike@gmail.com isn’t the same as mike@outlook.com.
if you look at a post and it’s written by “mike” and you don’t look at the instance it’s from you’re only getting half of the information you need.
Solutions for this type of problem exist already (PGP keys etc), they just aren’t very practical for regular people.
The “could be better solved in a different manner.” part was mostly about how the underlying software for the instances might be changed to allow for some of these existing solutions to be integrated more seamlessly.
Or something entirely new, who knows.
Nah crossposts are a solution for a different problem, 4 is for when an instance hasn’t federated with another instances remote comm yet and is therefore unknown to the instance
For example, I made this post to my comm at !gunnerkrigg@lemmy.cafe today from this toast.ooo instance I’m on rn
But toast.ooo never federated with that comm so as far as this instance knew !gunnerkrigg@lemmy.cafe didn’t exist until I manually went to the comm by URL (toast.ooo/c/gunnerkrigg@lemmy.cafe) and subbed to it
Until then nobody on this instance would have been seeing posts from that comm in their c/all/new/whatever feed, even if a post went “viral”. But now they will and for every other comm I sub to as I go
I didn’t know this is how it worked, makes sense in that context.