Sébastien Koechlin a écrit 854 commentaires

Ca va faire rire quasiment tout le monde, mais le Hurd a une réponse élégante à ce genre de problèmes.

On ne pourrait vraiment pas le faire tourner sur un noyau Linux ?

Il me reste 42 Mo sur /dev/lobe-droit, mais le FS n'est pas génial pour stocker ce genre de choses, ou alors je fais du ménage sur /dev/lobe-gauche

Ca déplace le problème, on va avoir pleins de votes d'IP déclassé, et il y a probablement plein de monde qui utilise 10.0.0.42 et 192.168.0.42; il faudrait enregistrer le couple proxy + ip source

En mélangeant des votes sérieux (java) et des votes ayant une teneur en trollitude supérieur à 84% (Suse), ça risque un peu de perdre les gens.

Le partage des IRQ au niveau matériel ne pose pas réellement de problème, le bus PCI le fait naturellement, et sur x86 sous Linux, on peut partager une IRQ entre plusieurs cartes sous réserve que les drivers concernées le supporte. Les autres architectures font souvent cela naturellement. Je crois que le problème est essentiellement qu'à la base, cela n'avait pas été prévu. Il y avait plus d'interruptions que nécessaire, cela semblait large. Ceci pose des problèmes lorsqu'on n'est pas capable de déterminer qui a déclencher l'interruption, dans ce cas, seul le numéro de l'interruption permettait de savoir qui était le coupable. Le but du PC étant de faire une machine bon marché, ça coutait moins cher de s'arreter là.

~$ cat /proc/cpuinfo
cpu : 750FX
temperature : 16 C (uncalibrated)
clock : 800MHz
revision : 2.2 (pvr 7000 0202)
bogomips : 1589.24
machine : PowerBook4,3
motherboard : PowerBook4,3 MacRISC2 MacRISC Power Macintosh
detected as : 257 (iBook 2 rev. 2)
pmac flags : 0000000b
L2 cache : 512K unified
memory : 128MB
pmac-generation : NewWorld

- Cela n'a rien de spécifique à Linux, tous les OS souffrent de ce problème, on fait pareil avec un solaris, avec un windows - La commande kill est interne dans plusieurs shells justement pour ce genre de problème, sous Linux on peut même voir les processus en naviguant dans /proc, et dans certains cas (pas celui ci, mais dans les cas de dépassement de mémoire par exemple) ca permet de résoudre le problème si on a un shell root lancé - Il existe plusieurs patchs noyau qui réserve des ressources pour root, pour ejecter des processus qui font des bétises, par défault, il y a déjà des quotas qu'il est possible d'activer, en RAM, en CPU, en nombre de processus, plus le OOM killer qui récupère de la RAM quand il n'y a plus aucun espoir (mais que l'on n'a pas encore appelé le capitaine Flams)...

GNU/tail -f ?

tail -f /mon/fichier1 /mon/fichier2 /mon/fichier3

Les lignes sont précédés d'un entete qui reprends le nom du fichier.
Je dis GNU parceque par exemple les versions Solaris que j'ai essayé en sont incapables.

Si tu veux un écran par fichier, tu peux aussi combiner plusieurs tail dans un screen

J'imagine qu'Emacs est aussi capable de faire ton bonheur.

Il y a une commande pour reconstruire la base de donnée, au bout d'un moment c'est indispensable.

rpm --rebuilddb

chez moi ça a corrigé beaucoup de problèmes sur des machines ayant grimpé plusieurs versions sans réinstallation.

Si tu refuses les prélèvements auquels tu t'es engagé, alors que le contrat est toujours valable, UGC est en droits de lancer une procédure de recouvrement des sommes qu'ils n'ont pas perçu; en prime, ils ont très certainement le droit de te facturer les couts engagés par le recouvrement (par exemple envoi d'une lettre avec accusé de réception: 50 € + frais de traitement du dossier 125 € +... )

Relis bien le contrat avant de faire une bêtise pour voir exactement à quoi tu t'exposes !

Lorsqu'il n'y a pas les entêtes adéquats, les navigateurs récents utilisent un rendu en mode dit de compatibilité; se disant probablement à juste titre que la page n'a pas été généré dans les règles de l'art et que l'on risque de rencontrer pas mal d'erreurs.

Dans ce mode, le navigateur essaye de corriger les erreurs, il ne faut donc pas s'attendre à ce que le rendu soit exactement conforme à la norme.

Arg, le swap est sur la CF ?

A mon avis, ce n'est VRAIMENT pas une bonne idée. La flash est une mémoire qui ne permet qu'un nombre limité de re-écriture. J'imagine que la gestion du swap sous Linux n'utilise pas un algo pour distribuer de manière égale les écritures sur les différents blocs de la partition (ou du fichier); ceci condamne la CF à une fin de vie prématurée par rapport à ses spécification.

Quand je pense que pratiquement toutes les flashs des balladeurs MP3 et autres appareils photos sont utilisées avec des filesystems basé sur une FAT, c'est une grave erreur, les blocs de la FAT étaient re-écrits à chaque manipulation du FS, on fragilise prématurément quelques blocs.

Je pense qu'il est inutile de citer l'argument massue qui fait que tout le monde fait de la FAT ?

Ca ressemble fichtrement à un deadlock massif, tu utilises quelle version du noyau, et as-tu essayé de changer de version de noyau ?

Il y a une limite à cette analogie. Il ne s'agit pas de se rattrapper des fautes non controlé, il s'agit de se protéger d'une attaque volontaire.

