GeneralZod a écrit 2316 commentaires

typage faible + la gestion bizarre des conversion string -> int en php + la syntaxe abscons inspiré de perl = 42

> Il semblerait que, pour toi, le sexe « par surprise » serait anodin

Ma réponse exacte est: ça dépends.
C'est simple, soit une relation est consentie, soit elle ne l'est pas, qu'il y ait un effet de surprise ou pas. Effet de surprise n'implique pas systèmatiquement viol, par exemple, ça peut être un jeu au sein d'un couple (sauf si l'une des parties retire son consentemment et même dans un couple marié, ça devient un viol entre conjoints).

> apparemment une des deux femmes aurait retiré son consentement pendant l'acte
Si c'est effectivement le cas, pas la peine de tourner autour du pot, c'est un viol.
L'effet de surprise c'est "la capote a pété pendant l'acte"
1. a-t-elle explicitement signifié à Assange qu'elle souhaitait arrêter immédiatement ou bien Assange l'a-t-il empêché d'exprimer sa volonté ? Difficile à prouver quand on s'est vanté urbi et orbi sur internet d'avoir couché avec lui.
2. Assange a-t-il volontaire éclaté la capote comme elle le prétends aujourd'hui ? c'est un peu trop gros comme accusation ?

Plutôt que de poursuivre une procédure judiciaire portant ostensiblement la grosse patte du département d'Etat US, on ferait mieux d'arrêter les violeurs et/ou pédophiles qui trainent en liberté comme un certain R. Polanski et les autres plus ou moins célèbres

> Oh oui. Mais tu le savais déjà, non ?
Oui, mais pour d'autres raisons, si en plus de m'inquiéter de chopper une MST, je dois m'inquiéter de me faire chopper par la police !

