Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
MP All Models What is stopping you from using Windows?
- Thread starter Konvictz
- Start date
- Sort by reaction score
We have 1.5TB of RAM available now, who needs paging!
[automerge]1576701553[/automerge]
But an OS can handle resource constrained situations more or less gracefully depending upon how well their scheduler works. I have no idea if MacOS or Windows do that better or worse or equally good/bad though.
That would depend on the extent of the resource constraint(s). The situation that was described for Linux suggested to me a severe shortage of memory ("filling up all useable RAM"). Use up all the RAM in any operating system, including macOS, and you're going to encounter problems up to and possibly including failure. The solution isn't to use another OS, the solution is to upgrade the system where the resources are no longer under such constraints.
This conversation prompted me to do some thinking, and realize that MacOS is the only OS I've never had to mess with the paging/swapping. It just works.
[automerge]1576702564[/automerge]
I regularly "fill up all useable RAM" many times over and my machine doesn't fail. On a properly tuned operating system, an application may thrash due to memory constraints, but the operating system itself (and its ability to respond to user input) never should.
Sorry, I find this difficult to believe. If one uses all of the memory in a system let alone "many times over" the system isn't going to be responsive and likely to fall over. macOS included.
That's what paging/swapping was invented for. You may now furiously Google that (make sure you also do "thrashing") in order to attempt a reply that makes you sound like you know what you're talking about.
FreeBSD is also really good about remaining responsive even when paging. In my experience, Linux is mixed and sometimes it can get bad enough that you can't even reliably ssh into the machine without using key-based authentication (the timings for keyboard-interactive logins can be thwarted on an unresponsive system).
Windows is middle-of-the road. I remember back in the NT4.0 days there were tunables in the registry that gave you some control over this, presumably those knobs still exist in some form with modern Windows. Back when I cared, NT Server was tuned so that interactive use suffered a lot more and NT Workstation was tuned to preserve more interactive performance when the system was truly slagged. Makes sense, I guess. Priorities for a workstation compared to a server aren't really the same.
Back then I was managing a flotilla of MS SQL Server boxes and didn't really care much at all how responsive the GUI was when things got bad.
They had a GUI? Wow, I've never had a DB server that had a GUI. Nowadays we don't even get SSH, it's failover and do post mortem rather than attempt anything with a live system.
Paging is not intended to be a substitute for exhausted memory situations. As for knowing about memory I know memory concepts really well so no need to Google.
It helps with low memory situations where inactive or lightly used pages, for example those assigned to a program which is idle in the background, can be swapped out to secondary storage freeing said memory for active pages in use by active programs. It is not intended to be a substitute to hold active pages which are being forced out of RAM due to memory exhaustion.
Very good! Now, wouldn't you say it would be a desirable situation that if an app reached the point of thrashing that the operating system shouldn't allow it to hose the entire system? That it should remain responsive so that the user can quite possibly adjust in order to get out of the thrashing?
Besides, some operating systems are better than others in preventing thrashing in the first place. As the saying goes, "There are only two hard problems in computer science, caching, naming things, and counting," and paging/swapping is an instance of caching. More sophisticated algorithms can deal better with situations where the working set is a modest amount larger than physical memory without ending up totally hosed.
Yes but the OS shouldn't be put in that situation in the first place. Last thing you want is an OS doing a "kill -9" on apps, especially things like databases and other things where it could lead to a lengthy recovery process.
Many OS's will try to fix the situation. Linux has the OOM killer that will take an educated guess. By the time the OOM killer comes into play your system is pretty much on life support at that time. In my many years of admining Linux I've never seen a box stay up for long after the OOM killer runs. It will stay up but usually some critical process for an app gets killed and you end up either restarting (to free up memory and swap) or it continues and crashes on its own.
I would need proof of this statement. Linux is highly regarded in how it handles memory and this is the first time I've ever heard anyone say it becomes completely unusable (i.e. your recommended solution is to turn off the system and restart) yet the same work sessions work effortlessly on macOS.
I use all three and I have never seen one become completely unusable while another performs the same task effortlessly. At least not on comparably equipped hardware.
The OS doesn't need to (and shouldn't!) kill processes, it needs to understand itself well enough to prevent pages critical to maintaining responsiveness from getting paged out. This is understandably hard to do on a system where you have all kinds of third party stuff sticking its nose in (especially where even the GUI is third party!). Assuming this is an interactive box with a user using a GUI, then the user has a fighting chance to save the situation. If it's not, like a database server, then you hopefully have software structured well enough that the main control thread can respond to a -HUP and exit gracefully even when the other threads may be thrashing.
Obviously if the user is running into this situation often, then they want to fix the problem with more memory. Maybe it's just the user needs to kill Spotify/Pandora running in the background when things get tight. But if it's only occasional, then an OS that can help you out is a godsend to finishing a project that might end up with unacceptable delays otherwise.
I have systems with 2 TiB of RAM, and 4 TiB pagefiles on RAID-0 arrays of five
NVMe drives. The pagefiles get lots of use!
Si tu parle
By default I'm not aware of any general purpose operating system (which I'll define as Windows, macOS, and your typical consumer distribution of Linux) which prohibits a process from consuming all of a systems resources.
I find it very difficult to believe that, given the same level of hardware specs, an task on one operating system completely falls over while the other works effortlessly. Especially when the one falling over is Linux, an operating system held up as one of the more stable and performant general purpose operating systems. I would need to see it to believe it.
You’re welcome to come and pay us a visit here in Japan. Be happy to serve you some humble pie. You look famished.
Feel free to ignore other users experiences though (as I’m sure you will). But remember that your experience, no matter how extensive it may or may not be, doesn’t cover all scenarios. You too can be wrong, and in this case you unfortunately are.
I'm willing to accept that, so provide more details and help me to understand.You’re welcome to come and pay us a visit here in Japan. Be happy to serve you some humble pie. You look famished.
Feel free to ignore other users experiences though (as I’m sure you will). But remember that your experience, no matter how extensive it may or may not be, doesn’t cover all scenarios. You too can be wrong, and in this case you unfortunately are.
OS's don't generally kill processes. I'm most familiar with Linux and it's OOM Killer. Once the system runs out of memory (RAM+Swap) it will use an algorithm to decide which processes to kill to keep the system going. I forget the exact algorithm but it usually leaves the critical system processes alone until the end. I've SSH'ed into a system in that state. The console is almost always available.
Problem is the OS has to know what is critical and what is not. What happens if, say a bug in a user mode app like the window manager is the culprit? Do you kill it? The system would then be unusable for many, especially in the case of OS X.
The good news is with SSD's even thrashing is usually recoverable. If not it will kill your SSD.
True. Memory leaks can affect all OS's.
I can believe it if the code is poorly written for one OS. OS X ships with a lot of stuff for graphics, audio, etc built in where as Linux it has to be written or leverage another library which could be buggy. Just because they are both UNIX doesn't mean the codebase for the apps is the same.
That being said Linux usually takes a lot of abuse before it falls over. And when it does, 9 times out of 10 you can recover.
What do you think they did back in the days of mainframes and minis that might be hosting hundreds of users? The OS isn't supposed to let one user's processes bring the entire system down. Even on a system with one user, the OS can keep apps from trampling all over each other, as resource allocation is the job of an OS. Do they not teach Operating Systems as a class to CS majors anymore?
Out of curiosity, I looked up how MacOS does swapping. Swap is dynamically allocated on disk until disk space is exhausted or the kernel page table is full (usually disk space is exhausted first). At that point, a window will pop up to inform the user that memory is full, and ask them which app(s) to kill. The system has tightly preserved the ability to keep the user in the loop.
Now the last time I had to deal with swap on Windows or Linux, they used fixed size swap files (or even swap partitions), which is why I was manually having to mess with it, and why I've never had to deal with it on MacOS. Now I can possibly see situations where the MacOS way of doing it could be bad, but I've personally never run into them.
This is the crux of it.
For me, i'm willing to deal with the Linux foibles because just as Apple do not seem willing to sell me hardware that doesn't suck for an acceptable price, Microsoft appear unwilling to sell me software that isn't essentially malware at any price (unless i'm willing to start a business large enough for an enterprise software agreement).
I understand if your software won't run on Linux, but i'd seriously suggest giving it a try if Microsoft is annoying.
UI wise, Linux is actually better than Windows 10 in 2019 in my opinion. It certainly changes less from release to release and performance is generally a lot better - and no mandatory telemetry from a vendor who is randomly deciding to put ads in your applications with a security/feature update. Assuming your application will work.
Linux may not be perfect, and it may be a little more work, but it is free both in terms of price and privacy controls.
[automerge]1576736805[/automerge]
People disabled windows updates because they have a well documented history of breaking stuff. People are STILL disabling Windows update (in more permanent ways under Windows 10) because Microsoft is still breaking stuff.
Just in the past two months (I work in a sysadmin capacity at #dayjob) i have had to deal with updates that broke critical business application functionality in an Office 2016 update.
If microsoft made the windows update process as seamless as it is in macOS (e.g., leave documents and applications as they were after a re-start) i doubt people would have an issue with it. Now? You leave a windows box unattended and good luck if your work is still there tomorrow. Never mind if you were running a rendering job/export/etc. over night.
Last edited:
Here's what's stopping me. It has become rather easy to build a sustainable vanilla OS hackintosh with working updates as long as you know what you're doing, avoid tonymac and don't jump onto the latest OS update on day one, but wait until the dust has settled (which seems to be appropriate anyway).