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.
Quoiqu'on pourra en dire, c'est toujours un pas de plus dans la bonne direction.
Donner accès à l'IPv6, c'est bien. Le faire bien, c'est mieux.
En fait, avec ton /96, tu ne vas pas pouvoir faire grand chose de plus qu'avec un /127, par exemple. Car à moins que tu héberges des tonnes de machines (virtuelles) que tu adresse manuellement dessus, aucun des mécanismes d'autoconfiguration prévus par ceux qui ont conçu IPv6 ne fonctionnera avec un /96. Pareil pour le routage : à moins de bidouiller à la main, ça ne fonctionnera pas. Tu ne pourras pas monter de VPN derrière, par exemple. C'est un cas typique de personnes qui ont voulu mettre en place IPv6 mais qui n'ont pas compris comment ça marche, c'est dommage.
Car quand on regarde combien ils ont de place… Ikoula a un /32. Imaginons qu'ils aient 10 millions de clients (ce qui me semble assez peu réalistes, mais passons) : ils pourraient donner un /56 par client ! Et se garder plusieurs /48 pour eux, pour leur infra. Et s'ils avaient réellement autant de clients, je suis sur que le RIPE leur donnerait un préfixe plus large (un /32 est le minimum attribué à un fournisseur de services IPv6). Bref, ils font comme Zenitram, ils veulent être plus intelligents qui ceux qui ont conçu IPv6, mais du coup ils se trompent. C'est dommage.
Bref, j'espère que tu pourras avoir mieux dans le futur ! (mais déjà, vu qu'il faudra sûrement renuméroter, ils vont hésiter avant de changer de méthode…)
Très bien, j'apprécie que tu prennes le temps de citer un exemple réel.
91 fichiers javascript […] onload : 2.86s
Effectivement, c'est lent.
Par contre :
version compilée […] onload : 1.17s
C'est mieux, mais comme tu dis, il y a un facteur 46 en taille avec le test précédent, et pourtant le temps de chargement n'est pas diminué du tout du même ordre de grandeur. De plus, comme tu précises, tu es en local, donc tu dois avoir de bons débits. J'en conclue donc que de toutes façons, la taille n'a rien changé, c'est juste de concaténer qui a aidé.
Effectivement, la concaténation peut être une optimisation très intéressante ; mais ça n'est pas ce dont je parlais : moi, j'aurais bien aimé voir le résultat du temps de chargement avec la version « simplement concaténée et gzipée ». Je suppose que tu ne gagnes presque rien entre ta version compilée et celle-ci. Si tu pouvais faire le test, ça pourrait être intéressant, même si c'est encore te demander un peu de temps.
Pour Javascript, dans pratiquement 100% des cas, c'est fait pour des questions de performances.
Sources ?
Minifier le JS, ça sert juste à raccourcir un peu le temps de chargement. Mais en fait, ça ne change quasiment rien si on le gzip, ou si on gère bien son cache (vu que tout le monde utilise les même libs, il n'y a qu'à faire pointer au bon endroit pour n'avoir à le charger qu'une fois pour tous les sites webs qui l'utilisent !)
Je dirais que l'argument de la performance est fallacieux car même si ça joue un tout petit peu, le bénéfice de l'obfuscation dans le sens de rendre la compréhension du code difficile est très apprécié par beaucoup de ses partisans.
Juste en passant, je ne demandais même pas un réencodage (même si c'est cool !) mais juste l'URL, mais je ne sais pas si c'est possible avec ce genre de service de vidéo.
En effet, dans Firefox (ou dérivé), il y a probablement du code dont la licence (libre), n'est pas compatible avec la GPL.
Perso, c'est ce genre d'amalgame que je trouve très dommageable pour le libre. Si, le code de Firefox (et de Iceweasel, à fortiori, si tu veux que le nom soit libre aussi) respecte les 4 libertés. En faisant ce genre d'amalgame, tu participes à l'affaiblissement du libre en disant qu'il n'est pas très important de faire la différence avec du propriétaire/privateur.
Attention d'ailleurs, ces personnes là vont probablement avoir une crise cardiaque, quand ils apprendront que le matériel sur lequel tourne leurs softs libre, n'est pas libre, que leur bios n'est pas libre etc…
Amalgame, encore.
Bref, faut parfois arrêter les conneries, et avoir un minimum de pragmatisme.
Ça veut dire quoi exactement dans ce cas ? Il existe du code libre, et du code non-libre. Cette extension permet de faire la différence. Effectivement, je pense qu'en pratique, ça n'est pas super évident de naviguer avec, mais elle a au moins le mérite de nous faire réaliser à quel point on abandonne assez rapidement ses idéaux sur le web.
Bon je revient à la charge avec une solution plus propre qui devrait plaire à pas mal de monde (enfin j'espère)
Mmhh, je pense que tu n'as pas saisi le problème que nous voyons. Je pense que nous n'avons pas les même objectifs : toi, tu veux absolument faire la chose dont Jiehong parle en respectant strictement ses contraintes, quelques soient les circonvolutions à faire en python. Moi et BFG (d'après ce que je comprends) essayons de trouver un compromis qui résolve son problème et soit lisible par un programmeur « normal », réutilisable, et respecte quelques « bonnes pratiques » de programmation.
Perso, je continue à trouver ton code très illisible. C'est marrant d'étirer le langage dans tous les sens, mais je n'écrirais jamais ce genre de chose pour quelqu'un d'autre. Après, pour s'amuser, pourquoi pas, mais en tous cas je n'espère jamais tomber sur ce genre de code pour le reprendre/relire.
J'espère que tu ne le prends pas mal (j'ai vaguement eu cette impression dans tes commentaires précédents), je pense que c'est juste que nous avons des buts différents. Mais j'aime bien essayer en général de « bien » faire les choses et de montrer des bouts de code qui me semblent plutôt facilement réutilisables, que d'aller chercher à tout prix les possibilités les plus tordues d'un langage.
Pas tout à fait. Par exemple, dans les langages déficients comme Java où on ne peut pas mettre de « vraies » variables globales en dehors des classes, on peut quand même en mettre dedans. Et pourtant, l'utilisation d'un singleton est préconisée. J'ai souvenir que ça venait d'une histoire de précaution vis à vis de la concurrence à l'initialisation, mais je peux me tromper.
Oui, merci ;-) Mais en même temps, je viens de me rendre compte que j'ai oublié les self aussi dans les définitions des méthodes… bref, les erreurs habituelles que je fais, et qui apparaissent quand on ne teste pas le code qu'on écrit /o\
# 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.
[^] # Re: Participe qui veut...
Posté par benoar . En réponse à la dépêche 6 juin 2012 : « World IPv6 launch ». Évalué à 3.
Donner accès à l'IPv6, c'est bien. Le faire bien, c'est mieux.
En fait, avec ton /96, tu ne vas pas pouvoir faire grand chose de plus qu'avec un /127, par exemple. Car à moins que tu héberges des tonnes de machines (virtuelles) que tu adresse manuellement dessus, aucun des mécanismes d'autoconfiguration prévus par ceux qui ont conçu IPv6 ne fonctionnera avec un /96. Pareil pour le routage : à moins de bidouiller à la main, ça ne fonctionnera pas. Tu ne pourras pas monter de VPN derrière, par exemple. C'est un cas typique de personnes qui ont voulu mettre en place IPv6 mais qui n'ont pas compris comment ça marche, c'est dommage.
Car quand on regarde combien ils ont de place… Ikoula a un /32. Imaginons qu'ils aient 10 millions de clients (ce qui me semble assez peu réalistes, mais passons) : ils pourraient donner un /56 par client ! Et se garder plusieurs /48 pour eux, pour leur infra. Et s'ils avaient réellement autant de clients, je suis sur que le RIPE leur donnerait un préfixe plus large (un /32 est le minimum attribué à un fournisseur de services IPv6). Bref, ils font comme Zenitram, ils veulent être plus intelligents qui ceux qui ont conçu IPv6, mais du coup ils se trompent. C'est dommage.
Bref, j'espère que tu pourras avoir mieux dans le futur ! (mais déjà, vu qu'il faudra sûrement renuméroter, ils vont hésiter avant de changer de méthode…)
[^] # Re: Plus léger ?
Posté par benoar . En réponse à la dépêche Sortie de GNU LibreJS 4.7. Évalué à 5.
Très bien, j'apprécie que tu prennes le temps de citer un exemple réel.
Effectivement, c'est lent.
Par contre :
C'est mieux, mais comme tu dis, il y a un facteur 46 en taille avec le test précédent, et pourtant le temps de chargement n'est pas diminué du tout du même ordre de grandeur. De plus, comme tu précises, tu es en local, donc tu dois avoir de bons débits. J'en conclue donc que de toutes façons, la taille n'a rien changé, c'est juste de concaténer qui a aidé.
Effectivement, la concaténation peut être une optimisation très intéressante ; mais ça n'est pas ce dont je parlais : moi, j'aurais bien aimé voir le résultat du temps de chargement avec la version « simplement concaténée et gzipée ». Je suppose que tu ne gagnes presque rien entre ta version compilée et celle-ci. Si tu pouvais faire le test, ça pourrait être intéressant, même si c'est encore te demander un peu de temps.
[^] # Re: Plus léger ?
Posté par benoar . En réponse à la dépêche Sortie de GNU LibreJS 4.7. Évalué à 2.
Sources ?
Minifier le JS, ça sert juste à raccourcir un peu le temps de chargement. Mais en fait, ça ne change quasiment rien si on le gzip, ou si on gère bien son cache (vu que tout le monde utilise les même libs, il n'y a qu'à faire pointer au bon endroit pour n'avoir à le charger qu'une fois pour tous les sites webs qui l'utilisent !)
Je dirais que l'argument de la performance est fallacieux car même si ça joue un tout petit peu, le bénéfice de l'obfuscation dans le sens de rendre la compréhension du code difficile est très apprécié par beaucoup de ses partisans.
[^] # Re: Vidéo lisible ?
Posté par benoar . En réponse au journal Une petite démo en vidéo du terminal Qy.Net dont on parle en ce moment.. Évalué à 2.
Merci beaucoup. Ça a l'air sympa en effet.
Juste en passant, je ne demandais même pas un réencodage (même si c'est cool !) mais juste l'URL, mais je ne sais pas si c'est possible avec ce genre de service de vidéo.
[^] # Re: Plus léger ?
Posté par benoar . En réponse à la dépêche Sortie de GNU LibreJS 4.7. Évalué à 10.
Perso, c'est ce genre d'amalgame que je trouve très dommageable pour le libre. Si, le code de Firefox (et de Iceweasel, à fortiori, si tu veux que le nom soit libre aussi) respecte les 4 libertés. En faisant ce genre d'amalgame, tu participes à l'affaiblissement du libre en disant qu'il n'est pas très important de faire la différence avec du propriétaire/privateur.
Amalgame, encore.
Ça veut dire quoi exactement dans ce cas ? Il existe du code libre, et du code non-libre. Cette extension permet de faire la différence. Effectivement, je pense qu'en pratique, ça n'est pas super évident de naviguer avec, mais elle a au moins le mérite de nous faire réaliser à quel point on abandonne assez rapidement ses idéaux sur le web.
# Vidéo lisible ?
Posté par benoar . En réponse au journal Une petite démo en vidéo du terminal Qy.Net dont on parle en ce moment.. Évalué à 2.
C'est pas /vraiment/ pour faire mon reulou, mais tu aurais un lien direct vers la vidéo ? Parce que la le blip.tv par ici ça marche pas du tout.
[^] # Re: wrapper et decorateur
Posté par benoar . En réponse au message Argument de fonction récurrent. Évalué à 3.
Mmhh, je pense que tu n'as pas saisi le problème que nous voyons. Je pense que nous n'avons pas les même objectifs : toi, tu veux absolument faire la chose dont Jiehong parle en respectant strictement ses contraintes, quelques soient les circonvolutions à faire en python. Moi et BFG (d'après ce que je comprends) essayons de trouver un compromis qui résolve son problème et soit lisible par un programmeur « normal », réutilisable, et respecte quelques « bonnes pratiques » de programmation.
Perso, je continue à trouver ton code très illisible. C'est marrant d'étirer le langage dans tous les sens, mais je n'écrirais jamais ce genre de chose pour quelqu'un d'autre. Après, pour s'amuser, pourquoi pas, mais en tous cas je n'espère jamais tomber sur ce genre de code pour le reprendre/relire.
J'espère que tu ne le prends pas mal (j'ai vaguement eu cette impression dans tes commentaires précédents), je pense que c'est juste que nous avons des buts différents. Mais j'aime bien essayer en général de « bien » faire les choses et de montrer des bouts de code qui me semblent plutôt facilement réutilisables, que d'aller chercher à tout prix les possibilités les plus tordues d'un langage.
[^] # Re: Sympa
Posté par benoar . En réponse au message Un mémento Python. Évalué à 2.
Effectivement, j'avais peut-être mal cerné le public. Bon boulot !
[^] # Re: Le global c'est bien pour du global
Posté par benoar . En réponse au message Argument de fonction récurrent. Évalué à 2.
Pas tout à fait. Par exemple, dans les langages déficients comme Java où on ne peut pas mettre de « vraies » variables globales en dehors des classes, on peut quand même en mettre dedans. Et pourtant, l'utilisation d'un singleton est préconisée. J'ai souvenir que ça venait d'une histoire de précaution vis à vis de la concurrence à l'initialisation, mais je peux me tromper.
[^] # Re: Le global c'est bien pour du global
Posté par benoar . En réponse au message Argument de fonction récurrent. Évalué à 2.
Oui, merci ;-) Mais en même temps, je viens de me rendre compte que j'ai oublié les
selfaussi dans les définitions des méthodes… bref, les erreurs habituelles que je fais, et qui apparaissent quand on ne teste pas le code qu'on écrit /o\