Radicle has plenty of red flags, see https://lemmy.ml/comment/8982169
Radicle has plenty of red flags, see https://lemmy.ml/comment/8982169
I would love a text based ActivityPub client focused on meaningful discussions: threaded view, ability to follow threads or branches, highlight posts based on keywords.
Github is designed to centralize git (as the word "hub" suggests). You can still migrate away code, issues and wikis, but contributors, followers, wiki editors, issue subscribers, visibility in general and github stars are locked in. Discoverability matters to projects trying to attract contributors.
They do now have a verified tick in Flathub to show if a Flatpak is official
Jia Tan liked your comment
Without the traditional distribution workflow what prevents flatpaks to be full of security issues? Unfortunately sandboxing cannot protect the data you put in the application.
This is not a communication problem. Communities are indeed centralized and if an instance is shut down permanently or loses its data all the communities are gone. This is a big design problem of Lemmy.
Edit: it's sometimes possible to rebuild new communities on another instance and recover past messages that have been replicated on other instances (if there were full replicas) but this requires all users and moderators to agree on where to migrate and avoid splits and so on.
Does OrganicMaps have editing abilities?
free people from proprietary gardens, yet FOSS has actually been one of the biggest creators of such gardens
Forgive the nitpick, but FOSS is not creating walled gardens, companies are. (After all, software has no willpower... yet)
Please do now upvote techrights.org - they use hyperbolic tones and produce clickbait.
A speech-to-text / dictation system geared towards writing documentation.
Software licenses cannot solve every problem and AGPL is still the best option.
There are many larger problems related to FOSS including freeloading, right of repair, surveillance, lock-in... and they require social solutions rather than new licenses.
Terminating a support contract, in itself, is not a GPL violation. The restrictions only affects the ability to receive future updates.
Edit: Red Hat indeed claims that no GPL violation is happening, yet they inform their customers that sharing updates leads to contract termination, which clearly breaches the GPL at least in spirit: https://sfconservancy.org/blog/2023/jun/23/rhel-gpl-analysis/
It's in no way "everyone", just a vocal minority.
Here's a summary: https://ploum.net/2023-06-23-how-to-kill-decentralised-networks.html
Then yes there’s EEE danger. Hopefully the Mastodon developers will resist that.
Unfortunately developers can do very little to prevent that. EEE works by first attracting a large userbase into a service and later on prevent them from leaving. It's up to instances admins and users to defederate to prevent EEE.
Element (and other crucial components of the Matrix ecosystem) received many rounds of investments including https://element.io/blog/element-raises-30m-as-matrix-explodes/ (These are investments, not donations.)
I would not be surprised if the usual bait & switch lock-in mechanism happens here as well.
This is debatable. The GPL allow redistribution of a given version of the software without additional restriction. If the user receives that copy knowing in advance that redistribution will lead to retaliatory actions this can be treated as an additional restriction.
Context is important. It's possible that the software is distributed without any warning like that and that the termination of the support contract is done without citing the redistribution of previous versions as a reason. OTOH if the customers could prove that there's widespread knowledge of the retaliatory termination that could be equivalent to a (non-written) restriction that is indeed incompatible with the GPL
That's besides the point. Of course it's always possible to create new communities on new instances, and import posts from various sources, but the original community would be still gone.
If an instance is shut down or becomes unusable for a long time there is no way to automatically migrate users to a new instance. Additionally, there is also no guarantee that all users will move to the same alternative instance. This can also cause unnecessary conflict around which alternative instance becomes the "legitimate" successor.
I am well aware of it. It is an example of the traditional distribution workflow preventing a backdoor from landing into Debian Stable and other security-focused distributions. Of course the backdoor could have been spotted sooner, but also much later, given its sophistication.
In the specific case of xz, "Jia Tan" had to spend years of efforts in gaining trust and then to very carefully conceal the backdoor (and still failed to reach Debian Stable and other distributions). Why so much effort? Because many simpler backdoors or vulnerabilities have been spotted sooner. Also many less popular FOSS projects from unknown or untrusted upstream authors are simply not packaged.
Contrast that with distributing large "blobs", be it containers from docker hub or flatpak, snap etc, or statically linked binaries or pulling dependencies straight from upstream repositories (e.g. npm install): any vulnerability or backdoor can reach end users quickly and potentially stay unnoticed for years, as it happened many times.
There has been various various reports and papers published around the topic, for example https://www.securityweek.com/analysis-4-million-docker-images-shows-half-have-critical-vulnerabilities/
They have to watch hundreds to thousands of packages so having them do security checks for each package is simply not feasible.
That is what we do and yes, it takes effort, but it is still working better than the alternatives. Making attacks difficult and time consuming is good security.
If there is anything to learn from the xz attack is that both package maintainers and end users should be less lenient in accepting blobs of any kind.
Count me in! (Or shall I say: you have my sword?)
How does it compare with Paperwork? https://www.openpaper.work/en/
You can use firejail or other sandoxes with any application packaged in any distribution.
Correct. The whole point is having simple mechanisms at home to turn on and off energy uses depending on pricing and need. Even discharge your batteries into the grid if needed.
Many technologies and other societal changes can create disproportionately negative conditions for the poor. For example not having a phone, not having a car, not having Internet access. Please do not blame the technology. Blame inequality instead.
What you are describing is just a local cache of !lemmy@lemmy.ml on your instance and it works only if it has been populated before the downtime of lemmy.ml. If lemmy.ml never comes back to life nobody can post to !lemmy@lemmy.ml proper. All the communities on in would be dead.
This is not correct. APT always verifies cryptographic signature unless you explicitly disable it. Yet it's very important to understand who is signing packages. What kind of review process did the software go through? What kind of vetting did the package maintainer themselves go through?
If software is signed only by the upstream developer and no 3rd party review is done by a distribution this means trusting a stranger's account on a software forge.
Update: the Debian infrastructure supports checking gpg signatures from upstream developers i.e. on the tarballs published on software forges.
Indeed. If a big instance like lemmy.ml was to be shut down all the communities would be lost. This is simply not sustainable. Why would users put effort building a community if it could be gone at any time?
Thanks!
This is pretty much what already happens, with the main difference that the target group would have a codename or a number. Algorithms don't care.
I did the survey but please would you mind identifying yourself and linking to the research paper when it's ready?