> Les deux femmes n'avaient peut-être pas envie d'étaler toute la chronologie de leurs ébats minute par minute dans les journaux... (du moins au début de l'affaire)

J'ai bel et bien l'impression que l'étalage des faits au compte-gouttes était volontaire.
Au départ, on te parle de viol, d'agression sexuelle, c'est à dire qu'une personne force une autre personne à accomplir ou subir un acte à caractère sexuel non consentie. Puis, on s'aperçoit que les faits reposent sur du vent, on essaie tant bien que mal de requalifier les actes comme étant "sexe par surprise" ("hé chérie, regarde un ours rose qui fait du tricycle" et hop un coup par surprise) qui même en Suède ne vaut à son auteur qu'une petite amende.
Même si J. Assange est innocenté de la charge de viol, il se trainera une étiquette de "violeur" jusqu'à sa mort. Le mal est fait.

> les poursuites ont été réouvertes lorsque les deux femmes ont contacté une dame procureur qui est une militante connue du durcissement des lois sur les agressions sexuelles.

Marianne Ny a beau être une conne notoire, le dossier est trop faible pour justifier la réouverture du dossier et encore moins un mandat d'arrêt international.
Va falloir faire gaffe, une capote qui éclate et vous voilà devenu un dangereux criminel recherché par interpol !

http://thestandard.org.nz/marianne-ny-making-an-arse-of-swed(...)

1. Je suis d'accord sur le principe que J. Assange ne doit pas être intouchable, mais les accusations de "viols" en fait "sexe par surprise", ah mais les filles étaient consentantes, non, c'est relations non protégées (Bouh, le vilain qui baise sans capote) puis au final, c'était la capote qui a pété dans un cas ... bref, ça commence à être douteux, surtout quand un secrétaire d'Etat US se réjouit publiquement de l'arrestation d'Assange ...
On notera que les poursuites qui avaient un temps arrếtés (un procureur suédois les trouvant même bancales) ont été réactivés suite à la publication des câbles diplomatiques - tiens drôle de coïncidences ! -
2. le but c'est de détourner l'attention des journaleux et du public, et pour ça rien de tel que de trainer une personne dans la boue autour d'une histoire de fesses.
3. ça sera pire mais ils n'ont encore pas compris.
4. le problème c'est que wikileaks n'a rien commis d'illégal (en revanche, certains de leurs informateurs oui), le journalisme scientifique c'est ni plus ni moins le retour du journalisme d'investigation sauf que les sources (bien évidemment vérifiés et filtrés) sont à la disposition du public. Or jusqu'à preuve du contraire, le journalisme d'investigation est protégé par la législation de la majorité des démocraties actuelles. S'attaquer légalement à Wikileaks reviendrait à remettre en question différents fondamentaux dont la liberté d'expression, c'est pourquoi les gouvernants ont choisis la menace plûtot que la légalité (y compris le traitre Besson, ministre à l'économie numérique avec OVH)

> Git est aussi très efficace pour compresser les deltas (cf. git gc, git repack)
Pour les opérations réseaux comme clone, pull, push etc ..., le protocole wire de mercurial est sensiblement plus efficace que le protocole git ou même HTTP utilisé par Git.
De plus, les opérations d'optimisation du stockage sont automatisées dans mercurial (donc plus "newbie-proof"), certes, Git reste un poil plus efficace à ce niveau.

> Autre truc qui m'énerve avec mercurial, c'est qu'on n'a aucun indicateur de progression quand on clone depuis le web
Tu as l'extension standard progress pour ça, suffit de l'activer.

C'est probablement le cas -même si certains kernel hackers n'utilisent pas leur adresse mail pro-, Justin Mattock a récemment un travail titanesque pour mettre à jour les urls dans les sources du noyau [1], mettre à jour les infos de copyright semblent être la continuation logique de son initiative.

[1] http://article.gmane.org/gmane.linux.kernel/1038673

> L'install est juste very easy sous ubuntu grace a la présence native python 2.6

C'est surtout que ton machin est mal gaulé [1], aucune raison valable pour qu'une application 100% python et dépendant de modules plutôt répandus ne tourne pas sur une distribution récente. Pour info, Fedora fournit python 2.6 de F11 à F13 et python 2.7 sur F14+ (ça tourne), je suis prêt à parier que pySHOT doit pouvoir tourner sur python 2.5 sans trop de difficultés.

[1] tu devrais utiliser les outils standards comme distutils/distribute ou au moins un Makefile. C'est typiquement le genre de choses qui facilitent la vie pour le mainteneur upstream et les empaqueteurs. Un projet facile à empaqueter est un projet qui peut toucher une plus large audience.

Comme souvent, les journaleux brassent de l'air pour pas grand chose.
On ne sait pas trop si Ubuntu s'oriente effectivement vers un système de rolling release, ou bien mettre à jour certains composants sans attendre la prochaine version (sont mentionnés OOo et Firefox etc ...) ou intégrer encore plus en avant les ppa à l'aide du Software machin bidule chouette. C'est même pas sourcé, pas de citations ou de liens pertinents en relation avec le sujet de l'article, un article bouche-trou ou bien un journaliste en mal d'inspiration qui a besoin de manger ce mois-ci.

Sinon est-ce qu'Ubuntu pourrait un jour passer à un système de rolling release, pourquoi pas ... ça aiderait Canonical à planifier plus sereinement les LTS sans devoir se soucier des versions intermédiaires mais je ne sais pas si la communauté y gagnerait vraiment.
C'est plus ou moins, le fonctionnement de Mandriva, une Cooker en rolling release puis une version entreprise qui sort à intervalles réguliers.

Non, si tu as une licence entreprise, tu as la possibilité de gérer toi-même la distribution sans passer par l'App Store (ou validation par Apple).
Leur programme entreprise est pas trop mal foutu, en tout cas plus grosses structures compliant que la concurrence.

Kristian a quitté Red Hat début 2010, c'était entre autre l'auteur d'AIGLX.

> Fedora suit Ubuntu dans l'adoption prgressive de Wayland
Keith Packard Mark Shuttleworth nous a montré la voie, gloire et prospérité au SABDFL ! Bigre, reste plus à convaincre les nazistes de Fedora d'utiliser Unity par défaut pour avoir enfin une distribution presque human-compliant (mais quels sangsues, ces gens de Fedora pour profiter du travail d'ubuntu !)

Comme son nom l'indique MQ ne gère qu'une file de patchs donc c'est le comportement normal.
git rebase -i ne peut modifier l'historique que d'une seule branche, si tu touches à un commit partagés par plusieurs branches, ça revient à changer le parent de ta branche et à créer un nouveau commit en cas de modification. C'est toujours possible avec à l'aide de plusieurs files (hg help qqueue) ou des extensions rebase et transplant mais dans ce cas-là, c'est plus fastidieux qu'avec git.
En même temps, ça reste cohérent avec la philosophie de mercurial qui déconseille l'édition de l'historique, comme on it: "there's no such thing as one size fits all".

Quant à histedit, j'ai peu utilisé donc je ne peux pas dire grand chose à ce sujet.

ça fait déjà quelques années que je m'y suis mis, et j'ai même été un des béta-testeurs de dist-git.
Pour info, mon Git-fu est aussi bon que mon hg do.

> Qui "on" ? Pas les développeurs de Git.
Shawn Pearce (2ème commiter dans Git devant Linus) avait écrit un quilt-like (abandonné depuis) et récemment Petr Baudis (TopGit). StGit et Guilt sont maintenus par des contributeurs de moindre importance.

> Je ne vois pas que c'est une "branche légère" dans Git. Ca c'est une formulation Hg.
Même pas, on parle de heads dans le jargon mercurial, les branches "légères" est un terme générique pour désigner les branches au sein d'un même clone, les branches "lourdes" désignant eux les clones.

> Quilt n'est qu'une évolution des scripts utilisés par les développeurs du noyau (avant BitKeeper, ils avaient bien un outil et ce n'était pas CVS).

Andrew Morton a publié ces scripts en 2002 - à l'époque où Linus a décidé d'utiliser BitKeeper - et c'était très rudimentaire.
http://lwn.net/Articles/13518/

> Les gens demandent aussi des poneys roses.
Si deux développeurs majeurs de Git ont proposés des surcouches pour gérer cette fonctionnalités, c'est peut-être pas si stupide que ça.

> Perso j'arrête la la discussion, le prosélytisme aveugle, ca me gonfle rapidement
>> La gestion des branches est tellement plus avancée que cette fonctionnalité n'est pas utile.
>> De plus, MQ est utile quand on est seul, mais devient intenable pour du travail collaboratif.
C'est très bien de reconnaitre ses erreurs.

> Mais pour cela, il faut connaitre les 2 outils.
Je plusse.

> Neophyte faites vos tests mais je soupconne que pour une utilisation "premier abord" les deux se valent.
Rien que le fait de pouvoir travailler hors-ligne (et par conséquent de meilleures performances), la gestion des branches, et un merge fonctionnel, on peut oublier les antiquités tels que CVS ou même SVN.

> Perso je prefere git (il ne se traine pas la passif de svn et donc de cvs...).
idem pour mercurial ...

Par expérience, je dirais qu'il est beaucoup plus facile de se tirer une balle dans le pied avec Git qu'avec Mercurial ne serait-ce qu'à cause de l'interface utilisateur complexe du premier.

> MQ n'existe pas dans git... car c'est totalement inutile
Tellement inutile qu'on a recréé des surcouches de Git pour gérer les patchs: stGit, Guilt (qui s'inspire directement des MQ) et bien d'autres.

> La gestion des branches est tellement plus avancée que cette fonctionnalité n'est pas utile.
Tu parles des branches légères ? hg help heads (si tu veux les nommer comme dans Git ==> extension standard bookmarks). Pour le reste, ça se vaut.
Néanmoins, même si les branches légères permettent partiellement de pallier à l'absence d'un outil de gestion de patchs, ça ne les remplacent pas complétement.

> De plus, MQ est utile quand on est seul, mais devient intenable pour du travail collaboratif.
MQ permet de versionner le dépôt de patchs (hg init --mq) pour permet de travailler en mode collaboratif.

> Note: MQ est une copie de Quilt, l'outil utilisé par... Linus torvalds avant de passer à BitKeeper
Linus a commencé à utiliser bitkeeper en 2002, quilt remonte à 2003 (les scripts d'Andrew Morton ont été publiés qui ont servi de base à quilt ont été publié en 2002). Chronologiquement, ça ne colle pas ton histoire.
De plus, MQ c'est un quilt survitaminée et très bien intégré à hg, ça permet de réaliser des opérations avancés qui vont bien au-delà de la simple gestion de patchs comme la réécriture de l'historique (et ce bien mieux que Git !). Les extensions de Mercurial permettent d'offrir un noyau simple à appréhender sans pour autant brider les utilisateurs avancés qui activent uniquement ce dont ils ont besoin.

> Il est donc parfaitement conscient de ce type d'outil et ce n'est pas un hasard si cela n'existe pas.
La demande d'un outil de gestion des patchs intégré à Git revient régulièrement dans les Git Surveys, donc ça contredit ton affirmation "Nan, on n'a pas besoin de ça".

Je rajouterais que MQ permet également une fonctionnalité très populaire parmi les utilisateurs de Git: l'édition de l'historique (rebaser, modifier, supprimer, ajouter combiner des changesets, etc ...) et ce de manière beaucoup plus simple et sûre !

> La distribution prendrait-elle vraiment un risque légal à distribuer un outil libre qu'elle n'a pas développé ?

Oui, et pas qu'aux USA dans ce cas-là.

> Est-ce pour rester corporate, "non on ne touche pas à ça nous ici" ?
C'est le Fedora Board qui a tranché après avoir consulté Fedora Legal (des contributeurs aidés des avocats de Red Hat). Le Fedora Board c'est le Fedora Project Leader (Jared Smith) + 4 représentants nommés par Red Hat et 5 représentants élus par les contributeurs.
Pour la non inclusion SQLNinja c'est 7 voix contre et 3 abstentions. De plus, si des éléments nouveaux se présentent, la porte n'est pas définitivement fermé.
Je pense qu'on peut écarter l'hypothèse corporate.

> Est-ce le rôle d'une distribution d'indiquer ce qui est bien ou PABIEN d'utiliser ?
Il n'y a aucun jugement de valeur, Fedora a estimé que distribuer SQLNinja constituait un risque légal non négligeable dans certains pays. De plus, soit c'est distribuable partout, soit ça n'est pas inclus dans Fedora, ça n'a rien d'incohérent dans une démarche libriste (parmi d'autres).
Fedora n'a pas statué sur le côté éthique de SQLNinja mais le côté légal pour distribuer ce paquet partout dans le monde. (En gros, est-ce que le jeu en vaut la chandelle, Fedora est sponsorisé par RH un concurrent direct de Microsoft, distribuer un outil qui permet de cracker les systèmes de ce dernier, c'est pas forcément le plus malin à faire).

