4 ms·

>Exiting unexpectedly should be a risk of battery exhaustion, users closing without saving, hardware failure, or power loss. Yes but all of these things still

>Exiting unexpectedly should be a risk of battery exhaustion, users closing without saving, hardware failure, or power loss. Yes but all of these things still happen anywhere and the apps themselves are the only place that can be fully prepared for that, 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. >The idea of your desktop session just crashing out just shouldn't happen and indeed doesn't happen with i3wm KDE or windows. Well again, that's a nonsense comparison because none of those have a comparable addons system. >The fact that extensions can crash is unremarkable the fact that they can crash the session itself is extraordinary. A windows 95 level of bad. No not really. You seem to think the alternative here to monkey patching is a system that doesn't crash. It's not. 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. >User: gnome lacks functionality Gnomie: but it has powerful extensions User: gnome extensions can crash the session! Gnomie: You don't have to use extensions! I've not seen anyone here saying that, I'm certainly not saying it. I wish you didn't ignore the part where I said to just fix the crashes in the extensions. I also wish you wouldn't turn this into a conversation with hypothetical users. You're talking to a real person here. >You either have to deal with potentially unstable extensions or limited functionality. Neither is particularly reasonable. Yes, welcome to engineering. It's the art of being forced to decide between two bad solutions because you don't have enough time to do it right. If you have a lot of spare time then I suggest you volunteer your time to do it, and figure out how to do it in a way that benefits everybody (not just gnome). >Characterization of the indefinite and indeterminant lifespan of objects as a normal part of gluing a compiled and garbage collected language is simply normalizing pathology. It seems painfully obvious that the dependency relationship expressed in the JavaScript should be mirrored in the c code allowing it to remove the garbage before the system falls over. This seems painfully obvious when the memory is allocated for an ephemeral purpose like a frame of animation. Can we not destroy everything related to frame n upon drawing it? This again is more nonsense. No, you can't because the longer you wait the longer your GC pauses will be. This is a problem with any stop-the-world generational GC and it's only made worse by plugging foreign objects into it. The solution would be of course to improve the GC (there are a lot of ways to do this) but then it becomes a mozjs problem. GNOME Shell is just a downstream and can't do anything about it. You're barking up the wrong tree here. Please just avoid talking about this unless you can propose a solution to the problem, if you can come up with something good that works everywhere and is easy to use then a lot of other projects will benefit from it. If you can't then this discussion will go nowhere. The most that could be said otherwise is "don't use GNOME" but I think it's safe to assume you were already doing that.

michaelmrose 5y ago
> 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.

michaelmrose 5y ago

> 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.