galactikboulay a écrit 620 commentaires

Exactement, on prend les armes et on va trancher la tête de ces sales parasites qui se croient supérieurs au commun des mortels, se font honteusement acheter par des entreprises privées et méprisent aussi scandaleusement la démocratie. Ces gens sont en principe là pour servir les intérêts du peuple, pas pour se servir eux.

Désolé d'être aussi extrémiste, mais voir ça ça m'énerve.

Installe le, il ne doit pas être proposé par défaut à l'installation.

Toujours avec rpmfind, le package correspondant pour Cooker est le suivant:

parted-1.6.21-1mdk.i586.rpm

http://www.rpmfind.net/linux/rpm2html/search.php?query=parted&s(...)

La taille de trame moyenne est en générale estimée à 256 octets plutôt que 1 Ko (ce qui est optimiste comme valeur).

Ton calcul ne me semble pas erroné dans l'idée, mais si il y a du NAT à gérer c'est plus complexe: il faut maintenir une table de translation en mémoire (en général, une table de hashage), et la réécriture des paquets n'est pas triviale. Ajouter à cela la gestion des protocoles spéciaux comme H.232 ou FTP où il faut aller plus en profondeur dans la trame.

Tout cela étant dit, je n'ai vraiment aucune certitude sur le matériel adéquat - j'ai proposé le pentium à 1.5 Ghz au feeling d'après mon expérience ;)
Ca serait intéressant que qqn qui a déjà mis en place ce genre de solutions pour des débits assez élevés fasse part de son expérience.

Excellent ce lien, j'étais justement à la recherche d'infos pour le multicast, où il est préférable d'avoir une carte capable d'écouter simultanément sur pas mal de groupes. En effet, au niveau IP, les adresses multicast vont de 224.0.0.0 à 239.255.255.255 et les 23 derniers bits sont utilisés pour générer l'adresse ethernet multicast.

Du coup je te pertinente allégremment pour ce lien super utile! :)

