Aissen a écrit 325 commentaires

libinput supporte l’accélération, juste ça n’utilise pas l’option de config globale de Xorg, mais une option par périphérique d’entrée. Cf la présentation de Hans de Goede pour ceux qui ne peuvent/veulent voir la vidéo YouTube liée dans la dépêche: https://fosdem.org/2015/schedule/event/libinput/attachments/slides/591/export/events/attachments/libinput/slides/591/libinput_xorg.pdf .

Oui, il fonctionne très bien, hormis le racket organisé des publicité "acceptables" (pour lesquelles je serai pour si il n'y avait pas d'argent échangé), et les gros problèmes de performance (gains similaires dans Firefox).

Je conseillerai plutôt uBlock Origin qu’Adblock Plus, bien plus performant:
https://addons.mozilla.org/fr/firefox/addon/ublock-origin/

Exact, merci.

Bon je met à jour, j’ai confondu 1024 et 768 bits… Il n’empêche que les clefs 1024bits sont crackables aujourd’hui par quelques entités sur la planète, et le seront plus largement dans 5 ans; sans Perfect-Forward-Secrecy, ça expose toutes les connexions à un décryptage a-posteriori sur une échelle de temps plutôt courte.

Dane n’est pas exempt de problèmes, notamment les certificat 1024 bits (crackables en quelques semaines) encore présents dans la chaine de root…
https://www.imperialviolet.org/2015/01/17/notdane.html (je vous laisse lire tous les liens présents dans l’article, yen a pour un moment)

Un .club qui reste, j’ai vraiment pas d’imagination ce soir:
G15CLUB-7039-B156-09D8

C’est basé sur Electron (ex-Atom Shell), mais pas Atom. Pour les plus vieux, Electron n’est rien d’autre que la réalisation de feu Mozilla Prism, basé sur Chromium.

Quoi qu’on pense de l’approche open source de Google, chromium est en train de tout dévorer sur son passage: Opera, Vivaldi, Chromium Embedded Framework, QtWebEngine, les innombrables navigateurs Android et la webview, et maintenant Electron utilisé par Microsoft; et j’en oublie surement.

Merci pour vos retours; effectivement on peut considérer qu’incipit puisse être un mot trop perturbant et sans lien évident avec du code.

Comme toujours, n’hésitez pas à répondre à l’appel à volontaires de la dépêche, c’est un gros boulot qui a toujours besoin de relecteurs et rédacteurs; une simplification serait passé sans soucis pendant la rédaction.

Je suis le coupable pour l’utilisation de ce mot; que j’assume totalement. Pas de soucis pour moi à utiliser un mot d’origine latine plutôt que grec (prologue), et à faire le lien entre le code source et une œuvre littéraire/musicale/poétique.

Je ne voulais pas rentrer dans les détails, pas certain de l’implémentation exact de ftrace sur toutes les architectures supportées (une quinzaine), mais en gros ce que désigne "incipit" ici c’est tout simplement la première instruction de chaque fonction, qui, avec l’aide de gcc (mcount), sera soit un NOP, soit un jump vers le code de ftrace.

Donc oui, j’aurai pu utiliser le mot "instruction", mais pour être précis ça aurait nécessité de détailler encore plus le fonctionnement de ftrace, et s’éloigner du sujet.

J’ai jamais prit le temps de la publier, mais ma solution est un poil plus complexe, elle évite le fait de versionner tout le home (donc les sous dossiers ne se croient pas dans un répertoire git). En fait le dépôt git est dans ~/.sync/ ; et on utilise un alias pour gérer ce dépôt :

alias gitsync="GIT_DIR=~/.sync/.git git"

L'installation se passe comme suit :

git clone maison:~/git/sync ~/.sync; cd ~/.sync; ./.init-sync

Pour initialiser le tout, le fichier .init-sync va paramétrer l’environnement:

#!/bin/bash
if [ -d .git -a "$PWD" != "$HOME" ]; then # This is a first run
        # At first run, we're run from the git dir, unconfigured
        export GIT_DIR=$PWD/.git
        git ls-files HEAD . |xargs rm -r
        git config --add core.worktree $HOME
        git checkout -f
        # configure bash
        echo "if [ -f ~/.bash-commons ]; then
    . ~/.bash-commons
