Discussion :

[Michael Guilloux]

Microsoft publie Skype en tant que snap
pour pouvoir prendre en charge un plus grand nombre d'utilisateurs Linux

Skype était déjà utilisé par des millions de personnes dans le monde entier pour faire des appels vidéo et vocaux gratuits, envoyer des fichiers, des vidéos et des messages instantanés, etc. Mais pour booster encore l'utilisation de son application de messagerie instantanée, Microsoft a décidé de faire une refonte qui met davantage l'accent sur le partage de médias et introduit des outils propres aux applications de médias sociaux, afin de mieux concurrencer les applications plus modernes comme Snapchat. C'est ainsi qu'en octobre dernier, Microsoft a lancé la première version de son tout nouveau Skype pour PC, pour les plateformes Windows, Mac, sans oublier Linux. Dans la continuité de ses efforts visant à soutenir le monde open source, Microsoft n’a pas voulu s’arrêter là pour Linux et vient de publier son application de messagerie instantanée en tant que snap.

Rappelons que snap est un format qui vise à permettre l'installation de nouvelles versions de logiciels dans les systèmes Linux, tout en apportant aux développeurs la facilité de distribution, la fiabilité et la sécurité. Et avec le format snap, pour recevoir de nouvelles versions de logiciels, les utilisateurs n'auront plus à mettre en jeu la stabilité de leur système par l'ajout de dépôts personnels (PPA).

« Les snaps sont des packages de logiciels conteneurisés, conçus pour fonctionner en toute sécurité dans n'importe quel environnement Linux sur desktop, dans le cloud et sur les appareils IoT », explique Canonical lors de l'annonce de la disponibilité Skype en tant snap. La publication de ce snap « signifie que Skype peut fournir son service de communication à un plus grand nombre d'utilisateurs de Linux, y compris des millions sur Ubuntu. » D'après l'éditeur d'Ubuntu, Skype est désormais proposé en tant que snap pour s'assurer que ses utilisateurs sur Linux reçoivent automatiquement ses dernières versions après leur sortie. Et grâce à la fonction "roll-back" des snaps, qui permet aux applications de revenir à la précédente version fonctionnelle en cas de bogue, les développeurs de Skype peuvent garantir une expérience utilisateur transparente.

Le snap Skype fonctionnera nativement sur toutes les distributions Linux qui prennent en charge les snaps, y compris Linux Mint, Manjaro, Debian, Arch Linux, OpenSUSE, Solus et Ubuntu. Cette version de bureau Skype sera compatible avec un large éventail de plateformes Linux, ce qui ouvre donc l'application de messagerie instantanée de Microsoft à un plus grand nombre d'appareils et à des millions d'utilisateurs.

« Nous voulons être en mesure de fournir sur Linux la même expérience [Skype] de haute qualité offerte sur les autres plateformes », a déclaré Jonás Tajrych, ingénieur logiciel senior chez Skype, Microsoft. « Les snaps nous permettent de faire exactement cela, en nous donnant la possibilité de livrer les dernières fonctionnalités directement à nos utilisateurs, quel que soit l'appareil ou la distribution qu'ils utilisent », dit-il.

« Nous sommes ravis d'accueillir Skype dans l'écosystème des snaps », a réagi Jamie Bennett, vice-président de l'ingénierie chez Canonical, responsable de la division Devices and IoT. « Skype, et le nombre toujours croissant de snaps qu'il rejoint, cherchent à mettre les utilisateurs Linux en premier, en leur permettant de profiter des dernières versions à la sortie, et à fournir une plus large gamme d'applications parmi lesquelles les utilisateurs pourront faire leur choix. »

Source : Canonical

Et vous ?

Qu'en pensez-vous ?

Voir aussi :

Microsoft introduit le chiffrement de bout en bout sur Skype Insider grâce à Signal sauf pour les discussions de groupes et les appels vidéo
Microsoft lance la nouvelle version de Skype pour bureau pour les plateformes Windows, Linux et macOS
Apple supprime l'application Skype de son App Store chinois et évoque une nouvelle fois une non-conformité aux lois du pays

[RyzenOC]

