> with cloud-synced web apps this is also not a problem. A lot of Linux users really seem to hate using cloud services though, for those users it's apparent tha

> with cloud-synced web apps this is also not a problem. A lot of Linux users really seem to hate using cloud services though, for those users it's apparent that avoiding data loss is an exercise in self-flagellation. This is where the entire dialog not only jumped the shark but blew it up while screaming Yippee Ki Yay. When the complaint is that a system is unreliable the solution isn't to pair an inherently unstable system with cloud synced web apps its not run software that doesn't randomly shit the bed. For example fire up a KDE x11 session and simulate crashing software by shooting its window manager kwin_x11 in the face and marvel at the fact that the window manager died but your applications did not. One can return to normal by explicitly calling kwin_x11 or even a different window manager like compiz and continuing like normal. I3wm doesn't have the same trick being only a wm but its also literally 1/10th of 1% as much code as the totality of the gnome project and it isn't monkey patched as the user is running it. That is to say other people handle the issue by not randomly shitting the bed knowing that the orthogonal issue of losing user space state and data is known to be imperfect. The designer of gnome can't fix literally every app in existence and thus ought to pessimistically act as if every failure will result in user data. > Well again, that's a nonsense comparison because none of those have a comparable addons system. An addon system that is literally used virtually entirely to add back options that were present in gnome 2 and are present in other systems. Users of x11 can pick and choose different bar/dock applications, window managers, compositors, selection of user space applications. They don't need to monkey patch a javascript process insofar as it doesn't materially improve the power of their environment. > The alternative is to load binary plugins into the display server which is even worse and has a higher risk of causing crashes and memory leaks. The actual alternative is just not to remove functionality that you need to monkey patch a javascript program to add back. > This again is more nonsense. No, you can't because the longer you wait the longer your GC pauses will be. The traditional methodology is to just not write such code in a language with a GC. There is no real good reason to write your desktop in JavaScript in the first place if performance of the GC is a factor. Not every technology is worth adopting.