ymorin a écrit 498 commentaires

Hadœpi, comment fait-elle pour lire notre courrier sans être anticonstitutionnelle ?

Ou as-tu vu que HADOPI lisait des mails ?

Ce qui suit est une estimation très grossière et approximative de ce qui pourrait se passer. Il est très probable que le processus soit plus complexe, voire même totalement différent...

HADOPI délègue à un prestataire, TMG, le relevé d'adresse IP qui s'enregistre auprès d'un tracker torrent (ou l'équivalent e-mule, etc...) pour demander, ou proposer, un bout de fichier.

En gros, ça se passe comme ça, chez TMG :

1. TMG écume les moteurs de recherche de torrents, voire même publie des torrents auprès de ces moteurs
2. ils s'annoncent, auprès d'un ou plusieurs trackers, comme détenant les bouts de fichiers identifiés dans les torrents listés en 1.
3. un internaute cherche un fichier sur un moteur de torrent, et tombe malencontreusement sur un des torrents du 1. et joint un des trackers du 2.
4. bittorrent demande à ce tracker la liste des pairs contenant un des fichiers annoncés par TMG, et du coup vas essayer de récupérer ce fichier chez TMG.
5. comme le transfert est de pair à pair, TMG connait l'adresse IP du demandeur de ce bout de fichier à une certaine date

Un autre scénario, avec la même premie étape :

1. un internaute possède et publie auprès d'un ou plusieurs des trackers du 1. un des fichiers surveillés par TMG
2. TMG demande à un tracker la liste des pairs détenant les bouts de ce fichier
3. le tracker envoie à TMG les pairs détennant ce fichier, dont notre malheureux internaute
4. TMG demande directement à cette IP de lui fournir le fichier, et le reçoit
5. TMG connait maintenant une adresse IP qui fournit ce fichier à une certaine date

Rincez, essorez, et recommencez...

Ainsi, TMG construit deux bases de données, horodatées (je ne sais pas s'ils font la différence, ou si même ils n'envoient que l'une, l'autre, ou les deux) :

• une contenant les IP leechers (premnier scénario)
• une contenant les IP seeders (second scénario)

TMG transmet ces BDD à la HADOPI, qui émet des demandes d'identification auprès du FAI à qui appartient chaque IP.

Ensuite, un simple 'sort -r' sur le résultat leur donne les noms des personnes dont la ou les IPs ont été le plus souvent observées par TMG.

Ainsi, jamais les e-mails, par leur existence et/ou leurs contenus, d'un internaute ne servent à identifier un contrevenant. Si cela était le cas, alors oui, la HADOPI serait plus que bancale, et très facilement opposable.

Maintenant, si tu as des infos supplémentaires, je suis preneur ! :-)

Hop,
Moi.

je synchronise avec unison

Alors là, tu cherches les ennuis ! :-)

Je ne sais vraiment pas comment Hg se comporte dans ce cas (je ne connais pas non plus unison) :

PC1:
$ hg clone URL/prj; cd prj
$ vi file-1 # Modifs bla-bla
$ hg ci file-1 # pas de push -> URL

PC2:
$ hg clone URL/prj; cd prj
$ vi file-1 # Modifs titi-toto
$ hg ci file-1 # Pas de push -> URL
$ unison-sync --from=PC1 --to=PC2

Maintenant, dans quel état sont les méta-données de Hg ( le contenu de .hg/ ) ? Mystère et boule de gomme... :-/

Hop,
Moi.

Ce qui lui faudrait c'est une fonctionnalité ala git stash (le plus proche c'est l'extension shelve non-officielle)

Je préfère les MQs. Il est possible d'avoir plusieurs MQs dans un même clone, et on peut passer de l'une à l'autre.

Le problème, pour moi, n'est pas de différencier les différents 'flux' (stream) de développement, mais plutôt d'éviter de re-compiler le projet en passant d'un flux à l'autre.

Mais tout ça ne résout pas le shmilblick de l'OP.

il n'y a pas de branches locales dans Hg ?

Ça évite d'avoir à faire 'make distclean' avant de passer d'une branche à l'autre.

Comme ça, les deux clones sont toujours prêts.

Hop,
Moi.

Il n'y a pas assez d'infos pour suggérer la bonne piste...

J'utilise Hg depuis plus de deux ans, tous les jours, à lq fois en tant que développeur et en tant que mainteneur. Je n'ai jamais, jamais, observé un tel comportement...

Ceci dit, est-ce que ta procédure de génération peut toucher aux fichiers en confs? Par exemple, des Makefiles modifiés...

