GNU Guix is a package manager for GNU/Linux systems. It is designed to give users more control over their general-purpose and specialized computing environments, and make these easier to reproduce over time and deploy to one or many devices.
I think it makes sense that publishers are required to update or at least assess games when open security issues come to their attention.
The current state is that you may have 20 games installed and 10 have not been maintained for a long time, and 5 have open security issues that an attacker may use. For example, a game launcher with service installs to program files with admin permission. And suddenly, you have a privilege escalation.
Or a game, when run, pulls in some monitoring, and suddenly exfiltrates data because that service is defunct and was taken over, or hacked.
The necessity is quite clear.
Maybe this will also push us towards more stable software, that changes less, or has less attack or escalation surface. That could significantly reduce maintenance burden - even if it ends up only assessing reported open vulnerabilities not affecting your product (because you don't make use of or open up the vulnerable functionality).
I find this kind of graph a bit misleading/ambiguous. I intuitively want to follow horizontal association between in and out. For example, Recruiter at the bottom splits into three at the bottom.
Not sure if there's a better way to do this. Disconnect in-bar and out-bar with a condensed point/circle to indicate non-conformity?
Concentric AI’s 2025 Data Risk Report found Copilot accessed almost three million confidential records per organization in the first half of this year alone.
Is this about a not-yet-published report?
They don't link to the report they are talking about, but only to the publisher. I can't find a report about Copilot risk.
There's a data risk report, supposedly updated twice a year, but from 2H 2023 (despite the web page being titled 2H 2025), and with no mention of Copilot.
There's also this blog post, which appears to connect their data risk report with Copilot.
The blog post seems a lot more concrete, specific, elaborate, approachable, and actionable than the Techradar post. To me, at least.
Assess and cache your package pulls. Make sure you're not pulling unchanging data on each build. Cache partial builds, or proxy dependency-pulled packages.
I don't think they care about those small movements.
This seems like a response to 1. the state of reality (half(?) of installs are still on 10) and 2. EU criticism and looming regulation/imposed requirements.
On the topic of "let's not have a Sourceforge again",
Sourceforge was great back in the day, and I'm not aware we had good alternatives back then. Sourceforge gave us a well known, trustworthy home for FOSS. You know where to look for FOSS, you can discover FOSS, you can host your own FOSS for free.
Should we have diversified back then? To what? At what cost?
When Sourceforge eventually became problematic, by chance, most active projects switched away. I did too. Thanks to FOSS and control of your own projects, that's possible.
Today, we have a number of alternatives. Not more than a few, if you count established hosted platforms, more if you count self-hosted and self-hosting.
I made my point about discoverability etc in my original comment. Trustworthiness of the hoster/provider is another. Decentralization to individuals has risks as well, including disappearance (my first Lemmy instance feddit.de, which was big, broke and disappeared), lack of security updates, or introduction of bugs and security issues through customizations or hosting setup. There's a middle ground with bigger platforms, of course.
When Sourceforge became bad, I migrated away. If and when GitHub becomes bad, it'll be fairly simple to move away from that as well. Until then, I find it to have the best UI/UX (although I have some criticisms) and offerings, as well as closeness of FOSS projects and community and other projects as well (positive network effect).
I certainly don't want to send email patches because I value the centralized nature of a big platform and clear, established workflows and UI.
Disconnected decentralization adding barriers is a shit idea.
Huge platforms like Github have some risk and concerns involved, but as long as it does well, and the network effect of a platform is a net positive, I don't think adding decentralization barriers and differentiation barriers and disconnects is a good idea.
There's reasons why people don't switch besides network effect and inertia. I certainly haven't ever felt like sourcehut were approachable.
One candidate we placed in the past told us they wanted $90k. We advised them not to say that number, because it'd get them filtered out. They ended up getting hired for close to 200.
Other post about this video (3h earlier) (shortened URL, hence no cross-links)