335
KDE is actively proposing a Pro-AI contribution policy, with most rejecting any suggestions for AI use to be disclosed, or any consideration for environmental concerns (invent.kde.org)
submitted 1 month ago by to c/linux@programming.dev
151 comments fedilink hide all child comments
😭 2
 

Direct link to the LLM Policy Discussion: https://invent.kde.org/plasma/plasma-workspace/-/work_items/187

Example of KDE dev rejecting environmental consideration:

Example of KDE devs not wanting to require LLM use be disclosed.

And all of this is coming right after the debacle with an AI slop project being allowed to give a presentation at Akademy, and the person asking how this was allowed being blocked by KDE:

https://lemmy.nz/post/42029517

as well as the discussion thread bringing up legitimate concerns about AI usage being closed:

https://discuss.kde.org/t/sorry-to-bring-up-a-contentious-topic-kde-ai-llm-policy/46333/164

As someone who genuinely loves KDE, and has even donated to the project multiple times, I sadly have to accept that the majority of KDE have hopped onto the Pro-AI train, and they will not be dissuaded otherwise.

you are viewing a single comment's thread
view the rest of the comments
[–] 6 points 1 month ago* (last edited 1 month ago) (8 children)

I love KDE (as a DE), but now I hate KDE (as a community).

Is there any fork (whether it's an stablished one or it's an emerging one) that outright bans AI, or that at least doesn't explicitly embrace it?

  • permalink
  • fedilink
  • source
  • hideshow 8 child comments
    •
  • [–] 6 points 1 month ago (7 children)

    KDE is huge, you can't just fork all of it (of course technically you could, but it is not much use). You maybe could fork individual projects, a bit like https://vim-classic.org/

    I was thinking of having some kind of online list for packages without AI stuff. Of course a 100% slop free desktop installation is probably impossible nowadays, it would still be interesting to see how far one can go.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 7 child comments
    •
  • [–] 3 points 1 month ago* (last edited 1 month ago) (3 children)

    Such a list already exists!

    Edit: i read the comment wrong, this is kind of the opposite list lmao. But it's still useful so imma leave the comment up

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 5 points 1 month ago* (last edited 1 month ago) (2 children)

    There's also https://noailist.org/, which is based on projects (not just OSS) committing to not using AI. That's probably also the only viable approach, if you want a list of projects without AI stuff, since projects can easily be using AI without it being visible to third parties inspecting the output of the projects

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 1 month ago (2 children)

    Yeah, the point is that I need something that has many features only available in KDE.

    Would it work if it's done from a previous, presumably untainted commit? I know it's possible that I'm being a bit ingenuous, but I still think that doing something is better that doing anything β€” just as there are explicitly anti-AI forks of other complex projects such as Firefox (both mobile [IronFox] and desktop [Konform], and both mostly untainted), and even a reimplementation of Linux in Rust (HyperOS, this one totally untainted).

    If not, I have some quite good architectural ideas for a new DE, because other big DEs are or ambiguous about AI (for example, Cinnamon, MATE, GNOME or COSMIC, Hyprland), or are not as extensible as KDE (COSMIC, MATE, Cinnamon, LXQt).

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 1 month ago (1 child)

    Would it work if it’s done from a previous, presumably untainted commit?

    Theoretically yes, but at the moment I have more than 150 KDE packages installed; you would need to do this for each one and then make sure that they actually work together in this specific combination. Then, for each package you would need to check if any security bugfixes exist upstream that don't exist in your fork and backport these.

    I would say that is the bare minimum; you probably also want any bugfixes that are implemented upstream.

    I guess with a team of a few people this would be doable, at least for some time; sooner or later some dependency (e.g. systemd) will be updated in such a way that your fork is no longer compatible and then you will either have to integrate the slop code from upstream to make it work, or do that on your own.

    By the way, https://en.wikipedia.org/wiki/Trinity_Desktop_Environment is a fork of KDE 3, but that has no support for e.g. dark mode.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 1 month ago

    By the way, https://en.wikipedia.org/wiki/Trinity_Desktop_Environment is a fork of KDE 3, but that has no support for e.g. dark mode.

    Oof, I didn't remember that one existed, and has even better extendability than KDE (and tabbing support, which I love), but yeah, there are some problems as that one.

    I think I'll try to support them in any way I can, and to contribute with anything I can.

    I know about programming and computer sciences (I'm studying that), although I don't know anything about actual coding, and I have some big-ish amount of architectural ideas (although I don't know how good these are).

    I'm also a music producer and sound designer.

    I hope I can make at least a bit of difference.

  • permalink
  • fedilink
  • source
  • parent