4 ms·

Some of your comments are valid and I agree with them, but some of them are a lot of nonsense. >This was caused by a weird mismatch between its javascript desk

Some of your comments are valid and I agree with them, but some of them are a lot of nonsense. >This was caused by a weird mismatch between its javascript desktop and its compiled code that was too hard to fix so they decided to just constantly run the garbage collector and marveled at how not horrible this performed in actuality. No, this is not even close to what happened. There was never any weird mismatch, the refcounting is very similar in both of them. The bug was that the garbage collector wasn't running correctly. Please read the (now 4 years old) blog post: https://feaneron.com/2018/04/20/the-infamous-gnome-shell-memory-leak/ https://feaneron.com/2018/04/20/the-infamous-gnome-shell-mem... >Deprecates features that people use without replacement. I would like to know about these desktops that are still under active development and have never removed or deprecated features. I've never seen one. I'm sure if you look hard enough you can find people complaining that Windows 11 doesn't support 8-bit color displays at 640x480. >See tray icons for a literal decade This never happened, there has been several extensions for tray icons for the entire decade. The real problem here is that all the APIs for tray icons are broken and nobody bothered to implement one correctly. >Has no addon API forcing addons to monkey patch the javascript desktop ensuring such efforts can trivially fail on any version update and addons that aren't actively developed will stop working. This has nothing to do with javascript or addons. In general code that isn't being developed has a high probability it will stop working at some point. And this presents a false choice too. I've heard this statement so many times but nobody has ever proposed what a real addons API should look like. AFAIK there are no desktop platforms or mobile platforms anywhere with an addons API that does everything that can be done with GNOME extensions. The closest I've ever seen are things like addon widgets for Android and KDE which aren't even close to being the same thing. >Worse if they crash they especially under Wayland take down the entire session That's not really important anywhere, the apps themselves are supposed to implement session management to insure against any system crash. If I were you I would avoid commenting on these things again unless you have a proposal to make, they cheapen the rest of your comments. It's honestly tiring to keep seeing these long lists of random grievances where the ultimate suggestion is "just throw it away and start over while somehow avoiding all these issues in a way that is not explained". Do you really think having yet another choice is going to make a difference?

michaelmrose 5y ago
This is the weird mismatch between compiled and javascript code from your own link which I am familiar with however I do thank you for linking it here as I shall substantiate my argument based on your own link. >-------------------------------------------------------------- Here’s the problem: C objects don’t track who owns them; instead, they only track how many owners they have. This is the traditional reference counting mechanism, and it works fine in C land because C is not garbage collected. To the garbage collector, however, the C objects would look like this: The garbage collector has no means to know the relationships between C objects. The garbage collector, then, will go there and destroy the root one. This object will be finalized, and the directly dependent objects will be marked for garbage collection. Only the directly dependent objects are marked for the next garbage collection. The “solution” is basically throwing a grenade to kill ants. We now queue a garbage collection every time an object is marked for destruction. So every single time an object becomes red, as in the example, we queue a GC. This is, of course, a very aggressive solution. But it is not all bad. Some early tests shows that this has a small impact on performance – at least, it’s much smaller than what we were expecting. >-------------------------------------------------------------- This is basically garbage engineering that shouldn't have made it out of the design stage let alone been knocking over systems for 8 years. Moving on. In essence a substantial chunk of the Linux desktop crowd feels like gnome is crap and has correctly understood that they aren't welcome to fix it because project owners have a very opinionated vision on how the Linux desktop works. This is probably why 60% of Linux Desktop users don't use it. https://linux-hardware.org/?view=os_de https://linux-hardware.org/?view=os_de If Pop!_OS succeeds in replacing it and Ubuntu ends up adopting it will probably drop from 40% of users to closer to 5%. It would be in serious danger of irrelevancy at that point if it weren't Red Hats baby. You are welcome to your own opinion on the utility of the gnome desktop but the idea expressed by the grand parent post that the Linux desktop space ought to just settle on a singular environment that cannot even convince the majority of users to use it despite having more corporate money spent on it in a year than other environments in history seems ill founded. Edit: > the apps themselves are supposed to implement session management to insure against any system crash Well designed software environments don't crash in a way that causes the underlying OS or end user applications to die. One time in a decade would be one time too many. Session management makes perfect sense as defense in depth for data loss not least of which because hardware failure, power loss, battery exhaustion happen but this isn't even remotely a defense against gnome's unreliable software design where features available in other environments as options require monkey patching gnome's javascript desktop wherein any addon up to and including a hokey little weather widget can somehow destroy the entire session because the underlying javascript changed between X.n and X.n+1. For practical purposes such crashes can cause the loss of user data and punting responsibility to user apps is absolutely ridiculous.

michaelmrose 5y ago

This is the weird mismatch between compiled and javascript code from your own link which I am familiar with however I do thank you for linking it here as I shall substantiate my argument based on your own link. >-------------------------------------------------------------- Here’s the problem: C objects don’t track who owns them; instead, they only track how many owners they have. This is the traditional reference counting mechanism, and it works fine in C land because C is not garbage collected. To the garbage collector, however, the C objects would look like this: The garbage collector has no means to know the relationships between C objects. The garbage collector, then, will go there and destroy the root one. This object will be finalized, and the directly dependent objects will be marked for garbage collection. Only the directly dependent objects are marked for the next garbage collection. The “solution” is basically throwing a grenade to kill ants. We now queue a garbage collection every time an object is marked for destruction. So every single time an object becomes red, as in the example, we queue a GC. This is, of course, a very aggressive solution. But it is not all bad. Some early tests shows that this has a small impact on performance – at least, it’s much smaller than what we were expecting. >-------------------------------------------------------------- This is basically garbage engineering that shouldn't have made it out of the design stage let alone been knocking over systems for 8 years. Moving on. In essence a substantial chunk of the Linux desktop crowd feels like gnome is crap and has correctly understood that they aren't welcome to fix it because project owners have a very opinionated vision on how the Linux desktop works. This is probably why 60% of Linux Desktop users don't use it. https://linux-hardware.org/?view=os_de https://linux-hardware.org/?view=os_de If Pop!_OS succeeds in replacing it and Ubuntu ends up adopting it will probably drop from 40% of users to closer to 5%. It would be in serious danger of irrelevancy at that point if it weren't Red Hats baby. You are welcome to your own opinion on the utility of the gnome desktop but the idea expressed by the grand parent post that the Linux desktop space ought to just settle on a singular environment that cannot even convince the majority of users to use it despite having more corporate money spent on it in a year than other environments in history seems ill founded. Edit: > the apps themselves are supposed to implement session management to insure against any system crash Well designed software environments don't crash in a way that causes the underlying OS or end user applications to die. One time in a decade would be one time too many. Session management makes perfect sense as defense in depth for data loss not least of which because hardware failure, power loss, battery exhaustion happen but this isn't even remotely a defense against gnome's unreliable software design where features available in other environments as options require monkey patching gnome's javascript desktop wherein any addon up to and including a hokey little weather widget can somehow destroy the entire session because the underlying javascript changed between X.n and X.n+1. For practical purposes such crashes can cause the loss of user data and punting responsibility to user apps is absolutely ridiculous.