effectivement, le seul truc qu'il a fait c'est abaisser la memoire disponible pour etre sur de stresser la VM. il ne donne pas suffisement de
mesures pour que l'on voit si d'autres parametres sont venus limiter les perfs.
il aurait fallu donner les courbes cpu/network/io/... sur les serveurs et sur les injecteurs pour en savoir plus.
Je note quand meme autre chose de ce bench: le scheduleur de BSD m'est toujours apparu comme plus rapide que celui de linux. Dans ce test, on voit de nouveau que linux est plus lent pour creer et detruire des process... si je me souviens bien la tendance est inversée pour les threads (plus rapide sous linux). Peut etre le prochain bouleversement du kernel sera de travailler sur le scheduleur ?
avant d'utiliser ces outils (parted, ...) tu prendra soin de demonter (umount) tes filesystemes correctement. du coup le journal tu t'en passe puisque le filesysteme est propre. parted traite ce filesysteme comme de l'ext2 et cela marche tres bien.
conclusion: ca marche bien si tu ne profites pas d'un crash pour repartitionner ton disque ...
faut pas (trop) pousser non plus :-)
la journalisation a un cout, comme l'ont dit certains en dessous. Du coup je vous conseille la lecture de ce papier ultra court de redhat sur le tuning de ext3. Ils indiquent les parametres qui ont une influence sur les perfs et donnent des exemples (tout en precisant bien qu'il n'y a pas de tuning applicable partout, faut le faire au cas par cas évidement).
url: http://www.redhat.com/support/wpapers/redhat/ext3/index.html(...)
deja pour le log, tu peux logguer a travers le reseau vers une autre machine, ou logguer sur une console serie (un cable nul-modem et un autre pc), ou logguer sur un vieux disque ide qui passe par la :-)
sinon, le freeze du bus scsi c'est courant quand un peripherique ne veut plus rendre le bus (chaque periph a un lock dessus quand il s'en sert). normalement l'os devrait faire un reset du bus au bout d'un certain temps.
les cartes tekram sont super bien supportées par linux (drivers GPL dispo sur le site de tekram et inclus dans le kernel), d'ailleur il y en as une nouvelle version (une re-ecriture complete en fait) pour supporter plus de chipsets differents (dispo dans linux-2.4.13-ac8).
verifie ton cablage, et tes terminaisons, ca a l'air con mais ca peut le faire. verifie aussi le mode d'acces (wide/narrow, synchrone/asynchrone).
je ne crois pas au probleme de driver. donc plus basique, dans l'ordre: cable / peripheriques / controleur.
Ben voila, on preche a longueur de commentaires sur DLFP pour l'armonisation des protocoles afin que toutes les machines puissent communiquer entre elles, et quand ils s'agit de faire communiquer des humains on est contre les solutions simples qui s'imposent :-)
</provoc>
honnetement, Internet peut tres bien véhiculer toutes les langues qui existent. mais il faut bien reconnaitre que nous avons besoin d'un protocole "universel" pour causer à tous les terriens maintenant que le réseau des réseaux propage la bonne nouvelle instantanément sur la planette. Cela me désole, mais ce n'est pas le francais qui va s'imposer dans ce role, ni l'espéranto pourtant fait pour ca.
Mais de la à dire que notre langue va disparaitre. quoi que après l'unification des monaies en europe, faudra bien choisir une langue "européenne"... dans quelques années hein, pour le moment les européens ne sont pas prets pour ca!
disclaimer: je ne suis pas l'annonyme qui a lancé ce thread.
Pour moi ? non c'est pas très important vu que j'ai la chance de lire l'anglais assez bien, surtout l'anglais technique. Comme tout passionné d'informatique 80% de mes lectures sont en anglais.
Par contre je comprends très bien ta remarque, puisque la langue peut etre un probleme pour certains et que linuxfr est ... francais.
Je comprends aussi l'annonyme "premier du nom", puisque cette nouvelle est déjà parue, un titre du genre "version frenchie de la news du 04/11" avec le lien sur l'ancienne news aurait été pas mal (normalement les commentaires devraient etre applicables aux 2 et eux sont en francais !!).
Bon je veux pas etre mechant, mais si tu ne compiles pas le driver ELF dans le noyau, c'est sur que tu ne va pas aller loin ... vu que /bin/init est deja un executable ELF.
Donc tu revois la config de tes noyaux et tu inclus le support ELF (pas en module hein, inclus DANS le noyau il en as besoin tout le temps de toutes facons).
humm, cela fait 2 fois que tu postes au sujet de la numérotation des kernels, et bien que je ne releve pas de sotise dans tes posts, je ne suis pas sur que tu ai bien capté l'histoire de pair/impair. plates excuses en cas contraire...
la branche du noyau c'est le second chiffre.
2.4 ==> branche stable car 4 est un nombre pair.
2.5 ==> branche instable (dev) car 5 est impair.
2.4.13 etait déjà un noyau "stable" comme tous les noyaux 1.0, 1.2, 2.0,2.2 et 2.4
2.5 n'existe pas encore, c'est bien/mal c'est un autre débat.
maintenant c'est sur que un kernel qui ne compile pas ca fait pas tres pro --meme en version instable--. c'est d'ailleur pas la premiere fois, il fallait deja modifier le 2.4.6 pour compiler les modules ntfs ...
oui mais en bénéficiant en plus du wireless ...
les voisins peuvent sniffer ton réseau sans violation de propriété privée, à distance et au chaud. vraiment le wireless c'est une avancée technique interessante !!
[entre (), vous conseillez quoi comme équipement pour un réseau wireless pas cher sous linux ?,
parce que la je suis un peu intéressé...]
de voisins en voisins
le probleme avec les transmissions lazer etant l'alignement des emetteur et recepteur (en plus de choisir un emplacement dénué d'obstacles pour le faisceau), si le signal passe de voisins en voisin, un coup de vent un peu fort et hop plus personne n'est connecté parce que l'un des voisins avait mal fixé son équipement ...
pas très valable à mon avis, d'ailleurs c'est assez peu utilisé comme liaison.
j'ai pas eu le temps de rajouter que les packages squid et ssh sont aussi à réinstaller.
ca nous fait donc comme upgrade sécurité:
kernel, ssh, squid et util-linux
c'est quand meme la première fois que la distrib est à patcher AVANT qu'elle ne soit downloadée. faites votre propre iso 7.2+ avec la doc qui va bien ( http://cambuca.ldhs.cetuc.puc-rio.br/RedHat7-CDs-HowTo.html(...) ) si vous devez installer plusieurs machines ... ou pour la frime (de toutes facons dans 1 mois il y aura plein de patchs à passer).
effectivement, ils ont également prévenu la liste bugtrack que le package util-linux qui avait été relivré en 7.1 doit aussi etre réinstallé car celui de la 7.2 possède le trou de sécurité :
New util-linux packages are available that fix a problem with /bin/login's
PAM implementation. This could, in some non-default setups, cause users to
receive credentials of other users. It is recommended that all users
update to the fixed packages.
2001年10月22日: Packages are now available for Red Hat Linux 7.2. Notably,
these packages also fix the problem noted in RHSA-2001:095-04 (vipw
incorrectly setting permissions on some files) - this bug was accidentally
reintroduced in Red Hat Linux 7.2.
non, le 2.4.9 fourni par redhat n'est pas vulnérable. RedHat (Alan Cox), ne veut pas encore de la nouvelle VM et donc ils ont préféré patcher un 2.4.9 plutot que de livrer un 2.4.12.
D'ailleurs les noyaux redhat sont des -ac aménagés, quand on défait un rpm source du noyau pour voir, il y a une multitude de patchs qui sont appliqués avant la compilation ...
Pourtant cette clef de decryptage il vont bien la filer (vendre) aux fabricants d'appareils domestiques, et autres editeurs de logiciels.
Ce qui est fondamentalement mauvais dans la protection des médias (cd audio, dvd, k7...) c'est que la fonction meme de ces média est de livrer les données à l'utilisateur final. crypter ces données c'est aussi donner les moyens de les décrypter pour les utiliser, ce qui ramène obligatoirement à la case départ: l'utilisateur à accès aux données qu'il vient d'acheter, et le cryptage n'a servi à rien [sinon vendre des clefs :-))].
Microsoft n'est pas obligé de filer les specs de ses modifications du protocole kerberos ( ? ,c'est une question !), si il ne veut pas que les autres machines puissent communiquer avec les siennes (par contre, on pourrait interdire à MS d'utiliser le terme kerberos dans la mesure ou il s ne sont pas 100% clients kerberos), par contre la RIAA ne vends pas les apareils de lecture, il faut donc bien qu'elle vende des clefs de decryptage !!
Quand je suis parti en ambassade en Afrique pour le gouvernement (CSN), on avait eu droit à une journée d'information présidée par des mecs de la DST.
Leur propos étaient alors qu'une guerre avait bien lieu en ce moment entre la France et d'autres pays: la guerre de l'information.
Les mecs de la DST qui nous "dégrossissaient" travaillaient pour un service faisant des cours et des interventions en entreprises.(grosses les entreprises, genre Matra, EDF, FT, Elf ...), pour apprendre aux gens a utiliser un broyeur systématiquement...
le plus gros des informations sont dans la poubelle.
et bien je suis désolé si tu as pris ma remarque pour une agression. cela n'en était pas une, crois moi.
d'ailleurs depuis quand anonyme est modérateur ? tu aurai pu au moins te présenter (a moins que tu ne soit qu'un hoax ?)
quand aux nouvelles qui passent, c'est clair que le tri doit etre difficile. j'avais pour ma part envoyé une news qui présentait la nouvelle version d'un document sur la sécurité des applications, au niveau architecture des applis, langage utilisé, base de données, etc. ce document est généraliste mais bourré de liens pour approfondir les sujets ...
la news n'est jamais passée ... a la place on a eu des trucs microsoft à troll et d'autres infos qui m'interessent moins.
modérateur c'est surement dur, mais poster des news c'est aussi dans un but de partage avec les autres, le document sur la sécurité que j'avais proposé, je l'ai lu moi, donc je ne vois pas d'interet spécial a ce que vous passiez "ma" news... il faut aussi considérer le travail que représente l'écriture d'une news, et veiller a encourager ceux qui en envoient !
merci anonyme, j'ai eu la meme idée quand j'ai vu que les 5 bandeaux des news locale ne representerai pas plus de place qu'une news générale si on enleve les descriptions de la page principale.
quand au débat paris/province, ce n'est pas du tout dans le sens de ma remarque. j'habite pres de versailles, je me décrit comme lyonnais, et non meme les infos locales à lyon ou versailles ne m'interessent pas, ma vie de famille m'empechant de toutes facon d'y participer.
je ne suis pas CONTRE les infos locales, il faut les publier et je posterai de nouveau pour me plaindre si elles n'étaient plus acceptées. Souvent il y a une ou 2 infos locales mélangées au reste et c'est très bien, mon commentaire disait plutot que si le nombre d'infos locales continu a augmenter (ce qui est bon signe), on ne trouvera plus les autres news sur ce site.
enfin, non le nombre de commentaires n'est pas révélateur de l'interet d'une news ... a cause des trolls. sinon, on apprends souvent pas mal de choses grace aux commentaires, parfois plus que dans la news. Je concois la richesse de linuxfr aussi par ses lecteurs grace à leurs commentaires. Si il n'y a pas de commentaires, linuxfr devient une revue de presse sans saveur, une liste de liens actualisée tous les jours ...
si on baisse le nombre de troll sans arguments et que l'on augmente les commentaires de points de vue différents (merci pbpg), on enrichit le contenu du site ... les news ici apportent plus que sur le journal du net ou voila ou l'afp GRACE AUX COMMENTAIRES.
juste pour dire que nous sommes sur la meme longueur d'onde. je ne vois pas de contradictions avec mon message précedent dans ta réponse, je ne m'étais pas toujours bien exprimé (developpement fermé par exemple).
linux chasse plusieurs loups a la fois, BSD un seul. il y a plus de developpeurs linux et ils livrent les modules experimentaux en les marquant comme tel alors que sous BSD ils attendent que cela soit fiable pour livrer, certes. ce sont des méthodes différentes.
Sous BSD si c'est livré c'est que cela marche, sinon tu t'en passe.
Sous linux, si un truc est VRAIMENT necessaire pour toi, tu peux essayer la version experimentale pour voir ... et en général elle fonctionne.
Quand a la question "pourquoi ré-ecrire ..."
parce que le but n'est pas le meme. le but de linux c'est que ses developpeurs s'amusent. Et pour se marrer il vaut mieux essayer de développer des idées nouvelles que d'implémenter un truc connu. la VM du 2.2 avait des lacunes (pas facilement scalable, tuning automatique pas terrible) qui fait qu'ils essaient d'autres trucs. le kernel linux est un truc de passionnés.
personnellement j'ai toujours passé mon temps à modifier mon train electrique dès qu'il tournait 15 minutes sans problèmes: ca marche, on pete tout et on essaie de faire mieux. aussi je comprends tout a fait le point de vu des dev de linux (et celui des utilisateurs de BSD si ils veulent un truc constant).
Je vais me faire trucider, mais temps pis, je me lance.
5 news "infos locales" en première page, je trouve qu'on atteint la limite du supportable.
Ne pourrait-on pas mettre tout cela dans la rubrique locale directement et ne pas polluer la première page ?
1/ ces infos locales ne génèrent quasiement jamais de commentaires (ou si peu).
2/ elles poussent des infos interessantes en première page vers la sortie.
bref, je suis évidement heureux de voir toutes ces initiatives qui se multiplient, preuve s'il en faut du succès de linux et de la bonne volonté de sa communeauté, prête a investir de son temps .... mais si on annonce toutes ces initiatives, bientot il n'y aura plus de place pour les autres news.
Après toutes ces lectures intéressantes, je ne résiste pas a répondre à mon tour. J'adore les BSD, et unix en général. Bsd force le respect c'est certain. Par contre je voudrais revenir sur certains points:
vous comparez BSD et linux en parlant principalement du kernel puis reprochez des faits qui tiennent de l'intégration d'une distribution sans la nommer.
linux (le kernel) n'est pas un unix. Il convient donc de comparer une distribution linux et BSD pour etre objectif (est-ce possible ?).
ensuite en vrac:
-non Torvald n'est pas un dictateur, il aime bien avoir le dernier mot mais change d'avis quand ses interlocuteurs savent démontrer que leur point de vu est meilleur TECHNIQUEMENT. Cela me parait assez sain comme gestion.
-non sous linux tout n'est pas installé, les daemons démarrés ... il faudrait parler d'une distribution pour savoir, mais sachez que je ne connais pas de distribution qui ouvre tous les ports par défaut (du moins je n'en connais plus).
-les scripts iptables sont moins lisibles que les scripts ipfw ?? a voir.
-les développeurs linux ont analysé la VM de BSD et décidé ensuite de s'en inspirer en essayant d'améliorer certaines lacunes. ce n'est pas forcement une réussite pour le moment je te l'accorde, mais laisse leur du temps. d'un autre coté, faire un copier coller de la VM de BSD c'est pas très interessant non plus.
-la stack IP a été réécrite moulte fois sous linux, elle n'est plus si mauvaise que cela, à mon avis (subjectif bien sur), c'est comparable.
-le kernel BSD était simple à optimiser car uniprocesseur. Les developpeurs de linux ont choisi (a tord ?) de s'attaquer à plein de problème en parallele et de se lancer dans le multiprocesseur très rapidement. De ce coté le kernel linux a une avance certaine sur BSD (lequel ?)... mais BSD travaille sur ce point depuis quelques releases.
-a mon avis on parle de Linux plus de BSD par simple effet de mode. BSD et son système de développement fermé n'a pas su attirer autant de monde que linux. Dans linux ce qui a plu aux gens au départ c'est que TOUT LE MONDE peut proposer un patch à inclure dans le noyau. Maintenant la base installée est beaucoup plus grande que celle des BSD ... d'ou le bruit autour de linux.
Cela ne doit avoir aucune incidence sur les qualités des 2 OS, la pub n'a jamais été un critère de qualité !!
Enfin, j'aime bien ces discussions BSD/Linux car d'elles nait une émulation qui pousse les 2 OS dans leurs retranchements. On voit apparaitre les lacunes de chacun d'eux et les developpeurs piqués au vif n'ont plus qu'a remettre le travail sur le métier. Que du bon !!
La "guerre" BSD/Linux n'aura pas lieu car seuls les ignares "fou de linux/fou de BSD" la propage. Ceux qui codent ces systèmes sont au dessus de cela.
pour le DBA oracle, pas de différence.
surtout si il administre a distance avec l'outil oracle sous windows qui va bien :-)
que veux-tu savoir ?
les raw device sont gérés sous linux en 2.4 mais tout le monde (quasiement) stocke ses données oracle dans des fichiers depuis que les filesystèmes sont performants.
maintenant les couples hard/unix.
les PC sont des architectures intel viellissantes, patchées a coup de cascade DMA et aures subterfuges. Il est évident que les machines SUN, SGI, ... sont mieux foutues.
Donc pour oracle, les perf sur une machine bien concue sera meilleure. A la limite tu pourrais faire tourner une base consequente sur un PC maquillé en serveur a coup de cartes scsi spéciales ou carrement une baie de disque externe ...
les différences déjà notées dans les commentaires font plus état des avantages/inconvénients à administrer la machine. Oracle s'administre de la meme facon sur tous les unix, un peu différement sous windows ...
honnetement je ne vois pas d'avantages a faire tourner oracle sur un linux, sinon le cout de la machine+os. Mais normalement les données sont la richesse première d'une entreprise et le cout d'une solution de bdd éprouvée ne devrait pas être rédibitoire.
autre chose: après comparaison sur le meme matériel de type PC il vaut mieux faire tourner oracle sur linux que oracle sur windows (coefficient multiplicateur des perfs genre x2 ou x3). Donc linux te permet a toi admin oracle de faire tourner de petites bases pour tester tes scripts et autres goodies. ca c'est déjà pas mal.
j'ai déjà fait tourner oracle8 + apache + Jserv + des servlet sur un portable...
En fait je pense que tu es a coté du problème soulevé par cet incapable.
En général, les trous de sécurité sont publiés (bugtrack ...) APRES que l'editeur du logiciel concerné ai été prévenu et APRES qu'il ait répondu/pondu un patch.
Il est courant de lire des annonces de bug stipulant que la firme bidule a été prévenue 3 mois plus tôt.
Mais les vers internet ciblant IIS se sont répandu malgré l'existance des patchs. De ce coté la, MS n'y peut pas grand chose (ok ils auraient pu faire un soft sans bug dès le départ, mais personne n'est à l'abris d'un bug ...). MS avait daigné répondre lors de la décourverte du bug, l'annonce sur bugtrack à été faite APRES que le patch existe ...
De ce coté la rien à redire donc.
Si on veut améliorer la situation il y a plusieurs voies possibles:
1/ upgrade système automatique à travers internet. oui mais faut faire confiance à MS (qualité des patchs) et ne pas avoir a rebooter la machine n'importe quand ...
2/ faire confiance aux admins NT, on a vu ou cela nous mène, on recoit TOUJOURS des scan sur le port 80 de nimda!!
3/ la nouvelle solution MS: ne plus prévenir des trous de sécurité, on diminue le nombre d'attaques (script kiddies), par contre les attaques qui restent sont quasiement impossible à contrer puisque seuls les black-hat ont les connaissances pour hacker les machines.
4/ y ont il pensé ? vendre un service de maintenance avec l'OS qui permette d'assister (et d'insister) pour patcher les machines.
On ne pourra pas contrer les ".doc" de microsoft sans format standardisé qui offre les memes possibilités.
a savoir:
1/ envoyer un document a qqun (le pdf fait cela tres bien)
2/ envoyer un document de travail a qqun. la le pdf ne marche pas, c'est difficile a modifier, du coup le .doc est de mise des que l'on veut être sur que le destinataire pourra en faire quelque chose (et encore ...).
j'espérai que ce standard soit aux documents ce que l'opensource est aux logiciels. Que l'on puisse enfin décider de livrer un document binaire/compilé (pdf) ou source/modifiable ( xsl-fo ?)
bon apparement d'après les premières réponses, ce format serait un peu l'équivalent du .o dans une compilation, reste plus qu'a linker vers le binaire adéquat, mais on ne dispose pas vraiment du source ... domage.
les applis qui sauront produire du xsl-fo seront donc garanties que derriere des traducteurs adequat permettront d'imprimer, de pdfiser ... c'est déjà ca (mais est-ce que cela apporte beaucoup par rapport au pdf ?).
[^] # Re: Euh...
Posté par PLuG . En réponse à la dépêche Comparatif des VM de Linux et FreeBSD. Évalué à 5.
mesures pour que l'on voit si d'autres parametres sont venus limiter les perfs.
il aurait fallu donner les courbes cpu/network/io/... sur les serveurs et sur les injecteurs pour en savoir plus.
Je note quand meme autre chose de ce bench: le scheduleur de BSD m'est toujours apparu comme plus rapide que celui de linux. Dans ce test, on voit de nouveau que linux est plus lent pour creer et detruire des process... si je me souviens bien la tendance est inversée pour les threads (plus rapide sous linux). Peut etre le prochain bouleversement du kernel sera de travailler sur le scheduleur ?
# conseil aupres de linus
Posté par PLuG . En réponse à la dépêche Linus dans le top25 des chefs d'entreprises. Évalué à 10.
voici ce que j'obtiens en cliquant sur le lien:
Microsoft OLE DB Provider for ODBC Drivers error '80040e14'
[Microsoft][ODBC SQL Server Driver][SQL Server]Line 1: Incorrect syntax near '='.
/templates/GlobalItems/sql_createarticle.asp, line 55
[^] # Re: Redimensionnement?
Posté par PLuG . En réponse à la dépêche EXT3 : intégration dans l'arbre de source du noyau de Linus.. Évalué à 7.
conclusion: ca marche bien si tu ne profites pas d'un crash pour repartitionner ton disque ...
faut pas (trop) pousser non plus :-)
[^] # Re: Nouveau système de fichier
Posté par PLuG . En réponse à la dépêche EXT3 : intégration dans l'arbre de source du noyau de Linus.. Évalué à 10.
je rajoute quand meme mes 2 eurocents:
la journalisation a un cout, comme l'ont dit certains en dessous. Du coup je vous conseille la lecture de ce papier ultra court de redhat sur le tuning de ext3. Ils indiquent les parametres qui ont une influence sur les perfs et donnent des exemples (tout en precisant bien qu'il n'y a pas de tuning applicable partout, faut le faire au cas par cas évidement).
url: http://www.redhat.com/support/wpapers/redhat/ext3/index.html(...)
[^] # Re: Comment on fait quand c'est des problemes de disques?
Posté par PLuG . En réponse à la dépêche Comment rédiger le certificat de décés de sa boiboite Linux. Évalué à 5.
sinon, le freeze du bus scsi c'est courant quand un peripherique ne veut plus rendre le bus (chaque periph a un lock dessus quand il s'en sert). normalement l'os devrait faire un reset du bus au bout d'un certain temps.
les cartes tekram sont super bien supportées par linux (drivers GPL dispo sur le site de tekram et inclus dans le kernel), d'ailleur il y en as une nouvelle version (une re-ecriture complete en fait) pour supporter plus de chipsets differents (dispo dans linux-2.4.13-ac8).
verifie ton cablage, et tes terminaisons, ca a l'air con mais ca peut le faire. verifie aussi le mode d'acces (wide/narrow, synchrone/asynchrone).
je ne crois pas au probleme de driver. donc plus basique, dans l'ordre: cable / peripheriques / controleur.
[^] # Re: La news est déjà passée le 04/11
Posté par PLuG . En réponse à la dépêche Linus Torvalds : 'Tout le monde se plaint de Windows'. Évalué à 8.
Ben voila, on preche a longueur de commentaires sur DLFP pour l'armonisation des protocoles afin que toutes les machines puissent communiquer entre elles, et quand ils s'agit de faire communiquer des humains on est contre les solutions simples qui s'imposent :-)
</provoc>
honnetement, Internet peut tres bien véhiculer toutes les langues qui existent. mais il faut bien reconnaitre que nous avons besoin d'un protocole "universel" pour causer à tous les terriens maintenant que le réseau des réseaux propage la bonne nouvelle instantanément sur la planette. Cela me désole, mais ce n'est pas le francais qui va s'imposer dans ce role, ni l'espéranto pourtant fait pour ca.
Mais de la à dire que notre langue va disparaitre. quoi que après l'unification des monaies en europe, faudra bien choisir une langue "européenne"... dans quelques années hein, pour le moment les européens ne sont pas prets pour ca!
[^] # Re: La news est déjà passée le 04/11
Posté par PLuG . En réponse à la dépêche Linus Torvalds : 'Tout le monde se plaint de Windows'. Évalué à 10.
Pour moi ? non c'est pas très important vu que j'ai la chance de lire l'anglais assez bien, surtout l'anglais technique. Comme tout passionné d'informatique 80% de mes lectures sont en anglais.
Par contre je comprends très bien ta remarque, puisque la langue peut etre un probleme pour certains et que linuxfr est ... francais.
Je comprends aussi l'annonyme "premier du nom", puisque cette nouvelle est déjà parue, un titre du genre "version frenchie de la news du 04/11" avec le lien sur l'ancienne news aurait été pas mal (normalement les commentaires devraient etre applicables aux 2 et eux sont en francais !!).
ok ca chipotte pas mal la :-)
[^] # Re: problème...
Posté par PLuG . En réponse à la dépêche Noyau 2.4.14 out. Évalué à 3.
Donc tu revois la config de tes noyaux et tu inclus le support ELF (pas en module hein, inclus DANS le noyau il en as besoin tout le temps de toutes facons).
Autre chose, il parait qu'il vaut mieux enseigner la peche que refiler du poisson, je vais donc te refiler LE TRUC de hacker qui permet de se sortir de presque tous les problemes sous linux: ... http://www.google.fr,(...(...))">http://www.google.fr,(...(...(...)))">http://www.google.fr,(...(...)">http://www.google.fr,(...(...(...))">http://www.google.fr,(...(...(...(...))))">http://www.google.fr,(...(...(...))">http://www.google.fr,(...(...(...(...)))">http://www.google.fr,(...(...(...)">http://www.google.fr,(...(...(...(...))">http://www.google.fr,(...(...(...(...(...)))))">http://www.google.fr,(...(...)">http://www.google.fr,(...(...(...))">http://www.google.fr,(...(...(...(...)))">http://www.google.fr,(...(...(...)">http://www.google.fr,(...(...(...(...))">http://www.google.fr,(...(...(...(...(...))))">http://www.google.fr,(...(...(...(...))">http://www.google.fr,(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...)">http://www.google.fr,(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...))))))">http://www.google.fr,(...(...(...))">http://www.google.fr,(...(...(...(...)))">http://www.google.fr,(...(...(...)">http://www.google.fr,(...(...(...(...))">http://www.google.fr,(...(...(...(...(...))))">http://www.google.fr,(...(...(...(...))">http://www.google.fr,(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...)">http://www.google.fr,(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...)))))">http://www.google.fr,(...(...(...)">http://www.google.fr,(...(...(...(...))">http://www.google.fr,(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...)">http://www.google.fr,(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...))))">http://www.google.fr,(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...(...)">http://www.google.fr,(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...)))))))">http://www.google.fr,(...(...)">http://www.google.fr,(...(...(...))">http://www.google.fr,(...(...(...(...)))">http://www.google.fr,(...(...(...)">http://www.google.fr,(...(...(...(...))">http://www.google.fr,(...(...(...(...(...))))">http://www.google.fr,(...(...(...(...))">http://www.google.fr,(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...)">http://www.google.fr,(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...)))))">http://www.google.fr,(...(...(...)">http://www.google.fr,(...(...(...(...))">http://www.google.fr,(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...)">http://www.google.fr,(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...))))">http://www.google.fr,(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...(...)">http://www.google.fr,(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...))))))">http://www.google.fr,(...(...(...(...))">http://www.google.fr,(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...)">http://www.google.fr,(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...))))">http://www.google.fr,(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...(...)">http://www.google.fr,(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...)))))">http://www.google.fr,(...(...(...(...)">http://www.google.fr,(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...(...)">http://www.google.fr,(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...))))">http://www.google.fr,(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...(...(...)">http://www.google.fr,(...(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...(...))))))))">http://www.google.fr,(...(...(...))">http://www.google.fr,(...(...(...(...)))">http://www.google.fr,(...(...(...)">http://www.google.fr,(...(...(...(...))">http://www.google.fr,(...(...(...(...(...))))">http://www.google.fr,(...(...(...(...))">http://www.google.fr,(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...)">http://www.google.fr,(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...)))))">http://www.google.fr,(...(...(...)">http://www.google.fr,(...(...(...(...))">http://www.google.fr,(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...)">http://www.google.fr,(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...))))">http://www.google.fr,(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...(...)">http://www.google.fr,(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...))))))">http://www.google.fr,(...(...(...(...))">http://www.google.fr,(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...)">http://www.google.fr,(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...))))">http://www.google.fr,(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...(...)">http://www.google.fr,(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...)))))">http://www.google.fr,(...(...(...(...)">http://www.google.fr,(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...(...)">http://www.google.fr,(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...))))">http://www.google.fr,(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...(...(...)">http://www.google.fr,(...(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...(...)))))))">http://www.google.fr,(...(...(...)">http://www.google.fr,(...(...(...(...))">http://www.google.fr,(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...)">http://www.google.fr,(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...))))">http://www.google.fr,(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...(...)">http://www.google.fr,(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...)))))">http://www.google.fr,(...(...(...(...)">http://www.google.fr,(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...(...)">http://www.google.fr,(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...))))">http://www.google.fr,(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...(...(...)">http://www.google.fr,(...(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...(...))))))">http://www.google.fr,(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...(...)">http://www.google.fr,(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...))))">http://www.google.fr,(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...(...(...)">http://www.google.fr,(...(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...(...)))))">http://www.google.fr,(...(...(...(...(...)">http://www.google.fr,(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...(...(...)">http://www.google.fr,(...(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...(...))))">http://www.google.fr,(...(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...(...(...(...)">http://www.google.fr,(...(...(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...(...(...)))))))))">http://www.google.fr,(...(...)">http://www.google.fr,(...(...(...))">http://www.google.fr,(...(...(...(...)))">http://www.google.fr,(...(...(...)">http://www.google.fr,(...(...(...(...))">http://www.google.fr,(...(...(...(...(...))))">http://www.google.fr,(...(...(...(...))">http://www.google.fr,(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...)">http://www.google.fr,(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...)))))">http://www.google.fr,(...(...(...)">http://www.google.fr,(...(...(...(...))">http://www.google.fr,(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...)">http://www.google.fr,(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...))))">http://www.google.fr,(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...(...)">http://www.google.fr,(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...))))))">http://www.google.fr,(...(...(...(...))">http://www.google.fr,(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...)">http://www.google.fr,(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...))))">http://www.google.fr,(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...(...)">http://www.google.fr,(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...)))))">http://www.google.fr,(...(...(...(...)">http://www.google.fr,(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...(...)">http://www.google.fr,(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...))))">http://www.google.fr,(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...(...(...)">http://www.google.fr,(...(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...(...)))))))">http://www.google.fr,(...(...(...)">http://www.google.fr,(...(...(...(...))">http://www.google.fr,(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...)">http://www.google.fr,(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...))))">http://www.google.fr,(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...(...)">http://www.google.fr,(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...)))))">http://www.google.fr,(...(...(...(...)">http://www.google.fr,(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...(...)">http://www.google.fr,(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...))))">http://www.google.fr,(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...(...(...)">http://www.google.fr,(...(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...(...))))))">http://www.google.fr,(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...(...)">http://www.google.fr,(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...))))">http://www.google.fr,(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...(...(...)">http://www.google.fr,(...(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...(...)))))">http://www.google.fr,(...(...(...(...(...)">http://www.google.fr,(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...(...(...)">http://www.google.fr,(...(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...(...))))">http://www.google.fr,(...(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...(...(...(...)">http://www.google.fr,(...(...(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...(...(...))))))))">http://www.google.fr,(...(...(...(...))">http://www.google.fr,(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...)">http://www.google.fr,(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...))))">http://www.google.fr,(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...(...)">http://www.google.fr,(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...)))))">http://www.google.fr,(...(...(...(...)">http://www.google.fr,(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...(...)">http://www.google.fr,(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...))))">http://www.google.fr,(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...(...(...)">http://www.google.fr,(...(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...(...))))))">http://www.google.fr,(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...(...)">http://www.google.fr,(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...))))">http://www.google.fr,(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...(...(...)">http://www.google.fr,(...(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...(...)))))">http://www.google.fr,(...(...(...(...(...)">http://www.google.fr,(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...(...(...)">http://www.google.fr,(...(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...(...))))">http://www.google.fr,(...(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...(...(...(...)">http://www.google.fr,(...(...(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...(...(...)))))))">http://www.google.fr,(...(...(...(...)">http://www.google.fr,(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...(...)">http://www.google.fr,(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...))))">http://www.google.fr,(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...(...(...)">http://www.google.fr,(...(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...(...)))))">http://www.google.fr,(...(...(...(...(...)">http://www.google.fr,(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...(...(...)">http://www.google.fr,(...(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...(...))))">http://www.google.fr,(...(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...(...(...(...)">http://www.google.fr,(...(...(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...(...(...))))))">http://www.google.fr,(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...(...(...)">http://www.google.fr,(...(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...(...))))">http://www.google.fr,(...(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...(...(...(...)">http://www.google.fr,(...(...(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...(...(...)))))">http://www.google.fr,(...(...(...(...(...(...)">http://www.google.fr,(...(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...(...(...(...)">http://www.google.fr,(...(...(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...(...(...))))">http://www.google.fr,(...(...(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...(...(...)))">http://www.google.fr,(...(...(...(...(...(...(...(...)">http://www.google.fr,(...(...(...(...(...(...(...(...(...))">http://www.google.fr,(...(...(...(...(...(...(...(...(...(...)))))))))) ici une simple recherche de "binfmt-464c" donne pleins de réponses, tu n'es pas le premier a compiler un noyau sans support ELF.
[^] # Re: Un bug dans la compil d'une release
Posté par PLuG . En réponse à la dépêche Noyau 2.4.14 out. Évalué à -1.
la branche du noyau c'est le second chiffre.
2.4 ==> branche stable car 4 est un nombre pair.
2.5 ==> branche instable (dev) car 5 est impair.
2.4.13 etait déjà un noyau "stable" comme tous les noyaux 1.0, 1.2, 2.0,2.2 et 2.4
2.5 n'existe pas encore, c'est bien/mal c'est un autre débat.
maintenant c'est sur que un kernel qui ne compile pas ca fait pas tres pro --meme en version instable--. c'est d'ailleur pas la premiere fois, il fallait deja modifier le 2.4.6 pour compiler les modules ntfs ...
[^] # Re: C'est marrant...
Posté par PLuG . En réponse à la dépêche Wireless 802.11b Sniffing. Évalué à 7.
les voisins peuvent sniffer ton réseau sans violation de propriété privée, à distance et au chaud. vraiment le wireless c'est une avancée technique interessante !!
[entre (), vous conseillez quoi comme équipement pour un réseau wireless pas cher sous linux ?,
parce que la je suis un peu intéressé...]
[^] # Re: Monopole
Posté par PLuG . En réponse à la dépêche Wireless 802.11b Sniffing. Évalué à 3.
le probleme avec les transmissions lazer etant l'alignement des emetteur et recepteur (en plus de choisir un emplacement dénué d'obstacles pour le faisceau), si le signal passe de voisins en voisin, un coup de vent un peu fort et hop plus personne n'est connecté parce que l'un des voisins avait mal fixé son équipement ...
pas très valable à mon avis, d'ailleurs c'est assez peu utilisé comme liaison.
[^] # Re: Noyau 2.4.7 ?
Posté par PLuG . En réponse à la dépêche Red Hat 7.2 dispo. Évalué à 2.
j'ai pas eu le temps de rajouter que les packages squid et ssh sont aussi à réinstaller.
ca nous fait donc comme upgrade sécurité:
kernel, ssh, squid et util-linux
c'est quand meme la première fois que la distrib est à patcher AVANT qu'elle ne soit downloadée. faites votre propre iso 7.2+ avec la doc qui va bien ( http://cambuca.ldhs.cetuc.puc-rio.br/RedHat7-CDs-HowTo.html(...) ) si vous devez installer plusieurs machines ... ou pour la frime (de toutes facons dans 1 mois il y aura plein de patchs à passer).
[^] # Re: Noyau 2.4.7 ?
Posté par PLuG . En réponse à la dépêche Red Hat 7.2 dispo. Évalué à -1.
New util-linux packages are available that fix a problem with /bin/login's
PAM implementation. This could, in some non-default setups, cause users to
receive credentials of other users. It is recommended that all users
update to the fixed packages.
2001年10月22日: Packages are now available for Red Hat Linux 7.2. Notably,
these packages also fix the problem noted in RHSA-2001:095-04 (vipw
incorrectly setting permissions on some files) - this bug was accidentally
reintroduced in Red Hat Linux 7.2.
[^] # Re: Noyau 2.4.7 ?
Posté par PLuG . En réponse à la dépêche Red Hat 7.2 dispo. Évalué à 10.
D'ailleurs les noyaux redhat sont des -ac aménagés, quand on défait un rpm source du noyau pour voir, il y a une multitude de patchs qui sont appliqués avant la compilation ...
[^] # Re: Retro-ingénierie != spec ouvertes
Posté par PLuG . En réponse à la dépêche Lettre ouverte à Bill. Évalué à 1.
Ce qui est fondamentalement mauvais dans la protection des médias (cd audio, dvd, k7...) c'est que la fonction meme de ces média est de livrer les données à l'utilisateur final. crypter ces données c'est aussi donner les moyens de les décrypter pour les utiliser, ce qui ramène obligatoirement à la case départ: l'utilisateur à accès aux données qu'il vient d'acheter, et le cryptage n'a servi à rien [sinon vendre des clefs :-))].
Microsoft n'est pas obligé de filer les specs de ses modifications du protocole kerberos ( ? ,c'est une question !), si il ne veut pas que les autres machines puissent communiquer avec les siennes (par contre, on pourrait interdire à MS d'utiliser le terme kerberos dans la mesure ou il s ne sont pas 100% clients kerberos), par contre la RIAA ne vends pas les apareils de lecture, il faut donc bien qu'elle vende des clefs de decryptage !!
[^] # Re: Espionage industrielle.
Posté par PLuG . En réponse à la dépêche Frenchelon dans le texte. Évalué à 10.
Leur propos étaient alors qu'une guerre avait bien lieu en ce moment entre la France et d'autres pays: la guerre de l'information.
Les mecs de la DST qui nous "dégrossissaient" travaillaient pour un service faisant des cours et des interventions en entreprises.(grosses les entreprises, genre Matra, EDF, FT, Elf ...), pour apprendre aux gens a utiliser un broyeur systématiquement...
le plus gros des informations sont dans la poubelle.
[^] # Re: encore !!
Posté par PLuG . En réponse à la dépêche Deux Install Fest simultanées... dans le Nord. Évalué à 2.
d'ailleurs depuis quand anonyme est modérateur ? tu aurai pu au moins te présenter (a moins que tu ne soit qu'un hoax ?)
quand aux nouvelles qui passent, c'est clair que le tri doit etre difficile. j'avais pour ma part envoyé une news qui présentait la nouvelle version d'un document sur la sécurité des applications, au niveau architecture des applis, langage utilisé, base de données, etc. ce document est généraliste mais bourré de liens pour approfondir les sujets ...
la news n'est jamais passée ... a la place on a eu des trucs microsoft à troll et d'autres infos qui m'interessent moins.
modérateur c'est surement dur, mais poster des news c'est aussi dans un but de partage avec les autres, le document sur la sécurité que j'avais proposé, je l'ai lu moi, donc je ne vois pas d'interet spécial a ce que vous passiez "ma" news... il faut aussi considérer le travail que représente l'écriture d'une news, et veiller a encourager ceux qui en envoient !
[^] # Re: encore !!
Posté par PLuG . En réponse à la dépêche Deux Install Fest simultanées... dans le Nord. Évalué à 0.
quand au débat paris/province, ce n'est pas du tout dans le sens de ma remarque. j'habite pres de versailles, je me décrit comme lyonnais, et non meme les infos locales à lyon ou versailles ne m'interessent pas, ma vie de famille m'empechant de toutes facon d'y participer.
je ne suis pas CONTRE les infos locales, il faut les publier et je posterai de nouveau pour me plaindre si elles n'étaient plus acceptées. Souvent il y a une ou 2 infos locales mélangées au reste et c'est très bien, mon commentaire disait plutot que si le nombre d'infos locales continu a augmenter (ce qui est bon signe), on ne trouvera plus les autres news sur ce site.
enfin, non le nombre de commentaires n'est pas révélateur de l'interet d'une news ... a cause des trolls. sinon, on apprends souvent pas mal de choses grace aux commentaires, parfois plus que dans la news. Je concois la richesse de linuxfr aussi par ses lecteurs grace à leurs commentaires. Si il n'y a pas de commentaires, linuxfr devient une revue de presse sans saveur, une liste de liens actualisée tous les jours ...
si on baisse le nombre de troll sans arguments et que l'on augmente les commentaires de points de vue différents (merci pbpg), on enrichit le contenu du site ... les news ici apportent plus que sur le journal du net ou voila ou l'afp GRACE AUX COMMENTAIRES.
[^] # Re: Questions pour les utilisateurs de BSD !
Posté par PLuG . En réponse à la dépêche FreeBSD sauvé ?. Évalué à 3.
linux chasse plusieurs loups a la fois, BSD un seul. il y a plus de developpeurs linux et ils livrent les modules experimentaux en les marquant comme tel alors que sous BSD ils attendent que cela soit fiable pour livrer, certes. ce sont des méthodes différentes.
Sous BSD si c'est livré c'est que cela marche, sinon tu t'en passe.
Sous linux, si un truc est VRAIMENT necessaire pour toi, tu peux essayer la version experimentale pour voir ... et en général elle fonctionne.
Quand a la question "pourquoi ré-ecrire ..."
parce que le but n'est pas le meme. le but de linux c'est que ses developpeurs s'amusent. Et pour se marrer il vaut mieux essayer de développer des idées nouvelles que d'implémenter un truc connu. la VM du 2.2 avait des lacunes (pas facilement scalable, tuning automatique pas terrible) qui fait qu'ils essaient d'autres trucs. le kernel linux est un truc de passionnés.
personnellement j'ai toujours passé mon temps à modifier mon train electrique dès qu'il tournait 15 minutes sans problèmes: ca marche, on pete tout et on essaie de faire mieux. aussi je comprends tout a fait le point de vu des dev de linux (et celui des utilisateurs de BSD si ils veulent un truc constant).
# encore !!
Posté par PLuG . En réponse à la dépêche Deux Install Fest simultanées... dans le Nord. Évalué à 10.
5 news "infos locales" en première page, je trouve qu'on atteint la limite du supportable.
Ne pourrait-on pas mettre tout cela dans la rubrique locale directement et ne pas polluer la première page ?
1/ ces infos locales ne génèrent quasiement jamais de commentaires (ou si peu).
2/ elles poussent des infos interessantes en première page vers la sortie.
bref, je suis évidement heureux de voir toutes ces initiatives qui se multiplient, preuve s'il en faut du succès de linux et de la bonne volonté de sa communeauté, prête a investir de son temps .... mais si on annonce toutes ces initiatives, bientot il n'y aura plus de place pour les autres news.
[^] # Re: Questions pour les utilisateurs de BSD !
Posté par PLuG . En réponse à la dépêche FreeBSD sauvé ?. Évalué à 10.
vous comparez BSD et linux en parlant principalement du kernel puis reprochez des faits qui tiennent de l'intégration d'une distribution sans la nommer.
linux (le kernel) n'est pas un unix. Il convient donc de comparer une distribution linux et BSD pour etre objectif (est-ce possible ?).
ensuite en vrac:
-non Torvald n'est pas un dictateur, il aime bien avoir le dernier mot mais change d'avis quand ses interlocuteurs savent démontrer que leur point de vu est meilleur TECHNIQUEMENT. Cela me parait assez sain comme gestion.
-non sous linux tout n'est pas installé, les daemons démarrés ... il faudrait parler d'une distribution pour savoir, mais sachez que je ne connais pas de distribution qui ouvre tous les ports par défaut (du moins je n'en connais plus).
-les scripts iptables sont moins lisibles que les scripts ipfw ?? a voir.
-les développeurs linux ont analysé la VM de BSD et décidé ensuite de s'en inspirer en essayant d'améliorer certaines lacunes. ce n'est pas forcement une réussite pour le moment je te l'accorde, mais laisse leur du temps. d'un autre coté, faire un copier coller de la VM de BSD c'est pas très interessant non plus.
-la stack IP a été réécrite moulte fois sous linux, elle n'est plus si mauvaise que cela, à mon avis (subjectif bien sur), c'est comparable.
-le kernel BSD était simple à optimiser car uniprocesseur. Les developpeurs de linux ont choisi (a tord ?) de s'attaquer à plein de problème en parallele et de se lancer dans le multiprocesseur très rapidement. De ce coté le kernel linux a une avance certaine sur BSD (lequel ?)... mais BSD travaille sur ce point depuis quelques releases.
-a mon avis on parle de Linux plus de BSD par simple effet de mode. BSD et son système de développement fermé n'a pas su attirer autant de monde que linux. Dans linux ce qui a plu aux gens au départ c'est que TOUT LE MONDE peut proposer un patch à inclure dans le noyau. Maintenant la base installée est beaucoup plus grande que celle des BSD ... d'ou le bruit autour de linux.
Cela ne doit avoir aucune incidence sur les qualités des 2 OS, la pub n'a jamais été un critère de qualité !!
Enfin, j'aime bien ces discussions BSD/Linux car d'elles nait une émulation qui pousse les 2 OS dans leurs retranchements. On voit apparaitre les lacunes de chacun d'eux et les developpeurs piqués au vif n'ont plus qu'a remettre le travail sur le métier. Que du bon !!
La "guerre" BSD/Linux n'aura pas lieu car seuls les ignares "fou de linux/fou de BSD" la propage. Ceux qui codent ces systèmes sont au dessus de cela.
[^] # Re: Quels sont les vrais avantages hardware/software ?
Posté par PLuG . En réponse à la dépêche Comparatif général des systèmes Unix propriétaires et Linux. Évalué à 4.
surtout si il administre a distance avec l'outil oracle sous windows qui va bien :-)
que veux-tu savoir ?
les raw device sont gérés sous linux en 2.4 mais tout le monde (quasiement) stocke ses données oracle dans des fichiers depuis que les filesystèmes sont performants.
maintenant les couples hard/unix.
les PC sont des architectures intel viellissantes, patchées a coup de cascade DMA et aures subterfuges. Il est évident que les machines SUN, SGI, ... sont mieux foutues.
Donc pour oracle, les perf sur une machine bien concue sera meilleure. A la limite tu pourrais faire tourner une base consequente sur un PC maquillé en serveur a coup de cartes scsi spéciales ou carrement une baie de disque externe ...
les différences déjà notées dans les commentaires font plus état des avantages/inconvénients à administrer la machine. Oracle s'administre de la meme facon sur tous les unix, un peu différement sous windows ...
honnetement je ne vois pas d'avantages a faire tourner oracle sur un linux, sinon le cout de la machine+os. Mais normalement les données sont la richesse première d'une entreprise et le cout d'une solution de bdd éprouvée ne devrait pas être rédibitoire.
autre chose: après comparaison sur le meme matériel de type PC il vaut mieux faire tourner oracle sur linux que oracle sur windows (coefficient multiplicateur des perfs genre x2 ou x3). Donc linux te permet a toi admin oracle de faire tourner de petites bases pour tester tes scripts et autres goodies. ca c'est déjà pas mal.
j'ai déjà fait tourner oracle8 + apache + Jserv + des servlet sur un portable...
[^] # Re: Et la marmotte ?
Posté par PLuG . En réponse à la dépêche Les trous de sécurité doivent rester secrets !. Évalué à -1.
parce que sur lip6 c'est un mirroir de ftp.redhat.com et que ce repertoire existe sur le ftp.redhat.com avec les memes droits ...
peut etre que tu compte demander a redhat pourquoi ?
[^] # Re: Toujours le même problème
Posté par PLuG . En réponse à la dépêche Les trous de sécurité doivent rester secrets !. Évalué à 10.
En général, les trous de sécurité sont publiés (bugtrack ...) APRES que l'editeur du logiciel concerné ai été prévenu et APRES qu'il ait répondu/pondu un patch.
Il est courant de lire des annonces de bug stipulant que la firme bidule a été prévenue 3 mois plus tôt.
Mais les vers internet ciblant IIS se sont répandu malgré l'existance des patchs. De ce coté la, MS n'y peut pas grand chose (ok ils auraient pu faire un soft sans bug dès le départ, mais personne n'est à l'abris d'un bug ...). MS avait daigné répondre lors de la décourverte du bug, l'annonce sur bugtrack à été faite APRES que le patch existe ...
De ce coté la rien à redire donc.
Si on veut améliorer la situation il y a plusieurs voies possibles:
1/ upgrade système automatique à travers internet. oui mais faut faire confiance à MS (qualité des patchs) et ne pas avoir a rebooter la machine n'importe quand ...
2/ faire confiance aux admins NT, on a vu ou cela nous mène, on recoit TOUJOURS des scan sur le port 80 de nimda!!
3/ la nouvelle solution MS: ne plus prévenir des trous de sécurité, on diminue le nombre d'attaques (script kiddies), par contre les attaques qui restent sont quasiement impossible à contrer puisque seuls les black-hat ont les connaissances pour hacker les machines.
4/ y ont il pensé ? vendre un service de maintenance avec l'OS qui permette d'assister (et d'insister) pour patcher les machines.
[^] # Re: enfin ??
Posté par PLuG . En réponse à la dépêche XSL-FO devient une recommandation. Évalué à 7.
a savoir:
1/ envoyer un document a qqun (le pdf fait cela tres bien)
2/ envoyer un document de travail a qqun. la le pdf ne marche pas, c'est difficile a modifier, du coup le .doc est de mise des que l'on veut être sur que le destinataire pourra en faire quelque chose (et encore ...).
j'espérai que ce standard soit aux documents ce que l'opensource est aux logiciels. Que l'on puisse enfin décider de livrer un document binaire/compilé (pdf) ou source/modifiable ( xsl-fo ?)
bon apparement d'après les premières réponses, ce format serait un peu l'équivalent du .o dans une compilation, reste plus qu'a linker vers le binaire adéquat, mais on ne dispose pas vraiment du source ... domage.
les applis qui sauront produire du xsl-fo seront donc garanties que derriere des traducteurs adequat permettront d'imprimer, de pdfiser ... c'est déjà ca (mais est-ce que cela apporte beaucoup par rapport au pdf ?).