[-] vapeloki@lemmy.world 2 points 2 days ago

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

[-] vapeloki@lemmy.world 1 points 4 days ago* (last edited 4 days ago)

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.

15
submitted 2 weeks ago by vapeloki@lemmy.world to c/linux@lemmy.ml

cross-posted from: https://lemmy.world/post/42787520

Most of us have some blinking, light-emitting, colorful devices attached to our potatoes - or whatever the minimum specs for Linux are these days, haven't checked in a while.

And most of us use OpenRGB to control them. But I fear this single project has some major, fundamental issues. As with many projects, it grew very fast and very big.

It has over 200 supported devices today, and the list keeps growing.

But it wasn't designed to grow this fast or support such a variety of devices.

This has led to several issues:

Not all features can be implemented for all devices:

For example, devices with different available effects per zone aren't supported by design. You may have noticed that sidebar LEDs on some keyboards aren't controllable via OpenRGB.

No support for macros, DPI settings, and more:

It was always about RGB. This isn't an issue per se - it's the scope of the software. But:

Cannot coexist with macro/mouse controlling software:

OpenRGB needs to open the HIDRAW device to control it, and this is an exclusive operation. So no other software can hook those devices at the same time.

Growing backlog:

Device-support requests keep piling up, new devices wait a long time to be accepted - the usual open-source maintenance challenges.

My Idea

Let's create a unified device abstraction library. The core part should just offer a C++ library with all the device abstraction logic in it. This library can then be consumed by a variety of software:

  • OpenRGB could use the RGB part of it, focusing on orchestration and advanced features
  • Python bindings for scripting your setup
  • Hyprland integrations
  • Custom CLI tools
  • Whatever the community builds

Therefore, if you're a developer who knows your way around modern C++ features (or wants to learn), here's my project pitch:

What this could be:

  • Modernized device code (C++23, memory safety, proper abstractions)
  • Support for ALL peripheral features (RGB, macros, DPI, profiles, etc.)
  • Clean API for other developers to build on
  • Reduced fragmentation - community maintains ONE device library instead of competing implementations

Making this real would need:

  • C++ developers , as one developer is no developer (and i have other hobbies!)
  • People who've worked with USB/HID protocols on Windows and other Non-Linux platforms!
  • Anyone frustrated with current Linux peripheral tools and willing to help fix it
  • Design feedback and testing

To kickstart this:

We can fork OpenRGB's existing device implementations (GPL-licensed) as a foundation. I have at least two devices here that offer on-device macro functionality, key remapping, and more, so I can create the basic abstractions for those features.

Thoughts?

9

Most of us have some blinking, light-emitting, colorful devices attached to our potatoes - or whatever the minimum specs for Linux are these days, haven't checked in a while.

And most of us use OpenRGB to control them. But I fear this single project has some major, fundamental issues. As with many projects, it grew very fast and very big.

It has over 200 supported devices today, and the list keeps growing.

But it wasn't designed to grow this fast or support such a variety of devices.

This has led to several issues:

Not all features can be implemented for all devices:

For example, devices with different available effects per zone aren't supported by design. You may have noticed that sidebar LEDs on some keyboards aren't controllable via OpenRGB.

No support for macros, DPI settings, and more:

It was always about RGB. This isn't an issue per se - it's the scope of the software. But:

Cannot coexist with macro/mouse controlling software:

OpenRGB needs to open the HIDRAW device to control it, and this is an exclusive operation. So no other software can hook those devices at the same time.

Growing backlog:

Device-support requests keep piling up, new devices wait a long time to be accepted - the usual open-source maintenance challenges.

My Idea

Let's create a unified device abstraction library. The core part should just offer a C++ library with all the device abstraction logic in it. This library can then be consumed by a variety of software:

  • OpenRGB could use the RGB part of it, focusing on orchestration and advanced features
  • Python bindings for scripting your setup
  • Hyprland integrations
  • Custom CLI tools
  • Whatever the community builds

Therefore, if you're a developer who knows your way around modern C++ features (or wants to learn), here's my project pitch:

What this could be:

  • Modernized device code (C++23, memory safety, proper abstractions)
  • Support for ALL peripheral features (RGB, macros, DPI, profiles, etc.)
  • Clean API for other developers to build on
  • Reduced fragmentation - community maintains ONE device library instead of competing implementations

Making this real would need:

  • C++ developers , as one developer is no developer (and i have other hobbies!)
  • People who've worked with USB/HID protocols on Windows and other Non-Linux platforms!
  • Anyone frustrated with current Linux peripheral tools and willing to help fix it
  • Design feedback and testing

To kickstart this:

