Nouvelles du Libre

La suite open source française OBM 3 est arrivée

Toolinux - jeu, 07/08/2014 - 23:35

La suite de communication open source française a peaufiné son interface et ses fonctions. OBM 3 vous attend, gratuitement et à coeur ouvert.

- Logiciels / ,
Catégories: Nouvelles du Libre

APRIL : sur l'application de la circulaire Ayrault (logiciels libres dans les administrations)

Toolinux - jeu, 07/08/2014 - 23:25

Fin mai 2013, la députée Isabelle Attard avait adressé à tous les ministres des questions écrites concernant la mise en œuvre de la circulaire Ayrault sur le bon usage des logiciels libres dans les administrations et sur les dépenses.

- Revue de presse
Catégories: Nouvelles du Libre

Epic Snake : la campagne de cyber-espionnage Turla expliquée

Toolinux - jeu, 07/08/2014 - 23:20

Turla, également connue sous le nom de Snake ou Uroburos, est l'une des campagnes de cyber-espionnage en cours les plus sophistiquées. Lorsque la première recherche sur Turla / Snake / Uroburos a été publiée, elle ne répondait pas à une question majeure : comment les victimes ont-elles été infectées ?

- Revue de presse
Catégories: Nouvelles du Libre

WD se rapproche des NAS Thecus

Toolinux - jeu, 07/08/2014 - 23:00

Le constructeur a annoncé la compatibilité de ses gammes de NAS et NVR avec les nouveaux disques WD Red 6TB et WD Red Pro.

- Matériels
Catégories: Nouvelles du Libre

Sortie de X.Org 1.16

Linuxfr - jeu, 07/08/2014 - 13:11

Si Wayland est sur la bonne voie pour arriver sur nos ordinateurs, l’équipe s’occupant de X.Org n’a pas chômé pour nous livrer, le 17 juillet dernier, cette version 1.16 qui apporte pas mal de nouveautés intéressantes !

La suite de la dépêche propose une traduction française des notes de version (Glamor, XWayland, systemd, compilation plus propre, appareils non PCI, etc.).

Intégration de Glamor

Glamor, le sous‐système d’accélération graphique 2D fondé sur OpenGL, offre des performances raisonnables, ce qui permet d’éviter, la plupart du temps, les solutions logicielles de secours.

XWayland

XWayland est maintenant livré avec X.Org. Il fournit un serveur X intégré dans un système de fenêtrage Wayland. Il utilise Glamor pour le rendu, et évite ainsi la plupart des problèmes de performance inhérents à la superposition de surfaces (layering) des systèmes de fenêtrage.

systemd

L’intégration de la prise en charge de systemd permet à ce dernier de lancer et gérer X.Org, améliorant la vitesse de démarrage et la fiabilité.

Sécurité : exécution sans les droits du super utilisateur

Le serveur X.Org est maintenant exécutable sans les droits du super utilisateur root, avec l’aide de systemd-logind. Cela signifie aussi qu’il doit être lancé à partir du même terminal virtuel que celui utilisé pour s’identifier. La redirection sur la sortie erreur standard stderr casse également la connexion sans droits root. L’ancien comportement d’exécution avec les droits du super utilisateur peut être restauré par le fichier de configuration Xorg.wrap (man xorg.wrap). Notez que le lancement du serveur X par un gestionnaire de connexion (GDM, KDM…) ne fournit pas encore l’accès sans les droits du super utilisateur.

Amélioration du code

Des milliers d’avertissements du compilateur ont été supprimés. Nous ajoutons lentement de plus en plus d’options au compilateur pour que la compilation du serveur X.org nous indique les pratiques dangereuses dans le code. La version 1.16 s’occupe enfin de l’énorme liste de ces avertissements.

Glamor pour Xephyr

Xephyr est une implémentation de X s’exécutant sur un autre serveur X. Xephyr sert d’environnement de développement principal pour Glamor, notre nouveau sous‐système d’accélération 2D, permettant un cycle de développement et de test rapide sur une seule machine.

Gestion des matériels non PCI

De nombreux périphériques d’affichage ne sont pas listés avec les API PCI standards ; désormais le serveur X peut les auto‐détecter et les configurer, comme il le fait pour des systèmes plus conventionnels.

Conclusion

Pour la première fois depuis plusieurs versions, il y a eu des ajouts de code considérables à X.Org, parmi lesquels deux tiers concernent le code de Glamor.

Télécharger ce contenu au format Epub

Lire les commentaires

Catégories: Nouvelles du Libre

GOG.com distribue maintenant des jeux pour GNU/Linux

Linuxfr - jeu, 07/08/2014 - 09:12

Le service de distribution et de vente de jeux vidéo en ligne sans DRM GOG.com annonce l’ajout de GNU/Linux aux plateformes pris en charge.

Pour rappel, « le service vend des vieux classiques sur PC mis à jour pour tourner sans encombre sous les dernières versions de Windows. » et depuis mars 2012 propose des titres plus récents comme The Witcher 2, Alan Wake, et Assassin's Creed entre autres. Merci Wikipédia francophone et anglophone.

Outre l’ajout d’une nouvelle plateforme prenant en charge GNU/Linux, on apprend que 50 jeux sont déjà disponibles pour GNU/Linux, dont 23 (et un en préparation) pour la première fois disponibles sous GNU/linux.

La prise en charge de GNU/Linux était l’un des souhaits les plus populaires sur la liste de souhaits de la communauté, ce qui a donc poussé GOG.com à la concrétiser.

Le 18 mars 2014, GOG.com annonce qu’il commence à y travailler, et que cela arrivera quand 100 jeux seront disponibles pour GNU/Linux. Finalement, le 24 juillet 2014, GOG.com annonce qu’il ne sert à rien d’attendre plus et que 50 jeux sont déjà disponibles pour cette nouvelle plateforme !

À cette occasion, plus de la moitié de ces jeux ont été mis en promotion avec 75% de remise sur leur achat pendant une semaine.

GOG.com distribue un .tar.gz indépendant de la distribution (reste à voir si effectivement cela fonctionne sans problème sur toutes les distributions), ainsi que des paquets DEB pour les versions LTS actuelles et futures d’Ubuntu et de Linux Mint.

GNU/Linux (ou en tout cas Ubuntu) devient une alternative de plus en plus crédible à Windows pour le jeu, et cette annonce ne fait que confirmer la tendance.

Et peut-être un jour, GNU/Linux première plateforme pour le jeu vidéo ?

Télécharger ce contenu au format Epub

Lire les commentaires

Catégories: Nouvelles du Libre

Sortie de Linux 3.16

Linuxfr - jeu, 07/08/2014 - 08:05

La sortie de la version stable 3.16 du noyau Linux vient d’être annoncée par Linus Torvalds. Le nouveau noyau est, comme d’habitude, téléchargeable sur les serveurs du site kernel.org. Le détail des évolutions, nouveautés et prévisions est dans la seconde partie de la dépêche.

Sommaire En Bref  Architecture
  • Unification de la hiérarchie des cgroups.
 Pilotes graphiques libres
  • AMD : meilleure performance et consommation plus basse grâce à BAPM ;
  • Intel : gestion des tampons graphiques alloués par malloc() ;
  • Nouveau : changements de fréquence expérimental pour les processeurs graphiques Kepler.
 Réseau
  • TCP Fast Open est maintenant disponible pour IPv6.
 Sécurité
  • Le bit NX est maintenant utilisé plus tôt dans le chargement des modules.
 Virtualisation
  • KVM permet de gérer Xen en virtualisation imbriquée.
La phase de test RC-1

La version RC-1 est sortie le 15 juin 2014.

Cela fait deux semaines que la phase d’intégration a commencé et que la RC1 est prête. Par conséquent, la phase d’intégration est finie.

Cette phase a été un peu inhabituelle, car cela fait seulement une semaine que la version 3.15 est sortie, et la première semaine a chevauché la dernière -RC de la version précédente ; mais cela ne semble pas avoir eu beaucoup de conséquences sur le développement. Tout semble normal et, s’il y a quelque chose à noter, c’est que cette phase a été plus grosse que d’habitude. Ce n’était tout de même pas une phase d’intégration aussi grosse que la 3.15, mais cela n’en était pas loin.

Tout cela semble habituel du point de vue des statistiques : deux tiers des changements concernent les pilotes (et un tiers de ceux‐ci concernent staging), la moitié restante correspond à des mises à jour d’architectures (avec ARM en tête, principalement les fichiers DTS — mais il y a aussi du MIPS, PowerPC, x86 et ARM64).

Mises à part les mises à jour de pilotes et d’architectures, un mélange habituel de changements : systèmes de fichiers (principalement ReiserFS, XFS, Btrfs, NFS), réseau, parties du cœur (mm, verrous, ordonanceur, traçage) et outils (performance et alimentation, mais aussi quelques tests).

Comme d’habitude, le résumé court des changements est beaucoup trop long pour être utile et inclus dans cette annonce ; mais, naturellement, vous pouvez regarder le détail dans Git. Je poste les « changements fusionnés » comme d’habitude, ce qui donne, je pense, une meilleure vision générale. Et, comme d’habitude, cela ne reflète pas nécessairement les honneurs dus aux personnes qui ont écrit le code, mais aux mainteneurs des sous‐systèmes qui me les ont envoyés. Pour les vrais honneurs, allez voir dans l’arbre de Git.

En avant, testez,

Linus

RC-2

La version RC-2 est sortie le 21 juin 2014.

C’est un jour plus tôt que d’habitude, mais demain cela risque de ne pas être possible pour moi, car je serai sur la route une bonne partie de la journée, donc allons‐y. Ces temps‐ci, la plupart des personnes envoient leurs demandes d’intégration et leurs correctifs pendant la semaine, donc ne pas publier un dimanche ne fera pas beaucoup de différence. De plus, ce n’est pas comme si je n’avais pas assez de modifications pour publier la RC2.

Bon, assez d’excuses. La 3.16-rc2 a été publiée et contient l’assortiment habituel de correctifs répartis sur l’ensemble du code. Ce qui est inhabituel à ce stade est de constater à quel point les changements concernant l’architecture SPARC sortent du lot (presque 40 % des correctifs en vrac), mais ce ne sont que des nettoyages d’avertissements.

De manière similaire, quelques modifications du DRM de Nouveau ressortent du côté taille. Mais, encore une fois, c’est principalement dû à des petites corrections de bogues de micro‐logiciels qui ont changé les fichiers générés. Les vrais changements sont peu importants.

Si l’on ignore ces deux grosses modifications inhabituelles (en termes de lignes de code), le reste semble normal. Il y a des modifications de pilotes, des mises à jour d’outils (particulièrement perf) et diverses autres mises à jour d’architecture (ARM, s390, UNICORE32, x86…). Et juste des trucs divers un peu partout : rtmutex, Btrfs, bla bla bla.

Le résumé de publication n’est pas minuscule, mais suffisamment petit pour être inclus ici, donc vous pouvez voir les détails si vous êtes intéressés.

S’il vous plaît, testez‐le donc,

Linus

RC-3

La version RC-3 est sortie le 29 juin 2014.

Nous sommes de retour à un emploi du temps dominical de publication, et les choses semblent raisonnablement normales.

Il y a peut‐être relativement moins de mises à jour de pilotes que d’habitude, dont la plupart sont assez petites, mais c’est probablement juste dû à la planification (par exemple, Greg n’a pas envoyé ses changements USB en staging cette semaine, donc les changements de pilotes sont principalement ceux des processeurs graphiques, du réseau et du son).