c'est un truc qui m'a toujours gonflé sous linux... rpm, deb, APK (pour AlpineLinux pas pour android ou c'est encore différent ), sous archilinux avec pacman on peut se contenter d'une archive tar...

si on pouvais universaliser un peu tous sa comme sous Windows avec un .exe ou un .msi, sa serait pas plus mal.

edit : je me renseigne sur le site officiel :
https://snapcraft.io/

surprise il manque les distrib à base redhat (RedHat, centos et fedora) sa commence mal quand je vois sur google RedHat Flatpaks

[ben51]

Fedora est noté dans les distribution compatible.

Après flatpak me semble beaucoup plus avancé en terme d'utilisation. Quand tu vois les gnome apps, gimp, darktable, Skype, Discord ... qui sont déjà disponible sur https://flathub.org/apps/



snap c'est un nouveaux mir.

[abriotde]

rpm, deb, APK

Les systèmes de gestionnaire de packets Linux sont bien plus performants et sécurisés que le système Windows. (Et pour l'utilisateur au moins aussi simple puisqu'on a un magasin d'application ce qu'ont repris tous les autres OS)
La différence fondamentale c'est qu'avec un gestionnaire de packets les bibliothèques communes sont mutualisées.
- Pour l'OS c'est beaucoup mieux car il ne chargera en mémoire qu'une seule fois la bibliothèque même si beaucoup d'applications l'utilisent. Alors que sinon les bibliothèques sont incluses dans les logiciels et donc chargées avec le binaire.
- Pour l'utilisateur c'est beaucoup plus sécurisé car les logiciels sont mis à jour plus facilement d'un seul coup.
- Pour les éditeurs de logiciels, ils n'ont plus à maintenir un système de téléchargement important car les utilisateurs ne passent plus par eux à chaque mise à jour pour mettre à jour leur application. La plupart du temps ils téléchargent l'application depuis le "magasin".
- Mais pour les éditeurs, les bibliothèques trop anciennes ne peuvent plus être utilisées ou de manière compliquées en incluses(?), compilées avec. Cela oblige à maintenir l'application à jour, ce que n'aiment pas faire les éditeurs.

Le seul inconvénient du système de packets, c'est pour les anciennes applications non maintenues, qui ne peuvent plus tourner sur un système à jour incompatible.

[Invité]

« Nous voulons être en mesure de fournir sur Linux la même expérience [Skype] de haute qualité offerte sur les autres plateformes », a déclaré Jonás Tajrych, ingénieur logiciel senior chez Skype, Microsoft. « Les snaps nous permettent de faire exactement cela, en nous donnant la possibilité de livrer les dernières fonctionnalités directement à nos utilisateurs, quel que soit l'appareil ou la distribution qu'ils utilisent », dit-il.

Présenter snap ou flatpack comme une "contribution" à linux c'est vraiment se moquer du monde. La seule chose que ces outils apportent c'est une diffusion plus facile de code propriétaire. Si MS voulait vraiment diffuser skype sur linux, il aurait simplement ouvert le code-source du logiciel client et laissé les mainteneurs des distribs faire leur boulot correctement.

Snap/flatpack c'est :
- du code binaire auquel il faut faire aveuglément confiance (bugs, code malveillant, etc...)
- du code compilé de façon générique (donc pas optimisé)
- des duplications de dépendances à tour de bras (donc gaspillage d'espace disque)
- une gestion dégradée des logiciels (recherche des logiciels, doublon du système de paquet standard, peu ou pas de test de la part des mainteneurs de la distrib...)

Un des gros intérets des distribs, c'est justement d'avoir une logithèque de confiance simple à utiliser. Si c'est pour se taper des .exe et des .msi, autant rester sur windows.

[RyzenOC]

Présenter snap ou flatpack comme une "contribution" à linux c'est vraiment se moquer du monde. La seule chose que ces outils apportent c'est une diffusion plus facile de code propriétaire. Si MS voulait vraiment diffuser skype sur linux, il aurait simplement ouvert le code-source du logiciel client et laissé les mainteneurs des distribs faire leur boulot correctement.

Snap/flatpack c'est :
- du code binaire auquel il faut faire aveuglément confiance (bugs, code malveillant, etc...)
- du code compilé de façon générique (donc pas optimisé)
- des duplications de dépendances à tour de bras (donc gaspillage d'espace disque)
- une gestion dégradée des logiciels (recherche des logiciels, doublon du système de paquet standard, peu ou pas de test de la part des mainteneurs de la distrib...)

Un des gros intérêts des distribs, c'est justement d'avoir une logithèque de confiance simple à utiliser. Si c'est pour se taper des .exe et des .msi, autant rester sur windows.

A contrario l'inverse moi sa me casse les coui****, devoir downloader le code source, faire un make/gcc...
Si les projets open source pouvait fournir un snaps au lieu de proposer soit 1 rpm soit un deb (je rencontre souvent ce cas... les dev n'ont souvent pas envie de maintenir leurs trucs sur trop de distrib et se limite donc à Debien ou CentOS, du coup je dois perdre du temps à compiler si je veut utiliser leurs programme)

et pire encore, si tu change d'architecture et que tu est sur un serveur PowerPC pour ARM, la c'est le saut vers l'inconnu, tu doit parfois passer 1 journée pour débugger du code et arriver le compiler et faire tourner le programme sur le serveur.

Je rêve d'un format "universelle" qui fonctionnerais sur toute les distrib mais aussi sur toute les architectures cpu (meme si la plus compliqué).

[Invité]

A contrario l'inverse moi sa me casse les coui****, devoir downloader le code source, faire un make/gcc...
...
Je rêve d'un format "universelle" qui fonctionnerais sur toute les distrib mais aussi sur toute les architectures cpu (meme si la plus compliqué).

Oui mais c'est malhonnête de présenter uniquement l'aspect universel en "omettant" de dire que c'est potentiellement du code fermé, avec tous les problèmes qui en découlent. Ensuite généraliser ce genre de format risque aussi de généraliser le code fermé et je doute que ça améliore la qualité générale des logiciels. Enfin, avec snap + flatpack + les logithèques, c'est déjà plus très universel tout ça...

Et surtout, quel intérêt ? Pour les utilisateurs, il y a déja des dizaines de milliers de paquets dans les logithèques et elles évoluent constamment. Pour les développeurs, avec deb et rpm, ils touchent la grosse majorité des utilisateurs linux. Et avec les outils d'aujourd'hui, un code qui compile sur une distrib a toutes les chances de compiler aussi sur les autres distribs.

[kain_tn]

A contrario l'inverse moi sa me casse les coui****, devoir downloader le code source, faire un make/gcc...
Si les projets open source pouvait fournir un snaps au lieu de proposer soit 1 rpm soit un deb (je rencontre souvent ce cas... les dev n'ont souvent pas envie de maintenir leurs trucs sur trop de distrib et se limite donc à Debien ou CentOS, du coup je dois perdre du temps à compiler si je veut utiliser leurs programme)

Tu mélanges deux notions: les RPM/DEB etc sont simplement des archives peu différentes des TAR que tu citais plus tôt. La seule différence réside dans leur structure et dans les métadonnées (un peu comme pour des JAR Java). Du coup, tes RPM/DEB te fournissent des binaires et non du code source à compiler, à moins que ce ne soit clairement précisé dans le nom du package qu'il s'agit de code source. Tu peux donc avoir des RPM/DEB et compagnie pour du code open source comme pour du code propriétaire (ex: packages NVIDIA).

En revanche, il existe des distributions pour lesquelles les archives que tu récupères sont des archives de code source et non de binaire et le gestionnaire s'occupe de les compiler (comme pour Gentoo/Funtoo/etc). Elle sont souvent plus difficile d'accès.

et pire encore, si tu change d'architecture et que tu est sur un serveur PowerPC pour ARM, la c'est le saut vers l'inconnu, tu doit parfois passer 1 journée pour déboguer du code et arriver le compiler et faire tourner le programme sur le serveur.

C'est l'intérêt de fournir un RMP/DEB etc dans un store justement: le package doit indiquer quelle architecture est supportée ce qui veut dire que le développeur a à minima déjà fait ces étapes de compilation et de debug puisqu'il te fournit un binaire.

Je rêve d'un format "universelle" qui fonctionnerais sur toute les distrib mais aussi sur toute les architectures cpu (meme si la plus compliqué).

Rien ne t'empêche de l'implémenter. Je veux dire que tu pourrais faire un gestionnaire de package et le livrer pour chaque distribution que tu voudrais supporter. Le seul truc c'est que la plupart des gestionnaires et distributions ont leur propre philosophie derrière, et donc qu'à moins de proposer un truc révolutionnaire, tu vas lutter pour l'adoption.

Pour les architectures de CPU, il faut que ton programme puisse être compilé sur différentes architecture et à ce moment là c'est déjà pris en charge par la plupart des gestionnaires.

D'un autre côté tu présentes le cas des EXE Windows mais ça existe aussi pour Linux. Tu n'est pas obligé de passer par un gestionnaire de package: certains jeux proposent l'équivalent d'un installer Windows pour Linux.