efuste a écrit 46 commentaires

Ok, désolé d'avoir empieté sur ton pallier.

(Enfin, d'après ce que j'en vois du pallier, t'as en plus poussé ma porte).

Bye a tous et bon vent.

Si j'ai écrit ce journal, c'est avant tout pour moi.

Si ca vous plait ou interresse, tant mieux.

Sinon, tant pis. Et un commentaire à deux balle c'est pas mieux qu'une présentation pourri.

Rien ne vous force a lire et si la présentation vous fait gerber (c'est vrai, j'ai fait aucun effort) alors passez votre chemin a moins que vous soyez sado-maso. Mais bon, ca ne me regarde pas.

Ouarf le troll !!!

La couche IPSEC de Linux (ipv4 et ipv6) est une réimplémentation 100% from scratch par David S Miller and Co.

Donc c'est maintenant natif sous Linux (pas la peine de se touner vers autre chose comme évoqué dans un autre message), et implémenté proprement (ca fait un paquet s'années qu'ils y réfléchissent et freeswan est un très bon retour dexpérience en ce qui concerne ce qu'il faut faire et pas faire).
Les rares intérêt de freeswan sont les suivant:
- plus vieux, plus éprouvé, mais ca doit changer par la force des choses.
- mieux "tuné" sur certains algo crypto.
- demon client userspace plus puissants/complet dans la version super freeswan : X509, etc...

L'intérêt de freeswan est donc minime, les quelques "optimisation" coté crypto doivent être reporté sur la crypto API et n'ont rien a voir avec IPSEC.
Et en ce qui concerne la partie userspace, on a le choix aujourd'hui entre les outils Kame, les outils BSD ou .... les outils Freeswan au travers de Openswan (le fork de freeswan + super freeswan) qui pour les kernel 2.6 utilise la couche kernel native:

For Kernel's 2.6.0 and higher, Openswan uses the built in IPsec support. Only the userland component of Openswan is required to use Openswan with a 2.6 series kernel.

Le support de la couche native des kernel 2.6 par Openswan n'est pas encore complète/parfaite, mais c'est plus que sur la bonne voie.

Donc pour résumer, Freeswan est mort, vive Freeswan !!!

Oui, heu, mais non.

Mac OS X, il fait ce qu'il faut: Il n'utilise pas OpenGL pour accélerer son moteur graphique, il utilise les primitives de la carte 3D utilisées entre autre pour implémenter OpenGL. En gros ce que j'ai exposé au dessus.

Ce n'est qu'une simple nuance, mais de taille !! et qui fait toute la différence.

Pense par exemple aux ATI (jsais plus quel modèle) le driver 2D XFree utilise le DRI (quand il est dispo) pour accélérer les surface XV (la video) en gros par rapport aux autre drivers, y a une copie mémoire de moins et c'est fait en dma par la carte et plus par ton cpu. Sur ma machine lors de décompression de divx ca peu faire une énorme différence (c'est un 586 et j'ai pas d'ati sniff). Ce n'est qu'un exemple basique et on pourrai aller beaucoup plus loin.

