7 ms·

The author left off the part where it was invented by a mother and how dentists hate it! /s I suppose it technically improves stability, but the cause seems li

The author left off the part where it was invented by a mother and how dentists hate it! /s I suppose it technically improves stability, but the cause seems like a flaw in the Windows operating system, if I'm understanding correctly. > Stalling the main process led to a smaller increase in tab crashes – which are also unpleasant for the user even if not nearly as annoying as a full browser crash – so we’re cutting those down too. I wonder if this has anything to do with my recent experience with Firefox Nightly on macOS. In the last few weeks I started to experience spontaneous tab crashes that couldn't be explained by anything from what I could tell. I could open a new tab with the exact same page and it would manage to not crash. Then I noticed Firefox would sometimes prevent me from viewing tabs until I restarted to update the software. Haven't seen it in the last few days, but it was incredibly frustrating. IMO, Firefox should make a best effort to render a page and not have its core functionality stop working entirely until updating.

deleted 4y ago
[deleted]
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.
Brian_K_White 4y ago
That update behavior where ff is still running and existing tabs mostly keep working, but new tabs don't, has been a thing for years and everyone hates it, not just you or me. I thought it was possibly related to ff on ubuntu switching to being a snap by default (even though I thought I had forced my system to have no snaps and no snapd and added a special ppa for ff) and said something in a comment on hn, and several people clued me in it's way older than that and I'm not the only one who hates it. It's like ff devs don't actually use browsers, which is crazy of course. But, they really are ok with always having to blow away everything ypu have going at any random time middle of the day? (it's always someone's middle of their day or stretch of involved work) They never have tabs open with partially filled forms or search results or web apps that "restore tabs" won't restore the way they were? Or this just doesn't bother them? It feels like a case of "you're holding it wrong", as in the user should shape their usage pattern around ff's update strategy, like, always do and apt upgrade before sitting down, and never after starting to work, and if you leave tabs and work open over night, well I guess just don't do that?
- aftbit 4y ago
  I run Arch and upgrade ~weekly, but I am very rarely inconvenienced by this restart behavior. Restore Tabs works pretty well on the modern web, and since old tabs still work, you can always complete whatever outstanding forms you have first.
  - nyanpasu64 4y ago
    Problem is when you click a link or enter a URL, restarting your browser restores the previous page from before you had triggered the restart prompt, discarding the page you were trying to open.
  - Brian_K_White 4y ago
    No, I can't complete the in-progress forms, because it requires doing research in other tabs.
- michaelt 4y ago
  > But, they really are ok with always having to blow away everything ypu have going at any random time middle of the day? Y'all don't get your tabs restored when you restart your browser? For me, the restart experience pre-snap was very easy - close, re-open, and you're right back. Most 'serious' webapps will happily save your drafts if, for whatever reason, you don't want to finish and send that half-composed slack message before restarting. It got much worse with the switch to snaps.
dblohm7 4y ago
> I suppose it technically improves stability, but the cause seems like a flaw in the Windows operating system, if I'm understanding correctly. It's not a flaw at all, when you understand what is going on. Part of the issue is that in 2022 so many developers come from Linux backgrounds that they assume that the Linux way of doing things is the "normal" or "correct" way. The NT kernel does not overcommit, and thus does not have an OOM killer. If the kernel cannot commit pages, the system call fails. That's it. No process terminations. Firefox would crash because (even on Windows) it uses a customized version of jemalloc that is configured to be infallible by default. If jemalloc requests pages and those pages cannot be committed, the heap allocation will fail, and thus Firefox will self-terminate. That's simply a policy decision on Firefox's part. Going back to Windows: suppose that the commit request failed because the swap file was full. Assuming that Windows was configured to automatically resize the swap file, the OS will then grow the swap file. That's why pausing for a bit and then retrying the VM allocation works: the swap file was grown, and now the pages can be committed.
- ziml77 4y ago
  The Linux design to allow for overcommit is weird to me. Why would you not want to be up-front about the fact that you don't have enough memory available to hand over to a process? The process requested a certain amount of memory to be allocated so surely it expects to use it, no?
  - layer8 4y ago
    See https://unix.stackexchange.com/a/521737 https://unix.stackexchange.com/a/521737 for example.
    - dblohm7 4y ago
      That Stack Exchange answer is kind of weird in the sense that it conflates different things. You can have demand paging without overcommitting (as NT does); the kernel simply needs to assure that there is somewhere to commit a particular page, even if that page isn't committed yet.
bitwize 4y ago
A flaw in the Windows operating system? This is one of those many instances where Windows is doing absolutely the right thing and it's Linux that's screwed up.
- BlueTemplar 4y ago
  Why ?
  - mrob 4y ago
    Overcommit exists mostly because of fork(). fork() exists because it was the simplest possible process creation API the Unix designers could get away with, which was an important consideration on a PDP-7. Now that computers are far more capable, we no longer need to sacrifice the ability for applications to handle low memory conditions in a more useful way than crashing. Microsoft put out an interesting PDF paper about fork(): https://www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19.pdf https://www.microsoft.com/en-us/research/uploads/prod/2019/0... I do not use Windows myself, but this is one thing I think they got right.
    - wizeman 4y ago
      > Overcommit exists mostly because of fork(). Then why does Solaris support fork() yet it doesn't do overcommit nor have an OOM killer? And also has a long history of being a very robust OS. For more details, see my comment here: https://news.ycombinator.com/item?id=33708633 https://news.ycombinator.com/item?id=33708633
      - mrob 4y ago
        I suspect a reputation for robustness is at least partly a self-fulfilling prophecy. People who care about robustness will be more likely to write software for an OS they believe to be robust, and that software is also more likely to be robust. fork() + no overcommit + no OOM killer can work if you're very careful with allocations in processes that fork, but it would be a disaster on Linux. Willingness to put up with the drawbacks of Solaris is a good signal that you value robustness/stability very highly. IMO, most people developing for Linux have different priorities.

