Let’s inventory other such jokes.

Google Annotation Gallery, annotations for things which shouldn’t have been coded: https://code.google.com/archive/p/gag/

VanillaJS, the most used JS library with famous users such as Google, Apache and even the NASA itself. http://vanilla-js.com/

FizzBuzzEnterpriseEdition, the correct Java implementation of the interview question: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

FizzBuzzEnterpriseEdition and its issues are fucking gold.

Also hello-world.rs

The quotes are excellent. As are the rockets everywhere.

“Because it’s typically typed, rust() catches errors at compile time. [...] Also, it compiles code down to machine learning, allowing for extra efficiency.”

You mean the the reaction to jndi logging RCE for log4j has been way too seriously?

What's the basis of this assessment?

Logging library fetching remote code and inject to local application runtime. Seems a pretty bad idea for any people with decent amount of programming experience, right?

Or I missed something.

People are mad that someone created a Go library mocking the (obviously terrible) log4j behavior. How dare you make fun of the hardworking log4j developers, or the programming community that accepted their outrageously overcomplicated library without question? They're trying their best!

Honestly, I'm a bit miffed. It's a damned if you do, damned if you don't scenario for OSS.

Don't add feature X that other log library might add or has added, your lib is bad. Add a feature X that other log library has, now you support it for the lifetime of universe. Oh and RCE might happen.

It all starts with little changes.

Allow us to show colors in console...

Allow us more formatting options...

We need to display remotely added class...

We need JNDI access...

> Oh and RCE might happen.

You added a feature that can load plugins and query any kind of data based on user provided strings, this is completely unexpected and never happened before. What to call it? How about SQL injection attack, sounds about fancy enough.

If you implement feature requests without thinking about the design and security implications it has you are doomed to repeat history.

Log4j maintainers didn't like the feature, they added it for backwards compatibility.

> Log4j maintainers have been working sleeplessly on mitigation measures; fixes, docs, CVE, replies to inquiries, etc. Yet nothing is stopping people to bash us, for work we aren't paid for, for a feature we all dislike yet needed to keep due to backward compatibility concerns.

It was added by these maintainers in 2.x and did not exist in 1.x. The maintainers are also different from 1.x developers and took the brand. They may regret their past decisions, but it was is irresponsible to claim that it was not their fault and added for backward compatibility.

There isn't a benefit to OSS projects all competing for the same audience and bloated feature set. Picking a subset, being opinionated about it and the implementation isn't wrong. For developers, there is such a thing as picking the right tool for the job, even if it isn't your favourite one you usually use.

As much as people moan about npm community, it does give you many choices and you can avoid complicated massive libs

...By adding thousands of libs, turning node_modules into a multi GB folder. Oh, and each of which can be compromised by an unscrupulous actor.

Good luck auditing that.

Like if any other thing with automatic package management is any better.

.m2/repository is 5 gb on my machine.

Rust crates?

Go packages that are neatly tucked away too?

Node just makes it visible and in your face by putting the node_modules in you project directory.

Besides, what’s the alternative? Write stuff yourself? Put stuff in language stdlib? Even minimal service requires _a lot_ of things to do minimal stuff.

I think at some point (like introducing the ability to fetch resources off a network in your logging library) you need to step back and say "let's put this in its own, optional extra module".

There are ways to manage this sort of stuff.

I'm sure the log4j developers have just as much potential as the code they're sort of maintaining.

If you let them into your codebase you get federated remote code updates for free.

Yeah I thought this was pretty funny. I AM trying to understand why people are so mad though.

Enterprise Java developers are scared to face the underlying human and cultural factors that led to such a massively boneheaded security vulnerability being possible.

Real Enterprise Java developer are probably still using log4j 1.x so are unaffected by the bug.

can confirm :D

Enterprise Java developers are ex-CORBA/DCOM/Smalltalk/Common Lisp developers actually, now busy building scalable Kubernetes clusters with Go to process CSV files with proper failover mechanisms.

LOL this one got an audible chuckle out of me

Ahaha. Unfortunately they are not. As in they don't care enough to fear or face it.