The squawker seems interesting to me. Unfortunately it’s only available on android and there are some issues probably out of their reach. But since I use it for something basic (literally seeing images of some profiles I follow), it serves me well
I did it with blob storage, ended up being much cleaner and cheaper. You’ll need to toy with it a bit, but from scratch will be a lot easier than the migration I had to do. You’ll easily eat up 100+GB in pictures, which on the cloud on a VM’s drive that’s a fair chunk of money. Object storage is pennies.
Yup Yup! I’ve got it uploading objects. It seems to be an issue with fetching them. The hash is either mismatched or it’s not correctly trying to grab from the sled repo. So, I get a 500 error in store response. Not really sure how to fix it.
This community is full of people who simply “don’t like certain things”. They may say “it’s overkill” disregarding the fact that it solves their use case perfectly. Or it could be written in a language they don’t like. Or maybe they heard somebody else complain about it on a forum once and now think it’s bad.
I think flatpaks are good. The performance penalty for containerized software can be felt much more when you’re not using a good CPU. So containers do not “solve” my use case.
Yeah, it’s also the same group of people who are always complaining about how much RAM a desktop environment or app uses, that app being whichever one they are using right now.
This looks interesting, but I don’t understand what it’s for. I read through the readme, but came out none the wiser. What exactly is a compose sequence?
A compose key (sometimes called multi key) is a key on a computer keyboard that indicates that the following (usually 2 or more) keystrokes trigger the insertion of an alternate character, typically a precomposed character or a symbol.
It’s a method to combine several characters on your keyboard and use it to create a special character which is not on the keyboard. For example “ and e produces ë. This tool allows you to configure those combinations.
But thanks for the feedback. I’ll update the readme to add some more context.
Just to get it out there… I checked this out about a year ago. It’s not completely open source. The project consists of many executables and “pre complied dependencies” that don’t appear to share matching checksums which may indicate modifications of some sort. Looks like a great tool, but I’m extremely skeptical of what’s going on under the hood.
Hopefully they do truly open source it and prove me wrong, I’d love to give it a try some day.
Those didn’t completely break federation, they just had some issues with a few services besides lemmy. They’re addressed now, but federation compatibility will always be an ongoing task as new services get added and existing ones change their activitypub responses.
As far as I’m aware the most widely-accepted standard for responsible disclosure is 90 days. This is a little different, since that’s normally between businesses and includes the time needed to develop a solution; it’s not typically aimed at federated or self-hosted applications rolling out an already-created patch. On the one hand, granting them that extra time to upgrade seems reasonable. On the other, wouldn’t anyone wanting to exploit a vulnerability be able to reverse-engineer it pretty easily by reading the git history?
The 90 days disclosure you’re referencing, which I believe is primarily popularized by Google’s Project Zero process, is the time from when someone discovers and reports a vulnerability to the time it will be published by the reporter if there is no disclosure by the vendor by then.
The disclosure by the vendor to their users (people running Lemmy instances in this case) is a completely separate topic, and, depending on the context, tends to happen quite differently from vendor to vendor.
As an example, GitLab publishes security advisories the day the fixed version is released, e.g. …gitlab.com/…/critical-security-release-gitlab-16….
Some vendors will choose to release a new version, wait a few weeks or so, then publish a security advisory about issues addressed in the previous release. One company I’ve frequently seen this with is Atlassian. This is also what happened with Lemmy in this case.
As Lemmy is an open source project, anyone could go and review all commits for potential security impact and to determine whether something may be exploitable. This would similarly apply to any other open source project, regardless of whether the commit is pushed some time between releases or just before a release. If someone is determined enough and spends time on this they’ll be able to find vulnerabilities in various projects before an advisory is published.
The “responsible” alternative for this would have been to publish an advisory at the time it was previously privately disclosed to admins of larger instances, which was right around the christmas holidays, when many people would already be preoccupied with other things in their life.
The only privacy setting I can encourage on any social media site is don’t share private stuff about yourself and never link to your account from other accounts
That is part of the problem though. Proper privacy allows you to express what you want to, without self censorship. The issue is not: don’t speak about x, but rather: speak about it and feel comfortable that you can do it in a safe environment. I fully agree with the account linking though
github.com
Hot