fi" >> ~/.bashrc
else
        export GIT_DIR=$HOME/.sync/.git
fi
cd $HOME
git submodule init
git submodule update
#configure vim
vim +BundleInstall +qall

Pour ajouter des fichiers dans le dépot:

gitsync add -f .gitconfig

Et ça permet de tracker et synchroniser à peu près tout ce qui compte (config bash, git, vim, less). Certains paquets supplémentaires sont installés comme submodules (z/autojump, icdiff, vimpager,…).

Le fichier ~/.init-sync peut être relancé sur quand des nouveaux paquets vundle ou submodules sont ajoutés.

Je me suis déjà fait avoir alors que je connais le problème… L’amour de CACert dans le monde du libre n’est pas réellement justifié; comment leur faire confiance sur la sécurité quand ils ne sont pas capables d’avoir la confiance de Debian, Mozilla ?

Gageons que https://letsencrypt.org/ va changer la donne, ça n’arrivera jamais assez tôt.

L’initiative est pas mal, on peut regretter de ne pas avoir la source du générateur (même si on se doute bien qu’il parse legifrance), et des messages de commits décrivant plus en détail les lois qui modifient le Code.

À noter des initiatives similaires précédentes:

• L’historique des amendements d’un texte sur la fabrique de la loi (merci Regards Citoyens) et les dépots git, apparemment hors service.
• Archéo Lex avec le CPI.
• Crimino Corpus (exemple de diff)
• Et la source canonique, le Code Civil sur legifrance et toutes ses modification.

Excellente analyse, merci. Juste un point de détail:

On prend juste du SPIR-V et on l'envoie sur le GPU.

Plus exactement, on l’envoie au driver, qui va ensuite traduire (i.e. compiler) le SPIR-V en bytecode GPU.

Et il y a fort à parier que dans le futur, le GPU sache directement exécuter du SPIR-V, donc.. quasiment rien à faire (Enfin, bon, il y aura quand même du boulot hein :) )

Effectivement, c’est une possibilité, mais j’en doute vu les investissements lourds pour faire une architecture GPU. On verra !

J’ai lu pas mal des articles cités, et j’ai du mal à voir les changements au niveau techniques; voici ce que j’ai cru comprendre de glNextVulkan:
- un bytecode commun SPIR-V pour Vulkan et OpenCL. Finit les programmes qui envoie des shaders en C et les différences d’implémentations des frontends de compilo
- plus de différence entre OpenGL, OpenGLES, WebGL; ils sont remplacés par Vulkan
- une API plus bas niveau; l’appli doit maintenant gérer ses buffers elle même; ça donne plus de puissance au développeurs de moteurs, mais pas non plus fait pour être utilisé directement par les devs d’applis comme OpenGL/DirectX.
- possibilité d’envoyer des commandes depuis une stack multi-threadées

D’autres personnes plus expérimentés passent par là pour expliquer les différences? Quelles seraient les inconvénient fassent à Mantle (voué à disparaître?) et Metal ? Est-ce que le rapprochement avec OpenCL va enterrer CUDA ? Comment ça se compare à DirectX12 ?

Le seul intérêt de Mir c’est de permettre à Canonical de contrôler la plateforme grâce à la GPLv3 + Copyright Assignement. Les fabricants de téléphone étant allergique à la GPLv3, ça permet à Canonical de leur vendre une license sans GPLv3.

Un argument technique pour Mir qui était présenté c’était de pouvoir utiliser les drivers Android, mais en fait ils ont fait ça en utilisant libhybris, à la base codé par Jolla pour utiliser des drivers Android avec… Wayland!

Au final aujourd’hui Wayland est dans plus de produits sur le marché que Mir, mais ce n’est qu’un détail ;-)

Je n'arrive pas à le configurer pour avoir des polices grasses (bold fonts). Du coup, malgré des choses intéressantes, ce n'est pas utilisable.

Il suffit de trouver la version (Bold) de ta police, si elle en a une. (Dans Settings -> Font).

Aussi : je n'ai pas trouvé comment ouvrir une nouvelle fenetre avec le même dossier courant ? Sur la plupart des terminaux je fais Ctrl+Maj+N.

Effectivement, il n’est pas possible pour l’instant de créer une nouvelle fenêtre; par contre, pour créer un nouvel "onglet" il suffit de faire Ctrl+Maj+T. Étant donné qu’il est possible de faire des splits et des onglets, la gestion de fenêtres est plus limitée (éternel dilemme).