(AAaaarrrghhhhh, je l'avais dit, je me tais maintenant).

Et puis pour en rajouter:

Keith a beau être un killer en ce qui concerne X11 (le protocole), une bonne partie de son implémentation (scheduling, 2D, asynchronisme ...), la composition 2D etc ..., c'est un gars du soft et il y panne ke dalle au hard. Y a qu'a voir le nombre de driver de carte qui implémentent aujourd'hui correctement les accélérations render: acune a part la pour la matrox, fait par keith au tout début de render, et c'est pas glorieux.

De la même manière il y panne que dalle à opengl, franchement aux plus je vois ce genre de connerie et d'abération (au moins 50 fois par jour sur les différentes ml et formum) au plus j'ai envi de gerber et d'envoyer bouler mon navigateur et toutes ces discutions à deux balle.

P$@*$! de ~"&*$m de m...., OpenGL c'est une API et une énorme usine à gaz en terme d'abstraction, d'implémentation, de complexité, etc... à coté l'ensemble du code de XFree, de la gestion du protocole, au DDX du driver le plus complexe, en passant par XAA et tutiquanti, c'est du pipi de chat comparé à n'importe quelle version d'une implémentation d'OpenGL le support pour une carte graphique 3D quelconque.

Il y a trois millons de choses à faire ajourd'hui dans le code de XFree pour l'améliorer et ce pout toutes les cartes graphiques (celles d'y a 15 ans comme celles d'aujourd'hui), mais non, on est trop mauvais pour faire le boulot, alors on se dit "ouaou, OpenGL Ca déchire, ca booste" avec un driver pourri, proprio, buggué ou incomplet, mais ca fait rien, ca déchire, alors on a la solution ultime, on vire tout le code un tant soit peu moyen ou bas niveaux de xfree (c'est cool, de toute manière c'est un truc trop compliqué et inbitable pour nous) et on ne garde que le protocole et on le replugue directement sur OpenGL (c'est assez haut niveaux là, on sait faire), et oui, OpenGL c'est un truc magique qui booste, qui fait de la 3D et tout et tout et puis en plus c'est pas nous, c'est eux qui font OpenGL .....
En gros, comment se défausser en deux temp trois mouvement.

Oui, les primitives hardwares des cates 3D sont intéressantes pas que pour OpenGL mais aussi pour DirectX et EGALEMNT pour les partie 2D de XFree (X11, render ...).
Oui, l'infrastructure logicielle que l'on a du mettre en place pour pouvoir implémenter a peu près correctement OpenGL est interressante aussi pour autre chose que OpenGL (le DRI), et entre autre une refonte de l'architecture des drivers de XFree.
Oui, cette infrastructure encore immature et incomplète (putain a quand le management mémoire graphique (inboard/pci/agp/vm) en kernel). Mais les besoins à la fois pour OpenGL, X11/XFree, V4L/DVB/Codec Mpeg/Mjpeg, etc... (pensez au carte qui font un peu tout et regardez le bordel que c'est aujourd'hui) doivent la faire évoluer et la rendre plus mature.

NON, OpenGL comme API driver 2D de XFree c'est se tirer une balle dans le pied et c'est une ignominie et une hérésie techniquement parlant. P$*àç%, demain je réécrit linux et tout son environnement en fortran. Ben quoi, ca blatre le fortran, ca se paralélise super bien, quoi ? vous n'avez pas de machine multiprocesseur et/ou vectorielle ? jettez la a la poubelle c'est qu'elle est dépassé. Et puis c'est des boulets tous ceux qui font encore du calcul sci avec pvm et ou mpi, moi j'utilise gnumeric, c'est Bô, c'est rapide....

Enfin tout ca pour dire que OpenGl, c'est bien, mais pour faire de la 3D de haut niveau, pour faire du rendu, y a une histoire de pipeline graphique, de contexte graphique des notions de rendu. Je nous y voit bien, enclencher toute l'artillerie pour tracer un pauvre trait à l'écran ou alumer un pixel. J'imagine aussi la super appli qui pour afficher une image fait un rendu de texture dans une fenêtre. "A ben désolé, ce q'on a pris pour une tumeur n'était q'un artefact de rendu, on vous a enlevé un poumon..." ou alors "avec le anisotropic-quadrilinear truc muche filtering de la mort qui tue, ca a lisé le truc sur votre radio qui était en fait une tumeur..."
Bref, OpenGL c'est lourd et complexe, mais on a pas mieux pour la 3D temp réel en terme d'API (et celui qui dit Direct3D --> [] ), par contre c'est pas une API pour faire de la 2D et encore moins pour implémenter un système de fenêtrage 2D et un ensembre de primitives 2D dont on n'est pas prêt de pouvoir se passer.

Voilà, je crois que je suis définitivement a bout et ce sera mon unique post sur le sujet. Bonne nuit a tous.

Tout simplement (c'est également expliqué dans l'article) parcequ'il y a moins d'aller/retour entre le client et le serveur, le client fait son choix/ sa résolution en local, son rendu et envoie en une seule fois les glyphs calculés 100% en local ou composés coté serveur avec Render.

On a donc:
- Dans tous les cas une latence moindre (c'est ce qui tue en général les perfs X)
- Dans certain cas un partage de la charge entre le client et le serveur, interressant sur du multiproc ou du client serveur multimachine.
- Si tu est chanceux aujourd'hui (en espérant que ca se généralise) tu profite de Render.
- Si tu est très chanceux, Render est en plus correctement accéléré par le driver de ta carte.

Le gain en perf des point 2,3 et 4 ne sont valables que si 1 est adressé sinon le gain en perf bien que réel en terme d'occupation CPU sera complètement imperceptible au chrono en regard de la latence.

L'avantage également des fontes coté client c'est contrairement aux "corefont" l'indépendance du protocole X vis à vis du format et des propriétés des fontes (quand on vois le bordel que ca a été et que c'est toujour plus ou moins avant d'avoir un support correct des fontes TT ou OpenType).

Un des arguments que répliquerons les détracteur des fontes coté clients à mon explication est que les points 3 et 4 peuvent très biens êtres appliqués aux fontes coté serveur.

Oui mais: au niveau perf c'est pas top, la négociation et le "roundtrip" global est énorme avec le protocole "corefont" -> "temp de latence qui pourri tout".
En plus, le protocole original de X pour gerer les fontes ne gère pas tous les nouveaux formats de fontes ni toutes les nouvelles caractéristiques de celles-ci.
Le choix fait est donc "d'aléger" le protocole en zappant complètement du protocole (et pas des API, ne pas tout confondre) la gestion des fontes (le fameux "corefont ) pour utiliser soit de la composition coté client soit coté serveur pour faire le rendu des fontes avec protocole X11 original ou protocole X11 original + render suivant les cas.

En ce qui concerne l'aspect "repositorie" centralisé pour les fontes, chose plutôt élégante et dispo de base avec le serveur de fonte untilisant le protocole "corefont" original:
Le fait de faire le rendu coté client ne remet pas en cause cette possibilité. La différence, c'est qu'il faut réinventer un nouveau protocole. XFS utilise directement le protocole X11. Ce dont on a besoin, c'est de partager des fichiers de fontes.
Aujourd'hui, celà peut être fait avec NSF ou tout autre système de fichier réseaux, demain celà pourra peut être être à l'aide de l'implémentation du support http/ftp/... ou "XFSv2" spécifique dans fontconfig (avec système de cache et tout le tralala) qui ne sait aujoud'hui utiliser que des fichiers locaux.

Voilà, en espérant que tu y verra un peu plus clair.

voir:
http://keithp.com/~keithp/talks/usenix2003/html/net.html(...)

plus précisement la section sur les fontes ("Client-side Font Performance")

Ben je vais avoir l'impression de me répéter alors,

Vu que l'on commence a faire ici des comparaisons XFree86 / XP, je dis que cette comparaison ne veut rien dire et que c'est Hors Sujet.

Tu dis,
Non, ce qu il faudrait comparer c est XFree86 et GDI(+).

Je te (re-)dis,
Oui, ce que plus légitimement et en tout cas techniquement recevable serait de comparer XFree86 et GDI(+) (et encore), ce qui n'est pas le cas donc non recevable et hors sujet.

Je rajoute,
Ce n'était pas une attaque personnelle, juste un "Halte aux Trolls perfs XFree86 vs XP sur un Pxx" vu que ça n'est pas comparable (c'est comme "l'espérence de vie d'un mort sur un bord d'autoroute VS un chemin de campagne en france" débile non ?) et n'est donc qu'un Troll.

Cordialement.

Raison de plus, il est ici question de XFree86, pas de Gnome ou KDE ou du couple XFree86/Gnome ou XFree86/KDE donc aucune comparaison entre XFree86 et XP a un sens/est faisable/est légitime ---> [] Exit les Trolls.

Je comprends la réaction des dévellopeurs de XFree vis-à-vis du manque de reconnaissance.

Hum, le pblm c'est que ce n'est pas la réaction des développeurs, mais d'un individu. La Core Team ayant été dissolu y a quelques semaines, cette décision n'est donc pas issu d'une concertation de celle ci. Aucune discution ni aucune concertation n'a eu lieux à ce propros sur les forum ou listes de difusion. Cette décision est une décision unilatérale et individuelle de D.Dawes, un des ex de la coreteam et toujours un des rare tout puissant sur le cvs de xfree (c'est pas parce que la coreteam est dissolu que le projet s'est beaucoup plus ouvert, c'est plus du marketing qu'autre chose...). David est un excellent développeur et l'un des fondateurs de XFree86, mais c'est aussi un gros conservateur réac de base qui se croit investi d'une mission divine et qui a fait pas mal de dégats depuis quelques années de part sa position de leader/manager/décisionnaire/faiseur de pluie et de beau temp technique/etc.... mais bon, je vais pas m'étendre la dessus, j'y ai déjà amplement fait référence dans mes réponses aux articles et débats techniques sur XFree.

En solution libre, je connais malheureusement rien.
En solution proprio, y en a deux:

DIRXML de Novell, malheureusement indissociable de e-directory, et franchement immature la dernière fois que j'y ai jeté un oeil.

Meta Directory Server de Critical Path qui est la seule solution réellement sérieuse et mature du marché. Un connecteur Notes natif est dispo et permet d'attaquer non seulement le NAB mais n'importe quelle base nsf et en read write.
La tache LDAP de Domino est assez basique et ne permet pas d'interagir complètement avec le système en ce qui concerne la gestion des users (création de certificats etc...).

Le gros défault de MDS: proprio et cher, très cher...

De plus, MDS necessite un niveau minimum du coté de l'annuaire LDAP servant d'annuaire consolidé appelé par abus de language Meta Annuaire, a savoir le support d'un mécanisme de changelog.
Celui de e-directory, de CP DS, de AD, iplanet etc.. est supporté.
Malheureusement OpenLdap n'en implémente aucun pour l'instant.

Transport et production/distribution/commercialisation sont déjà des entitées juridiques séparées (europe oblige).
Production et distribution/commercialisation sont également en cour de scission (toujour europe).
Même si l'ART est favorable a l'évolution des status, même si une filliale est créée, l'ART et/ou EDF ne peut rien faire sans l'accord de Bruxelle, sauf si en haut lieux au gouvernement on decide de se friter grave avec Bruxelle.
Donc en gros, EDF a d'autres chats a fouetter en ce moment, d'où le peut d'interrêt qu'il portent à la chose à part pour leur propre utilisation (télépilotage et supervision du réseau).

Mouarfff, Tous le monde a faux et tous le monde a bon. Il y a deux choses completement differentes: L'APIC et l'IO-APIC Le premier est interne au cpu et permet en effet de gerer 256 sources differentes, c'est la partie interne au cpu qui permet de masquer ou pas les interrupts entre autre. Il sert egalement à la gestion du bus de signalisation interprocesseur pour les machines SMP et integre (cpu>pentium) un timer additionnel utilisé par linux pour réaliser un watchdog hard (genère une interruption bas niveau nom masquable (smi)). Il integre plein de gadgets en plus sur les proc recents. L'IO-APIC quand a lui est le remplacant de nos bon vieux 8259 (dénomé xt-pic sous linux). C'est le controleur physique d'interrruption en lui meme qui est en double (cascadé) dans les anciens PC a base de 8259. L'IO-APIC permet en effet de generer 24 interrupt hw differentes. Y a des machines un peut tordu avec plusieurs IO-APIC, ou des IO-APIC "Custom" gérant plusieurs dixaines de lignes d'interruption physiques. Sous Linux, dans /proc/interrupts, les interrupts sont numérotés par rapport au nombre de ligne physiques disponibles (16 ou 24 en gereral), le mapping vers le vecteur APIC est caché (voir la table affiché au boot). Sous Windows (NT), c'est le numéro des vecteur APIC qui est affiché. Sur une machine SMP en mode MPS1.4 (multiprocesseur post 486), les interruptions sont donc numérotés de 0 a 255. Sur ma machine, ma 2940 se retrouve en 30 et des brouettes et ma matrox en 80 et des poussières. Quand on parle d'interruption sur nos pc modernes il faut avoir à l'esprit la chose suivante: Broche physique -> mapping broche physique vs No INT IO-APIC -> mapping INT IO-APIC vs INT CPU APIC -> vecteur d'interruption réel. Pour compliquer un peut plus les tables de mapping, une interrupt peut être routée ver un cpu uniquement, plusieurs, tous ...

Attention,
Ma remarque s'incrit dans le cadre d'une aproche informaticienne de l'informatique (glups!), pas de l'approche utilisateur/exploitant.
Un bon concepteur/codeur/admin doit savoir comment fonctionne la bête, il conprendra un peut mieux ce qu'il fait, pourquoi et quelles implications ca a. Maintenant, c'est encore mieux s'il comprend prourquoi la bête est foutu comme ca et pas autrement, ca peut même l'aider à mieux comprendre comment elle marche et donc l'aider à mieux en tirer parti pour atteindre son objectif, que ce soit dans un milleux professionnel purement industriel, scientifique, ludique, pour épater la gualerie, pour faire fumer le scilicium, peter les zistor, cramer les lampes et j'en passe..... pour le fun quoi!
Bon, sinon, je suis pas si vieux que ca, meme si je suis un felé des vielles machines. Mes dernières acquisitions sont un VAX3400 et un C64. Si qqu'un de mon ancienne école sait aussi ou sont passés mes ApolloDN3500 et mon ApolloDN4000 (ou 5000, je sais plus) ce serait cool. Avec un pote on vient de récupérer (il a récupéré) un HP9000 a base de PA1.1 qu'on compte bien faire tourner sous Linux un de ces quatre (coucou pillule....) Si qqun chez HP arrivait enfin a refoutre les mains sur la spec du HPPB ce serait cool.
Si le je vous sert ici le discourt du "manque de culture générale" informatique dans un peut toutes les disciplines de celle ci, c'est par expérience personnelle. Tout devient clair lorsque l'on se penche sur le pourquoi du comment technique en regardant les choses d'un point de vue historique.
Pour expliquer correctement les principes d'une VM moderne à n'importe qui, il suffit de beaucoup d'histoire (de l'informatique), de la fin des années cinquantes à aujourd'hui, saupoudré de quelques notions techniques introduites au fur et à mesure et le boulanger du coin en saurra plus (et chose plus dramatique, aurra de meilleures bases sur le sujet à partir desquelles il pourra se perfectionner) que la pluspart des admins ou des développeurs de la boite d'info du coin (même si le coin est plustot balaize...).
Mais bon, j'ai eu en quelques sortes un bon prof, genre le type qui vous explique comment il fesait en cour ses premier processeurs a base de diodes et comment il fesait à l'époque du reverse engeenering sur les soft de de l'autre coté. La légende veut même qu'il ait fait parti de l'équipe qui a démonté un vax à l'ouest pendant des nuits sans lune dans un labo pour en faire une copie conforme à l'est, machine qui bien des années plus tard fut considérée comme supérieure à l'originale par les ingénieurs de DEC.

ARRGGhh, je fatigue, c'est plein de foootes.
celle ci -> celui ci
phénomère -> phénomène

Désolé si y en a d'autres.

Ton argumentaire ne me plait pas, tu fait dans celle ci l'amalgame entre Utilisateur (genre ma mère et sa bagnole) et Personne qui peut potentiellement se découvrir une vocation en informatique.
Windows (ou autre) ne peut pas nuire a la vocation informatique du premier (quoi que ;-) ) étant donné que ce n'est qu'un outil pour lui et ne veut le voir que comme tel et que donc par définition il ne pourra en découler aucune vocation.

Sinon, on est parfaitement en phase en ce qui concerne ta conclusion. Ce qui me fait peur, c'est que les générations se succèdent, ne faisant qu'entretenir le phénomère en l'agravant.
Le seul phénomène pouvant peut être enrayer le processus est le poid que commence à peser le LL dans la balance. (même si celui ci n'échape pas au phénomène).

Bon, je me calme,
Ce que je voulais faire passer, c'est le manque global de "culture générale" dans toutes nos aproches "modernes" à l'informatique, que ce soit à l'école ou dans les millieux professionnels.

"Echange" :-))) Oooopss!!!

