SoWhat a écrit 198 commentaires

Eh, j'ai jamais dit que j'avais une garantie sur mon Linux !!! Je disais juste que son affirmation précédente me semblait douteuse.
Marre de me faire moinsser parce que les gens ne savent pas lire et/ou comprendre un post. Pas besoin de pousser, je sors tout seul du site.

comment tu sais que tu n'as pas de virus ? tu veux dire que tu n'as pas de virus connu par ton antivirus?

ben ils ont interêt à avoir des contacts sérieux avec motorola parce que comme ils le disent eux même (enfin, lui même, vu que le site est pour le moment l'initiative d'une seule personne):

Extrait de Why open-ezx.org ?

[...]
However, Motorola have "locked down" the phone. They don't want their users to make use of Linux, but rather only use the J2ME API's for their own applications. They don't publish any SDK for development of native Linux applications :(
[...]

Et c'est bien là tout le problème. Ca fait franchement plus marketing qu'autre chose. Ceci dit, pour les avoir vu bricoler dessus en labo, en effet c 'est du linux, et les dev avaient l'air bien content.

Sur les 'simples' téléphones Motorola, tout ce qu'on a le droit de faire c'est du j2me. Alors ça change quoi d'avoir Linux ou un autre? C'est franchement plus du marketing qu'autre chose. L'accès au kernel et aux API linux, ils se les gardent pour eux et nous laissent les miettes ...
Alors si t'as des références, ça m'intéresse : fait tourner les liens !

GNU/Linux reproduit très bien les API Unix
Elles sont quand même normalisées, les API en quesiton. Ca s'appelle ANSI, POSIX, etc. Ces normes sont justement faites pour que tout le monde utilise la même API, avec un moteur différent sous le capot. POSIX = Portable Operating System Interface.
C'est donc très différent des API win32.

Il faut prendre de temps de lire *et* de comprendre les posts, car tu extrapoles mes propos de façon hallucinante ! Je ne critique pas du tout HAL, mais je me pose des questions sur l'utilisation qui peut en être faite.

http://www.freedesktop.org/wiki/Software_2fhal(...)

je n'ai pas du tout la même lecture de la phrase que toi:
(1) HAL sera mieux intégré dans KDE
(2) une nouvelle fenêtre s'ouvre quans un media est inséré

toi tu dis qu'il dit (1) puis (2)
moi je dit qu'il ((1) parce que (2))

La seule chose que je demande à HAL, c'est qu'il me détecte le périphérique correctement et qu'il me permette de l'utiliser. Mais j'avoue ne pas être allé voir dans le détail ce qu'il en disent dans freedesktop.

Windaube? c'est quoi.
Si le produit t'est insupportable au point de ne pas pouvoir l'écrire correctement, ne l'utilise pas et tu n'auras plus de problèmes avec. Dans le cas contraire, assume.

Meilleure intégration de HAL : lors de l'insertion d'un CD, ou une clef USB, une boite de dialogue apparaît suggérant quelques actions.

Tu veux dire que comme ça ressemble plus à Windows(TM) c'est mieux? Je trouve ça insuportable, on ne peut plus connecter un périphérique ou insérer un média sans qu'il y ait des fenêtres qui s'ouvrent partout.
(Je sais, on me retorquera qu'en allant dans 3 sous-menus planqués au fond d'un 'panneau de configuration' on peut le désactiver. arg ...).
Au lieu de présenter des nouveautés en toute objectivité, tu les présentes en suggérant son avis au lecteur. C'est pas bien ;)

Compile avec gcc et l'option -ansi ou -std=c89
Note que dans ce cas, le code source est standard mais pas le binaire généré.

un apt-get install tetex-extra plus loin, dpkg --listfiles tetex-extra | grep a4wideme revoie '/usr/share/texmf/tex/latex/misc/a4wide.sty'
au temps pour moi, donc ;)

En gros, au lieu d'attendre le résultat d'un gros select() pendant n secondes et de le dispatcher aux travailleurs, là les évènements devraient être distribués aux travailleurs en flux continu tout au long de ces n secondes.

Tu n'as pas bien compris comment fonctionne select : la fonction est bloquante *tant qu*''il n'y a pas d'évènements associés à tes sockets.
Si on se place dans le cas de la lecture, le select rend la main dès q'une des sockets à des données à lire. Tu ne perds donc pas de temps à scruter les sockets une par une s'il n'y a rien à faire, l'OS s'en charge pour toi. Il n'y a donc aucune perte de temps à scruter des choses inutiles. Et crois moi, l'OS fais souvent les choses très bien, souvent mieux que toi (et que moi). Dans le cas des FD_SET et de ses petits frères, ce sont souvent des macros qui font des tests sur des masques de bits, et crois moi c'est bien plus rapide que de lier et de délier des objets dans des listes!

Si on se cantonne à d'un programme mono-process, outre le fait que ce soit un bonheur à programmer par rapport à un programme multithread (pas de mutex à tout va), la difficulté dans ton cas concerne principalement la gestion de l'écriture, qui doit se faire en mode non bloquant. Là, pas de solution miracle: bien réfléchir !

A ce propos, je pense que tu pourrais prendre des idées dans ce qui se fait dans le monde objet, et plus précisément en ce qui concerne les patterns 'proactor' et 'reactor'. Ces patterns sont dédiés au démultiplexage et à la distribution d'évènements

Pas entièrement
Quelle partie de la question reste sans réponse ?

