I don’t think there were any standards for this sort of thing when Flatpak and Snaps first came out, and they arrived at the same time and have pretty big differences. So this doesn’t apply.

Yeah I agree.

In my experience taking an inefficient format and copping out by saying “we can just compress it” is always rubbish. Compression tends to be slow, rules out sparse reads, is awkward to deal with remotely, and you generally always end up with the inefficient decompressed data in the end anyway, whether in temporarily decompressed files or in memory.

I worked in a company where they went against my recommendation not to use JSON for a memory profiler output. We ended up with 10 GB JSON files, even compressed they were super annoying.

We switched to SQLite in the end which was far superior.

Hmm I think just using SQLite or DuckDB with normalised data would probably get you 99% of the way there…

Well that’s clearly worse… Why even make this comment?

If I’m understanding you correctly, you can create a branch to mark where you are git branch tmp then abort the rebase. Switch to tmp get the history like you wanted, then switch back. Finally do a git rebase -i again, but immediately git reset --hard tmp. Now you have the resolved commits you want, and can delete any you don’t want to do again with git --edit-todo.

Maybe.

I like how they have to explain what interlacing is but not DPI. I’m old.

That’s way more than 30 lines or code and also their “We didn’t add anything.” claim seems to be nonsense.

You mean like forcing people to use email to submit pull requests to your self-hosted git repos?

I think he meant “you” as in there person running the project, not a contributor.

But… it’s still stupid because GitHub doesn’t force a workflow on you. Unless he means “have an issue tracker” and “use CI” are a workflow. You don’t even need to use merge requests if you don’t want (but I have no idea why anyone would give up something that works so well).

The majority of the post comes across as someone who just doesn’t like the forge sites and aside from the trust aspect, then spent a bunch of effort trying to create associations and limitations between things that don’t exist.

Definitely.

It’s not hard and fast but:

• API is the actual interface for the functions, not the implementation. It’s possible for one API to be implemented by more than one library.
• Library is a bunch of code provided together. It might have more specific meaning depending on the language.
• A package is something you can install. It’s pretty much synonymous to library since most packages contain one library.
• A framework is just a library that dictates a lot about how your app works.

Apart from API they don’t really have strict definitions so they’ll be used interchangeably and differently depending on the language.