Je recommande d’utiliser la dernière version (0.8.0).

Un danger assez grand c’est que maintenant ça expose un single-point-of-failure (Mozilla) à des procès. Imaginez une extension qui pose problème à un éditeur de site: elle permet de contourner des limitations et viole les conditions d’utilisation ou le copyright du site. Tout ce qu’il a à faire c’est d’attaquer Mozilla pour le forcer à révoquer ou arrêter de signer l’extension. Avant, la majorité des utilisateurs pouvait facilement installer l’application en un clic. Maintenant, ils doivent utiliser la version développeur ou nightly. Avec Adblock/uBlock on est pas à l’abri qu’une régie peu scrupuleuse profite d’une législation locale pour les bloquer par exemple.

Pour moi le problème aurait dû être attaqué à la source: en nettoyant l’API qui permet de faire des addons. Si le problème ce sont les extensions qui changent la home ou injectent de la pub, il suffit de limiter ces API. Mozilla a déjà commencé ce travail avec l’addon-sdk (anciennement jetpack). On peut imaginer que les extensions qui utilisent les API "dangereuses" soient celles qui soient soumises à validation ou signature, laissant libre champ aux autres.

Un autre point mystérieux dans l’annonce c’est de quelle nature va être la validation automatique.

On apprend également sur ce même blog qu’il faut 6 semaines aux volontaires d’AMO faire une "full review". À combien ça va monter quand toutes les extensions devront passer par là ?

Dernier point, aucun changement de politique concernant les extensions proprio: les extensions dont le code est "obfusqué" (par exemple en sortie d’un compilo) sont interdites. Avant il suffisait de ne pas passer par AMO, mais maintenant c’est complètement interdit ? C’est pas forcément la meilleure manière de faire une plateforme "ouverte".

Je pense que c’est effectivement naïf, sinon ils en parleraient dans leur article d’annonce. Il s’agit bien d’une fermeture sèche.

C’est compatible AndroidMacWindowsBlackberryiOSWindowsPhoneSymbianNavigateur ? Comment on fait pour partager un fichier ou un album photo avec un lien web ? Comment on annule une suppression de fichier ?

Bon vous voyez l’idée, on ne se "passe" pas de Dropbox comme ça. Et je n’ai pas parlé des fonctionnalités pro.

Edit: pour ne pas être entièrement négatif, il existe des solutions OSS avec un peu plus de fonctionnalités à installer sur votre NAS pour se rapprocher de Dropbox: Owncloud, Cozy (cocorico), SparkleShare, Syncthing, Pydio, etc.

Où en est la procédure ? Un commentaire ou un journal de suivi serait assez intéressant pour conter l’expérience, avec une éventuelle analyse des raisons du succès ou de l’échec du "challenge station de travail linux".

Effectivement, parceque le programming model d’OpenGL ne correspond plus aux pipelines de GPU modernes. GLES s’en approche déjà mieux, et les API proprios (Metal, Mantle,…) encore plus.
Si on ne peut plus tirer partie de la puissance du GPU, c’est que l’abstraction ne convient plus.

Très intéressant, ça va à l’encontre de ce qui est dit (ou éludé) dans la dépêche; peux-tu donner une source ?

Oui, c’est que pour clavier externe, le seul où il y a vraiment un manque. AnySoftKeyboard fait son office pour le tactile, bien que je ne l’utilise pas.

Il y a pas mal d’innovation justement sur les claviers tactiles; message ease est un exemple, mais il y a aussi:
- 8pen http://www.8pen.com/
- minuum http://minuum.com/
Et des plus classiques:
- Swiftkey/Swype/Google Keyboard: incontournables avec glisse et saisie prédictive
- Flesky/Go keyboard/ai keyboard etc.
- Le Hacker keyboard, libre et complet
- des projets de recherches comme un clavier pour montre: http://research.microsoft.com/en-us/downloads/3e3aaa26-804c-486e-b3d7-d394c733da90/default.aspx http://www.theverge.com/2014/10/11/6961447/microsoft-android-wear-keyboard-download-features (minuum le fait aussi)
- des claviers pour tablettes, des claviers constructeurs (tous les gros ont le leur), etc.