De fait, les diverses mises à jour d’architectures (MIPS, PowerPC, x86, ARM) dominent dans les différences, et il y a quelques autres mises à jour diverses. Nous avons des mises à jour de systèmes de fichiers (AIO, NFS et OCFS2), un petit lot de corrections d’Andrew sur la gestion mémoire, quelques trucs réseau, etc.

Le résumé de publication donne une bonne idée des changements. Les plus visibles pour les utilisateurs sont probablement le « dé‐cassage » des accès en lecture des périphériques à accès bloc sur les cibles 32 bits, et quelques corrections de régressions sur vDSO x86 qui posaient problème. Le reste n’affecte probablement, au final, que peu de personnes, mais ce sont des corrections appropriées…

Linus

RC-4

La version RC-4 est sortie le 6 juillet 2014.

Les choses se sont gentiment calmées et tout semble parfaitement normal. Peut‐être que ce calme a été dû, en partie, aux gens qui commencent à décoller pour l’été et (aux États‐Unis) la semaine du 4 juillet, mais quelle qu’en soit la raison, à la fois les journaux et les statistiques sur les modifications des fichiers semblent sympathiques et raisonnablement petits.

La plupart des modifications concernent les pilotes (pilotes graphiques, USB, SCSI et son), les systèmes de fichiers (Btrfs, ext4) et les mises à jour d’architectures (principalement ARM). Avec une poignée de divers trucs épars. Mais cela reste relativement limité.

Allez le tester,

Linus

RC-5

La version RC-5 est sortie le 13 juillet 2014.

Les choses ont l’air normales et, comme d’habitude, j’aurais aimé qu’il y ait un peu moins d’agitation, puisqu’il commence à être assez tard dans le cycle des versions candidates. Mais, honnêtement, ce n’est pas comme s’il y avait quelque chose qui fasse réellement froncer les sourcils.

La plupart des modifications concernent les pilotes — avec ACPI et pilotes graphiques qui ressortent du lot. C’est vraiment assez varié (HID, moniteurs matériels, sous‐système IIO, capteurs de température, pilotes d’horloge, libata, pinctrl, etc.). Il y a les mises à jour d’architectures habituelles (principalement ARM et un peu de PowerPC), un peu de corrections pour la documentation DocBook et quelques corrections de systèmes de fichiers (F2FS, kernfs et ext4). Avec aussi une poignée de petites corrections du cœur (principalement les cgroups).

En avant, testez,

Linus

RC-6

La version RC-6 est sortie le 20 juillet 2014.

Semaine après semaine, nous nous dirigeons vers ce qui est supposé être la dernière RC, mais, franchement, les modifications ne se calment pas comme elles le devraient.

C’était déjà vrai pour la RC5 — plus grosse que la RC4. Cela ne m’avait pas inquiété outre mesure, parce que la RC4 était plutôt petite. Mais maintenant la RC6 est sortie, et elle est plus grosse que la RC5, et elle ne contient pas que des modifications triviales.

Ce n’est pas comme cela que c’est supposé se passer.

Quoi qu’il en soit, la RC6 n’est pas si grosse, donc je ne suis pas vraiment inquiet, mais j’en arrive au point où je vais commencer à insulter les gens et vous crier dessus, si vous m’envoyez des choses qui ne sont pas adéquates pour les dernières publications de RC. Ça ne veut pas dire que des gens l’ont fait : bien que la RC6 soit plus grosse que je le souhaitais, je ne pense pas qu’il y ait trop de choses manifestement frivoles dedans. Mais je vais continuer de garder un œil dessus, et je vais commencer à être grincheux (ou PLUS grincheux) si je remarque que les gens ne sont pas sérieux concernant le fait d’essayer de calmer les choses.

Malgré tout, la RC6, elle‐même, finit par avoir des changements à peu près partout : pilotes (le principal étant du réseau, mais il y a du processeur graphique, il y a InfiniBand, nommez‐le comme vous voulez), les systèmes de fichiers (corrections NFS tardives, XFS, FUSE, GFS2, Btrfs), du code réseau de base, etc, etc. Ci‐joint le rapport résumé pour ceux qui sont intéressés par (un aperçu) des détails.

Donc, allez récupérer la dernière RC et donnez un coup de pied dans les pneus, pour voir si rien ne passe entre les fissures. OK ?

Linus

RC-7

La version RC-7 est sortie le 27 juillet 2014.

Je suis content de dire que les choses se sont un peu calmées, et les choses semblent être sur la bonne voie.

Ce qui n’était, en fait, pas du tout le cas au début de cette semaine — nous avions ce qui semblait être des bogues au cœur du code vraiment vicieux et, en plus du fait que la RC6 était plus grosse que les précédentes RC, je ne sentais vraiment pas bien cette publication pendant un moment.

Mais les bogues les plus « méchants » n’étaient, au final, pas du tout des bogues du noyau. L’un venait en réalité d’une erreur de compilateur NdT : la version de GCC de Debian était en cause (ce qui est toujours très effrayant, difficile à déboguer et très ennuyeux), et qui avait même une solution de contournement assez simple ce qui fait que nous n’avons pas eu à mettre des compilateurs sur listes noires. Un autre s’est avéré n’être qu’un faux positif, car lockdep était un peu trop agressif.

Nous avons évidemment effectué diverses vraies corrections là‐dedans, mais aucune n’a l’air spéciale ou inquiétante. Et la RC7 est finalement sensiblement plus petite que les RC précédentes, donc nous sommes clairement en train de nous calmer. Donc, contrairement à mes précédentes inquiétudes, ce pourrait être la dernière RC ; nous verrons comment la semaine prochaine se passera.

En chiffres, la RC7 se compose d’environ un tiers d’architectures (Xtensa, PowerPC, x86, s390, Blackfin), un tiers de pilotes (pilotes graphiques, média, réseau) et un tiers de divers (réseau, gestion mémoire). Mais c’est assez petit. Journal résumé en pièce jointe.

Linus

Version finale

La version finale est sortie le 2 août 2014.

Alors, rien de spécialement intéressant ne s’est passé cette semaine, et la version 3.16 est arrivée.

Et comme d’habitude (la version précédente faisant figure d’exception), cela signifie que la fenêtre d’intégration de la version 3.17 est évidemment ouverte. Pour la troisième fois consécutive, le calendrier craint, car j’ai un voyage à venir pendant la seconde semaine de la fenêtre. De nombreux autres développeurs principaux seront aussi en déplacement, car c’est juste avant le Kernel Summit de Chicago.

Donc nous verrons comment se passera la prochaine fenêtre d’intégration, mais je ne vais pas m’en préoccuper outre mesure. Si finalement je n’arrive pas à venir à bout des intégrations, je pourrai retarder dans la semaine du Kernel Summit, mais j’espère terminer la pluplart des grosses intégrations la semaine prochaine, avant tout départ en voyage, alors peut‐être qu’on n’en arrivera pas là. Il s’agit juste d’une information sur le fait que la fenêtre d’intégration pourrait être allongée.

Quoi qu’il en soit, revenons aux changements depuis la RC7 : ce sont vraiment d’assez petits changements épars, avec un tiers de modifications d’architectures, un tiers de pilotes et un tiers de « divers » (principalement gestion mémoire et réseau). Les trucs d’architecture sont de petites mises à jour d’ARM (surtout DT), quelques corrections de Xen pour x86, et diverses petites choses pour PowerPC. Le journal résumé des changements donne une bonne idée de genre de truc que c’est, mais ça ne représente en réalité que 83 commits (plus les fusions et le commit de publication), et dont environ un tiers d’entre eux marqués comme stables.

Bien que la version 3.16 ait semblé un peu incertaine pendant un moment, les choses se sont gentiment clarifiées, et il n’y avait aucune raison pour faire une version candidate supplémentaire comme je le craignais il y a quelques semaines.

Linus

Les nouveautés Architecture Problèmes avec GCC 4.9

Un bogue assez pénalisant a été repéré au sein de l’ordonnanceur par des développeurs du noyau. Lorsque ce dernier était compilé en mode débogage, le compilateur gcc ne compilait pas correctement la fonction load_balance() au sein de l’ordonnanceur, ce qui entraînait des comportements complètement inexplicables. Il s’agit d’un problème datant de gcc 4.5 et qui se serait manifesté avec la sortie de gcc 4.9 et 4.9.1, suite à l’activation de certaines optimisations. Le problème est maintenant corrigé dans la version de développement de gcc. En attendant, une solution de repli a été trouvée, il s’agit de compiler le noyau avec l’option -fno-var-tracking-assignments, ce qui cache l’existence du bogue.

Pour plus de détails, consultez le commit.

Unification de la hiérarchie des cgroups

L’architecture actuelle des cgroups permet de créer plusieurs hiérarchies dans lesquelles on va pouvoir regrouper les processus et leur appliquer des restrictions lorsque ces hiérarchies sont spéciales, c’est‐à‐dire associées à des contrôleurs (options passées lors du montage). En pratique, cette hiérarchie est visible sous la forme d’un pseudo‐système de fichiers :

$ ls -l /sys/fs/cgroup total 0 dr-xr-xr-x 2 root root 0 Aug 7 01:52 blkio lrwxrwxrwx 1 root root 11 Aug 6 12:03 cpu -> cpu,cpuacct lrwxrwxrwx 1 root root 11 Aug 6 12:03 cpuacct -> cpu,cpuacct dr-xr-xr-x 2 root root 0 Aug 7 01:52 cpu,cpuacct dr-xr-xr-x 2 root root 0 Aug 7 01:52 cpuset dr-xr-xr-x 2 root root 0 Aug 7 01:52 devices dr-xr-xr-x 2 root root 0 Aug 7 01:52 freezer dr-xr-xr-x 2 root root 0 Aug 7 01:52 memory dr-xr-xr-x 2 root root 0 Aug 7 01:52 net_cls dr-xr-xr-x 4 root root 0 Aug 7 01:52 systemd $ tree /sys/fs/cgroup/systemd /sys/fs/cgroup/systemd ├── cgroup.clone_children ├── cgroup.procs ├── cgroup.sane_behavior ├── notify_on_release ├── release_agent ├── system.slice │   ├── cgroup.clone_children │   ├── cgroup.procs │   ├── dbus.service │   │   ├── cgroup.clone_children │   │   ├── cgroup.procs │   │   ├── notify_on_release │   │   └── tasks ... │   ├── home.mount │   │   ├── cgroup.clone_children │   │   ├── cgroup.procs │   │   ├── notify_on_release │   │   └── tasks ... ├── tasks └── user.slice ├── cgroup.clone_children ├── cgroup.procs ├── notify_on_release ├── tasks └── user-1000.slice ├── cgroup.clone_children ├── cgroup.procs ├── notify_on_release ├── session-1.scope │   ├── cgroup.clone_children │   ├── cgroup.procs │   ├── notify_on_release │   └── tasks ├── tasks └── user@1000.service ├── cgroup.clone_children ├── cgroup.procs ├── notify_on_release └── tasks ...

Ici, la hiérarchie systemd n’est associée à aucun contrôleur, alors que les autres imposent des contraintes sur l’utilisation de la mémoire, du processeur…

Tout ceci est donc très flexible mais difficile à gérer lorsque l’on veut modifier de façon cohérente les restrictions appliquées à un groupe de processus ou ajouter des restrictions à un groupe qui n’en avait pas auparavant. Cette complexité est avantageusement masquée par systemd, qui se charge actuellement de la gestion des cgroups en proposant des options plus accessibles dans les fichiers d’unit pour les services (systemd.resource-control — Resource control unit settings).

Ainsi, il a été décidé de se débarrasser de cette séparation en plusieurs hiérarchies pour regrouper tous les contrôleurs dans une seule hiérarchie. Cela permet d’inclure dans l’architecture même de cette hiérarchie toutes les opérations que systemd fait actuellement afin d’éviter cette complexité.