Linus a refusé plusieurs fois d'intégrer ce genre de protection, sous prétexte que cela ne ferme pas le problème, il a donné au moins deux fois une méthode permettant d'exploiter un buffer overflow sur une machine disposant d'une pile non exécutable (il me semble qu'il faut modifier l'adresse de retour pour qu'elle pointe sur un appel à exec situé dans la partie exécutable du code, on se contente d'ajouter un niveau d'indirection).

Sa politique est plus ou moins la suivante (si j'ai bien compris): les dépassements de pile sont toujours exploitables malgré cette protection, ils sont simplement nettement plus compliqués à mettre en place et donc aussi à traquer.
Donc les dépassements de buffers seronts moins bien corrigés si ce patch est intégré. Le seul bénéfice serait une diminution temporaire des attaques jusqu'à ce que les hackers se soient mis à niveau.

Je ne sais pas si c'est le bon critère.

S'il y a des filles, je leur conseille de rester anonyme vu l'influence des hormones chez certains.

Bon courage, ramasse tes yeux.

Et au final, combien de personnes connaissent la structure de la base de données ?

Il me semble que les sites à grosse audience qui ont fait du Perl sont plutot un cauchemard à maintenir.

Pas besoin de sniffer, déjà, utiliser talkd à la place du serveur, ça évite d'avoir à le ré-écrire (même si ce n'est pas le plus compliqué)

Ensuite il ne reste plus qu'à modifier légèrement ytalk, à moins que le shell soit déjà une fonction implémentée.

Sinon il y avait jadis un truc appelé vtsplit ou quelque chose dans le genre pour avoir plusieurs programmes partagés dans un VT.

Une méthode graphique: vnc pour tout le monde, avec vision en mode lecture-seule pour ceux qui ne bossent pas.

Enfin lors d'une formation UnixWare 7.0, j'avais découvert un outils qui faisait déjà plus ou moins ça: le formateur lançait un shell, et ça s'affichait chez tous les formés sans qu'eux puissent interagir.

S'il suffit de poster des commentaires pour voter, il suffit d'aller dans les vieilles dépèches que plus personne ne lit et de poster n'importe quoi.

Suffit-il réellement de poster un commentaire sur la réunion du 35 mai 2001 du Lug de Grosville sur Saint Doux pour avoir le droit de voter ?

Et pour la structure de la table, il y a un document de référence ? Parqu'il n'est pas question de toucher au code et d'envoyer un patch sans connaitre la structure de la base; vu que toutes les données sont dans la base de donnée (ce qui est normal).

J'ai mis ça en place en 1999 dans une petite entreprise, avec xtel en plus.

Jamais je ne configure le ppp en connexion à la demande, on se retrouve toujours un jour ou l'autre avec un programme qui est resté ouvert, et qui balance un paquet sur le net toutes les 5 minutes, ça fait des factures dépassant les 300 € à la fin du mois.

A la place, j'utilise un script CGI qui permet de voir le status et de lancer ou couper la connexion. C'est accessible facilement par tout le monde.

Hylafax n'est pas évident à mettre en place, je ne me souviens plus des détails des problèmes.

Et puis dans le trio gagnant, il y a encore xtel qui permettait d'accéder à tous les services qui n'étaient pas encore disponibles sur le net.

Tout ça tourne toujours sur un 386SX16 avec 8Mo de RAM (un serveur Compaq qui avait été payé plus de 30kf neuf) et deux disques SCSI de 500 Mo en RAID 1.

Deux modems,
- le premier RNIS pour la connexion internet,
- le fax et xtel utilisait un pool composé des deux modems avec le non-RNIS en priorité.

Aujourd'hui, un abonnement ADSL à remplacé la connexion RNIS vers internet.

Voila un excellent article qui explique comment, une fois que l'on a bien initialisé les dicos, trier automatiquement le SPAM lors de sa réception :

http://linux.oreillynet.com/pub/a/linux/synd/2003/01/30/bogofilter.(...)

Au passage, en regardant les options, on trouve plusieurs choses intéressantes :

-u pour mettre à jour les filtres selon ce qui a été détecté (lorsque bogofilter détecte un spam, il l'ajoute à sa base de spam)

Ensuite pour rattraper le coup, il suffit de définir deux actions, une pour signaler que le mail n'était pas du SPAM (-N) et une autre pour signaler que le mail était du SPAM (-S).

De cette façon, le tri est automatique, et en cas d'erreur, bogofilter peut revoir ses filtres.

Ils étudient aussi les fontes côté client

Est-ce réellement coté client ? Parce qu'avec X, on mélange facilement les deux cotés.

Je ne vois pas trop l'intérêt de coller les fontes coté client, cela va justement augmenter la charge réseau, puisqu'il faudra alors envoyer les fontes au serveur afin qu'il puisse les afficher.

Ils devrait aller faire aussi un tour sur les machines des étudiants en informatique, autant traiter le mal à la base. On aurait moins de cliquouilleurs admin 2000 (j'ai joué avec la béta tout l'été m'sieur) et peut-être plus de développeurs JBoss.

Absolument pas d'accord, le boulot de mplayer, c'est d'afficher une vidéo, pas de gérer l'interface avec l'utilisateur.

La GUI doit être confié à un programme prévu pour cela. En plus, ça arrange tout le monde, parce qu'il est alors possible de faire une GUI en Qt pour KDE et une en Gtk pour Gnome, et encore une en Tk parce que quelqu'un avait envie.. Et tout ce beau monde peut profiter de mplayer plutot que de re-développer tout un tas de trucs qui existent déjà.