> Pourtant je t'assure que ce matin, ça m'a posé pas mal de problèmes, et je sens que ça va arriver de plus en plus.
Non ce qui a posé problème ce matin c'est que tu as des compétences sur des outils de 20 ans d'age mais que tu n'as pas mis à jour tes compétences sur des technos récentes.
Non le fonctionnement des Unix ni simple ni naturel alors que tout les outils récents sont merdiques et mal concu. Tout au mieux il est logique; et on a juste appris à s'en servir et s'imprégner de leur logique et de leurs limitations avec le temps. Alors t'as deux solutions, te former sur les technos que tu veux utiliser ou utiliser des produits qui n'offrent que des technos sur lesquels tu as des compétences.
> Ce n'est pas tant NM qui m'énerve que son incompatibilité avec tout ce qui s'est fait jusqu'alors, et qui ne marchait pas si mal que ça.
Oui avant NM c'était très facile et pratique de se connecter à un réseau wifi recontré dans la rue, puis de basculer sur du RJ45 et enfin je rejoindre un vpn en tant que simple utilisateur d'un laptop. Tu as raison.
> Donc, les opérateurs téléphone d'hier étant les opérateurs Internet d'aujourd'hui, et la culture d'entreprise étant ce qu'elle est, il n'y a pas de raison que les procédures soient devenues plus compliquées...
Ca n'a rien à voir avec la culture d'entreprise, c'est juste une obligation légale pour tout les opérateurs (téléphoniques et autres).
Cf code de télécommunication (pour le chiffrement) et loi 91-646 (pour les écoutes)
> Combien de routeur/modem adsl n'ont pas été mis à jour depuis plusieurs années ?
TCP c'est de bout en bout (donc les routeurs non patchés...) et il faut une large fenêtre TCP ce qui n'est pas le cas courant. Je te dis pas que c'est impossible. Je te dis "Spoof moi une connexion sur un Windows ou un OS X dans des conditions normales"
Évidement qu'UDP n'en a pas. Mais tu crois vraiment qu'un protocole bittorrent basé sur UDP n'en intégrerait pas un ? Tu peux regarder les réseaux s'écrouler dans la journée.
> Le but n'est pas de faire fermer la connection de quelqu'un mais de noyer dans la masse de faux positifs et rendre la détection statistiquement impossible.
Alors il faudra de changer de méthode de détection ! En attendant avant de déclarer celle là obsolète, faut que quelqu'un réussisse à mettre en oeuvre celle que tu décris. Et que ca soit suffisament reproductible pour "noyer".
Tu n'arrêtes pas de dire que c'est facile. Je t'encourage donc à le mettre en pratique sur un des protocoles de P2P courant (si c'est utilisé par 3 clampins, ca rentre pas dans le but d'HADOPI). Rien n'est infaisable par contre tout à un coup. bt aussi bien que emule, utilisent des sessions TCP, avec handshake au niveau 7 puis échange de données. Ca n'a rien de trivial, et si quelqu'un y arrive avec des moyens raisonables (style j'ai la main sur les routeurs de level3) ca relève de l'exploit.
C'est beau vos rêve de super méchant, qui va prendre la main sur un subnet ADSL pour faire fermer la connexion ADSL de quelqu'un pendant 3 mois à un an. Wha ca c'est du pouvoir de nuissance ! Mauvaise nouvelle pour vous, y'a des millions de facons beaucoup plus faciles d'emmerder 100 fois plus un mec...
Le but d'HADOPI ce n'est pas de punir 100% des gens qui télécharge ou d'être infaillible. Simplement de faire suffisament peur aux gens pour rendre les réseaux moins attractifs (moins de contenu, moins de partage, moins de débit).
1- Faut arrêter de vivre dans le passé. Mitnick à réussi son truc par ce que la pile TCP/IP était une chiotte et qu'il arrivait à prédire les numéro de séquence. Tu me refais la même sur une pile TCP/IP moderne
2- Faut comparer ce qui est comparable. Mitnick a réussi à faire un SYN/ACK + envoyer UN paquet. On parle d'uploader en P2P là
3- Même dans le cas hypothétique ou c'est de UDP/IP et que ton FAI te laisse envoyer n'importe quoi il faudrait qu'il soit possible de tout faire en aveugle.
4- Si c'est de l'UDP/IP alors le protocole implémente forcement une gestion de congestion. Ca limite les chances de pouvoir tout faire en aveugle
5- Il faut garder le sens de la mesure. C'est pas un peu démeusuré comme effort pour faire fermer une pauvre connexion internet à quelqu'un ? Au départ les remarques c'était "C'est tous des baltringues, c'est super facile d'usurper une identité". Tout est possible, mais investir 500 000 euros pour en gagner 100 ca n'interesse pas forcement grand monde.
6- Si tu n'as pas confiance dans le réseau alors moi si il n'a que ca a foutre que de jouer avec HADOPI c'est un moindre mal. Avec un noeud bien placé (et bonus avec quelqu'un de bien placé chez une autorité de certification inclus dans les navigateurs web) il y a tellement mieux à faire...
> Avec le protocole bittorrent en UDP cela ne doit pas être très compliqué
Et bien explique nous (une démo c'est encore mieux). Que ca soit en UDP tu gagnes juste le spoof de session TCP.
D'ailleurs y'a vraiment des clients qui utilisent UDP pour le transfert des données ? J'ai pas regardé le protocol bittorrent depuis deux ans. Je sais qu'il y avait des annonces faites mais j'ai jamais vu la spec ou l'annonce d'un client qui utilisait UDP (en dehors de la connexion au tracker).
Ce commentaire s'applique mot pour mot aux radars automatiques fixes et mobiles ainsi qu'aux jumelles. A part que faire une doublette c'est à la portée de tout le monde. Par contre réussir à avoir une fausse IP sur un accès ADSL ca tient de la prouesse par contre. Légalement c'est le propriétaire de la connexion qui est responsable. Si tu laisses un AP ouvert, c'est pour toi. Ca n'a rien d'une usurpation d'une IP. En faisant le parallèle si tu laisses ta voiture à quelqu'un soit tu le dénonce, soit c'est toi qui prend. Soit tu prouves que c'était pas toi sur la photo et t'essayes de jouer...
En même temps c'est sucuidaire de partir avec une TOP25 avec des données d'il y a 70 ans... Quand on prend une carte au 1:25000 c'est qu'il y a une raison. Les informations précisent ne sont pas la pour faire joli.
Déjà que tu peux te faire quelques belles surprises avec des top 25 en fin de vie et n'ont pas été réactualisée depuis une petite dizaine d'années.
> De plus ça m'échappe quand même qu'une norme suive l'implémentation et pas le contraire... Ils feraient mieux décire la norme en collaboration avec des gens travaillant sur les navigateurs et en sortir quelque chose réalistiquement implémentable et utile.
Ca doit t'étonner par ce que tu as pas du souvent bosser sur ce genre de choses. C'est une pratique très courante que de demander des implémentations de référence valides avant qu'un draft ne devienne une norme.
1- Ca évite de faire n'importe quoi. Et tu te foures le doigt dans l'oeil en disant "Ce qui est décrit précisément est forcément implémentable". En implémentant on lève des points qui ne sautent pas aux yeux quand on écrit la spec. On trouve aussi des points peu clair ou tout simplement faux.
2- En avoir deux ca permet justement de trouver plus facilement les ambiguitées et les différentes interprétation possibles.
3- Ca évite d'éditer une norme qui n'intéresse personne.
4- Les normes sont poussées par ceux qui veulent en tirer partie. Le W3C comme tout autre organisation de normalisation, c'est pas une assemblée de magicien qui sortent une norme de nul part. En pratique ce sont les industriels intéressés par la norme qui l'écrivent. Donc c'est totalement raisonable d'attendre qu'ils développent une implémentation dès que le draft se stabilise.
> L'intérêt? Pourquoi ne pas fait directement une branche dans svn?
En fait c'est mal exprimé en effet. Tu crée ta branche subversion et tu peux associé N de tes branches git à cette branche subversion. En général une seule suffit, mais des fois c'est pratique d'en faire deux. Pour bosser sur des trucs séparés qui iront dans la même branche SVN. Évidement l'intêret de la branche SVN, c'est que les gens qui utilisent SVN peuvent y avoir accès.
Note que tu gardes le côté pratique de git, par ce qu'un commit git n'entraine pas immédiatement un commit SVN. Tu décides quand les pousser.
> C'est pas un peu abusé du concept, juste un point de vue.
C'est un point de vue en effet. Libre à chacun de faire comme il le veut. L'expérience m'a montré que mettre de nouveaux devs ou des refactoring important dans le trunk était une très mauvaise idée. Tu te retrouves avec un trunk non stable, ou avec des fonctionalités que tu ne veux pas encore ds la branche officielle donc impossibilité de releaser (voir même souvent de rollbacker). Avoir une branche par feature ca permet de prendre son temps pour que tout arrive à maturation, et de réfléchir au moment où tu intègres dans la branche principale. Ne pas créer de branche, ca veut dire que quelqu'un bosse en sousmarin donc tu n'as aucune idée de son changeset. C'est une question d'équilibre c'est sur. Il n'y a pas de bonne solution, il y a des solutions qui fonctionne avec ton projet et ton équipe.
> À te lire, on a l'impression que les autres devs n'y ont pas accès
Si bien sur, c'est une branche SVN. Ce que t'apporte git-svn, ce sont les branches locales et la possibilité créer une ou plusieurs branches git à partir d'une branche SVN. Tu travailles en locale avec tes branches git. Et tu pousses tes commits sur le SVN en une commande, de même tu mets à jour en une commande. Bref tu as la puissance de git sur la gestion des branches, des merges, des cherry-pick, du stash etc. tout en utilisant très simplement SVN. Hormis 2 ou 3 pièges ca fonctionne très bien, j'ai jamais réussi à le planter.
> Et le "merge" tu le fais où et quand? Sachant que c'est(c'était?) un inconvénient de SVN.
Oui c'est un des gros interet de passer à git-svn. Les merge (ou rebase) sont fait par git. Ensuite tu pousses le résultat sur le SVN. L'inconvéniant c'est que à cause du backend SVN tu perds les informations de merge dans git une fois que c'est poussé. Y'a pas de miracle.
> Les revisions SVN sont donc beaucoup plus espacées, ça se passe comment si tu veu revoir l'évolution de telle partie de code?
La j'ai pas compris la question.
Pour résumé comme dit plus haut. git-svn c'est le meilleur client svn, même si tu veux pas merger.
C'est ce qu'on fait au boulot avec les nouveaux arrivant et les gens qui n'ont pas de raison d'intégrer du code eux même. Techniquement y'aurait pas de soucis pour le faire sur des projets communautaires.
Je crois que dans le libre, les gens préfèrent leur confort et leurs convictions à aider les autres à intégrer un projet. On essaye encore de te convaincre sur quel éditeur utiliser en 2010... ;) Mais y'a des projets très sympas où le maintainer est très acceuillant pour ceux qui cherchent à contribuer. Récuperer un commit bit sur hudson c'est pas trop compliqué par exemple.
>1) Je veux contribuer à un projet, je commence par demander les droits pour commiter sur le dépôt du projet. Une fois que j'aurais cette autorisation, je pourrais faire mes commits là bas.
>2) Je veux contribuer à un projet, je n'ai pas les droits. Je fais un "svn checkout", je code, je fais "svn diff" et j'envoie le résultat par email.
3) Je sais configurer mon VCS, alors je donne les droits d'écriture aux wannabes qui le demande uniquement sur une branche qui leur est dédiée. Comme ca je peux voir leur travail en cours de route et les aider. Et c'est moi qui merge leurs commits dans les branches de prod.
Tu as la puissance de git en local tout en ayant la possibilité de garder ton repo SVN et donc n'avoir rien à changer dans tes confs et pour les autres. C'est très très très pratique quand tu es dans une infrastructure assez lourde et que tu ne peux pas changer de SCM facilement (Au choix problème de gestion, management, technique, formation des autres devs, manque d'outils etc.).
Tout les devs avec qui j'ai bossé et qui ont essayé ne peuvent plus s'en passer tellement ca leur facilite la vie. Pourtant ils étaient tous sceptiques.
Workflow commun:
- Ton master local correspond au trunk/
- Possibilité de mapper des branches locales vers des branches subversion. On créé une branche par feature. Tout ceux qui bossent sur cette feature utilise cette branche. On peut donc bosser sur une feature que les autres devs utilisent git ou pas
- Pour les petits patchs solo, une branche locale (aussi rattachée au trunk) un dcommit et c'est poussé dans le trunk.
Après ca reste git, compliqué d'accès. Trop de choix et de facon de faire. Marrant presque aucuns de ceux qui utilise git-svn ne l'utilisent de la même facon (merge puis dcommit VS dcommit, rebase VS merge, suivi de branch). Bref chacun fait a sa sauce, ce qui implique de perdre pas mal de temps au départ et n'aide pas à son adoption.
Bref c'est l'outil idéal si comme contrainte tu as "Le dépot du projet sur lequel je bosse est SVN". Attention j'ai pas dit que c'était l'outil idéal ;-)
> Tous les cadriciels ne sont pas des usines a gaz incroyables a la symfony/zend/jboss etc.
Dans les projets jboss y'a des énormes tueries (rarement vu un truc aussi bien foutu et propre que netty). Faut savoir choisir ses dépendances et pas embarquer une centrale nucléaire pour faire une galerie pourrie sur un autoindex ;)
Tu ne cites pas le paragraphe textuellement par ce que les gens se rendraient compte que tu racontes n'importe quoi ?
Between the previous and next sequence point an object shall have its stored value
modified at most once by the evaluation of an expression.72) Furthermore, the prior value
shall be read only to determine the value to be stored.73)
Ce qui ne correspond en rien à ce dont on discute: dst[pdst++] = src[psrc++]; ou la post incrémentation en général. Ou alors il va falloir expliquer en quoi...
C'est marrant à chaque fois que tu parles de quelque chose, ou que tu essayes de te justifier tu changes complétement de sujet. C'est pas plus simple de dire "J'ai dit une connerie ca change rien en C" ?
Reconnaitre qu'on a tord et qu'on ne sait pas tout c'est un bon début pour faire un bon développeur. Bien meilleur que de brailler sur des points d'une importance plus que douteuse.
> (et à lire les thuriféraires du C, on a toujours l'impression qu'ils se prennent pour des programmeurs parfaits). Mais un peu d'humilité est recommandé, dans n'importe quel métier...
À mettre en relation avec le fait que dans un journal, presque 40 ans après la création du C, on en est encore à discuter de savoir si post incrémenter un entier dans une boucle for c'est bien ou pas...
> Bref, c'est facile de démolir Perl mais personnellement, je préfère voir une application Perl tourner sur mon système que voir un machin java dont je n'y comprends rien. Question de goût (et puis aussi de liberté).
Y'a un intêret à ton message hormis dire "J'y connais un peu en X, j'y connais rien en Y. Alors je dis que j'utilise des trucs qui reposent sur X en cassant du dos sur Y alors que j'y connais rien" ?
Tu sais des mécanismes de plugins bien fait, drag & drop ca peut se faire dans tout les langages (et même en s'ouvrant à plein d'autres langages que celui du coeur de l'appli). Et si tu veux que les admins qui ne sont pas des devs écrivent des extensions, tu fais des trucs propres et simples à utiliser comme des bêtes filtres E/S ou embarquer des interpreteur python/ruby/js (ca se fait en 10 lignes de Java-beurk) etc.
En gros pour justifier ta bafouille tu parles de C++ alors que tu critiques du code C, et après fais une jolie diversion qui n'a pas grand chose à voir avec la post-incrémentation (change ton i++ en i *=4 et c'est parreil).
Bref en mettant tes habitudes de côté et avec un peu de bonne fois tu peux aussi admettre qu'en C post-incrémenter dans une boucle ca change keud et ca n'a rien de sâle.
PS: Avec un bête grep qui doit manquer la moitié des occurences, je trouve 33757 post incrémentations dans une boucle dans les sources du 2.6.34.1. Tu postes un patch sur LKML pour nous divertir un peu ?
> Moi ce que j'aimerais bien voir, c'est que dirait une entreprise si je leur faisais appliquer ces conditions à leurs contributions pour un de mes projets. Je suis sûr à 99% qu'elles n'accepteraient pas. J'aimerais d'ailleurs bien avoir des infos sur combien d'entreprises donnent leur copyright à une autre sur un projet Libre.
L'entreprise elle ne vient pas chialer que tu ne respectes pas le jeu du libre. Si elle considère que céder son copyright n'est pas juste pour un projet donné. Soit elle se passe de ce projet. Soit elle met les moyens en interne pour maintenir une version parallèle, avec ses patchs, qui correspond à ses besoins.
> J'aimerais d'ailleurs bien avoir des infos sur combien d'entreprises donnent leur copyright à une autre sur un projet Libre.
Bha commence par faire un tour du coté des projets apache et regarde d'où vient le code et ce qu'il y a derrière les @ des commiters.
Sur un seul projet: Yahoo!, Getopt, Facebook, Agmlab, Lastfm, Quantcast, Apple, Netflix, CBS Interactive, StumbleUpon, WorldLingo, Trend Micro, Autodesk, Twitter
> Pour l'instant, très peu de projets « phares » ont été cités utilisant cette méthode en dehors de la FSF
Par ce que les projets "phares" sont communautaires à la base. Il n'y a pas de pognon à faire sur les logiciels finaux donc très peu de chance que quelqu'un décide de payer 10 dev pour bosser la dessus. Comment veux tu qu'un lecteur de mail te rapporte de l'argent ? Tu ne vendras pas de version proprio, personne ne te paieras pour faire du dev custom et personne n'achetera le support. Ce sont donc des logiciels développés par la communauté dès la base. Si chacun amène sa pierre à l'édifice dès le début une telle clause est injustifiée, nous sommes d'accord. Dans ce cas, les seuls qui se permettent de le faire ce sont des fondations type GNU ou Apache.
Maintenant au risque de me répéter, le transfert de copyright ca s'applique à des projets qui existent par ce quelqu'un à beaucoup investi à un moment donné.
> C'est bizarre cette manie de tout ramener aux entreprises et à l'argent : je ne vie pas du Libre, mais j'y participe
Pour me répéter encore il y a de nombreux de types de projets libres: communautaire, utilisant les moyens d'une fondation, créé par une boite, sponsorisé etc.
Oublier les spécificités de chaque projets pour imposer sa vision, ca par contre je trouve ça assez réducteur. Quand une boite donne le boulot de 50 dev pendant X années gratos en libre (Qt par exemple), moi je dis merci. je les insultes pas par ce que si tu veux ton code mainstream faut céder ton copyright.
PS: Donc si j'ai bien compris tu viens faire la morale à des mecs qui arrivent/essayent à vivre professionnellement en écrivant du code libre (et qui ne te demande un transfert de copyright uniquement pour être inclus dans la version mainstream) alors que toi... Oui tu fais quoi ? ;-)
> J'aimerais bien avoir un exemple d'un changement tel que tu dis.
La où je bosse. Et pour ne pas être ego centrique ceux qui était en GPL v2 et qui se sont dit que ce serait une bonne idée de passer en v3 pour pouvoir être compatible avec ASF 2 et donc tout les projets Apache. Ca n'arrive pas tout les jours. Mais si tu peux éviter de tirer un trait sur cette possibilité pourquoi s'en priver ?
> le kernel en ce qui concerne la licence que veulent les utilisateurs/clients.
Non la licence de linux n'impact personne sauf les dev de modules et les forkeurs. Y'a pas de derivative work sur le kernel.
> Effectivement, mais la GPL ne fait pas de garantie de rentabilité, contrairement à ce qu'ont l'air de croire certaines boites
Elles te donnent une version GPL, ce qui est irrévocable. C'est un don. Certaines pensent pouvoir vivre uniquement du support, d'autres misent aussi sur le fait de pouvoir vivre en plus de versions prorios pour ceux qui ne veulent pas de libre (cool ils financent du dev libre !), d'autres espère vivre suffisament longtemps pour ne pas vouloir se retrouver bloquer sur une license.
> « regarde notre générosité, pauvre manant ! » Ils ont sorti du code sous GPL, je leur en suis reconnaissant, mais c'est tout : ils ont joué le jeu, c'est très bien. Quand je fais aussi du code sous GPL, ils devraient être content également. Mais non, ils veulent plus, une assignation de copyright.
Bin oui c'est ca. Ils sont généreux, ils ont développé du code qu'ils ont donné de manière irrévocable sous license libre. Tu veux contribuer au projet mainstream ? Alors tu acceptes qu'ils puissent relicensier ton boulot sous certaines conditions (ce que demande python par exemple). Tu trouves ca innaceptable ? Trouve un autre projet, ou tu maintiens une version en // avec ton code. C'est clause là ne sont appliquer que dans des projets où l'entreprise/la fondation mère à écrit une très grosse base de code.
Ne pas jouer le jeux du libre ? Ils t'ont donné le code et ils appliquent les mêmes procédés que les projets phares du libre... Tu as une vision, les autres en ont une autre. La tienne n'est pas plus représentative du jeux du libre que celles des autres.
Bref tu as de jolis principes. Maintenant faudrait voir la réalité, genre en vivant de code libre ou en montant une boite qui fait vraiment du dev libre (je parle pas d'un intégrateur qui pisse 1Kloc autour d'un produit libre pour un client).
[^] # Re: Pas de problème
Posté par ckyl . En réponse au journal Toujours plus vite. Évalué à 9.
Non ce qui a posé problème ce matin c'est que tu as des compétences sur des outils de 20 ans d'age mais que tu n'as pas mis à jour tes compétences sur des technos récentes.
Non le fonctionnement des Unix ni simple ni naturel alors que tout les outils récents sont merdiques et mal concu. Tout au mieux il est logique; et on a juste appris à s'en servir et s'imprégner de leur logique et de leurs limitations avec le temps. Alors t'as deux solutions, te former sur les technos que tu veux utiliser ou utiliser des produits qui n'offrent que des technos sur lesquels tu as des compétences.
> Ce n'est pas tant NM qui m'énerve que son incompatibilité avec tout ce qui s'est fait jusqu'alors, et qui ne marchait pas si mal que ça.
Oui avant NM c'était très facile et pratique de se connecter à un réseau wifi recontré dans la rue, puis de basculer sur du RJ45 et enfin je rejoindre un vpn en tant que simple utilisateur d'un laptop. Tu as raison.
[^] # Re: pas mal de magnifiques joujous ne quitteront jamais l'Asie
Posté par ckyl . En réponse au journal Des produits pas en vente. Évalué à 6.
Si ils sont trop cons pour voir que y'a gras de bénéf à faire, pourquoi tu investis par dans l'import ?
[^] # Re: il me semble qu'on a (avait) en principe les memes contraintes en Fr
Posté par ckyl . En réponse au journal Defective by design : backdoors NSA, le retour ?. Évalué à 2.
Ca n'a rien à voir avec la culture d'entreprise, c'est juste une obligation légale pour tout les opérateurs (téléphoniques et autres).
Cf code de télécommunication (pour le chiffrement) et loi 91-646 (pour les écoutes)
[^] # Re: Sont pas sûrs d'eux..
Posté par ckyl . En réponse au journal Seedfuck et la légalité. Évalué à 2.
Les deux premiers liens n'ont rien a voir.
> Combien de routeur/modem adsl n'ont pas été mis à jour depuis plusieurs années ?
TCP c'est de bout en bout (donc les routeurs non patchés...) et il faut une large fenêtre TCP ce qui n'est pas le cas courant. Je te dis pas que c'est impossible. Je te dis "Spoof moi une connexion sur un Windows ou un OS X dans des conditions normales"
> Non, c'est faux. UDP n'a pas de gestion de congestion. Les routeurs intermédiaires peuvent le faire via des files. Il y a néanmoins un protocole récent et peu utilisé qui fait le boulot [http://en.wikipedia.org/wiki/Datagram_Congestion_Control_Pro(...)] .
Évidement qu'UDP n'en a pas. Mais tu crois vraiment qu'un protocole bittorrent basé sur UDP n'en intégrerait pas un ? Tu peux regarder les réseaux s'écrouler dans la journée.
> Le but n'est pas de faire fermer la connection de quelqu'un mais de noyer dans la masse de faux positifs et rendre la détection statistiquement impossible.
Alors il faudra de changer de méthode de détection ! En attendant avant de déclarer celle là obsolète, faut que quelqu'un réussisse à mettre en oeuvre celle que tu décris. Et que ca soit suffisament reproductible pour "noyer".
[^] # Re: Sont pas sûrs d'eux..
Posté par ckyl . En réponse au journal Seedfuck et la légalité. Évalué à 5.
[^] # Re: Sont pas sûrs d'eux..
Posté par ckyl . En réponse au journal Seedfuck et la légalité. Évalué à 4.
C'est beau vos rêve de super méchant, qui va prendre la main sur un subnet ADSL pour faire fermer la connexion ADSL de quelqu'un pendant 3 mois à un an. Wha ca c'est du pouvoir de nuissance ! Mauvaise nouvelle pour vous, y'a des millions de facons beaucoup plus faciles d'emmerder 100 fois plus un mec...
Le but d'HADOPI ce n'est pas de punir 100% des gens qui télécharge ou d'être infaillible. Simplement de faire suffisament peur aux gens pour rendre les réseaux moins attractifs (moins de contenu, moins de partage, moins de débit).
[^] # Re: Sont pas sûrs d'eux..
Posté par ckyl . En réponse au journal Seedfuck et la légalité. Évalué à 1.
2- Faut comparer ce qui est comparable. Mitnick a réussi à faire un SYN/ACK + envoyer UN paquet. On parle d'uploader en P2P là
3- Même dans le cas hypothétique ou c'est de UDP/IP et que ton FAI te laisse envoyer n'importe quoi il faudrait qu'il soit possible de tout faire en aveugle.
4- Si c'est de l'UDP/IP alors le protocole implémente forcement une gestion de congestion. Ca limite les chances de pouvoir tout faire en aveugle
5- Il faut garder le sens de la mesure. C'est pas un peu démeusuré comme effort pour faire fermer une pauvre connexion internet à quelqu'un ? Au départ les remarques c'était "C'est tous des baltringues, c'est super facile d'usurper une identité". Tout est possible, mais investir 500 000 euros pour en gagner 100 ca n'interesse pas forcement grand monde.
6- Si tu n'as pas confiance dans le réseau alors moi si il n'a que ca a foutre que de jouer avec HADOPI c'est un moindre mal. Avec un noeud bien placé (et bonus avec quelqu'un de bien placé chez une autorité de certification inclus dans les navigateurs web) il y a tellement mieux à faire...
[^] # Re: Sont pas sûrs d'eux..
Posté par ckyl . En réponse au journal Seedfuck et la légalité. Évalué à 2.
Et bien explique nous (une démo c'est encore mieux). Que ca soit en UDP tu gagnes juste le spoof de session TCP.
D'ailleurs y'a vraiment des clients qui utilisent UDP pour le transfert des données ? J'ai pas regardé le protocol bittorrent depuis deux ans. Je sais qu'il y avait des annonces faites mais j'ai jamais vu la spec ou l'annonce d'un client qui utilisait UDP (en dehors de la connexion au tracker).
[^] # Re: Mouais...
Posté par ckyl . En réponse au journal Seedfuck et la légalité. Évalué à 3.
[^] # Re: Sont pas sûrs d'eux..
Posté par ckyl . En réponse au journal Seedfuck et la légalité. Évalué à 7.
Oui moi aussi. Tu me fais la démonstration pratique de comment tu fais sur une infra réelle type accès ADSL ?
[^] # Re: La montagne, ça vous perd
Posté par ckyl . En réponse à la dépêche syj: site de partage d'itinéraire. Évalué à 2.
Déjà que tu peux te faire quelques belles surprises avec des top 25 en fin de vie et n'ont pas été réactualisée depuis une petite dizaine d'années.
[^] # Re: Pas que chez nous...
Posté par ckyl . En réponse au journal Les journalistes et les chiffres. Évalué à 8.
[^] # Re: Pas compris.
Posté par ckyl . En réponse au journal Le W3C a besoin de vous!. Évalué à 8.
Ca doit t'étonner par ce que tu as pas du souvent bosser sur ce genre de choses. C'est une pratique très courante que de demander des implémentations de référence valides avant qu'un draft ne devienne une norme.
1- Ca évite de faire n'importe quoi. Et tu te foures le doigt dans l'oeil en disant "Ce qui est décrit précisément est forcément implémentable". En implémentant on lève des points qui ne sautent pas aux yeux quand on écrit la spec. On trouve aussi des points peu clair ou tout simplement faux.
2- En avoir deux ca permet justement de trouver plus facilement les ambiguitées et les différentes interprétation possibles.
3- Ca évite d'éditer une norme qui n'intéresse personne.
4- Les normes sont poussées par ceux qui veulent en tirer partie. Le W3C comme tout autre organisation de normalisation, c'est pas une assemblée de magicien qui sortent une norme de nul part. En pratique ce sont les industriels intéressés par la norme qui l'écrivent. Donc c'est totalement raisonable d'attendre qu'ils développent une implémentation dès que le draft se stabilise.
[^] # Re: Git svn
Posté par ckyl . En réponse au journal Git malgré moi. Évalué à 3.
En fait c'est mal exprimé en effet. Tu crée ta branche subversion et tu peux associé N de tes branches git à cette branche subversion. En général une seule suffit, mais des fois c'est pratique d'en faire deux. Pour bosser sur des trucs séparés qui iront dans la même branche SVN. Évidement l'intêret de la branche SVN, c'est que les gens qui utilisent SVN peuvent y avoir accès.
Note que tu gardes le côté pratique de git, par ce qu'un commit git n'entraine pas immédiatement un commit SVN. Tu décides quand les pousser.
> C'est pas un peu abusé du concept, juste un point de vue.
C'est un point de vue en effet. Libre à chacun de faire comme il le veut. L'expérience m'a montré que mettre de nouveaux devs ou des refactoring important dans le trunk était une très mauvaise idée. Tu te retrouves avec un trunk non stable, ou avec des fonctionalités que tu ne veux pas encore ds la branche officielle donc impossibilité de releaser (voir même souvent de rollbacker). Avoir une branche par feature ca permet de prendre son temps pour que tout arrive à maturation, et de réfléchir au moment où tu intègres dans la branche principale. Ne pas créer de branche, ca veut dire que quelqu'un bosse en sousmarin donc tu n'as aucune idée de son changeset. C'est une question d'équilibre c'est sur. Il n'y a pas de bonne solution, il y a des solutions qui fonctionne avec ton projet et ton équipe.
> À te lire, on a l'impression que les autres devs n'y ont pas accès
Si bien sur, c'est une branche SVN. Ce que t'apporte git-svn, ce sont les branches locales et la possibilité créer une ou plusieurs branches git à partir d'une branche SVN. Tu travailles en locale avec tes branches git. Et tu pousses tes commits sur le SVN en une commande, de même tu mets à jour en une commande. Bref tu as la puissance de git sur la gestion des branches, des merges, des cherry-pick, du stash etc. tout en utilisant très simplement SVN. Hormis 2 ou 3 pièges ca fonctionne très bien, j'ai jamais réussi à le planter.
> Et le "merge" tu le fais où et quand? Sachant que c'est(c'était?) un inconvénient de SVN.
Oui c'est un des gros interet de passer à git-svn. Les merge (ou rebase) sont fait par git. Ensuite tu pousses le résultat sur le SVN. L'inconvéniant c'est que à cause du backend SVN tu perds les informations de merge dans git une fois que c'est poussé. Y'a pas de miracle.
> Les revisions SVN sont donc beaucoup plus espacées, ça se passe comment si tu veu revoir l'évolution de telle partie de code?
La j'ai pas compris la question.
Pour résumé comme dit plus haut. git-svn c'est le meilleur client svn, même si tu veux pas merger.
[^] # Re: workflows
Posté par ckyl . En réponse au journal Git malgré moi. Évalué à 2.
Je crois que dans le libre, les gens préfèrent leur confort et leurs convictions à aider les autres à intégrer un projet. On essaye encore de te convaincre sur quel éditeur utiliser en 2010... ;) Mais y'a des projets très sympas où le maintainer est très acceuillant pour ceux qui cherchent à contribuer. Récuperer un commit bit sur hudson c'est pas trop compliqué par exemple.
[^] # Re: workflows
Posté par ckyl . En réponse au journal Git malgré moi. Évalué à 3.
>1) Je veux contribuer à un projet, je commence par demander les droits pour commiter sur le dépôt du projet. Une fois que j'aurais cette autorisation, je pourrais faire mes commits là bas.
>2) Je veux contribuer à un projet, je n'ai pas les droits. Je fais un "svn checkout", je code, je fais "svn diff" et j'envoie le résultat par email.
3) Je sais configurer mon VCS, alors je donne les droits d'écriture aux wannabes qui le demande uniquement sur une branche qui leur est dédiée. Comme ca je peux voir leur travail en cours de route et les aider. Et c'est moi qui merge leurs commits dans les branches de prod.
[^] # Re: Git svn
Posté par ckyl . En réponse au journal Git malgré moi. Évalué à 3.
Tu as la puissance de git en local tout en ayant la possibilité de garder ton repo SVN et donc n'avoir rien à changer dans tes confs et pour les autres. C'est très très très pratique quand tu es dans une infrastructure assez lourde et que tu ne peux pas changer de SCM facilement (Au choix problème de gestion, management, technique, formation des autres devs, manque d'outils etc.).
Tout les devs avec qui j'ai bossé et qui ont essayé ne peuvent plus s'en passer tellement ca leur facilite la vie. Pourtant ils étaient tous sceptiques.
Workflow commun:
- Ton master local correspond au trunk/
- Possibilité de mapper des branches locales vers des branches subversion. On créé une branche par feature. Tout ceux qui bossent sur cette feature utilise cette branche. On peut donc bosser sur une feature que les autres devs utilisent git ou pas
- Pour les petits patchs solo, une branche locale (aussi rattachée au trunk) un dcommit et c'est poussé dans le trunk.
Après ca reste git, compliqué d'accès. Trop de choix et de facon de faire. Marrant presque aucuns de ceux qui utilise git-svn ne l'utilisent de la même facon (merge puis dcommit VS dcommit, rebase VS merge, suivi de branch). Bref chacun fait a sa sauce, ce qui implique de perdre pas mal de temps au départ et n'aide pas à son adoption.
Bref c'est l'outil idéal si comme contrainte tu as "Le dépot du projet sur lequel je bosse est SVN". Attention j'ai pas dit que c'était l'outil idéal ;-)
[^] # Re: Les cadriciels (frameworks)
Posté par ckyl . En réponse au journal Marre du dévelopement bloatware moderne ! Appel aux armes !. Évalué à 3.
Dans les projets jboss y'a des énormes tueries (rarement vu un truc aussi bien foutu et propre que netty). Faut savoir choisir ses dépendances et pas embarquer une centrale nucléaire pour faire une galerie pourrie sur un autoindex ;)
[^] # Re: Sécurité ?
Posté par ckyl . En réponse à la dépêche Un nouveau serveur httpd : Ashd, A Sane HTTP Daemon. Évalué à 3.
Between the previous and next sequence point an object shall have its stored value
modified at most once by the evaluation of an expression.72) Furthermore, the prior value
shall be read only to determine the value to be stored.73)
Ce qui ne correspond en rien à ce dont on discute: dst[pdst++] = src[psrc++]; ou la post incrémentation en général. Ou alors il va falloir expliquer en quoi...
C'est marrant à chaque fois que tu parles de quelque chose, ou que tu essayes de te justifier tu changes complétement de sujet. C'est pas plus simple de dire "J'ai dit une connerie ca change rien en C" ?
Reconnaitre qu'on a tord et qu'on ne sait pas tout c'est un bon début pour faire un bon développeur. Bien meilleur que de brailler sur des points d'une importance plus que douteuse.
[^] # Re: J'y crois pas.
Posté par ckyl . En réponse à la dépêche Un nouveau serveur httpd : Ashd, A Sane HTTP Daemon. Évalué à 8.
À mettre en relation avec le fait que dans un journal, presque 40 ans après la création du C, on en est encore à discuter de savoir si post incrémenter un entier dans une boucle for c'est bien ou pas...
[^] # Re: J'y crois pas.
Posté par ckyl . En réponse à la dépêche Un nouveau serveur httpd : Ashd, A Sane HTTP Daemon. Évalué à 6.
Y'a un intêret à ton message hormis dire "J'y connais un peu en X, j'y connais rien en Y. Alors je dis que j'utilise des trucs qui reposent sur X en cassant du dos sur Y alors que j'y connais rien" ?
Tu sais des mécanismes de plugins bien fait, drag & drop ca peut se faire dans tout les langages (et même en s'ouvrant à plein d'autres langages que celui du coeur de l'appli). Et si tu veux que les admins qui ne sont pas des devs écrivent des extensions, tu fais des trucs propres et simples à utiliser comme des bêtes filtres E/S ou embarquer des interpreteur python/ruby/js (ca se fait en 10 lignes de Java-beurk) etc.
[^] # Re: Sécurité ?
Posté par ckyl . En réponse à la dépêche Un nouveau serveur httpd : Ashd, A Sane HTTP Daemon. Évalué à 5.
Bref en mettant tes habitudes de côté et avec un peu de bonne fois tu peux aussi admettre qu'en C post-incrémenter dans une boucle ca change keud et ca n'a rien de sâle.
PS: Avec un bête grep qui doit manquer la moitié des occurences, je trouve 33757 post incrémentations dans une boucle dans les sources du 2.6.34.1. Tu postes un patch sur LKML pour nous divertir un peu ?
[^] # Re: KDE/GNOME
Posté par ckyl . En réponse à la dépêche Sortie de Qt 4.7. Évalué à 3.
(Réponse ironique à http://linuxfr.org/comments/1164653.html#1164264 )
[^] # Re: poum poum poum... contributor agreement
Posté par ckyl . En réponse à la dépêche Diaspora publié sur GitHub et une alpha annoncée pour octobre. Évalué à 2.
L'entreprise elle ne vient pas chialer que tu ne respectes pas le jeu du libre. Si elle considère que céder son copyright n'est pas juste pour un projet donné. Soit elle se passe de ce projet. Soit elle met les moyens en interne pour maintenir une version parallèle, avec ses patchs, qui correspond à ses besoins.
> J'aimerais d'ailleurs bien avoir des infos sur combien d'entreprises donnent leur copyright à une autre sur un projet Libre.
Bha commence par faire un tour du coté des projets apache et regarde d'où vient le code et ce qu'il y a derrière les @ des commiters.
Sur un seul projet: Yahoo!, Getopt, Facebook, Agmlab, Lastfm, Quantcast, Apple, Netflix, CBS Interactive, StumbleUpon, WorldLingo, Trend Micro, Autodesk, Twitter
> Pour l'instant, très peu de projets « phares » ont été cités utilisant cette méthode en dehors de la FSF
Par ce que les projets "phares" sont communautaires à la base. Il n'y a pas de pognon à faire sur les logiciels finaux donc très peu de chance que quelqu'un décide de payer 10 dev pour bosser la dessus. Comment veux tu qu'un lecteur de mail te rapporte de l'argent ? Tu ne vendras pas de version proprio, personne ne te paieras pour faire du dev custom et personne n'achetera le support. Ce sont donc des logiciels développés par la communauté dès la base. Si chacun amène sa pierre à l'édifice dès le début une telle clause est injustifiée, nous sommes d'accord. Dans ce cas, les seuls qui se permettent de le faire ce sont des fondations type GNU ou Apache.
Maintenant au risque de me répéter, le transfert de copyright ca s'applique à des projets qui existent par ce quelqu'un à beaucoup investi à un moment donné.
> C'est bizarre cette manie de tout ramener aux entreprises et à l'argent : je ne vie pas du Libre, mais j'y participe
Pour me répéter encore il y a de nombreux de types de projets libres: communautaire, utilisant les moyens d'une fondation, créé par une boite, sponsorisé etc.
Oublier les spécificités de chaque projets pour imposer sa vision, ca par contre je trouve ça assez réducteur. Quand une boite donne le boulot de 50 dev pendant X années gratos en libre (Qt par exemple), moi je dis merci. je les insultes pas par ce que si tu veux ton code mainstream faut céder ton copyright.
PS: Donc si j'ai bien compris tu viens faire la morale à des mecs qui arrivent/essayent à vivre professionnellement en écrivant du code libre (et qui ne te demande un transfert de copyright uniquement pour être inclus dans la version mainstream) alors que toi... Oui tu fais quoi ? ;-)
[^] # Re: poum poum poum... contributor agreement
Posté par ckyl . En réponse à la dépêche Diaspora publié sur GitHub et une alpha annoncée pour octobre. Évalué à 3.
La où je bosse. Et pour ne pas être ego centrique ceux qui était en GPL v2 et qui se sont dit que ce serait une bonne idée de passer en v3 pour pouvoir être compatible avec ASF 2 et donc tout les projets Apache. Ca n'arrive pas tout les jours. Mais si tu peux éviter de tirer un trait sur cette possibilité pourquoi s'en priver ?
> le kernel en ce qui concerne la licence que veulent les utilisateurs/clients.
Non la licence de linux n'impact personne sauf les dev de modules et les forkeurs. Y'a pas de derivative work sur le kernel.
> Effectivement, mais la GPL ne fait pas de garantie de rentabilité, contrairement à ce qu'ont l'air de croire certaines boites
Elles te donnent une version GPL, ce qui est irrévocable. C'est un don. Certaines pensent pouvoir vivre uniquement du support, d'autres misent aussi sur le fait de pouvoir vivre en plus de versions prorios pour ceux qui ne veulent pas de libre (cool ils financent du dev libre !), d'autres espère vivre suffisament longtemps pour ne pas vouloir se retrouver bloquer sur une license.
> « regarde notre générosité, pauvre manant ! » Ils ont sorti du code sous GPL, je leur en suis reconnaissant, mais c'est tout : ils ont joué le jeu, c'est très bien. Quand je fais aussi du code sous GPL, ils devraient être content également. Mais non, ils veulent plus, une assignation de copyright.
Bin oui c'est ca. Ils sont généreux, ils ont développé du code qu'ils ont donné de manière irrévocable sous license libre. Tu veux contribuer au projet mainstream ? Alors tu acceptes qu'ils puissent relicensier ton boulot sous certaines conditions (ce que demande python par exemple). Tu trouves ca innaceptable ? Trouve un autre projet, ou tu maintiens une version en // avec ton code. C'est clause là ne sont appliquer que dans des projets où l'entreprise/la fondation mère à écrit une très grosse base de code.
Ne pas jouer le jeux du libre ? Ils t'ont donné le code et ils appliquent les mêmes procédés que les projets phares du libre... Tu as une vision, les autres en ont une autre. La tienne n'est pas plus représentative du jeux du libre que celles des autres.
Bref tu as de jolis principes. Maintenant faudrait voir la réalité, genre en vivant de code libre ou en montant une boite qui fait vraiment du dev libre (je parle pas d'un intégrateur qui pisse 1Kloc autour d'un produit libre pour un client).