I kind of get it. Note apps are normally horribly cumbersome data serialization ecosystems you have to invest a lot of time into before you really feel like its doing anything more than a standard text editor could
This is where someone tracks down an upgrade path chart you didn’t know existed and points out some goofy intermediary release, not an lts for some reason, that you were supposed to upgrade to first…
<span style="font-style:italic;color:#969896;">/*
</span><span style="font-style:italic;color:#969896;"> * Make /sys/kernel/notes give the raw contents of our kernel .notes section.
</span><span style="font-style:italic;color:#969896;"> */
</span>
If I recall correctly, the whole suite was sold to a company that has a history of acquiring existing tools just to park them in maintenance mode and fill them with ads.
Big if true, do you have a link to follow that development? I’ve been curious about some languages that compile to JS+WASM but I’ve been waiting for something like this to finally cut out the middle man and give me an excuse to learn WASM directly.
This is exactly the reason why I can’t believe that was ever a requirement. I would have crazy respect for webassembly if it could stand on it’s own as it would allow people to completely move away from JS, but if JS is still in the stack in any way it will introduce a (even if it is minimal) compatibility and maintenance cost in the long run.
This may be a little bias but this is my understanding:
Flatpaks were the solution for reducing the duplication in Appimages and providing an automated way to do security updates. Flatpak got a chance to learn from Snap.
Snaps are basically a proprietary approach to creating and distributing Appimages that were created prior to the current Appimage tooling. They got to learn from the first generation of Appimages and decided to deviate from them early on.
Appimages were a stupid simple approach to a complex issue. Initial tooling was rough though and a lot of people, while they liked the idea, hated the requirements. Basically setting up an Ubuntu 18.04 environment for packaging was the only way to guarantee a truly portable image.
It left room for improvement and so decisions were made to try and fill that room. They were never bad, and devs weren’t really trying to do anything other than simplify the creation and distribution of existing Appimage functionality.
I still think flatpaks are the closest to the ideal solution but again, I’m biased.