Windows file access performance compared to Linux

Re:Windows file access performance compared to Linux by rikkus on Saturday December 29, 2018 @02:09PM (#18785173)

This behaviour - and perhaps other causes with similar issues for desktop users, is what drove me away from helping to make Linux ‘ready for the desktop’. The kernel philosophy was incompatible with the needs of desktop users. Those developing for the desktop (like myself) didn’t have the required expertise to make the kernel do the Right a Thing, and couldn’t find enough people willing or able to help.

Things may have changed over the years - I’ve been running a Linux desktop recently and haven’t seen this kind of issue yet (the kind where you need to use magic keys to ask the kernel to kill all, sync and reboot) but reading your post, perhaps this is because RAM is much more plentiful these days.

[ Parent | on HN ]

Re:Windows file access performance compared to Linux by zanny on Saturday December 29, 2018 @05:53PM (#18786192)

Its probably the ram plentiful thing. I haven't looked recently into if the Arch mainline kernel kconfig is just bad or not but the oomkiller is trash for me. Used to have the "recommended" swap == ram size but then the memory manager never even tried to cull pages until it was OOM and froze up trying to swap constantly. Currently running a 16/4 spread and probably going to drop to 16/1 because any time I hit memory limits everything just freezes permanently rather than the oomkiller getting invoked. I've hit it twice this week trying to render in Kdenlive and run a debug build of Krita...

[ Parent | on HN ]