Oui ça mérite plus qu'un journal.
C'est vrai pour le framework android bien sur. Les applis en java utilisent le SDK et la VM qui est sur chaque téléphone. Une appli compilé avec le NDK utilise surtout la libc qui est également dans le SDK, mais peut aussi appeler directement des composants java. Comme une appli mac n'est pas forcément indépendante, elle peut quand même linker avec une lib système, qui bouge pas entre les versions de l'OS (en tout cas, qui cassent pas la compatibilité).
Mais pour toute les autres librairies externes, qui peuvent être dupliqués dans plusieurs app chez ces autres OS, on ne cherche pas à les partager à tout prix, quitte à remettre un gestionnaire de paquet par dessus un autre.
Pareil pour la sandbox de flatpak, d'où l'application peut ouvrir n'importe qu'elle fichier sans l'autorisation de l'utilisateur ? Normalement, seuls les fichiers volontairement ouvert via le file chooser sont accédés.
Et bien tu vois je ne savais pas. macOS fonctionne comme ça aussi, c'est très bien. Pour l'enregistrement ça marche pareil ?
[^] # Re: Si tous les gens autour de toi sont des cons ...
Posté par FluffyHamster . En réponse au journal Mais pourquoi flatpak ?. Évalué à 4.
Oui ça mérite plus qu'un journal.
C'est vrai pour le framework android bien sur. Les applis en java utilisent le SDK et la VM qui est sur chaque téléphone. Une appli compilé avec le NDK utilise surtout la libc qui est également dans le SDK, mais peut aussi appeler directement des composants java. Comme une appli mac n'est pas forcément indépendante, elle peut quand même linker avec une lib système, qui bouge pas entre les versions de l'OS (en tout cas, qui cassent pas la compatibilité).
Mais pour toute les autres librairies externes, qui peuvent être dupliqués dans plusieurs app chez ces autres OS, on ne cherche pas à les partager à tout prix, quitte à remettre un gestionnaire de paquet par dessus un autre.
Et bien tu vois je ne savais pas. macOS fonctionne comme ça aussi, c'est très bien. Pour l'enregistrement ça marche pareil ?