Je n'ose pas imaginer un time-drift. Plusieurs mois de time-drift, c'est cheulou, tu t'en serais (j'espère!) déjà rendu compte...

Il est possible aussi que tu ai 'oublié' de comitter ces changements. Si tu fais des commits explicites à chaque fois (eg. hg ci file1 file2) plutôt que global (hg ci .), alors au check-in global suivant, tu vas te traîner les reliquats non committés.

Pareil, si tu as oublié d'ajouter (hg add) ou d'enlever (hg delete ou hg forget), le prochain vas trouver ces reliquats.

Un cas concret qui m'est arrivé : j'ai deux clones, l'un pour quelques tests, et l'un de dev principal. Normalement, je ne commite rien dans le clone de test, je fais que des pull. Sauf qu'une fois, j'ai du reporter à la main quelques lignes de dev vers le test juste pour voir (quand on en est au 12ème patch MQ, on n'a pas forcement envie de finir la MQ pour récupérer dans un autre clone). Un peu plus tard, j'ai fait un quick-fix dans le clone de test, et comme il était bon, j'ai voulu le committer. Et là, c'est la cata... Je me retrouve avec ces p*t@!n5 de modifs dont je voulais pas...

Bref, un très bon outil comme Hg ne suffit pas a régler tous les problèmes. Il faut aussi un workflow correct, auquel on doit se tenir.

Par exemple, je ne fais quasi jamais de commit direct. J'utilise quasi-exclusivement une MQ, même pour un seul patch. Ça permet d'éviter tout erreur, et de corriger le tir si nécessaire. Sans compter le nombre de fois où un quick-fix en nécessite un autre ailleurs, et du coup, il faut deux commits; les MQs permettent de gérer ça vraiment très bien! Et viva las MQ!

Hop,
Moi.

301: moved permanently
Location: https://linuxfr.org/forums/linuxsuse/posts/pour-alien-youtube-dl-et-mixxx

[...] c'était à cause du Hub...

En effet, ce genre de problèmes est principalement lié à une connectique défaillante.

Pour exemples :

• un câble trop long et/ou mal blindé
• une fiche un peu lâche rt une clé un peu lourde qui tord la prise USB
• un hub mal alimenté
• clé et/ou hub pas réellement conformes
• un coktail de tout ça...

J'ai rencontré chaque situation au moins une fois, parfois plusieurs. Essaie de supprimer au maximum les intermédiaires : pas de câble, pas de hub, directement en sortie du PC.

Hop,
Moi.

dès qu'il y a des sous à se faire (ici avec Android) on se bouge les fesses. [...] c'est un peu dommage.

Au contraire, je trouve cela tres bien. Ca prouve que le logiciel libre peut etre une source de revenus, directs on indirects. Dans ce cas, c'est de l'indirect, puisque ce sera la vente de chipsets qui raportera a AMD.

Un des principaux points que j'aborde lorsque je presente ou defend le logiciel (ou autre) libre, c'est la difference entre liberte et gratuite. Il ne faut pas confondre.

Hop,
Moi.

Voici, pour ce qu'elle vaut, mon analyse de cette phrase mystère :

• L'expression And so implique une conséquence. On peut la traduire par donc, du coup, ou plus familièrement par Bon, bin.

• I'm off signifie un départ. Du style J'y vais, ou plus familièrement j'me barre, j'me casse.

• S'mores a été plus que largement expliqué dans les précédents commentaires.

• Dans le contexte de cette phrase, Linus semble avoir été blasé par l'absence de changement significatif dans cette release.

• La phrase me semble être de formulation plutôt familière.

Donc, je proposerai un truc du genre :

Bon, bin, m'en vais m'faire des s'mores, moi...

Hop,
Moi.

Bon, il n'y a pas assez d'infos pour resoudre le probleme.

Ceci dit, quelques pistes :

• il est deconseille de compiler dans un sous-repertoire des sources, il vaut mieux remonter d'un cran :

ls -1
gcc-4.6.1
mkdir build-gcc
cd build-gcc
../gcc-4.6.1/configure --bla-bla...

• ensuite, tu peux voir plus d'explications sur les erreurs en allant dans le repertoire incrimine, et en regardant le fichier 'config.log':

cd libquadmath
less config.log

• dernier petit point : newlib-1.9.0 a maintenant plus de 10 ans (sortie en fevrier 2001) ! Alors que la 1.18.0 a 1.5 ans, et la 1.19.0 a 7 mois.

Generer une chaine de compilation croisee n'est pas de tout repos, crois-en ma (tres) grand experience. Si c'est ta premiere chaine de compilation croisee, je te conseille fortement d'utiliser un outil qui automatise tout ca. Ensuite, tu peux regarder ce que cet outil fait, dans quel ordre il le fait, avec quelles options, et ensuite essayer de reproduire 'a-la-main'.

Mais franchement, pour que les devs de gcc et (surtout) glibc disent (en substance) :

Ne compilez pas vous-meme glibc, c'est trop complique; utilisez celle de votre distrib.

( Je ne retrouve pas le pointeur, mais c'est encore du grand Ulrich... )

Meme si tu utilises newlib, cette remarque reste valide.

A noter, avec crosstool-NG, j'ai genere une chaine de compilation croisee pour 'arm-cortex_a9-elf' sans souci. La difference avec ta config, c'est just binutils-2.21 et newlib-1.18.0. J'ai passe 5 minutes dans le menu de configuration, et environ 10 minutes de compilation (mais ma machine est tres rapide). Sur une machine plus modeste, compte environ 20-30 minutes. Je peux te fournir le fichier de config si tu veux. Viens nous rejoindre sur IRC et la liste de diffucsion ! ;-)

Hop,
Moi.

c'est un cross-compilateur Linux vers ARM Cortex-A9.

Ce n'est pas suffisant comme infos.

Premièrement, 'Linux' c'est l'OS ; il tourne sur plusieurs architectures. Donc on ne sait pas sur quelle type de machine tu veux compiler. Est-ce que tu veux compiler sur un x86 vers ARM, ou d'un MIPS vers un ARM? Ou d'un PowerPC vers un ARM?

Ensuite, 'ARM' c'est une architecture ; on peut y faire tourner plusieurs OS, voire pas du tout (eg. bootloader). Est-ce que tu veux y faire tourner un Windows CE (TM)? Un Linux ? Ou rien de tout ca, juste du bare-metal ?

Par exemple, dire :

C'est un compilateur qui :

• est généré sur mon PC x86_64 sous OS Linux
• s'éxecute sur mon PC x86_64 sous OS Linux
• génère du code ARM sous OS Linux

est déjà plus parlant. ;-)

Hop,
Moi.

[...] la génération de chaînes de compilation, croisée, native, canadienne et cross-native.

Ah, déjà, un petit aperçu de ce que ca donne en anglais :
How is a toolchain constructed

D'après le sujet de ton message, il n'est pas très clair de savoir si tu veux générer :
* un compilateur croisé qui s'exécute sur ton PC, et cible de l'ARM;
* un compilateur natif qui s'exécute sur ARM, et génère de l'ARM.

Je te conseille de jeter un œil à crosstool-NG.

C'est un outil qui permet de générer des chaînes de cross-compilation. Tu précises les composants que tu veux utiliser, leurs versions, leurs options, et crosstool-NG télécharge, extrait, patch, configure, compile et installe le tout, avec les bonnes options, dans le bon ordre. Pour info, il y a des 'samples', dont un sait deja générer une chaîne de compilation croisée pour ARM Cortex-A8 (passer à du A9 est trivial).

Et puisque j'en suis le mainteneur, je ne peux qu'en dire du bien! ;-) Il y a sur le site toutes les infos pour commencer, et nous contacter (liste de diffusion, canal IRC).

