but for the sake of being a successful project to the masses? It’s basically a dead end Road

I think that’s why we should still have requirements against software we run (although as some funnily say, we are free to get a refund), but not pretend that the software is more secure than it is known to be. sad that we need a VPN for security, but it is what it is.

I don’t know how could we get our devs to be more attentive to security.

it is pathetic indeed, but I think much fewer projects admit it than how many should

It should at worst give people a copy of my media if there’s a security issue.

that’s not the worst possibility. the worst possibility is an RCE into your server.

Personally I went out of my way to make this be the case, i have my instance locked into an unprivileged lxc whitelist only on syscalls which took a while to figure out the minimum needed for function but

that’s a pretty exotic setup. Exciting, but for most people learning to manage a VPN is easier

It should at worst give people a copy of my media if there’s a security issue.

that’s not the worst possibility. the worst possibility is an RCE into your server.

Personally I went out of my way to make this be the case, i have my instance locked into an unprivileged lxc whitelist only on syscalls which took a while to figure out the minimum needed for function but

that’s a pretty exotic setup. Exciting, but for most people learning to manage a VPN is easier

but you present your “wide populace” fact without giving sources too

my statement is not that many people are using passkeys today. but that if there comes a time when many people will use passkeys, they will be as careless and convenient as they are with everything else today, accepting any restrictions, because “why would anyone not use Google Passkeys? It’s the most convenient thing!”.

and not only that. I was talking about device locking but that’s only part of the problem. isn’t it that passkey receiving services can identify the client software, and decide they will only accept passkeys from x and y clients?

wait, did Godot enshittify?

what were the questions to which they gave those responses? It’s really not clear. link the source.

element was very buggy a few years ago. the new clients are just now starting to get feature parity, and in my experience calls are still quite unstable, requiring your server to have some specific additional setup (which most public registration instances don’t have), besides that not a lot of clients have implemented yet MatrixRTC calls. even the client list on matrix.org is only showing whether a client supports the former calling system.

so for the layman it’s definitely not production ready yet. and even for new tech literate users some of the things are still challenging to figure out.

but it’s so much easier to grab torches and pitchforks than to read an announcement

except when the wide populace starts accepting it being device locked, and your opinion does not matter anymore to those making the decisions

namely the VC funding and the huge resource hungry clients to me

It’s not the CCTV you want to worry about. The CCTV is overwritten regularly and typically goes nowhere.

yes, it is the CCTV. Because there is no way to verify by yourself that the recordings don’t get transmitted or processed for their contents all the time.

Carrying a smartphone and worrying about CCTV while you post pictures of yourself where LLMs can scrape them is utterly irrational.

that’s a huge assumption. that kind of people don’t usually complain about CCTVs.

username checks out

so it must be a problem with your connector maybe

or with their programming language

But seems like you cannot do it with your own Facebook account.

what causes the limitation? the posts are readable to all registered users

wasn’t there a DB conversion document?

if you are downloading the tools in every pipeline run, you are doing it wrong, wasting resources and time. tools should be baked into a new docker image that you use in the pipeline. another pipeline updates the image on schedule

woodpecker was an older system, it supports github actions workflows too

the debian cve tracker also links to that page, but they have written 7.0-rc7 besides it.

https://security-tracker.debian.org/tracker/CVE-2026-31431

the openwall link has some comments that talk about the delayed patches, Greg KH also commented.

and the patch to the kernel was commited on 1th of April.

are you sure? what I have seen in git patch dates is 11th for the unreleased 7.0, and yesterday for the LTS versions

tbh they could have boasted even less bytes by just having everything in a zlib.decompress()