If your adversary has the resources of a nation state, you've got much bigger problems to worry about than application updates.

To exploit the self-update process, an attacker would have to do at least the following:

• intercept the update check, possibly by capturing the domain serving update meta-data (adobe.com for example) or via a MITM
• forge a malicious application which will be accepted by the self update feature and installed over the old application

Both are definitely possible. The second becomes almost impossible if the original application vendor enforces digital signature verification on update bundles before installing them.

This doesn't really apply on most GNU/Linux systems though, where application updates are performed through the package manager. You may trust that your updated application is not infected because:

• the updates are served by the same people who made your OS
• digital signatures are verified on downloaded packages before installation

I haven't read the article, so I'm responding to the title, not it's actual content. While it is true that one can learn to code without being good at math, every coder uses math and the discipline associated with it. Modeling real world objects and abstract concepts eventually involves describing them with numbers.

If those are the only choices: Python. If you're willing to consider other options, Ruby

arbitrary code execution with privilege escalation

• Spend more time coding and less time networking. You have time for Voat? You aren't maximizing your programming potential.
• No matter the language, no matter the project, the more you code the more you learn and the better you become as a result.
• Be very accepting of qualified opinions. In other words, don't let your project be guided by jerk offs on Twitter who've never worked on a project of note.
• The famous programmers you idolize: Most of them are not as great as you think, and some of them are downright despicable human beings. I'm not naming names.
• No matter what anyone else says about your project, language, technique, just keep coding.
• Your program sucks for the same reasons all software sucks. Commit long term to improving your code, and your program may come to suck less than others.

And me? I've never worked on a project of note. Despite programming since 1983, learning a dozen languages, and going back to school in the 2000s, I never got a programming job or found success. Mostly because I didn't know then the things I just told you above.

Good luck and thanks for reading my rant.

You really are a programmer, aren't you. Thanks for reminding me of some reasons to hate C.

You probably don't to, but you could grab an emulator for your favorite 1980s home micro and teach yourself assembly language.

• http://vice-emu.sourceforge.net/
• https://www.c64-wiki.com/index.php/Assembler

This is no joke: https://en.wikipedia.org/wiki/Master/slave_%28technology%29#Appropriateness_of_usage

Reminds me of David Crane's Pitfall Classic Postmortem. Of particular interest is the fact that the Atari 2600 had only 128 bytes of RAM memory. That's half a 6502 page, so you don't even have room for a stack, much less any kind of bloat. Forget fancy high level languages, you're writing in 6502 assembly at best. This is the realm of hand coded machine language where you exploit every possible aspect of the hardware to avoid having to add another byte or cycle to your code.