> Par nature, tout texte en anglais ou en français pose un problème si l'on veut s'adresser au monde entier. Il ne sera pas compréhensible pour la plupart des humains. C'est le fait d'empêcher l'intercompréhension qui va à l'encontre des droits de l'homme. Là où le sujet est délicat, c'est que le respect des cultures individuelles appartient également aux droits de l'homme. On est donc confronté à un besoin d'intercompréhension et de respect des cultures. L'anglais, la traduction, ou d'autres solutions méritent d'être analysés pour répondre du mieux possible à cette double contrainte.
Ton argument de base est valide, sauf que tu oublies que la traduction a un coût. Un coup que GNU/Linux ne peut s'offrir pour ce qui est de la partie la plus technique et la plus pointue... je parle évidemment du noyau (et des outils de programmation).
Les traducteurs sont une ressource rare et utile, mais les gaspiller pour traduire les messages des compilateurs, les messages du noyau ou même l'aide du noyau, me semble vraiment imbécile (si, si, c'est le mot).
La traduction est utile (et même nécessaire) pour les documentations qui ont pour cible les utilisateurs terminaux. Ceux qui utilisent les logiciels qui sont en bout de chaîne, ceux qui ne connaissent rien à la programmation.
L'autre point sur lequel je suis en total désaccord avec toi, c'est que segmenter les traductions des messages d'erreurs en plusieurs langues mène inévitablement à l'effet que j'ai déjà ecrit dans mon post initial.
Bref, afin d'éviter le coup de la traduction et de factoriser les expériences des utilisateurs lorsqu'ils trouvent un bug, une langue unique est nécessaire... C'est une question de survie.
Et bien, pas de chance, c'est l'anglais et toi tu es français.
Bon, bah y'a plus qu'a apprendre à parler l'anglais....
> Je souhaite défendre toutes les langues (celles qui sont en voix de disparitions mais aussi l'anglais victime du broken english ).
En "voie" pas en "voix".... (je sais c'est facile et moi aussi je fais des fôtes). :)
Néammoins, la défense de la langue n'a rien à voir ici. Comme je l'ai dit plus haut, il s'agit d'une question de survie pour Linux. L'efficacité du développement n'est pas quelque chose d'inutile, il existe des tas de concurrents pour Linux et perdre de l'efficacité veut dire perdre des batailles contre Windows ou autres. Linux commence à peine à convaincre les "décideurs", et cela seulement parceque presque rien n'a été été gaspillé et tous les efforts ont été concentrés. Si tu commences à faire partir tout ces efforts dans toutes les directions parceque tu veux "protéger" les languages (ce qui n'a rien à voir avec le schmilblick) tu vas vite te retrouver avec un poste Windows au boulot...
Si tu veux protéger les languages, ce qui est tout à fait louable, alors enseigne les, écrit des essais littéraires, parle les, mais ne commence pas à mélanger la défence des languages et Linux.
> Ne cherchant pas à imposer ma propre langue (le français), je préfère proposer l'utilisation d'une langue neutre, simple et respectueuse des minorités linguistiques.
Toutes les expériences de languages artificiels construit à cet effet ont échoués. Nous avons, maintenant, déjà à disposition, un language parfaitement adapté aux discussions techniques qui est l'anglais. Que veux-tu de plus ??????
> Tout à fait : chacun a le droit d'avoir ses préférences. Personnellement, pour mes échanges internationaux, j'utilise une autre langue que l'anglais.
Qui est ?????
> D'autre part, on peut préférer consacrer son temps à d'autres choses qu'aux langues. Par exemple aux LL...
Qu'est-ce qui empêche de faire les deux ??? Explique-moi ?
Je crois que vous n'avez pas encore tout à fait compris combien peut-être mauvaise la traduction à outrance... J'ai déjà développé mon point de vue dans le début de ce thread, inutile de m'étendre plus donc.
Cependant, je ne peux que me réjouir du fait que ce projet va probablement avorter comme son ancêtre l'a fait.
Le politiquement correct dégoulinant n'est pas vraiment ma tasse de thé. Si vous voulez rester ignorants et ne parler que Français, comment vous en empêcher ? (cela doit être dans les droits de l'homme, le droit à l'ignorance) Mais au moins ne dérangez pas les gens qui utilisent cette langue comme un outils de travail indispensable.
Si des docs devaient être traduites, je pense qu'il vaudrait mieux traduire des docs de end-users... Si l'on se demande qui sont les gens qui recompilent le noyau, on se rend compte que ce sont ceux qui ont besoin de lire quoi qu'il arrive des documentations en anglois. Mais, bon, soyons naïfs et imaginons une seconde que cela arrive...
Quelque part en France dans un futur proche...
Vous avez un kernel panic lorsque vous démarrez sur votre disque-dur externe USB ? Ooooh, quel dommage ! Il va vous falloir lire des documentations, des enfilades de listes de diffusion toutes en ANGLAIS avant de vous apercevoir du problème...
Ah bah oui, la traduction des messages de "help" a été vachement utile !!! Surtout quand vous vous êtes retrouvé complétement con lorsque vous avez tapé la traduction francaise des options du noyaux qui vous semblaient pertinentes dans Google...
« Aucune page trouvée » s'entêtais à dire Google (encore un vendu du complexe américano-anglo-australien !!! Ou alors un coup d'Échelon).
Après quelques temps, il vous a fallu retrouver les noms originaux (en anglais) pour pouvoir suivre les discussions des développeurs du noyau et comprendre enfin qu'il fallait appliquer le patch XYZ afin que votre "firmware" soit reconnu.
Mais quelle idée géniaaaaale !!!
Quand à traduire les messages du Kernel (ou ceux de logiciels comme des compilateurs), c'est tout aussi stupide.
Comment identifier un problème si le message d'erreur n'est pas dans une langue commune à tous les dévelopeurs ?
L'équation est pourtant simple ! Plus vous avez d'utilisateurs pour un logiciel, plus il y a de chances de trouver quelqu'un qui a été confronté au même problème. Si vous vous acharnez à segmenter les utilisateurs en sous-groupes cela va ralentir la découverte de bugs, et la rendre difficile pour ne pas dire impossible pour les non-anglophones...
Vous me direz: "Oui, mais de toute façon les non-angplophones y savent pas lire les forums de développement du noyau!"....
Ok, mais à qui ils posent des questions lorsqu'ils ont des problèmes ???
Et bien, je vous le donne en mille émile, à des gens comme moi qui se retrouvent comme des cons devant des messages comme: "Erreur de jetage sur le type de x" . 8-o
Qui plus est, ceux qui ont déjà codé un tant soit peu dans le monde merveilleux du kernel-space, savent qu'il n'y a pas de place pour ce genre de bétises. À la rigueur, le traducteur peut se trouver en user-space et intercepter les messages du kernel et les traduire au vol... mais franchement quel est l'intêret ?????
Les non-développeurs ne comprennent pas de toute façon ce qui se passe et donner à un développeur l'habitude de lire des messages d'erreur que seul un _petit_ fragment de la communauté peut comprendre, c'est vraiment du gachis car il ne pourra pas communiquer avec les autres (et faire des logiciels libres, c'est 10% de code et 90% de communication).
Ah oui, c'est vrai, j'oubliais. vous etes un de ces imbéciles de Français qui considère que tout devrait être traduit en Français, quitte à épuiser les traducteurs à la tâche.
Évidemment, il est hors de question pour vous d'aider en quoi que ce soit !!! Non, quelle horreur ! Votre truc à vous c'est de tchatcher sur les forums et d'avoir des idées "géniales" comme par exemple essayer de traduire en flux tendu l'aide du noyau qui est probablement un des trucs qui change le plus facilement (surtout à présent qu'avec le nouveau système de Makefile du 2.6 l'aide sera distribuée dans chacun des répertoires et plus un gros fichier unique dans Documnentations/ ).
Quant au "Les documentation en anglais sont contre les droits de l'homme", j'avoue que tu as touché le ponpon, mon gars.... C'est tellement imbécile et franco-centriste que cela me donne la nausée. Tes arguments sont complétement stupides et démontrent juste une envie de rester dans ta bétise crasse ! Comment peut-on dire en l'an 2003 que l'on ne veut pas parler d'autres langues que le Français ???? Nous sommes Européens ! Le language communément utilisé dans les échanges internationaux c'est l'anglais. Entre nous, je préferre l'anglais au Latin, ou l'arabe (comme cela se fasait il y a quelques siècles) la grammaire est bien plus simple.
Et puis, vous enviez ces anglophones pour qui cela tombe tout cuit. Mais, certains sont ausi fort que vous pour décrypter des textes écrits par un Tchèque et relu par un Japonais et un Mexicain. En bref, cette langue que vous appelez "anglais" ne leur appartient pas plus qu'à vous. Il s'agit d'un dialecte technique pour exprimer des choses à propos de l'informatique (si vous cherchez "segmentation fault" dans un dictionnaire, vous risquez d'être déçu).
Finalement, j'ai toujours plaisir à parler anglais, ou même allemand, ou encore français, j'avoue avoir un peu moins de plaisir lorsque je parle danois ou norvégien, mais c'est parceque je débute. Et alors !!! Apprenez des langues ! Cela vous ouvre l'esprit ! Et il semble qu'un bon nombre d'entre vous en a besoin !
Je veux dire la faille de sécurité !
Cela ressemble fort à un exploit par dépassement de tampon et ce patch (fait fin juillet) ressemble à s'y méprendre à un patch fixant un problème éventuel de dépassement de tampon (mais je ne suis pas un spécialiste !!!)...
La correction n'est toujours pas prise en compte (ou alors il y en avait plusieurs):
-la RIAA ait pris connaissance de l'existence du logiciel et _est_ décidée d'attaquer
+la RIAA ait pris connaissance de l'existence du logiciel et _ait_ décidée d'attaquer
> The upstream developers for mplayer have, several times, stated that
> mplayer was licensed entirely under the GPL, when it simply was not,
> and they had clearly not even tried to check.
>
> It doesn't matter whether this was intentional or just inept -
> continuing to trust their word on the matter would be foolish.
Je suppose que j'ai été "foolish enough" pour faire confiance aux développeurs de mplayer. :-)
Mais cela me pose quelques problèmes d'utiliser MPlayer maintenant que je sais ça... Je vais peut-être être vu comme un extrémiste mais je suis extrêmement respectueux des licences (même celles de Microsoft Windows, bon j'en ai aucune mais si j'avais à bosser sur Windows, je suppose que je l'acheterai).
Quelles seraient les parties de MPlayer qui ne seraient pas GPL/LGPL (je suppose que cela se joue du coté des codecs....) ?
Ce n'est pas que la recompilation de MPlayer soit difficile (configure && make && make install) mais je me demandais pourquoi il n'y a pas de paquetage MPlayer pour Debian...
Y aurait-il des problèmes de droits ? On m'aurait menti ? MPlayer n'est pas GPL ?
Microsoft a une politique très "aggressive" envers Linux. Ils ne le voient pas seulement comme un concurrent normal, mais réelement comme une menace. Il ne serait pas trop surprenant pour moi de les voir réagir assez promptement pour éviter de voir trop de gens acheter des Xbox pour faire tourner Linux dessus. Après tout, la Xbox est moins chère qu'un véritable ordinateur et a une puissance de calcul suffisante pour faire tourner la plupart des applications Linux.
Non, c'est une erreur dans le système d'exploitation mais la façon dont est codé le jeu 007 permet d'y acceder. Cela dit, l'auteur de l'exploit semble dire que beaucoup d'autres jeux ont cette particularité aussi.
Oui, mais la technique est là. On pourrait imaginer d'isoler et de reproduire le bug de 007 pour l'utiliser pour charger Linux. Pour l'instant, on doit encore utiliser le CD de 007, mais ce n'est que temporaire car on exploite en fait un buffer overflow du système de la Xbox.
Reste à savoir si Microsoft va patcher ce bug ou non dans les futures versions du système (à priori un buffer-overflow se patche assez facilement).
Trouver un bug qui repose sur le design même du système assurerait une certaine pérennité, mais ces bugs sont difficiles à trouver. Cela dit, habbi_xbox a vraiment fait du bon boulot !!!
Le problème, c'est que ton pot de miel va simuler des failles évidentes (sinon ce ne serait pas attirant et cela ne se serait pas appelé un "pot de miel"). Donc, de par cette simulation de failles, tu incites les pirates à passer à l'action (puisque tu n'as pas ces failles pour de vrai, mais tu les simules).
Le principe du pot de miel repose un peu sur le principe de la prestidigitation, on donne aux pirates un objet d'attention pour les éloigner de notre vrai réseau et les piéger (ou les étudier) sur un réseau que l'on contrôle totalement.
Non, tu ne dois déclarer à la CNIL que les fichiers qui contiennent des informations personnelles sur des personnes.
Évidemment, cela dépend de ce que l'on appelle des informations personnelles, mais en l'occurence pour tes logs apache ou iptables, ces fichiers ne contiennent que l'adresse IP des machines qui ont accèdé à ton site et pas les noms des personnes.
Comme d'un point de vue légal il est difficile de faire le lien entre une adresse IP et une personne (qui utilisait l'ordinateur à ce moment, est-ce de l'IP-spoofing, etc) tu peux te convaincre facilement que tes logs ne contiennent aucune information personnelle sur des gens (seulement des infofrmations "personnelles" pour des ordinateurs... :).
1) Pour le mp3, le ogg serait mieux (autant pour des raisons de qualité audio que de droits).
2) Pour ce qui est de l'aspect non libre de leurs créations. Pareil, il s'agit ici de création artistique et pas de code. Je comprend tout à fait qu'ils n'aient pas envie de voir leur oeuvre modifiée (du moins sans autorisation). Cela dit, ils utilisent quelques fois des musiques qui sont sous copyright (on entend la bande originale de Conan le barbare de temps à autre). Je ne sais pas si c'est tout à fait légal.
Cela dit, ils vont bientôt sortir un CD (avec des suppléments inédits). Tout sera au format wav (et donc de meilleur qualité que le format mp3). Achetez le, cela leur permettra de continuer !!!! :)
Cela pourrait bien être ça... Je n'avais pas pensé à un crash du driver (surtout qu'il s'agit d'un driver experimental sur une carte Gigabit-Ethernet de syskonnect).
Il faut que je vérifie ça (l'ennui c'est que depuis on a mis à jour le prototype de driver, et du coup cela pourrait expliquer pourquoi on a plus rencontré le problème.... Je vais voir ce que donne un diff sur le source).
A propos de vulnerabilités du noyau 2.4. Dernièrement, j'ai vu un truc bizarre.
Avec un collègue on fait des tests de performances sur un petit réseau gigabit ethernet qui passe à travers une machine qui est censée contenir un firewall. Pour l'instant on faisait des tests de calibrage, donc la machine avait été configurée juste pour router les paquets d'un réseau à l'autre.
On utilise un traffic "pire cas", c'est à dire que l'on forge des paquets et qu'on les envoi d'un réseau à l'autre à travers cette machine. Il est possible que la façon dont on forge les paquets soit mauvaise. Je ne peux rien garantir.
Donc, à un moment lors d'une expérience, plus rien ne passait à travers le machine Linux montée en routeur... Pourtant, on pouvait faire tout ce qu'on voulait via un accès direct (clavier et moniteur marchait, tous les logiciels non réseau marchaient...). Sinon, du coté réseau, pas de ping, rien... J'ai eu l'impression que l'on avait planté la pile TCP/IP. Le problème, c'est qu'en essayant de le reproduire, on a pas réussi (du moins pas pour l'instant). Donc, je ne sais pas du tout d'où cela pouvait venir.
Est-ce que quelqu'un a déjà rencontré ce genre de problème ????
[^] # Re: Comment perdre son temps en une leçon....
Posté par Alan_T . En réponse à la dépêche Projet relancé chez traduc.org : traduction du noyau Linux.. Évalué à -1.
Désolé !!!
[^] # Re: Comment perdre son temps en une leçon....
Posté par Alan_T . En réponse à la dépêche Projet relancé chez traduc.org : traduction du noyau Linux.. Évalué à -1.
Ton argument de base est valide, sauf que tu oublies que la traduction a un coût. Un coup que GNU/Linux ne peut s'offrir pour ce qui est de la partie la plus technique et la plus pointue... je parle évidemment du noyau (et des outils de programmation).
Les traducteurs sont une ressource rare et utile, mais les gaspiller pour traduire les messages des compilateurs, les messages du noyau ou même l'aide du noyau, me semble vraiment imbécile (si, si, c'est le mot).
La traduction est utile (et même nécessaire) pour les documentations qui ont pour cible les utilisateurs terminaux. Ceux qui utilisent les logiciels qui sont en bout de chaîne, ceux qui ne connaissent rien à la programmation.
L'autre point sur lequel je suis en total désaccord avec toi, c'est que segmenter les traductions des messages d'erreurs en plusieurs langues mène inévitablement à l'effet que j'ai déjà ecrit dans mon post initial.
Bref, afin d'éviter le coup de la traduction et de factoriser les expériences des utilisateurs lorsqu'ils trouvent un bug, une langue unique est nécessaire... C'est une question de survie.
Et bien, pas de chance, c'est l'anglais et toi tu es français.
Bon, bah y'a plus qu'a apprendre à parler l'anglais....
> Je souhaite défendre toutes les langues (celles qui sont en voix de disparitions mais aussi l'anglais victime du broken english ).
En "voie" pas en "voix".... (je sais c'est facile et moi aussi je fais des fôtes). :)
Néammoins, la défense de la langue n'a rien à voir ici. Comme je l'ai dit plus haut, il s'agit d'une question de survie pour Linux. L'efficacité du développement n'est pas quelque chose d'inutile, il existe des tas de concurrents pour Linux et perdre de l'efficacité veut dire perdre des batailles contre Windows ou autres. Linux commence à peine à convaincre les "décideurs", et cela seulement parceque presque rien n'a été été gaspillé et tous les efforts ont été concentrés. Si tu commences à faire partir tout ces efforts dans toutes les directions parceque tu veux "protéger" les languages (ce qui n'a rien à voir avec le schmilblick) tu vas vite te retrouver avec un poste Windows au boulot...
Si tu veux protéger les languages, ce qui est tout à fait louable, alors enseigne les, écrit des essais littéraires, parle les, mais ne commence pas à mélanger la défence des languages et Linux.
> Ne cherchant pas à imposer ma propre langue (le français), je préfère proposer l'utilisation d'une langue neutre, simple et respectueuse des minorités linguistiques.
Toutes les expériences de languages artificiels construit à cet effet ont échoués. Nous avons, maintenant, déjà à disposition, un language parfaitement adapté aux discussions techniques qui est l'anglais. Que veux-tu de plus ??????
> Tout à fait : chacun a le droit d'avoir ses préférences. Personnellement, pour mes échanges internationaux, j'utilise une autre langue que l'anglais.
Qui est ?????
> D'autre part, on peut préférer consacrer son temps à d'autres choses qu'aux langues. Par exemple aux LL...
Qu'est-ce qui empêche de faire les deux ??? Explique-moi ?
[^] # Re: Comment j'ai perdu mon temps à lire ce post en une leçon....
Posté par Alan_T . En réponse à la dépêche Projet relancé chez traduc.org : traduction du noyau Linux.. Évalué à -1.
Cependant, je ne peux que me réjouir du fait que ce projet va probablement avorter comme son ancêtre l'a fait.
Le politiquement correct dégoulinant n'est pas vraiment ma tasse de thé. Si vous voulez rester ignorants et ne parler que Français, comment vous en empêcher ? (cela doit être dans les droits de l'homme, le droit à l'ignorance) Mais au moins ne dérangez pas les gens qui utilisent cette langue comme un outils de travail indispensable.
# Comment perdre son temps en une leçon....
Posté par Alan_T . En réponse à la dépêche Projet relancé chez traduc.org : traduction du noyau Linux.. Évalué à 0.
Quelque part en France dans un futur proche...
Vous avez un kernel panic lorsque vous démarrez sur votre disque-dur externe USB ? Ooooh, quel dommage ! Il va vous falloir lire des documentations, des enfilades de listes de diffusion toutes en ANGLAIS avant de vous apercevoir du problème...
Ah bah oui, la traduction des messages de "help" a été vachement utile !!! Surtout quand vous vous êtes retrouvé complétement con lorsque vous avez tapé la traduction francaise des options du noyaux qui vous semblaient pertinentes dans Google...
« Aucune page trouvée » s'entêtais à dire Google (encore un vendu du complexe américano-anglo-australien !!! Ou alors un coup d'Échelon).
Après quelques temps, il vous a fallu retrouver les noms originaux (en anglais) pour pouvoir suivre les discussions des développeurs du noyau et comprendre enfin qu'il fallait appliquer le patch XYZ afin que votre "firmware" soit reconnu.
Mais quelle idée géniaaaaale !!!
Quand à traduire les messages du Kernel (ou ceux de logiciels comme des compilateurs), c'est tout aussi stupide.
Comment identifier un problème si le message d'erreur n'est pas dans une langue commune à tous les dévelopeurs ?
L'équation est pourtant simple ! Plus vous avez d'utilisateurs pour un logiciel, plus il y a de chances de trouver quelqu'un qui a été confronté au même problème. Si vous vous acharnez à segmenter les utilisateurs en sous-groupes cela va ralentir la découverte de bugs, et la rendre difficile pour ne pas dire impossible pour les non-anglophones...
Vous me direz: "Oui, mais de toute façon les non-angplophones y savent pas lire les forums de développement du noyau!"....
Ok, mais à qui ils posent des questions lorsqu'ils ont des problèmes ???
Et bien, je vous le donne en mille émile, à des gens comme moi qui se retrouvent comme des cons devant des messages comme: "Erreur de jetage sur le type de x" . 8-o
Qui plus est, ceux qui ont déjà codé un tant soit peu dans le monde merveilleux du kernel-space, savent qu'il n'y a pas de place pour ce genre de bétises. À la rigueur, le traducteur peut se trouver en user-space et intercepter les messages du kernel et les traduire au vol... mais franchement quel est l'intêret ?????
Les non-développeurs ne comprennent pas de toute façon ce qui se passe et donner à un développeur l'habitude de lire des messages d'erreur que seul un _petit_ fragment de la communauté peut comprendre, c'est vraiment du gachis car il ne pourra pas communiquer avec les autres (et faire des logiciels libres, c'est 10% de code et 90% de communication).
Ah oui, c'est vrai, j'oubliais. vous etes un de ces imbéciles de Français qui considère que tout devrait être traduit en Français, quitte à épuiser les traducteurs à la tâche.
Évidemment, il est hors de question pour vous d'aider en quoi que ce soit !!! Non, quelle horreur ! Votre truc à vous c'est de tchatcher sur les forums et d'avoir des idées "géniales" comme par exemple essayer de traduire en flux tendu l'aide du noyau qui est probablement un des trucs qui change le plus facilement (surtout à présent qu'avec le nouveau système de Makefile du 2.6 l'aide sera distribuée dans chacun des répertoires et plus un gros fichier unique dans Documnentations/ ).
Quant au "Les documentation en anglais sont contre les droits de l'homme", j'avoue que tu as touché le ponpon, mon gars.... C'est tellement imbécile et franco-centriste que cela me donne la nausée. Tes arguments sont complétement stupides et démontrent juste une envie de rester dans ta bétise crasse ! Comment peut-on dire en l'an 2003 que l'on ne veut pas parler d'autres langues que le Français ???? Nous sommes Européens ! Le language communément utilisé dans les échanges internationaux c'est l'anglais. Entre nous, je préferre l'anglais au Latin, ou l'arabe (comme cela se fasait il y a quelques siècles) la grammaire est bien plus simple.
Et puis, vous enviez ces anglophones pour qui cela tombe tout cuit. Mais, certains sont ausi fort que vous pour décrypter des textes écrits par un Tchèque et relu par un Japonais et un Mexicain. En bref, cette langue que vous appelez "anglais" ne leur appartient pas plus qu'à vous. Il s'agit d'un dialecte technique pour exprimer des choses à propos de l'informatique (si vous cherchez "segmentation fault" dans un dictionnaire, vous risquez d'être déçu).
Finalement, j'ai toujours plaisir à parler anglais, ou même allemand, ou encore français, j'avoue avoir un peu moins de plaisir lorsque je parle danois ou norvégien, mais c'est parceque je débute. Et alors !!! Apprenez des langues ! Cela vous ouvre l'esprit ! Et il semble qu'un bon nombre d'entre vous en a besoin !
[^] # Re: Sortie de Open SSH 3.7
Posté par Alan_T . En réponse à la dépêche Sortie de Open SSH 3.7. Évalué à 1.
[^] # Re: Sortie de Open SSH 3.7
Posté par Alan_T . En réponse à la dépêche Sortie de Open SSH 3.7. Évalué à 2.
Cela ressemble fort à un exploit par dépassement de tampon et ce patch (fait fin juillet) ressemble à s'y méprendre à un patch fixant un problème éventuel de dépassement de tampon (mais je ne suis pas un spécialiste !!!)...
# Re: Sortie de Open SSH 3.7
Posté par Alan_T . En réponse à la dépêche Sortie de Open SSH 3.7. Évalué à 5.
http://www.eviladmin.org/cvs/cvsweb.cgi/buffer.c(...)
http://www.eviladmin.org/cvs/cvsweb.cgi/buffer.c.diff?r1=1.14&r(...)
# Et l'argent ????
Posté par Alan_T . En réponse à la dépêche Amende pour SCO pour propos "mensongers". Évalué à 1.
[^] # Re: Le développeur principal d'xMule poursuivi en justice
Posté par Alan_T . En réponse à la dépêche Le développeur principal d'xMule poursuivi en justice. Évalué à -1.
-la RIAA ait pris connaissance de l'existence du logiciel et _est_ décidée d'attaquer
+la RIAA ait pris connaissance de l'existence du logiciel et _ait_ décidée d'attaquer
[^] # Re: MPlayer vs Debian
Posté par Alan_T . En réponse à la dépêche MPlayer G2 : un avant-goût. Évalué à 4.
> The upstream developers for mplayer have, several times, stated that
> mplayer was licensed entirely under the GPL, when it simply was not,
> and they had clearly not even tried to check.
>
> It doesn't matter whether this was intentional or just inept -
> continuing to trust their word on the matter would be foolish.
Je suppose que j'ai été "foolish enough" pour faire confiance aux développeurs de mplayer. :-)
Mais cela me pose quelques problèmes d'utiliser MPlayer maintenant que je sais ça... Je vais peut-être être vu comme un extrémiste mais je suis extrêmement respectueux des licences (même celles de Microsoft Windows, bon j'en ai aucune mais si j'avais à bosser sur Windows, je suppose que je l'acheterai).
Quelles seraient les parties de MPlayer qui ne seraient pas GPL/LGPL (je suppose que cela se joue du coté des codecs....) ?
# MPlayer vs Debian
Posté par Alan_T . En réponse à la dépêche MPlayer G2 : un avant-goût. Évalué à 2.
Y aurait-il des problèmes de droits ? On m'aurait menti ? MPlayer n'est pas GPL ?
[^] # Re: Exploit français
Posté par Alan_T . En réponse à la dépêche Faille de sécurité pour les noyaux < 2.4.21. Évalué à 2.
[^] # Re: Une Xbox non modifiée sous linux, c'est désormais possible
Posté par Alan_T . En réponse à la dépêche Une Xbox non modifiée sous linux, c'est désormais possible. Évalué à 2.
[^] # Re: Une Xbox non modifiée sous linux, c'est désormais possible
Posté par Alan_T . En réponse à la dépêche Une Xbox non modifiée sous linux, c'est désormais possible. Évalué à 1.
[^] # Re: Une Xbox non modifiée sous linux, c'est désormais possible
Posté par Alan_T . En réponse à la dépêche Une Xbox non modifiée sous linux, c'est désormais possible. Évalué à 4.
Reste à savoir si Microsoft va patcher ce bug ou non dans les futures versions du système (à priori un buffer-overflow se patche assez facilement).
Trouver un bug qui repose sur le design même du système assurerait une certaine pérennité, mais ces bugs sont difficiles à trouver. Cela dit, habbi_xbox a vraiment fait du bon boulot !!!
[^] # Re: Les "pots de miel" sont-ils légaux?
Posté par Alan_T . En réponse à la dépêche Les "pots de miel" sont-ils légaux?. Évalué à 1.
Le principe du pot de miel repose un peu sur le principe de la prestidigitation, on donne aux pirates un objet d'attention pour les éloigner de notre vrai réseau et les piéger (ou les étudier) sur un réseau que l'on contrôle totalement.
[^] # Re: Les "pots de miel" sont-ils légaux?
Posté par Alan_T . En réponse à la dépêche Les "pots de miel" sont-ils légaux?. Évalué à 1.
Évidemment, cela dépend de ce que l'on appelle des informations personnelles, mais en l'occurence pour tes logs apache ou iptables, ces fichiers ne contiennent que l'adresse IP des machines qui ont accèdé à ton site et pas les noms des personnes.
Comme d'un point de vue légal il est difficile de faire le lien entre une adresse IP et une personne (qui utilisait l'ordinateur à ce moment, est-ce de l'IP-spoofing, etc) tu peux te convaincre facilement que tes logs ne contiennent aucune information personnelle sur des gens (seulement des infofrmations "personnelles" pour des ordinateurs... :).
[^] # Re: Les aventures en mp3 continuent
Posté par Alan_T . En réponse à la dépêche Les aventures en mp3 continuent. Évalué à 3.
1) Pour le mp3, le ogg serait mieux (autant pour des raisons de qualité audio que de droits).
2) Pour ce qui est de l'aspect non libre de leurs créations. Pareil, il s'agit ici de création artistique et pas de code. Je comprend tout à fait qu'ils n'aient pas envie de voir leur oeuvre modifiée (du moins sans autorisation). Cela dit, ils utilisent quelques fois des musiques qui sont sous copyright (on entend la bande originale de Conan le barbare de temps à autre). Je ne sais pas si c'est tout à fait légal.
Cela dit, ils vont bientôt sortir un CD (avec des suppléments inédits). Tout sera au format wav (et donc de meilleur qualité que le format mp3). Achetez le, cela leur permettra de continuer !!!! :)
[^] # Re: Des vulnérabilités des Linux 2.4 permettent un DoS distant
Posté par Alan_T . En réponse à la dépêche Des vulnérabilités des Linux 2.4 permettent un DoS distant. Évalué à 1.
Il faut que je vérifie ça (l'ennui c'est que depuis on a mis à jour le prototype de driver, et du coup cela pourrait expliquer pourquoi on a plus rencontré le problème.... Je vais voir ce que donne un diff sur le source).
Merci beaucoup pour la piste !!!
[^] # Re: Des vulnérabilités des Linux 2.4 permettent un DoS distant
Posté par Alan_T . En réponse à la dépêche Des vulnérabilités des Linux 2.4 permettent un DoS distant. Évalué à 1.
[^] # Re: Des vulnérabilités des Linux 2.4 permettent un DoS distant
Posté par Alan_T . En réponse à la dépêche Des vulnérabilités des Linux 2.4 permettent un DoS distant. Évalué à 2.
# Re: Des vulnérabilités des Linux 2.4 permettent un DoS distant
Posté par Alan_T . En réponse à la dépêche Des vulnérabilités des Linux 2.4 permettent un DoS distant. Évalué à 7.
Avec un collègue on fait des tests de performances sur un petit réseau gigabit ethernet qui passe à travers une machine qui est censée contenir un firewall. Pour l'instant on faisait des tests de calibrage, donc la machine avait été configurée juste pour router les paquets d'un réseau à l'autre.
On utilise un traffic "pire cas", c'est à dire que l'on forge des paquets et qu'on les envoi d'un réseau à l'autre à travers cette machine. Il est possible que la façon dont on forge les paquets soit mauvaise. Je ne peux rien garantir.
Donc, à un moment lors d'une expérience, plus rien ne passait à travers le machine Linux montée en routeur... Pourtant, on pouvait faire tout ce qu'on voulait via un accès direct (clavier et moniteur marchait, tous les logiciels non réseau marchaient...). Sinon, du coté réseau, pas de ping, rien... J'ai eu l'impression que l'on avait planté la pile TCP/IP. Le problème, c'est qu'en essayant de le reproduire, on a pas réussi (du moins pas pour l'instant). Donc, je ne sais pas du tout d'où cela pouvait venir.
Est-ce que quelqu'un a déjà rencontré ce genre de problème ????
(Au fait, pour le noyau, c'est un 2.4.20)
[^] # Re: J'ai testé Windows
Posté par Alan_T . En réponse à la dépêche J'ai testé Windows. Évalué à 1.
# Package Debian Templeet
Posté par Alan_T . En réponse à la dépêche Test de charge Openbrick: Mise à jour Drupal PHP-Nuke. Évalué à 0.
Ce serait plus facile à installer/désinstaller...
[^] # Re: Streaming à travers un proxy ?
Posté par Alan_T . En réponse à la dépêche Radio France en Ogg Vorbis. Évalué à -1.
C'est génial ! :-)