Hop,
Moi.

PS. Je me disais qu'un jour j'allais faire un petit article (journal ou dépêche) qui rentre dans les détails de la génération de chaînes de compilation, croisée, native, canadienne et cross-native. Je vais voir à libérer quelques heures pour ca s'il y a de l'intérêt...

Il n'as pas de prénom ?

Il est absurde de créer une fonction pour une portion de code qu'on n'utilisera qu'une fois.

Permet moi de m'inscrire en faux. Meme pour du code lineaire, l'utilisation de fonctions est parfois tres interessant.

Exemple:

void configure( void ) {
  /* 125 lignes de code pour configurer le bouzin */
}
void utilise( void ) {
  /* 200 lignes pour utiliser le bouzin */
}
void libere( void ) {
  /* 80 lignes pour liberer le bouzin */
}

int tout_le_boulot( void ) {
  configure();
  utilise();
  libere();
}

C'est tout de meme plus lisible qu'une fonctions avec 305 lignes de code.

Ensuite, tu utilises des prototypes pour les 3 sous-fonctions, tu mets leurs corps en bas, et tout de suite, la structure macroscopique du programme apparait : en fait, tu configures, tu utilises et tu liberes le bouzin. Ca devient lumineux ! ;-)

Ensuite, que ces trois fonctions soient compliquees, c'est pas grave, l'idee generale est la, visible du premier coup d'oeil.

