Gentoo */* ~amd64 isn’t unstable. If I have to use 5 year old packages with bugs long fixed, then I am getting unstable

No, they won’t, but they may shoot you.

But their models can not be used as flexible as an LLM, they are purpose made

They have, but no LLM as far as I am aware of.

Oh, someone said something against Firefox.

As someone who donated regularly to the Mozilla foundation: adding AI in a browser is a stupid idea, always will be and alone the fact that Firefox spends time and resources in this feature means, they have to earn that money again.

I will not donate anymore, as long as they develop WI features for Firefox.

Vote this and this comment down as much as you like but fact is, that money must come from somewhere, and the biggest source of income is still selling Google the default search engine spot and outer questionable sources.

This is not sustainable and a bad day for user choice.

Moved from KDE to hyperland, while keeping some of the ecosystem, like KDE PIM, Dolphins, Okular and the other standard apps.

Best decision for my daily work I made in a long time

The KDE PIM Stack is what I use for it.

It does not depend on KDE/Plasma/KWin DM, and should offer what you are looking for

So, you don’t do backups of /etc? Or parts of it?

I have those tars dir ssh, pam, and portage for Gentoo systems. Quickset way to set stuff up.

And before you start whining about ansible or puppet or what, I need those maybe 3-4 times a year to set up a temporary hardened system.

But may, just maybe, don’t assume everyone is a fucking moron or has no idea.

Edit Or just read what op did, I think that is pretty much the same

I am running a zfs raidz1-0 pool on 3 consumer nvme in my workstation, doing crazy stuff on it.

Ran zfs under proxmox with enterprise nvme and had the same issue.

It is proxmox, not zfs

I assumed something like this. That’s a perfectly valid usecase for a tar extracted to /.

But I love it how people always jump to the assumption that the one on the other end is the stupid one

Safe you all the click. Author claims ai is getting better at writing code and we should think about what we want not how we want it.

Friendly reminder LLMs are not good a writing software. They can only put pieces together that may make sense.

Want proof? Ask it to write some valid C++26 without raw pointers, using modules and reflection.

Not sure if you referring to your post as “could as well be an onion article” but if not , you should maybe go out, touch some grass and then learn to differentiate fake news from facts.

And polymorphism is the only way you could expose those composite Interfaces as bindings on C API based languages. And polymorphism is part of OOP.

If we take the text book definition of OOP, then the kernel is OOP …

dedicated to hosting open documentation

I know this project, and if they publish protocol documentation, I will use it. What is your point?

Other stuffis not part of OpenRGB and never will be. Maybe you should have a loook at the project yourself, mainly read the contribution document.

What is your issue? Avoiding fragmentation? Yeah me to.

Currently,I do want to control my mouse, I need a different software that collides work OpenRGB.

This is not fixable by trying to force stuff into OpenRGB the maintainer clearly does not want (he said so).

After we have a working lib, with at least feature parity, I will try to convince the current maintainer of OpenRGB to outsource the device handling, and focus on the features he wants to build.

EDIT and I don’t want to compete with OpenRGB, I want to focus the currently fragmented world of Linux peripheral development in a singular place, so every tool can use it. Ad a library, not a GUI application that just is another project that will die because it gets unmaintanable.

So, please, have a good look at the contribution documentation and the bug tracker. Look for yourself, or try to introduce macro support or other stuff into this project. I have done so in the past.

And to be clear: If the author and maintainer says he don’t want to have this feature, I completely understand.

This will not be a fork of OpenRGB. While I plan to take a huge chunk of it (the reversed generiert device protocols) the library itself, is all written from scratch.

And, as mentioned, OpenRGB has issues. Besides the listed, technical, issues it has also design and maintenance issues:

While OpenRGB heavily depends on Qt, and is written in C++, ur is full of plain C constructs. This is intentional, have a look at the README.md. raw pointer juggling, lifetime issues (therefore, segfaults) and most importantly:

Making it a dependency would not aolfe any of the feature issues. A device, provided by OpenRGB, still has no support for macros, OpenRGB does all the device communication, so no way to add it.

Steam Input is a framework to abstract controllers and their inputs.

This should implement the vendor protocols for RGB control, macro settings, DPI and more.

May I propose to call those mf Sturmabteilung/SA?

They are no secret police, they are paramilitary brown shirts. Fucking literally.

Thanks, a german

That looks like a typical dryer from “Nicht Nachmachen” (a German comedy and science education program, it’s ob YouTube, have fun)

This! Disable sshd sock, maybe rebuild initramfs.

And, the “kernel command line” is also used by the initramfs for fucks sake …

I feel you. I lost my dad 3 weeks ago.

I always wanted to do some more woodworking, so that is what I did the last weeks in nearly every free minute. Dad would have loved the results, most of it I learned from him. And creating something, that helps. A lot.

This works for me, you will have to find that will work for you.

Be strong. And that means: strong enough to deal with you feelings and grief, not pushing it away or burrowing it