Cette hiérarchie unifiée est disponible dans le noyau 3.16, mais elle n’est pas activée par défaut. Il faut monter le pseudo‐système de fichiers contrôlant les cgroups avec les options :

$ mount -t cgroup -o __DEVEL__sane_behavior cgroup <mount-point>

Il est pour l’instant possible d’utiliser les deux hiérarchies simultanément pour tester le comportement de la nouvelle version, mais cela ne sera bien entendu plus possible dans les prochaines versions.

Cette unification introduit aussi la notion de délégation : un processus privilégié (systemd) pourra déléguer le contrôle d’une partie de la hiérarchie à un autre processus, par exemple à un processus systemd dans un conteneur (LXC, Docker, systemd-nspawn), voire à un processus systemd pour la session d’un utilisateur.

Plus d’informations sont disponibles dans l’article de LWN (The unified control group hierarchy in 3.16), ainsi que dans la documentation officielle (Cgroup unified hierarchy) qui décrit notamment comment se servir de cette nouvelle hiérarchie.

Système mono‐puce ARM (SoC ARM)

Cette version intègre pas mal de nouveautés sur les plates‐formes ARM.

La carte de développement NVIDIA Jetson TK1 dispose désormais d’un début de prise en charge. Il s’agit d’une carte embarquée dotée d’un processeur graphique NVIDIA Kepler avec 192 cœurs CUDA, un processeur quadruple‐cœur basé sur l’ARM Cortex A15, 2 Gio de mémoire vive, USB 3, mini‐PCIe. Bref, une véritable machine de guerre. Les cartes NVIDIA Tegra Note 7 et Shield sont intégrées à l’arborescence matérielle Device Tree (DT) et disposent également d’une prise en charge initiale pour cette version.

La gestion multi‐plate‐forme des cartes Samsung Exynos est désormais en place. Il s’agit d’une spécificité des plates‐formes ARM au sein du noyau Linux qui permet à une même image noyau de pouvoir s’exécuter sur différents systèmes mono‐puces (SoC) d’une même famille de processeurs, ou à un même pilote de périphérique de pouvoir fonctionner sur différents matériels tout en gardant un cœur générique et indépendant de la machine ou de la carte embarquée sur laquelle il tourne. Cela évite de devoir mettre en dur dans le code des informations spécifiques au matériel. C’est notamment possible grâce à l’utilisation du Device Tree. Les familles de processeurs ARM qui disposent de cette fonctionnalité sont de plus en plus nombreuses, on peut notamment citer : Samsung Exynos, Freescale i.MX, NVIDIA Tegra, Texas Instruments OMAP ou encore ceux de Rockchip.

Parmi les nouveautés les plus marquantes, nous pouvons également noter la gestion du Symmetric MultiProcessing (SMP) pour les Marvell Armada 375/38x et les Allwinner A31, ainsi que l’arrivée de la prise en charge de nouveaux systèmes mono‐puces : Freescale i.MX6SX, LSI Axxia AXM55xx et Samsung Exynos 3250, 5260, 5410, 5420 et 5800. Pour plus de renseignements concernant les nouvelles fonctionnalités ARM pour cette version, je vous invite à regarder le commit plus en détail.

MIPS

Pas mal de nouveautés sont au rendez‐vous pour l’architecture MIPS. La para‐virtualisation fait son apparition au sein de Linux 3.16. Le nombre maximum de processeurs se voit augmenté de 64 à 256.
Il est maintenant possible d’éteindre la carte d’évaluation Malta, qui dispose d’un mode d’extinction logiciel (c’est‐à‐dire générique et non propre à la carte).

Un début de gestion de l’Octeon 3 a également été ajouté. L’Octeon 3 est le nouveau processeur de Cavium annoncé en fin d’année 2013. Il s’agit d’un processeur multi‐cœur basé sur les processeurs MIPS 64 bits, gravé en 28 nm et orienté calcul haute performance.

Pour plus de renseignements, lire la demande d’intégration.

ARM64 big.LITTLE dans cpufreq

Une nouveauté assez intéressante est l’ajout du mode big.LITTLE de la dernière famille de processeurs ARMv8 au sein du pilote CPUFreq. Le mode big.LITTLE est une nouvelle technologie dite « d’optimisation de gestion de l’énergie » qui permet au processeur ARM de disposer d’un maximum de performances lorsqu’il en a besoin, tout en préservant au maximum son énergie lorsque cette puissance n’est pas nécessaire. Pour ce faire, le système mono‐puce est doté de plusieurs cœurs destinés au calcul intensif (BIG) et d’autres qui consomment moins d’énergie qui sont destinés à faire tourner les tâches moins gourmandes en ressources (LITTLE). Le système mono‐puce fait connaître ses cœurs de processeurs BIG et LITTLE au système d’exploitation afin que les tâches puissent migrer à chaud d’un cœur de calcul à l’autre en fonction de la charge du cœur sur lequel il se trouve, mais aussi en fonction de son « historique » logiciel d’exécution, ce qui permet à l’ordonnanceur de pouvoir anticiper ses décisions.

Il ne s’agit là que d’une gestion au sein de CPUFreq lui permettant ainsi de décider quel cœur doit être activé et quel cœur doit être éteint, et ainsi gérer les « niveaux de puissance » (power states) en conséquence. Les futurs changements concernant l’ordonnanceur devraient voir le jour dans les prochaines versions.

EFI Stub

L’architecture ARM 64 bits dispose désormais de la gestion d’EFI stub. L’EFI stub de Linux permet à un système disposant d’un micrologiciel (U)EFI de démarrer l’image du noyau directement sans avoir à passer par un chargeur d’amorçage (tel que GRUB ou elilo). Ceci est notamment possible en ajoutant du code au début de l’image du noyau afin de faire croire au micrologiciel (U)EFI qu’il s’agit d’une image de type PE/COFF, de cette façon le noyau se fait passer pour un exécutable (U)EFI. Pour plus de renseignements, voir la demande d’intégration.

AMD Seattle

Le nouveau système mono‐puce ARM 64 bits Opteron A1100 d’AMD, baptisé Seattle, se voit pris en charge par cette nouvelle version du noyau. Il s’agit du premier système mono‐puce ARM de chez AMD, destiné à équiper les serveurs à basse consommation d’énergie dédiés à la gestion de données massives (ce qu’on appelle communément le « big data »). Cette puce comprend huit cœurs ARM Cortex A57 cadencés à plus de 2 GHz chacun, gère jusqu’à 128 Gio de mémoire vive, intègre la technologie ARM TrustZone, un bus PCIe doté de huit voies, deux ports Ethernet 10 Gbit/s, de co‐processeurs cryptographiques et de compression‐décompression. Selon AMD, La série A de Opteron irait jusqu’à deux à quatre fois plus vite que la série X et disposerait d’un bien meilleur rendement énergétique (rapport performance / consommation). Le meilleur étant, bien entendu, pour la fin : le prix !

x86 : Intel Broadwell dans P-State

La future génération de processeurs de chez Intel, baptisée Broadwell est maintenant prise en charge dans le pilote P-State.

Pour rappel, P-State est le nouveau pilote Intel au sein du noyau Linux qui permet de contrôler plus finement les tensions électriques et les fréquences des éléments du processeur, afin gérer plus efficacement la consommation énergétique (notamment comparé au pilote de CPUFreq).

Pilotes graphiques libres DRM (Direct Rendering Manager)

Contrairement à Linux 3.15, le code commun aux pilotes graphiques libres (DRM) a reçu peu d’attention dans cette version. Les modifications les plus intéressantes dans l’immédiat sont une mise à jour de la documentation et la correction d’une situation de concurrence (race condition) dans le nommage des connecteurs et des encodeurs. Pour finir, la gestion des verrous a été revue en préparation du travail sur la gestion atomique du mode graphique.

Cette gestion atomique du mode graphique est un saint Graal en discussion depuis au moins 2012. Une présentation claire a été donnée au FOSDEM 2013 qui explique l’intérêt d’avoir une interface transactionnelle pour la gestion du mode graphique afin de respecter le mantra de Wayland, qui est que toute image doit être parfaite, même lorsque l’on modifie des plans d’affichage graphique.

Pour plus d’informations, vous pouvez consulter la demande d’intégration DRM.

Adreno (pilote msm)

Peu de nouveautés pour Adreno dans cette nouvelle version, si ce n’est l’ajout d’outils de débogage à destination des développeurs.

La nouveauté majeure est l’ajout d’une gestion très partielle des compteurs de performance, exposés dans debugfs. Les compteurs exposés sont le temps d’activité du processeur graphique, ALUACTIVE et ALUFULL.

Toujours dans debugfs, il est maintenant possible de récupérer les commandes envoyées avec les numéros de barrières (fences) associées. Il est aussi possible de connaître l’état des registres, afin de pouvoir retrouver quel groupe de commandes a planté le processeur graphique.

Pour plus d’informations, vous pouvez consulter la demande d’intégration msm.

AMD/ATI (pilote radeon)

La nouveauté principale du pilote Radeon est l’ajout de la gestion du Deep Color. Au lieu d’utiliser 8 bits par composante (rouge, verte ou bleu), il est maintenant possible d’utiliser 10 ou 12 bits par composante pour les écrans qui le gèrent. Comme certains écrans disent, à tort, gérer cette fonctionnalité, celle‐ci a été désactivée par défaut jusqu’à ce que tous les bogues aient été corrigés. Si vous voulez tester cette fonctionnalité pour vérifier qu’elle n’ajoute pas de régression ou qu’elle fait ce qui est attendu, vous devez rajouter le paramètre noyau « deep_color=1 » pour le module radeon.

Une optimisation de la mémoire virtuelle pour la gestion des tampons graphiques situés dans le tableau de réadressage de la mémoire graphique (Graphics Address Remapping Table — GART) a été également été ajoutée à cette version pour les familles Southern Islands et Sea Islands. Le programme d’évaluation Unigine Tropics a mesuré un gain de performances jusqu’à 34 %.

Des corrections de bogues ont imposé l’activation permanente du BAPM (Bidirectional Application Power Management) pour certaines puces graphiques d’AMD. Le BAPM est une gestion de la consommation énergétique plus fine (plus granulaire) remplaçant l’ancienne DPM (Dynamic Power Management) aux seuils de déclenchement plus larges. BAPM est désormais activée implicitement. Ce système agit sur la fréquence de fonctionnement de la puce qui peut passer rapidement, par exemple, de 3,4 GHz à 1,4 GHz par des seuils plus fins qu’avec DPM. Plus la fréquence est basse, moins on consomme. Malgré son caractère expérimental, cette fonction indispensable pour les portables et mobiles est désormais activée en permanence sur les puces de type Trinity, car ces systèmes plantaient souvent lorsque le DPM était activé.
De même, le DPM classique activé (radeon.dpm=1) empêchait le démarrage des systèmes à base de puces compatibles ARUBA, même avec l’alimentation secteur, et principalement dans les APU. Non seulement, le BAPM a permis une meilleure gestion de l’énergie des puces ARUBA, mais il a également accru significativement leur performance.

Pour plus d’informations, vous pouvez consulter les demandes d’intégration Radeon [1] et [2].

Intel (i915)

La nouveauté principale du pilote Intel dans cette version est la possibilité pour une application de créer un tampon graphique à partir d’un tampon alloué avec malloc(). Cela permet d’éviter de faire des copies lors de transferts vers ou depuis le processeur graphique, et donc d’améliorer les performances en réduisant les latences. Jérôme Glisse a réagi et exprimé son mécontentement, car ce correctif change radicalement la gestion de la mémoire et est probablement peu sûr. Il a proposé une explication de comment une erreur pourrait se produire, mais le correctif a quand même été accepté. Celui‐ci devrait améliorer les performances des compositeurs graphiques en évitant la recopie des fenêtres exposées par mémoire partagée au compositeur.

