patrick_g a écrit 6392 commentaires

tu viens de dire que tu aimes la politique de Microsoft en termes de sécurité

Et après tu t'étonnes qu'on te tape dessus parce que tu racontes n'importe quoi.
En quoi la politique de sécurité de Microsoft (à l'époque, parce qu'ils ont changé depuis) était comparable à l'actuelle politique suivie par les mainteneurs Linux ? Autrefois Microsoft se foutait royalement de la sécurité et seul le "time to market" comptait. Depuis ils ont bien appris leur leçon et ils ont maintenant une politique assez efficace.
Donc évoquer Microsoft comme tu le fais n'a aucun sens à part le plaisir d'agiter un chiffon rouge pour faire dérailler la conversation.

Et cela n'a absolument rien à voir avec la nécessité de faire des compromis entre plusieurs buts contradictoires.
C'est sûr que c'est confortable pour Spender de cracher sur les devs Linux quand on se branle royalement des perfs du noyau patché Grsecurity/PaX.
Regarde donc le journal que j'avais écris à l'époque sur ces perfs : https://linuxfr.org/users/patrick_g/journaux/les-performances-d-un-noyau-avec-le-patch-pax
Les résultats des micro-benchmarks sont absolument catastrophiques !

Un peu facile de taper sur une personne qui a le malheur de ne pas rentrer dans le moule "gentil qui fait tout comme les mainteneurs upstream et/ou certains utilisateurs attendent".

Tu crois que je suis le seul à lui taper dessus ? Tout le monde lui reproche son attitude infecte, son arrogance inouïe ,sa propension à se faire mousser en permanence et son incapacité absolue à travailler avec les autres.
Bien entendu il est très compétent, et là personne ne remet ça en cause…mais des gens compétents il y en a d'autres (par exemple Kees Cook, l'auteur de KASLR). Pour bosser sur le noyau il ne suffit pas d'être compétent, il faut collaborer avec les autres puisque c'est un projet collectif et il faut accepter les compromis puisque c'est un noyau généraliste.

Sauf que tu as 511 chances sur 512 de faire planter le noyau quand tu tentes d'en prendre le contrôle. Et un plantage noyau ça a tendance à se remarquer un peu plus qu'un plantage de process en userspace.
Et tout ça c'est sans évoquer les autres bénéfices du patch (protection de la table IDT par exemple).

Je pense que kASLR n'est pas une bonne idée. Les raisons sont simples et elles sont détaillés dans l'article sur le blog/forum de grsecurity

Sauf que Spender est un maximaliste qui ne pense qu'à la sécurité et se fiche de tout le reste (perfs, portabilité, etc). Les mainteneurs du noyau eux doivent faire des choix et des compromis.
Dans l'article LWN dédié on comprend bien que KASLR n'est pas une solution miracle mais que ça apporte quand même des bénéfices non nuls en terme de sécurité et sans aucune dégradation des perfs.

C'est la bataille des mots

Un lien fort utile : http://politiquedunetz.sploing.be/2013/07/les-mots-ont-un-sens-parler-de-monopole-du-droit-dauteur-pour-sauvegarder-nos-libertes/

Si tu faisais une blague par rapport à mon avatar

Je ne vois pas les avatars, j'ai coché la case "Ne pas afficher les avatars sur le site" dans mes préférences Linuxfr.

Ma mère a configuré son imprimante-scanner en suivant un tuto sur ubuntu-fr.org, elle a configuré son Thunderbird toute seule, etc

Ta mère est un mutant surpuissant venu de l'espace par rapport à la mienne.

Il s'agit de parvenir à avoir un patch qui soit accepté dans la branche principale….et pas de devenir mainteneur.
Mais excellente initiative.

Je ne comprends même pas que cette fonction n'existe pas de base. Il s'agit de ne pas faire quelque chose (le réencodage) donc pourquoi est-ce que ce n'est pas présent dans le soft ?

Tails m'a l'air focalisé sur l'utilisation en tant que live-cd ou live-usb.
De plus Tails semble porté par un team et être plus complet. Whonix est juste une collection de scripts appliqués sur une Debian.

Analyse et commentaires intéressants ici :

https://www.imperialviolet.org/2014/02/22/applebug.html

et aussi ici :

http://utcc.utoronto.ca/~cks/space/blog/programming/IndentationProblem

Et moi j'ai relayé vers LWN ce matin pour que ce soit plus productif ;-)

je pense qu'OpenRC va devenir, de facto, l'init des autres noyaux Debian en plus d'être supporté par Gentoo (l'autre alternative étant sysV que personne ne regrettera).

SysV n'est pas la seule alternative. Il existe (au moins) un autre projet qui semble techniquement plus prometteur qu'OpenRC :

http://homepage.ntlworld.com/jonathan.deboynepollard/Softwares/nosh.html

Pour une comparaison avec Btrfs il faut lire l'excellente série d'articles publiés par LWN :

1) The Btrfs filesystem: An introduction

2) Btrfs: Getting started

3) Btrfs: Working with multiple devices

4) Btrfs: Subvolumes and snapshots

5) Btrfs: Send/receive and ioctl()

Merci pour le retour.
Est-ce que quelqu'un sait si ITOP peut concurrencer l'ITSM de BMC ?

Il n'y a strictement aucune avance majeure

Est-ce qu'on a lu les mêmes notes de version ?
Pour toi la réécriture complète du moteur de Calc ce n'est pas majeur ?
Le backend expérimental Firebird SQL de Base à la place de l'immonde HSQLDB ce n'est pas majeur ? Regarde l'écart monstrueux de perf décrit ici : http://www.firebirdnews.org/?p=9109