D'ailleurs, on remarque que les mainteneurs du projet n'ont pas été capables de fournir une réponse crédible sur le risque légal.
Si SQLNinja avait une utilité autre que de cracker un système via des injections SQL, ça n'aurait posé aucun problème, on distribue déjà des outils permettant de faire ce genre de choses même si ça n'est pas leur utilité première (on distribue un spin security destiné à faire des audits de sécurité depuis quelques temps déjà).

> Si j'utilise l'extension rebase, est ce que je verrai dans le dépôt central SVN tous mes commits ?

Rien à voir, l'opération rebase consiste à importer en local les nouveaux changesets effectués sur le dépôt distant puis changer le parent des changesets locaux

a) avant le rebase
sur le serveur (B est le dernier changeset commun aux deux dépôt)
A ---> B ---> C ---> D
en local:
A ---> B ---> E ---> F

b) après le rebase
en local (rien n'a changé sur le serveur)
A ---> B ---> C ----> D ---> E' ---> F'
Si tu avais fait un pull, tu aurais eu:
A ---> B ---> C ---> D
\\\\\\\\\\ |---> E ---> F
Et ensuite, il faudrait faire un merge des deux branches (donc un nouveau commit, ce qui devient rapidement désagréable, GNOME et Mozilla encouragent à faire un rebase avant de proposer un nouveau patch entre autre pour cette raison)

C) push
sur le serveur et en local:
A ---> B ---> C ----> D ---> E' ---> F'