Le pilote i915 continue sa transformation progressive vers la commutation atomique de page mémoire (atomic page flipping) et l’exposition de ses plans d’affichage graphique, sans que ce soit pour l’instant utilisable par les utilisateurs. Cependant, il est maintenant possible d’utiliser des curseurs de 256 × 256 pixels au lieu de 64 × 64, ce que les possesseurs d’écrans à haute densité de pixels, tels que le Retina d’Apple, devraient apprécier. Pour l’exploiter, il vous faudra utiliser une version Git de xf86-video-intel et l’architecture SNA.

Une première version de la gestion du Connected Standby (alias InstaGo) est maintenant disponible. Celle‐ci est équivalente à une mise en veille de la machine, mais les applications peuvent réveiller la machine sans intervention de l’utilisateur. Sous Windows, cette fonctionnalité désactive la possibilité de faire une mise en veille en mémoire ou sur le disque et nécessite à la fois un micro‐logiciel UEFI et une carte réseau compatibles. Les pré‐requis pour Linux ne sont pas encore connus.

Le pilote i915 a maintenant plus de chance de survivre à une situation où il manquerait de mémoire. Dans le cas où il survivrait, plus d’informations seront disponibles pour diagnostiquer la raison.

Une gestion préliminaire de la 3D pour les nouveaux systèmes mono‐puces Atom Cherryview, qui devrait sortir en septembre 2014, a été ajoutée. Son unité de rendu est basée sur les processeurs Broadwell (sortie prévue fin 2014), alors que le bloc d’affichage est une version améliorée de celui de la génération précédente, Valleyview. Mesa 3D a déjà été modifié afin de gérer ces nouveaux systèmes mono‐puces.

En parlant de Valleyview, celui‐ci a reçu beaucoup d’attention pour corriger de multiples bogues. Cependant, l’amélioration la plus importante est la gestion des écrans MIPI DSI. Cela permettra de faire fonctionner l’Asus T100 correctement, sans bidouille !

Les processeurs de la famille Broadwell gèrent maintenant l’eDRAM, qui sert à fournir 128 Mio de cache de niveau 4 pour les processeurs Iris Graphics basés sur Broadwell, la technologie boost, ainsi que le décodage vidéo matériel grâce au moteur VEBOX2.

Comme à son habitude, Daniel Vetter (mainteneur i915) a publié un compte rendu des modifications sur son blog, que vous pouvez lire pour plus d’informations. Vous pouvez aussi consulter la demande d’intégration i915.

NVIDIA (pilote nouveau)

La nouveauté principale de Nouveau dans cette version est la réécriture de la gestion du DisplayPort, ce qui a permis de corriger énormément de bogues et permet enfin aux moniteurs de se mettre en veille et de pouvoir en sortir.

Le changement de fréquence manuel est maintenant activé par défaut pour les cartes des familles NV40 (GeForce 7), NVAA/NVAC (ION) et NVE0 (Kepler). Cette gestion est expérimentale et est à utiliser à des fins de test uniquement [commit]. Phoronix a fait quelques bancs de test utilisant cette nouvelle capacité. Toutes les cartes n’ont pas réussi à être re‐cadencées à leur vitesse maximale, mais quand elles l’étaient, les performances étaient améliorées la plupart du temps d’un facteur 4, et jusqu’à 5,8 pour OpenArena. Ce n’est cependant pas suffisant pour atteindre la vitesse du pilote propriétaire, puisque sur les puces de la famille Kepler, Nouveau n’atteint à fréquences égales que de 59 % à 80 % des performances du pilote NVIDIA.

La gestion du GK20A (processeur graphique intégré aux Tegra K1 basé sur Kepler) fait enfin son entrée dans Nouveau grâce au travail d’Alexandre Courbot de NVIDIA. Cette gestion est conditionnelle à l’utilisation des microcodes de NVIDIA pour la gestion des contextes graphiques, jusqu’à ce qu’un contributeur fasse le travail de rétro‐ingénierie ou jusqu’à ce que NVIDIA donne le droit à Nouveau de redistribuer le microcode.
En l’état actuel, il devrait donc être possible de créer un contexte graphique et faire du rendu dans une texture. Cette texture pourra ensuite être envoyée via Prime (dma-buf) au pilote host1x qui gère l’affichage, mais pas avant Linux 3.18. La gestion de la mémoire est actuellement expérimentale et est en train d’être améliorée par Alexandre. Côté espace utilisateur, il vous faudra attendre la sortie de la prochaine version de Mesa 3D qui devrait arriver aux alentours de la conférence des développeurs de X.Org XDC 2014, qui aura lieu à Bordeaux du 8 au 10 octobre 2014. D’après Alexandre, ce processeur graphique devrait être utilisable dès Linux 3.18.

En parlant de microcode de gestion des contextes graphiques, celui du jeu de puces GK208 a été corrigé afin de pouvoir gérer les unités (shaders) de géométrie.

Pour finir, les cartes GeForce GTX 780 Ti et Tesla K40 (GK110B) sont maintenant gérées par Nouveau grâce au travail d’un contributeur externe à Nouveau. Celui‐ci a également activé le décodage vidéo matériel sur les puces GK110, GK110B et GK208 [noms de code].

Samsung (pilote exynos)

Plusieurs corrections de bogues liés à la gestion de l’horloge et de la synchronisation verticale. Pour une liste plus détaillée des changements, vous pouvez consulter la demande d’intégration exynos.

Pour continuer sur la gestion des pointeurs utilisateur, Jérôme a proposé de désactiver complètement sa gestion, car son implémentation actuelle n’était pas sûre. Le mainteneur du pilote DRM Intel a approuvé. Espérons que cette gestion sera réécrite dans Linux 3.17 ou désactivée.

En vrac
  • Aspeed (Ast) : Ajout de la gestion de l’AST2400.

  • Freescale (ipuv3) : Le pilote ipuv3, pour les processeurs graphiques Freescale i.MX IPUv3, quitte la branche staging et intégre la branche /drivers/gpu/. Ce pilote ne respecte cependant pas le standard DRM, probablement parce qu’il ne propose pas d’affichage, comme Tegra.

  • Tegra (pilotes host1x et tegra) : Ajout de la gestion des curseurs et du HDMI pour les Tegra 124 (K1).

Réseau

Le TCP Fast Open, ajouté dans Linux 3.13 pour l’IPv4, est maintenant disponible pour l’IPv6 [commit].
Pour mémoire, le TCP Fast Open permet de diminuer le temps de connexion à un service lorsque plusieurs connexions vers celui‐ci sont ouvertes. Avec TCP Fast Open, le serveur n’attend plus que le client émette l’acquittement final avant d’envoyer des données à l’utilisateur. D’un point de vue latence, cela permet d’ouvrir la connexion avec un seul aller, au lieu d’un aller, un retour et un nouvel aller. Cela peut être très efficace pour réduire drastiquement le temps des chargements des pages Web lorsque le réseau d’accès à Internet a une grosse latence.

Une émulation logicielle du TCP Segmentation Offload (TSO), c’est‐à‐dire du délestage de la segmentation TCP, a été ajoutée au noyau et permet à des systèmes mono‐puces d’augmenter leur débit maximal de 16 % à 54 %, tout en réduisant l’utilisation processeur de 40 % dans un test de performance basé sur HTTP (commits : 1 et 2). En principe, le TSO consiste à envoyer l’ensemble des données à transmettre à la carte réseau et laisser celle‐ci découper les paquets. Cela permet de limiter la consommation processeur sans perdre de performance.

AMD a ajouté la gestion d’une nouvelle carte Ethernet permettant d’atteindre 10 Gbit/s. Le pilote de cette carte s’appelle "amd-xgbe" et celle‐ci fera partie du système mono‐puce Seattle (commits : [1], [2], [3] et [4]).

Sécurité Liste non exhaustive des vulnérabilités corrigées : Bit NX et chargement des modules

Les zones mémoire utilisées pour stocker le code et les données d’un module sont protégées respectivement en lecture seule (RO) et en non exécution (NX) à l’aide de la technologie du bit NX présente dans les processeurs x86 modernes. Jusqu’à présent, ces protections étaient mises en place assez tard dans le chargement d’un module par le noyau. Elles sont maintenant activées avant que les arguments passés lors du chargement du module soient analysés, c’est‐à‐dire juste avant la première exécution de code appartenant au module en cours de chargement [correctif]. Cela améliore légèrement la sécurité, en diminuant l’impact d’une erreur dans le code analysant les arguments passés à un module.

Compilation à la volée des filtres seccomp

Les filtres seccomp peuvent maintenant profiter du compilateur à la volée (JIT — Just In Time) qui a été ajouté pour le langage BPF [correctif]. Ce langage ne servait au départ que pour le filtrage des paquets réseau, mais il a été étendu et est utilisé par plusieurs sous‐systèmes du noyau (voir BPF: the universal in‐kernel virtual machine et Extending extended BPF).

IMA et EVM

L’utilisation du mode O_DIRECT pour accéder aux fichiers contrôlés par une politique IMA — Integrity Measurement Architecture — pouvait provoquer un interblocage. Ce problème n’est pas encore complètement résolu, mais une solution temporaire a été trouvée pour autoriser un administrateur à désactiver dans la politique de sécurité le contrôle d’IMA pour certains fichiers lorsque le mode O_DIRECT est utilisé [correctif].

La méthode de calcul des signatures HMAC utilisées par EVM — Extended Verification Module — a été modifiée [correctif] pour permettre plus facilement l’ajout de nouveaux attributs étendus (par exemple ceux de SMACK) [correctif]. L’accès à l’attribut étendu qui stocke cette signature est maintenant restreint [correctif].

Un bogue pouvant provoquer des « kernel oops » lorsqu’IMA était utilisé avec AppArmor a été corrigé [correctif].

LSM SELinux

Les informations présentes dans les messages d’erreur d’accès SELinux les AVC — Access Vector Cache — ne permettaient pas de savoir si l’accès avait été réellement bloqué ou s’il avait été autorisé parce que le système ou le type était en mode permissif. Un nouvel élément permissive= permet d’obtenir cette information [correctif].

Lorsqu’un processus fait appel à exec(), le contexte SELinux reste par défaut celui du père, mais il peut être changé si la politique le précise et que le contexte du fichier exécuté correspond (transition de domaine à l’exécution). Une troisième façon de définir le contexte d’exécution SELinux d’un processus à l’avance est d’utiliser l’appel setexeccon(). Dans le cas où un programme tentait un exec() d’un fichier dans un système de fichiers monté avec l’option nosuid, cette transition n’était pas effectuée, mais aucune erreur n’était retournée. Le code d’erreur -EACCES est maintenant retourné dans ce cas [correctif].

SMACK

Note : Si vous avez du mal à faire la correspondance entre les accès autorisés et les étiquettes SMACK, je vous conseille de vous référer à la documentation.

Pour rappel, SMACK — Simplified Mandatory Access Control Kernel — stocke les règles de contrôle d’accès aux objets représentés dans l’arborescence du système dans les attributs étendus (dans l’espace de noms security). Il n’est pour l’instant pas possible d’utiliser les attributs étendus avec les pseudo‐fichiers décrivant les cgroups. Ces pseudo‐fichiers sont donc étiquetés par défaut avec l’étiquette « * », ce qui signifie qu’aucun contrôle supplémentaire n’est effectué par SMACK (tous les accès sont autorisés par SMACK). Ce contournement est nécessaire pour faire fonctionner systemd avec SMACK (probablement dans le cadre du projet Tizen) [correctif].

