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\
Le but est de passer en paramètre une variable qui serait globale autrement. Alors j'entends des voix dans le fond de la salle, notamment le mot « singleton », mais c'est une fausse bonne idée et n'est qu'une classe unique cachant une variable à portée globale.
Et c'est quoi ton problème avec les variables globales ? Si c'est un paramètre qui doit être utilisé partout, une variable globale est tout à fait indiquée. Si c'est un paramètre spécifique à une « chose » particulière, qui sera réutilisée pour cette « chose », et bien… fait de l'objet ! Ça sert à ça…
Et sache que singleton n'est pas une formule magique qui résout tous les problèmes. (j'ai l'impression des fois que les designs patterns ça fait plus de mal que de bien)
Je dirais qu'il y a un malentendu à cause du (mauvais) titre de l'article de patrick_g : ce dernier parle effectivement de mémoire flash dans son article, et pas vraiment de SSD. Par contre, les posts de Sylvain et de Yao parlent effectivement de SSD.
En ce qui concerne les FS orientés SSD, certains parlent du fait qu'on n'a plus besoin de scheduler, mais ça n'est pas la seule différence : l'option ssd (voire ssd_spread) de btrfs change la manière dont le FS alloue les blocs. Je pense qu'aujourd'hui, même s'il manque encore un peu de maturité, btrfs est le meilleur FS pour SSD. L'histoire de :
Note that -o ssd will not enable TRIM/discard.
c'est juste pour dire que ça n'implique pas l'activation tu TRIM, mais btrfs sait bien sûr l'activer quand un SSD est utilisé.
Je ne connais pas de périphérique grand public qui offre un accès à la mémoire flash directement, ce qui est sans doute la raison pour laquelle on entend peu parler de ces FS.
Les interfaces mtd telles qu'utilisées par le kernel actuellement ne sont de toutes façons pas faites pour le grand public. L'accès direct à la Flash se démocratisera plus quand on verra des périphériques NVM Express arriver.
Très sympa comme mémento, merci. Je ne me suis pas encore complètement mis aux spécificités de la version 3, donc ça peut être très utile.
Quelques petites remarques :
J'aurais plutôt utilisé enumerate() pour le parcours de liste avec index ; je vois qu'il est quand même mentionné juste à côté, donc c'est juste un détail
La section sur le formatage des chaînes pourrait peut-être avoir des exemples un peu plus « complexes », plutôt que simplement des explications des différentes options ? (je trouve les précédents exemples bien pratiques)
La différenciation (nouvelle) de str et bytes n'est pas abordée : c'est pour éviter de mettre trop de choses dans ce mémento ?
si un attaquant arrive à deviner le protocole d'authentification utilisé par le serveur, il peut se faire passer pour n'importe qui
Je ne vois pas trop le rapport entre « se faire passer pour n'importe qui » et arriver à ouvrir une connexion TCP en devinant le bon numéro de séquence.
De plus il peut également inonder de paquets ACK le serveur pour tenter de créer une connexion.
Ça ne fera pas plus de mal qu'un syn-flood avec syn-cookie niveau charge, et après, pour arriver à ouvrir une connexion, c'est pareil que d'arriver à deviner les numéros de séquence de manière « classique » : c'est considéré comme assez difficile.
Et enfin, un serveur utilisant des syncookies ne pourra pas effectuer un filtrage de paquets ACK, ce qui peut permettre éventuellement à un attaquant de passer à travers un pare-feu qui filtre les paquets SYN de demande de connexion.
Ça c'est simplement faux.
Bref, c'est un peu n'importe quoi cet article. Et de toutes façons il me semble que les syn-cookies sont activés par défaut depuis un bout de temps.
Je croyais qu'il avait récemment était augmenté à 90 ans et de manière rétroactive bien sûr.
Je ne crois pas. En tout cas ce n'est pas ce que dit Wikipédia.
Bah c'est étrange mais moi aussi je croyais avoir vu passer au parlement européen, il y a moins de 6 mois, dans un beau silence des grands médias, une extension à 90 ans. Mais je fais des recherches et je ne trouve quasiment rien là-dessus. Vu qu'on est deux, je ne pense pas complètement avoir rêvé, mais quelqu'un d'autre pourrait-il confirmer/infirmer ?
Pour FDN, c'est dégroupage partiel uniquement, effectivement. Par contre on a eu un retour de quelqu'un qui a pris une ligne fixe SFR « normale » (je ne savais même pas qu'ils vendaient ça) et qui a pu prendre un abonnement FDN dessus sans problème. Et on couvre bien sûr toute la France.
En ce qui concerne la couverture, de toutes façons, tu n'auras pas vraiment de différence que tu sois chez FDN, OVH, ou SFR : les deux premiers utilisent en gros le réseau du troisième… Ya Orange qui couvre parfois un peu « mieux », mais aucun « alternatif » n'aura de meilleure couverture en ADSL que SFR ou Orange.
Dictionnaire! Le translateur ne dépend pas du protocole, il a un dictionnaire qui l'alimente.
Traduction, dictionnaire, fourni avec… oui, tu viens bien de réinventer la compression style gzip ou autre. Sauf qu'en plus, les algorithmes de compression « standard » sont généralistes.
Après, je vais être gentil, j'ai découvert récemment que les mecs qui font vraiment attention au moindre bit, dans le domaine des microcontrôleurs, ont adapté du HTTP version très simple et « compressée », ça s'appelle CoAP (Constrained Application Protocol) http://tools.ietf.org/html/draft-ietf-core-coap-09
C'est mieux que tes longues sessions ssh… Tu peux récupérer ta session de partout au lieu de juste ton laptop avec lequel tu es partis.
Effectivement, c'est un avantage de screen/tmux. Mais personnellement, je n'ai, dans mon cas, qu'une machine, que j'utilise tout le temps. J'ai rarement besoin de ce cas d'usage. Comme quoi, on a tous des usages différents.
[^] # 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\[^] # Re: Le global c'est bien pour du global
Posté par benoar . En réponse au message Argument de fonction récurrent. Évalué à 3.
On aura bien sûr corrigé l'appel à
function1qui devait bien sûr s'écrireself.function1.[^] # Re: wrapper et decorateur
Posté par benoar . En réponse au message Argument de fonction récurrent. Évalué à 5.
Ha, je me demandais si j'étais le seul à trouver ça illisible…
# Le global c'est bien pour du global
Posté par benoar . En réponse au message Argument de fonction récurrent. Évalué à 7. Dernière modification le 01 juin 2012 à 18:23.
Et c'est quoi ton problème avec les variables globales ? Si c'est un paramètre qui doit être utilisé partout, une variable globale est tout à fait indiquée. Si c'est un paramètre spécifique à une « chose » particulière, qui sera réutilisée pour cette « chose », et bien… fait de l'objet ! Ça sert à ça…
Et sache que singleton n'est pas une formule magique qui résout tous les problèmes. (j'ai l'impression des fois que les designs patterns ça fait plus de mal que de bien)
[^] # Re: btrfs et ext4 en plus ?
Posté par benoar . En réponse au message "Technologie : Les systèmes de fichiers pour disques SSD" suite ?. Évalué à 2.
Je dirais qu'il y a un malentendu à cause du (mauvais) titre de l'article de patrick_g : ce dernier parle effectivement de mémoire flash dans son article, et pas vraiment de SSD. Par contre, les posts de Sylvain et de Yao parlent effectivement de SSD.
En ce qui concerne les FS orientés SSD, certains parlent du fait qu'on n'a plus besoin de scheduler, mais ça n'est pas la seule différence : l'option
ssd(voiressd_spread) de btrfs change la manière dont le FS alloue les blocs. Je pense qu'aujourd'hui, même s'il manque encore un peu de maturité, btrfs est le meilleur FS pour SSD. L'histoire de :c'est juste pour dire que ça n'implique pas l'activation tu TRIM, mais btrfs sait bien sûr l'activer quand un SSD est utilisé.
Les interfaces
mtdtelles qu'utilisées par le kernel actuellement ne sont de toutes façons pas faites pour le grand public. L'accès direct à la Flash se démocratisera plus quand on verra des périphériques NVM Express arriver.# Sympa
Posté par benoar . En réponse au message Un mémento Python. Évalué à 2.
Très sympa comme mémento, merci. Je ne me suis pas encore complètement mis aux spécificités de la version 3, donc ça peut être très utile.
Quelques petites remarques :
enumerate()pour le parcours de liste avec index ; je vois qu'il est quand même mentionné juste à côté, donc c'est juste un détailstretbytesn'est pas abordée : c'est pour éviter de mettre trop de choses dans ce mémento ?[^] # Re: Syn cookie
Posté par benoar . En réponse au message Protection attaque SYN flood. Évalué à 2.
Je ne vois pas trop le rapport entre « se faire passer pour n'importe qui » et arriver à ouvrir une connexion TCP en devinant le bon numéro de séquence.
Ça ne fera pas plus de mal qu'un syn-flood avec syn-cookie niveau charge, et après, pour arriver à ouvrir une connexion, c'est pareil que d'arriver à deviner les numéros de séquence de manière « classique » : c'est considéré comme assez difficile.
Ça c'est simplement faux.
Bref, c'est un peu n'importe quoi cet article. Et de toutes façons il me semble que les syn-cookies sont activés par défaut depuis un bout de temps.
[^] # Re: 90 ans
Posté par benoar . En réponse à la dépêche Les Variations Goldberg dans le domaine public. Évalué à 2.
Bon, j'ai trouvé ça http://entertainment.slashdot.org/story/11/09/12/1534213/eu-extends-music-copyright-to-70-years qui dit que c'est passé de 50 à 70 ans récemment en fait, mais Wikipédia parle de 70 ans depuis 1993… Je ne comprends pas trop. Par contre http://en.wikipedia.org/wiki/European_Union_95_year_recording_copyright_extension_proposal explique peut-être ma confusion avec 90 ans.
[^] # Re: 90 ans
Posté par benoar . En réponse à la dépêche Les Variations Goldberg dans le domaine public. Évalué à 2.
Bah c'est étrange mais moi aussi je croyais avoir vu passer au parlement européen, il y a moins de 6 mois, dans un beau silence des grands médias, une extension à 90 ans. Mais je fais des recherches et je ne trouve quasiment rien là-dessus. Vu qu'on est deux, je ne pense pas complètement avoir rêvé, mais quelqu'un d'autre pourrait-il confirmer/infirmer ?
# Pour FDN
Posté par benoar . En réponse au message Retours d'expérience sur offres single play. Évalué à 2.
Pour FDN, c'est dégroupage partiel uniquement, effectivement. Par contre on a eu un retour de quelqu'un qui a pris une ligne fixe SFR « normale » (je ne savais même pas qu'ils vendaient ça) et qui a pu prendre un abonnement FDN dessus sans problème. Et on couvre bien sûr toute la France.
En ce qui concerne la couverture, de toutes façons, tu n'auras pas vraiment de différence que tu sois chez FDN, OVH, ou SFR : les deux premiers utilisent en gros le réseau du troisième… Ya Orange qui couvre parfois un peu « mieux », mais aucun « alternatif » n'aura de meilleure couverture en ADSL que SFR ou Orange.
[^] # Re: Entêtes binaires???
Posté par benoar . En réponse à la dépêche En route pour HTTP/2.0. Évalué à 6.
Traduction, dictionnaire, fourni avec… oui, tu viens bien de réinventer la compression style gzip ou autre. Sauf qu'en plus, les algorithmes de compression « standard » sont généralistes.
Après, je vais être gentil, j'ai découvert récemment que les mecs qui font vraiment attention au moindre bit, dans le domaine des microcontrôleurs, ont adapté du HTTP version très simple et « compressée », ça s'appelle CoAP (Constrained Application Protocol) http://tools.ietf.org/html/draft-ietf-core-coap-09
[^] # Re: Screen
Posté par benoar . En réponse au journal Le TCP keepalive m'a tué. Évalué à 1.
https://linuxfr.org/nodes/94082/comments/1349431
https://linuxfr.org/nodes/94082/comments/1349403
Effectivement, c'est un avantage de screen/tmux. Mais personnellement, je n'ai, dans mon cas, qu'une machine, que j'utilise tout le temps. J'ai rarement besoin de ce cas d'usage. Comme quoi, on a tous des usages différents.