Parler de dérèglement du climat suppose l'existence de règles fixes. Or le propre du climat est de changer constamment au cours de l'histoire. Donc cette expression me paraît aussi impropre que celle de réchauffement climatique
D'un autre côté c'est aux clients d'Open Source Security Inc de faire valoir leur droit car se sont eux qui subissent la clause
Non à mon avis ce ne sont pas seulement les clients qui peuvent faire valoir leurs droits.
Supposons que Bruce Perens ait raison. Alors cela signifie qu'un développeur ayant participé au noyau Linux peut légitimement attaquer Open Source Security Inc. En effet en travaillant sur le noyau il a produit du code sous GPLv2. Ici on a une entreprise qui reprend son code (puisqu'elle reprend le noyau) et y ajoute une restriction violant la GPLv2. Son copyright n'a donc pas été respecté et il est en droit d'attaquer.
La société a un seul employé (sans doute Brad lui-même) et apparemment le revenu annuel est de 140 000 dollars.
Cela ne nous dit pas quels sont les tarifs pratiqués pour chaque client mais cela donne un ordre de grandeur de l'argent brassé en un an par la société. Après il faudrait savoir de quand date cette info, est-ce qu'elle est fiable, etc etc.
Quand on prétend être une : "team of world-class experts in Linux security"
Je crois que personne ne nie ce point. Brad et PaXteam sont réellement des cadors de la sécurité. Dans leur patch noyau ils ont développé des techniques nouvelles qui sont en avance sur les autres. Ils sont vraiment reconnus dans le domaine. La preuve c'est que la Linux Foundation finance des devs pour essayer de porter certains trucs issus de Grsecurity dans le noyau vanilla.
c’est à priori de l’expertise et de la prestation intellectuelle, pas juste l’accès au logiciel, qu’on vend
Amha c'est là qu'est le point bloquant. Pour vendre de l'expertise et du conseil il faut interagir avec d'autres humains. Mais Brad et (dans une moindre mesure) PaXteam n'ont jamais fait preuve de la moindre capacité à travailler avec d'autres personnes.
Surtout que le message de Linus date de juin ne porte pas sur le procès fait à Bruce Perens mais uniquement sur les fonctions de sécurité de Grsecurity.
Il a toujours été d'avis que le code du noyau doit être maintenable, que les devs doivent travailler ensemble et que l'accent ne doit pas porter exclusivement sur un domaine au détriment de tous les autres. Comme Brad et PaXteam ne pensent qu'en terme de sécurité et qu'ils semblent incapables de bosser avec les simples mortels qui peuplent ce monde, il est normal que Linus ne veuille rien avoir à faire avec eux.
Après il y a son ton abrasif habituel.
Il s’agit de corriger les bugs du noyau en évitant d’en introduire d’autres avec un nouveau noyau.
Mouais…mais au fil des années de support d'une release cette stratégie devient amha de plus en plus casse-gueule. Rester sur le même noyau et rétroporter les patchs c'est assez facile les 2 ou 3 premières années (si on a une équipe de devs solide comme Red Hat). Mais au fur et à mesure le noyau vanilla diverge inexorablement (12 000 patchs tous les 3 mois quand même !!!) et le rétroportage de patchs devient de la jonglerie en monocycle sur un câble tendu au dessus des chutes du Niagara.
Je ne dis pas que les serveurs de Prod devraient tous être sous Arch…mais garder un noyau frankenstein pendant plus de 10 ans c'est pas non plus une solution attirante.
En gros c'est juste que Red Hat n'a pas l'expertise pour maintenir correctement Btrfs pendant la durée de support d'une release (ils doivent tout backporter parce qu'ils refusent de changer de noyau en cours de route).
Les autres BSD portant leur attention sur la qualité et la simplicité UNIX sont probablement plus fiable que Linux
Et donc tu sors ça d'où ? Tu as fait une étude rigoureuse quelconque ou bien c'est juste du vent ?
si l'on prends la dernière version de Linux, elle est probablement moins fiable que BSD
Même question.
OpenBSD reste au dessus
Même question.
L'avantage de l'étude d'Ilja c'était justement d'introduire de la rigueur dans toutes ces spéculations oiseuses qui courent sur la fiabilité relative des OS libres. Lui il s'est retroussé les manches et il a plongé dans le code pendant 3 mois pour essayer d'y voir plus clair.
Toi tu t'appuies sur quoi pour tes affirmations ?
Mais comment dans le même temps conclure que Linux c'est mieux
Il me semble que cette conclusion n'apparait ni dans le pdf d'Ilja ni dans mon journal.
La question était juste "Est-ce que la qualité intrinsèque du code des noyaux BSD peut expliquer le faible nombre de CVE ?". L'étude démontre qu'en regardant de plus près le code on trouve plein de bugs donc la réponse à la question est "Non".
C'est la seule conclusion rigoureuse qu'on puisse tirer. Il faut donc chercher une autre explication au faible nombre de CVE des BSD.
Mais pas question de dire (et personne ne le fait ici) que Linux c'est mieux.
En fin de pdf Ilja propose juste (sans éléments rigoureux pour étayer ça) que le nombre de relecteurs doit jouer un rôle.
Many eyeballs … Gut feeling, I suspect this is a factor. Say what you will about the people reviewing the Linux kernel code, there are simply orders of magnitude more of them.
Au début des années 90 étaient 386BSD, qui a alors forké en Net/Open/Free BSD d'un côté, et GNU/Linux de l'autre.
Ouch ! Va dire ça à RMS et Linus et tu vas te prendre un coup de pelle.
Pour le reste je trouve ton trollo-journal assez médiocre et convenu. Non systemd n'est pas "en train de bouffer l'univers Linux" comme si c'était un prédateur venu de l'extérieur. Ce sont les développeurs de l'écosystème Linux qui ont décidé de créer et de passer à systemd. Ce sont eux, les faiseurs, et pas les commentateurs qui sont les créateurs de l'univers Linux.
Les tests à l'écoute c'est bien mais c'est trop empirique. Une analyse comparative avec un analyseur de spectre donnerait la confirmation indiscutable de la puissance de l'algo d'Opus.
Ne pas oublier que les algos de compression avec pertes se basent sur des modèles psycho-acoustiques donc il est important que l'oreille humaine soit utilisée pour valider les modèles.
Heu si, si ça remplace Vorbis.
Pour la musique cela a été testé en aveugle et il a été montré qu'Opus est meilleur que MP3, Vorbis et AAC => http://listening-test.coresv.net/results.htm
Merci pour ce correcteur (et pour cette dépêche). J'ai testé sur divers journaux LinuxFr et ça marche vraiment bien.
Ça laisse quand même passer des trucs. Par exemple dans ce journal la phrase "On peut se dire que c'est anti-constitutionnelle" n'est pas jugée fautive.
possible que opus (et même vorbis) soient bien meilleurs
Opus est effectivement meilleur que MP3 mais il faut préciser en quoi il est meilleur : Avec Opus on peut obtenir une même qualité audio que le MP3 avec un débit plus faible.
Par exemple (chiffres bidons inventés pour l'argumentation) on aura la même qualité audio entre MP3 256 kb/s et Opus 160 kb/s.
Mais ça ne veut pas dire que le MP3 est intrinsèquement pourri et a toujours un son plus mauvais qu'Opus. Juste qu'il faut lui donner plus de débit pour obtenir la même qualité qu'Opus.
Donc si tu n'es pas exagérément contraint par l'espace disque cela reste parfaitement rationnel de privilégier MP3 puisqu'il est reconnu bien plus largement qu'Opus. On aura juste des fichiers plus gros.
J'ai lu une bonne partie des documents, et je ne vois pas comment il pourrait s'agir de fausses boîtes e-mail._
Extrait de l'article du New York Times cité plus haut (très intéressant):
Mahjoubi refused to reveal the nature of the false documents that were created, or to say whether, in the Friday document dump that was the result of the hacking campaign, there were false documents created by the Macron campaign.
But he did note that in the mishmash that constituted the Friday dump, there were some authentic documents, some phony documents of the hackers’ own manufacture, some stolen documents from various companies, and some false emails created by the campaign.
[^] # Re: Réchauffement ou Dérèglement ?
Posté par patrick_g (site web personnel) . En réponse au journal Le jour d’après, c’est aujourd’hui. Évalué à 10. Dernière modification le 07 septembre 2017 à 16:23.
Changement-climatique-rapide-d'origine-anthropique ?
[^] # Re: Exceptionnel ou systémique ?
Posté par patrick_g (site web personnel) . En réponse au journal Le jour d’après, c’est aujourd’hui. Évalué à 2.
https://linuxfr.org/aide#aide-imgcertificatssl
# Dépêche
Posté par patrick_g (site web personnel) . En réponse au journal Nouvelles de ZeMarmot, GIMP et GIMP Motion (plugin d'animation dans GIMP). Évalué à 5.
J'ai poussé le journal dans la file de rédaction des dépêches.
[^] # Re: A quoi sert vraiment cette clause ?
Posté par patrick_g (site web personnel) . En réponse au journal Grsecurity attaque Bruce Perens en justice pour diffamation. Évalué à 9.
Non à mon avis ce ne sont pas seulement les clients qui peuvent faire valoir leurs droits.
Supposons que Bruce Perens ait raison. Alors cela signifie qu'un développeur ayant participé au noyau Linux peut légitimement attaquer Open Source Security Inc. En effet en travaillant sur le noyau il a produit du code sous GPLv2. Ici on a une entreprise qui reprend son code (puisqu'elle reprend le noyau) et y ajoute une restriction violant la GPLv2. Son copyright n'a donc pas été respecté et il est en droit d'attaquer.
[^] # C'était le point pédanterie du jour
Posté par patrick_g (site web personnel) . En réponse au journal Grsecurity attaque Bruce Perens en justice pour diffamation. Évalué à 5.
s/gâchette/détente
[^] # Re: Combien ?
Posté par patrick_g (site web personnel) . En réponse au journal Grsecurity attaque Bruce Perens en justice pour diffamation. Évalué à 10. Dernière modification le 05 août 2017 à 18:10.
Sous l'article LWN consacré à cette affaire, un user a posté un commentaire intéressant au sujet des revenus d'Open Source Security Inc.
La société a un seul employé (sans doute Brad lui-même) et apparemment le revenu annuel est de 140 000 dollars.
Cela ne nous dit pas quels sont les tarifs pratiqués pour chaque client mais cela donne un ordre de grandeur de l'argent brassé en un an par la société. Après il faudrait savoir de quand date cette info, est-ce qu'elle est fiable, etc etc.
Je crois que personne ne nie ce point. Brad et PaXteam sont réellement des cadors de la sécurité. Dans leur patch noyau ils ont développé des techniques nouvelles qui sont en avance sur les autres. Ils sont vraiment reconnus dans le domaine. La preuve c'est que la Linux Foundation finance des devs pour essayer de porter certains trucs issus de Grsecurity dans le noyau vanilla.
Amha c'est là qu'est le point bloquant. Pour vendre de l'expertise et du conseil il faut interagir avec d'autres humains. Mais Brad et (dans une moindre mesure) PaXteam n'ont jamais fait preuve de la moindre capacité à travailler avec d'autres personnes.
[^] # Re: Les quatre libertés des logiciels libres
Posté par patrick_g (site web personnel) . En réponse au journal Grsecurity attaque Bruce Perens en justice pour diffamation. Évalué à 8.
Et donc c'est quoi ton avis ?
[^] # Re: Garbage!
Posté par patrick_g (site web personnel) . En réponse au journal Grsecurity attaque Bruce Perens en justice pour diffamation. Évalué à 10.
Surtout que le message de Linus date de juin ne porte pas sur le procès fait à Bruce Perens mais uniquement sur les fonctions de sécurité de Grsecurity.
Il a toujours été d'avis que le code du noyau doit être maintenable, que les devs doivent travailler ensemble et que l'accent ne doit pas porter exclusivement sur un domaine au détriment de tous les autres. Comme Brad et PaXteam ne pensent qu'en terme de sécurité et qu'ils semblent incapables de bosser avec les simples mortels qui peuplent ce monde, il est normal que Linus ne veuille rien avoir à faire avec eux.
Après il y a son ton abrasif habituel.
[^] # Re: Red Hat != World
Posté par patrick_g (site web personnel) . En réponse au journal Btrfs ne serait plus le futur. Évalué à 10. Dernière modification le 02 août 2017 à 22:47.
Mouais…mais au fil des années de support d'une release cette stratégie devient amha de plus en plus casse-gueule. Rester sur le même noyau et rétroporter les patchs c'est assez facile les 2 ou 3 premières années (si on a une équipe de devs solide comme Red Hat). Mais au fur et à mesure le noyau vanilla diverge inexorablement (12 000 patchs tous les 3 mois quand même !!!) et le rétroportage de patchs devient de la jonglerie en monocycle sur un câble tendu au dessus des chutes du Niagara.
Je ne dis pas que les serveurs de Prod devraient tous être sous Arch…mais garder un noyau frankenstein pendant plus de 10 ans c'est pas non plus une solution attirante.
# Red Hat != World
Posté par patrick_g (site web personnel) . En réponse au journal Btrfs ne serait plus le futur. Évalué à 10.
L'explication de Josef Bacik (un des devs de Btrfs) : https://news.ycombinator.com/item?id=14909843
En gros c'est juste que Red Hat n'a pas l'expertise pour maintenir correctement Btrfs pendant la durée de support d'une release (ils doivent tout backporter parce qu'ils refusent de changer de noyau en cours de route).
[^] # Re: La qualité dépends de l'attention porté à la sécurité.
Posté par patrick_g (site web personnel) . En réponse au journal Les BSD sont‐ils tous égaux devant les bugs ?. Évalué à 3.
Mmm…y'a un truc bizarre pour le scan Coverity d'OpenBSD : https://scan.coverity.com/projects/openbsd-kernel
Il est indiqué que le nombre de lignes scannées est seulement de 15 858.
[^] # Re: La qualité dépends de l'attention porté à la sécurité.
Posté par patrick_g (site web personnel) . En réponse au journal Les BSD sont‐ils tous égaux devant les bugs ?. Évalué à 10.
Et donc tu sors ça d'où ? Tu as fait une étude rigoureuse quelconque ou bien c'est juste du vent ?
Même question.
Même question.
L'avantage de l'étude d'Ilja c'était justement d'introduire de la rigueur dans toutes ces spéculations oiseuses qui courent sur la fiabilité relative des OS libres. Lui il s'est retroussé les manches et il a plongé dans le code pendant 3 mois pour essayer d'y voir plus clair.
Toi tu t'appuies sur quoi pour tes affirmations ?
[^] # Re: Certif autosigné
Posté par patrick_g (site web personnel) . En réponse au journal Les BSD sont‐ils tous égaux devant les bugs ?. Évalué à 5.
La news EuroBSDCon (j'ai réparé la typo dans ton lien) est très bien rédigée et informative. Peut-être qu'il n'y a pas grand chose à y ajouter ?
Oui les blogposts de tedu@ sont intéressants. Je me permet de coller également un lien vers un post récent de David Madore au sujet du HTTPS.
C'est plein de food for thought !
[^] # Re: Il manque encore un peu de travail pour conclure :)
Posté par patrick_g (site web personnel) . En réponse au journal Les BSD sont‐ils tous égaux devant les bugs ?. Évalué à 10.
Il me semble que cette conclusion n'apparait ni dans le pdf d'Ilja ni dans mon journal.
La question était juste "Est-ce que la qualité intrinsèque du code des noyaux BSD peut expliquer le faible nombre de CVE ?". L'étude démontre qu'en regardant de plus près le code on trouve plein de bugs donc la réponse à la question est "Non".
C'est la seule conclusion rigoureuse qu'on puisse tirer. Il faut donc chercher une autre explication au faible nombre de CVE des BSD.
Mais pas question de dire (et personne ne le fait ici) que Linux c'est mieux.
En fin de pdf Ilja propose juste (sans éléments rigoureux pour étayer ça) que le nombre de relecteurs doit jouer un rôle.
# Portnawak
Posté par patrick_g (site web personnel) . En réponse au journal Vous avez aimé BSD vs System V ? Vous aimerez systemd vs openRC (et le reste du monde). Évalué à 10.
Ouch ! Va dire ça à RMS et Linus et tu vas te prendre un coup de pelle.
Pour le reste je trouve ton trollo-journal assez médiocre et convenu. Non systemd n'est pas "en train de bouffer l'univers Linux" comme si c'était un prédateur venu de l'extérieur. Ce sont les développeurs de l'écosystème Linux qui ont décidé de créer et de passer à systemd. Ce sont eux, les faiseurs, et pas les commentateurs qui sont les créateurs de l'univers Linux.
[^] # Re: Vorbis
Posté par patrick_g (site web personnel) . En réponse au journal Opus 1.2. Évalué à 10.
Ne pas oublier que les algos de compression avec pertes se basent sur des modèles psycho-acoustiques donc il est important que l'oreille humaine soit utilisée pour valider les modèles.
[^] # Re: Vorbis
Posté par patrick_g (site web personnel) . En réponse au journal Opus 1.2. Évalué à 9.
Heu si, si ça remplace Vorbis.
Pour la musique cela a été testé en aveugle et il a été montré qu'Opus est meilleur que MP3, Vorbis et AAC => http://listening-test.coresv.net/results.htm
[^] # Re: Vivement la suivante
Posté par patrick_g (site web personnel) . En réponse à la dépêche Debian 9 : Stretch déploie ses tentacules. Évalué à 5.
Pourquoi ne pas faire une version AppImage de ton logiciel ?
# Super projet
Posté par patrick_g (site web personnel) . En réponse à la dépêche Grammalecte, correcteur grammatical [2]. Évalué à 7.
Merci pour ce correcteur (et pour cette dépêche). J'ai testé sur divers journaux LinuxFr et ça marche vraiment bien.
Ça laisse quand même passer des trucs. Par exemple dans ce journal la phrase "On peut se dire que c'est anti-constitutionnelle" n'est pas jugée fautive.
[^] # Re: hors sujet
Posté par patrick_g (site web personnel) . En réponse au journal Serveur Git avec Gitolite. Évalué à 4.
Fait.
[^] # Re: hors sujet
Posté par patrick_g (site web personnel) . En réponse au journal Serveur Git avec Gitolite. Évalué à 4.
Modif effectuée.
[^] # Re: C'est une technologie dépassée
Posté par patrick_g (site web personnel) . En réponse à la dépêche Expiration des brevets du Fraunhofer Institute sur le format MP3. Évalué à 7.
Opus est effectivement meilleur que MP3 mais il faut préciser en quoi il est meilleur : Avec Opus on peut obtenir une même qualité audio que le MP3 avec un débit plus faible.
Par exemple (chiffres bidons inventés pour l'argumentation) on aura la même qualité audio entre MP3 256 kb/s et Opus 160 kb/s.
Mais ça ne veut pas dire que le MP3 est intrinsèquement pourri et a toujours un son plus mauvais qu'Opus. Juste qu'il faut lui donner plus de débit pour obtenir la même qualité qu'Opus.
Donc si tu n'es pas exagérément contraint par l'espace disque cela reste parfaitement rationnel de privilégier MP3 puisqu'il est reconnu bien plus largement qu'Opus. On aura juste des fichiers plus gros.
[^] # Re: Coquille
Posté par patrick_g (site web personnel) . En réponse au journal Un décalage de 64 bits, ça vous inspire comment ?. Évalué à 3.
Corrigé.
[^] # Re: fôte
Posté par patrick_g (site web personnel) . En réponse à la dépêche Revue de presse — mai 2017. Évalué à 3.
Les deux typo sont corrigées.
Merci.
[^] # Re: Un peu gros
Posté par patrick_g (site web personnel) . En réponse au journal MacronLeaks est tombé dans le pot de miel tendu par En Marche!. Évalué à 9.
Extrait de l'article du New York Times cité plus haut (très intéressant):
Mahjoubi refused to reveal the nature of the false documents that were created, or to say whether, in the Friday document dump that was the result of the hacking campaign, there were false documents created by the Macron campaign.
But he did note that in the mishmash that constituted the Friday dump, there were some authentic documents, some phony documents of the hackers’ own manufacture, some stolen documents from various companies, and some false emails created by the campaign.