Je n'ai pas de chiffres sous la main, mais je pense qu'il vaut mieux prendre une machine relativement récente vu le débit (100 Mb/s, ce n'est pas négligeable), surtout s'il y a beaucoup de règles de firewall. La gestion du NAT et de protocoles un peu "tordus" qui nécessitent des traitements spécifiques (FTP en mode actif, H.323, etc.) impose également un surcroit de travail non négligeable.

Pour 100 Mb/s, je tablerais plus sur une machine de type Pentium à 1.5 Ghz qu'un Pentium 200 Mhz.

Au fait, quel système comptes-tu installer ? Linux, un *BSD, autre ?

Au fait, il y a des cartes réseaux qui font du calcul de checksum TCP et autres en hardware, ça peut être intéressant d'utiliser de telles cartes pour décharger la CPU de la machine.

Tu fais une compilation / installation à la main ou tu installes des packages .rpm ?

Pour le fichier "gb.qt.list" que tu n'as apparemment pas, il est fourni normalement par:

gambas-gb-qt-1.0.3-1mdk.i586.rpm

Voir:

http://www.rpmfind.net//linux/RPM/cooker/cooker/i586/media/contrib/(...)

Par contre, ce n'est pas dans /opt/gambas (après je ne sais pas si c'est toi qui fais de l'installation dans /opt ou si il y a des liens symboliques spécifiques à Mandrake...)

J'ai cherché "libintl.so.2" sur l'excellent rpmfind.net et j'ai trouvé ça:

Mandrake Cooker : libintl2-0.11.5-1mdk.i586.rpm

En espérant que ça puisse t'aider.

J'installe un autre serveur sur lequel se trouve Postfix+MySQL+Cyrus Imap. Il a fallu que je recompile les sources de postfix pour rajouter le support mysql et déployé un max de bidouilles pour arriver au résultat final.
Donc tout fonctionne. Et l'instant d'angoisse me tombe dessus. La feuille blanche...

Pourquoi ne pas tout simplement rédiger un document que tu vas découper en grandes étapes (ex: chapitre 1: compilation/installation de Postfix, chapitre 2: compilation/installation de MySQL, etc.) ?

Ensuite dans chaque étape, tu indiques comment tu as effectué la compilation (options passées au ./configure, pré-requis pour pouvoir effectuer la compilation, etc.). Indique ensuite où tu as installé le produit, et comment tu l'as configuré (par ex en montrant les extraits pertinents des fichiers de configuration).

Précise les embûches auxquelles tu as du faire face et comment tu les as résolues. C'est toujours bon de noter les subtilités de tel ou tel produit, à l'installation suivante, tu évites de galérer.

Après comme quelqu'un l'a dit très justement, ce n'est pas un roman, donc qqch de clair et concis de quelques pages est bien plus utile qu'une doc de 50 pages.

- La plus simple, si tu es root sur la machine qui fait tourner le sshd: tu changes le port 22 en port 80 ou 443, ou tu fais tourner un 2ème SSH si tu veux pouvoir continuer à te connecter sur le port 22. Il est possible que ça ne fonctionne pas avec des firewalls "intelligents" qui font une inspection du trafic poussée (remontée jusqu'au niveau 7 du modèle OSI, et qui par ex. vont vérifier que ce qui passe sur le port 80/tcp est bien des requêtes HTTP).

- L'autre solution est d'utiliser un proxy par dessus le protocole HTTP. Une recherche sur google devrait aider pour trouver un soft (j'ai vu http://www.nocrew.org/software/httptunnel.html(...) mais j'ignore ce que ça vaut). Le principe est de tunneler n'importe quoi sur http. C'est évident moins rapide que la 1ère méthode, du fait de l'encapsulation sur un protocole qui n'est à la base pas prévu pour ça. Il faut aussi pouvoir héberger l'autre coté du tunnel à l'extérieur.

Et ça c'est du poulet ?

> Solaris est beaucoup plus stable sous plateforme Sparc jamasi vu un kernel
> panic en 10 ans d'utilisation

"Beaucoup plus stable" tu pousses un peu.
Si Linux maîtrisait le hard et le soft se serait beaucoup plus simple. Je doute sérieusement que Solaris sous x86 soit plus stable que Linux si d'aventure tu trouves les drivers.

Bonjour, dans la série "j'apprends à lire":

"le processeur utilise un cache TLB"

Mouais, effectivement. Quoique mmap() parle plutôt de getpagesize() et mlock() de PAGESIZE définie dans <limits.h>

Quoiqu'il en soit, tant que tu respectes la contrainte imposée (offset multiple de PAGESIZE ou autre), tu te moques complètement de comment est réalisée l'implémentation derrière, et des particularités du CPU et de sa MMU. C'était le sens de mon message :)

Je ne suis pas convaincu que toutes les applis marchent après avoir changé PAGE_SIZE (qui est une macro définie dans /usr/include/asm/page.h).

Normalement une application ne doit pas se préoccuper de PAGE_SIZE ou de tout autre particularité de la mémoire virtuelle.

Au feeling, je n'ai pas l'impression que ça peut apporter un gain important.

Pour faire les conversions adresse mémoire virtuelle -> adresse physique, le processeur utilise un cache TLB (Translation Lookaside Buffer). A priori, je dirais que plus la taille des pages est grande, plus on peut stocker d'associations (adresse virtuelle, adresse physique) dans cette table. Mais je me trompe peut-être.

Merci pour toutes ces infos. J'avais déjà effectué quelques petites recherches et j'avais noté que les protocoles CAN et VAN, bien que standardisés, ne permettaient de gérer les équipements embarqués de manière homogène entre marques (codes d'identification des équipements, format des données, etc.). D'où l'apparition des normes OBD certifiées par l'ISO pour obtenir quelquechose d'un peu plus "portable".

En revanche, je me demande s'il est possible d'accéder aux réseaux CAN et VAN à partir de cette fameuse prise DIAG. Chaque constructeur est libre d'implémenter le nombre de réseaux qu'il souhaite dans ses voitures: par ex, chez Peugeot il y a un réseau CAN pour tout ce qui concerne le moteur, et 3 bus VAN pour tout ce qui est habitacle / confort (clim, essuie-glaces, tableau de bord et autres).

D'après le brochage de la prise DIAG, il semble que seul le CAN soit accessible (ce qui est un peu limité je trouve). Quelqu'un pour confirmer ?

C'est plus de la curiosité intellectuelle qu'autre chose :) D'ailleurs je ne vois pas trop ce qu'il serait possible de tuner de cette manière... surtout s'il faut embarquer un PC dans la voiture pour interagir avec l'électronique embarquée. Accessoirement, le tuning avec pot ninja / jantes 19" / aileron / spoiler et tout le carnage, c'est pas du tout mon dada. J'aurais un peu du mal à claquer des fortunes dans des équipements inutiles pour faire le kéké.

Excellent tout ça, je devrais arriver à me débrouiller!
Merci à tous pour vos réponses!

Je te conseille de jeter un oeil sur ce document:

http://www.tldp.org/LDP/lkmpg/2.6/lkmpg.pdf(...)

Il explique notamment comment créer des modules et jouer avec les appels systèmes. Je te recommande d'utiliser un module, ça t'évitera des phases de compilation / reboot qui sont pénibles pour ce style de développement. Si tu veux vraiment faire qqch d'intégré au noyau, tu peux tester avec UML, ça t'évitera d'avoir à redémarrer ta machine.

Pour ce qui est de placer les fichiers, si c'est un module, tu n'as pas à t'en soucier (-> dans ton répertoire de développement). Si c'est qqch d'intégré, ça dépend de ce que tu veux faire de ton appel système: par ex pour tout ce qui est IPC (mémoire partagée, sémaphores, files de messages), il y a un répertoire "ipc" spécifique dans l'arborescence des sources du noyau. Pour tout ce qui est relatif à la gestion mémoire, c'est dans "mm", pour les fichiers dans "fs" (open(), close(), etc).

D'après le manuel de LILO, le code d'erreur 0x01 correspond à une "Illegal Command" au niveau d'un disque. A mon avis, ton 2ème disque n'est pas vu du BIOS, ou qqch comme ça, ce qui fait que LILO n'est pas capable d'y accéder.

http://lea-linux.org/trucs/item.50.html(...) donne quelques infos
Je me suis appuyé sur /usr/share/doc/lilo/Manual.txt.gz pour trouver la signification de l'erreur.

Tout à fait, setenv est l'équivalent pour CSH / TCSH.

Tu pourrais au moins copier/coller le résultat du ./configure parce que là je ne vois pas comment on peut t'apporter une véritable aide.

Tu as installé un compilateur et les bibliothèques de développement nécessaires sur ton système au moins ? Parce que sinon tu n'iras pas loin...

Et comme ça a été dit, tu ferais mieux de prendre une version packagée pour ton système si elle existe, il y a de fortes chances que le packageur ait compilé une version aux petits oignons avec les options qui vont bien.

Je n'ai pas été voir les détails d'implémentation, mais je suppose qu'il y a une table des connexions TCP utilisant des adresses IPv6 dans le noyau. Chaque entrée dans la table contiendrait l'adresse source et l'adresse de destination.
Au niveau réseau, quand le kernel aurait à envoyer des paquets TCP, il construirait au niveau 3 des paquets IPv4 si l'adresse IPv6 correspond à une adresse IPv4 mappée, sinon des paquets IPv6.
Je spécule sur le fonctionnement du noyau mais ça doit être plus ou moins ça. Je regarderai les détails si ça t'intéresse.

Sur les systèmes *BSD, il semble que les sockets gèrent soit v4 soit v6 mais pas les 2 en même temps. Exemple sur mon FreeBSD 5.3:

tcp4 0 0 *.22 *.* LISTEN
tcp6 0 0 *.22 *.* LISTEN

Pour avoir un comportement similaire sous Linux, je pense qu'il faut faire la séquence socket() / bind() / accept() sur un socket ne gérant que le v4, puis après refaire la même chose avec du v6. La 2ème socket ne pourrait pas "binder" sur les adresses v4 comme c'est le cas habituellement vu que la 1ère socket a déjà pris la main. C'est ce que doit faire Exim je pense.

Pour ce que sort netstat, à mon avis il va lire ce qu'il y a dans /proc/net (fichiers tcp, tcp6, etc) et c'est tout. Je dirais qu'a priori, si tu as une socket "de type v6" sous Linux, elle est capable de recevoir en v4 et en v6, sauf si il y a eu une socket v4-only de créée explicitement avant.

En fait, sur un système comme Linux, les sockets sont capables de gérer IPv4 et IPv6 simultanément... Ce qu'il se passe, c'est que quand une adresse IPv4 est utilisée avec ce genre de socket, elle est "mappée" en adresse IPv6.

Par exemple, si tu as un serveur SSH (tournant sur le port 22/tcp), tu auras comme info au niveau de netstat:

tcp6 0 0 :::22 :::* LISTEN

Ce socket sera capable d'accepter des connexions IPv4 ou IPv6. Quand il s'agit d'une connexion IPv6, tu auras une ligne du style:

tcp6 0 0 ::ffff:10.2.2.2:22 ::ffff:172.16.155:39464 ESTABLISHED

Le "::ffff:" indique que c'est une adresse v4 mappée (jamais visible sur le réseau, uniquement au niveau applicatif).

Ok, mais chaque canal est-il indépendant des autres en terme de débit ? ou bien s'agit-il d'un débit global qui est partagé indifféremment entre les canaux ?

On pourrait aussi imaginer des règles de QoS qui font que la VoIP est plus prioritaire que le trafic "data", histoire qu'il n'y ait pas de latence ou de gigue trop importante, ce qui est très pénalisant pour ce type de flux. Quand il n'y a pas de VoIP, l'intégralité de la bande passante peut être employée pour de la data.
Je pense que c'est une méthode plus simple que de gérer une "séparation" de canal d'un point de vue technique.

Un nouveau à mon sens, il va se dire "tiens, un GNU/ devant le Linux là, je me demande ce que ça veut dire, d'un autre coté, je m'en fous, ça n'empêche pas le système de fonctionner, ou ça ne résoud pas mon pb de conf".