benoar a écrit 4237 commentaires

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.

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.

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.

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.

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.

Effectivement, j'avais peut-être mal cerné le public. Bon boulot !

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\

On aura bien sûr corrigé l'appel à function1 qui devait bien sûr s'écrire self.function1.

Ha, je me demandais si j'étais le seul à trouver ça illisible…

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…

    class Recurrent(object):
        def __init__(self, arg_r):
            self.arg_r = arg_r
        def function1(self, arg1, arg2):
            print(self.arg_r)
            # …
        def function2(self, arg1, arg2):
            self.function1(arg1, arg2)

    chose = Recurrent(42)
    chose.function2(1, 2)

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.

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.

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

Tu peux pointer le commentaire ? En quoi ça te convient pas ?

https://linuxfr.org/nodes/94082/comments/1349431
https://linuxfr.org/nodes/94082/comments/1349403

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.

Ce qu'il dit c'est qu'un mec qui abuse volontairement tu lui shoots tout voir tu lui bloque l'accès. Un mec qui à un truc qui déconne, tu lui buttes son processus, tu le préviens et tu reviens à la solution 1 si ça recommence trop souvent.

Effectivement.

Si SSH te laisse traîner des shells, tu peux pas vraiment blâmer les utilisateurs. Tu te rappels pas forcément qu'une cnx à déconnée et ils ont pas que ça a faire que de tout vérifier.

Effectivement, c'est reulou à faire à la main. On pourrait imaginer un keepalive à une semaine, ça pourrait être raisonnable et nettoyer automatiquement les sessions « fantômes ».

C'est un peu comme imaginer que le système puisse ne pas nettoyer la mémoire quand un process crash et qu'on doivent le faire à la main.

Oui, sur des systèmes de grande envergure, il faut trouver un système automatique. L'avantage avec les processus, c'est qu'on peut détecter quand ils crashent, et il y a l'oom-killer en cas de dérapage. Pour les sockets tcp, une période d'inactivité d'une semaine me semble pas mal.

Donc : fait des benchs, dans diverses situations, et va le dire aux mainteneurs, ce sera plus utile que de pleurer sur LinuxFr.

Ça serait bien effectivement de « faire des benchs », mais ça n'est pas évident de tester une situation qui est un ensemble de facteurs très divers (qualité du réseau, gestion des serveurs, comportement des utilisateurs,…). Mais une étude sur une sorte d'échantillon pourrait être sympa.

En attendant, ça a été choisi pas pour rien.

Bah justement, je me demande. En regardant le CVS d'OpenSSH, je vois que cette option est active par défaut depuis le début (premier commit de Théo). Ça se trouve, personne ne s'est vraiment posé la question. Et personne ne l'a vraiment testé en conditions réelles, dans les personnes que je connais.

