4 ms·

> "Use it if you've got it, give it back if you're running low". > You just need to make sure that "full" can be adjusted to make space for whatever applicatio

> "Use it if you've got it, give it back if you're running low". > You just need to make sure that "full" can be adjusted to make space for whatever application you might want to open next. > full disclosure, I can't speak for how well this is adopted This is the issue I'm highlighting. This is what everyone tries - engineers are one of the most vulnerable breeds to overestimating their ability to achieve an ideal plan. It rarely if ever works perfectly, and very often works sub-optimally to the point of significantly hampering overall system performance. I don't know that Gnome abjectly fails in this goal, but I do know that it's not fast. It's significantly slower than other projects with comparatively much less engineering resources behind them. For some reason. > It's not being "wasted" it's resulting in faster IO for anything that happens to be in it. Given the choice of having your RAM full or empty... you should pick full every time. This is absolutely wrong, because you're basing this all on the assumption that if it's not in RAM it'll be loaded from disk. In other words, the assumption that "it" needs to exist in the first place (&/or needs to be the size that it is). This is really disingenuous: when people talk about RAM-hungry apps and wastage they're never targeting optimistic IO (good) they're targeting large unnecessary data being accessed at all. Good low-RAM apps don't load excessively from disk. They use less data. They have more efficient raw resource handling & execution paths in the first place. An emphasis on engineering systems that effectively & efficiently release RAM when needed elsewhere focuses person-hours on improving (very complex) pieces of logic that wouldn't be as necessary if said person-hours were instead focused on making those resources being loaded smaller / less numerous.

horsawlarway 4y ago
> They use less data. And generally they do that by offering fewer features (and yes - aesthetics and ergonomics are features!). By the time I'm installing Gnome/KDE... I've already picked a heavy DE - I want it to be extensible (js/css in gnome is pretty great), pretty, and fast on a modern machine. I'm not picking those DEs for a constrained environments. In those envs - I may well just skip the DE although, or go with something lighter like Sway. But when I have 32gb of RAM... I really would prefer the feature rich DEs continue to focus on features when the usage is ~6% of RAM (2/32's). The RAM is, all things considered, outrageously cheap compared to their dev team's time. When I want to conserve RAM... I'll pick a different tool.
- lucideer 4y ago
  > And generally they do that by offering fewer features (and yes - aesthetics and ergonomics are features!). XFCE has more features than modern Gnome. Aesthetics comes from GTK, which it uses. Ergonomics is better in Gnome, largely due to consistency, which I'd attribute to Gnome's development effort: more people to work on more coordinated behaviours across apps & integrations - XFCE borrows small parts of Gnome's work while also using a patchwork of other solutions from elsewhere; an approach which detracts from the UX. This is about engineer resourcing though, not engineering approach to performance. The latter is an independent variable. There's nothing "heavy" about Gnome aesthetically of feature-wise except the general inefficiency of its implementations. Especially feature-wise in its latest incarnations: ever since the Unity/Shell split &c., the Gnome featureset as contracted significantly from what it once was. > I want it to be extensible (js/css in gnome is pretty great) What's great about it specifically? It's unrealised potential? Gnome's extensibility is a graveyard. The pace of API changes (another code smell when it comes to engineering approach), compared to the tiny level of community contribution of Shell extensions means most of those available for download are broken. Those that work are minimal / have inconsistent UX / no docs. If you've got to write your own code to customise the thing anyway, why not just use a more esoteric highly-customisable DE in the first place?
  - horsawlarway 4y ago
    You know it's ok to just say you don't like Gnome. I'm not going to judge. I think the 2gb it eats are essentially trivial costs to pay compared to the functionality you get (easily comparable to modern windows/macOS) given the costs of those alternatives. I'm on my work mac right now, and it's using 26gb of ram right now (mostly dev related) - but at least 4gb of which is for non-application usage... to count: windowServer is 1.3 softwareupdated is 1.2 softwareUpdateNotificationManager/Finder/systemSoundserverd are another 1 misc services are about .72 Basically - you can complain about how inefficient Gnome is all day - I'm telling you that it DOES NOT CHANGE THE VALUE PROPOSITION. It's plenty efficient for what it does. Please use the RAM - keep focused on features.

horsawlarway 4y ago

> They use less data. And generally they do that by offering fewer features (and yes - aesthetics and ergonomics are features!). By the time I'm installing Gnome/KDE... I've already picked a heavy DE - I want it to be extensible (js/css in gnome is pretty great), pretty, and fast on a modern machine. I'm not picking those DEs for a constrained environments. In those envs - I may well just skip the DE although, or go with something lighter like Sway. But when I have 32gb of RAM... I really would prefer the feature rich DEs continue to focus on features when the usage is ~6% of RAM (2/32's). The RAM is, all things considered, outrageously cheap compared to their dev team's time. When I want to conserve RAM... I'll pick a different tool.

lucideer 4y ago
> And generally they do that by offering fewer features (and yes - aesthetics and ergonomics are features!). XFCE has more features than modern Gnome. Aesthetics comes from GTK, which it uses. Ergonomics is better in Gnome, largely due to consistency, which I'd attribute to Gnome's development effort: more people to work on more coordinated behaviours across apps & integrations - XFCE borrows small parts of Gnome's work while also using a patchwork of other solutions from elsewhere; an approach which detracts from the UX. This is about engineer resourcing though, not engineering approach to performance. The latter is an independent variable. There's nothing "heavy" about Gnome aesthetically of feature-wise except the general inefficiency of its implementations. Especially feature-wise in its latest incarnations: ever since the Unity/Shell split &c., the Gnome featureset as contracted significantly from what it once was. > I want it to be extensible (js/css in gnome is pretty great) What's great about it specifically? It's unrealised potential? Gnome's extensibility is a graveyard. The pace of API changes (another code smell when it comes to engineering approach), compared to the tiny level of community contribution of Shell extensions means most of those available for download are broken. Those that work are minimal / have inconsistent UX / no docs. If you've got to write your own code to customise the thing anyway, why not just use a more esoteric highly-customisable DE in the first place?
- horsawlarway 4y ago
  You know it's ok to just say you don't like Gnome. I'm not going to judge. I think the 2gb it eats are essentially trivial costs to pay compared to the functionality you get (easily comparable to modern windows/macOS) given the costs of those alternatives. I'm on my work mac right now, and it's using 26gb of ram right now (mostly dev related) - but at least 4gb of which is for non-application usage... to count: windowServer is 1.3 softwareupdated is 1.2 softwareUpdateNotificationManager/Finder/systemSoundserverd are another 1 misc services are about .72 Basically - you can complain about how inefficient Gnome is all day - I'm telling you that it DOES NOT CHANGE THE VALUE PROPOSITION. It's plenty efficient for what it does. Please use the RAM - keep focused on features.