5 ms·
Yes, and? The difficulty of this is overstated. Except maybe that library thing, but my general guiding principle is to use as few dependencies as possible alre
by AnIdiotOnTheNet 4y ago
Yes, and? The difficulty of this is overstated. Except maybe that library thing, but my general guiding principle is to use as few dependencies as possible already anyway so that mitigates it somewhat.
If there are some situations where there is no logical course of action? Then yeah, crash I guess. Assuming your software isn't responsible for people's lives. It's still better than the OS randomly killing you because some other program fucked up.
I mean this is just crazy. The OS lies to you about memory, you ignore it anyway since it always lies to you, and then we randomly kill programs when we're out of memory. This is not a reasonable way to do things.
The problem, as I see it, is that by now programmers are so used to not paying attention to memory (or any other resource in most cases) that there's a ton of inertia behind the "nothing can be done" sentiment.
- tinus_hn 4y agoI suggest you pick up a project and show us how easily this can be done.
- AnIdiotOnTheNet 4y agoLeave that aside for a sec. Are you honestly saying that because it isn't easy to do this, the best course of action is to make it impossible by lying to the program?
- tinus_hn 4y agoIf it bothers you, you can just turn off overcommit. It’s not hard: $ sysctl vm.overcommit_memory=2 # policy number 2 $ sysctl vm.overcommit_ratio=0 # ratio = 0% So here’s your golden opportunity to show us how easy it is to program against that! I didn’t claim that it is not easy. I claimed that it is practically impossible. You claimed it was easy. So please, prove me wrong and just show us how easy it is.
- AnIdiotOnTheNet 4y agoThat's for the entire system though. If this behavior is default because programs suck at dealing with memory then that will definitely cause problems, right? That's why we're in this shitpickle to begin with. Obvious solution is obvious: opt in to no-overcommit behavior on a per-program basis and exempt programs that opt-in from being OOM killed. > I claimed that it is practically impossible. Suddenly it makes sense why modern software is such unreliable slow garbage. You don't by chance work for Microsoft on the Windows Terminal team do you? If this is so impossible, why would so many other OSs actually correctly not-lie to the program about memory allocation failure? > So here’s your golden opportunity to show us how easy it is to program against that! Alright, what would you like me to program for you for free and how long are you going to give me[0], because the vast majority of code I write doesn't even have to allocate at all. Even the stuff that does just does the obvious thing when it can't allocate what it needs: tell the user it can't allocate what it needs and exit as gracefully as possible. Even that is impossible on an OS that fucking lies to you. [0] No, I'm not going to actually do it. This whole tactic is predicated on the idea that it is more work than someone is willing to go through to prove a point on the internet, you know that, that's why you went there.
- tinus_hn 4y agoSo, 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 agoHe has spoken.
- 4y ago