Odd. I know that FreeBSD vendors or did vendor jemalloc in-tree as their malloc implementation

IIRC automatic controls important pieces of infrastructure that made a fork very difficult, and they also sabotage people who attempted to fork

https://techcrunch.com/2025/01/11/matt-mullenweg-deactivates-wordpress-accounts-of-contributors-planning-a-fork/

Maybe?

I tend to think that they treated people shitty because they had no solution to questions that had already been answered, besides closing the question and marking it as duplicate. That the behavior of treating people like shit was a symptom, not the disease.

SO was incredible. I remember it very fondly circa 2011 thru 2013 while it was still growing and all the questions every thought of hadn’t been asked yet.

Obviously as time went on, the challenge of organizing and managing questions once a huge base of knowledge had accumulated, proved to be a much more difficult. I don’t think they ever solved that, and ended up rewarding toxic behavior.

It’s a shame.

I was going to say “Who?” until I looked at his bio, he helped start Django which I use. I need to go lay down.

But what about all those hours I spent torturing myself learning jq’s filter syntax, and jmespath ?

CVS would probably suffice…

CVS is awful. Even for local use.

Why use Git at all then?

Still need to version control the work. No editor’s undo buffer is a complete history of all changes

This might be unpopular because I’m an old head, when jQuery was a must because of IE6, but I would maybe start out learning vanilla Javascript first, at least a little bit, before diving into React, just so that you have more background about Javascript rather than just experience in a single framework. I’m not saying do an entire application in vanilla JS first, but maybe do a simple TODO app or something very small with Flask (or equivalent) and some light JS on the frontend.

I see you used Django recently, the one thing about Django’s Form classes and Views is that it does a lot of the heavy lifting around form processing for you. Its super super awesome and gets all that annoying shit out of the way so you can deal just with application logic, but it might be worth dropping down to Flask or Node or something else where you don’t have form processing and building done for you, and do vanilla JS with that.

Then again I hate javascript and do almost all server side rendering in Python or Zig so take what I say with a grain of salt.

I’ve been writing web applications and just sprinking a tiny bit of JS in the apps, and have generally avoided the whole JS framework mess.