Certaines opérations effectuées sur des descripteurs de fichiers ouverts en écriture seule peuvent être apparentées à des opérations de lecture. En effet, les appels système fstat() et lseek(), par exemple, permettent d’obtenir des informations sur l’état du fichier ouvert et peuvent donc être considérés comme des opérations de lecture. SMACK autorisait ces appels système si le descripteur de fichier était ouvert en écriture seule et que les étiquettes SMACK autorisaient l’opération write(). Ce comportement pouvait potentiellement mener à la création d’un canal d’information caché qui n’est pas contrôlé par SMACK. Il n’est donc plus possible d’ouvrir un descripteur de fichier en écriture si l’on ne dispose pas aussi des droits SMACK pour l’ouvrir en lecture (on peut par contre ne pas disposer des droits DAC en lecture) [correctif].

Une modification du même style avait été ajoutée à SMACK dans le noyau 3.13 (cf. Sortie de Linux 3.13 au paragraphe SMACK). Dans le cas précédent, une nouvelle opération avait été ajoutée pour gérer correctement le cas de figure, mais ici les appels système fstat() et lseek() ne sont pas contrôlés par les hooks LSM, donc ce n’est pas une solution possible actuellement.

Pour pouvoir envoyer une information par l’intermédiaire d’une communication inter‐processus (IPC), SMACK vérifie que le processus émetteur dispose du droit d’accès SMACK write sur le destinataire. Dans le cas des sockets UNIX (UNIX domain socket) la vérification est faite uniquement à la connexion et n’était faite que dans un sens (du processus ouvrant le socket vers le processus ayant créé le socket, et pas l’inverse). C’est maintenant corrigé [correctif].

Le retrait de l’attribut SMACK64TRANSMUTE d’un dossier n’avait pas l’effet désiré. C’est maintenant corrigé [correctif].

L’affectation d’une chaîne vide comme valeur à un attribut étendu ne provoque plus de panique du noyau [correctif].

Un utilisateur doit avoir la capacité CAP_MAC_ADMIN pour pouvoir enlever les attributs étendus SMACK d’un fichier. Il était possible, par erreur, d’enlever l’attribut étendu SMACK64MMAP. C’est maintenant corrigé [correctif].

Une entrée ptrace() a été ajoutée au pseudo‐système de fichiers permettant de contrôler le comportement de SMACK. Elle permet de régler le niveau de sécurité requis pour pouvoir utiliser l’appel système ptrace() [correctif]. Les vérifications liées à l’appel ptrace() ont été regroupées [correctif]. Un bogue inversant la vérification lors d’un appel à ptrace() a été corrigé [correctif].

Les vérifications effectuées lors de l’accès au trousseau de clefs stocké dans le noyau ont subi une correction. Elles étaient incorrectes car une clé avec une étiquette « _ » ne pouvait être lue alors qu’elle aurait dû être accessible par tout le monde [correctif].

Systèmes de fichiers

Le nettoyage et la réorganisation de code sont des points importants sur le long terme. Quelques fichiers concernant les couches en mode bloc de VFS passent ainsi de l’arborescence fs/ et mm/ vers le dossier fédérateur block/.

XFS

Du côté de chez XFS, Dave Chinner nous apprend que le code a subi un nettoyage et un peu de réusinage.

Btfrs

Le plus gros changement dans cette version est la refonte du calcul des quotas que Josef Bacik a effectuée et qui améliore le suivi en mémoire des opérations extent en attente.

Chris Mason a travaillé de son côté sur l’utilisation de la pile Btrfs, car il est devenu impossible d’effectuer les longs tests de charge avec slab(), lockdep() et pagealloc() en mode debogage, sans faire exploser la pile.

Enfin, il y a les habituelles corrections de bogues, le lot d’optimisation et de nettoyage de code.

Pour plus de détails, il est possible de consulter le rapport résumé.

Phoronix nous offre quelques tests de performances (ici et ), et le bilan est assez simple : il n’y a pas de changements statistiquement notables.

F2FS

Jaegeuk Kim nous indique que Samsung s’affaire toujours à améliorer ce système de fichiers.

Il prend en charge des partitions de taille supérieure à 2 Tio correctement, tout en améliorant la gestion du readahead. Pour rappel, cette lecture anticipée permet de précharger un fichier dans la mémoire vive pour diminuer les temps de latence par la suite.

Enfin, le flush() des fichiers a été amélioré.

Reiser4

Ivan Shapovalov a continué à travailler sur l’implémentation du mécanisme de discard (mise au rebut), aussi connu sous le nom de TRIM. Celui-ci permet d’informer un SSD que des blocs mémoire sont inutilisés et peuvent être effacés.

Ce travail devrait permettre d’améliorer les performances de Reiser4 avec les SSD.

NFS

Neil Brown a corrigé NFS afin que les montages locaux (sur la même machine) fonctionnent correctement dans tous les cas de figure. Par ailleurs, la gestion XDR (eXternal Data Representation) a été réécrite afin de pouvoir gérer de grosses listes de contrôle d’accès (Access Control Lists) faisant plus de 4 Kio. De même, la fonction readdir() renvoie aussi des résultats pouvant faire plus de 4 Kio, ce qui améliore les performances pour les dossiers ayant un très grand nombre de fichiers.

Virtualisation KVM

Plus de 200 commits pour cette version, répartis un peu partout. Commençons avec x86, pour lequel on retrouve la virtualisation imbriquée pour Xen : c’est‐à‐dire qu’il est possible de faire tourner Xen dans une machine KVM tout en permettant la virtualisation matérielle de Xen. C’est une fonctionnalité principalement utile pour les migrations ou les tests.

Du côté des processeurs ARM, la publication des informations PSCI (Power State Coordination Interface) en version 0.2 est disponible avec les instructions ARMv8. Dans les noyaux précédents, seule la version 0.1 de PSCI était disponible. Ces instructions permettent d’améliorer la gestion de l’énergie, particulièrement quand plusieurs systèmes d’exploitation tournent sur un même système mono‐puce et qu’il faut qu’ils se coordonnent, par exemple pour savoir quand un processeur peut être éteint.

Dans le cas des processeurs POWER, la prise en charge de u-boot est disponible pour les systèmes embarqués, pour la version 8, la prise en charge des hôtes configurés en petit‐boutiste (Little Endian).

Et enfin, pour le S/390 (mainframe IBM), les principaux changements sont la prise en charge des migrations, ainsi que de débogueur GDB.

Pour la prochaine version, on attend un gros lot de commits pour le x86, et le retrait de l’architecture IA-64 (les Itanium).

Xen

Xen sous ARM gère désormais les deux fonctions suspend() et resume(). Côté réseau, l’interface virtuelle pour gérer le réseau prend désormais en charge le mode multi‐queue, ce qui améliore les performances réseau des machines virtuelles.

Le bilan en chiffres

En ce qui concerne les statistiques du cycle de développement de Linux 3.16, on peut se référer à la page dédiée du site remword.com qui compile des statistiques relatives au développement de Linux.

Le nombre final de correctifs incorporés dans cette version est de 12 802, soit légèrement en dessous des 13 720 correctifs de la précédente. Ces ajouts sont le résultat du travail d’environ 1 527 développeurs soit, là encore, une légère baisse par rapport aux 1 547 développeurs du noyau précédent.

C’est à nouveau Intel qui occupe la tête du classement des entreprises avec 10,52 % des correctifs, suivi de très près par Red Hat (10,37 %). Red Hat est, en revanche, l’entreprise qui signe le plus de correctifs, avec 11,85 % contre 10,25 % pour Intel.

Les hobbyistes occupent comme d’habitude la troisième place, avec 5,73 %, si l’on ne comptabilise pas les contributeurs dont l’affiliation est inconnue, qui représentent 18,01 % des contributions. Le développement de Linux est donc majoritairement sponsorisé par des entreprises, mais il reste encore de nombreux passionnés qui font ça pour eux.

Appel à volontaires

Jiehong, le mainteneur actuel de la partie Systèmes de fichiers va laisser sa place à une personne ayant plus de temps. Cette position est maintenant ouverte.

Cette dépêche est rédigée par plusieurs contributeurs dont voici la répartition :

Mainteneur Contributeur(s) La phase de test Aucun Mali, Julien Pecqueur Architectures Romain Perier Mali, Timothée Ravier Pilotes graphiques libres Martin Peres Réseau Florent F. Martin Peres Systèmes de fichiers Jiehong Mali, Julien Pecqueur Sécurité Timothée Ravier Virtualisation Xavier Claude Édition générale Aucun Martin Peres, Davy Defaud

Un peu de vocabulaire :

  • le mainteneur d’une section de la dépêche est responsable de l’organisation et du contenu de sa partie, il s’engage également à l’être dans le temps jusqu’à ce qu’il accepte de se faire remplacer ;
  • un contributeur est une personne qui a participé à la rédaction d’une partie d’une section de la dépêche, sans aucune forme d’engagement pour le futur.

Malgré cette équipe importante, beaucoup de modifications n’ont pas pu être expliquées par manque de temps. Si vous aimez ces dépêches et suivez tout ou partie de l’évolution technique du noyau, veuillez contribuer dans votre domaine d’expertise. C’est un travail important et très gratifiant qui permet aussi de s’améliorer. Il n’est pas nécessaire d’écrire du texte pour aider, simplement lister les commits intéressants dans une section aide déjà les rédacteurs à ne pas passer à côté des nouveautés. Essayons d’augmenter la couverture sur les modifications du noyau !

Télécharger ce contenu au format Epub

Lire les commentaires

Catégories: Nouvelles du Libre

1,2 milliard de mots de passe piratés ? Rien de surprenant

Toolinux - mer, 06/08/2014 - 23:26

Des pirates informatiques Russes viennent de réaliser « le casse du siècle » en récoltant 1,2 milliard de comptes utilisateurs (identifiants et mots de passe associés) et plus de 500 millions d'adresses e-mail, provenant de 4200 000 site Internet d'entreprises de toute taille.

- Revue de presse
Catégories: Nouvelles du Libre

Ateliers du Samedi Libre le 30 août à Marseille

Toolinux - mer, 06/08/2014 - 23:25

Le CercLL annonce un nouvel « atelier du Samedi Libre » le 30 août de 14h30 à 17h30. Ces ateliers se déroulent, en général, sur une séquence hebdomadaire, de 2 à 3 séances de travail et sur un thème déterminé.

- Evénements et séminaires
Catégories: Nouvelles du Libre

Base64 : encoder et décoder en ligne de commande

Toolinux - mer, 06/08/2014 - 23:21

Le codage de l'information en base64 signifie qu'une information va être encodée (et non chiffrée ou hashée) sur un alphabet de 64 caractères. Le base 64 est définie en tant qu'encodage MIME dans le RFC 2045, il est principalement utilisé pour la transmission de messages (courrier électronique et forums Usenet) sur l'Internet.

- Revue de presse
Catégories: Nouvelles du Libre

LibreOffice 4.3 est sorti

Linuxfr - mer, 06/08/2014 - 13:52

LibreOffice 4.3 vient d’être publié en ce 30 juillet 2014. Cette nouvelle version est destinée aux utilisateurs expérimentés — les autres, comme les entreprises et les administrations, sont invités à utiliser LibreOffice 4.2.6.


Michael Meeks est un développeur qui travaille sur la suite bureautique LibreOffice pour l’éditeur Collabora.

Il vient de publier sur son blog une longue description du travail de refactorisation et de nettoyage qui a eu lieu lors de ce cycle de développement menant à la version 4.3 de LibreOffice. Cette dépêche est une traduction de son article initialement publié dans le domaine public ou licence CC0, comme indiqué au bas de l’article.