Maintenant, si tu veux optimiser, et eviter trois appels de fonction (qui seront de toute facon invisibles par rapport au temps necessaire a executer le reste du code), tu declare tes fonction inline, et/ou static.. Et tout bon compilateur qui se respecte saura optimiser ca sans soucis.

Bien entendu, dans l'evolution n+27 de ton logiciel (que ton client te demanderas, style c'est juste une evolution mineure ! ;-] ), tu seras bien content d'avoir factorise tout ca, parce que tu auras non plus un, ni meme deux, mais 42 bouzins a configurer, utiliser plusieurs fois, et ensuite liberer !

Hop,
Moi.

PS. oui, je sais : les accents... J'ai juste oublier de reconfigurer compose sur la nouvelle becane... M'en vais faire ca de suite...

le nombre de caractères limités [...] c'était pour s'adapter à des terminaux qui n'affichaient pas en retour la commande tapé[e]

Non, non. La vraie raison, c'est que les gros geeks barbus aux cheveux longs étaient des grosses faignasses. Moins y'avait de touches à taper, mieux ils se portaient...

Donc, tant que le mot restait reconnaissable (eg. usr -> user, etc -> editable text files, bin -> binaries, lib -> libraries...), pas de soucis, on raccourcissait.

Et pour tous ces répertoires/fichiers souvent modifiés (à l'époque, pas de DHCP, de DNS tel qu'on le connait, pas d'auto-completion...), c'était plus rapide à taper. Et les modifier était réservé à ces gros geeks bouffeurs de pizzas, et souvent ils en étaient les seuls utilisateurs. Alors, faire un truc compréhensible par le commun des mortels, pensez-vous...

Il y avait aussi la propension toute naturelle chez les mêmes geeks poilus d'utiliser un langage à eux, leur jargon. Et dans ce jargon, les voyelles étaient souvent éludées. Pas toujours, juste souvent. Il fallait quand même que le mot reste reconnaissable...

Et surtout, les terminaux était petits, donc plus les noms étaient courts, plus les listings étaient compacts, plus on pouvait en mettre à l'écran. D'où le nom de ls : list short.

Hop,
Moi, barbu aux cheveux longs, bouffeur de pizzas. Mais pas gros ni trop poilu ! ;-)

Oh, et en parlant de jargon.

Salaud de vieux !
Faudrait tous vous noyer dès la naissance...

Alors là, j'ai ri ! Merci ! ;-)

Hop,
Moi.

Aller, un indice : 4.6.4

Hop,
Moi.

on ne retire pas un copyright "comme ça" sans accord de son auteur.

Copyright != license

Bon, en me relisant une fois de plus, je m'aperçois que je n'ai pas dit ce que je voulais dire... Pfff, saloperie d'heure tardive...

Bref, le copyright, c'est l'identification du ou des auteurs. Ne pas le mentionner, c'est de la contrefaçon. Un peu comme si un écrivain repompait tout ou partie d'une autre œuvre dans une partie ou la totalité de son œuvre. Bref, comme on le sait tous, C'est Pas Bien (TM).

D'un autre côté, la license, c'est ce que le ou les auteurs autorise à faire de leur œuvre. Encore une fois, si je ne m'abuse, ne pas respecter les termes de la license expose à des poursuites en contrefaçon. Et encore une fois, C'est Pas Bien (TM).

Donc, résumons:

• copyright <-> identification
• license <-> droits d'utilisation

Voila. ;-)

/me vas s'coucher...

Hop,
Moi.

on ne retire pas un copyright "comme ça" sans accord de son auteur.

Tout à fait. Mais il y a confusion, ici.

Copyright != license

Tu dois garder le copyright, c'est une disposition légale dans à peu prés tous les pays auxquels je pense. C'est le respect du droit d'auteur. Si tu ne le fais pas, tu t'exposes à des poursuites en contrefaçon (et pas pour vol ! ;-) ).

Par contre, la license BSD autorise l'inclusion du code dans à peu prés n'importe quoi, y compris du code GPL. Donc, il y a propagation (et non pas contamination, beurk quel horrible mot...) de la GPL vers le code BSD, lorsque celui-ci est lié à du code GPL. Et donc, dans ce cas, les termes de la GPL s'appliquent de plein droit, car l'ensemble est considéré comme un travail dérivé du code GPL.