Et tu crois que 1 appel de select sur n socket est plus long que n appels de select sur 1 socket ?
Je crois que tu devrais plutôt revoir la conception de tout ce qui entoure cet appel à select. L'utilisation de threads peut simplifier la programmation mais ne va pas intrinsèquement augmenter la vélocité de l'éxécution.

Il y a une énorme documentation sur gcc, soit le C

Faux, archi faux.
La documentation de g++ est incluse dans celle de gcc.
$ man g++

NAME
gcc - GNU project C and C++ compiler

etc.

Lis un peu la doc en question et tu vas t'appercevoir qu'il y a des options qui sont spécifiques au C, d'autres au C++.

La description de ton problème n'est clair du tout:

1. tu dis que le _bête_ polling qui est basé sur select n'est pas très efficace
2. tu dis que tu réimplémentes
3. tu montres un pseudo-code de réimplémentation ... qui utilise select !

Le problème ne vient donc sans douet pas du select mais de l'utilisation que tu en fais. Dans ta première implémentation, as tu identifié que qui ne te permet pas de monter en charge (opérations bloquantes, charge CPU, autre) ?

Bien plus que la société, c'est la solution qui a été retenue qui est importante. Rien ne t'empèche de faire un appel d'offre basé sur un cahier des charges qui impose la portabilité et l'utilisation de protocoles et de standards ouverts. Quelle importance ensuite de qui développe, du moment que ce cahier des charges est respécté ? Evidemment, si les spécifications à partir desquelles a été fait l'appel d'offre sont foireuses, alors le pire est à craindre. Mais que ce soit, MS, Bull, Atos ou FT qui fasse le boulot, je ne vois pas bien la différence : il mangent tous du proprio au petit déj (oui, certains moins que d'autres).

Au lieu de crier au loup sur un nom, cherche peut être à en savoir plus sur la solution retenue et revient nous en dire plus. Je compte sur toi !

Cependant, je ne vois pas trop l'intérêt d'installer aujourd'hui une RH9 plutot qu'une Fedora Core 4 ou autre chose...

parce que:
1/ C'est la dernière version 'officielle' de la distib alors que Fedora est fait pour expérimenter ?
2/ Parce que Aucun programme tiers n'offre de support sur des Fedora (mais Redhat 7..9 et/ou RHEL)
3/ Parce qu'on utilise du matos qui n'a pas de driver pour le noyau 2.6 et qu'il faut donc utiliser un 2.4. Or 2.4, c'est jusqu'à Fedora Core 1b, pas plus. Et au niveau des mises à jour, Fedora Core 1, ben ça vaut franchement pas mieux qu'une RedHat 9.

etc.
Bref, chacun a ses raisons.

Mon pb devait en effet venir de là car j'avais renommé le fichier dsl-provider en wanadoo, pour que la ligne de commande soit plus simple (et pour pouvoir en créer plusieurs autre par la suite). Mais je n'avais pas répercuté ce renommage jusque dans ce fichier?

Comme tu as l'air de connaitre un peu ce fichier, j'ai un soucis avec:
voici le mien

[ ...]
auto wanadoo
iface wanadoo inet ppp
provider wanadoo
# please do not modify the following line
pre-up /sbin/ifconfig eth0 up # line maintained by pppoeconf
[...]

donc pppoeconf a ajouté la dernière ligne pour être sûr que l'interface eth0 soit activée avant de monter la cnx pppoe. En pratique, ça ne marche pas et je suis obligé de la faire moi même. Curieux, non ?

merci ;)
je viens de faire la manip, et c'est bon. les logs me disaient 'not replacing default route to eth0' , alors que le paramètre 'defaultroute' est bien déclaré. Me reste à éclaircir ce mystère, mais au moins j'arrive à démarrer la cnx à la mano.

je vais vérifier, mais le parmètre 'defaultroute' est bien déclaré dans le fichier /etc/ppp/peers/dsl-provider.

je ping avec des noms de machine. Je vais essayer avec des IP, dès fois que. Le log de la cnx pppoe me dit pourtant qu'il a les dns:

Sep 23 11:29:59 zz pppd[2158]: primary DNS address 80.10.246.130
Sep 23 11:29:59 zz pppd[2158]: secondary DNS address 80.10.246.3

dans le doute, je vais faire la manip.

T'as rien compris : il te parle de canards. Et tout le monde monde a le droit d'être un canard si il veut ;)

La situation actuelle en terme de format de documents hétérogènes et fermée est tellement insupportable que j'applaudie cette initiative. Il est quand même affligeant de constater qu'alors que les échanges de documents n'ont jamais été aussi faciles qu'aujourd'hui (internet, p2p, etc.) et que l'industrie informatique génére des revenus impressionants, aucun format de ce type n'ait encore été adopté de façon _universelle_. Cela parait pourtant tellement évident !
Si toutes les administrations imposaient que leur logiciel soit en mesure d'utiliser un tel format sans restrictions ni incompatibilités, la vie serait tellement plus simple pour la pérénité des documents et de leurs traitements. Je me moque bien qu'une administration achète le traitement de texte A ou B, fût il fermé, du moment que je peux manipuler par la suite les documents produits avec un autre logiciel.
Tout cela n'est il qu'une utopie, ou pensez vous que certains fonctionnaires arriveront à faire face à la mega-puissance de lobbying et de marketing que fait s'abattre sur eux les grandes compagnies ?