By “solar power in operation” (in GW) i think they mean maximum output capacity rather than actual production, since these numbers add up to 923 GW while wikipedia says in 2024 there was 2.13 petawatt-hours (243 GW on average) actually produced by solar.

As more data becomes available

Then we can start doing more with it

And as we do more with it

That that creates more data

As I wrote in the thread about this last month on !linux@lemmy.ml:

I wonder how much work is entailed in transforming Fedora in to a distro that meets some definition of the word “Sovereign” 🤔

Personally I wouldn’t want to make a project like this be dependent on the whims of a US defense contractor like RedHat/IBM, especially after what happened with CentOS.

and, re: “what do you mean ‘redhat is a defense contractor’?!”: here are some links.

(source)

if that is the case I choose upper-left of the political compass for you (:

i’m curious, where do you place yourself on that compass? if you’ve got 20 minutes I highly recommend this video about it.

and here i does it for free 🤡

What is a U.S.-sanctioned place? Why does the U.S. government think this is a bad thing?

https://en.wikipedia.org/wiki/United_States_government_sanctions

🎉 sometimes US sanctions actually do lead to positive outcomes :)

I often see Rust mentioned at the same time as MIT-type licenses. Is it just a cultural thing that people who write Rust dislike Libre licenses?

The word “libre” in the context of licensing exists to clarify the ambiguity of the word “free”, to emphasize that it means “free as in freedom” rather than “free as in beer” (aka no cost, or gratis) as the FSF explains here.

The MIT license is a “libre” license, because it does meet the Free Software Definition.

I think the word you are looking for here is copyleft: the MIT license is a permissive license, meaning it is not a copyleft license.

I don’t know enough about the Rust community to say why, but from a distance my impression is that yes they do appear to have a cultural preference for permissive licenses.

!meshtastic@mander.xyz is the more active of the two lemmy communities about it

here are some related issues:

• https://github.com/LemmyNet/lemmy/issues/833 Option to disable notifications for a specific post - this was closed in favor of #1883
• https://github.com/LemmyNet/lemmy/issues/1883 Add settings to disable comment, mention, and private message notifications - here @dessalines@lemmy.ml commented “We already have one for post notifs” but i don’t see where that exists 🤔
• https://github.com/LemmyNet/lemmy/issues/3042 Add a “disable inbox replies” option of posts and comments

Nice post, but your title is misleading: the blog post is actually titled “Supply Chain Attacks on Linux distributions - Overview” - the word “attacks” as used here is a synonym for “vulnerabilities”. It is not completely clear from their title if this is going to be a post about vulnerabilities being discovered, or about them actually being exploited maliciously, but the latter is at least not strongly implied.

This lemmy post however is titled (currently, hopefully OP will retitle it after this comment) “Supply Chain Attack found in Fedora’s Pagure and openSUSE’s Open Build Service”. edit: @OP thanks for changing the title!

Adding the word “found” (and making “Attack” singular) changes the meaning: this title strongly implies that a malicious party has actually been detected performing a supply chain attack for real - which is not what this post is saying at all. (It does actually discuss some previous real-world attacks first, but it is not about finding those; the new findings in this post are vulnerabilities which were never attacked for real.)

I recommend using the original post title (minus its “Overview” suffix) or keeping your more verbose title but changing the word “Attack” to “Vulnerabilities” to make it clearer.

TLDR: These security researchers went looking for supply chain vulnerabilities, and found several bugs in two different systems. After responsibly disclosing them, they did these (very nice and accessible, btw - i recommend reading them) writeups about two of the bugs. The two they wrote up are similar in that they both involve going from being able to inject command line arguments, to being able to write to a file, to being able to execute arbitrary code (in a context which would allow attackers to perform supply chain attacks on any software distributed via the targeted infrastructure).

it’s 2025 now but otherwise yeah

Fuck this project, but… their source code can be free and open source even if they distribute binaries which aren’t. (Which they can do if they own the copyright, and/or if it is under a permissive non-copyleft FOSS license.)

And if the source code is actually FOSS, and many people actually want to use it, someone else will distribute FOSS binaries without this stupid EULA. So, this BS is still much better than a non-FOSS license like FUTO’s.

I immediately knew this was going to be from Microsoft users, and yeah… of course, it is.

Binaries distributed under this EULA do not meet the free software definition or open source definition.

However, unlike most attempts to dilute the concept of open source, since the EULA is explicitly scoped to binaries and says it is meant to be applied to projects with source code that is released under an OSI-approved license, I think the source code of projects using this do still meet the open source definition (as long as the code is actually under such a license). Anyone/everyone should still be free to fork any project using this, and to distribute free binaries which are not under this EULA.

This EULA obviously cannot be applied to projects using a copyleft license, unless all contributors to it have dual-licensed their contributions to allow (at least) the entity that is distributing non-free binaries under this EULA to do so.

I think it is extremely short-sighted to tell non-paying “consumers” of an open source project that their bug reports are not welcome. People who pay for support obviously get to heavily influence which bugs get priority, but to tell non-paying users that they shouldn’t even report bugs is implicitly communicating that 2nd and 3rd party collaboration on fixing bugs is not expected or desired.

A lot of Microsoft-oriented developers still don’t understand the free software movement, and have been trying to twist it into something they can comprehend since it started four decades ago. This is the latest iteration of that; at least this time they aren’t suggesting that people license their source code under non-free licenses.

as i said, it “is about to be released”.

or, one could also say that the the 3.0.0 source code has been released, but the official binaries haven’t been yet :)

edit: i see https://flathub.org/apps/org.gimp.GIMP has 3.0.0 now, and from https://testing.gimp.org/downloads/ i see that https://download.gimp.org/gimp/v3.0/linux/GIMP-3.0.0-x86_64.AppImage is also there. presumably https://www.gimp.org/downloads/ will be updated very soon.

Could anybody in short explain, what I have to understand from “it’s tagged”?

Git is the most popular version control system, which lets developers track changes to software source code. A “tag” applies a name (or version number) to a specific point in the history.

The commit shows that there was a longer with 3.0.0 tag before and now its just 3.0.0

The link goes to a commit which is tagged GIMP_3_0_0, and shows the change made in this commit. This commit happens to change the version line in a file called meson.build - this file configures Meson, which is used to build GIMP. The version is being changed from 3.0.0-RC3+git to 3.0.0. The string “RC3” in the previous version number is short for “release candidate 3”, and “git” here means that there were additional changes since “release candidate 3” was released.

What does that tell us? :D

So far the news and downloads pages still haven’t been updated, but the version being changed to 3.0.0 and this commit being tagged tells us that GIMP 3.0.0 is about to be released: official binaries and an announcement about it can be expected to appear very soon.

The tag means no more changes will be included in 3.0.0; if some show-stopping bug were discovered now, the version number would be incremented to 3.0.1 rather than to include a fix in 3.0.0. (Technically, a tag can be updated/replaced, but by convention it is not.)