u wot

It takes 5minutes for dnf to start running and when it does run, it runs for next to forever when doing commands

I use i3, but i tried every desktop environment. same issue

What? i3 does not leak. I have been using it quite happily so far.

I had almost a similar kind of thing with dnf once even though it was a clean install. It took somewhere around a minute at times to get past the Metadata expiry date thing. I ran dnf clean all and the slowness went away...

I been there, done that. It wasnt dnf, it was the whole system

Can you send screenshot of htop and iotop?

will do, but when I did. Nothing was noticably except for the high disk usage

It takes 5minutes for dnf to start running and when it does run, it runs for next to forever when doing commands

that's so strange How slow is your internet connection?

This sounds like you're hitting loads of swap or something.

swap usage was constantly under 10%

that's so strange How slow is your internet connection?

1MB/ps

will do, but when I did. Nothing was noticably except for the high disk usage

Thats likely the reason.

What exactly is using io?

swap usage was constantly under 10%

Doesnt matter if it needs to read and write to it all the time - swap should be a last resort

If your memory reaches 95% ever you already have a sign to upgrade, fast.

What exactly is using io?

I use just chrome. Thats all. tried firefox, it was unbearable

I use just chrome. Thats all. tried firefox, it was unbearable

How much ram do you have?

Doesnt matter if it needs to read and write to it all the time - swap should be a last resort

My ram usage is always under 50%

1MB/ps

that's actually so slow

Doesnt matter if it needs to read and write to it all the time - swap should be a last resort

I thought it was actually weird because it normally avgs 5%

that's actually so slow

I have used dnf on slower connections and it was way faster

Phoronix The Big GNOME Shell Memory Leak Has Been Plugged, Might Be Backported To 3.28 The widely talked about "GNOME Shell memory leak" causing excessive memory usage after a while with recent versions of GNOME has now been fully corrected. The changes are currently staged in Git for what will become GNOME 3.30 but might also be backported to 3.28...

Phoronix The Big GNOME Shell Memory Leak Has Been Plugged, Might Be Backported To 3.28 The widely talked about "GNOME Shell memory leak" causing excessive memory usage after a while with recent versions of GNOME has now been fully corrected. The changes are currently staged in Git for what will become GNOME 3.30 but might also be backported to 3.28...

They finally fixed it. Now they need to make it smooth. I'll switch to gnome again next month to check.

Phoronix The Big GNOME Shell Memory Leak Has Been Plugged, Might Be Backported To 3.28 The widely talked about "GNOME Shell memory leak" causing excessive memory usage after a while with recent versions of GNOME has now been fully corrected. The changes are currently staged in Git for what will become GNOME 3.30 but might also be backported to 3.28...

Oops...

They finally fixed it. Now they need to make it smooth. I'll switch to gnome again next month to check.

Memory leak fix won't make gnome smooth

Gnome 4 will

Still waiting for wayland to implement proper Ui scaling for HiDPI screens ç__ç

Memory leak fix won't make gnome smooth

Why won't this memory fix make gnome smooth?

Why won't this memory fix make gnome smooth?

because gnome 3 by design runs extensions and other things on the ui thread

not to mention that thats in javascript

this memory leak was caused by the Javascript Runtime GC iirc

this memory leak was caused by the Javascript Runtime GC iirc

You can read the blogpost, it describes why mozjs and c objects didnt interact that well.

this memory leak was caused by the Javascript Runtime GC iirc

Ha-ha

I am going to check that out. Thanks!

Gnome 4 will

Which will not be released in the near future

Gnome devs will take the eazy way out and take shortcuts to fix problems.

Why don't Gnome folks follow success cases like MATE staff does and benchmark them to correct these memory-based issues for good?

Why don't Gnome folks follow success cases like MATE staff does and benchmark them to correct these memory-based issues for good?

Cause they made a really bad decision while making gnome 3 (the single ui thread, JavaScript runtime, etc.) They've been trying to use makeshift fixes ever since.

Gnome devs will take the eazy way out and take shortcuts to fix problems.

Taht is incredibly unfair. They have the problem that mozjs and c just dont work together and that mozjs doesnt have recursive garbage collection or proper disposal tracking.

@Kohane @jflory @AnXh3L0 joinspam

Taht is incredibly unfair. They have the problem that mozjs and c just dont work together and that mozjs doesnt have recursive garbage collection or proper disposal tracking.