> On doit respecter un formalisme dans les messages de commit SVN que je ne respecte pas en local.

Je te conseille de rebaser, ça te simplifiera d'autant plus la tâche que tu dois respecter des guidelines pour tes messages de commits sur le dépôt distant.

> Existe-t-il quelque part un bon tutoriel si possible dans la langue de Mr Poquelin sur l'utilisation de hg et toutes les astuces possibles, et notamment mq ?
http://mercurial.selenic.com/wiki/FrenchTutorial ===> le tutoriel officiel en français
http://bitbucket.org/rpelisse/hgbook-fr/ ====> la traduction du hg book
http://doc.fedora-fr.org/wiki/Gestion_et_contr%C3%B4le_de_ve(...) ===> le tutoriel de mes amis de fedora-fr
http://dblugeon.developpez.com/tutoriel/mercurial/intro/ ===> un autre tutoriel de chez developpez.com

Je te l'accorde la littérature francophone n'est pas très prolixe autour de mercurial.

> j'imagine donc que les possibilités de hg et de tortoiseHg évoluent sans cesse
Je ne suis pas familier avec tortoisehg, mais tu peux considérer que depuis la version 1.1 (sortie en 2008), la sémantique des commandes de base et le format de dépôt n'a pas évolué.
Les principales nouveautés depuis (hormis l'amélioration des performances, les quelques nouvelles commandes et extensions) sont la possibilité de fermer explicitement une branche et les dépôts imbriqués.

> car lorsque mon code sera prêt, je vais devoir faire un hg pull, puis un hg merge, un hg ci et enfin un hg push qui remontera mes modifications dans le dépôt central en un seul commit.

Je te conseille d'utiliser l'extension standard rebase pour rebaser tes changesets sur ceux du serveur. Ça rajoute la commande rebase et l'option --rebase à la commande pull avec un fonctionnement similaire à Git.
Tu peux également le faire avec mq (qui tu l'auras compris est le couteau suisse de mercurial), il suffit d'importer tes changesets dans une queue et les réimporter sur le nouveau tip. Les deux méthodes se valent, la première est probablement plus simple pour ceux qui ne sont pas habitués à mq.

Même si mercurial n'inclut par défaut le rebasing, c'est considéré comme une bonne pratique dans la communauté mercurial. Contrairement au merge, le rebasing permet d'avoir un historique plus "propre" en éliminant les changesets propre au merge.

Contrairement à Git (Cf git rebase --interactive), Mercurial ne permet d'éditer directement l'historique). Tu as plusieurs façons de le faire

a) la méthode manuelle
Le principe est simple, tu veux combiner les changesets ]rev1, rev2] (note le sens des crochets
1. hg update rev1 # revenir à la révision 1 (index et répertoire de travail)
2. hg revert --all --rev rev2 # revenir à la révision 2 (répertoire de travail)
3. hg commit -m "combine rev1:rev2 changesets" # on commit l'ensemble des modifications en 1 changeset
L'inconvénient est que cette méthode crée une branche inutile (celle avec les commits non combinés), pour s'en débarrasser, soit tu clones le dépôt ou bien utiliser la commande strip fourni par l'extension mq.

b) la méthode mq
À peine plus compliqué que la précédente et beaucoup plus propre.
On suppose que tu as activé l'extension mq et initialiser le support dans le dépôt local
1. hg qimport rev1:rev2 # on confie à mq la gestion des changesets de rev1 à rev2
2. hg qgoto qbase # on applique le premier patch
3. hg qfold `hg qunapplied` # on combine tout les patchs non appliqués au dépôt, l'avantage c'est que tout les messages de commits sont concaténés
4. hg qfinish qbase # on repasse la gestion des changesets à mercurial
MQ est un peu le couteau suisse de mercurial (ça fait partie partie des outils à connaitre), il permet la gestion avancées de patchs comme Quilt, l'édition de l'historique, etc ... La différence avec la méthode précédente est qu'il n'y a rien qui traine dans le dépôt.
http://mercurial.selenic.com/wiki/MqExtension

