[djsumdog]

It's very different if you're a developer. Developers are almost always local admins, and unless you work for NASA, you're always going to be using 3rd party code. You simply cannot write everything (or even a fraction of) the things you need for basic applications in the current space. This isn't the 80s and we're not on Commodore64 machines and punch card systems.

[primitur]

Actually this 'very different' aspect is a broken piece of modern development - its a bug, not a feature. There are methodologies which could have caught this entire stack issue and nobody would have lost their jobs - its just that the ethics of "developer who has control over everything else, or else" versus that of "proper operations and support engineering management (i.e. fire burns upwards..)" are out of skew.

We've been putting up with live fixes and direct "developer"-"production system" style methodologies for a long time; only ethically. It just happens to be 'accepted practice' to fold some gargantuan code-base into ones own environment, without a line-for-line proper review. "Its impossible", say the bean counters. "Who would pay for that?"

Technically there is no good reason for the easter egg to have occurred, had someone done a proper code-review, observed full test reports, respected code-coverage rules and principles, and so on.

The easter egg proved that someone wasn't doing their job.

[djsumdog]

Really? So some team should have inspected the entire Linux or FreeBSD kernel they were running one? Someone should have gone line-by-line through nginx? What about all the shell commands used? They should have had people go line by line through bash, cat and all the other tools needed in the background to setup and environment, all their libraries, all their dependencies?

That's not even getting to a project. Have you looked at a projects node_modules, or the maven/jar dependences pulled in? Even for small projects, it grows to a very non-trivial amount very quickly. Inspect ever single jar and dependency?

Should people write their own web servers instead? Their own frameworks? Their own operating systems?

At some point you have to trust someone enough to actually get your work done. If an OSS project breaks that trust (like we've seen with some node modules) you stop using them, but inspecting every last dependency is often impractical.

[primitur]

> all their libraries, all their dependencies?

Well, you see ... I happen to think that you can use a lot of tools to cover your ass, and .. the fact that this one slipped in is as much a comment on the crud that is promulgating the wild and woolly Node/JS ecosystem as it is anything else. In point of fact, this kind of bollocks is why I eschew Node/JS and use other things [1], instead.

I do believe there are tools and ecosystems which make this sort of thing less likely. I can't recall a Linux easter egg .. nor a Golang one ..

>Should people write their own web servers instead? Their own frameworks? Their own operating systems?

One should at least, audit. As much as possible. It doesn't take much for a competent dev to 'grep -ir "easter egg $CODEBLASE' or, whatever .. not that its an expectation.

But yeah, if you have to have government-level 5-nines on all services, then I would say - fair play. The responsibility for an audit of such things should definitely have been in the requirements. I've seen such expectations for lesser projects, personally, where .. indeed .. code audit and ownership were tightly .. and properly .. managed.

[1] - I don't know for sure, but I think its harder to slip in such an easter egg on a production golang system. I guess I'll tune into that if/when it happens/has happened..