[Gormo]

If he has implemented mitigations for all of the applicable risks of the software he's using, how is that "not the behavior of a security expert".

To my mind, a security expert is someone who understands the functional details of specific vulnerabilities, and explains how to mitigate them, not someone who makes vague, cargo-culty judgments about entire applications or OSes.

[paulryanrogers]

He was browsing the web, that's pretty high risk. And sticking to reputable sites isn't enough when their ads could contain malware. While it sounds like he doesn't use XP anymore, (IIRC) he was using it for the Internet well beyond its EOL.

He also admitted to having trouble getting his dev environment working on newer OS's. My guess is he was rationalizing the choice to stick with XP to avoid the friction of upgrading development tools. Which is odd since he's not afraid to delay things for years and ultimately has upgraded his environments anyway.

[wolpoli]

Steve Gibsons was always a bit of a laggard in adopting things through. He was writing pages about how assembly languages create small programs in the late 90s when that advantage was no longer relevant, running a newsgroup server and hooking up a web UI as a web forum, and so on.

[naikrovek]

Considering final application size as well as CPU and RAM usage will always be important, whether people believe them to be or not.

I won’t ever go so far as to recommend that others write stuff in Assembly, but I’d love to be able to do that.

CPU and RAM will matter so long as users are billed by those metrics. More RAM will always be more expensive than less RAM, and faster CPUs will always be more expensive than slower CPUs. If you write software that is used as scale, I would consider it a moral failing if you do not consider how many resources your application uses at scale and you do not make some effort to increase the efficiency of your application in some way.

Accordingly, I have almost zero respect for JavaScript developers, especially server-side JavaScript developers. Server-side JavaScript developers know that JS is inefficient and they choose to use it, anyway. How much coal has been burned exclusively to allow JavaScript developers to run Node on the server, instead of some other, more efficient language? A LOT, I guarantee it.

Performance and efficiency matter a lot at scale. At the small scale, no user has ever complained that their application was too fast or that it didn’t use enough RAM.

When you invoke a Lambda trillions of times per year, every last byte of RAM and every millisecond of CPU time matters. My employer has a few Lambdas which are invoked tens of trillions of times per year, and we saved a lot of money moving from Python to compiled languages. We’d save a lot more if we knew how to write assembly.

[TeeMassive]

> especially server-side JavaScript developers. Server-side JavaScript developers know that JS is inefficient and they choose to use it

I'm in no way a JS fan, but this take is wrong. The main reason JS is on the server side is because it makes the transition between server side and client side trivial. Not everyone runs SAAS with billions of requests every seconds.

In terms of not only money and time, but also resources and energy spent, this increase in software productivity it is worth it in most cases.

[Gormo]

The advantage of writing code in assembly was relevant then, and remains relevant now.

Given the vast regressions in usability and compatibility of software generally that we've seen in the past 10-15 years, someone maintaining and extending the functionality of superior older technology is doing something unequivocally useful.