This post is primarily for the people here that are forced to work with AI. But it may be interesting for everyone.

We all here are aware how bad AI is for people and the environment. During some research I found out that this effect is most likely multiplied by pure greed (no even worse then you thought).

A little bit of context: I am currently responsible for a small R&D Team (me and some trainees) for a EU managed Services provider. Because of corpo pressure we need to evaluate AI usage.

I gave multiple models, nearly all run on 150W hardware a shot. And of course I was forced to test Claude also.

And what I found buffled me: the "frontier" top nodge best of the best model by Anthropic was the only one that did not even complete the task.

It constantly violated against clear rules. All of them about code simplicity and maintainability.

For example QWEN solved the task in about 30 minutes, one shot

And this would be the bill we would have paid for Claude without any usable result.

Having a deeper look at what happens if you let different models work on an existing codebase:

Claude will introduce complexity on every change. Wasting compute and energy.

As open source models clearly can do the job, why can those super huge big models not do the job?

And I think the answer is greed:

• more tokens more money
• lock the user into your model. Make sure you can not leave anthropic.

And that cost is really high. Not only those absurdly high token prices (factor of 100 higher then open models) it burns the employees out.

Is anyone here forced to work with AI and had made similar observations?

Luckily for me, I have some influence at my job and can minimize the AI impact in every sense. And maybe such experiments and research can convince other employers to not go down this road.

In the last weeks, I have seen some posts against kinds of AI, we are using as a society since decades (yes, decades) just because the Term AI is used.

When we are talking about society and planet destroying AI, we are talking generative AI. That is that shit we know als Claude and ChatGPT.

But media (and we) are starting to mix this up with "classical Machine Learning"

Some stuff that is AI, and I am pretty sure we are not fighting against:

• hand written numbers recognition (developed around 30 years ago)
• lane hold assist systems
• voice recognition
• image classification (computer aided diagnostics in radiology is around since 2010).

Those tasks do not need GPUs, huge amount of RAM or electricity.

We should differentiate between Generative AI (LLM, Video and image Generation) and those old school, valid and useful "AI" systems.

Not seeing a difference between those things is a AI Bro behavior, and should be beneath us.

Just being against everything because somebody wrote "AI" besides it only offers AI Bros an attack surface on every other argument we bring forward.

Everything that makes GenAI bad (hallucinations, AI psychosis, energy consumption, RAM usage,....) is a result of the generative part.

An AI model that recognizes YOUR (yes, your!) handwriting on a envelope and routes your letter correctly, and does that since decades, is also AI. I hope nobody here expects us to go back to sorting boxes and hand sorting of letters and packages.

EDIT: for more detail on AGI vs. GenAI look at this great comment.

cross-posted from: https://quokk.au/c/tenforward/p/1054802/fuck-ai

Fuck AI

• Star Trek S2E8 "I, Mudd"
• Star Trek: The Next Generation S1E2 "The Naked Now"

AI is the future they say. But what future?

While AI still did not deliver the promised solution to climate change, it will for sure speed it up.

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?

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?

Hey all,

I don't know what to do, and need some advice.

Today I received the information that my father was moved to the palliative ward. He was in the hospital since a few days.

He had lung cancer, and lost half of his lung, now the tumor is back and restricting the remaining half.

He is dying. The doctors don't know when, and if there are days weeks or months left. Nothing to do but to make hin as comfortable and pain free as possible.

I want to visit him badly. But I am panicking already just thinking about what to say or what to do. I could call him but me, taking on the phone..., and the main issue remains, what should I say?

I am bad at social interaction, yeah. I live with that. But this situation is wo much worse I ever could imagine.

I love my dad. He is one of the most important persons in my life. Loosing him will of course be painful, but being in a situation where I can get the call every day, every minute ...

I am not able to work, think, sleep or be around other people very long.

Does anybody here have some advice?

UPDATE1:

Thank you all so much for your feedback!

TLDR: I organized a visit tomorrow, and made sure i will go through.

First, i want to clarify my issue, as yesterday i was rather vague: This is not a question about "to go or not to go". I am experiencing meltdowns on the pure thought of "what happens during the visit". I just lock up. That is nothing rationale. I have to overcome those meltdowns - and that is why i am asking for advice.

Your feedback helped a lot during this process. While i am still not at a point, where i don't freeze, not doing so would for sure not come to any good.

I asked my spouse to go with me tomorrow. She will make sure that i will go through. Also, i don't have to worry about medication to much ( I get medical cannabis), as she will drive me home if needed.

Again, thank you all! And every feedback is still welcome, it really really helps!

Yesterday we took a plant in for emergency care. 12 hours after we moved the plant from soil to hydro she is still alive, and shows no signs of giving up.

Today, I received a call from a friend of a friend. One of his plants showed fungus on the leaves, several signs of nutrition burns and deficit symptoms on other leaves.

We took the plant in, and removed it from its soil. 80% of the root was just brown, dead mush.

We put it into hydro as an emergency solution.

Let's hope the girl survives.