Pretends to rage-quit from contributing, not resigns.

Good riddance, unless they learn how to behave like well adjusted adults, instead of constantly playing to a microblogtard crowd. <= That’s what would I have wrote if something relevant actually happened, which is not the case.

And this is coming from a Rustacean.

This more belongs to a “linux drama” community (if one exists).

Is there a tiling Wayland compositor out there that supports applying custom shaders to windows (similar to picom)? This has been a known limitation for many years. And I brought it up myself with a couple of compositors’ developers, and they told me that it would break direct scan-out, and I told them that I would be fine with that, and then discussions fizzled out.

I also tried an x11vnc alternative I don’t remember the name of, and besides the generally buggy experience, it completely broke when power management kicked on the sever side (turning off the monitor IIRC). So that’s another show stopper, although maybe not as relevant as custom shader support which I need for applying my custom color inversion shaders to specific windows, otherwise, my vision would go bad quickly.

So yeah, I will be sticking with my Awesome WM (+picom +x11vnc) setup for a while too.

The highest cost for most projects comes from the CI runners.

i2p only provides anonymous transport, so not relevant at all.

ipfs is joke tech (you would be better off building something on top of good old torrents).

A fanatic microblogger* inflating some kernel drama, and inviting the microblog echo chamber and the whole internet gantry to chime in… is surely worthy of being the hottest topic of the day.

* Yes, I know who they are.

What serious Linux users buy GPUs based on raw gaming performance on release week?

I personally buy based on open-source driver support. And this includes long-term active support, AND developer approachability.

My current GPU is an AMD/Radeon one because of that. But I’m reconsidering my position when my next hardware upgrade comes.

I reported an AMD GPU driver issue to mesa once. It was tested, confirmed, and patched by a competent AMD developer within a few days. Now you have easily reproducible issues like this not even going past the testing phase after many months. And there are similar issues across all model generations.

If I were to upgrade my workstation next year, I would probably go with an AMD CPU and an Intel GPU, which is the exact opposite of my current setup 🙃. One should never rely on outdated perceptions.

I’m getting Hans Reiser vibes from Overstreet

You would do good on a CoC board.

Friendly Advice: If you hang out in microblog platforms, especially mastodon, do it less. The echo chamber discourse there is not good for your sanity. This is general advice, not just for you, really.

If you’re not into tiling, install openbox and a panel of your choosing. You will quickly find that you don’t need a DE at all.

The maintenance is too high.

acquired knowledge spotted

I will let you on a little secret.

The best “support” you can get is support from upstreams directly (I’m involved in both sides of that equation). But upstreams will often only “support” you when you 1. run the latest stable version 2. the upstream source code wasn’t patched willy-nilly by the packager (your distro).

So the best desktop linux experience comes with using rolling distro that gives you such packages, with Arch being the most prominent example.

The acquired knowledge that argues stability and tells you otherwise is a meme.

Monthly Reminder: High or low, all Linux usage stats are fake.

Ask yourself:

• Where do these stats come from?
• What do they actually measure?
• How can the total number of all Desktop Linux users or devices be known to anyone?

​
The fact of the matter is, none of these stats actually measure the number of users. Most of them are just totally flawed guestimates based on what is often limited web analytics data collected by them.

In fact, not even the developers of a single distribution can guess the number of people/devices using/running that specific distribution. A distribution like Debian for example has mirrors, and mirrors to some mirrors, and maybe even mirrors to some mirrors to some mirrors. So if Debian developers can’t possibly know the number of Debian users, do you think OP’s site knows the total number of Desktop Linux users?

And let’s not get into the fact that the limited data they collect itself is not even reliable. View desktop site on your Android phone’s browser. Congratulations! Now you’re a desktop Linux user. No special user-agent spoofing add-on needed. You’re even running X11. Good choice not following the Wayland fad too soon.

High or low, all Linux usage stats are fake.

sublemmy

Lemmy communities. Mbin/kbin magazines.

I appreciate the attempt at comedy. But I have no problem with Alpine (other than the snail oldmalloc performance). I even contributed a port fix or two.

The more interesting part that should have been read from my comment was that Chimera DOES NOT use GCC. Not to mention that it ships non-GNU coreutils that are usable by desktop users. While Alpine has it’s GNU coreutils package overriding busybox because that’s what most users would want. So that’s another GNU component any non-meme non-turbo-minimalist desktop user would be using on Alpine.

Alpine uses GCC at least.

OpenBoozy/OpenBooza
BundleGreen

The freeze-the-world “stable distro” concept is an outdated meme, especially when it comes to desktop usage.

In server usage, at least there is the idea of not breaking things by avoiding major version upgrades of used services/daemons. But even then, freezing the used services alone, while letting other system components have what may amount to thousands of fixes for some of them (and yes, a few bugs), is probably better, at least conceptually. But it’s admittedly not a well supported setup, unless you’re willing to basically maintain a distro yourself.

And no, the “stable” distro maintainer is not going to magically backport all the “important” changes, unless backport means applying an almost full diff from a later version of the source package.

(I actually mention this because I remember Debian doing this a long time ago with what I think was ffmpeg. lol.)

Many desktop users know this.
Upstream developers definitely know this, and occasionally write about it even.

(I was a Debian user many moons ago. That was before systemd came to existence, or PulseAudio became default in any distro. Went from stable to testing to sid. Testing was the worst, even stability wise. Sid was the best for desktop usage. Then a sid freeze came because a stable release cycle was near. Went to a rolling-release distro and never looked back.)

The Rust hype at least makes sense.

In technical context, yes. I’m a Rustacean myself.
In business/marketing context, …

It’s not you who needs it.
It’s for buzzword chasers and cost cutters.

Rust (=> fast and hip)
Shared (=> outsourced)
AI generated (=> robot devs)

Get it?

why gcc couldnt do this automatically? i mean its supposed to do this right?

Because gcc is a compiler, not a build tool.

Maybe you come from a language where the two tasks are combined, but that’s not the case here.

and another important issue that clang ls (language server) showed the same error? i thought fixing this would fix that too, but that isnt the case here.

For the same reason stated above, clangd needs to know how you build your code. This is done via a JSON file called compile_commands.json.

In your trivial case, running this should be enough:

clang -MJ- main.c `pkg-config --cflags --libs dbus-1` > compile_commands.json