Pour en revenir a une remarque faite dans les threads précédents, pour les personnes qui veulent faire de l'informatique leur vocation/metier, les docs/bouqins/l'enseignement est beaucoup trop factuel. Je m'explique: le meilleur cour d'informatique (quelque soit le sujet précis, l'informatique c'est vaste) est en fait un cour d'histoire. La pluspart des simplifications que l'on s'efforce de faire afin d'aborder un sujet particulier vaudront pas l'explication du chemin que l'on a emprunté au cour de l'histoire, ces 50 dernières années, en informatique.
Il faut juste zapper les années 90, réservées au cours avancés en science politico/economique de l'informatique (bon je pousse un peu, mais dans 90% des cas l'histoire des années 90 servent à illustrer des cas particulier, exceptions, voies de garages, ou juste maturation de certains vieux concepts. Je précise, je n'évoque ici que l'aspect technique de l'histoire de l'informatique).
AAAaaahhhhh, ce bon vieux PDP qui a vu naître Unix et le C, et les VAX avec leurs instructions VM préfigurant les MMU actuelles, les VT ou on reprogrammait les rom pour exploser tout le monde a space war, les DD dans des racks a porte blindé pour éviter de se faire décapiter quand un aterrissage de tete se passait mal, les cartes perforées qui pu le roussi lorsque l'on pousse un peu trop le lecteur de compet mal graissé, le bon vieux clavier mécanique sur l'imprimante a boule capable de déplacer un bati de 200kg lorsqu'elle débite a plein tube, esemble apellé teletype, ancetre de nos terminaux a écran d'ou le défilement de bas en haut et ayant donné son petit nom à nos /dev/tty......