Là, la force de chacune des deux licenses est mise en application. D'une part, la GPL oblige la redistribution du code conforme lorsque des binaires sont fournis; d'autre part, la BSD autorise l'intégration du code dans tout et n'importe quoi, y compris du GPL.

Si un auteur de code ( aka. développeur ) place son œuvre sous license BSD, c'est consciemment qu'il le fait ( ou alors il ne comprends rien, et il devrait consulter un avocat et/ou juriste ( coucou les amis ! ;-] ) ). De fait, il accepte toutes les conséquences qui découlent du respect de la license.

Alors, oui, bien sûr, on peut s'offusquer de détourner l'esprit de la license en y ajoutant des restrictions et/ou libertés ( selon le côté de la barrière où l'on se trouve ), mais la lettre ( et même, oserai-je, l'esprit ) de la license BSD est respectée tant que le nom du/des auteurs est mentionné, ainsi que le texte original de la license BSD.

Seul, le code sous license BSD le reste, même s'il est distribué dans le but de générer un binaire contenant du code GPL. Dés que le binaire est généré, alors, et seulement alors, les clauses de la GPL se propagent, et obligent à fournir le code sous license BSD.

ARM, c'est un coeur CPU [...]. Le coeur étant le même [...]

Oui, mais pas tout à fait ... ;-) Il faut savoir que l'éco-système ARM est très fragmenté.

Déjà, ARM, c'est une famille, à l'instar de x86. Par exemple, le pentium a plus d'instructions que le i386. C'est pareil pour la dernière génération (armv7) qui offre plus d'instructions que les anciennes générations (essentiellement armv4 et armv5).

En parallèle, le jeu d'instructions peut être étendu avec des extensions :
* Jazelle, qui permet d'exécuter du code Java quasi nativement (un genre d'implémentation light d'une JVM);
* Thumb et Thumb2 qui permettent une densité de code plus grande, au détriment ( mais pas toujours ! ) de la vitesse d'exécution;
* NEON, qui est une espèce de FPU offrant un peu de SIMD;
* VFP, VFPv2, FPA, Maverick (etc...) qui sont des FPU incompatibles entre elles, respectant pour certaines IEEE-754, partiellement pour d'autres, voire carrément pas pour d'autres.

Toutes ces extensions ne sont pas obligatoires pour qualifier de 'ARM' un CPU ARM. De plus, ARM11 va par exemple dire que Jazelle et Thumb2 sont obligatoires ( par exemple, hein ! ), alors que ARM9 non. C'est surtout visible dans le différentes familles de Cortex (R, A et M).

Porter du code d'un ARM à un autre est certes plus simple que de passer de x86 à ARM. La plupart du temps. Parce que, passer d'un Cortex-A8 (armv7, arm+thumb+neon+jazelle) à un Cortex M3 (uniquement Thumb2), c'est pas facile...

Obligatory Wikipedia link

Alors, dire que "le cœur est le même", c'est, au sens strict, pas vrai. ;-)

Hop,
Moi.

Et comme on ne peut plus te pertinenter: +1 !
Aller, encore un p'tit avant d'aller se coucher... :-)
Vais pas être frais, moi, demain...

Hop,
Moi.

Et le jour où l'on créé une nouvelle famille de CPU [...], il faudra redescendre d'un niveau.

Ou faire de la compilation croisée.

Pour une nouvelle architecture, on prend un compilateur existant (eg. gcc), on écrit un 'backend' pour cette nouvelle architecture, on génère un compilateur croisé.

Ce compilateur croisé génère du code pour la nouvelle architecture, et avec ce compilateur, on cross-compile le compilateur pour obtenir un compilateur natif sur la nouvelle architecture.

C'est le dernier 2.4 qui est devenu 2.6 (puisque le dernier 2.5 était devenu 2.4).

Je crois que c'est le dernier 2.5 qui est devenu le 2.6. La branche impaire servait de branche de développement pour la branche paire suivante. Voir notamment :

• UNIX history
• UNIX history - PDF

Hop,
moi.

à cause de Microsoft Office, pour les macros

wtf???

Je ne sais pas si cette assertion est vraie ou non. Cependant, il serait envisageable qu'un interpréteur de macros génère des datas qui soient en fait des opcodes x86, qu'il exécute ensuite. Ca nécessite des pages W, pour y mettre les opcodes, et X pour exécuter ces opcodes. Un espèce de JIT, en gros.

Attention, je n'ai pas dit que c'est ce que l'interpréteur de macros MSOffice faisait.

Hop,
Moi.