7 ms·
The difference is Linux has fork, while Windows doesn’t, so Linux cannot do accurate accounting (without wasting a lot of memory) while Windows can.
by manwe150 1mo ago
The difference is Linux has fork, while Windows doesn’t, so Linux cannot do accurate accounting (without wasting a lot of memory) while Windows can.
- coliveira 1mo agoThis is the best explanation, thanks.
- pjmlp 1mo agomacOS is a UNIX as well, and it isn't the only UNIX that manages to do accounting properly.
- hnlmorg 1mo agomacOS includes a GUI user land whereas Linux is just a kernel. So Apple can build a whole user-controlled GUI workflow around memory exceptions, which Linux cannot. Maybe what needs to happen is new Linux syscalls + signals for DEs to utilise for building memory exception UIs? But the problem then with that is you’re impacting the portability of those DEs. So some maintainers might still refuse to work with Linux to provide this. That all said, I’m pretty sure KDE does provide GUI tools for when this kind of scenario arises.
- pjmlp 1mo agoI mentioned they aren't the only UNIX where this isn't a problem. Also we cannot use the reasoning Linux means distributions, instead of using GNU/Linux for it, and other times Linux is just the kernel, depending on convenience.
- hnlmorg 1mo ago> I mentioned they aren't the only UNIX where this isn't a problem. You did. But without examples, it’s a meaningless throwaway. Personally, I can’t say I’ve pushed many other UNIX desktops that far that they’ve OOMed. Except maybe OpenSolaris and FreeBSD, neither of which faired much better. But they’d also suffer from the same kind of DE development issues I described for Linux. > Also we cannot use the reasoning Linux means distributions, instead of using GNU/Linux for it, and other times Linux is just the kernel, depending on convenience. I’m not saying it for convenience. I’m saying it because it matters in this specific situation. Surely you must understand that the reason Windows and macOS have arguably better GUI support for OOM is because the same company that owns the kernel also writes the frontend too? It’s hardly rocket science as a concept. As I said in my previous comment, there are ways Linux (the kernel) could work with DEs to bridge that gap. But at present, they’re entirely separate concerns.
- pjmlp 1mo agoWho says it needs to be desktop for proper memory management, servers and embedded can crash willy-nilly with OOM? In any case, Xenix, DG/UX, SunOS/Solaris, Aix, HP-UX, z/OS UNIX, NeXTSTEP.
- hnlmorg 1mo ago> Who says it needs to be desktop for proper memory management, servers and embedded can crash willy-nilly with OOM? The context of the thread is about the UX. And the OS crashing isn’t a better option than an OOM killer. Frankly, there’s no good automated options. That’s why modern desktop OSs present users with a warning. And hence why we are talking about GUIs. > In any case, Xenix, DG/UX, SunOS/Solaris, Aix, HP-UX, z/OS UNIX, NeXTSTEP. Listing OSs doesn’t explain how they handle things better. For example you’ve cited SunOS and I already said previously, I’ve seen SunOS completely die on its arse when OOM.
- Espressosaurus 1mo agoAllowing allocations to fail is a solution. Alas, not one that was made back in 1970, so here we are.
- hnlmorg 29d agoAllocations can and do fail in Linux. To be clear: I’m not trying to defend Linux here. Just calling out the GPs BS when he said Linux is uniquely bad in POSIX.