And "taking the easy way" is "making it work for now until mozjs doesnt suck in this area again"

@Kohane @jflory @AnXh3L0 joinspam

Done.

Is there an O'Reilly SELinux book?

I think yes. But you can check in their website.

Not sure if this will be considered SPAM, but it is related to Fedora... ?

If it’s related it’s fine, just send a few introductory words as you did now.

Cause they made a really bad decision while making gnome 3 (the single ui thread, JavaScript runtime, etc.) They've been trying to use makeshift fixes ever since.

And far, far from it - they are in the process of either separating the rendering and logic threads from each other, improving the rendering to screen and and - and maybe they'll even keep the js base for it. Or use gtk4 for everything.

And "taking the easy way" is "making it work for now until mozjs doesnt suck in this area again"

That's right but as an end user who really likes their UX, things should be smooth enough. You don't notice it much if you use gnome exclusively, but when you compare it to any other DE, the difference it noticeable.

And none of those fixes have been "makeshift". That discredits thousands upon thousands of manhours to make a well-working, smooth UI and friendly user experience. And gnome is that nowadays. Its the default in 4 major commercial distros for a reason.

Cause they made a really bad decision while making gnome 3 (the single ui thread, JavaScript runtime, etc.) They've been trying to use makeshift fixes ever since.

So, do you think that if they ditch this single ui thread and JS runtime and only focus on c libs, that issue would be amended once and for all?

And far, far from it - they are in the process of either separating the rendering and logic threads from each other, improving the rendering to screen and and - and maybe they'll even keep the js base for it. Or use gtk4 for everything.

Gnome and GTK 4 is in the pipeline?

That's right but as an end user who really likes their UX, things should be smooth enough. You don't notice it much if you use gnome exclusively, but when you compare it to any other DE, the difference it noticeable.

I compare it and other environments, yes.

And kde was laughing stock over gnome whenever i tried it. Unlike gnome most other envs didnt use my gpu for acceleration either.

Thus gnome is usually the most smooth and definitely the least crashing DE for me.

ERROR: S client not available

So, do you think that if they ditch this single ui thread and JS runtime and only focus on c libs, that issue would be amended once and for all?

Nope. I think more optimization can do it. Gnome 3 vs 3.28 are extremely different in terms of speed. But yeah, they need to completely rework it to entirely fix it.

And kde was laughing stock over gnome whenever i tried it. Unlike gnome most other envs didnt use my gpu for acceleration either.

I'm not having that debate again.

And "taking the easy way" is "making it work for now until mozjs doesnt suck in this area again"

dude

the golden rule when building a ui

is not to put too many things on the ui thread

every ui dev knows this

js and everything else aside

that is the poorest design decision

Nope. I think more optimization can do it. Gnome 3 vs 3.28 are extremely different in terms of speed. But yeah, they need to completely rework it to entirely fix it.

splitting logic and ui should already do alot

But if they want to fully redo gnome 4 anyway basing things on gtk might make sense

splitting logic and ui should already do alot

which in of itself is a rearchitecture

Nope. I think more optimization can do it. Gnome 3 vs 3.28 are extremely different in terms of speed. But yeah, they need to completely rework it to entirely fix it.

Hum..I see! Nevertheless, wouldn't it be more feasible to reposition (or reallocate - if you will) garbage collection towards mozjs and leaving C more freely to perform other tasks - thus, it won't consume so much memory? Would that be one of these optimization deeds you've mentioned?

Hum..I see! Nevertheless, wouldn't it be more feasible to reposition (or reallocate - if you will) garbage collection towards mozjs and leaving C more freely to perform other tasks - thus, it won't consume so much memory? Would that be one of these optimization deeds you've mentioned?

Mozjs is in the process of having that fixed, yes.

But for now if calling another GC cycle isnt all that wasteful in performance then seems fine.

Thanks for clarifying!

Does turning on night light consumes more power?

Does turning on night light consumes more power?

Yes, it does

Is that the color shift that cause the power consumption or just turning on the feature?

I have added the night light slider extension and if I extend the bar all the way to the right side such that the night light is technically off, but the night light is actually on, would it still consumes power?

GNOME quite likes to use animations even though they run at 10 fps. Have to turn them off

Why, the gnome themes doesn't apply to lock screen? On lock screen it always shows the default theme.

https://feaneron.com/2018/04/20/the-infamous-gnome-shell-memory-leak/