c) histedit
Une extension non inclus en standard dédié à l'édition de l'historique (à la manière de git rebase --interactive). Je n'ai jamais utilisé cette extension celà dit, donc je me contenterais de signaler son existence.
http://mercurial.selenic.com/wiki/HisteditExtension

> Cependant, des développeurs de VLC avec le soutien de la FSF demande, à raison, à Apple de supprimer VLC de l'AppStore pour violation de la license GPL.

Et quelques lignes plus bas:
> Je demande solennellement aux développeurs VLC d'abandonner tout effort sur la plateforme iOS et de se concentrer sur les plateformes ouvertes non privatrice.

La communauté VLC se déchire ou quoi ?

> Tu veux que je te trouve le fil du forum où le développeur du radeonhd explique qu'on s'est fait niqué par red hat + ati qui ont joué contre suse + amd et où le dévelopeur red hat vient se foutre de sa gueule quand il dit comme toi qu'ils ont réutilisé son code ?

chiche.
Évidemment, il y a eu des conflits entre les développeurs Radeon et RadeonHD (entre autre pour le support des chipsets R500), mais ça c'est réglé depuis. De plus, AMD a certes sponsorisé le travail de Novell sur RadeonHD, mais ils ont également soutenu le développement de Radeon en embauchant Alex Deucher, contributeur de longue date du pilote radeon.

