Funny thing is that the same issue was resolved for me by switching the other way around - from HDMI to DisplayPort. So there’s something weirder going on than a bug in DP implementation

Drawing over the PDF is not a digital signature. I haven’t seen a browser that can sign a PDF.

People might also assume that the quote in the post is from the article, and not just your rant

The biggest drawback of not providing any SSDs even as a fallback is obviously… what if the app just doesn’t draw CSDs?

Wayland requires apps to be able to draw CSDs, so that’s just a broken app. SSDs are optional extension. So the app should either use X11 (and rely on Xwayland to provide the decorations), or implement Wayland properly.

In fact, I think you’d be better off writing a deep dive into what/how environment variables work at build time, and also invoking commands on the CLI.

But LD_PRELOAD doesn’t really have much to do with build time behavior (unless you’re talking about replacing parts of the compiler) - it allows you to force a shared library to be loaded with higher priority than anything else, so it overrides symbols from other libraries.

It is recognized and used by Linux’s dynamic linker, which is run-time, not build-time.

Yes, the DE-specific implementations is pointless (as far as I know, I use a WM), but the XDG implementation is actually used first, and the function returns true if any impl returns true, like xdg() || gnome() || gnome_old() || kde().

True, I must’ve read the code wrong when making the comment.

This isn’t that bad?

Yes, which is why I take issue with a PR (or rather what should have been a PR) that introduces crap code with clearly visible low effort improvements - the submitter should’ve already done that so the project doesn’t unnecessarily gain technical debt by accepting the change.

With multiple impls, you have to resolve conflicts somehow.

Yep, that’s why I think it’s important for the implementations to actually differentiate between light and fail state - that’s the smallest change and allows you to keep the whole detection logic in the individual implementations. Combine that with XDG being the default/first one and you get something reasonable (in a world where the separate implementations are necessary). You do mention this, but I feel like the whole two paragraphs are just expanding on this idea.

But it’s better to criticize the code’s actual faults (…)

I made a mistake with the order in which the implementations are called, but I consider the rest of the comment to still stand and the criticisms to be valid.

Well, the detection is broken for KDE and backwards in the XDG implementation (which is also only used as a fallback when the three DE-specific implementations fail, even though all of them actually support XDG so having separate implementations is pointless).

Also with the way it’s implemented, it will have unexpected results for users who have both KDE and Gnome installed (or at least have leftover configuration files) - if you for example used KDE in the past with a theme considered to be “dark” by this and now use Gnome and have it set to light mode, you will get dark mode GZdoom with no obvious reason why.

Oh and the XDG implementation is also very fragile and will not work on everyone’s system because it depends on a specific terminal utility being installed. The proper way would be to use a DBus library and get the settings through that.

And when somebody comes to fix it, they will have to figure out a) what’s so special about the DE-specific implementations that XDG wasn’t enough (they might just assume that XDG isn’t supported widely enough), b) learn how to detect dark theme properly on the DE they’re fixing, c) rework the code so that there is a difference between “this DE wants light mode” and “couldn’t figure out of this DE is in light or dark mode” - both of these are now represented by the “false” return value.

I don’t think a well written and functioning code made with AI assistance would get a response this strong, but the problem here is that the code is objectively bad and its (co-)author kept doubling down about something they probably barely even checked.

You don’t need any swap space for suspend to work

The download will simply fail if the version pacman wants to download isn’t available on the mirror. The version is part of the download URL.

Wayland does force clients to be able to cope with a compositor that doesn’t do SSD - CSD support is mandatory, SSD optional.

It’s a crappy clickbait title, I don’t see why it shouldn’t get downvoted

I guess how much people care also depends on whether they tend to use laptops in ways and places that are prone to causing damage to the ports. I’ve never damaged any port on any laptop I’ve ever owned, and it’s unlikely I ever will because I like to keep the cables organized and out of the way (so it would require conscious effort to tug on them), and when I want to pick my laptop up, I always quickly run my hand around its perimeter to make sure everything is disconnected.

I do not claim that this is the correct way to use a laptop or that others should do the same, it is a tool that should be used the way its user needs, I just want to point out that for some usecases, this is simply a non-issue in the same way a non-replaceable CPU is - nothing’s going to happen to it.

Also, my current laptop does have both a barrel jack (probably works, I’ve never used it) and a USB-C charging connector, so it’s not necessarily an either-or proposition.

deleted by creator

Just to be clear, the applets were stuck while the laptop was plugged in? If so, then it might just be the threshold - connected, not charging, not discharging (because the laptop is running off the AC adapter).

For example on my IdeaPad laptop, when I enable the charge limiting feature it will get “stuck” at 59 or 60% while plugged in. It doesn’t have a configurable threshold. Although your laptop might provide a more fine-grained control given that you were able to fully discharge it while plugged in.

I agree, the fact that Meta considers 13 year olds being able to have romantic chats with chatbots to be perfectly fine is disturbing and IMHO the main newsworthy thing here.

However there is no mention of “200 pages of romantic interactions with minors” in the article - that is the whole chatbot guidelines document. Still, it including such things shows how shitty Meta is as a company.

OK, so the whole LLM chatbot arranging dates with people thing is obviously problematic, but this person simply tripped and fell, and the headline vaguely implies that the chatbot is responsible for his death. That seems a bit clickbaity - if it was a real person and they were actually waiting to meet at the agreed upon address, the outcome would be the same.

You can disable the USB printing module if you don’t use it - that’s the one causing this bug. It should be fixed in the next release.

Idk, it surprises me it took so long for TP-Link to get into trouble with how they tend to support every HW revision of their routers for about a year and then stop releasing any security updates for them. That’s awful for a device intended to sit at the edge of your network, possibly having a public IP address.

Like sure, you can look for any reasons you want, but not giving a fuck about security in a device that’s always connected to the internet and also routes all user traffic is bound to get companies in trouble when someone with the power to do something about it notices.

xfwm is XFCE’s window manager, and it’s eating almost 30% of the total system memory, so that’s the prime suspect (I’m not exactly sure how much it interacts with other apps, so it’s possible something else is forcing xfwm to use all that memory, but that is IMHO unlikely).

An ugly “fix” is to log out and log back in (yes, not much better than just rebooting), or you could try to somehow restart xfwm - running xfvm --replace in terminal might work.

Edit: there’s an issue on the Manjaro forums that might be related: https://forum.manjaro.org/t/xfwm4-memory-leak-since-4-20/173910/7

That was my deleted comment, but then I realized the article specifies they are Rome CPUs (Zen 2), while the 4000 series of EPYCs is based on Zen 4