il y a quand même quelque chose qui me gène dans ce billet…c'est le dénigrement du code qui a été modifié.

Bon d'abord il faut voir que l'article de Michael n'est pas une liste des nouveautés de LibreOffice 4.2.
Le lien vers les vrais Release Notes a été mis dans la dépêche mais ici ce n'est pas vraiment l'objet. Dans cet article Michael parle plutôt du travail invisible (compilation, tests, etc) et de la santé du projet (contributions). Il est donc légitime qu'il évoque les améliorations de la qualité du code. A mon sens ce n'est pas du dénigrement mais la volonté de mettre en avant le travail de ceux qui se consacrent à une tâche peu visible mais cruciale pour l'avenir du projet.

Le code est peut-âtre moche, mais il a fait son boulot plus ou moins bien pendant des années.

Bien entendu…mais c'est bien aussi de nettoyer une base de code qui est vieille en même temps qu'on ajoute de nouvelles fonctions.

J'ai corrigé le lien.

Bon les gens, si on reparlait un peu de Lem? D'autres personnes ont lu ses romans?

Solaris est une référence et reste un excellent bouquin de SF philosophique.
Le seul autre que j'ai lu est "Les voyages électriques d'Ijon Tichy" et je n'ai pas accroché.

C'est quoi l'utilité de Adblock Edge par rapport à un Adblock Plus sur lequel on a décoché l'option "Autoriser certaines publicités non intrusives" ?

LWM.net offrent pour leur part des abonnements gratuits.

Juste une petite rectification. En fait c'est HP qui sponsorise un abonnement de groupe pour tous les devs Debian.
C'est précisé dans la FAQ :

HP has generously funded a group subscription for Debian developers; see this posting for information on how to gain access to this subscription.

Houlala…tu prends des risques en lançant le sujet :-)

Pour résumer les trois épisodes de la saga :

1) FreeBSD annonce que, suite aux révélations de Snowden, ils vont réduire le rôle des générateurs d'entropie implémentés en hardware (HW RNGs) car ils n'ont plus confiance en Intel ou en Via.

2) Un journaliste inconscient demande à Theo de Raadt (leader d'OpenBSD) si ils vont faire pareil que FreeBSD. Theo en profite pour passer le projet FreeBSD au lance-flammes en disant que ce sont des brèles qui ne connaissent rien à la sécurité. Que dans OpenBSD, et aussi dans Linux, cela fait des années (le commit sur le générateur Via date de 2003) qu'on n'accorde aucune confiance exclusive aux HW RNGs et qu'on se contente de les considérer comme une source d'entropie comme une autre qu'on mixe au sein de l'entropy pool.
Theo se demande même pourquoi les gens de FreeBSD, pendant des années, n'ont pas suivi les bonnes pratiques cryptographiques. Il lance même une accusation vraiment grave : "They must have chosen a few years ago to do this wrong, intentionally. Perhaps that decision was made by their Californian developers, the ones who work fairly close to that NSA building."

3) Marshall Kirk McKusick, un des grands manitous du monde UNIX et un des développeurs FreeBSD répond à Theo. En résumé il explique que ce choix avait été fait à l'époque pour des raisons de performances parce que les HW RNGs sont très rapides et consomment peu de CPU.
Il confirme donc parfaitement les critiques de Theo avec cette phrase en forme d'aveu : "Specifically, FreeBSD 9.2 shipped using 'rdrand' support enabled by default. If you have an Intel CPU supporting this feature, Yarrow will not be used for /dev/random: all randomness comes straight from the CPU's built-in random number generator."

Dans FreeBSD 9.2 on était donc complètement dépendant du générateur aléatoire rdrand d'Intel. A partir de FreeBSD 10.0 l'entropie générée par ce module sera envoyée dans Yarrow (le générateur cryptographique de nombres pseudo-aléatoires de FreeBSD).

C'est donc certes un progrès pour FreeBSD mais ça arrive avec 10 ans de retard sur ses concurrents libres ;-)

C'est pourquoi je me permets de rigoler un bon coup en lisant cette phrase dans l'article d'ITWire : "McKusick said FreeBSD remained committed to staying on the leading edge of cryptographic engineering."

Leading edge ? Mouarf !

Pour les commits, j'en doutes fort, mon job est de casser, pas de reparer

Il te reste les tags Reported-by :-)

Le truc amusant, c'est que j'ai quitte MS il y a 3 mois, et que maintenant je bosses pour une boite qui pourrait bien etre le plus grand utilisateur de Linux de la planete, ou sinon au moins le 2eme derriere Google. Eh oui, je passe mes journees sur Linux.

Par curiosité tu fais quoi au quotidien ? On va voir des commits à ton nom dans les contributeurs du noyau ou bien tu ne bosses que sur des trucs internes Facebook ?

C'est moi, ou il n'y a rien de bien sympa pour l'utilisateur desktop normal

Et le support de 8192 CPU alors ?
Bon sinon pour être sérieux je pense que le boulot effectué sur Multi-Queue Block Layer va, à moyen terme, être utile à tous les détenteurs de SSD très rapides. Ces joujoux ne sont pas réservés aux serveurs, de nombreux utilisateurs desktop vont donc en voir les bénéfices quand les pilotes seront adaptés.

Et puis, même si un noyau n'a pas de grosse nouveauté desktop, il reste les milliers de petites améliorations incrémentales.

En quoi est-ce que la personne à laquelle tu réponds a-t-il indiqué que le problème était spécifique à la licence BSD ? En quoi a-t-il sous-entendu que la GPL était différente sur ce point ?