A partir du moment où tu racontes des conneries sur les utilisateurs (tu crois qu'ils vont bien se comporter parce que tu le demandes?),

Ah oui, c'est vrai, tous les utilisateurs sont des cons, j'avais oublié.

forcément on ne peut que rire à ton "ça ne va pas tuer sa machine" qui n'a aucune crédibilité avec la phrase qui démontre que tu crois toujours que les bisounours existent.

Bah riez si vous voulez, mais c'est clair que c'est pas avec des réactions comme ça qu'on essayera d'améliorer notre environnement de travail.

ce qu'on comprends pas c'est l'intérêt d'un screen sur une machine proxy qui garde up une connexion ssh du proxy vers le serveur au lieu d'un screen directement sur le serveur… donc du coup argumenter pour dire non pas screen car j'ai pas de machine qui peut me servir de proxy est ridicule.

Je n'utilise pas cet argument pour dire pas screen, c'est encore une incompréhension. J'ai trouvé cette solution non idéale, point, ce thread parlait de ça uniquement.

Utilises screen sur le serveur directement et yabasta problème résolu

En ce qui concerne cette utilisation, j'ai déjà répondu plus haut que ça n'était pas une utilisation optimale pour moi.

oui dans le meilleur des mondes, ta connexion ne couperait pas… mais ici c'est pas le meilleur des mondes, c'est le vrai monde et dans le vrai monde, y a screen et c'est caisse.

Le but de ce journal est justement de discuter de comment faire pour y tendre, vers ce monde meilleur. Car je pense que cette option de keepalive n'est pas si bonne qu'elle en a l'air.

J'espère que c'est plus clair.

je sais bien mais au moins je n'ai pas à trier parmi les connexions tcp ouvertes par tous les comptes.

Je ne suis pas sûr d'avoir bien compris ta réponse, mais je parlais justement du fais que le kill était également la solution au cas où tu te retrouves avec des sessions tcp en grand nombres qui te bouffent des ressources, puisque c'est l'inconvénient qu'on essayait de mitiger dans le cas où on n'active pas le keepalive. L'abus de connexions tcp se corrige donc de la même manière que l'abus de ressources CPU/mémoire, et se traite aussi facilement ! C'est pas beau, ça ?

Donc, je ne vois pas en quoi désactiver le keepalive poserait plus de problèmes dans la gestion des cas de congestion que l'abus « classique » d'autres types de ressources. C'est là où je voulais en venir.

2H comme spécifié par la RFC.

Ah, pardon, merci de l'info. J'avais l'impression que c'était plus court, et j'avais 300s dans la tête pour je ne sais quelle raison. Mais ça le fait effectivement en général pour des temps d'absence assez longs.

Oui. Des laptops qui freezent, j'en vois 4x par jour. Sans compter les autres problèmes.

Et qui freezent avec des connexions ssh ouvertes ? C'est du windows, ou pas ? Ça mettrait tant de sessions fantômes que ça qu'un keepalive à une semaine ne serait pas assez ?

Fréquence aléatoire. Ca peut arriver très fréquemment quand tu as un switch qui déconne, une carte réseau defectueuse etc.

Et ça te coupe des sessions tcp si souvent que ça ? C'est des switchs qui font firewall statefull ? La carte réseau défectueuse ça arrive vraiment très fréquemment ? Comme j'ai déjà dit, je n'ai pas travaillé dans de très gros environnements, mais que ce problème ce conjugue avec des sessions ssh qui passaient par là à ce moment, de manière assez récurrente, ça me paraît tellement pas assez probable pour que ça soit un problème d'envergure. Mais je dois peut-être me tromper.

Quand ca arrive ca peut donner 12 heures de coupure sur Amazon S3 à cause d'un bit flip dans un gossip protocol…

C'est quoi cette histoire ?

Je pense que tu as deux problèmes. Tu considères que les cas d'erreurs sont suffisamment rare pour être ignorés, ne sont pas graves et que les utilisateurs préfèrent réparer les erreurs.

Effectivement, je considère, peut-être à tort, qu'ils sont assez rares pour être ignorés. Que ça soit aux utilisateurs de le réparer, on peut envisager de mettre une sort de keepalive à une semaine (je ne sais pas si c'est réaliste avec un mécanisme de keepalive ; peut-être envisager un système de nettoyage de socket inactives pendant une semaine) afin d'automatiser ça. Mais responsabiliser les utilisateurs, c'est déjà pas mal : tu leurs dis déjà de fermer leur session web correctement, pourquoi pas la même chose avec ssh ? (remarquons au passage que c'est le même problème : ça fait chier les utilisateurs qui ont des sessions http qu'ils veulent faire durer longtemps, quand un site te déco après X minutes d'inactivité)

Et d'autre part tu sembles supposer que les choix fait par TCP sont applicables aux couches du dessus.

Bah, ssh est quand même pour moi vachement lié à tcp, je pense que c'est normal qu'il « subisse » ses choix.

TCP n'offre que le sous ensemble commun nécéssaire à tout les protocoles de couche supérieur. Le keep-alive est vraiment un truc litigieux, qui est d'ailleurs dans une RFC annexe. Ca a été inclus car détecter les pannes est un besoin très courant mais le faire au niveau TCP est assez moisi.

Effectivement. Mais même niveau au-dessus, je ne suis pas fan.

Merci pour ce commentaire constructif en tous cas.

Non pas moi, jamais. Relis tout le journal, 10 fois s'il le faut… Et puis reviens t'excuser ensuite.

Alors, je n'avais effectivement pas vu ce comportement de ta part jusqu'à ce message (« me les briser ») qui m'a passablement énervé, vu le ton, alors j'ai utilisé le « on » sans discerner ; excuse-moi pour ça. Mais…

Pardon ? Tu veux faire un concours de mauvaise foi ou quoi ? On te dis que t'as pas besoin de machine dédiée pour utiliser screen contrairement à ce que tu as écris et tu nous dis qu'on est à coté de la plaque ? Dis t'as bien pris tes pilules ou quoi ?

Je ne sais pas combien de fois il faut que tu relises le message de Michaël, à l'origine de ma réponse, pour que tu comprennes. Que tu insistes sans chercher à comprendre me fait dire que tu as une idée toute faite sur mon cas et que ça ne sert à rien de continuer.

Je n'ai ABSOLUMENT pas vu la moindre critique constructive venant de ta part dans ce journal.

Ah bah forcément, on ne doit vraiment pas se comprendre alors.