Sommaire

Aujourd’hui, nous publions LibreOffice 4.3.0, livré avec beaucoup de nouvelles fonctionnalités que vous allez aimer. Vous pouvez lire et apprécier toutes les nouveautés visibles apportées par tant de développeurs. Mais il y a aussi des contributeurs dont le travail se fait principalement en arrière-plan et dont les résultats ne sont pas si faciles à voir. Pourtant ces développements sont aussi vitaux pour le projet. Mais il peut être difficile de les distinguer parmi les quatorze mille commits faits depuis LibreOffice 4.2, alors laissez‐moi détailler :

Interface utilisateur

La migration de l’interface utilisateur depuis les composants graphiques VCL vers Glade approche finalement de sa fin. Plus de deux cents boîtes de dialogues ont été converties dans cette version, les boîtes restantes étant les plus dures à trouver — de l’aide serait d’ailleurs appréciée. Grands mercis à Caolán McNamara (Red Hat) pour son incroyable travail ici, et également à Szymon Kłos, Michal Siedlaczek, Olivier Hallot (EDX), Andras Timar (Collabora), Jan Holesovsky (Collabora), Katarina Behrens, Thomas Arnhold, Maxim Monastirsky, Manal Alhassoun, Palenik Mihály, et beaucoup d’autres… Merci aussi à nos traducteurs qui ont aidé à la migration des chaînes de caractères.

Si vous souhaitez vous impliquer pour arriver à 100 % de conversion, allez voir le howto de Caolán et son superbe blog : 99 to go update (plus que 54 au 25 juillet), illustré par ceci :

Améliorations de la compilation

LibreOffice est beaucoup plus facile à compiler, et cette étape est mieux documentée — cela est important pour les nouveaux contributeurs

Prise en charge de Visual Studio

Non seulement Jesus Corrius a ajouté la prise en charge initiale de Visual Studio 2013, mais nous avons fait une avancée majeure grâce à Honza Havlíček qui, utilisant un travail similaire de Bjoern Michaelsen (Canonical) sur KDevelop, a implémenté la compilation depuis un fichier projet Visual Studio, permettant une amélioration importante de la compilation et du débogage : voyez la vidéo ou tapez juste : make vs2012-ide-integration.

Dépendance à l’exécution sur OpenGL

Dans le passé nous avions un chemin de code spécifique à OpenGL que l’on compilait dans une bibliothèque partagée liée à OpenGL, puis l’on chargeait dynamiquement ce composant — comme, par exemple, pour le diaporama en OpenGL. Dans la version 4.3, nous avons unifié tout notre code OpenGL pour utiliser glew, et nous avons maintenant une interface de programmation (API) VCL centrale pour s’initialiser et se lier à OpenGL, permettant une utilisation beaucoup plus facile dans le futur. Un autre bénéfice à l’utilisation de glew est la possibilité de vérifier dynamiquement les extensions OpenGL en cours d’exécution, pour mieux les adapter aux capacités de votre plate‐forme plutôt que de se limiter aux fonctions de base.

En‐têtes pré‐compilés et mises à jour de PCH

Thomas Arhnold a découvert que nos fichiers pch (utilisés pour accélérer la compilation sous Windows) se sont détériorés, et a fait un bon ménage parmi eux. Cela a accéléré significativement le temps de compilation pour un certain nombre de modules.

Réduction de la taille de code mobile

Beaucoup de travail a été effectué dans LibreOffice 4.3 pour nous permettre de diminuer la taille du code et l’adapter à la taille mémoire des plates‐formes mobiles. Merci à Matus Kukan (Collabora) qui a découpé un grand nombre de composants UNO en différentes fonctions de construction, ce qui permet à l’éditeur de liens de supprimer les composants non utilisés. Matus a également créé un script Python solenv/bin/native-code.py pour partager les listes de compilations de composants liés statiquement dans diverses combinaisons de fonctionnalités. Tor Lillqvist (Collabora) a retravaillé ICU pour empaqueter les tables de données, qui sont globalement assez grandes, dans un fichier plutôt que dans le code. Vincent Saunders (Collabora) a pas mal travaillé pour améliorer dwarfprofile, afin d’identifier les plus gros morceaux de fichiers objets et savoir d’où ils venaient. Jan Holesovsky a découplé beaucoup de code concernant l’accessibilité et supprimé beaucoup de variables statiques non nécessaires dans certaines parties du code. Miklos Vajna a transformé les OOXML custom shape preset definitions (oox::drawingml::CustomShapeProperties::PresetsMap) de code généré à donnée générée : cela a permis la suppression de 50 000 lignes de code. Grand merci à son auteur, Tsahi Glik, et CloudOn, pour avoir financé ce travail.

Travail sur la qualité du code

Il y a eu beaucoup de travail sur la qualité du code, et pour améliorer la maintenabilité et la propreté de ce code. Nous remercions Julien Nabet pour les (à peu près) 75 correctifs concernant les erreurs cppcheck, et pour les commits quotidiens, ce qui a permis d’avoir des compilations sans alertes sur toutes les plates‐formes. Merci également à Tor Lillqvist (Collabora), Caolán McNamara (Red Hat), et Thomas Arnhold.

Utilisation de assert

Un autre outil que les développeurs utilisent pour s’assurer qu’ils n’introduisent pas de nouveaux bogues sont les assertions (asserts). Historiquement le code OOo a eu un système d’assertions spécifique qu’on peut facilement occulter, ce qu’ont fait la plupart des développeurs. Grâce à Stephan Bergmann (Red Hat), nous avons commencé à utiliser les macros standards assert() dans LibreOffice, ce qui a l’énorme avantage qu’elles arrêtent le programme : si une assertion est fausse, le développeur voit un plantage, ce dont il est plutôt difficile de ne pas se rendre compte, comparé à du texte s’affichant dans le terminal. Grands mercis à tous ceux qui ont rendu efficientes les assertions.

Coverity

Nous avons été submergés par l’énorme quantité d’analyses venant de Coverity Scan, et Caolán McNamara (Red Hat), en particulier, a fait un travail incroyable ici ; son blog sur ce sujet est, comme à l’accoutumée, modeste.

Nous avons maintenant une densité de défauts (nombre de défauts par 1 000 lignes de code) de 0,08, ce qui signifie 8 bogues pour 100 000 lignes de code trouvés par l’analyse statique. Ceci se compare favorablement avec les projets libres de cette taille qui contiennent en moyenne 65 bogues pour 100 000 lignes. Peut‐être que le plus utile dans les rapports Coverity sont les nouveaux problèmes signalés, car beaucoup d’entre eux sont plus sérieux que les précédents rapports de basse priorité en vrac.

Ceci a été réalisé avec 2 679 commits, 88 % d’entre eux venant de Caolán, puis ensuite Norbert Thiebaud, Miklos Vajna (Collabora), Noel Grandin, Stephan Bergmann (Red Hat), Chris Sherlock, David Tardon (Red Hat), Thomas Arnhold, Steve Yin (IBM), Kohei Yoshida (Collabora), Jan Holesovsky (Collabora), Eike Rathke (Red Hat), Markus Mohrhard (Collabora) et Julien Nabet.

Test de l’importation et maintenant de l’exportation

Le grand crash-test de Markus Mohrhard sur l’importation et l’exportation a été étendu à plus de 55 000 documents contenant des problèmes ou suscitant des bogues, et couvre maintenant l’importation PDF. Le nombre de crashs et de problèmes de validation continue à diminuer. Markus a également réécrit et simplifié le script de test en Python. Cependant nous avons régulièrement des soucis avec ce test (qui tourne pendant 5 jours en utilisant une machine costaude), ce qui bloque plusieurs systèmes GNU/Linux de plusieurs distributions, versions de noyau, à la fois sur du matériel virtuel et réel ; ce qui a un impact négatif sur son utilité.

Refactorisation des gros objets

Dans certains cas, LibreOffice a des classes qui semblent faire « un peu tout », y compris le café. Mercis à Valentin Kettner, Michael Stahl (Red Hat) et Bjoern Michaelsen (Canonical) pour avoir aidé à retravailler ces classes. Par exemple, SwDoc (un document Writer) hérite maintenant de seulement 9 classes au lieu de 19, et l’en‐tête du fichier a diminué de plus de 300 lignes.

Corrections Valgrind

Valgrind s’avère toujours être un outil merveilleux pour trouver et isoler les fuites et les mauvais comportements sur différents morceaux du code, même si les chemins de code normaux sont maintenant plutôt propres. Dave Richards, de Largo, a très gentiment donné du temps processeur sur sa nouvelle machine GNU/Linux à 80 processeurs. Nous utilisons cette machine pour lancer le test d’importation et exportation de Markus sous Valgrind, et trouver et résoudre un certain nombre de problèmes. Les journaux de Valgrind sont ici. Nous serions très heureux d’aider les autres pour leurs tests de charge.

Assainisseur d’adressage et de fuite de mémoire

Il y a plein de super nouvelles façons de faire de l’assainissement de code (à la compilation) et, grâce à Stephan Bergmann (Red Hat), nous les utilisons avec enthousiasme. L’option -fsanitize est disponible pour Clang et gcc 4.9. Cela nous permet de faire de la vérification mémoire (comme Valgrind), mais avec une visibilité sur la pile corrompue, et de faire ça vraiment beaucoup plus rapidement. Les détails sur -fsanitize pour LibreOffice sont disponibles sur le wiki. Beaucoup de fuites et de mauvais comportements ont été résolus grâce à cet outil. Merci également à Markus Mohrhard et Caolán McNamara.

Tests unitaires

Nous compilons et exécutons plus de tests unitaires avec LibreOffice 4.3, pour éviter les régressions au fur et à mesure du développement. La recherche grep sur CPPUNIT_TEST() et CPPUNIT_ASSERT, comme la dernière fois, montre bien que la tendance à la croissance continue :

Notre idéal est que tous les bogues corrigés soient accompagnés d’un test unitaire, afin qu’ils ne réapparaissent pas. Avec 1 100 correctifs, et plus de 80 participants pour les tests unitaires dans la 4.3, il est difficile de citer toutes les personnes impliquées, je m’excuse pour cela. Ce qui suit est la liste triée de ceux qui ont fait plus de 20 correctifs sur les répertoires qa/ : Miklos Vajna (Collabora), Kohei Yoshida (Collabora), Caolán McNamara (Red Hat), Stephan Bergmann (Red Hat), Jacobo Aragunde Pérez (Igalia), Tomaž Vajngerl (Collabora), Markus Mohrhard (Collabora), Zolnai Tamás (Collabora), Tor Lillqvist (Collabora), Michael Stahl (Red Hat) et Alexander Wilms.

SAL_OVERRIDE et plus

Traditionnellement, C++ autorisait une grosse ambiguïté sur la surcharge des méthodes, permettant l’omission du mot clé « virtual » dans les surcharges et permettant également les surcharges polymorphiques accidentellement. Pour se préparer au nouveau standard C++, nous avons annoté toutes nos méthodes virtuelles qui sont surchargées dans des sous‐classes avec la macro SAL_OVERRIDE, pour être sûrs que nous compilons nos vtables correctement. Grands mercis à Noel Grandin, et Stephan Bergmann (Red Hat) pour avoir écrit un greffon Clang qui aide à produire ces annotations et un autre pour vérifier que les résultats restent cohérents. Ceci corrige certains bogues présents de longue date. Et comme bonus, quand vous lisez le code, il est beaucoup plus facile de trouver la déclaration de la méthode virtuelle initiale : c’est celle qui n’est pas annotée avec SAL_OVERRIDE.

