Il existe toute une liste de traits typiques des machos et des misogynes :
Il minimise les agressions : être atteint(e) dans son intégrité physique n'est pas si grave si c'est juste une caresse
Il trouve toutes les excuses à l'annihilation de la volonté de la femme : elle le « cherchait » bien ; il existerait une limite à partir de laquelle la femme doit se laisser faire et où elle ne pourra plus user de sa volonté
Il se fout de la gueule de son interlocuteur en inventant des retournements de situation les plus ubuesques, par exemple en utilisant la « probable » homosexualité du sujet
Il arrive à dénicher une femme qui se sent homme et l'utilise comme contre-argument pour toutes les autres
Il essaye d'inverser la situation pour montrer qu'elle serait « acceptable » dans l'autre sens, en oubliant volontairement tout le contexte misogyne de la société
Il joue de l'ironie sur l'esclavagisation des hommes
Il ne voit pas la relation entre la qualification des femmes uniquement d'après leur physique, et le sexisme
Je pense qu'on a un beau condensé dans les commentaires ci-dessus. Ne vous étonnez-pas que vous n'ayez jamais de réponses à vos « remarques », et que vous vous confortiez ainsi dans votre pensée.
Parce que certains périphériques ne marchent pas quand le système est en veille : tous ne sont pas branchés de manière à pouvoir émettre une interruption matérielle au processeur (par exemple les touchscreens ; en plus, ça réveillerait ton smartphone tout le temps quand il est dans ta poche, et ça boufferait beaucoup de batterie). Et certains ne peuvent simplement pas marcher quand le CPU n'est pas la pour effectuer une partie du travail (genre la caméra).
Nvidia n'a jamais rien fait pour le Libre, il a toujours été contre. Espérer quelque chose aujourd'hui c'est vraiment croire au père Noël.
Surtout que pour développer des (vrais?) jeux, les développeurs auront bien plus besoin des specs du hardware que pour développer un jeu qui nous demande de lancer des oiseaux fâchés sur des cochons.
Gni ? OpenGL et consorts te suffisent largement. C'est pour ça qu'ils ont choisi un OS généraliste, je pense, car ça ne sera pas une plateforme de développement spécialisée.
Et il fallait un noyau et un xorg récents pour le support des cartes graphique et réseau intégrées.
Pour info, dans ce cas moi j'utilise squeeze + backports, et il existe une version du debian-installer avec kernel backporté, pour les matos récents : http://kmuto.jp/debian/d-i/
Bon alors en fait, je me suis penché un peu plus sur un autre utilitaire dont j'entends parler depuis quelques temps : socat [http://www.dest-unreach.org/socat/]. Parce que j'ai lu qu'il résolvait beaucoup de choses. Et bien il peut nous aider ici ! On peut lui demander de connecter l'entrée et la sortie standard sur un tty quelconque, comme ça on est indépendant de si c'est dans un screen/tmux/terminal directement. C'est extrait du man en plus, mais j'ai enlevé la conversion CR/NL :
Comme ça, on a ^O (c'est le escape=0x0f) pour terminer socat, et il passera les autres séquences comme il faut. Allez voir la section sur les options termios dans le man pour voir tout ce qu'il est possible de configurer, comme la vitesse du port série, etc.
Bah justement, c'est ma deuxième ou troisième utilisation la plus courante, et je comptais aller faire un patch un jour. J'ai déjà regardé le code, ça me semble faisable pas trop difficilement. Si quelqu'un d'autre en a besoin, ça me motive d'autant plus.
C'est drôle, en lisant ton journal, je me dis « chouette, ça a peut-être avancé niveau perfs », et je regarde le résultat de ta commande pour mon système actuel :
% uname -r ; cat /proc/cpuinfo | grep "model name" ; lspci -nnk |grep -A 2 "VGA" ; glxinfo |grep -A 3 "OpenGL vendor" ; glewinfo |grep s3tc 3.2.0-2-amd64
model name : AMD Athlon(tm) X2 260 Processor
model name : AMD Athlon(tm) X2 260 Processor
01:05.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI RS780 [Radeon HD 3200] [1002:9610]
Subsystem: Giga-byte Technology GA-MA78GM-S2H Motherboard [1458:d000]
Kernel driver in use: radeon
--
02:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI Manhattan [Mobility Radeon HD 5430 Series] [1002:68e1]
Subsystem: PC Partner Limited Device [174b:3000]
Kernel driver in use: radeon
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD CEDAR
OpenGL version string: 2.1 Mesa 8.0.3
OpenGL shading language version string: 1.20
zsh: command not found: glewinfo
Niveau soft, c'est pareil ; niveau hard, on va dire CPU équivalent, mais carte effectivement moins puissante (je n'utilise plus l'intégrée).
Et bah moi je fais juste de la 2D, l'accélération c'est juste pour les effets de gnome shell… Et bien c'est pas très fluide tout ça ! Certes, j'ai un gros affichage :
% xrandr | head -1
Screen 0: minimum 320 x 200, current 4020 x 1680, maximum 8192 x 8192
Mais franchement, c'est à la limite du supportable tellement les trucs sont lents des fois (et c'est réellement du à l'affichage ; sur l'intégrée en simple écran, ça va). Je ne pense pas que la carte soit limitante, enfin j'espère, donc je pense qu'il reste encore des efforts à faire au niveau de ces drivers. Mais ça s'améliore régulièrement…
Pour réitérer ce qui a été dit au-dessus, FDN faisant parti de la FFDN, toute la France métropolitaine est couverte, même si c'est un peu « tricher » par rapport aux locaux.
sur x86, tu peux faire tourner ce que tu veux si tu stoppes SecureBoot
Et demain, pour Windows 9, il te suffira juste de leur signer une lettre de décharge en 3 exemplaires, et tu auras éventuellement le droit d'utiliser ton ordinateur en mode non-« sécurisé ».
sur ARM, ce materiel la ne fera tourner que certains de tes logiciels (ceux qui tournent sur Win8), a toi de choisir si ce matos repond a tes besoins ou pas, et achete en consequence. Tu es libre d'acheter d'autres materiels qui eux feront tourner ce que tu veux. Ils ne t'interdisent absolument rien, tu fais ce que tu veux de tes logiciels, il s'agit d'une limitation du materiel que tu achetes en connaissance de cause.
C'est exactement le même discours que la mafia qui te dit que tu as la liberté de ne pas payer. Tu sais très bien la puissance de MS, tu es son représentant ici, et te voir pérorer comme ça me fait gerber. Tu ressors les même conneries en boucle. Dégage d'ici, connard.
Et t'inquiètes, je trouve aussi nase la fermeture des Android & co (je n'en ai pas pour cette raison), au cas où tu me le ressortes ; c'est juste que MS et toi vous avez un tel historique qu'on ne peut pas s'empêcher ce genre de réaction. D'ailleurs, je vais m'arrêter ici.
On ne propose a personne de se faire signe, on dit juste que les autres distribution peuvent faire comme nous en reutilisant les memes outils, la seul chose qu'on ne partage pas c'est notre cle prive.
Oui enfin vous facilitez vachement la tâche à ceux qui veulent se faire signer. Ça s'approche beaucoup de l'incitation, selon moi.
Je peux te dire que tous mes collegues ici Red Hat (Matthew inclus) n'aime pas secure boot. La question qui c'est pose c'est comment permettre a Madame Michu de tester voir meme d'installer une fedora sur son pc flambant neuf qui a windows 8. Sachant que les pc certifies windows8 auront le secure boot d'active par defaut.
Demande t-on a Madame Michue d'aller le menu uefi pour desactive le secure boot (et comme ca ne sera pas standardise au temps dire impossible d'ecrire un manuel simple et qui s'applique a tous les pc).
Ou alors on fait en sorte que nos livecd/cd d'install soit aussi bootable avec secure boot.
Madame michu n'a jamais été capable d'installer un Linux, alors ça ne change rien cette histoire de Secure Boot à désactiver dans le BIOS. Les personnes capables d'installer/administrer un Linux sauront désactiver le Secure Boot.
Voila. Bon y avait d'autre solutions mais encore plus pourris et plus incertaines.
Je ne vois pas en quoi la solution de refuser de se faire signer et de demander de désactiver le Secure Boot était plus pourrie et incertaine. Et je trouve ça drôle de dire que d'un côté, le désactiver est « difficile » pour madame michu, et de l'autre que c'est « simple » si on le veut réellement. C'est prendre les gens pour des ignorants en les faisant passer complètement à côté de l'implication qu'a ce switch et ce genre de techno.
Donc en conclusion, je ne dirai pas qu'on supporte secure boot mais qu'on s'en accomode. Mais c'est une question de point de vue. Je repete que je trouve cette techno inutile, incertaine, dangeureuse, liberticide et probablement rapidement ineffective.
Qu'une personne lambda s'en « accommode », OK. Que Red Hat, qui est une entreprise majeure dans le libre, qui se bat contre les brevets logiciels, les violations de la GPL, etc, abdique d'un coup sans autre revendication contre TPM, je trouve ça très dommage, pour ne pas dire plus. Ne se rendent-ils pas compte que c'est faire rentrer le loup dans la bergerie ?
Le fait que Matthew et d'autres fassent passer ça pour quelque chose d'anodin me fait encore plus peur : on parle bien de l'interdiction de modifier ses logiciels ! Franchement, qu'est-ce qu'il faut comme atteinte au Libre pour que Red Hat réagisse ?
Tu serais donc sympa de rester poli et revoir ce que tu ecris avant de l'ecrire.
C'est une formule pour dire que ça a beau être vrai, le fait que ça soit off par défaut et que ça soit géré à moitié fait que la majorité des gens qui connaissent cette histoire de casse ne te croiront pas si tu leur dit que NTFS le gère quand même.
Mais voilà, avec toi c'est toujours pareil, ton but c'est de faire perdre du temps aux gens en jouant au débile mental, et tu y arrives bien.
L'idee c'est que d'autre distribution peuvent reutilise le bootloader changer la cle RH par leur propre cle et signe leur kernel avec leur cle. Voila Red Hat n'oblige et n'empeche personne. Donc pour 99$ d'autre compagnie peuvent faire signe le bootloader avec leur propre cle.
Ha, moi je ne l'avais pas compris comme ça, pardon. Mais alors, dire qu'ils ne « supportent » pas Secure Boot est un peu fort : c'est justement ce qu'ils font en proposant aux gens de se faire signer.
Et si tu compiles ton propres kernel alors tu dois t'y connaitre assez pour aller dans l'uefi desactive le secure boot ou y ajouter ta cle personnel.
Mais ça n'est pas le problème… Tout bon libriste sait que c'est le choix par défaut qui importe, et que ce genre de mécanisme désactivable ne le sera plus un jour. C'est le premier pas dans la mauvaise direction.
Tu m'expliques le rapport ? Tu voudrais que les constructeurs vendent des PC nus uniquement ?
Homme de paille, toussa. Si tu veux être certifié Windows 8 (ce que feront bien sûr tous les constructeurs), toi dois obligatoirement mettre Windows sur ton ordi, tu nu peux pas le vendre sans. Ça s'appelle la vente liée, au cas où tu ne serais pas au courant.
En passant, tu peux me donner la raison de cette différence de traitement entre x86 et ARM ?
Choix. Sur x86 tous les PCs se vendront avec Windows
(au passage, belle confirmation sur mon affirmation plus haut)
et le gars moyen n'aurait aucun choix --> permettre de desactiver.
Moui… Donc avant c'était évident qu'on devait pouvoir installer ce qu'on veut sur sa machine, maintenant c'est Microsoft, grand seigneur, qui vous fait l'honneur d'avoir le choix d'installer un OS autre que Windows sur les ordinateurs qui contiendront tous sa clé. Merci !
Sur ARM, deja il est peu probable qu'un autre systeme tourne dessus facilement et en plus il y a plein de systemes se vendant sans Windows, donc pas le meme probleme(et surtout pas de risque de proces pour violation de monopole).
Les systèmes ARM se vendant sans Windows ne pouvant pas fonctionner avec Windows, la certification Windows 8 ils s'en balancent un peu. Concernant la « probabilité » qu'un autre système tourne dessus, j'« aime » bien que MS s'arroge le droit de le décider. Forcément, si Secure Boot n'est pas désactivable, il ne risque pas d'arriver beaucoup de systèmes alternatifs…
Quant au « pas de risque de procès pour violation de monopole », ça montre bien que MS n'en a rien à foutre d'enfermer tout le monde.
Du moins, c'est mon avis.
Donc, tu confirmes que le but de MS c'est d'enfermer les gens pour qu'ils n'aient pas le choix de leur OS, c'est ça ? Parce que ton pseudo-argument du « choix » (ça n'est pas un argument, car il essaye de se justifier par lui-même) ne vaut rien.
Pourquoi tu veux toujours jouer au con ?
Je n'ai jamais dit que NTFS ne gérait pas la casse, arrête d'imaginer les remarques qui t'arrangent. NTFS saura stocker ton fichier sensible à la casse. Mais une appli lambda ne pourra pas choisir lequel elle ouvre. C'est ce qu'on appelle supporter à moitié, comme on disait plus haut.
Je te rappelais l'importance des choix par défaut un peu plus haut… Tu vois comme c'est emmerdant quand c'est pas dans ton sens ? (parce que tu n'arriveras à convaincre personne que le FS de Windows gère la casse même avec cette option, tellement c'est anecdotique, et qu'en plus je suis sûr que ça casse la moitié du système)
Oui enfin il existe des ports « spécifiques », avec des kernels qui supportent une plateforme donnée, avec des scripts qui changent le “machine code” (je n'ai plus le nom exact) inclus dans le kernel pour faire plaisir au bootloader de la machine en particulier (c'est fait avec des hooks post-install dans dpkg). Tu peux voir ici un certain nombre de machines gérées pour armel, par exemple, avec en prime l'installeur qui peut se lancer depuis le système original, en général :
J'en parle parce que j'ai justement fait le support d'un (avec l'aide de Martin Michlmayr qui bosse beaucoup pour le support ARM dans Debian). Je pense que le nombre de machines supportées mais sans installeur est encore plus grand.
Merci. La désactivation de Secure Boot sera donc bien présente.
On en voit aussi d'autres pas mal :
Mandatory. A working WinRE image must be present on all Win8 Client systems The Windows Recovery image must be present in the factory image on every Secure Boot capable system.
La vente liée n'est pas près de s'arrêter…
Nocive ? Tu m'expliques comment ? L'utilisateur peut le stopper, peut ajouter les clefs qu'il veut.
Oui OK, je vois que tu veux jouer à ça, je t'arrête tout de suite, ça ne m'intéresse pas.
En passant, tu peux me donner la raison de cette différence de traitement entre x86 et ARM ?
Enfin bon, de toutes manières, tu ne réponds même pas au problème principal, comme tous les supporters de cette techno : tu veux juste à tout prix montrer qu'on « peut » la désactiver, sans même parler de la nocivité de la techno en elle-même. C'est toujours les même méthodes, déplacer le débat. Alors que tu sais très bien la différence que ça fait que ça soit activé par défaut : le « par défaut », MS connaît bien.
En fait, ce truc c'est juste le retour du TPM (puisque c'est exactement un TPM qui est utilisé) encore sous un autre nom, sauf que MS a cette fois-ci bien réussi à « convaincre » tous les constructeurs de mettre sa clé dedans par défaut. Mais on dirait que personne ne s'en rend compte.
Ça fait au moins un an que Matthew Garret (mjg59) travaille sur le support de Secure Boot, non pas pour le plaisir de verrouiller les machines mais parce que ça sera une technologie incontournable vu que Microsoft compte l'imposer pour être certifié Windows 8.
On a toujours le choix. On pourrait aussi bien dire qu'essayer de faire du Logiciel Libre est inutile car de toutes façons Windows est vendu avec toutes les machines. Red Hat, vu sa position, avait tout à fait le pouvoir pour bien faire pencher la balance dans le sens du libre (je ne dis pas qu'ils y seraient arrivés tout seul, mais ils ont un poids certain). Je trouve très dommageable qu'ils aient accepté ce compromis foireux.
certains constructeurs peuvent rendre non optionnel cette fonctionnalité (Microsoft est revenu en arrière et n'impose plus que ça soit non désactivable)
On sait très bien que les « peuvent » dans ce cadre là sont très hypothétiques.
certains utilisateurs peuvent vouloir utiliser fonctionnalité et c'est leur droit.
Ils pouvaient déjà avant, c'est exactement le rôle de TPM. Ici, on parle de la rendre active par défaut partout, avec la clé de MS, ce qui est très différent. Cette remarque n'apporte donc aucune justification.
sur ARM, Microsoft impose que Secure Boot ne soit pas désactivable et aucune solution ne sera proposé pour le supporter.
Génial.
En résumé, la solution de Fedora sera de signer le stage1 de Grub2 (qui change rarement au cours de la vie d'une version contrairement au noyau) et non pas le noyau.
Et ? Au final, pour que Red Hat garde sa certification, il ne faut pas qu'il accepte avec ce bootloader de booter n'importe quel stage 2, et subséquemment n'importe quel noyau. Sinon, ils vont se faire révoquer leur clé. Bref, indirectement, ça revient à signer également le noyau.
C'est une solution qui a été choisie en concertation avec la fondation Linux afin d'être réutilisable par les autres distributions, ce que ne permette pas les autres solutions.
Mais c'est tout aussi pourri, parce que bien sûr Red Hat ne va pas signer n'importe quel stage 2 : seulement ceux qui chargent des noyaux vérifiés. Bref, Red Hat se place en autorité de certification de qui dans le libre aura le droit de booter en mode « sécurisé » !
C'est toujours la même chose dans les mondes fermés : on appâte les premiers en leur donnant du pouvoir sur les suivants. Comme ça, ils craquent plus facilement. Ce qu'a fait Red Hat est vraiment pas classe.
Donc on voit bien les deux axes d'amélioration : gzip (même si en local ce n'est pas le primordial) et compilation
OK, merci pour ce test. Même si, quand on regarde en détail, il n'est pas super cohérent avec ton autre bench : version compilée « seulement » deux fois moins lourde, contre 8 fois moins précédemment ; versions gzippée qui ne réduit pas beaucoup (c'est du code beaucoup plus « complexe » dans ce bench, peut-être ?) ; grosse différence inexpliquée de la version gzippée compilée. Mais c'est intéressant de voir que la version compilée fait effectivement gagner un certain temps.
J'espère que ça répond un peu plus à tes questions.
# À quoi reconnaît-on un macho ?
Posté par benoar . En réponse à la dépêche Petite rétrospective diversité, sexisme, harcèlement et humour vaseux. Évalué à 10.
Il existe toute une liste de traits typiques des machos et des misogynes :
Je pense qu'on a un beau condensé dans les commentaires ci-dessus. Ne vous étonnez-pas que vous n'ayez jamais de réponses à vos « remarques », et que vous vous confortiez ainsi dans votre pensée.
[^] # Re: empeche ou permet
Posté par benoar . En réponse à la dépêche Sortie du noyau Linux 3.5. Évalué à 3.
Parce que certains périphériques ne marchent pas quand le système est en veille : tous ne sont pas branchés de manière à pouvoir émettre une interruption matérielle au processeur (par exemple les touchscreens ; en plus, ça réveillerait ton smartphone tout le temps quand il est dans ta poche, et ça boufferait beaucoup de batterie). Et certains ne peuvent simplement pas marcher quand le CPU n'est pas la pour effectuer une partie du travail (genre la caméra).
[^] # Re: Nop, bug d'OpenSSH
Posté par benoar . En réponse au journal Compromission de clé SSH chez OVH. Évalué à 1.
Dommage, ce patch est faux : la chaîne de format ne prend plus qu'un argument alors que deux sont toujours passés.
[^] # Re: Masochiste pragmatique
Posté par benoar . En réponse au journal Et les lecteurs de Linuxfr, ils votent pour qui ?. Évalué à 8.
T'as des convictions, toi !
[^] # Re: Hardware "ouvert" c'est quoi ?
Posté par benoar . En réponse au journal Ouya: la console libre ?. Évalué à 1.
Gni ? Je ne vois pas de quoi tu veux parler.
Nan mais ils vendent mille fois plus de laptops avec cartes Nvidia que ne sera vendue cette console. Ça ne changera rien…
[^] # Re: Hardware "ouvert" c'est quoi ?
Posté par benoar . En réponse au journal Ouya: la console libre ?. Évalué à 4.
Nvidia n'a jamais rien fait pour le Libre, il a toujours été contre. Espérer quelque chose aujourd'hui c'est vraiment croire au père Noël.
Gni ? OpenGL et consorts te suffisent largement. C'est pour ça qu'ils ont choisi un OS généraliste, je pense, car ça ne sera pas une plateforme de développement spécialisée.
[^] # Re: Hardware "ouvert" c'est quoi ?
Posté par benoar . En réponse au journal Ouya: la console libre ?. Évalué à 2.
Tu rêves. Bref, cette console n'est pas plus ouverte que n'importe quel téléphone Android.
[^] # Re: wheezy en stable ? depuis quand ?
Posté par benoar . En réponse au message La souris virtuelle (Maj+NumLock) ne marche plus dans wheezy. Évalué à 3.
Pour info, dans ce cas moi j'utilise squeeze + backports, et il existe une version du debian-installer avec kernel backporté, pour les matos récents : http://kmuto.jp/debian/d-i/
[^] # Re: serie
Posté par benoar . En réponse au journal Utiliser tmux aussi bien en local qu'en distant. Évalué à 2.
Bon alors en fait, je me suis penché un peu plus sur un autre utilitaire dont j'entends parler depuis quelques temps : socat [http://www.dest-unreach.org/socat/]. Parce que j'ai lu qu'il résolvait beaucoup de choses. Et bien il peut nous aider ici ! On peut lui demander de connecter l'entrée et la sortie standard sur un tty quelconque, comme ça on est indépendant de si c'est dans un screen/tmux/terminal directement. C'est extrait du man en plus, mais j'ai enlevé la conversion CR/NL :
Comme ça, on a ^O (c'est le
escape=0x0f) pour terminer socat, et il passera les autres séquences comme il faut. Allez voir la section sur les options termios dans le man pour voir tout ce qu'il est possible de configurer, comme la vitesse du port série, etc.[^] # Re: serie
Posté par benoar . En réponse au journal Utiliser tmux aussi bien en local qu'en distant. Évalué à 2.
Bah justement, c'est ma deuxième ou troisième utilisation la plus courante, et je comptais aller faire un patch un jour. J'ai déjà regardé le code, ça me semble faisable pas trop difficilement. Si quelqu'un d'autre en a besoin, ça me motive d'autant plus.
# Un autre point de vue
Posté par benoar . En réponse au journal [Radeon] Enemy Territory: QUAKE Wars jouable out-of-the-box sur Fedora 17. Évalué à 3.
C'est drôle, en lisant ton journal, je me dis « chouette, ça a peut-être avancé niveau perfs », et je regarde le résultat de ta commande pour mon système actuel :
Niveau soft, c'est pareil ; niveau hard, on va dire CPU équivalent, mais carte effectivement moins puissante (je n'utilise plus l'intégrée).
Et bah moi je fais juste de la 2D, l'accélération c'est juste pour les effets de gnome shell… Et bien c'est pas très fluide tout ça ! Certes, j'ai un gros affichage :
Mais franchement, c'est à la limite du supportable tellement les trucs sont lents des fois (et c'est réellement du à l'affichage ; sur l'intégrée en simple écran, ça va). Je ne pense pas que la carte soit limitante, enfin j'espère, donc je pense qu'il reste encore des efforts à faire au niveau de ces drivers. Mais ça s'améliore régulièrement…
[^] # Re: J'aimerais bien mais il n'y a pas de FAI de FFDN actif là où j'habite
Posté par benoar . En réponse au sondage Votre FAI est-il membre de la FFDN ?. Évalué à 3.
Pour réitérer ce qui a été dit au-dessus, FDN faisant parti de la FFDN, toute la France métropolitaine est couverte, même si c'est un peu « tricher » par rapport aux locaux.
[^] # Re: RH ne supporte pas Secure Boot
Posté par benoar . En réponse au journal Canonical embrasse la technologie Microsoft (bootloader). Évalué à 5.
Et demain, pour Windows 9, il te suffira juste de leur signer une lettre de décharge en 3 exemplaires, et tu auras éventuellement le droit d'utiliser ton ordinateur en mode non-« sécurisé ».
C'est exactement le même discours que la mafia qui te dit que tu as la liberté de ne pas payer. Tu sais très bien la puissance de MS, tu es son représentant ici, et te voir pérorer comme ça me fait gerber. Tu ressors les même conneries en boucle. Dégage d'ici, connard.
Et t'inquiètes, je trouve aussi nase la fermeture des Android & co (je n'en ai pas pour cette raison), au cas où tu me le ressortes ; c'est juste que MS et toi vous avez un tel historique qu'on ne peut pas s'empêcher ce genre de réaction. D'ailleurs, je vais m'arrêter ici.
[^] # Re: RH ne supporte pas Secure Boot
Posté par benoar . En réponse au journal Canonical embrasse la technologie Microsoft (bootloader). Évalué à 0.
Oui enfin vous facilitez vachement la tâche à ceux qui veulent se faire signer. Ça s'approche beaucoup de l'incitation, selon moi.
Madame michu n'a jamais été capable d'installer un Linux, alors ça ne change rien cette histoire de Secure Boot à désactiver dans le BIOS. Les personnes capables d'installer/administrer un Linux sauront désactiver le Secure Boot.
Je ne vois pas en quoi la solution de refuser de se faire signer et de demander de désactiver le Secure Boot était plus pourrie et incertaine. Et je trouve ça drôle de dire que d'un côté, le désactiver est « difficile » pour madame michu, et de l'autre que c'est « simple » si on le veut réellement. C'est prendre les gens pour des ignorants en les faisant passer complètement à côté de l'implication qu'a ce switch et ce genre de techno.
Qu'une personne lambda s'en « accommode », OK. Que Red Hat, qui est une entreprise majeure dans le libre, qui se bat contre les brevets logiciels, les violations de la GPL, etc, abdique d'un coup sans autre revendication contre TPM, je trouve ça très dommage, pour ne pas dire plus. Ne se rendent-ils pas compte que c'est faire rentrer le loup dans la bergerie ?
Le fait que Matthew et d'autres fassent passer ça pour quelque chose d'anodin me fait encore plus peur : on parle bien de l'interdiction de modifier ses logiciels ! Franchement, qu'est-ce qu'il faut comme atteinte au Libre pour que Red Hat réagisse ?
[^] # Re: Ce qu'il faut faire
Posté par benoar . En réponse au journal Canonical embrasse la technologie Microsoft (bootloader). Évalué à 2.
C'est une formule pour dire que ça a beau être vrai, le fait que ça soit off par défaut et que ça soit géré à moitié fait que la majorité des gens qui connaissent cette histoire de casse ne te croiront pas si tu leur dit que NTFS le gère quand même.
Mais voilà, avec toi c'est toujours pareil, ton but c'est de faire perdre du temps aux gens en jouant au débile mental, et tu y arrives bien.
[^] # Re: RH ne supporte pas Secure Boot
Posté par benoar . En réponse au journal Canonical embrasse la technologie Microsoft (bootloader). Évalué à 3.
Ha, moi je ne l'avais pas compris comme ça, pardon. Mais alors, dire qu'ils ne « supportent » pas Secure Boot est un peu fort : c'est justement ce qu'ils font en proposant aux gens de se faire signer.
Mais ça n'est pas le problème… Tout bon libriste sait que c'est le choix par défaut qui importe, et que ce genre de mécanisme désactivable ne le sera plus un jour. C'est le premier pas dans la mauvaise direction.
[^] # Re: RH ne supporte pas Secure Boot
Posté par benoar . En réponse au journal Canonical embrasse la technologie Microsoft (bootloader). Évalué à 8.
Homme de paille, toussa. Si tu veux être certifié Windows 8 (ce que feront bien sûr tous les constructeurs), toi dois obligatoirement mettre Windows sur ton ordi, tu nu peux pas le vendre sans. Ça s'appelle la vente liée, au cas où tu ne serais pas au courant.
(au passage, belle confirmation sur mon affirmation plus haut)
Moui… Donc avant c'était évident qu'on devait pouvoir installer ce qu'on veut sur sa machine, maintenant c'est Microsoft, grand seigneur, qui vous fait l'honneur d'avoir le choix d'installer un OS autre que Windows sur les ordinateurs qui contiendront tous sa clé. Merci !
Les systèmes ARM se vendant sans Windows ne pouvant pas fonctionner avec Windows, la certification Windows 8 ils s'en balancent un peu. Concernant la « probabilité » qu'un autre système tourne dessus, j'« aime » bien que MS s'arroge le droit de le décider. Forcément, si Secure Boot n'est pas désactivable, il ne risque pas d'arriver beaucoup de systèmes alternatifs…
Quant au « pas de risque de procès pour violation de monopole », ça montre bien que MS n'en a rien à foutre d'enfermer tout le monde.
Donc, tu confirmes que le but de MS c'est d'enfermer les gens pour qu'ils n'aient pas le choix de leur OS, c'est ça ? Parce que ton pseudo-argument du « choix » (ça n'est pas un argument, car il essaye de se justifier par lui-même) ne vaut rien.
[^] # Re: Ce qu'il faut faire
Posté par benoar . En réponse au journal Canonical embrasse la technologie Microsoft (bootloader). Évalué à 4.
Pourquoi tu veux toujours jouer au con ?
Je n'ai jamais dit que NTFS ne gérait pas la casse, arrête d'imaginer les remarques qui t'arrangent. NTFS saura stocker ton fichier sensible à la casse. Mais une appli lambda ne pourra pas choisir lequel elle ouvre. C'est ce qu'on appelle supporter à moitié, comme on disait plus haut.
[^] # Re: Ce qu'il faut faire
Posté par benoar . En réponse au journal Canonical embrasse la technologie Microsoft (bootloader). Évalué à 3.
Je te rappelais l'importance des choix par défaut un peu plus haut… Tu vois comme c'est emmerdant quand c'est pas dans ton sens ? (parce que tu n'arriveras à convaincre personne que le FS de Windows gère la casse même avec cette option, tellement c'est anecdotique, et qu'en plus je suis sûr que ça casse la moitié du système)
[^] # Re: RH ne supporte pas Secure Boot
Posté par benoar . En réponse au journal Canonical embrasse la technologie Microsoft (bootloader). Évalué à 3.
Oui enfin il existe des ports « spécifiques », avec des kernels qui supportent une plateforme donnée, avec des scripts qui changent le “machine code” (je n'ai plus le nom exact) inclus dans le kernel pour faire plaisir au bootloader de la machine en particulier (c'est fait avec des hooks post-install dans dpkg). Tu peux voir ici un certain nombre de machines gérées pour armel, par exemple, avec en prime l'installeur qui peut se lancer depuis le système original, en général :
http://d-i.debian.org/daily-images/armel/daily/
J'en parle parce que j'ai justement fait le support d'un (avec l'aide de Martin Michlmayr qui bosse beaucoup pour le support ARM dans Debian). Je pense que le nombre de machines supportées mais sans installeur est encore plus grand.
[^] # Re: RH ne supporte pas Secure Boot
Posté par benoar . En réponse au journal Canonical embrasse la technologie Microsoft (bootloader). Évalué à 3.
Merci. La désactivation de Secure Boot sera donc bien présente.
On en voit aussi d'autres pas mal :
La vente liée n'est pas près de s'arrêter…
Oui OK, je vois que tu veux jouer à ça, je t'arrête tout de suite, ça ne m'intéresse pas.
En passant, tu peux me donner la raison de cette différence de traitement entre x86 et ARM ?
[^] # Re: RH ne supporte pas Secure Boot
Posté par benoar . En réponse au journal Canonical embrasse la technologie Microsoft (bootloader). Évalué à 4.
Source ? La seule que je trouve c'est http://www.softwarefreedom.org/blog/2012/jan/12/microsoft-confirms-UEFI-fears-locks-down-ARM/ et qui parle de pouvoir ajouter ses propres clés, ce qui n'est pas tout à fait pareil, même si ça s'en rapproche.
Enfin bon, de toutes manières, tu ne réponds même pas au problème principal, comme tous les supporters de cette techno : tu veux juste à tout prix montrer qu'on « peut » la désactiver, sans même parler de la nocivité de la techno en elle-même. C'est toujours les même méthodes, déplacer le débat. Alors que tu sais très bien la différence que ça fait que ça soit activé par défaut : le « par défaut », MS connaît bien.
En fait, ce truc c'est juste le retour du TPM (puisque c'est exactement un TPM qui est utilisé) encore sous un autre nom, sauf que MS a cette fois-ci bien réussi à « convaincre » tous les constructeurs de mettre sa clé dedans par défaut. Mais on dirait que personne ne s'en rend compte.
[^] # Re: RH ne supporte pas Secure Boot
Posté par benoar . En réponse au journal Canonical embrasse la technologie Microsoft (bootloader). Évalué à 3.
On a toujours le choix. On pourrait aussi bien dire qu'essayer de faire du Logiciel Libre est inutile car de toutes façons Windows est vendu avec toutes les machines. Red Hat, vu sa position, avait tout à fait le pouvoir pour bien faire pencher la balance dans le sens du libre (je ne dis pas qu'ils y seraient arrivés tout seul, mais ils ont un poids certain). Je trouve très dommageable qu'ils aient accepté ce compromis foireux.
On sait très bien que les « peuvent » dans ce cadre là sont très hypothétiques.
Ils pouvaient déjà avant, c'est exactement le rôle de TPM. Ici, on parle de la rendre active par défaut partout, avec la clé de MS, ce qui est très différent. Cette remarque n'apporte donc aucune justification.
Génial.
Et ? Au final, pour que Red Hat garde sa certification, il ne faut pas qu'il accepte avec ce bootloader de booter n'importe quel stage 2, et subséquemment n'importe quel noyau. Sinon, ils vont se faire révoquer leur clé. Bref, indirectement, ça revient à signer également le noyau.
Mais c'est tout aussi pourri, parce que bien sûr Red Hat ne va pas signer n'importe quel stage 2 : seulement ceux qui chargent des noyaux vérifiés. Bref, Red Hat se place en autorité de certification de qui dans le libre aura le droit de booter en mode « sécurisé » !
C'est toujours la même chose dans les mondes fermés : on appâte les premiers en leur donnant du pouvoir sur les suivants. Comme ça, ils craquent plus facilement. Ce qu'a fait Red Hat est vraiment pas classe.
[^] # Re: Je ne comprends pas
Posté par benoar . En réponse à la dépêche Les IDS et les obligations CNIL. Évalué à 5.
Ça serait bien de le signaler dans cette dépêche alors, parce que déjà le ton populiste fait assez moyen, je trouve, en plus.
[^] # Re: Plus léger ?
Posté par benoar . En réponse à la dépêche Sortie de GNU LibreJS 4.7. Évalué à 2.
OK, merci pour ce test. Même si, quand on regarde en détail, il n'est pas super cohérent avec ton autre bench : version compilée « seulement » deux fois moins lourde, contre 8 fois moins précédemment ; versions gzippée qui ne réduit pas beaucoup (c'est du code beaucoup plus « complexe » dans ce bench, peut-être ?) ; grosse différence inexpliquée de la version gzippée compilée. Mais c'est intéressant de voir que la version compilée fait effectivement gagner un certain temps.
Oui, merci.