> Tu as vu des release de specs de cartes ati depuis comme à l'époque?
Cet été, Alex Deucher a mis à jour certaines documentations
http://www.x.org/docs/AMD/

Ça n'a pas empêché Red Hat de détacher quelques employés (par ex. Ray Strode) pour travailler sur Wayland. Red Hat encourage les employés à développer des projets personnels (comme beaucoup de boites innovantes d'ailleurs) et n'hésite pas à investir dessus si ça se révèle intéressant.

> Exactement, pourquoi continuer à dire que c'est la raison?
C'est quelle partie que tu n'as pas compris ? Il a fallu presque une décennie pour que la communauté libre apprenne à faire confiance à Sun (la libération du code de Star Office date de 2000 et à l'époque les suites bureautiques libres ne couraient pas les rues, KOffice et Abiword n'en était qu'à leurs prémisses).

> Montre moi des projets upstream de red hat où red hat contribue énormément et où le projet est controlé par un compétiteur commercial?
Xen (Citrix), go-oo (Novell), OpenJDK (Sun/Oracle), Btrfs (Oracle), Upstart (Canonical) pour te citer des projets controlé par un compétiteur direct. La quasi-totalité des projets libres maintenus par Red Hat ont un développement ouvert et Red Hat encourage ces employés à pousser leur travail upstream (ie: PackageKit ou AIGLX), ils libérent même certains employés de leurs obligations professionnelles pour des projets considérés comme non stratégiques (ogg Theora, GNOME Color Manager récemment).
À ce niveau-là, Red Hat n'a guère de leçons à recevoir de Canonical.

> Sinon comme exemple qui a fait mal au libre, le dévelopement du driver ati contre le driver radeonhd.
Je vois pas le rapport, à part le fait que RH emploie le mainteneur principal de Radeon. Le pilote radeon existait bien avant qu'AMD lache sa doc et ils ont choisi de redévelopper un nouveau pilote avec l'aide de Novell. Il n'a jamais été prévu que RadeonHD supporte les anciens chipsets et celui-ci n'a jamais été complet. Sinon, les mainteneurs des deux pilotes ont toujours collaborés ensemble, Fedora a même distribué RadeonHD et l'a intégré à ces journées de tests.

> Et c'est pas parce qu'elles font une fondation en front end, que je ne les voie plus comme une entité commerciale, que ce soit canonical/ubuntu ou red hat/fedora

Ni Canonical, ni Red Hat ne sont des bisounours, on ne doit les juger que sur leurs actes.
En revanche, Ubuntu et Fedora n'ont pas du tout le même mode de fonctionnement, Ubuntu est une distribution 100% contrôlé par une entité commerciale (ils ont même réussi à appeller conseil communautaire, un organe où tout les membres sont nommés par Canonical !), Fedora une distribution semi-communautaire dont la direction technique est communautaire (tout les membres du fesco sont élus par les contributeurs), RH nomme un Project Leader qui sert essentiellement de trésorier et de répresentant et la moitié du Project Board (gère l'aspect légal).

> En fait, au bout du compte, je pense que ce qu'on dit des distros, qu'elles doivent contribuer upstream est vrai, mais que ça s'applique aussi aux contributeurs.
C'est justement un point important du partenariat entre Red Hat et la communauté Fedora originelle. Un maximum doit être fait en upstream et de la façon la plus transparente possible.
Certes, ce n'est pas une obligation légale, mais ça fait partie de l'éthique tacite qui régit la communauté libre. C'est la principale critique portée à Canonical, et c'est également la moins bien comprise par la communauté Ubuntu qui n'est souvent pas familière avec cette façon de faire. Forcément, comme on ne se comprends pas, ça génére des tensions.