QA / bugzilla

Dans cette version, l’équipe assurance qualité a grandi et fait un travail fantastique sur à la fois le tri des bogues et la fermeture de ceux‐ci, nous ramenant sous la valeur ô combien symbolique des 1 000 bogues non triés. Nous avons actuellement environ 750 bogues non confirmés, ce qui est le nombre le plus bas depuis plus de deux ans. Merci à tous pour ce bon travail, malheureusement c’est assez difficile d’extraire les remerciements pour les bogues confirmés, mais la liste des héros recouvre bien la liste des non‐développeurs ayant fermé le plus de bogues (voir plus bas).

Nous avons aussi eu un de nos meilleurs week‐ends de chasse aux bogues pour la 4.3, voir ce qu’a écrit Joel Madero. L’équipe assurance qualité a également fait un excellent travail en « bissectant » nos dépôts Git pour isoler les régressions à de petits blocs de correctifs, ce qui améliore grandement la vie des développeurs.

Un des indicateurs que nous regardons pendant l’ESC call est ce qui est dans le top 10 dans le Freedesktop Weekly bug summary. Voici la liste des 20 personnes qui apparaissent le plus fréquemment dans le top 10 des gens fermants le plus de bogues, par ordre de fréquence d’apparition : Jorendc, Kohei Yoshida (Collabora), Maxim Monastirsky, tommy27, Joel Madero, Caolán McNamara (Red Hat), Foss, Jay Philips, m.a.riosv, Julien Nabet, Sophie Gautier (TDF), Cor Nouws, Michael Stahl (Red Hat), Jean‐Baptiste Faure, Andras Timar (Collabora), Adolfo Jayme, ign-christian, Markus Mohrhard (Collabora), Eike Rathke (Red Hat) et Urmas. Et merci aux nombreux autres qui ont aidé à fermer tant de bogues pour cette version.

Bjoern Michaelsen (Canonical) a aussi écrit une belle taxonomie sur nos 25 000 bogues rapportés jusqu’à présent, et a fourni les données pour une belle répartition :

Nettoyage du code

Le code sale doit être nettoyé — et une fois encore, nous n’avons pas chômé.

La mort finale de UniString

Même si nous avions éliminé dans la version 4.2 la dernière classe string de tools/ pour la remplacer par une nouvelle classe uniforme (OUStrings) partout, nous utilisions encore en d’autres endroits des quantificteurs de 16 bits pour décrire des offsets textuels. Merci à Caolán McNamara (Red Hat) pour avoir permis d’avoir des paragraphes de plus de 65 535 caractères dans Writer, une fonctionnalité demandée depuis fort longtemps par certains utilisateurs, voir le billet idoine.

Nettoyage du code et de la structure de VCL

Les bibliothèques graphiques natives de LibreOffice — Visual Class Libraries — n’ont pas reçues toute l’attention qu’elles auraient mérité ces dernières années. Mille mercis à Chris Sherlock pour les centaines de correctifs inaugurant le nettoyage de ces bibliothèques. Beaucoup de bonnes choses en découlent : une structure de code plus logique, de sorte qu’il est aisé de trouver les méthodes ; une écriture systématique d’une documentation (Doxygen) pour les méthodes de l’API, assurant que celles‐ci possèdent des noms judicieux et descriptifs. Ceci commence à nous désengluer de pauvres choix de conception historiques. Ce travail est très apprécié.

Suivi des commentaires en allemand

Nous progressons toujours dans la traduction des derniers commentaires en allemand qui parsèment le code vers un anglais correct, précis et technique. Merci à Luc Castermans, Sven Wehner, Christian M. Heller, Philipp Weissenbacher, Stefan Ring, Philipp Riemer, Tobias Mueller, Chris Sherlock, Alexander Wilms et les autres. Dans ce cycle (NdT: de version), nous avons aussi accéléré l’outil de détection des commentaires allemands et réduit le nombre de faux positifs.

Refactorisation automatisée de code avec Clang

Un des héros du nettoyage de code est Noel Grandin qui améliore constamment le code de différentes façons, par exemple en remplaçant le code inutilement dupliqué pour utiliser les wrappers standards comme SimpleReferenceObject. Noel a été lourdement impliqué dans les greffons Clang, qui servent à réécrire notre format de fichier binaire qui est sujet aux erreurs. La surcharge de flux pStream >> nVar a l’air d’être une très bonne idée, jusqu’à ce que l’on réalise qu’un changement inattendu du type de nVar, loin de là, change le format du fichier. Ces opérateurs ont maintenant tous été réécrits pour l’utilisation explicite de ReadFloat, améliorant ainsi la robustesse du code à modifier. Noel a aussi créé des greffons pour mettre à la file automatiquement les membres de fonctions simples, détecter les passages inefficaces de uno::Sequence et OUString. Stephan Bergmann (Red Hat) a aussi écrit pas mal d’outils perfectionnés d’analyse statique, de vérification de déréférencement de pointeurs NULL permettant de trouver rapidement des problèmes de mise en file (inlining) sous GNU/Linux qui posent des problèmes essentiellement sous Windows, et a réécrit les utilisations non nécessaires de sal_Bool en bool. Stephan a aussi écrit un greffon pour trouver les fonctions non utilisées dans les modèles ou non, et émet aussi des alertes sur les conversions illicites des littérales vers un bool, par exemple if (n == KIND_FOO || KIND_BAR). Tout cela améliore la lisibilité, la cohérence, la fiabilité et, dans certains cas, la performance du code.

Amélioration du cycle de vie

Takeshi Abe s’est beaucoup investi pour rendre les cycles de vie des objets plus utiles. Se servir de pointeurs intelligents rend le code non seulement plus lisible et court, mais surtout le sécurise du point de vue des exceptions, ce qui est vraiment très utile.

Suppression de DocTok

Ce nettoyage nous débarrasse de presque 80 000 lignes de code et rend le code bien plus simple à comprendre. Merci à Miklos Vajna de Collabora. Vous pouvez voir l’avant et l’après dans ce billet.

Tenir bon sur la performance

La performance fait partie de ces choses difficiles à conserver. Elle a la fâcheuse manie de partir en sucette dès qu’on a le dos tourné. C’est pourquoi Matus Kukan (Collabora) a construit une machine de test qui compile régulièrement LibreOffice et lance des tests sur le chargement, conversions, etc, de documents sous callgrind. L’utilisation du simulateur de processeur de callgrind a cette magnifique propriété de répétabilité de comportement, ce qui permet de détecter la moindre diminution ou amélioration des performances et de tout de suite résoudre le problème. C’est facile de voir sur le graphique — admirez au passage la superbe platitude des lignes entre les évènements importants. L’axe x représente le temps (annoter les axes avec les hashes de Git n’est pas photogénique).

Souvent on regarde les performances juste avant la sortie finale. Ici, il est intéressant de voir la grosse bosse orange d’un point de vue fragilité des performances, trouvée et résolue grâce à ces tests. Les données brutes de callgrind sont disponibles pour examen des dernières traces avec le fichier plat ODS (flat ODS) des derniers tests.

S’investir

J’espère que vous comprendrez que de plus en plus de développeurs arrivent et se sentent comme chez eux parmi nous. Nous travaillons ensemble pour achever des travaux d’importance à la fois sous le capot et sur la carrosserie. Si vous voulez vous impliquer, il y a plein de merveilleuses personnes à rencontrer et avec qui œuvrer. Comme vous pouvez le constater, les indépendants ont un impact significatif sur la diversité de LibreOffice (la légende de couleurs se lit de gauche à droite, de haut en bas, ce qui représente les couleurs de haut en bas dans le graphique. [NdT: les indépendants, c’est le gros morceau orange au milieu.])

Et en ce qui concerne la diversité des patchs, nous adorons voir le volume des contributions apportées par les indépendants, même si clairement ce volume et les équilibres changent selon les saisons, les cycles de publication, le temps libre des volontaires et les business-plans.

Naturellement, nous maintenons une liste de petites ou minuscules tâches sur notre page Easy Hacks dont vous pouvez vous emparer pour vous impliquer dans ce projet, avec des instructions simples d’installation ou de compilation. C’est extrêmement facile de compiler LibreOffice. Chaque “easy hack” indique où aller dans le code et représente une tâche simple à résoudre dans un cadre bien restreint. De plus, certaines de ces tâches sont des fonctionnalités vraiment utiles ou des améliorations de performance. S’il vous plaît, envisagez de vous impliquer sur quelque chose.

Autre chose qui aide vraiment : lancer les préversions et rapporter les bogues. Il suffit de télécharger et d’installer une préversion et vous êtes prêt pour contribuer avec l’équipe de développement.

Conclusion

LibreOffice 4.3 est la suivante d’une série de versions qui vont améliorer progressivement non seulement les fonctionnalités, mais aussi les fondations de la suite bureautique libre. Soyez patient, c’est juste la première version parmi la longue série des cycles mensuels de publication 4.3.x, qui apporteront leurs lots de correctifs et d’améliorations qualitatives pour les mois à venir, tandis que nous commençons à travailler sur LibreOffice 4.4.

J’espère que LibreOffice 4.3 vous plaira. Merci de m’avoir lu, et merci de soutenir LibreOffice.

Les données brutes de la plupart graphiques ci‐dessus sont disponibles.

Télécharger ce contenu au format Epub

Lire les commentaires

Catégories: Nouvelles du Libre

Un NAS 4 baies N4310 chez Thecus

Toolinux - mar, 05/08/2014 - 23:33

Le nouveau N4310 pour PME embarque un SoC AMCC 1GHZ avec 1 Go de mémoire DDR3 pour un prix très abordable.

- Matériels
Catégories: Nouvelles du Libre

Productivité au travail : vous êtes plutôt Picasso ou Dickens ?

Toolinux - mar, 05/08/2014 - 23:23

Nouveau hors-piste cet été. Citrix a étudié les habitudes de travail des plus grands penseurs de ces dernières décennies.

- Revue de presse
Catégories: Nouvelles du Libre

Comment interdire les connexions SSH de l'utilisateur root

Toolinux - mar, 05/08/2014 - 23:05

L'accès SSH à une machine permet de manager cette dernière via un terminal (CLI). Par défaut, on peut utiliser tous les utilisateurs présents sur le système pour s'y authentifier.

- Revue de presse
Catégories: Nouvelles du Libre

Clé USB ou voiture de course ?

Toolinux - mar, 05/08/2014 - 23:00

Un peu de beauté dans ce monde de geek ? ADATA a lancé la clé USB 2.0 UV130, dotée d'un aspect titane avec des matériaux en alliage de zinc et un passage de sangle. Compatible Linux, forcément.

- Matériels
Catégories: Nouvelles du Libre

Sbires! La suite

Linuxfr - mar, 05/08/2014 - 13:58

Sbires! est un roman photo narrant la vie méconnue de ces personnages normalement cantonnés au second plan dont la principale fonction est de mourir sans faire d'histoire pour montrer que l'heure est grave ou que le méchant est vraiment méchant.

Il s'agit du deuxième épisode, diffusé sous forme de feuilleton tous les lundis. La première fournée a été livrée le 4 août 2014 au soir.

