41
Proposed KDE LLM guidelines (invent.kde.org)
submitted 6 days ago by to c/techtakes@awful.systems
32 comments fedilink hide all child comments
 

Putting shit in your food is OK as long as it is only a little bit of shit and you can't immediately taste it.

you are viewing a single comment's thread
view the rest of the comments
[–] 7 points 4 days ago (10 children)

GNOME, the most boring DE is just about the only refuge at this point from LLM garbage…They aren't particularly great for daily driving because of its usability hell over there. If I have to. I might eat a bullet and just use GNOME since they are against LLMs as a rule. If their contribution policy leans towards allowing LLM-assisted to outright vibe-coded contributions, KDE is cooked as fuck. Given that Valve and a lot of others use it as a default…It will be getting pretty messy over there. At some point, I will just have to make my own window manager and fuck off the pre-made shit, at least me learning Python and C will be put to good use that way. ROFL

  • permalink
  • fedilink
  • source
  • hideshow 10 child comments
    •
  • [–] 5 points 3 days ago (2 children)

    unfortunately even gnome is not really against llms... some apps sure, and core libraries like libadwaita have taken a stance, but both gtk and mutter allow llm "contributions"

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 3 days ago

    Might as well just stick with my plan of fucking off into my own WM and not giving a single shit about any of the standard DEs then. They can rot if they'd like to swallow shit, I hope they choke.

  • permalink
  • fedilink
  • source
  • parent
  • [–] [S] 4 points 4 days ago (6 children)

    I was thinking about using swaywm but I don't want to make the switch until their LLM ticket is resolved.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 3 points 4 days ago (4 children)

    I was using SwayWM but there are some issues with background shit (at least on the system I was using it on). It was using an insane amount of ram and taxing my CPU unnecessarily. If I do make my own WM, I can optimize and control more aspects of how it performs.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] [S] 3 points 4 days ago* (3 children)

    Maybe take a look at River as a starting point. I think it has an interesting concept and it's strictly slop free.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 2 points 4 days ago (2 children)

    People have been pointing me in River's direction...Zig, that is the main issue. I am looking for things based on C at the very least. I think using SwayWM as a starting inspiration for some elements is where I will be starting. As I have to be able to read the code, I have the most experience reading C, Zig just looks too weird. If I have any hope to translate most of it into Python. ROFL

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] [S] 3 points 4 days ago (1 child)

    The thing that I like about River is that it does the compositing while you can build your own window manager on top of it in whatever language you like. There are already a few examples to choose from some of them in C.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 3 points 4 days ago

    Yeah, I was looking deeper into it as initially River seemed to be going through a zig rewrite but I looked a bit more into it without editing my comment and found there is more. When I got to the stage when my knowledge matched the ability to write my own WM, I was going to use wlroots as a base to build off of. It seems like I have a few paths open to me. Might take awhile for me to get the idea fully off the ground though, as I need to master Python and get back into C before realizing the idea. It will come in stages.

  • permalink
  • fedilink
  • source
  • parent