How would a “built-in protection against centralization” even work?
IMHO, you can only provide tools. You can’t prevent people from being stupid and not using them. That’s also why by now, e.g. the EU tries to solve such problems through regulation.
How would a “built-in protection against centralization” even work?
IMHO, you can only provide tools. You can’t prevent people from being stupid and not using them. That’s also why by now, e.g. the EU tries to solve such problems through regulation.


If you don’t plan to host free software, you might not care.
For free software, you might consider GNU’s criteria for ethical repositories, under which this would already make the hosting unacceptable due to a violation of C2 (see https://www.gnu.org/software/repo-criteria.en.html). Even if you don’t adhere to GNU’s definition, you might then ask yourself why your definition of free software allows for more discrimination and whether that is justified.


Considering the increasing importance of AcivityPub-driven interaction, an interesting choice might be Codeberg as its underlying codebase Forgejo has an initiative heading for federation (see https://lemmy.ml/comment/396978)
Exciting! Might also indicate that @Codeberg@social.anoxinon.de could be a good choice for those willing to switch their #git hosting due to platform lock-in concerns because it’s likely that it would benefit from that to-be-implemented #federation support.
Definitely. But I guess the proprietary players will only take part when they are either forced to do so by regulation, or when 80% of the market already federates. So the question is probably which of the open source platforms has the biggest promise for making it happen.
Btw, a similar effort for Gitlab: https://gitlab.com/gitlab-org/gitlab/-/issues/30672
Federation and task/responsibility distribution would be exciting to solve the storage dimension issue.
Couldn’t someone train a model on their university’s computing cluster, and share it? This would boost independent research on these things for sure.


On a more positive note: Saxony was the only federal state in Germany which, during times of more strict pandemic-related rules, allowed tracking exposure using the government-funded open source software instead of some app used by the other federal states based on stolen code whose only unique selling point was being advertised by a famous rapper…


And at the same time, Saxon universities coerce students into proprietary solutions, hiding behind university autonomy when members of the parliament criticize this.


This calls for some quantitative research: What is the critical mass of open access publications in some area from which it becomes feasible to fully boycott closed access research?
Or maybe we don’t have the suitable tools for that task: Do we need a copyleft (or rather “citeleft”?) mechanism for scientific publications?
The headline is misleading, as the article merely covers the decision of the Data Protection Commissioner of Hesse (one of Germany’s 16 federal states). Many other federal states have a similar tendency by now, but in detail it can be very different, and in practise, the Data Protection Commissioners can be very patient when it comes to giving schools additional time to switch to other solutions.


It would be interesting to find something within real-world behaviour of crows that requires this cognitive ability.
Big tech companies route loads of data through their data centers that could either be processed on the end users’ devices, or that aren’t needed at all for the services that help the end users. A comparison between the climate impact of all the big tech data center processing that is done for the sole purpose of the big tech companies and other factors relevant to climate would be both interesting and meaningful.
Edit: Funny to see downvoting without making a point. Regarding the latter mentioned source of serviceless resource wasting of big tech, see https://www.inkandswitch.com/slow-software/ (under “user-hostile work”). Regarding the former one, think about why your average smartphone keyboard implementation needs to phone home to the tech company’s data center, while there are implementations that work right on the device. Removing all this stuff could most likely greatly reduce the resource usage of today’s end user devices, and does not provide any useful service to the end users.


I didn’t mean running on the top of some distro, but “native” compatibility to existing packaging. Snap/Flatpack/Nix etc. can also more or less run on the top of arbitrary distros, but I think more acceptance can be achieved if the packages are (at least source-level) compatible to something existing and widespread and run as first-class citizens there.
Not saying that Guix isn’t innovative, useful or joyful, though. Just thinking that it might not work as an alternative for Debian in every case.
Will look into PureOS and Trisquel. Are their releases roughly corresponding to some releases of Debian or Ubuntu, respectively (e.g. package-version-wise)?


This might create a bias towards large vendors with huge human resources to throw at maintenance. But it should be illegal to sell devices and hinder third parties to fix bugs and develop security upgrades, for example through closed software platforms, drivers and interfaces.


Looks interesting, but to what extent is it compatible to other distributions, allowing for package-related or other reuse?
As much as an Ubuntu fork that removes that semi-proprietary snap stuff would be in a good position to build a user base quickly, so would now a Debian fork that keeps the on-device code licenses clean.


I understand the point, but I was thinking that there were already Linux distributions fitting into that niche…


Boycotting efforts against digital souvereignty alone is not enough. But the efforts to build a regulative solution won’t work without enough people willing to continue the boycott.
The point is that IRC is normally used in a way that leaves more to the client. ActivityPub services usually expect that users put much more trust in the instances. It might be worth thinking about that.