Sortie le 13 octobre 2016, Ubuntu 16.10 est la vingt‐cinquième version d’Ubuntu. Contrairement à Ubuntu 16.04 LTS, cette version est davantage destinée aux utilisateurs expérimentés et ne sera maintenue que pendant neuf mois.
Son nom de code est Yakkety Yak, ce qui est assez étrange et difficilement traduisible. L’expression anglaise yakety‐yak (avec un seul « k » à yakety) signifie bla‐bla, dans le sens « cette explication est trop longue, c’est du bla‐bla ! ». On peut donc penser à un simple jeu de mots afin de mettre en valeur un yack assez bavard.
Sommaire
- Distribution Ubuntu
- Nouveautés générales
- Gestion de la session utilisateur par systemd
- Session de test pour Unity 8
- Ubuntu Touch (téléphones, tablettes, mais pas que)
- Les autres variantes
- Et la suite ?
Distribution Ubuntu
Pour rappel, Ubuntu est une distribution GNU/Linux basée sur Debian. Elle a hérité de sa distribution mère l’objectif d’universalité : elle vise à être utile sur les ordinateurs de bureau, les ordinateurs portables, mais aussi les serveurs, le cloud, les téléphones, les tablettes et les objets connectés en général. Elle se veut simple d’accès pour les utilisateurs n’ayant pas de connaissances poussées en informatique, mais également attrayante pour les développeurs.
En plus de la distribution mère, Ubuntu, il existe plusieurs variantes officielles, fournies avec des choix logiciels différents, afin de couvrir un besoin (Ubuntu Server, Ubuntu Studio…) ou de fournir un environnement de bureau particulier (Kubuntu, Xubuntu, Lubuntu…). Cette dépêche présente les principales nouveautés.
Nouveautés générales
- noyau Linux 4.8 ;
- Mesa 3D 12 ;
- systemd 231 ;
- GCC 6.2 ;
- le binaire gpg par défaut est maintenant fourni par gnupg2 ;
- LXD 2.4 ;
- la majeure partie des composants de GNOME passe en 3.20, d’autres sont en 3.22 ;
- Qt 5.6.1 ;
- LibreOffice 5.2, avec l’interface GTK 3 activée par défaut ;
- le gestionnaire de mises à jour peut maintenant afficher les journaux des modifications pour les PPA.
Gestion de la session utilisateur par systemd
Le système d’initialisation systemd a certes remplacé Upstart comme PID 1 par défaut depuis Ubuntu 15.04, mais Upstart continuait de gérer les sessions utilisateur. Ces dernières sont maintenant gérées par une instance dédiée de systemd afin de lancer les services au démarrage (indicateurs, appliquettes…), mais aussi de les relancer en cas de plantage.
Upstart n’a toujours pas entièrement disparu et reste pour le moment cantonné sur l’écran de connexion en lui‐même. Cependant, il ne fait pas de doute qu’Upstart sera complètement supprimé d’ici la prochaine version LTS.
Session de test pour Unity 8
Une session « Unity 8 » expérimentale est maintenant disponible par défaut sur l’écran de connexion, en parallèle de la session Unity 7 habituelle.
Notez cependant que cette session ne fonctionnera pas forcément chez vous, en fonction de la carte graphique et de la version du pilote que vous utilisez.
Très rustique mais néanmoins utilisable, cette session est avant tout une étape importante dans le développement. Elle devrait permettre à plus de développeurs et d’utilisateurs avancés d’utiliser Unity 8 dans son mode desktop et, ainsi, accélérer l’implémentation des éléments manquants pour remplacer Unity 7.
Ces six derniers mois, on pourra noter l’implémentation de la maximisation partielle d’une fenêtre en la collant sur un bord de l’écran, le prise en charge du copier‐coller depuis et vers les applications X11 (et donc via XMir), l’amélioration du Alt + Tab et beaucoup d’autres choses encore.
De plus, Unity 8 et tous les composants associés ont été migrés vers le dépôt principal (main), afin d’être supportés officiellement par Canonical. Ce processus a nécessité, entre autres, un audit général de sécurité. Celui‐ci a permis de corriger un certain nombres de bogues et d’améliorer la robustesse du système.
Ubuntu Touch (téléphones, tablettes, mais pas que)
Ubuntu Touch est une distribution dérivée à part entière. Il s’agit d’une quasi distribution à publication continue (rolling‐release) dont chaque nouvelle version est déployée, en moyenne, toutes les huit semaines. À terme, c’est cette version qui devrait prendre la place de l’Ubuntu officielle.
Trois versions ont été déployées au cours des six derniers mois (nous sommes passés de la version OTA 10 à l’OTA 13). On pourra noter les nouveautés suivantes, au‐delà de celles déjà citées précédemment pour Unity 8 et des corrections de bogues :
- amélioration de la précision du service de positionnement‐localisation ;
- prise en charge de l’affichage sans fil (Miracast) pour le Meizu Pro 5 ;
- prise en charge du lecteur d’empreintes digitales pour le Meizu Pro 5 ;
- l’interface entière de Unity 8 tourne désormais avec l’écran ;
- ajout d’un indicateur pour gérer l’agencement des claviers physiques ;
- les notifications peuvent maintenant être configurées finement pour chaque application ;
- ajout de la prise en charge des comptes ownCloud et Nextcloud ;
- prise en charge de la synchronisation depuis plusieurs agendas ;
- plus d’options pour les connexions de réseaux privés virtuels (mot de passe…) ;
- un nouveau clavier complet d’émojis colorés ;
- possibilité de transférer un message à un autre destinataire ;
- le navigateur Web a beaucoup évolué :
- WebRTC est entièrement fonctionnel, ouvrant la voie pour de nombreuses applications de tchat audio et vidéo,
- possibilité d’ouvrir plusieurs fenêtres à la fois en mode desktop,
- meilleure gestion des raccourcis clavier,
- optimisation du temps de chargement lors de l’ouverture d’un nouvel onglet,
- prise en charge du zoom en mode desktop ;
- de nombreuses améliorations au niveau des performances et de la gestion de l’énergie.
Les autres variantes
Kubuntu
La nouvelle mouture de Kubuntu est accompagnée des mises à jour suivantes :
- Plasma 5.7.5 ;
- Applications 16.04.3 ;
- Frameworks 5.26.0.
Les images sont disponibles en torrent ou en téléchargement direct sur http://cdimage.ubuntu.com/kubuntu/releases/16.10/release/.
Xubuntu
Cette version n’a que peu de changements visibles depuis la version 16.04 d’avril (essentiellement des corrections de bogues). Cependant, beaucoup a été fait pour pouvoir fournir Xubuntu avec les paquets Xfce livrés avec GTK 3, notamment de nombreux greffons et le terminal Xfce. Si quelqu’un souhaite tester ces portages, ils peuvent être installés depuis l’un des PPA de développement de l’équipe.
Thunar est toujours le sujet de quelques bogues, même s’ils semblent être résolus petit à petit. Sur certaines machines, pour pouvoir sortir du mode veille, il faut parfois le taper à deux reprises.
Les images sont disponibles en torrent ou en téléchargement direct sur http://cdimage.ubuntu.com/xubuntu/releases/16.10/release/.
Ubuntu GNOME
Cette variante est basée sur l’environnement GNOME. Celle‐ci inclut la version 3.20 de GNOME, chroniquée récemment. En résumé, nous pouvons lister les changements suivants :
- de nombreuses applications utilisent en fait leur versions GNOME 3.22, seul le cœur du système (GTK+, GNOME Shell, GNOME Control Center et Nautilus) est toujours à la version 3.20 ;
- de nombreuses applications GNOME ont une vue contenant les raccourcis clavier disponibles ;
- possibilité de partager facilement des photos Google Photos avec l’application Photos. L’édition non destructive a aussi été ajoutée ;
- l’application de messagerie instantanée Empathy n’est plus installée par défaut, mais toujours disponible à l’installation.
Les images sont disponibles en torrent ou en téléchargement direct sur http://cdimage.ubuntu.com/ubuntu-gnome/releases/16.10/release/.
Ubuntu MATE
Ubuntu MATE 16.10 est, plus ou moins, une refonte complète d’Ubuntu MATE. En effet, hormis la transition de l’environnement vers GTK+ 3, un gros travail a été accompli pour briser les dépendances dures entre les paquets des différents composants installés par défaut (transition de Depends à Recommends). Concrètement, cela signifie que la plupart des applications peuvent maintenant être désinstallées individuellement, sans entraîner la suppression de la moitié du reste de l’environnement avec elles.
Le travail nécessaire pour porter le bureau MATE sur GTK+ 3 a pris plusieurs années, et Ubuntu MATE est la première distribution majeure à proposer une intégration complète de GTK+ 3 du bureau MATE. La dernière version (1.16) du bureau MATE est donc disponible.
Durant ce cycle, les bibliothèques graphiques ont été changées à deux reprises. La première fois de GTK 2.24.x à GTK 3.18, et ensuite pour GTK 3.20. Les thèmes graphiques ont nécessité deux mises à jour significatives durant cette opération.
Le portage devait initialement être terminé pour la future Ubuntu MATE 17.04, mais un important financement participatif a permis d’atteindre l’objectif plus tôt.
Les images sont disponibles en torrent ou en téléchargement direct sur http://cdimage.ubuntu.com/ubuntu-mate/releases/16.10/release/.
Lubuntu
La distribution légère basée sur LXDE est en train de préparer la migration vers LXQt. De nombreux bogues ont été résolus, et les thèmes graphiques ont été mis à jour.
Les images sont disponibles en torrent ou en téléchargement direct sur http://cdimage.ubuntu.com/lubuntu/releases/16.10/release/.
Et la suite ?
À l’heure de la rédaction de cette dépêche, le nom de code d’Ubuntu 17.04 (ou « Ubuntu Z ») n’a toujours pas été annoncé. (NdM.: Zesty Zapus via NextINpact). La prophétie maya annonçant qu’il s’agirait de la dernière version d’Ubuntu (pour cause de manque de lettres dans l’alphabet) serait‐elle vraie ? Seul l’avenir nous le dira.
Ubuntu Touch devrait enfin passer sur une base Ubuntu 16.04 (contre 15.04 aujourd’hui). Cela semble en tout cas être la priorité des développeurs en ce moment, avec la transition vers un empaquetage Snap de l’ensemble.
Pour le reste, Unity 7 devrait rester le bureau par défaut, mais Unity 8 (dans son mode desktop) aura vraisemblablement suffisamment gagné en maturité pour devenir une alternative véritablement utilisable au quotidien.
Aller plus loin
- Téléchargement de la version 16.10 sous forme de torrent et d’ISO (2085 clics)
- Notes de version (469 clics)
- Tutoriel d’installation (Léa-Linux) (1310 clics)
# Vivement la prochaine !
Posté par Malizor . Évalué à 5.
Depuis le passage en modération, le nom de code d'Ubuntu 17.04 a été dévoilé: ça sera Zeisty Zapus.
http://www.markshuttleworth.com/archives/1512
Si quelqu'un pouvait éditer la conclusion…
# Intégration app store
Posté par tuxicoman (site web personnel) . Évalué à 6.
Un truc que j'ai découvert dans Debian Stretch, c'est l'intégration réussie de l'app store "Gnome logiciels" dans l'interface.
Quand on cherche une appli dans gnome shell, même si on l'a pas installée, elle apparaît quand même comme résultat de recherche en tant qu'icone et on peut alors l'installer d'un clic (et un mot de passe admin).
J'ai trouvé cela vraiment bien fait. Peut être que je débarque, mais ca existe également sur d'autres distrib? quelle est la position d'ubuntu par exemple? il y a surement du business à faire sur l'app store (cf Google/Apple/Microsoft stores)
[^] # Re: Intégration app store
Posté par ff9097 . Évalué à 7.
Normalement ça fonctionnera avec n'importe quelle distrib avec Gnome.
[^] # Re: Intégration app store
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 3.
Ça fonctionnait déjà avec le prédécesseur de GNOME Logiciels, le très controversé Ubuntu Software Store. Je trouve la manière de faire dans le Shell beaucoup plus propre que ce que proposait Unity avant, mais ce n'est pas à proprement parler une nouveauté.
Quant à la partie business, il faut surveiller les projets cross-distro comme FlatHub. Mais leur avènement n'est clairement pas pour demain. De mon côté, j'espérais me baser sur Flatpak pour proposer une installation rapide et facile de notre appli GNOME Jeux, mais il s'avère que les fichiers
*.flatpakrefne seront supportés par Logiciels que dans six mois, et logiquement pas avant un an dans Ubuntu… Peut-être que ça marchera mieux avec un snap.[^] # Re: Intégration app store
Posté par Letho . Évalué à 3. Dernière modification le 18 octobre 2016 à 16:45.
Il me semble que Gnome Software 3.22 supporte parfaitement l'installation de bundles Flatpak, à défaut de pouvoir utiliser les *.flatpakref.
Et tant que j'y suis : merci (vraiment) (beaucoup !) pour Gnome Games, j'utilisais OpenEmu dans ma période OSX, cela faisait longtemps que je cherchais à retrouver quelque chose de semblable sous Linux, et intégré à Gnome :)
[^] # Re: Intégration app store
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 2.
Genre en cliquant simplement dessus ? Et ça t'ajoute aussi le dépôt ou bien tu dois faire les mises à jour toi-même ?
Sinon, merci beaucoup pour tes compliments ! L'appli n'est pas encore bien mûre mais on nourrit de grandes ambitions pour elle !
[^] # Re: Intégration app store
Posté par Jehan (site web personnel, Mastodon) . Évalué à 5.
Le format
.flatpak, c'est juste un paquetage standalone. Par exemple GIMP-telle-version; il n'y a pas de dépôt, pas de mise à jour. Pour le dépôt, le format.flatpakreposera possible. Mais le format vraiment intéressant quand on gère un dépôt pour une seule application principalement sera le.flatpakref. Celui-ci référence les infos du dépôt ainsi qu'une application à installer par défaut en même temps.On pourrait donc installer GIMP en un clic tout en ayant des mises-à-jour régulières.
Et oui l'objectif final est bien de pouvoir installer en un clic (bon avec une GUI intermédiaire, le but n'est pas d'installer des trucs à l'insu de l'utilisateur), comme pour un
.rpmou un.debpar exemple.On pourra aussi voir les paquets flatpak installés et les désinstaller dans GNOME Software. Et surtout on pourra installer des paquets sans pouvoir d'administration (pour moi, ça c'est vraiment majeur).
Voir ce billet de Richard Hughes pour voir l'état d'intégration de flatpak dans GNOME Software.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Intégration app store
Posté par gpe . Évalué à 0. Dernière modification le 19 octobre 2016 à 11:33.
Est-ce vraiment un bien de pouvoir installer des paquets sans droits d'administrations ?
A force vouloir singer les vieux Windows ou n'importe qui pouvait faire n'importe quoi ne risque-t'on pas d'annihiler un des avantages premiers des systèmes Linux: la sécurité ?
Cela ne risque-t'il pas de détruire la cohérence d'une distribution, en ayant de multiples versions de libs de provenance diverses dont il sera difficile de savoir si elles sont à jour par rapport à des failles de sécurités ?
[^] # Re: Intégration app store
Posté par Letho . Évalué à 8.
Les bibliothèques de base sont regroupées au sein de runtimes partagés entre les applications. Par exemple, toutes les applications qui nécessitent le runtime Gnome 3.22 utiliserons le même. On peut bien sûr installer différents runtimes en parallèle.
Par contre, effectivement, les bibliothèques n'appartenant pas à un runtime doivent être packagées avec l'application. La contrepartie positive, c'est que l'on n'est plus dépendant des versions de bibliothèques fournies par la distribution. De même, la notion de runtime permet par exemple sans aucun souci d'installer des applications Gnome 3.24 sous Gnome 3.22. Ou même des versions de développement, qu'importe, pourvu que tu dispose du bon runtime.
Après, d'un point de vue sécurité, le principal intérêt de Flatpak reste le sandboxing.
Ce n'est que mon avis, mais je pense que c'est la meilleure chose qui soit arrivée à la distribution d'applicatifs sous Linux depuis des années. Et à titre personnel, cela faisait justement des années que j'attendais un truc pareil :)
Je t'invite à aller voir le site officiel pour plus d'infos :
http://flatpak.org/
[^] # Re: Intégration app store
Posté par gpe . Évalué à 9.
Le sandboxing répond à la sécurité de ton système. Mais la sécurité ce n'est pas que ça. C'est aussi la sécurité des données. Avec le modèle "distribution" de linux quand une faille est détectée dans une lib genre ssl, la distri met à jour son paquet et tous les logiciels s'appuyant dessus en profite.
Une appli flatpack, si j'ai bien compris (?), peut très bien intégrer sa propre version de la lib ssl et ne pas la mettre à jour et on va se retrouver avec une appli certes jouant seule dans son bac à sable mais dont les données utilisateur ne sont pas sécurisées.
Pour moi le point très très fort du modèle distribution c'est de n'avoir qu'une source à regarder pour gérer les aspects sécurité (les distri sont en général très réactives) alors qu'avec le modèle flatpack, j'ai l'impression que l'utilisateur va devoir se renseigner auprès de multiples sources (surtout que si j'ai bien compris (?) une lib peut se trouver à différent niveau) pour savoir si les failles sont bien corrigées, avec potentiellement moins de réactivité d'un développeur seul dans son coin plus axé sur son appli qu'à suivre les alertes de sécurité des libs ?
[^] # Re: Intégration app store
Posté par Letho . Évalué à 3. Dernière modification le 19 octobre 2016 à 17:19.
Oui et non. Une application Flatpak pourrait n'avoir accès qu'à ce à quoi tu lui donne accès. Maintenant, tu as raison, si une bibliothèque embarquée doit être mise à jour, cela relève de la responsabilité du développeur. Les bibliothèques les plus courantes devraient faire partie des runtimes, qui eux sont mis à jour pour toutes les applications les utilisant. J'avoue que je ne sais pas du tout si la libssl fait partie du runtime Freedesktop ou de celui de Gnome.
Après, tu y gagne énormément en confort d'utilisation pour l'utilisateur, ET pour le développeur qui souhaite distribuer son application. Soyons honnêtes : je suis vraiment très heureux sous Fedora, mais l'installation d'applications tierces est une véritable plaie. Et je ne parle même pas du souci du packaging pour les X distributions existantes. Flatpak offre ça, plus le sandboxing. Ça demande de sacrifier - et encore, de façon relative - un peu de ce qu'offrent actuellement les gestionnaires de paquets. Mais les avantages dépassent à mon sens largement les inconvénients.
[^] # Re: Intégration app store
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 19 octobre 2016 à 13:07.
Le meilleur moyen pour flinguer la sécurité est de ne pas fournir un moyen sécurisé de faire ce que l'utilisateur cherche à faire.
Dans le cas présent, ton idée est d'inciter l'utilisateur à installer un paquet venant de n'importe où avec les droits admin (car tu ne veux pas lui laisser la possibilité de faire sans droits admins).
Linux n'a pas besoin d'ennemis, ses amis se chargent de le flinguer en disant à l'utilisateur "oui tes besoins je m'en fou, casse-toi" (je reformule ta deuxième phrase en version comprise par celui qui se prend ton commentaire, sérieux si les gens le faisaient sous Windows et que c'est une grosse critique de Linux de ne pas avoir ce genre de possibilités, c'est peut-être que le soucis est chez les gens qui pensent que c'est inutile tu ne penses pas?).
Bref, merci à Ubuntu de penser expérience utilisateur et pas "principes immuables comme une religion et on ne regarde pas l'évolution des besoins".
[^] # Re: Intégration app store
Posté par xcomcmdr . Évalué à 5. Dernière modification le 19 octobre 2016 à 14:06.
Étant donné que HeartBleed et autres joyeusetés ne concernent pas Windows, la réputation de sécurité de "Linux" est déjà sérieusement mise à mal de toutes façons. ;-)
Et pouvoir installer une application à partir d'un simple paquet téléchargé en dehors du store, avec ou sans droits admins (selon l'installeur), c'est tout à fait d'actualité aujourd'hui sous Windows. C'est d'ailleurs toujours le modèle dominant sous Windows (presque personne n'utilise le Windows Store bourré de malwares et adwares. Et personne ou presque n'utilise ni ne connaît l'existence du gestionnaire de paquets de Windows 10).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Intégration app store
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
Ben oui carrêment. C'est plutôt la question inverse qu'il faudrait poser: pourquoi aurait-on besoin de droits d'administration pour la plupart des programmes? C'est une aberration sécuritaire, en un sens. Bien sûr, ce n'est pas tout à fait vrai en remettant en contexte: à l'époque où les systèmes de paquetage classique (.rpm, .deb…) ont été créé, on pensait encore l'informatique avec l'opposition "un admin pointu qui connaît tout sur tout (ahahah)" d'un côté et des "utilisateurs idiots" de l'autre. Dans ce contexte, l'admin choisissait pour ses utilisateurs et il savait (normalement) ce qu'il faisait et aussi pouvait peser la légitimité de la source d'un programme, voire lire les dites-sources (re-ahahah).
Depuis les choses ont évolué et on se rend compte de plus en plus que le plus gros de l'utilisation, c'est: "un seul utilisateur par machine, qui est aussi l'admin". L'informatique personnelle en somme. Souvent cet utilisateur n'a pas particulièrement de connaissance, même si je pense qu'il serait bien de le rendre un peu plus responsable plutôt que totalement soumis (le rêve des GAFAM est qu'ils deviennent les administrateurs du monde et que l'ensemble des utilisateurs restent "idiots" sans chercher à comprendre).
Dans ce nouveau contexte, pouvoir installer un nouveau programme sans droits d'administration est un must.
Le fait est que les utilisateurs Linux installent depuis des années maintenant des logiciels sans droit d'administration: soit en les compilant soi-même, soit en téléchargeant une archive sur un site web (par exemple, on fait cela pour Blender, afin d'avoir une version récente), etc.
Quitte à faire cela, autant le faire de manière sécurisé et avec une intégration au bureau (je déteste avoir à aller chercher un binaire dans un dossier et double-cliquer pour devoir lancer un programme!).
En outre, tu dis plus bas:
Ben c'est justement là où flatpak va exceller. Un logiciel en sandbox n'a accès aux données que si ce droit lui a été donné. Ce genre de paquetage est 100 fois plus sécurisé pour les données que les systèmes à l'ancienne (lesquels n'ont tout simplement quasiment aucune sécurité, hormis l'utilisateur et le groupe, ce qui ne protège justement absolument pas les données qui auront le même utilisateur que l'exécution). Ils ont accès aux données, au réseau, l’interaction avec les autres processus, etc. Ensuite y a d'autres mécanismes, comme les capabilities POSIX, mais c'est plus complexe et très peu de logiciels "grand public" vont en faire usage. Les logiciels de tous les jours ont un peu tous les pouvoirs au final.
Avec une sandbox dont les permissions sont visibles par l'utilisateur, les choses sont déjà plus claires pour l'utilisateur et plus simple pour le développeur et packageur.
Alors soyons clair, je préférerai de loin n'avoir besoin que des dépôts de distribution, qu'une seule version par librairie, etc. Mais la réalité a montré les limites de ce système. Au final on se retrouve régulièrement à vouloir installer une version plus récente que ce qu'il y a sur le dépôt, voire même carrément à ne pas trouver dans le dépôt un logiciel. Ça m'est encore arrivé y a 2 jours: je lis une description d'un logiciel libre qui pourrait m'être utile, je me tiens "tiens testons le", il n'était pas dans les dépôts. Et le projet upstream ne proposait qu'un binaire
.deb, ainsi qu'une archive qui nécessitait une version différente d'une bibliothèque Python. Au final je n'ai pas pu tester, et j'ai abandonné (j'aurais pu insister et réussir, sans aucun doute. Mais franchement j'ai estimé l'effort comparé à mon besoin et ai décidé que ça ne valait pas le coup). Ça m'a clairement attristé.Quant à la sécurité, même si l'usptream avait fourni un
.rpmque j'aurais pu installer en un clic — avec mon mot de passe root! — quelle sécurité aurais-je eu? Niet, nada, zip! Le programme s'installerait dans mon système et une fois lancé aurait simplement accès à toutes mes données, à mon interface réseau, etc. Je dois avouer l'inavouable: je n'ai pas minutieusement inspecté le code de ce logiciel, même s'il est libre et que j'avais donc accès à tout (ceci dit, la version dans le rpm aurait pu être différente du code public! Donc même si j'avais inspecté le code, ça n'aurait pas forcément servi). Au final, il pourrait tout aussi bien contenir un gros malware qui serait passé comme une lettre à la poste (je l'ai peut-être échappé belle en échouant, qui sait!).Si ça avait été un flatpak, j'aurais pu vérifier à quoi il avait accès: tiens pourquoi un accès réseau? Ce logiciel doit-il vraiment avoir accès à mon home complet? Etc.
Avec Wayland, j'aurais aussi pu avoir la certitude qu'il ne peut lire mon clavier ou faire un screenshot d'autres programmes (bye-bye keyloggers et assimilés), etc.
Franchement Flatpak améliore la sécurité dans ce cas de figure.
Oui on n'a plus le beau système avec chaque librairie partagée. C'est très triste et franchement cela ne me fait pas plaisir. Mais il faut aller de l'avant. J'ai envie de dire que c'est seulement le monde de l'informatique desktop, mais en fait sur le serveur, ils ont connu cela bien plus tôt, déjà avec les machines virtuelles, puis plus récemment avec docker.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Intégration app store
Posté par groumly . Évalué à 3.
La sécurité de nos jours tiens énormément dans le sandboxing: refuser au binaire accès à tout fichier et/ou api auquel l'utilisateur n'a pas explicitement donne accès (ca veut pas forcément dire UAC, hein, regardez ce que macos fait sur les accès filesystem). On peut pas vraiment dire que Linux soit en avance dans ce domaine, soit dit en passant.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Intégration app store
Posté par gpe . Évalué à 7.
Les UAC partent d'un bon sentiment mais au final n'aboutissent à pas grand chose. Le gros problème des UAC c'est que quand tu installes un logiciel tu vas être informé qu'il demande l'accès à tel ou tel truc (et parfois tu ne comprends même pas de quoi il s'agit) mais comme on ne te dit jamais pourquoi il te demande cet accès ni les conséquences d'un refus partiel. Donc dans 99% des cas les gens disent ok les autres renoncent à l'utilisation.
[^] # Re: Intégration app store
Posté par barmic . Évalué à 3.
Il faut aussi faire attention à ne pas devenir un botnet par exemple. Le fait de donner des droits limité (sandbox est le nom à la mode, mais selinux ou autre peuvent déjà suffisamment limiter) ne peut fonctionner qu'avec une granularité bien maîtrisée des droits et c'est généralement là que le problème se trouve. Trop fin l'utilisateur est harcelé et ne comprend pas ce qu'on lui demande, trop large les droits n'ont plus beaucoup de sens et les binaires ont trop de droits.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Intégration app store
Posté par Letho . Évalué à 2.
Ce n'est pas ce que semble indiquer le billet que tu cite :
A priori, un bundle flatpak peut également installer un remote qui ne concernera que le logiciel en question. La doc ne semble cependant pas à jour à ce propos sur le site officiel.
Pour le *.flatpakref, effectivement, il configure obligatoirement un remote et installe une application.
En gros, soit on télécharge l'application dans un bundle qui va potentiellement configurer le remote de mise à jour (possible à l'heure actuelle), ce qui permet également de la distribuer autrement que par un remote (mail, dropbox, etc), soit on utilise un *.flatpakref qui est plus léger mais utilise obligatoirement un remote.
[^] # Re: Intégration app store
Posté par gpe . Évalué à 3.
Ah oui ce truc infernal qui te pompe la bande passante réseau au démarrage et bloque les autres commandes de mises à jour pendant des plombes sans savoir pourquoi. Ça me gonflait tellement que je l'ai désactivé …
[^] # Re: Intégration app store
Posté par gUI (Mastodon) . Évalué à 2.
J'ai pas ça moi ! il doit me manquer un paquet… t'as une idée de ce qu'il me manque pour avoir cette fonctionnalité ?
Merci !
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Intégration app store
Posté par Sébastien Wilmet . Évalué à 2.
En installant gnome-software et en utilisant gnome-shell (le desktop GNOME). Je ne sais pas si dans Unity il y a cette fonctionnalité. Mais les dernières versions d'Ubuntu utilisent gnome-software aussi (sous un autre nom).
# Signification de Yakkety Yak
Posté par Boa Treize (site web personnel) . Évalué à 9.
C'est surtout un énorme jeu de mot sur le célèbre Yakety Sax du générique de fin du Benny Hill Show. ;-)
[^] # Re: Signification de Yakkety Yak
Posté par xseticon . Évalué à 8. Dernière modification le 18 octobre 2016 à 16:47.
… qui est lui-même un jeu de mot du Yakety Yak de 1958 …
[^] # Re: Signification de Yakkety Yak
Posté par Malizor . Évalué à 3.
Mais pourquoi deux « k » à Yakkety ?
[^] # Re: Signification de Yakkety Yak
Posté par Dr BG . Évalué à 10.
Sûrement parce 3 auraient fait polémique.
[^] # Re: Signification de Yakkety Yak
Posté par Sébastien Wilmet . Évalué à 1.
Résultats plus pertinents dans un moteur de recherche ?
[^] # Re: Signification de Yakkety Yak
Posté par Maclag . Évalué à 2.
Woah! Ça y est, maintenant je l'ai dans la tête!
Nostalgie, quand tu nous tiens!
Merci!!
# Proposer des noms
Posté par Nibel . Évalué à 4.
Et pour les personnes débordantes d'imagination, il est possible d'aller proposer les futurs noms ici :
https://wiki.ubuntu.com/DevelopmentCodeNames#Code_Name_Suggestions
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: Proposer des noms
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Une NdM a été ajoutée suite à l'annonce du nom de la prochaine version (« Zesty Zapus »).
[^] # Re: Proposer des noms
Posté par Sébastien Wilmet . Évalué à 0.
Zapus la fin.
(De l'alphabet bien entendu).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.