Déjà, juste pour clarifier car je commence à douter, est-ce que tu préfères comme moi la législation française sur les armes à feu, plutôt que celle des Etats-Unis ? Et oui, je fais la distinction entre armes à feu et couteau.
Mon hypothèse est que l'usage de copilot impliquerait trop souvent de devoir respecter la licence de ce qu'il a ingéré (tout comme la possession d'une arme à feu implique trop souvent de tuer, ce qui n'est pas le cas du couteau). Puisque tu n'es pas d'accord avec cette hypothèse (je parle bien de celle sur copilot), soit tu ignores ce que j'ai écrit à partir de là, soit tu pars du principe que l'hypothèse est valable. Sinon, tu mélanges tout et tu me prêtes des idées que je n'ai pas.
Et la GPL, ou le libre en général, ne fait aucune différence entre quelque chose entre un individu privé et un "grand méchant", et c'est ça qui est bien dans le libre : ne pas dépendre de ton petit goût de vouloir faire cette différence.
Je ne vois pas du tout où j'ai pu laisser penser ça.
Si je te comprends bien, tu es un libriste qui critique les licences copyleft. A partir de là évidemment, le jugement qui a été rendu est parfait.
Au passage, je comprend donc que tu adorerais interdire les couteaux de cuisine (on condamne une mauvaise utilisation de la chose mais pas une autre utilisation). Non merci.
N'importe quoi.
Bon, je pensais l'exemple assez évident.
Au lieu de me prêter de telles idées, demande-moi plutôt de clarifier. (J'ai un peu détaillé dans ma réponse ci-dessus.)
Même chose sur la GPL. Ca ne me dérange évidemment pas que quiconque fasse n'importe quel usage privé d'un code que j'ai publié en GPL. Quand j'écris « projets non-GPL », je fais référence à quelque chose de vendu/publié.
Etant donné que les LLM ne comprennent pas ce qu'ils font, dans le sens où c'est plutôt un modèle statistique, je suis curieux de les voir implémenter d'une manière différente quelque chose d'original qui n'existe que dans un seul logiciel.
On ne parle pas de déréguler les armes à feu
Euh oui, c'était juste une comparaison concernant la distinction outil/usage. Si l'usage qui en est fait est trop rarement souhaitable, on ne peut plus dédouaner l'outil.
La loi n'est pas magique, elle interdit certaines choses, et ce qui n'est pas interdit est autorisé.
J'ai hésité à le mentionner et j’admets que un jugement différent aurait peut-être demander d'interpréter la loi trop librement.
Les licences copyleft sont explicitement publiées pour autoriser l'étude du code,
C'est une mauvaise lecture de la GPL.
Le souhait (disons plutôt l'utopie) est qu'il n'existe que du logiciel à source ouvert (que l'on puisse étudier) et le copyleft n'est qu'un outil y arriver. Et enfin à terme, la suppression du droit d'auteur pour le code (pour l'art, c'est une autre histoire) et seulement à ce moment, Copilot me dérangerait un peu moins.
Il y a aussi les cas où pour éviter des violations de droit d'auteur, on prend une équipe pour écrire des specs à partir d'un code qu'on ne peut pas copier, et une autre pour réimplémenter à partir des spécifications.
la très grande majorité du code que j'ai écrit est trivial et qu'il ne pourrait pas raisonnablement être considéré comme une œuvre de l'esprit devant un tribunal
Dans le cas du code, c'est souvent trivial une fois qu'on l'a écrit, mais ça a quand même demandé un effort significatif. Le droit d'auteur permet de protéger cet effort.
…
En fait, tu restes sur l'idée qu'un LLM fonctionnent comme le cerveau d'un être humain. Mon propos initial est que si nous avions des capacités cognitives différentes, nos lois sur le droit d'auteur serait sans doute différentes, peut-être plus strictes, inexistantes, ou autre. Les lois sont seulement un outil pour équilibrer les rapports entre humains, et à mon avis les caractéristiques des LLM sont telles qu'elles perturbent cela.
je maudis les LLM
Arg, je n'invitais pas à développer ce hors-sujet ici, par manque de temps. Ai-je besoin de rappeler tous les inconvénients de l'IA et surtout des LLM ?
Je serais intéressé de savoir si c'est parce que tu penses que leurs résultats sont médiocres ou inutiles, ou inversement parce que tu te sens humilié en tant qu'être humain par l'existence d'algorithmes capables de faire mieux que toi ce que tu pensais maitriser.
Je suis surtout persuadé que la plupart des IA ne vaudront jamais ce que ça coûte.
L'idée de détester les trucs nouveaux qu'on a du mal à comprendre et qui peuvent modifier l'équilibre de notre vie n'est pas nouvelle, elle est probablement aussi vieille que l'humanité. Mais j'imagine que tu es déja au courant que cette idée n'a jamais gagné; que les nouvelles générations vont s'approprier cet outil et réussir à faire des choses avec, et que tu finiras tes jours malheureux en ronchonnant que c'était mieux avant?
Je ne suis absolument pas comme ça.
Et je n'ai aucun problème à décharger l'humain de tâches ingrates par de l'automatisation fiable et économe.
Je trouve au contraire que cette décision n'a rien d'évident.
D'abord, elle ignore l'aspect quantitatif. Les lois ont été écrites pour les humains, selon ce qu'ils sont capables de faire, alors que les LLM ont la capacité d'ingérer des quantités de données sans commune mesure. Un peu comme si, sous prétexte qu'on peut citer ou inclure un extrait d'une oeuvre protégé (fair use), on serait libre de copier l'oeuvre entièrement. On ne peut pas se contenter de dire que les LLM "apprennent" de la même manière que nous.
Ça veut dire qu'il est tout à fait possible par exemple d'écrire un texte qui ne contient que des phrases tirées de livres déja publiés, sans que ça soit une contrefaçon.
Bien sûr. Mais je ne crois pas que les LLM se limitent à faire ça. S'il existe déjà un bout code de taille significative qui fait grosso modo ce que le développeur souhaite, je m'attend à ce qu'il soit repompé d'une manière qui ne serait pas autorisé normalement sans LLM.
prétendre que la sortie d'un LLM peut violer sa propriété intellectuelle me semble quasiment auto-contradictoire. Par définition, la propriété intellectuelle ne s'applique qu'aux oeuvres de l'esprit (que la jurisprudence considère comme uniquement humain, pas de copyright sur les dessins de chimpanzés etc). Or, les sorties d'une IA ne peuvent pas être protégées par le droit d'auteur, parce que justement elles ne sont pas des oeuvres de l'esprit
Ouais, ça c'est l'argument pour déréguler la possession une arme à feu en prétendant qu'un outil est innocent et qu'il faut se contenter de condamner une mauvaise utilisation.
Mais LLM ne sont rien d'autre qu'un outil de copiage sophistiqué dont on ignore la source. Même si l'utilisateur souhaite respecter les licences, il ne peut pas le faire.
J'ai l'impression que l'esprit des lois sur lesquelles les juges se sont basés n'a pas été respecté.
Je ne supporte pas le fait que du code publié en GPL finisse aussi facilement dans des projets non-GPL. Et je suis d'autant plus mécontent que je maudis les LLM.
Posté par lcld .
En réponse au journal Bug réseau chez Free.
Évalué à 2.
Dernière modification le 09 décembre 2018 à 14:49.
Je fais juste remarquer à l'auteur que son affirmation "Un FAI n'est pas censé regarder au-delà de la couche 3 (réseau)." est pour le moins naïve.
Je n'ai juste pas développé ce point. Ce n'est pas pour rien que je chiffre toutes mes communications, y compris en ayant installé stubby (DNS-over-TLS) sur mon serveur, auquel j'accède depuis n'importe où par un VPN.
Bien sûr, Free est maître de son réseau et peut faire ce qu'il veut. Pas vu, pas pris. Les services secrets peuvent aussi certainement s'incruster. Mais il y a toujours une différence entre supposer et avoir une preuve.
Ce je rapporte n'est pas non plus une preuve irréfutable de quelque chose que Free n'est pas censé faire. Mais même si un bug peut prendre des formes étonnantes, j'ai du mal à imaginer ce qui pourrait merder ici sans qu'il n'y ait à la base du code analysant la trame TCP.
systemd will no longer pass any environment from the kernel or initrd to system services. If you want to set an environment for all services, do so via the kernel command line systemd.setenv= assignment.
Et depuis la version 205:
systemd gained the new DefaultEnvironment= setting in /etc/systemd/system.conf to set environment variables for all services.
Par contre, si la valeur de ta variable peut changer à chaque démarrage, le plus simple est apparemment d'écrire une unité qui se lance suffisamment tôt et qui utilise la commande set-environment de systemctl.
Quelle distribution ? N'importe laquelle. Celle que tu préfères. Avec un matériel aussi récent, il faut toujours utiliser le noyau le plus récent donc il faudra installer toi-même le noyau. Surtout si tu veux patcher l'ACPI : http://gentoo-wiki.com/HOWTO_Fix_Common_ACPI_Problems
Cela est-il génant pour un pc portable (prob de surchauffe)?
Non, ce n'est pas gênant, mais tu perds des fonctionnalités, comme certaines touches, la lecture de l'état de la batterie, le contrôle des leds wlan/mail, etc.
Utilise plutôt l'option acpi=noirq pour les noyaux < 2.6.19
D'ailleurs, je recherche quelqu'un qui n'a pas le dernier BIOS (version 0802) installé. Si possible un vieux BIOS comme la version 0402, mais 0502 ou 0602 seraient pas mal.
* informations about Hachoir in CheeseShop: You can find there .egg file and .tar.gz file
Ok, ça saute pas aux yeux. On admet qu'il faille réorganiser un minimum le wiki.
2. not as root
Et l'option --help ??
$ python ez_setup.py --help
=>
$ mkdir -p /tmp/usr/lib/python2.4/site-packages
$ export PYTHONPATH=/tmp/usr/lib/python2.4/site-packages
$ python2.4 hachoir/ez_setup.py --prefix=/tmp/usr
$ /tmp/usr/bin/easy_install --prefix=/tmp/usr -U hachoir
et vala, c'est installé
3. quick_install
Bon ben euh... comme son nom l'indique : ... and dirty
Ca a d'autres avantages que celui de faire une install toute propre. Il a notamment été décidé d'utiliser la commande 'checkout' de subversion plutôt que 'export' pour télécharger hachoir :
* Il y a tout les données de svn (répertoire .svn) et en particulier des fichiers en lecture seule, ce qui explique le 'rm -rf'.
* C'est plutôt orienté beta-testeur : par exemple, si quelqu'un rapporte un bug sur un chan et si un dev peut corriger rapidement, il suffit de lui répondre 'svn up'.
* ... ou développeur en déplacement : ça permet de réinstaller rapidement une copie de travail et toutes les librairies rarement installées comme python-urwid.
Quant à svn, désolé, mais je considère qu'il faut aller de l'avant en info. Il faut bien que quelqu'un se dévoue pour utiliser un nouvel outil. Oh et puis de toute façon, comme ça a déjà été dit, svn est vraiment courant maintenant.
Tu as de la chance pour le .tar.gz, tu as échappé au .cpio.7z (oui, c'est que j'utilise personnellement) :D
Pour commencer, non, il n'y a pas encore d'interface graphique. Je sais qu'une interface console rebute de plus en plus de monde. C'est dommage, le mode texte a pourtant de nombreux avantages. Sachant que l'aide est quasiment absente, il faudrait que je détaille un peu.
Avant j'aimerais parler d'une des nouveautés d'Hachoir : le support du système de fichiers FAT. Euh... oops on est sur linuxfr.org... Oui, ça fait bizarre. D'ailleurs, ce format ne m'intéresse pas du tout. Mais à défaut d'être bien foutu, il a l'avantage d'être simple et de bien mettre en évidence les limitations d'Hachoir. Sans les améliorations apportées à l'API d'Hachoir, implémenter FAT aurait été presque impossible.
[1] Ce système de fichiers n'a pas une structure arborescente. Tout est à plat et pour atteindre un fichier en particulier, il faudrait presque tout parser et on finirait avec un liste de plusieurs miliers d'entrées. On ne peut plus dire qu'Hachoir reste paresseux ; on serait vite limité à des petits FS.
[2] Admettons qu'on atteigne le champ qui contient les données du fichier recherché. On peut vouloir hacher le contenu. C'était possible avec Hachoir 0.1. Voilà, la feature est de nouveau là, dans l'interface urwid.
[3] Oui mais... quel système de fichiers ne fragmente jamais ? Sûrement pas la FAT.
Hachoir 0.5 marque le début du support des containers.
J'appelle container tout format destiné à contenir des données dans un format quelconque. Les catégories les plus courantes sont :
- archives : C'est le cas le plus facile. Le contenu est en un seul morceau. (La compression est une toute autre histoire)
- systèmes de fichiers : Ca se corce. On fait souvent face à des contenus fragmentés.
- containers multimedia : Là, ça peut devenir un cauchemar. Il s'agit souvent d'un flux de paquets (un paquet pouvant être à son tour fragmenté ; avec 2 types de fragmentation, finir le parseur ogg va être un casse-tête) et le format ne peut pas se contenter d'un flux bêtement défragmenté : il peut avoir besoin de connaître le découpage.
Dans l'interface urwid, 2 raccourcis ont fait leur apparition :
1. La touche 'espace', utile pour les parseurs non terminés. Il considère le champ actuellement sélectionné comme un contenu ayant son propre format. Une nouvelle fenêtre est ouverte, Hachoir cherche un parseur approprié et commence un nouveau hachage. On peut l'utiliser n'importe où et même pour un fichier non fragmenté dans un FS. Actuellement, c'est le seulement moyen d'hacher :
- une partition si on a lancé hachoir sur un disque entier
- un fichier attaché à un fichier matroska
- ...
2. La touche 'f' qui, pour le moment, fonctionne uniquement pour le parseur FAT. Une fois que le début d'un fichier (fragmenté ou non) est sélectionné (il ne faut pas sélectionner le champ "data" mais le champ parent), une nouvelle fenêtre est ouverte et cette fois-ci, c'est tout le contenu défragmenté qui est haché.
Pour ceux qui seraient intéressés par le support des flux fragmentés, un bug sérieux affecte malheureusement la version 0.5. Je m'en suis aperçu quelques heures après que tout a été packagé. Il faudra alors appliquer le patch http://hachoir.org/changeset/726 (plutôt gruik d'ailleurs ; va falloir que je revois l'API) ou télécharger depuis le dépôt subversion.
Une autre nouveauté : le lien interne. Dans urwid, on suit un lien tout comme on développe/réduit un champ : avec la touche 'entrée'. Le lien permet de faciliter là navigation.
Pour l'instant, il y en a très peu : dans les parseurs Matroska et FAT uniquement.
Dans les fichiers Matroska, il existe une structure ('Cues') qui indexe certaines trames. En général, les trames clés d'un flux video. Il faut consulter plusieurs champs pour localiser la trame clé dans le fichier, et de toute façon, même si un seul champ suffisait, celui-ci ne serait pas forcément intelligible : indice de temps, ou position en octets par rapport à un endroit bien précis (et lire les specs pour le connaître), etc.
Dans le cas du système FAT, les liens permettent par exemple de naviguer entre les différents fragments d'un fichier.
Mais c'est surtout en suivant le lien dans une entrée de répertoire qu'on déclenche le hachage du fichier correspondant à cet entrée. Cela résoud [1]. On laisse des zones non hachées (padding) puis on hache ces zones à la demande.
On peut recompiler aussi son propre noyau. Il faut le support d'unionfs et cramfs dans le noyau je crois, mais des modules sont chargés également (je ne sais pas exactement comment cela fonctionne, en fait je n'ai pas cherché à savoir et j'ai utilisé le noyau fournit sur le site, c'était plus simple...).
En fait, le script suppose que les pilotes nécessaires pour lire un CD (ide-*, cdrom...) sont intégrés au noyau, ce qui n'est pas le cas sous Debian (qui laisse beaucoup de choses en modules). Donc oui, tel quel, faut soit recompiler son propre noyau soit utiliser celui fourni.
A propos des lecteurs CD SCSI, je retire ce que j'ai dit. J'ai lu
Data for LiveCD not found. Searching for livecd.sgn file, not found.
You are maybe using an unsupported boot device
(for example a CD-ROM connected to SCSI or PCMCIA interface)
sans réfléchir. A condition que les pilotes sont chargés (intégrés au noyau), je ne vois pas de raison pour que ça ne marche pas.
Après un rapide coup d'oeil, je dirais :
- Ca ne marche pas avec le noyau fourni par debian, pour un bête problème de modules.
- Création de liveusb peu pratique (même si ça peu se corriger facilement) : tel quel, il faut commencer par créer le livecd.
- Pas de support des lecteurs CD SCSI.
- Une livedistro est censé tourner sur n'importe quoi sans avoir trop de choses à faire au démarrage : quid du serveur X (si je prend le xorg.conf d'une machine (nvidia) pour le mettre sur une autre (ati), ça ne marche pas) ? Je n'ai pas vu la moindre fonctionnalité permettant de traiter cette aspect de la construction d'un livecd.
Alors s'il faut configurer certaines choses soi-même, j'ajouterais :
- Nécessité d'installer un système préalablement. Contrairement à mon outil qui ne modifie pas le moindre fichier du système source.
Mais j'admets que si j'avais connu ce projet, je m'en serais sans doute contenté, en y apportant quelques modifications. Maintenant, non.
car j'ai fait un live-cd avec, cela tourne très bien.
Posté par lcld .
En réponse au message Cramfs.
Évalué à 2.
J'aimerais charger en ram mon application : Firefox pour une plus grande rapidité
Tu es sûr que c'est plus rapide ou tu espères/crois ?
J'imagine que Linux garde tout ce qu'il peut en cache donc si tu as assez de RAM, il ne devrait pas y avoir de différence selon que tu copies ou non tout ta partition (à la limite, tu peux forcer une mise en cache au démarrage).
De plus je n'ai pas l'executable tar d'installer sur ma machine, est ce qu'il est obligatoire ou est ce qu'on peut se passer de lui si tu as une autre solution n'hésite pas...
(... et bunzip2)
Bah, c'était pour compresser et gagner de la place. Apparemment, tu en as assez (49Mo sur 64) donc tu peux aussi y aller à coup de 'cp -a'
Si tu peux te contenter de tout copier sauf certains répertoires (ex: /bin), la solution que j'ai donnée dans mon précédent post doit suffire, quitte à ajouter /usr (pour Firefox) à la liste /etc,/home...
Pour avoir _toute_ ta partition en RAM, j'aurais dit qu'il faut passer par un image de démarrage (initrd). Mais apparemment, dans ton cas, la méthode suivante devrait fonctionner :
* intégrer au noyau tous les pilotes nécessaires pour qu'il puisse monter / sans module et passer la bonne valeur pour l'option 'root'
* pas d'option initrd
* créer un script /sbin/preinit (exécutable) du genre :
#! /bin/sh
# ne pas oublier de créer le point de montage ( /mnt/ramdisk )
PATH=/usr/sbin:/sbin:/usr/bin:/bin
mount -t tmpfs -o mode=0755 tmpfs /mnt/ramdisk
cd /mnt/ramdisk
cp -ax / .
exec chroot . /sbin/init -i
* ajouter l'option init=/sbin/preinit
* (dans ce cas, plus besoin de faire quoique ce soit de spécial pour /etc, /home, etc)
Posté par lcld .
En réponse au message Cramfs.
Évalué à 2.
Faut croire qu'il y a une limite, et si on peut l'augmenter, je ne sais pas comment on fait.
Si j'ai bien compris ce que tu veux faire, ton système charge toute ta partition en mémoire vive : tu en as assez ?
Je demande car tu peux aussi utiliser un système à la KNOPPIX, cad avec un système de fichiers compressé en lecture seule. Ex. de systèmes de fichiers : cloop, squashfs, isofs (avec compression transparente)
Si tes besoins le permettent, il se peut que tu puisses te passer d'une image de démarrage (solution non testée) :
* intégrer au noyau tous les pilotes nécessaires pour qu'il puisse monter / sans module et passer la bonne valeur pour l'option 'root'
* pas d'option initrd
* créer un script /sbin/preinit (exécutable) du genre :
#! /bin/sh
# rw.tar.bz2 contient etc, home, etc.
# ne pas oublier de créer le point de montage ( /mnt/ramdisk )
# et les liens symboliques suivants :
# /etc -> /mnt/ramdisk/etc
# /home -> /mnt/ramdisk/home
# ...
(export PATH=/usr/sbin:/sbin:/usr/bin:/bin
mount -t tmpfs -o mode=0755 tmpfs /mnt/ramdisk
cd /mnt/ramdisk
tar -xjf /rw.tar.bz2)
exec /sbin/init -i
* ajouter l'option init=/sbin/preinit
Avec une image de démarrage, même très petite, tu as beaucoup plus de libertés pour préparer /. Et puisque c'est pour de l'embarqué, il reste préférable d'intégrer au noyau tous les pilotes nécessaires pour monter /.
Avant de développer cette possibilité, ce serait mieux que tu décrives plus précisement ce que tu veux.
Au fait, tu pars de quelle distribution ? Quel quantité de RAM ? Quoi comme unité de stockage ?
Comment casser le mythe de rapidité de Fibonacci :-)
Je crois plutôt que le problème vient du compilateur C. Je ne sais pas si la norme le permet, mais le compilateur devrait être capable, si c'est possible, de transformer les algorithme récursifs les plus simples en algorithmes itératifs. Je pense notamment à la récursivité terminale.
De toute façon, ici, la meilleure solution au solution problème reste encore d'exprimer la suite en fonction de n plutôt qu'en fonction des termes précédents -> algo en O(1) (quoique ça dépende de l'implémentation de l'exponentielle...).
Et puis ces discours étaient les mêmes dans les années 90 entre l'asm et le C sur 68k/80x86 :-))) et le C a gagné, cas son niveau d'abstraction ;-) permet d'être plus productif que de l'asm pur.
La comparaison est mauvaise : la principale raison pour laquelle le C a gagné est que l'assembleur n'est pas portable et qu'un langage assembleur est censé avoir une durée de vie limitée.
Cela dit, il y a quand même un point qui me gêne. Comment justifier cette surenchère de couches alors qu'il y a de nombreuses tâches qui ne sont pas parallélisables (ou difficilement parallélisables) et que la puissance des coeurs CPU augmente de plus en plus lentement.
Par exemple : réactivité des IHM, compression de données, etc.
Je veux bien mettre la forme de côté, mais franchement, j'ai beau chercher, je ne vois pas comment on peut en arriver à poster un bout de code pareil.
Ne me dites pas que c'est le résultat auquel il est arrivé, ou le reste de son message aurait été complètement différent : il donne l'impression de l'avoir compilé alors pourquoi ne pas avoir _copié-collé_ ?
Vous vous rendez compte que vous avez pris la peine de répondre ceci :
"chainelu char[30]; il faut mettre le type avant le nom de variable: char chainelue[30];" ?
Comme vous voulez, mais je pense qu'il gagnera à mieux poser ses questions. Et ce n'est pas comme si c'était son premier post.
Ca n'a rien à voir avec le fait qu'il débute en C.
voir comment faire autrement si une solution plus simple existe et que je me fourvoye dans l'utilisation de C ?
Je comprends qu'il ne voulait pas forcément faire ça en C.
Si vous préférez que j'ignore ce genre de questions, dites-le.
Non, non, il n'y a pas de ';' puisqu'il définit tout de suite son constructeur.
L'erreur est... ah ben tu l'as corrigée sans faire attention. C'est :
Tableau ( int t[8] ) : tab(t) {}
et non pas :
Tableau ( int t[8] ) : tab=t {}
que ca scan les .txt et ne m'affiche QUE le texte situé entre le ? et le ?
Ahlala, cette foutue manie de poser des questions imprécises : tu ne dis pas ce que tu veux faire des '?'.
$ cat tst
------------------------------------------------
Titre : incident serveur
Com : Explique comme résoudre le probleme maj RF530
blablablablala
?
Ceci est l'explication pour résoudre le problème
blablablablablablablablblablablablablablablabl
?
------------------------------------------------
Titre : incident serveur
Com : Explique comme résoudre le probleme mAj RF530
blAblAblAblAlA
?
Ceci est l'explicAtion pour résoudre le problème
blAblAblAblAblAblAblAblblAblAblAblAblAblAblAbl
?
------------------------------------------------
$ sed '/^?$/,/^?$/!d;/^?$/d' tst
Ceci est l'explication pour résoudre le problème
blablablablablablablablblablablablablablablabl
Ceci est l'explicAtion pour résoudre le problème
blAblAblAblAblAblAblAblblAblAblAblAblAblAblAbl
[^] # Re: Clarification bienvenue
Posté par lcld . En réponse au lien Judge dismisses DMCA copyright claim in GitHub Copilot suit. Évalué à 0.
pas compris
Déjà, juste pour clarifier car je commence à douter, est-ce que tu préfères comme moi la législation française sur les armes à feu, plutôt que celle des Etats-Unis ? Et oui, je fais la distinction entre armes à feu et couteau.
Mon hypothèse est que l'usage de copilot impliquerait trop souvent de devoir respecter la licence de ce qu'il a ingéré (tout comme la possession d'une arme à feu implique trop souvent de tuer, ce qui n'est pas le cas du couteau). Puisque tu n'es pas d'accord avec cette hypothèse (je parle bien de celle sur copilot), soit tu ignores ce que j'ai écrit à partir de là, soit tu pars du principe que l'hypothèse est valable. Sinon, tu mélanges tout et tu me prêtes des idées que je n'ai pas.
Je ne vois pas du tout où j'ai pu laisser penser ça.
Si je te comprends bien, tu es un libriste qui critique les licences copyleft. A partir de là évidemment, le jugement qui a été rendu est parfait.
[^] # Re: Clarification bienvenue
Posté par lcld . En réponse au lien Judge dismisses DMCA copyright claim in GitHub Copilot suit. Évalué à -1.
N'importe quoi.
Bon, je pensais l'exemple assez évident.
Au lieu de me prêter de telles idées, demande-moi plutôt de clarifier. (J'ai un peu détaillé dans ma réponse ci-dessus.)
Même chose sur la GPL. Ca ne me dérange évidemment pas que quiconque fasse n'importe quel usage privé d'un code que j'ai publié en GPL. Quand j'écris « projets non-GPL », je fais référence à quelque chose de vendu/publié.
[^] # Re: Clarification bienvenue
Posté par lcld . En réponse au lien Judge dismisses DMCA copyright claim in GitHub Copilot suit. Évalué à 1.
Etant donné que les LLM ne comprennent pas ce qu'ils font, dans le sens où c'est plutôt un modèle statistique, je suis curieux de les voir implémenter d'une manière différente quelque chose d'original qui n'existe que dans un seul logiciel.
Euh oui, c'était juste une comparaison concernant la distinction outil/usage. Si l'usage qui en est fait est trop rarement souhaitable, on ne peut plus dédouaner l'outil.
J'ai hésité à le mentionner et j’admets que un jugement différent aurait peut-être demander d'interpréter la loi trop librement.
C'est une mauvaise lecture de la GPL.
Le souhait (disons plutôt l'utopie) est qu'il n'existe que du logiciel à source ouvert (que l'on puisse étudier) et le copyleft n'est qu'un outil y arriver. Et enfin à terme, la suppression du droit d'auteur pour le code (pour l'art, c'est une autre histoire) et seulement à ce moment, Copilot me dérangerait un peu moins.
Il y a aussi les cas où pour éviter des violations de droit d'auteur, on prend une équipe pour écrire des specs à partir d'un code qu'on ne peut pas copier, et une autre pour réimplémenter à partir des spécifications.
Dans le cas du code, c'est souvent trivial une fois qu'on l'a écrit, mais ça a quand même demandé un effort significatif. Le droit d'auteur permet de protéger cet effort.
En fait, tu restes sur l'idée qu'un LLM fonctionnent comme le cerveau d'un être humain. Mon propos initial est que si nous avions des capacités cognitives différentes, nos lois sur le droit d'auteur serait sans doute différentes, peut-être plus strictes, inexistantes, ou autre. Les lois sont seulement un outil pour équilibrer les rapports entre humains, et à mon avis les caractéristiques des LLM sont telles qu'elles perturbent cela.
Arg, je n'invitais pas à développer ce hors-sujet ici, par manque de temps. Ai-je besoin de rappeler tous les inconvénients de l'IA et surtout des LLM ?
Je suis surtout persuadé que la plupart des IA ne vaudront jamais ce que ça coûte.
Je ne suis absolument pas comme ça.
Et je n'ai aucun problème à décharger l'humain de tâches ingrates par de l'automatisation fiable et économe.
[^] # Re: Clarification bienvenue
Posté par lcld . En réponse au lien Judge dismisses DMCA copyright claim in GitHub Copilot suit. Évalué à -2.
Je trouve au contraire que cette décision n'a rien d'évident.
D'abord, elle ignore l'aspect quantitatif. Les lois ont été écrites pour les humains, selon ce qu'ils sont capables de faire, alors que les LLM ont la capacité d'ingérer des quantités de données sans commune mesure. Un peu comme si, sous prétexte qu'on peut citer ou inclure un extrait d'une oeuvre protégé (fair use), on serait libre de copier l'oeuvre entièrement. On ne peut pas se contenter de dire que les LLM "apprennent" de la même manière que nous.
Bien sûr. Mais je ne crois pas que les LLM se limitent à faire ça. S'il existe déjà un bout code de taille significative qui fait grosso modo ce que le développeur souhaite, je m'attend à ce qu'il soit repompé d'une manière qui ne serait pas autorisé normalement sans LLM.
Ouais, ça c'est l'argument pour déréguler la possession une arme à feu en prétendant qu'un outil est innocent et qu'il faut se contenter de condamner une mauvaise utilisation.
Mais LLM ne sont rien d'autre qu'un outil de copiage sophistiqué dont on ignore la source. Même si l'utilisateur souhaite respecter les licences, il ne peut pas le faire.
J'ai l'impression que l'esprit des lois sur lesquelles les juges se sont basés n'a pas été respecté.
Je ne supporte pas le fait que du code publié en GPL finisse aussi facilement dans des projets non-GPL. Et je suis d'autant plus mécontent que je maudis les LLM.
[^] # Re: Critères d'achat
Posté par lcld . En réponse au journal Une histoire de smartphones. Évalué à 3.
C'est possible si le téléphone est rooté. Il faut juste avoir pensé à récupérer la clé de chiffrement. https://forum.xda-developers.com/android/general/how-to-decrypt-split-adopted-storage-t3383666
[^] # Re: et donc ?
Posté par lcld . En réponse à la dépêche Firefox 77. Évalué à 2.
https://github.com/aris-t2/customcssforfx
Je l'utilise ainsi (extrait du fichier
chrome/userChrome.css
de mon profil Firefox):(
...
pointant vers une copie de travail de customcssforfx)(cf README de customcssforfx pour activer
chrome/userChrome.css
si ce n'est pas déjà fait)Par contre, je suis encore sous FF75 donc je garantis pas que ça marche encore aussi bien sous FF77.
[^] # Re: La couche 3 ? Tu n'as pas tout compris !
Posté par lcld . En réponse au journal Bug réseau chez Free. Évalué à 2. Dernière modification le 09 décembre 2018 à 14:49.
Je n'ai juste pas développé ce point. Ce n'est pas pour rien que je chiffre toutes mes communications, y compris en ayant installé stubby (DNS-over-TLS) sur mon serveur, auquel j'accède depuis n'importe où par un VPN.
Bien sûr, Free est maître de son réseau et peut faire ce qu'il veut. Pas vu, pas pris. Les services secrets peuvent aussi certainement s'incruster. Mais il y a toujours une différence entre supposer et avoir une preuve.
Ce je rapporte n'est pas non plus une preuve irréfutable de quelque chose que Free n'est pas censé faire. Mais même si un bug peut prendre des formes étonnantes, j'ai du mal à imaginer ce qui pourrait merder ici sans qu'il n'y ait à la base du code analysant la trame TCP.
[^] # Re: Juste une question
Posté par lcld . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 5.
Depuis la version 207:
Et depuis la version 205:
Par contre, si la valeur de ta variable peut changer à chaque démarrage, le plus simple est apparemment d'écrire une unité qui se lance suffisamment tôt et qui utilise la commande
set-environment
desystemctl
.# "yahoo est ton ami" :p
Posté par lcld . En réponse au message ASUS A6T-AP014H. Évalué à 1.
Perso, j'ai un A6Tc-AP014H (carte graphique plus faible) : une requête sur A6Tc-AP014H renvoie http://jmuchemb.no-ip.com/~jm/trac/wiki/A6Tc-AP014H
Et il y a aussi les sites comme http://www.linux-on-laptops.com/
Quelle distribution ? N'importe laquelle. Celle que tu préfères. Avec un matériel aussi récent, il faut toujours utiliser le noyau le plus récent donc il faudra installer toi-même le noyau. Surtout si tu veux patcher l'ACPI : http://gentoo-wiki.com/HOWTO_Fix_Common_ACPI_Problems
Non, ce n'est pas gênant, mais tu perds des fonctionnalités, comme certaines touches, la lecture de l'état de la batterie, le contrôle des leds wlan/mail, etc.
Utilise plutôt l'option acpi=noirq pour les noyaux < 2.6.19
D'ailleurs, je recherche quelqu'un qui n'a pas le dernier BIOS (version 0802) installé. Si possible un vieux BIOS comme la version 0402, mais 0502 ou 0602 seraient pas mal.
# Oublie
Posté par lcld . En réponse au message subversion "svn co -N" puis chekout local. Évalué à 2.
Autrement dit, il n'y a pas de solution à ton problème, hormis, si c'est possible, celle de réorganiser le dépôt. J'ai eu le même souci avec Hachoir ( http://hachoir.org/ ) et finalement, c'est ce qu'on a fait :
http://www.mail-archive.com/hachoir%40lists.tuxfamily.org/ms(...)
http://www.mail-archive.com/hachoir%40lists.tuxfamily.org/ms(...)
voir aussi : http://subversion.tigris.org/servlets/ReadMsg?listName=users(...)
[^] # Re: Package
Posté par lcld . En réponse à la dépêche Hachoir, le couteau suisse qui découpe vos fichiers binaires. Évalué à 3.
1. .tar.gz
Je cite http://hachoir.org/wiki/HachoirYield : Ok, ça saute pas aux yeux. On admet qu'il faille réorganiser un minimum le wiki.
2. not as root
Et l'option --help ??
$ python ez_setup.py --help
=>
$ mkdir -p /tmp/usr/lib/python2.4/site-packages
$ export PYTHONPATH=/tmp/usr/lib/python2.4/site-packages
$ python2.4 hachoir/ez_setup.py --prefix=/tmp/usr
$ /tmp/usr/bin/easy_install --prefix=/tmp/usr -U hachoir
et vala, c'est installé
3. quick_install
Bon ben euh... comme son nom l'indique : ... and dirty
Ca a d'autres avantages que celui de faire une install toute propre. Il a notamment été décidé d'utiliser la commande 'checkout' de subversion plutôt que 'export' pour télécharger hachoir :
* Il y a tout les données de svn (répertoire .svn) et en particulier des fichiers en lecture seule, ce qui explique le 'rm -rf'.
* C'est plutôt orienté beta-testeur : par exemple, si quelqu'un rapporte un bug sur un chan et si un dev peut corriger rapidement, il suffit de lui répondre 'svn up'.
* ... ou développeur en déplacement : ça permet de réinstaller rapidement une copie de travail et toutes les librairies rarement installées comme python-urwid.
Quant à svn, désolé, mais je considère qu'il faut aller de l'avant en info. Il faut bien que quelqu'un se dévoue pour utiliser un nouvel outil. Oh et puis de toute façon, comme ça a déjà été dit, svn est vraiment courant maintenant.
Tu as de la chance pour le .tar.gz, tu as échappé au .cpio.7z (oui, c'est que j'utilise personnellement) :D
[^] # Re: problème sous Arch x86_64
Posté par lcld . En réponse à la dépêche Hachoir, le couteau suisse qui découpe vos fichiers binaires. Évalué à 5.
Au format diff : http://hachoir.org/changeset/727?format=diff
Ou télécharger depuis le dépôt subversion : svn co svn://hachoir.org/hachoir/hachoir/trunk hachoir
Si ça ne marche toujours pas, annule le commit 690 : http://hachoir.org/changeset/690
(attention à la récente réorganisation des fichiers sources)
# Compléments
Posté par lcld . En réponse à la dépêche Hachoir, le couteau suisse qui découpe vos fichiers binaires. Évalué à 10.
Avant j'aimerais parler d'une des nouveautés d'Hachoir : le support du système de fichiers FAT. Euh... oops on est sur linuxfr.org... Oui, ça fait bizarre. D'ailleurs, ce format ne m'intéresse pas du tout. Mais à défaut d'être bien foutu, il a l'avantage d'être simple et de bien mettre en évidence les limitations d'Hachoir. Sans les améliorations apportées à l'API d'Hachoir, implémenter FAT aurait été presque impossible.
[1] Ce système de fichiers n'a pas une structure arborescente. Tout est à plat et pour atteindre un fichier en particulier, il faudrait presque tout parser et on finirait avec un liste de plusieurs miliers d'entrées. On ne peut plus dire qu'Hachoir reste paresseux ; on serait vite limité à des petits FS.
[2] Admettons qu'on atteigne le champ qui contient les données du fichier recherché. On peut vouloir hacher le contenu. C'était possible avec Hachoir 0.1. Voilà, la feature est de nouveau là, dans l'interface urwid.
[3] Oui mais... quel système de fichiers ne fragmente jamais ? Sûrement pas la FAT.
Hachoir 0.5 marque le début du support des containers.
J'appelle container tout format destiné à contenir des données dans un format quelconque. Les catégories les plus courantes sont :
- archives : C'est le cas le plus facile. Le contenu est en un seul morceau. (La compression est une toute autre histoire)
- systèmes de fichiers : Ca se corce. On fait souvent face à des contenus fragmentés.
- containers multimedia : Là, ça peut devenir un cauchemar. Il s'agit souvent d'un flux de paquets (un paquet pouvant être à son tour fragmenté ; avec 2 types de fragmentation, finir le parseur ogg va être un casse-tête) et le format ne peut pas se contenter d'un flux bêtement défragmenté : il peut avoir besoin de connaître le découpage.
Dans l'interface urwid, 2 raccourcis ont fait leur apparition :
1. La touche 'espace', utile pour les parseurs non terminés. Il considère le champ actuellement sélectionné comme un contenu ayant son propre format. Une nouvelle fenêtre est ouverte, Hachoir cherche un parseur approprié et commence un nouveau hachage. On peut l'utiliser n'importe où et même pour un fichier non fragmenté dans un FS. Actuellement, c'est le seulement moyen d'hacher :
- une partition si on a lancé hachoir sur un disque entier
- un fichier attaché à un fichier matroska
- ...
2. La touche 'f' qui, pour le moment, fonctionne uniquement pour le parseur FAT. Une fois que le début d'un fichier (fragmenté ou non) est sélectionné (il ne faut pas sélectionner le champ "data" mais le champ parent), une nouvelle fenêtre est ouverte et cette fois-ci, c'est tout le contenu défragmenté qui est haché.
Pour ceux qui seraient intéressés par le support des flux fragmentés, un bug sérieux affecte malheureusement la version 0.5. Je m'en suis aperçu quelques heures après que tout a été packagé. Il faudra alors appliquer le patch http://hachoir.org/changeset/726 (plutôt gruik d'ailleurs ; va falloir que je revois l'API) ou télécharger depuis le dépôt subversion.
Une autre nouveauté : le lien interne. Dans urwid, on suit un lien tout comme on développe/réduit un champ : avec la touche 'entrée'. Le lien permet de faciliter là navigation.
Pour l'instant, il y en a très peu : dans les parseurs Matroska et FAT uniquement.
Dans les fichiers Matroska, il existe une structure ('Cues') qui indexe certaines trames. En général, les trames clés d'un flux video. Il faut consulter plusieurs champs pour localiser la trame clé dans le fichier, et de toute façon, même si un seul champ suffisait, celui-ci ne serait pas forcément intelligible : indice de temps, ou position en octets par rapport à un endroit bien précis (et lire les specs pour le connaître), etc.
Dans le cas du système FAT, les liens permettent par exemple de naviguer entre les différents fragments d'un fichier.
Mais c'est surtout en suivant le lien dans une entrée de répertoire qu'on déclenche le hachage du fichier correspondant à cet entrée. Cela résoud [1]. On laisse des zones non hachées (padding) puis on hache ces zones à la demande.
[^] # Re: linux live
Posté par lcld . En réponse au journal Debian(?) LiveCD/USB sur mesure. Évalué à 4.
A propos des lecteurs CD SCSI, je retire ce que j'ai dit. J'ai lu sans réfléchir. A condition que les pilotes sont chargés (intégrés au noyau), je ne vois pas de raison pour que ça ne marche pas.
[^] # Re: linux live
Posté par lcld . En réponse au journal Debian(?) LiveCD/USB sur mesure. Évalué à 4.
- Ca ne marche pas avec le noyau fourni par debian, pour un bête problème de modules.
- Création de liveusb peu pratique (même si ça peu se corriger facilement) : tel quel, il faut commencer par créer le livecd.
- Pas de support des lecteurs CD SCSI.
- Une livedistro est censé tourner sur n'importe quoi sans avoir trop de choses à faire au démarrage : quid du serveur X (si je prend le xorg.conf d'une machine (nvidia) pour le mettre sur une autre (ati), ça ne marche pas) ? Je n'ai pas vu la moindre fonctionnalité permettant de traiter cette aspect de la construction d'un livecd.
Alors s'il faut configurer certaines choses soi-même, j'ajouterais :
- Nécessité d'installer un système préalablement. Contrairement à mon outil qui ne modifie pas le moindre fichier du système source.
Mais j'admets que si j'avais connu ce projet, je m'en serais sans doute contenté, en y apportant quelques modifications. Maintenant, non.
Quelle distribution ?
[^] # Re: cramfs ?
Posté par lcld . En réponse au message Cramfs. Évalué à 2.
J'imagine que Linux garde tout ce qu'il peut en cache donc si tu as assez de RAM, il ne devrait pas y avoir de différence selon que tu copies ou non tout ta partition (à la limite, tu peux forcer une mise en cache au démarrage).
(... et bunzip2)
Bah, c'était pour compresser et gagner de la place. Apparemment, tu en as assez (49Mo sur 64) donc tu peux aussi y aller à coup de 'cp -a'
Si tu peux te contenter de tout copier sauf certains répertoires (ex: /bin), la solution que j'ai donnée dans mon précédent post doit suffire, quitte à ajouter /usr (pour Firefox) à la liste /etc,/home...
Pour avoir _toute_ ta partition en RAM, j'aurais dit qu'il faut passer par un image de démarrage (initrd). Mais apparemment, dans ton cas, la méthode suivante devrait fonctionner :
* intégrer au noyau tous les pilotes nécessaires pour qu'il puisse monter / sans module et passer la bonne valeur pour l'option 'root'
* pas d'option initrd
* créer un script /sbin/preinit (exécutable) du genre : * ajouter l'option init=/sbin/preinit
* (dans ce cas, plus besoin de faire quoique ce soit de spécial pour /etc, /home, etc)
# cramfs ?
Posté par lcld . En réponse au message Cramfs. Évalué à 2.
Si j'ai bien compris ce que tu veux faire, ton système charge toute ta partition en mémoire vive : tu en as assez ?
Je demande car tu peux aussi utiliser un système à la KNOPPIX, cad avec un système de fichiers compressé en lecture seule. Ex. de systèmes de fichiers : cloop, squashfs, isofs (avec compression transparente)
Si tes besoins le permettent, il se peut que tu puisses te passer d'une image de démarrage (solution non testée) :
* intégrer au noyau tous les pilotes nécessaires pour qu'il puisse monter / sans module et passer la bonne valeur pour l'option 'root'
* pas d'option initrd
* créer un script /sbin/preinit (exécutable) du genre : * ajouter l'option init=/sbin/preinit
Avec une image de démarrage, même très petite, tu as beaucoup plus de libertés pour préparer /. Et puisque c'est pour de l'embarqué, il reste préférable d'intégrer au noyau tous les pilotes nécessaires pour monter /.
Avant de développer cette possibilité, ce serait mieux que tu décrives plus précisement ce que tu veux.
Au fait, tu pars de quelle distribution ? Quel quantité de RAM ? Quoi comme unité de stockage ?
[^] # Re: Comment casser le mythe de rapidité de Fibonacci :-)
Posté par lcld . En réponse à la dépêche Erlang/OTP R11B supporte les architectures multiprocesseur. Évalué à 2.
De toute façon, ici, la meilleure solution au solution problème reste encore d'exprimer la suite en fonction de n plutôt qu'en fonction des termes précédents -> algo en O(1) (quoique ça dépende de l'implémentation de l'exponentielle...).
La comparaison est mauvaise : la principale raison pour laquelle le C a gagné est que l'assembleur n'est pas portable et qu'un langage assembleur est censé avoir une durée de vie limitée.
Cela dit, il y a quand même un point qui me gêne. Comment justifier cette surenchère de couches alors qu'il y a de nombreuses tâches qui ne sont pas parallélisables (ou difficilement parallélisables) et que la puissance des coeurs CPU augmente de plus en plus lentement.
Par exemple : réactivité des IHM, compression de données, etc.
[^] # (réponse groupée)
Posté par lcld . En réponse au message Chaine de caractère. Évalué à 3.
Ne me dites pas que c'est le résultat auquel il est arrivé, ou le reste de son message aurait été complètement différent : il donne l'impression de l'avoir compilé alors pourquoi ne pas avoir _copié-collé_ ?
Vous vous rendez compte que vous avez pris la peine de répondre ceci :
"chainelu char[30]; il faut mettre le type avant le nom de variable: char chainelue[30];" ?
Comme vous voulez, mais je pense qu'il gagnera à mieux poser ses questions. Et ce n'est pas comme si c'était son premier post.
Ca n'a rien à voir avec le fait qu'il débute en C.
Je comprends qu'il ne voulait pas forcément faire ça en C.
Si vous préférez que j'ignore ce genre de questions, dites-le.
# Ton post est une blague ou
Posté par lcld . En réponse au message Chaine de caractère. Évalué à -5.
Bon, je vais quand même répondre parce qu'une solution en shell tient en 8 lignes : Ex. d'utilisation : ./en_shell < entrée.txt
Et si tu veux des pistes pour le faire en C, montre que ça t'intéresse un minimum.
[^] # Re: point virgule ?
Posté par lcld . En réponse au message Tableaux en parametres. Évalué à 2.
L'erreur est... ah ben tu l'as corrigée sans faire attention. C'est :
Tableau ( int t[8] ) : tab(t) {}
et non pas :
Tableau ( int t[8] ) : tab=t {}
[^] # Re: re
Posté par lcld . En réponse au journal Contrôle parental open-source. Évalué à 3.
# man ssh
Posté par lcld . En réponse au message ececution de commande dans un shell distant. Évalué à 1.
1ere commande: $> cd toto; ls
au lieu de :
1ere commande: $> cd toto
2nd commande: $> ls
tu obtiens :
$ ssh 127.0.0.1 'cd /bin; ls'
Et si la commande est compliquée au point que tu en as fait un script, tu peux écrire :
$ ssh me@somewhere "`cat toto`"
# Imprécis
Posté par lcld . En réponse au message Comment afficher du texte d'un fichier situé entre caractères spéciaux.. Évalué à 2.
$ cat tst
------------------------------------------------
Titre : incident serveur
Com : Explique comme résoudre le probleme maj RF530
blablablablala
?
Ceci est l'explication pour résoudre le problème
blablablablablablablablblablablablablablablabl
?
------------------------------------------------
Titre : incident serveur
Com : Explique comme résoudre le probleme mAj RF530
blAblAblAblAlA
?
Ceci est l'explicAtion pour résoudre le problème
blAblAblAblAblAblAblAblblAblAblAblAblAblAblAbl
?
------------------------------------------------
$ sed '/^?$/,/^?$/!d;/^?$/d' tst
Ceci est l'explication pour résoudre le problème
blablablablablablablablblablablablablablablabl
Ceci est l'explicAtion pour résoudre le problème
blAblAblAblAblAblAblAblblAblAblAblAblAblAblAbl
Mais j'imagine que tu veux un séparateur...
# Pour commencer...
Posté par lcld . En réponse au message cron php. Évalué à 3.
Sous Debian, il te faudrait le paquet php4-cli (ou php5-cli...).
Voilà un exemple de script :