4 ms·

Operating in a low memory environment is inherently about tradeoffs. Where is the blame? Maybe Firefox is too bloated or memory-inefficient. Maybe Mozilla did

by nwah1 4y ago

Operating in a low memory environment is inherently about tradeoffs. Where is the blame? Maybe Firefox is too bloated or memory-inefficient. Maybe Mozilla didn't understand Windows's memory management strategy until now. Or maybe Windows is too bloated and memory-inefficient. Or maybe the memory management tradeoffs were suboptimal. Or maybe nobody is to blame, and they are taking advantage of something in a novel way that allows them to squeeze more juice out of the same fruit than others.

narag 4y ago
Where is the blame? Not sure, but sound stopped working in VLC about one year ago and was restored this month at the same time that dropping files stopped working. Every time after a Windows update and with the same VLC version. I don't think Windows is too bloated or memory-inefficient, but I do believe that they're abusing the AV and "monitoring" stuff. It's a cat & mouse game, with me trying to disable crap and they re-enabling it with every update or simply making impossible to disable annoyances. Also I suspect they're trying to "fix" drivers that worked before the fixes.
- dr_zoidberg 4y ago
  > I don't think Windows is too bloated or memory-inefficient. You know I used to be on that boat up until very very recently. I have a 2019 HP Stream 10" with 32GB eMMC and soldered 4GB DDR4. Windows got it bricked on a botched update, so I installed Linux Mint to get it back up quickly. Not only is Linux using a lot less storage (which was always and issue with Windows Update), but the RAM usage is about 700MB without any applications running, and well under 4GB for most common uses. Sure, Chrome(ium) will eat a hefty chunk of it when you run it, between zram-config and some extra swap space, it handles things a lot better than Windows ever did. Antoher point of anecdata: shared libraries are actually shared a lot more between processes on Linux than on Windows. That tends to mean a lot less RAM usage on certain process. I know it's down to how they handle sharing things and that Windows takes the "safe" approach (pretty much what the article talks about!) but it ends up hitting memory a lot more than Linux and macOS.
  - nwah1 4y ago
    The safe approach to me is exactly their answer to the tradeoff question. Forcing the application developers to be cautious is just changing who needs to be safe, because reducing problems for your app while increasing overall system instability is still bumping up against the issue at hand. It is sort of like how someone might be upset with speed limits, but the people who set the speed limits aren't thinking about your particular desire to get to work today, but the overall flow of traffic and public safety needs. I realize linux still has out-of-memory handling and various safeguards in their memory management, but it is sort of like arguing whether to set the speed limit at 50 or 60. Nobody is actually right, it is just different preferences.
  - deleted 4y ago
    [deleted]
3pt14159 4y ago
Eh—the blame comes down to the swap. If the swap were allocated to the whole HD that wasn't used for actual files, then this hack wouldn't work. If the swap were leaner that it already is, this hack would be necessary in every program. If I had to point a finger at who is to blame, it's the Windows swap allocation team. Some combination of predictive analytics or even just a saner ratio of swap to free HD for an incoming file would fix this problem for most users most of the time. But computers are hard and people want to keep them running for days on end. I get that memory just slowly, slowly gets eaten up by all the zombie procs out there.
- adql 4y ago
  > If the swap were allocated to the whole HD that wasn't used for actual files, then this hack wouldn't work. Then the hack wouldn't be neccesary as they'd have far more committed space to waste
  - 3pt14159 4y ago
    Right. What I'm saying is that swap vs available HD is a tradeoff the OS should be making and it's probably going too far in the "have avail HD" side of the spectrum or at least not employing enough predictive analytics to figuring out the right balance for any given time.
dblohm7 4y ago
(Former Mozilla engineer who can speak Windows) > Maybe Mozilla didn't understand Windows's memory management strategy until now. That is part of it. A lot of FLOSS engineers come from a Linux background and tend to assume that the Linux way of doing things is the "normal" way. While I was there I had to explain to more than one developer that Windows doesn't have an OOM killer because the NT kernel doesn't overcommit.

by nwah1 4y ago

narag 4y ago

Where is the blame? Not sure, but sound stopped working in VLC about one year ago and was restored this month at the same time that dropping files stopped working. Every time after a Windows update and with the same VLC version. I don't think Windows is too bloated or memory-inefficient, but I do believe that they're abusing the AV and "monitoring" stuff. It's a cat & mouse game, with me trying to disable crap and they re-enabling it with every update or simply making impossible to disable annoyances. Also I suspect they're trying to "fix" drivers that worked before the fixes.

dr_zoidberg 4y ago
> I don't think Windows is too bloated or memory-inefficient. You know I used to be on that boat up until very very recently. I have a 2019 HP Stream 10" with 32GB eMMC and soldered 4GB DDR4. Windows got it bricked on a botched update, so I installed Linux Mint to get it back up quickly. Not only is Linux using a lot less storage (which was always and issue with Windows Update), but the RAM usage is about 700MB without any applications running, and well under 4GB for most common uses. Sure, Chrome(ium) will eat a hefty chunk of it when you run it, between zram-config and some extra swap space, it handles things a lot better than Windows ever did. Antoher point of anecdata: shared libraries are actually shared a lot more between processes on Linux than on Windows. That tends to mean a lot less RAM usage on certain process. I know it's down to how they handle sharing things and that Windows takes the "safe" approach (pretty much what the article talks about!) but it ends up hitting memory a lot more than Linux and macOS.
- nwah1 4y ago
  The safe approach to me is exactly their answer to the tradeoff question. Forcing the application developers to be cautious is just changing who needs to be safe, because reducing problems for your app while increasing overall system instability is still bumping up against the issue at hand. It is sort of like how someone might be upset with speed limits, but the people who set the speed limits aren't thinking about your particular desire to get to work today, but the overall flow of traffic and public safety needs. I realize linux still has out-of-memory handling and various safeguards in their memory management, but it is sort of like arguing whether to set the speed limit at 50 or 60. Nobody is actually right, it is just different preferences.
- deleted 4y ago
  [deleted]

3pt14159 4y ago

Eh—the blame comes down to the swap. If the swap were allocated to the whole HD that wasn't used for actual files, then this hack wouldn't work. If the swap were leaner that it already is, this hack would be necessary in every program. If I had to point a finger at who is to blame, it's the Windows swap allocation team. Some combination of predictive analytics or even just a saner ratio of swap to free HD for an incoming file would fix this problem for most users most of the time. But computers are hard and people want to keep them running for days on end. I get that memory just slowly, slowly gets eaten up by all the zombie procs out there.

adql 4y ago
> If the swap were allocated to the whole HD that wasn't used for actual files, then this hack wouldn't work. Then the hack wouldn't be neccesary as they'd have far more committed space to waste
- 3pt14159 4y ago
  Right. What I'm saying is that swap vs available HD is a tradeoff the OS should be making and it's probably going too far in the "have avail HD" side of the spectrum or at least not employing enough predictive analytics to figuring out the right balance for any given time.

dblohm7 4y ago

(Former Mozilla engineer who can speak Windows) > Maybe Mozilla didn't understand Windows's memory management strategy until now. That is part of it. A lot of FLOSS engineers come from a Linux background and tend to assume that the Linux way of doing things is the "normal" way. While I was there I had to explain to more than one developer that Windows doesn't have an OOM killer because the NT kernel doesn't overcommit.