A RAM Edition of Dirty Coding Tricks

What's the point of having more memory if not for new features?

How much time and cost do most of the things I listed add? I mean really.

Building a 32 bit exe of a game that uses no 64 bit features, packing assets up to avoid FS chatter, loading lazily, closing up ports on an IoT appliance, not abusing NTP like TP-Link does, not pasting raw user input into an SQL query, having a dedicated security team that 24/7 monitors all tech deployed in the company for outdated versions of software?

These things are absolutely basic and most are one time efforts and others completely achievable. None of them require any degree of excellence. This is not about excellent code, this is technology 101. There are trade offs to be made like IDEs in Java vs. native ones on look and feel, features, start up speed, snappiness, etc. but there is no trade off in a situation where a program does less stuff, does it in a worse way and does it slower and taking more resources.

Look at amounts of money Equifax operates with and how touchy the information they handle is and try to tell me again with a straight face that what they did skimping on security and running outdated software was all okay because if they did better they'd be crushed by costs and competition into oblivion. And now there are already articles pointing at China with evidence as flimsy as "Chinese security blog reported the vulnerability day after it was patched by Apache and a week later Equifax got hacked".

Or explain to me what and why is TP-Link doing with it's repeaters querying NTP every 5 seconds (which actually takes more development effort to do than not doing anything would).

Or the recent failures of Apple, like password being stored in the hint field, that got deployed despite their (supposedly) stellar QA and polish that justifies the high price of their products.

This fail talk all reminds me of yet another crazy negligent story. There (and still is) an online shop in Poland that once was doing some "adjustments" on a world facing machine (that was supposedly not available from the internet due to high traffic causing the hosting provider to take it offline... I don't get it, the language and concept described is murky). Someone accidentally removed index.php (by renaming it to inedx.php), the web server had file listing enabled so what was shown was the webroot file listing and there was a textual backup of entire DB in it that had in it real names, phone numbers, delivery addresses, plaintext passwords and email addresses in it, it was of course accessible to the web server so all that separated you from data of 65 thousand people was a single click... The company of course bullshitted and gave 20% sale to everyone affected after lying for 4 days and saying they have "experts working on it"... They are also quoted as saying that "users agree that all their data is public when they sign up" (about real names, phone numbers, addresses, etc. despite the fact their terms and conditions said that all data is used only for order processing and never made available to anyone..) but it's murky and might have been a hoax. I'm not aware of anyone going to jail over this and the shop is evidently still open for business. Here's an article (I do not have an English one) if you're interested: https://niebezpiecznik.pl/post/kupiles-papierosa-przez-inter...

Tell me that stories like these are not absolutely surreal and that you'd never do as badly personally (I mean really - all it takes would be to try visit the website you just edited to see if it's okay and notice the file listing, lack of index.php, etc.). I'd not believe such a multi-layered fail story (file listing on, removing index.php, plaintext passwords, DB dump in web root and accessible, they way they didn't do responsible disclosure, etc.) if someone told me, it's too outlandish but it's also - evidently - true.

A university teacher would have crushed me into oblivion if for homework I submitted a web app vulnerable to SQL injections because "no one will guess to do that and it's illegal anyway" and that stored plaintext passwords as a "reminder feature". But I would just not submit something as bad in the first place, and as you can see I am not coy and can stand my ground if I think something right. But in real world both happen and then people scream China.

Even just recently someone had a laugh here in the comments under Mirai story about how it was considered (as always..) to have to been China, Russia, North Korea, etc. and then it turned out to just be few really smart Minecraft kids plus millions of devices with Swiss cheese security out in the world.

Duke Nukem Forever is a very special case of development hell, it doesn't exonerate games that don't even care. I have played games on my old laptop with no real GPU, including Unity3D ones, it's not the tool, it's how it's used. Today I can't play a 2D VN I paid for on an integrated Intel GPU and that's somehow okay.

I've already spend too much time replying to you and the "hurr durr we cna't all use cppluspluz!" gentleman/madam below. I won't be reading any more replies here, if I didn't convince you then nothing will (short of getting burned yourself by some company leaking your data in a dumb way - hopefully not).

I might. I'll inform you if I do but I generally try to avoid controversial topics like these.

My point is about game development in general, not one exact game. The fact that in general, you make a trade-off between performance and features doesn't excuse the fact that there are actually bad games made by bad developers out there - in fact, I usually work in legacy codebases and have seen many examples first-hand.

Yes, man, and kids don't understand or perceive software bloat at all ;(

I remember coding while listening to music and reading docs somewhere using a P166MXX with 32mb of ram, and that ran quite snappily using debian and fluxbox.

I now code while listening to music and reading docs somewhere using an i7 with 6GB of ram and sometimes I'm swapping because I left Google Chrome opened for too long :(