deleted 4y ago

[deleted]

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.

Brian_K_White 4y ago

That update behavior where ff is still running and existing tabs mostly keep working, but new tabs don't, has been a thing for years and everyone hates it, not just you or me. I thought it was possibly related to ff on ubuntu switching to being a snap by default (even though I thought I had forced my system to have no snaps and no snapd and added a special ppa for ff) and said something in a comment on hn, and several people clued me in it's way older than that and I'm not the only one who hates it. It's like ff devs don't actually use browsers, which is crazy of course. But, they really are ok with always having to blow away everything ypu have going at any random time middle of the day? (it's always someone's middle of their day or stretch of involved work) They never have tabs open with partially filled forms or search results or web apps that "restore tabs" won't restore the way they were? Or this just doesn't bother them? It feels like a case of "you're holding it wrong", as in the user should shape their usage pattern around ff's update strategy, like, always do and apt upgrade before sitting down, and never after starting to work, and if you leave tabs and work open over night, well I guess just don't do that?

aftbit 4y ago
I run Arch and upgrade ~weekly, but I am very rarely inconvenienced by this restart behavior. Restore Tabs works pretty well on the modern web, and since old tabs still work, you can always complete whatever outstanding forms you have first.
- nyanpasu64 4y ago
  Problem is when you click a link or enter a URL, restarting your browser restores the previous page from before you had triggered the restart prompt, discarding the page you were trying to open.
- Brian_K_White 4y ago
  No, I can't complete the in-progress forms, because it requires doing research in other tabs.
michaelt 4y ago
> But, they really are ok with always having to blow away everything ypu have going at any random time middle of the day? Y'all don't get your tabs restored when you restart your browser? For me, the restart experience pre-snap was very easy - close, re-open, and you're right back. Most 'serious' webapps will happily save your drafts if, for whatever reason, you don't want to finish and send that half-composed slack message before restarting. It got much worse with the switch to snaps.

dblohm7 4y ago

> I suppose it technically improves stability, but the cause seems like a flaw in the Windows operating system, if I'm understanding correctly. It's not a flaw at all, when you understand what is going on. Part of the issue is that in 2022 so many developers come from Linux backgrounds that they assume that the Linux way of doing things is the "normal" or "correct" way. The NT kernel does not overcommit, and thus does not have an OOM killer. If the kernel cannot commit pages, the system call fails. That's it. No process terminations. Firefox would crash because (even on Windows) it uses a customized version of jemalloc that is configured to be infallible by default. If jemalloc requests pages and those pages cannot be committed, the heap allocation will fail, and thus Firefox will self-terminate. That's simply a policy decision on Firefox's part. Going back to Windows: suppose that the commit request failed because the swap file was full. Assuming that Windows was configured to automatically resize the swap file, the OS will then grow the swap file. That's why pausing for a bit and then retrying the VM allocation works: the swap file was grown, and now the pages can be committed.

ziml77 4y ago
The Linux design to allow for overcommit is weird to me. Why would you not want to be up-front about the fact that you don't have enough memory available to hand over to a process? The process requested a certain amount of memory to be allocated so surely it expects to use it, no?
- layer8 4y ago
  See https://unix.stackexchange.com/a/521737 https://unix.stackexchange.com/a/521737 for example.
  - dblohm7 4y ago
    That Stack Exchange answer is kind of weird in the sense that it conflates different things. You can have demand paging without overcommitting (as NT does); the kernel simply needs to assure that there is somewhere to commit a particular page, even if that page isn't committed yet.

bitwize 4y ago

A flaw in the Windows operating system? This is one of those many instances where Windows is doing absolutely the right thing and it's Linux that's screwed up.

BlueTemplar 4y ago
Why ?
- mrob 4y ago
  Overcommit exists mostly because of fork(). fork() exists because it was the simplest possible process creation API the Unix designers could get away with, which was an important consideration on a PDP-7. Now that computers are far more capable, we no longer need to sacrifice the ability for applications to handle low memory conditions in a more useful way than crashing. Microsoft put out an interesting PDF paper about fork(): https://www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19.pdf https://www.microsoft.com/en-us/research/uploads/prod/2019/0... I do not use Windows myself, but this is one thing I think they got right.
  - wizeman 4y ago
    > Overcommit exists mostly because of fork(). Then why does Solaris support fork() yet it doesn't do overcommit nor have an OOM killer? And also has a long history of being a very robust OS. For more details, see my comment here: https://news.ycombinator.com/item?id=33708633 https://news.ycombinator.com/item?id=33708633
    - mrob 4y ago
      I suspect a reputation for robustness is at least partly a self-fulfilling prophecy. People who care about robustness will be more likely to write software for an OS they believe to be robust, and that software is also more likely to be robust. fork() + no overcommit + no OOM killer can work if you're very careful with allocations in processes that fork, but it would be a disaster on Linux. Willingness to put up with the drawbacks of Solaris is a good signal that you value robustness/stability very highly. IMO, most people developing for Linux have different priorities.