3 ms·

So, to the surprise of really no-one, you claim programmers have ‘learned helplessness’ because they can’t apply your easy solutions, but back down on the groun

So, to the surprise of really no-one, you claim programmers have ‘learned helplessness’ because they can’t apply your easy solutions, but back down on the ground when it’s time to demonstrate your superior abilities, it turns out to be all talk. You don’t need to go and write software for me, if your arguments are worth anything you would be able to demonstrate them using the software you already wrote as you gained the experience to back your handwaving claims. Clearly you didn’t do that (if you did you would have known your original claims were a bit shallow), you just show up on your high horse to talk down to others who do. All talk and no action.

worthless-trash 4y ago
He has spoken.
AnIdiotOnTheNet 4y ago
Or to put it another way, the only way you are able to defend the ludicrous idea that an OS should be lying to programs about their allocations is to claim it is impossible and get all demanding and pissy to the first person who comes by to contradict you. Which is ridiculous, because plenty of programs will stop and tell you they have run out of memory for an operation. It's the easy way to handle allocation failure you're so hell bent on me showing you. Here's one: https://knowledge.ni.com/servlet/rtaImage?eid=ka03q0000012W23&feoid=00N0Z00000HEWRk&refid=0EM0Z000000phNh https://knowledge.ni.com/servlet/rtaImage?eid=ka03q0000012W2... You can do that kind of thing when the OS doesn't lie to you. Depending on circumstances you can do other things. But hell, even if you think that's stupid and I'm stupid for saying that this is better than crashing, I still can't fathom why you think the status quo on Linux is the best possible idea. Hey, I know, let's pretend we can't run out of disk space either and just randomly delete files when the disk starts to fill up.
- tinus_hn 4y ago
  I never said any of these things, I said it is practically impossible to deal with not getting memory when you need it, which you claim but can’t show is easy. And then there’s a whole lot of rambling about operating systems which has nothing to do with it. If you do one huge allocation and it fails, yes it’s easy to handle that. But programs do tons of small allocations all the time and it’s impossible to handle if that fails. Do you think you can even show that fancy pop-up when you can’t allocate memory?
  - AnIdiotOnTheNet 4y ago
    I didn't say it was easy, I said the difficulty (nearly impossible, according to you) was overstated. I also said there are circumstances where there isn't really anything the program can reasonably do other than terminate. However, there are other things it can do in other circumstances. And the OS behavior has everything to do with it, that's the whole context of this discussion: Linux lying to programs about memory and having to deal with the consequences in a really dumb way. > But programs do tons of small allocations all the time Mine don't, at least they don't allocate a bunch of small shit from the OS all the time[0], that's slow. Again I suspect learned helplessness here: people have been doing it a certain way for so long they don't even consider alternatives. [0] Actually, come to think of it I don't think most malloc implementations do it differently.
    - isityouyesitsme 4y ago
      I think you are missing the point of an OOM kill. The intention is to keep the SYSTEM healthy, not any one application. Let me assure you, system-wide, this policy is sane. Do you have any idea what happens when the kernel is not able allocate when it needs to? Bad things. This is different from whether applications handle this reality well (by and large, they do not). You are 100% correct with this. As is the poster who says fixing it is next to impossible (given the wide amount of deployed, critical software). I think if you actually dive into this, you will find Windows does not handle this as gracefully as you want to believe it does. Everyone says "turn of overcommit" as if it is a general solution. This works only when you have tight control of what runs on the system, and it is tailored for a specific application or deployment that behaves well. And guess what? If this is you, then you already know how to disable overcommit in the kernel build for the custom OS you are building for your product. I will leave it as an exercise for the reader to determine if the policy of crashing the current process is a better strategy than what the OOM killer does (it favors to reap shorter-lived and larger-RSS processes). Linux is not Windows. People get upset when they first realize this. They want different defaults (nevermind that they can customize it however they want to, and it isn't as though this is some esoteric kernel topic buried in the lkml that should surprise anyone). If anything, I'd say that Linux needs easier ways to securely load a different set of code for running at OOM time.

worthless-trash 4y ago

He has spoken.

AnIdiotOnTheNet 4y ago

Or to put it another way, the only way you are able to defend the ludicrous idea that an OS should be lying to programs about their allocations is to claim it is impossible and get all demanding and pissy to the first person who comes by to contradict you. Which is ridiculous, because plenty of programs will stop and tell you they have run out of memory for an operation. It's the easy way to handle allocation failure you're so hell bent on me showing you. Here's one: https://knowledge.ni.com/servlet/rtaImage?eid=ka03q0000012W23&feoid=00N0Z00000HEWRk&refid=0EM0Z000000phNh https://knowledge.ni.com/servlet/rtaImage?eid=ka03q0000012W2... You can do that kind of thing when the OS doesn't lie to you. Depending on circumstances you can do other things. But hell, even if you think that's stupid and I'm stupid for saying that this is better than crashing, I still can't fathom why you think the status quo on Linux is the best possible idea. Hey, I know, let's pretend we can't run out of disk space either and just randomly delete files when the disk starts to fill up.

tinus_hn 4y ago
I never said any of these things, I said it is practically impossible to deal with not getting memory when you need it, which you claim but can’t show is easy. And then there’s a whole lot of rambling about operating systems which has nothing to do with it. If you do one huge allocation and it fails, yes it’s easy to handle that. But programs do tons of small allocations all the time and it’s impossible to handle if that fails. Do you think you can even show that fancy pop-up when you can’t allocate memory?
- AnIdiotOnTheNet 4y ago
  I didn't say it was easy, I said the difficulty (nearly impossible, according to you) was overstated. I also said there are circumstances where there isn't really anything the program can reasonably do other than terminate. However, there are other things it can do in other circumstances. And the OS behavior has everything to do with it, that's the whole context of this discussion: Linux lying to programs about memory and having to deal with the consequences in a really dumb way. > But programs do tons of small allocations all the time Mine don't, at least they don't allocate a bunch of small shit from the OS all the time[0], that's slow. Again I suspect learned helplessness here: people have been doing it a certain way for so long they don't even consider alternatives. [0] Actually, come to think of it I don't think most malloc implementations do it differently.
  - isityouyesitsme 4y ago
    I think you are missing the point of an OOM kill. The intention is to keep the SYSTEM healthy, not any one application. Let me assure you, system-wide, this policy is sane. Do you have any idea what happens when the kernel is not able allocate when it needs to? Bad things. This is different from whether applications handle this reality well (by and large, they do not). You are 100% correct with this. As is the poster who says fixing it is next to impossible (given the wide amount of deployed, critical software). I think if you actually dive into this, you will find Windows does not handle this as gracefully as you want to believe it does. Everyone says "turn of overcommit" as if it is a general solution. This works only when you have tight control of what runs on the system, and it is tailored for a specific application or deployment that behaves well. And guess what? If this is you, then you already know how to disable overcommit in the kernel build for the custom OS you are building for your product. I will leave it as an exercise for the reader to determine if the policy of crashing the current process is a better strategy than what the OOM killer does (it favors to reap shorter-lived and larger-RSS processes). Linux is not Windows. People get upset when they first realize this. They want different defaults (nevermind that they can customize it however they want to, and it isn't as though this is some esoteric kernel topic buried in the lkml that should surprise anyone). If anything, I'd say that Linux needs easier ways to securely load a different set of code for running at OOM time.