Concordo, non capisco perché Canonical debba sempre reinventarsi la ruota: è successo con Mir/Wayland, Upstart/systemd chissà per quanto continueranno
In realtà prima c'era anche
limba project, ma dopo l'incontro tra Klumpp e Alexander Larsson (sviluppatori di Limba e Flatpack) si è deciso di sospendere lo sviluppo del primo.
VI lascio i punti salienti del
blog post di Klumpp di pochi giorni fa:
Quote:
Alex and I had very productive discussions, and except for the modularity issue, we were pretty much on the same page in every other aspect regarding the sandboxing and app-distribution matters.
The main difference between Limba and Flatpak is that Limba allows modular runtimes, with things like the toolkit, helper libraries and programs being separate modules, which can be updated independently. Flatpak on the other hand, allows just one static runtime and enforces everything that is not in the runtime already to be bundled with the actual application. So, while a Limba bundle might depend on multiple individual other bundles, Flatpak bundles only have one fixed dependency on a runtime.
Sometimes stepping out of the way is the best way to achieve progress
I still think Limba is the superior solution for app distribution, but it is also the one that is most complex and requires additional work by upstream projects to use it properly. Which is something most projects don’t want, and that’s completely fine. 😉
[...]
An integral part of Limba is a web service called “LimbaHub” to accept new bundles, do QA on them and publish them in a public repository. I will likely rewrite it to be a service using Flatpak bundles, maybe even supporting Flatpak bundles and Limba bundles side-by-side (and if useful, maybe also support AppImageKit and Snappy). But this project is still on the drawing board.
|