By creating your own format, you now have to create your entire ecosystem, or add functionality to existing systems to deal with your format. That is a huge undertaking and why media consortiums exist for stuff like JPEG, MP3, MP4, etc etc.

I don’t know the music ecosystem at all, so I don’t know what open source programs you could modify to support your format, but realistically that could easily be a year+ project.

If you’re having fun, keep going, but it’s a big challenge

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

Put as much of your testing in shell scripts, or even better, Ansible playbooks, so that you can run them locally. That way your CI system just does ansible-playbook

There’s a very good Ansible collection for podman, so you can orchestrate the unit tests to run inside a container for full isolation

SSR libraries

Let me clarify. I meant server side rendering as in the response is all generated server side.

NOT JavaScript SSR where parts of your JavaScript code run on the server side.

https://developer.mozilla.org/en-US/docs/Glossary/SSR

Django, Flask, FastAPI

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.

Art of Unix Programming

https://archive.org/details/ost-computer-science-the_art_of_unix_programming-1

Gell-Mann Amnesia effect

Don’t know what to tell you. Been doing it that way since 2011

Not exactly, because n commits will have been squashed into one, so making the edit would lose the reference to the originals which should have been squashed with other commits

See but you can break the commit back apart by doing a git rebase interactive, selecting that squashed commit as the commit to edit, then doing a git reset HEAD~1 then recommit it in pieces, then git rebase --continue

Then git rebase -i a second time and then remove the commit that you don’t want to be included

If you are continually rebasing and having to fix the same merge conflict over and over, you should look at https://git-scm.com/book/en/v2/Git-Tools-Rerere

You can also do a git rebase -i and mark a commit as edit and git will stop at that commit in the rebase to allow you to stop, look around, and make changes… I think that is what you are looking for