I am seeing higher latency even plugged via cable though, even if less so

I think I updated it a couple months ago on this same windows pc

No, kde on amd

yeah, but the point of a platform are the applications it supports, you don’t want to be The King of Nothing. If even after buying into wayland, applications still work bad on gnome because they expect to get support for X, than gnome needs X or to give a better option (better for the applications, not just according to themselves).

PING. Commenting just for the notification. I edited to respond to the other points but in the meantime you had already answered.

The point 2.1 “less to implement in the compositor” doesn’t apply, because for xwayland go work (which is intended to stay around for the foreseeable future) mutter still needs to implement SSD, it’s only skipping on implementing the Wayland SSD protocols.

Points 1 and 2.2 are not strong points. “We do <thing > because we always did before <thing 2>” is not a good point. For example, after all, we always used X10 before Wayland, and we always did implicit sync before last year. And compositor shouldn’t limit programming styles, they should support as many things as possible, and let the application decide their programming design. Plus, most modern applications on windows and macos embed a copy of chrome to display a single offline Web page, but I don’t see you suggesting we replace compositors with browsers.

Point 2.3 is also weak because most of the things a compositor does are already hard, but they implement them because it makes the experience better. If something is hard, it just means it will be worked on more. Take a look at explicit sync, it took like 4 years to be rolled out, but it was necessary and got implemented.

I’ll give you point 2.3.1… in general I think KDE looks pretty bad, and gnome is really more polished in many aspects. Unfortunately I really prefer the KDE workflow on big screens (but gnome on laptops).

You mean about adding SSD to gnome, which will not happen?

As an argument in favour, I see:

• Support for more applications that “don’t want” to implement CSD (i.e. foot terminal, davinci resolve, that one archive manager I can’t remember)
• Lifting burden for applications that don’t need custom decoration buttons, and so don’t care about implementing their own decorations
• Making the decorations on those applications consistent with the theming of the system

As an argument against, I personally don’t see any. Sure, most gtk apps are designed for CSD and will not translate well to SSD, but I just don’t see why that should stop gnome from implementing SSD. I remember the gnome maintainers were strongly convinced against SSD, but I don’t remember their argument

Paleo Kabi-Lamius

Ahhh, Verona, the city of Romeo and Juliet, and of trademark infringements

rice, noddles and potatoes don’t have any taste, nothing to like

The noodles maybe, the rest is fake

But what about the surname? Grandoni basically means Very Big. The coincidences keep piling up for Mr. Very Big Dino

First of all… Always follow the distribution’s instructions for this kind of thing. Second, I suppose you installed the proprietary drivers, but your GPU is a 30xx so you should really get the open drivers instead. There’s a paragraph on that in the page you linked, try that and see if it works.

If you are writing a parser in haskell just use Happy and get it over with

I only drink Gatorwine

What a coincidence, I saw that for the first time this Friday

Apathetic omelette

I experience something similar on a vega56, but it doesn’t happen on generic high loads, it happens only

• in some specific loads (for me it was mainly A Plague Tale: Requiem)
• when something touches the grounding of my monitor (the display port of the GPU is faulty, it seems)

I like many of your points, but your comment is facetious.

You said it yourself, “it’s good for someone trying to bang out scripts”… and that’s it, that’s the main point, that’s the purpose of python. I will argue over my dead body that python is a trillion times better than sh/bash/zsh/fish/bat/powershell/whatever for writing scripts in all aspects except availability and if that’s a concern, the only options are the old Unix shell and bat (even with powershell you never know if you are stuck ps 5 or can use ps 7).

I have a python script running 24/7 on a raspberry that listens on some mqtt topics and reacts accordingly asynchronously. It uses like 15kiB (literally less than 4 pages) of ram mostly for the interpreter, and it’s plenty responsive. It uses about two minutes of CPU time a day. I could have written it in rust or go, I know enough of both to do it, it would have been faster and more efficient, but it would have taken three times the time to write, and it would have been a bitch to modify, I could have done it in C and it would have been even worse. For that little extra efficiency it makes no sense.

You argue it has no place in mainstream software, but that’s not really a matter of python, more a matter of bad software engineers. Ok, cool that you recognise the issue, but I’d rather you went after the million people shipping a full browser in every GUI application, than to the guys wasting 10 kiB of your ram to run python. And even in that case, it’s not an issue of JavaScript, but an issue of bad practices.

P.S. “does one thing well” is a smokescreen to hide doing less stuff, you shouldn’t base your whole design philosophy on a quote from the 70s. That is the kind of shit SystemD hater shout, while running a display server that also manages input, opengl, a widget toolkit, remote desktop, and the entire printer stack. The more a high profile tool does, the less your janky glue code scripts need to do.

I’ll be honest, I think modern python is cool. You just need to accept that it has some limitations by design, but they mostly makes sense for its purpose.

It’s true that the type system is optional, but it gets more and more expressive with every version, it’s honestly quite cool. I wish Pylance were a bit smarter though, it sometimes fails to infer sum types in if-else statements.

After a couple large-ish personal projects I have concluded that the problem of python isn’t the language, but the users.

On the other hand, C’s design is barren. Sure, it works, it does the thing, it gives you very low level control. But there is nothing of note in the design, if not some quirks of the specifications. Being devoid of innovation is its strength and weakness.

goo-goo g’joob, g’goo goo g’joob Goo goo g’joob, g’goo goo g’joob, g’goo.