We can fork OpenRGB's existing device implementations (GPL-licensed) as a foundation. I have at least two devices here that offer on-device macro functionality, key remapping, and more, so I can create the basic abstractions for those features.

Thoughts?

[-] vapeloki@lemmy.world 154 points 1 month ago

Just as a friendly reminder. Here in Germany, BMW would have to provide access to the required tools. After all, we have a right to repair over here in Europe.

And if you are american: fucking fix your government

[-] vapeloki@lemmy.world 63 points 3 months ago

I have to answer to this post directly.. First of all: I am a member of the European free software foundation. I am since over 10 years.

Using those distributions is, sadly, a security risk!

Everybody must be absolutely clear about the fact that CPU microcode updates are property blobs, and therefore removed by those projects.

This means: Your CPU runs with only the build in firmware and is most likely vulnerable against many CPU level attacks. CPU bugs can only be fixed with microcode , and if you drop those from the systems you leave the systems vulnerable.

Full free software distributions are a important, but very esoteric.

OP claims even the kernel itself is non free software. So let me just cite the kernel archive

Is Linux Kernel Free Software?

Linux kernel is released under the terms of GNU GPL version 2 and is therefore Free Software as defined by the Free Software Foundation.

I heard that Linux ships with non-free "blobs"

Before many devices are able to communicate with the OS, they must first be initialized with the "firmware" provided by the device manufacturer. This firmware is not part of Linux and isn't "executed" by the kernel -- it is merely uploaded to the device during the driver initialization stage.

While some firmware images are built from free software, a large subset of it is only available for redistribution in binary-only form. To avoid any licensing confusion, firmware blobs were moved from the main Linux tree into a separate repository called linux-firmware.

It is possible to use Linux without any non-free firmware binaries, but usually at the cost of rendering a lot of hardware inoperable. Furthermore, many devices that do not require a firmware blob during driver initialization simply already come with non-free firmware preinstalled on them. If your goal is to run a 100% free-as-in-freedom setup, you will often need to go a lot further than just avoiding loadable binary-only firmware blobs.

https://www.kernel.org/faq.html

[-] vapeloki@lemmy.world 67 points 4 months ago

Over here in Germany where everybody has at least 3 weeks paid time off (being ill does not count to this contingent btw), it is common that leaves are planned in the beginning of the year for larger vacations, so there are no collisions.

Also, if you have children you have priority during school breaks for paied leaves.

This concept could be copied by us employers also, I wonder why not? Maybe because this way you can pressure your employees with your vacation as leverage

[-] vapeloki@lemmy.world 112 points 11 months ago

As a german: this is 1:1 the 3rd Reich playbook.

Stop it as long as you can!

[-] vapeloki@lemmy.world 73 points 11 months ago

Have you ever heard of case of overheating hard drives within the last decade?

[-] vapeloki@lemmy.world 93 points 1 year ago

Greetings from Germany. Maybe you want to skip everything that happens from now on and end this before this lunatic takes office.

On a unrelated topic: aren't you the nation with the most guns?

[-] vapeloki@lemmy.world 69 points 1 year ago

Social media is to blame, at least in huge parts.

It offers a platform for unproven claims, and especially the short content formats are an issue:

You can not cover important topics fairly in those formats. Only populism can profit from it. And the far right does this.

We reached a point where people don't believe the published agendas of candidates and parties anymore. They only trust what the hear and see on social media.

Of course there are other factors, but this is an important one.

[-] vapeloki@lemmy.world 80 points 2 years ago

It is, in most of the civilized world anyways

158
ich_iel (lemmy.world)
submitted 2 years ago* (last edited 2 years ago) by vapeloki@lemmy.world to c/ich_iel@feddit.de

wenn ich "Söder" höre

[-] vapeloki@lemmy.world 44 points 2 years ago

Not so vintage at all. This is a power d-sub. Used in industrial appliances for example. I have seen them used in traffic signs, fire alarm systems and more.

They can carry a data signal and power UP to 30 amps. For example to control a motor, or to power the boards on the other end. You can find them on digikey if you want to find this type and geht the specs. If you have trouble finding them, look for the NOR1344-ND

[-] vapeloki@lemmy.world 66 points 2 years ago

And this is on purpose. The manufacturers pushing those huge trucks and SUV, because the required security and safety standards are lower.

Glad I am not living in the USA

324
submitted 2 years ago by vapeloki@lemmy.world to c/memes@lemmy.ml

Am i to late for the stock photo memes?

6
our 14 year old boy (lemmy.world)
submitted 2 years ago by vapeloki@lemmy.world to c/aww@lemmy.world
view more: next ›

vapeloki

joined 2 years ago