Notices by THE MARTYR OF BUTLERIAN JIHAD (icon_of_computational_sin@mstdn.starnix.network)

@Arwalk Valve dudes are unhappy that FDO autists take years (literally) to pass even the most basic of protocols and started their own repo of Wayland extensions, open for submissions from anyone.

https://github.com/misyltoad/frog-protocols

cc @sun

Just a gentle reminder. All this modern IDE tooling that you've grown to rely upon makes you an objectively worse programmer.

x86 is a bad architecture and I'm hopeful that it dies soon.

Since I hate Wayland so much, any software that I write will, upon detecting itself running under a Wayland compositor, randomly turn into a fork-bomb where each process creates a dozen windows with random properties.

HOW IS THAT FOR SECURITY, YOU FUCKING FREEDESKTOP CUNTS? I just want my software to be able to move its own windows, but noooooo... you claim it's insecure. FUCK OFF! EAT SHIT AND DIE! I WILL BREAK EVERYTHING THAT YOU HOLD DEAR!

@dcc @rek2 @threat no, you are just being petty about some dude on the internet not liking your favourite software

@dcc @rek2 @threat i wouldn't know what a hot dog with shit tastes like, but I'm glad you've had this experience for all of us.

@dcc @rek2 @threat pure alsa is garbage. The rest isn't any better, most software only supports pipewire these days anyway.

I am not going to completely reconfigure every part of my system that deals with sound just because one garbage of a player shits itself profusely. Winamp works just fine for me.

@dcc @rek2 @threat hahahaha

again, pipewire works for everything but audacious. So, it's audacious problem. Also, it's not like L'Eunuchs has any other audio system.

@dcc @rek2 @threat

1. Winamp works with Pipewire somehow. So, it's an Audacious problem.
2. Of course. If I wanted a player without UI, I'd use cmus. Again, Winamp doesn't have this issue, provides nice UI and doesn't gulp memory.

@dcc @rek2 @threat

1. does it matter? EQ should work inside the player.
2. Yeah, it does

@dcc @rek2 @threat

1. substandard EQ that somehow manages to be broken in my system. No, I don't want to debug it and submit bug reports, I just wanna listen to music. Thanks you.
2. somehow Audacious manages to munch on more resources than the latest Winamp. Winamp works like it's 2007, rarely going about 100 megs of RAM. Audacious easily gulps triple or more of that. Not that I care, I have 128G of that, but still it's nice to use more thoughtfully written software.

@dcc @rek2 @threat audacious sucks

@threat @rek2 kinda same. Which is why I use Winamp to listen to music on L'Eunuchs. Funny, but it works much better via Wine than any native L'Eunuchs music player. I'm dying of irony.

I also heard of people using Windows versions of Firefox in Wine for some seemingly valid reasons I can't remember.

@threat @rek2 because Electron is the only somewhat portable GUI out there. Except maybe Qt, but Qt comes with it's own barrel of worms (ahem C++ ahem..)

@threat @rek2 depends on your target platforms. A lot of devs target Android and iOS too, and Qt has weak support for those. Especially for iOS.

I'd take Qt + Kirigami too, KDE people did a magnificent job of splitting their libraries into small reusable components that do not pull the entirety of Plasma desktop. Still, I understand the rationale behind using Electron even though I hate it.

It's actually stupidly funny that the most portable after Electron GUI framework out there is...

WAIT FOR IT!!!!

Winapi + MFC! Because Wine exists and works virtually everywhere, and this makes older Windows apps portable as fuck. Even if you consider L'Eunuchs world alone, you have much higher chances of successfully launching a winapi binary than anything in GTK.

@threat @rek2 your workflow doesn't, but I'm willing to bet money that your Signal app for both phones and desktops is actually the same code. Element, for one, does exactly that, it's the same code base for browser, desktops (Electron), and mobile, with just slightly tweaked UI settings.

As for Wine, it's not just them. Say what you will about Macrohard, but they do a stellar job of supporting backwards compatibility. L'Eunuchs gnutards can only dream of something like that. It's much easier to launch Windows versions of even not that old games (say, early 2010s) with Wine/Proton than their native L'Eunuchs ports.

Working on a C++ project really does make me appreciate Haskell's tooling. Other languages are just so much worse here.

What happens if you provide an invalid library name for cmake in target_link_libraries()? Nothing, really. CMake will just ignore it.
Does cmake --fresh really start a fresh build, ignoring local caches? No, you need to clean up things manually sometimes or you'll run into bizarre errors.
And this stuff is just full of little annoying quirks like this.

One peculiar consequence of fat CPUs with enormous core counts is that measuring CPU load in percentage of allocated time slots - as in, most monitoring software does now - is kind of useless.

For example, when talking about a CPU with 64 logical cores, one process utilising two cores to the full will only show up as 3% load, and yet this might just be enough to ramp up the cooling system and make some noise. Meanwhile, a bunch of small loads spread across the cores will add up to the same 3% and yet the overall load will be lower, your fans will stay quiet. If you throw dynamic clocking into the mix, the entire idea of counting allocated time slots goes to shit. 50% load on a core at 2GHz and 50% load on a core at 5GHz are entirely different things. Therefore, this metric is most useless any way you look at it.

The better idea, as I see it today, would be to RETVRN to tradition and measure load in... Watts against the maximum TDP that your CPU can draw. A mostly idling CPU at low clock wouldn't draw much power, whereas a CPU at high load would draw as much as possible. Number of processes or cores loaded doesn't matter here, and the number is pretty easy to grasp.

Just so that you know, loading GMail interface requires downloading about 11 megabytes of data. Which is a lot more than the entire contents of my GMail inbox. What is the point of this, again?

Yeah, plain text passwords. Just as we expected.

Should an application trust that the keyring and its access are secure? Perhaps. Should the implementation just forward secrets over a bus without any access restrictions? FUCK NO!

Here I would like to remind you again that freedesktop.org people are a bunch of backwards shit-for-brain cockfaced retards and nothing - I repeat, NOTHING - that they have ever made is good for anything. The whole organisation is a circus full of clowns.