J'aime bien ta remarque sur "l'aspect shamanique" de beaucoup de logiciels / environnements propriétaires.
C'est malheureusement la principale cause de tous les maux de l'informatique moderne à savoir en première ligne l'incompétence crasse de personnes prétendu informaticien(ene)s.
D'un autre coté on ne peut pas toujour leur en vouloir. Je connais dans mon entourage beaucoup de personnes travaillant en SSII comme simple technicien, avides de connaissances et ayant une curiosité plus que dévelopé, mais se heurtant au mur d'opacité que sont les systèmes d'expoitation MS ou telle et telle application propriétaire.
Ces personnes perdent bien vite courrage lorsque les seules réponses / pistes / explications du grand gourou spécialiste voire expert de l'aplication ou du système, de son équipe ou de sa SSII a comme réponse "reboote", "réinstalle", "essay le service pack truc ou le hotfix machin", "comment ca fonctionne ? ben, heu, en fait c'est compliqué.... ".
Ces personnes resteront dans l'igniorance et perdrons toute leurs envies, leur curiosité, leur illusions.
Un jour elles seront gourou de leur equipe/boite, car elles auront une liste de recettes vodoo plus longue que les autres et seront donc élues grand shaman.
Et la roue tournera... Et ca fait déjà lontemps que ca dure...
Pour les grand chefs, c'est pas beaucoup mieux, il suffit de saupoudrer les choses avec un peut de sauce politico/économique, laisser pourrir ca une petite décénie et admirer le résultat.
La faute n'en revient pas qu'aux environnement ou applicatifs propriétaires, mais aussi a l'abandon de tout concept technique pour ne parler que de produit.
Aujourd'hui, on ne parle plus de SMTP/IMAP/POP/LDAP/Kerberos, filtre de packets, proxy , mais de Echange, Lotus Notes, Active Directory, ISA server, CheckPoint etc......