Sous licence art libre, Sbires! est produit avec Gimp, Inkscape et un peu Blender. Excédant légèrement les impératifs de la licence, les sources seront mises à disposition (celles de l'épisode 1 sont déjà disponibles).

Sbires! est fait sous l'égide de l'AMMD, coopérative d'artistes libristes qui s'occupaient notamment de la partie sono/concert lors des dernières RMLL.

Télécharger ce contenu au format Epub

Lire les commentaires

Catégories: Nouvelles du Libre

Que peut faire le service d'élite JTRIG du GCHQ ?

Linuxfr - mar, 05/08/2014 - 12:05

Bonjour tout le monde, comme l'article précédent la version originale de cet article possède énormément de liens et de références ; je ne peux pas tout mettre ici, vous avez le lien vers l'article en question en bas de la page. J'espère que ça vous plaira :)

Nous allons parler dans cet article du JTRIG (pour Joint Threat Research Intelligence Group), qui est l'équivalent anglais pour le GCHQ (les services de renseignements anglais) du département TAO de la NSA. La mission du JTRIG consiste entre autres à détruire ou à empêcher d'agir les ennemis en les discréditant via de fausses informations ou en empêchant leurs communications de fonctionner : déni de service (DoS) via appels ou sms, suppression de la présence en ligne d'une cible, changement de photos sur les réseaux sociaux (pour discréditer une cible ou augmenter drastiquement sa parano), captation des courriels (par exemple pour apporter de la crédibilité lors de l'infiltration d'un groupe), … la liste est longue.

Sommaire

Le GCHQ possède un rayon d'action étendu, allant d'une cible individuelle à l'échelle d'un pays.

GCHQ vs Anonymous

Dans un article du 5 février 2014, Mark Schone (NBC News) racontait comment le JTRIG lançait des DDoS contre les Anonymous avec le programme ROLLING THUNDER (DDoS via P2P/syn flood selon le journal).

Le GCHQ était aussi présent sur des canaux IRC Anons, ce qui leur a permis d'arrêter quelques personnes : Edward Pearson dit GZero. Jake Topiary Davis (porte-parole du groupe Lulzsec), Mustafa Tflow Al-Bassam, aussi du groupe Lulzsec, ainsi que quelques autres.

Quelques infos supplémentaires sur les condamnations

GZero a sans aucun doute cherché les emmerdes : vol de comptes paypal, utilisation de CB volées, discussion en ligne avec un agent se faisant passer pour un Anon à propos d'attaque…, le blog garwarner.blogspot.fr raconte des choses très intéressantes : son compte SoundCloud aurait eu comme Userid GZero et comme nom "Edward Pearson". Selon la diapositive 7 de ce document, un whois sur un de ses liens échangés sur IRC aurait rapporté des informations… même pas sûr que le GCHQ ait eu à utiliser le programme PHOTON TORPEDO qui permet de récupérer l'adresse IP d'un utilisateur de MSN : oui… il avait aussi son adresse en clair sur un site, lié à son pseudo…

Un autre Anon, p0ke, a cliqué sur un lien menant vers l'article de la BBC “Who loves the hacktivists" qu'un agent lui a envoyé. Je pense que vous devinez ce qui s'est passé, le GCHQ a été capable de récupérer l'adresse IP qu'il avait derrière son VPN.

Ça marche avec des liens (rappelez-vous de QUANTUM et de FOXACID), mais ça marche aussi très bien avec des pièces jointes, comme avec un document Office : TRACER FIRE permet de récupérer des infos sur la machine ciblée, comme des fichiers ou des logs), TORNADO ALLEY fait plus ou moins la même chose sous la forme d'un document Excel. Ou encore GURKHAS SWORD qui permet de faire remonter l'adresse IP de la cible. Le lien sur lequel il a cliqué était sans doute piégé, mais il existe une autre hypothèse : une surveillance passive des connexions à l'article via TEMPORA et ANTICRISIS GIRL, et qui aurait pu permettre par ricochet de remonter à sa navigation, comme son compte Facebook, et ses adresses de courriels.

Ça aurait aussi pu venir de l'utilisation d'un programme comme GLASS BACK (permet de récupérer l'adresse IP d'une cible en la spammant), ou tout simplement une requête en bonne et due forme au fournisseur du VPN en question (on en oublierait presque les bonnes vieilles méthodes).

Que font les terroristes déjà ? Des DDoS ?

Il est toujours agréable d'apprendre que le GCHQ sait très, très bien utiliser le déni de services sous toutes ses formes : DoS sur des serveurs web (PREDATORS FACE), sur les téléphones via call bombing (SCARLET EMPEROR), contre SSH (SILENT MOVIE) ou encore de manière silencieuse sur les téléphones satellite / GSM avec VIPERS TONGUE (par silencieux, on entend que la cible ne voit rien du DoS ; les messages n'arrivent pas réellement sur le périphérique mais bloquent les communications).

AMBASSADORS RECEPTION a été utilisé dans différentes situations : quand il est utilisé sur une machine cible, il se chiffre lui-même, efface tous les courriels, chiffre tous les fichiers, fait trembler l'écran et empêche l'utilisateur de s'identifier. STEALTH MOOSE cible spécifiquement les machines Windows.

Une autre opération visant spécifiquement les Talibans en Afghanistan a consisté en une tempête de fax, d'appels et de SMS programmée pour arriver toutes les minutes sur les terminaux cibles.

CANNONBALL permet de spammer via SMS une cible, BURLESQUE permet d'envoyer des SMS modifiés et CONCRETE DONKEY permet l'envoi d'un message audio à de nombreux téléphones ou de "spammer" une cible avec le même message (on notera la référence à Worms Armageddon <3).

Spam

Et le GCHQ n'hésite pas à envoyer via les réseaux sociaux (Facebook, Twitter, Skype) le message "DDOS and hacking is illegal, please cease and desist" pour « dissuader » des activistes de participer à des DDoS. Une des diapositives indique que 80% des personnes à qui avait été envoyé le message n'étaient plus sur les canaux IRC un mois après.

On parle ici de programme comme BADGER ou WARPATH qui permettent d'envoyer massivement (qui a dit spammer ?) du courriel.

Pour information, MINIATURE HERO vise spécifiquement le logiciel Skype et permet de collecter et d'enregistrer des conversations (aussi bien skypeOut que en skype to skype), les messageries instantanées et les listes de contacts.

Honey traps (pots de miel)

ROYAL CONCIERGE exploite les réservations d'hôtels pour tracker les diplomates étrangers (et sans doute pas que les diplomates). Le GCHQ utilise ce programme pour essayer de mener les cibles vers des hôtels "SIGINT friendly" : plus facilement espionnables, aussi bien électroniquement que humainement.

La mise en place de pots de miel fait aussi partie du catalogue du JTRIG, et il arrive qu'une opération soit mise en place pour leurrer une cible en lui faisant miroiter une possibilité de relation amoureuse et/ou sexuelle et ainsi l'amener à faire quelque chose (le B.A.BA des services de renseignements quoi…). C'est typiquement ce qui s'est passé en 1986 avec Mordechai Vanunu et l'agente du Mossad (les services de renseignements israéliens) Cheryl Bentov.

Plus d'infos sur le cas Julian Assange

Réseaux sociaux

La propagande est à la Démocratie ce que la violence est aux dictatures. Noam Chomsky

Et ça le GCHQ l'a trop bien compris, ils peuvent accroître artificiellement le trafic d'un site (GATEWAY), amplifier un message (c'est à dire augmenter le nombre de vues et donc le référencement), comme une vidéo sur Youtube (GESTATOR), ou encore modifier un mur Facebook aussi bien pour une seule personne que pour un pays entier (CLEANSWEEP).

Ils ont aussi bien la possibilité de modifier les photos d'utilisateurs sur les réseaux sociaux que d'envoyer des courriels ou des sms à vos collègues ou à vos voisins à votre place, il est indiqué dans les documents fuités que ce type de méthode a aidé la police britannique à « arrêter des criminels ».

Donc, maintenant, si (par exemple) vous trompez votre conjoint-e et qu'arrive le moment où vous vous trompez de destinataire lors de l'envoi d'un message, vous avez maintenant l'excuse « c'est une opération des services de renseignements anglais pour me discréditer ! ». Pas mal non ?

Quelques programmes bonus

  • BABYLON permet de faire une requête sur une adresse de courriel Yahoo ou Hotmail (à la date du document) pour savoir quand elle est utilisée ou non ce qui permet de savoir quand s'y connecter.
  • DANCING BEAR permet d'obtenir la localisation d'un point d'accès wifi.
  • HACIENDA permet de scanner une ville ou un pays entier
  • SWAMP DONKEY localise des types de fichiers prédéfinis et les chiffre.
  • DEEPSTALKER aide à la géolocalisation des téléphones satellites et des GSM en faisant un « appel silencieux » (invisible pour la cible).
  • SQUEAKY DOLPHIN permet une supervision en temps-réel des vues sur Youtube, des Likes sur Facebook ou encore des visites sur Blogspot/Blogger. Ce qui permet de récupérer des informations pertinentes sur des tendances (diapos 29 à 32), et donc potentiellement "prévoir" des événements (l'exemple dans les diapos concerne les tags "14FEB", "Bahrain" et "March rally" le 13 février 2012, c'est à dire la veille du premier anniversaire du « jour de colère » au Bahrein).
Pour finir "Nul ne sera l'objet d'immixtions arbitraires dans sa vie privée, sa famille, son domicile ou sa correspondance, ni d'atteintes à son honneur et à sa réputation. Toute personne a droit à la protection de la loi contre de telles immixtions ou de telles atteintes." Article 12 de la déclaration universelle des droits de l'homme

Que pouvons nous faire ? La réponse est simple à écrire, mais plus difficile à mettre en œuvre, il faut commencer par faire son modèle de menace, après ça, vous avez le choix : chiffrer, tout, tout le temps. Utiliser Tor, dont les services cachés, le plus souvent possible. Mettre en place des machines virtuelles dédiées (par exemple KVM ou virtualbox—pour les adminsys : SSH au-dessus de Tor seulement par exemple, navigation web), utiliser des logiciels libres (vous méritez de vous faire prendre sinon ;-)), SSL/TLS par défaut pour TOUT, OTR sur les messageries, ouvrir les liens que quelqu'un vous donne sur une machine distante (sans lien avec vous) ou sur une VM… etc.

Et évidemment, ne pas faire de conneries : toute la crypto du monde ne vous protégera jamais si vous faites des erreurs bêtes, comme permettre des passerelles entre votre pseudo et votre nom (comme une adresse de courriel). Le fondateur de SilkRoard, William Ulbricht (dit Dread Pirate Robert's) peut en témoigner.

Télécharger ce contenu au format Epub

Lire les commentaires

Catégories: Nouvelles du Libre

OwnCloud 7 : version finale disponible

Toolinux - lun, 04/08/2014 - 23:20

Sept mois après la version ownCloud 6, la septième mouture de la plate-forme de stockage et de partage de données en ligne voit le jour. Globalement, cette version a pour objectif de faciliter le partage de fichiers, et, d'améliorer la gestion et la prévisualisation des documents.

- Logiciels
Catégories: Nouvelles du Libre

Dissocier mobilité et environnement de travail, véritable frein pour une stratégie Cloud d'entreprise ?

Toolinux - lun, 04/08/2014 - 23:20

Nous avons eu accès à l'informatique à travers des ordinateurs centraux utilisés collectivement dans les années 70. L'accès à l'informatique individuel est né avec la naissance du PC dans les années 80. Le premier accès à la mobilité a ensuite été réalisé grâce à l'apparition des pc portables au début des années 90. Finalement, ces nouveaux outils ont intégré le quotidien des foyers seulement après une utilisation dans les entreprises…

- Revue de presse
Catégories: Nouvelles du Libre

Linux Identity : Debian et Ubuntu à l'honneur

Toolinux - lun, 04/08/2014 - 23:10

Si vous hésitez encore à passer à Linux, le magazine est un excellent moyen de vous persuader. Deux horizons possibles : Ubuntu et Debian.

- Revue de presse
Catégories: Nouvelles du Libre
Syndiquer le contenu