Snifff...

hhhhmmmmm, que le temps passe .... y a plus de 8 ans déjà...
:-)))))

dmesg |less
1ere ligne:
Linux version 2.4.20-686 (herbert@gondolin) (gcc version 2.95.4 20011002 (Debian prerelease)) #1 Mon Jan 13 22:22:30 EST 2003

Pareil dans kern.log

uname -a ou demsg|less ou voir /var/log/kern.log
enfin je crois...
(j'ai pas de linux sous la main pour l'instant)

En sid, tu as le 2.4.20 de dispo.
Recompiler Alsa est très simple sur une debian.

- Installe le package de sources du kernel.
- installe le package de source Alsa.
- un tar xvzf a faire dans /usr/src
- un export VARIABLE-TRUC=/usr/src/modules
- make-kpkg modules_image (en etant dans /usr/src/linux)

et hop: dpkg -i alsa-modules-........

Bon, ^^^^^^ contient plein d'erreurs. Voir /usr/share/doc/alsa-sources/ pour la proc d'install exacte (nom des variables exactes ...)

Pour être sur, fait un export CC="path to gcc 2.95" avant de compiler ALSA.

Dans tous les cas, si kernel compilé avec gcc 3, modules avec gcc3.
Si compilé avec gcc 2.95 : compiler les modules avec 2.95.
C'est un pblm que j'ai déjà rencontré avec ALSA et VMWARE.

Si tu utilise un kernel pre-packagé, fait bien attention de compiler ALSA avec gcc 2.95 et pas gcc 3.x .

C'est un pblm classique ....