Ouf ! J'y ai mis 3 jours, mais ça y est, j'y suis arrivé !
Oui, j'ai nagé à travers tous les Makefile et ./configure, tous générés par autoconf évidement, soit 10000 lignes minimum. J'ai essayé de changer quelques paramètres etc ...
La solution est la suivante:
S'il est conseillé de mettre une directive "--target=", tant à la construction de gcc qu'à celle des binutils, l'ignorer provoque la construction d'une suite d'outils natifs, destinés à traiter des fichiers au format adaptée à la machine sur laquelle on est censé travailler, ce qui est en général ce que l'on veut.
Or: passer cette option provoque également l'ajout d'un préfixe devant tous les noms des outils, préfixe correspondant à la cible. Ex "i686-pc-linux-gnu-ar", "i686-pc-linux-gnu-ld" pour binutils, ou "i686-pc-linux-gnu-gcc" dans le cas des compilateurs de gcc. Il est d'ailleurs précisé dans la doc que lorsque l'on invoque gcc -arch=xxxxx, c'est en fait ces exécutables qu'il va chercher.
Mais en outre, ne pas préciser de cible génère non seulement des outils natifs mais aussi sans préfixe ! Et c'est eux qui vont être invoqués en premier, même en passant une option "--arch" (dans ce cas, les suivants sont appelés par ces premiers). C'est aussi ce qui provoque la prise en charge par défaut de la machine locale.
Cela veut déjà dire qu'il est préférable de construire d'abord tous les outils et compilateurs pour toutes les plateformes croisées, et seulement enfin, les outils et compilateurs natifs.
La clé du mystère:
S'il faut effectivement créer une suite de compilateurs, un par cible (ce qui, déjà, en soi, n'est pas clair: cela ne le devient qu'implicitement, au moment où l'on apprend que passer une architecture en directive appelle l'exécutable correspondant), cela est loin d'être évident pour binutils, qui reçoit l'option --enable-targets=all, contrairement à gcc. Cette option laisse penser que l'on peut bâtir une suite d'outils visant toutes les cibles.
En fait c'est faux: Cette option ne sert qu'à activer l'accès aux différentes cibles, volontairement restreintes. Il faut en plus ajouter "--enable-64-bit-bfd" pour étendre cette sélection aux cibles 64bits telles que Sun Solaris2 sur Sparc64 (v9).
Cela implique donc de construire binutils exactement comme gcc, les deux suites partageant les mêmes répertoires, ce qui est une bonne chose. Donc reconstruire une version de binutils pour chaque cible.
C'est là que tout se dénoue: chaque build de binutils ciblant une plateforme particulière, et windres ne servant qu'à manipuler les fichiers Windows, cet outil ne sera compilé que si binutils cible explicitement cette plateforme ! Même si les sources de l'outil se trouve dans le package.
Fini ? Pas encore tout-à-fait: binutils va encore faire appel à votre intuition:
Déjà, créer un exécutable Windows n'est l'affaire que du linker "ld", et pas du compilateur, qui lui ne doit produire que du code objet pour le processeur sur lequel le système de Redmond doit tourner.
Ensuite, à votre avis, quel sera le nom de la cible ? Win32 ? Nan, Windows contamine aussi les machines 64 bits.
Il faut en fait se souvenir qu'à la naissance de Windows, sont apparus les formats NE (New Executable), puis PE (Portable Executable), encapsulés au sein d'un fichier Exe MS-DOS standard, lequel ne servant plus qu'à écrire "This program cannot run in DOS mode" à l'écran. D'ailleurs, le même format sera utilisé sur toutes les architectures, y compris non-PC. En cherchant un peu dans les BFD de binutils, on trouve donc pe-i386 et pei-i386.
D'où une cible qui marche: i386-pc-pe, pour ratisser le plus large possible.
Après l'effort, la récompense: Cette procédure fonctionne pour toutes les cibles. Vous pouvez donc essayer l'impressionnante palette de processeurs et de plateformes reconnus par gcc, et n'êtes plus obligés de débourser entre 10000 et 20000 francs ( http://fr.kelkoo.com/search.jsp?catId=100164013&siteSearchQuery(...) ) pour profiter d'un compilateur performant, et surtout vous n'avez plus de raisons de rebooter:
Un seul tarball, un seul makefile, et votre application fonctionnera partout. Quelques NFS/SMBmount judicieux, voire des montages de partitions, et tout votre pôle de développement sera centralisé !
Bon je poste tout cela en astuce ou j'écris un HOWTO ? :-)
En effet, j'aurais du le préciser mais c'est le problème: Il n'y a pas de message d'erreur: La compilation arrive à son terme et l'installation se déroule correctement mais les outils windres et dlltool n'ont pas été construits. Pourtant le source windres.c est bien présent.
Il y a une mise en garde dans la doc du binutils concernant le fait que l'outil n'est pas systématiquement distribué, mais dans mon cas il est, et il n'y a rien concernant une éventuelle option à passer ...
Le meilleur endroit pour réclamer cela est encore le forum « linuxfr.idees », à mon avis, en donnant éventuellement en réference l'URL de cette entrée. Il n'est pas impossible que les développeurs pensent la même chose que toi et corrigent le parser, mais toutes ces corrections ont plus de chances d'être effectuées si elles sont centralisées en un seul et unique lieu ...
> je voudrais pirater la fac ou je suis qui est sur réseau sur linux!
> Aidez moi SVP
echo "C'est quoi le mot de passe?" | mail root
-+- AGV in Guide du linuxien pervers - "Faut savoir rendre service." -+-
Si ils avaient abandonné les serveurs, ca aurait été abandon immédiat de la puce je pense, la c'est juste qu'elle va pas décoller et va continuer à servir ponctuellement dans des gros centres de calcul, où il est vrai qu'elle est pas mal concurrencée...
Et à quel prix ? La puce Itanium restera-t-elle compétitive en centre de calcul face à deux AMD 32-64bits, par exemple ? Sans compter que tous les logiciels, des librairies de plus bas niveau jusqu'au moindre « grep » devront être portés. Ce n'est pas vraiment un problème, les distirbs Itanium existent (pour autant que je sache, d'ailleurs), mais cela veut dire qu'il sera impossible d'importer le moindre binaire d'une autre machine, plus courante. Sous GNU/Linux, on a l'habitude d'avoir les sources et de recompiler, mais rares sont les systèmes où c'est possible. Cela ne va pas aider la puce à décoller ...
C'est d'ailleurs bien dommage, à mon goût. Pour une fois, c'eût été faire usage de son poids pour imposer une nouvelle technologie, mais dans le bon sens cette fois. A mon avis, seul Intel était suffisamment influent pour imposer d'aussi drastiques changements. Le fait qu'ils aient échoués me laisse à penser que les puces à venir vont rester mal architecturées et grosses consomatrices de courant pendant encore longtemps.
Faire table rase du passé à l'occasion du passage en 64bits était vraiment une bonne idée, à mon goût. C'était le moment ou jamais de le faire. D'autant qu'avec une puce complètement nouvelle, on n'aurait pas tué le marché du 32bits (en tout cas pas tout de suite). Deux marchés complètement distincts auraient existés. Il est clair que cela ne va plus se reproduire avant un bon moment, désormais.
Mon humble et propre expérience me dit que ce n'est pas si inutile que cela, pour les raisons suivantes:
1) La théorie de la caverne. L'utilisateur ne saura pas qu'il y a mieux si on ne lui dit pas. Bon nombre d'utilisateurs pensent que rebooter une machine est une chose normale, que cela devrait être fait régulièrement, et croient sans difficulté leur interlocuteur lorsqu'il leur dit que WinXP est une avancée technologique majeure parce qu'il y a moins d'écrans bleus ou parce que « quand un programme plante, on peut la plupart du temps le fermer sans avoir à redémarrer son ordinateur et perdre son travail » (affirmation extraite des slides de présentation à l'installation de Windows XP).
2) LES SENTIMENTS. Aussi incroyable que cela puisse paraître, l'utilisateur de base s'attache émotivement et en moins de trois semaines au système qu'il utilise, au point de vraiment prendre très mal toute critique contre ce système. Dans la plupart des cas, vous verrez le visage du sujet devenir très grimaçant, ce qui est une mauvaise chose parce qu'il conservera contre vous une rancoeur dont il ignorera l'origine. Au pire, vous le verrez fondre en larme (c'est pratiquement arrivé à un copain, et je ne me moquais pas de lui).
Tout cela est très irritant lorsque de meilleurs systèmes existaient bien avant la suprémacie de Windows. Cela devient carrément un problème lorsque certains cas auraient pu être réglés en moins de temps qu'il n'en faut pour le dire avec les outils appropriés (en général la dernière KNOPPIX suffit), mais qu'un DSI borné restant à un « je ne veux pas voir de CD de Linux traîner » vous empêche de le faire ...
Bien souvent, en informatique, on privilégie le mysticisme aux critères techniques.
Pareil. Je me joins aux autres commentaires pour te dire que:
1) Pas la peine d'essayer de bluffer ton interlocuteur. Des stagiaires, il en voit passer des dizaines par an, donc au travers de ton CV il lit en toi comme dans un livre ouvert. Pas de honte à avoir: Il est normal qu'à 19 ans et en sortant de l'école, ton expérience professionnelle soit réduite. Ce qui va compter le plus, c'est ta motivation et ton initiative. La façon dont tu vas t'exprimer à l'écrit va en dire long à ce sujet.
2) Ton cursus tient largement sur une seule page. Vouloir remplir la première par de la mise en page, et s'étendre sur une deuxième est une erreur de débutant (que j'ai faite à ton âge). Ton CV aura l'air largement plus étoffé si tu ne le dilue pas sur ces deux pages.
3) « Juillet 2002: ... et travail à la chaîne » ! Pas top.
4) Enfin, mets en tête de page le poste pour lequel tu as été formé. Il faut attendre la deuxième page pour le savoir, en l'état actuel des choses. DUT informatique c'est trop vague. Précise ce que tu sais faire, et surtout ce que tu vise: programmation ? administration système ? Technicien micro/réseau ? Support Technique ? Hotline ? etc.
N'hésite pas à prendre conseil auprès des professionnels ou des centres d'orientation si tu veux être sûr de viser juste et de faire un stage qui te plaise. Si tu te loupes, tu ne tireras aucun profit de cette expérience et tu risques de faire perdre beaucoup de temps aux gens qui vont t'accueillir.
Bienvenue dans le monde du travail et bonne chance !
'faudrais que tu nous donne un peu plus de détails sur ta base de données.
- Elle doit être utilisée par un seul programme ou par plusieurs en même temps ?
- Ta liste d'éléments, elle est toute seule ou il y en a plusieurs, avec des relations entre elles ?
Si c'est la première réponse dans les deux cas, et qu'en plus les opérations d'insertion sont rares, alors tu as plus vite fait de mapper un fichier en mémoire avec mmap() ou mmap64(), de récupérer de le pointeur sur la zone et de le caster, genre:
typedef struct _element
{
char element [128];
unsigned long int checksum;
} Element;
Element * ptr;
ptr= mmap (LesArgumentsQuiVontBien);
Le contenu de ton fichier sera alors immédiatement utilisable comme si c'était un tableau en mémoire.Un petit « ptr[x] » pour retrouver immédiatement l'élément x. Simplicité et rapidité: C'est le système qui s'occupe du chargement/déchargement des pages et de choisir leur granularité.
Pour retrouver tous les éléments, un simple balayage de 0 à n-1 éléments. Techniquement, il n'est pas possible de faire plus rapide. Tu peux ajouter un index à tes « éléments », mais si tu dis que les insertions sont rares, tu peux te permettre de les trier en temps réel. Gain de temps à la lecture grandement amélioré !
Le seul tout petit souci que tu peux avoir apparait lorsque tu modifies la structure de Element: Il faut reconstruire le fichier. C'est exactement la même chose avec un SGBD, sauf que l'opération se fait automatiquement lorsque tu lui demande. Quoiqu'il en soit cela reste très simple: Deux définitions de structures, deux pointeurs ptr1 et ptr2, deux mmaps et une boucle qui scanne tous tes éléments, avec à chaque itération une copie de l'une des structure vers l'autre, et c'est fini.
en lisant un livre je peux ecouter Platon ou Aristote ou Marc Aurele ou Montaigne. Je peux vivre la vie de des héros de Stendhal ou de Balzac.
Mais pourquoi diable faut-il que chaque fois que l'on parle de littérature ou d'art, et d'une manière générale de culture, on fasse référence aux classiques ?
Loin de moi l'idée de remettre en cause l'immense contribution apportée au patrimoine de l'humanité par ces grands auteurs, mais nom d'un chien, ils ne sont pas tout seuls !
On nous distille cette vérité toute faite depuis l'école, et comme l'Education Nationale est pratiquement le seul sésame pour arriver à faire quelque chose de sa vie en France, ceux qui réussissent et qui donc définissent les standards sont ceux qui ont adhéré et apprécié les oeuvres définies par les programmes.
Moi, cela me dérange. En suivant cette voie, un auteur ne peut être s'il ne suit les traces de ces « modèles », et restera de toute façon qu'un « ordinaire » tout au long de sa vie, à moins que se produise le miracle qui brusquement va le faire entrer au panthéon, au club très fermé des gens qui nous montrent la voie.
J'ai beaucoup plus d'estime pour quelqu'un qui va aller faire l'effort de dénicher une perle rare, un livre presqu'anonyme et en révéler toutes les subtilités, plutôt que pour quelqu'un qui va se gargariser d'oeuvres archi-connues sous prétexte que c'est culturellement correct.
Sur tous les grands lecteurs, combien sont capable d'apprécier le monde et l'histoire de la bande dessinée ?
Si bon nombre de personnes sont (heureusement) encore capables d'apprécier un bon morceau de musique dite « classique », sur tout ceux qui vont vous parler de Mozart, Beethoven, Brahms, Chopin, Bach ... combien sauront vous parler de John Williams, de Danny Elfmann ou Jerry Goldsmith ?
D'autre part, beaucoup de ces auteurs ou compositeurs sont devenus des « génies » parce qu'ils étaient pionniers en leur domaine. Qui se souviendra du 10ème homme à avoir marché sur la Lune ? Qui se souviendra dans 100 ans des plus grands morceaux composés à la fin du vingtième siècle ?
La plupart des « classicistes » le sont en fait soit parce qu'ils ont une banale affinité pour ce style, soit parce qu'on leur a toujours dit que c'était Bien™.
Je n'ai jamais beaucoup aimé AXA, de toutes façons.
Moi-même, j'y ai mis les pieds pour une mission de migration fin 2000.
A l'époque, l'un des responsables informatiques était assez passionné et nous expliquait en détail, à moi et un pote aussi Linux que moi, la stratégie suivie pour réécrire Access (je ne sais pas d'où ils tenait ses sources).
Il nous a dit « Quand je vois Linux, je rigole ! », ne sachant pas qu'il a avait à faire à deux passionnés d'Unix. Il a fait une drôle de tronche quand il s'en est rendu compte.
Un mois après, nous étions mis dehors, à quelques jours d'intervalle et pour un motif assez nébuleux ... je ne sais pas si cela a pesé dans la balance ... :-)
Ben oui, dans le cas de la PS2, c'est un CD que l'on presse. On ne fabrique pas le module entier avec son boitier plastique, son circuit imprimé et les composants qui vont bien, et le reste tel que l'étiquette et la visserie. Les éditeurs économisent énormément.
Toujours est-il que pour moi, une console de jeux, cela fonctionne avec une cartouche ! J'ai pris l'arrivée de la PSX et de ses CD comme un sacrilège ! :-)
Effectivement, vers la fin des années 80 je payais mes jeux vidéos environ 200 francs. C'est vrai que depuis on les a vu doubler, mais il ne faut pas oublier que:
1) En 15 ans, les prix augmentent.
2) Les jeux vidéos sont devenus une industrie comparable à celle du cinéma. On ne peut - malheureusement - plus envisager écrire un jeu vidéo tout seul, par exemple. D'autre part, cela nécessite d'être rompu à toutes les dernières technologies, et évidement, de connaître parfaitement la 3D car aujourd'hui, « jeu vidéo » est pratiquement synonyme de « simulation » (Rha, les jeux de plateforme: nostalgie ... :-) ).
A mon avis, la seule raison pour laquelle le prix des jeux se stabilise autour de 60 euros est qu'un jeune ne peut s'offrir un logiciel de jeu pour l'équivalent de 500 francs ou plus, spécialement s'il a une durée de vie de quelques mois tout au plus, et que d'une manière générale personne n'a envie de le faire.
Ben ghostview est fait pour lire les fichiers PostScript. Même si le PDF est très très proche, ce n'est pas la même chose et Adobe le précise clairement dans ses spécifications.
Par contre le fait que ce PDF-là fasse planter gv est probablement dù au fait que ledit document doit avoir été écrit avec Word. C'est mal prti pour réduire le TCO ... :-)
Je ne suis pas au courant d'un modèle à éviter particulièrement, mais par contre il y a 9 chances sur 10 pour qu'il soit équipé d'un winmodem . Donc t'auras peut-être des ennuis de ce coté, sinon en général tout marche.
[^] # Re: Chouette !
Posté par Obsidian . En réponse au journal Un juge américain annule une partie du Patriot Act. Évalué à 6.
Précisément ! C'est exactement ce genre de phrase, bien ciblée, qui fait mouche lors d'affaires comme celle-ci.
On éviterait bien des conflits avec des mots bien choisis, je crois ...
[^] # Re: Une minute de silence
Posté par Obsidian . En réponse à la dépêche Le brevet Microsoft sur la FAT est rejeté. Évalué à 0.
[^] # Re: L'occasion de s'acheter un cerveau :p
Posté par Obsidian . En réponse à la dépêche Le brevet Microsoft sur la FAT est rejeté. Évalué à 2.
[^] # Re: ...
Posté par Obsidian . En réponse au message binutils: Recherche windres désespérement !. Évalué à 3.
Oui, j'ai nagé à travers tous les Makefile et ./configure, tous générés par autoconf évidement, soit 10000 lignes minimum. J'ai essayé de changer quelques paramètres etc ...
La solution est la suivante:
S'il est conseillé de mettre une directive "--target=", tant à la construction de gcc qu'à celle des binutils, l'ignorer provoque la construction d'une suite d'outils natifs, destinés à traiter des fichiers au format adaptée à la machine sur laquelle on est censé travailler, ce qui est en général ce que l'on veut.
Or: passer cette option provoque également l'ajout d'un préfixe devant tous les noms des outils, préfixe correspondant à la cible. Ex "i686-pc-linux-gnu-ar", "i686-pc-linux-gnu-ld" pour binutils, ou "i686-pc-linux-gnu-gcc" dans le cas des compilateurs de gcc. Il est d'ailleurs précisé dans la doc que lorsque l'on invoque gcc -arch=xxxxx, c'est en fait ces exécutables qu'il va chercher.
Mais en outre, ne pas préciser de cible génère non seulement des outils natifs mais aussi sans préfixe ! Et c'est eux qui vont être invoqués en premier, même en passant une option "--arch" (dans ce cas, les suivants sont appelés par ces premiers). C'est aussi ce qui provoque la prise en charge par défaut de la machine locale.
Cela veut déjà dire qu'il est préférable de construire d'abord tous les outils et compilateurs pour toutes les plateformes croisées, et seulement enfin, les outils et compilateurs natifs.
La clé du mystère:
S'il faut effectivement créer une suite de compilateurs, un par cible (ce qui, déjà, en soi, n'est pas clair: cela ne le devient qu'implicitement, au moment où l'on apprend que passer une architecture en directive appelle l'exécutable correspondant), cela est loin d'être évident pour binutils, qui reçoit l'option --enable-targets=all, contrairement à gcc. Cette option laisse penser que l'on peut bâtir une suite d'outils visant toutes les cibles.
En fait c'est faux: Cette option ne sert qu'à activer l'accès aux différentes cibles, volontairement restreintes. Il faut en plus ajouter "--enable-64-bit-bfd" pour étendre cette sélection aux cibles 64bits telles que Sun Solaris2 sur Sparc64 (v9).
Cela implique donc de construire binutils exactement comme gcc, les deux suites partageant les mêmes répertoires, ce qui est une bonne chose. Donc reconstruire une version de binutils pour chaque cible.
C'est là que tout se dénoue: chaque build de binutils ciblant une plateforme particulière, et windres ne servant qu'à manipuler les fichiers Windows, cet outil ne sera compilé que si binutils cible explicitement cette plateforme ! Même si les sources de l'outil se trouve dans le package.
Fini ? Pas encore tout-à-fait: binutils va encore faire appel à votre intuition:
Déjà, créer un exécutable Windows n'est l'affaire que du linker "ld", et pas du compilateur, qui lui ne doit produire que du code objet pour le processeur sur lequel le système de Redmond doit tourner.
Ensuite, à votre avis, quel sera le nom de la cible ? Win32 ? Nan, Windows contamine aussi les machines 64 bits.
Il faut en fait se souvenir qu'à la naissance de Windows, sont apparus les formats NE (New Executable), puis PE (Portable Executable), encapsulés au sein d'un fichier Exe MS-DOS standard, lequel ne servant plus qu'à écrire "This program cannot run in DOS mode" à l'écran. D'ailleurs, le même format sera utilisé sur toutes les architectures, y compris non-PC. En cherchant un peu dans les BFD de binutils, on trouve donc pe-i386 et pei-i386.
D'où une cible qui marche: i386-pc-pe, pour ratisser le plus large possible.
Après l'effort, la récompense: Cette procédure fonctionne pour toutes les cibles. Vous pouvez donc essayer l'impressionnante palette de processeurs et de plateformes reconnus par gcc, et n'êtes plus obligés de débourser entre 10000 et 20000 francs ( http://fr.kelkoo.com/search.jsp?catId=100164013&siteSearchQuery(...) ) pour profiter d'un compilateur performant, et surtout vous n'avez plus de raisons de rebooter:
Un seul tarball, un seul makefile, et votre application fonctionnera partout. Quelques NFS/SMBmount judicieux, voire des montages de partitions, et tout votre pôle de développement sera centralisé !
Bon je poste tout cela en astuce ou j'écris un HOWTO ? :-)
[^] # Re: ...
Posté par Obsidian . En réponse au message binutils: Recherche windres désespérement !. Évalué à 2.
Il y a une mise en garde dans la doc du binutils concernant le fait que l'outil n'est pas systématiquement distribué, mais dans mon cas il est, et il n'y a rien concernant une éventuelle option à passer ...
[^] # Re: C'est un peu idiot de devoir mettre un titre pour un commentaire non
Posté par Obsidian . En réponse au message Ou sont définis les répertoires standard pour #include <> ?. Évalué à 2.
[^] # Re: Doute...
Posté par Obsidian . En réponse au journal Un rat sur #linuxfr EFnet. Évalué à 2.
Ce qui ne les empêche pas de faire des conneries ! :-)
« Il y a deux sortes d'admins Unix ... »
[^] # Re: d'un autre coté ...
Posté par Obsidian . En réponse au journal Un rat sur #linuxfr EFnet. Évalué à 3.
« - Y a quoi sous Linux pour lire les .rm »
« - Ben rm ! »
Issu des fortunes:
http://sam.linuxfr.org/fortunes.txt(...)
Moins méchant:
> je voudrais pirater la fac ou je suis qui est sur réseau sur linux!
> Aidez moi SVP
echo "C'est quoi le mot de passe?" | mail root
-+- AGV in Guide du linuxien pervers - "Faut savoir rendre service." -+-
[^] # Re: Pour laisser les windowsiens tranquilles...
Posté par Obsidian . En réponse au journal Laissons les Windowsiens tranquilles !. Évalué à 2.
Voila c'est dis
Ton clavier doit être mal configuré:
$ xmodmap -e "keycode 28 = t T tslash Tslash"
:-)
[^] # Re: Workstation
Posté par Obsidian . En réponse au journal La mort de l'Itanium ?. Évalué à 4.
Et à quel prix ? La puce Itanium restera-t-elle compétitive en centre de calcul face à deux AMD 32-64bits, par exemple ? Sans compter que tous les logiciels, des librairies de plus bas niveau jusqu'au moindre « grep » devront être portés. Ce n'est pas vraiment un problème, les distirbs Itanium existent (pour autant que je sache, d'ailleurs), mais cela veut dire qu'il sera impossible d'importer le moindre binaire d'une autre machine, plus courante. Sous GNU/Linux, on a l'habitude d'avoir les sources et de recompiler, mais rares sont les systèmes où c'est possible. Cela ne va pas aider la puce à décoller ...
C'est d'ailleurs bien dommage, à mon goût. Pour une fois, c'eût été faire usage de son poids pour imposer une nouvelle technologie, mais dans le bon sens cette fois. A mon avis, seul Intel était suffisamment influent pour imposer d'aussi drastiques changements. Le fait qu'ils aient échoués me laisse à penser que les puces à venir vont rester mal architecturées et grosses consomatrices de courant pendant encore longtemps.
Faire table rase du passé à l'occasion du passage en 64bits était vraiment une bonne idée, à mon goût. C'était le moment ou jamais de le faire. D'autant qu'avec une puce complètement nouvelle, on n'aurait pas tué le marché du 32bits (en tout cas pas tout de suite). Deux marchés complètement distincts auraient existés. Il est clair que cela ne va plus se reproduire avant un bon moment, désormais.
# Pour ou contre le prosélytisme ?
Posté par Obsidian . En réponse au journal Laissons les Windowsiens tranquilles !. Évalué à 10.
1) La théorie de la caverne. L'utilisateur ne saura pas qu'il y a mieux si on ne lui dit pas. Bon nombre d'utilisateurs pensent que rebooter une machine est une chose normale, que cela devrait être fait régulièrement, et croient sans difficulté leur interlocuteur lorsqu'il leur dit que WinXP est une avancée technologique majeure parce qu'il y a moins d'écrans bleus ou parce que « quand un programme plante, on peut la plupart du temps le fermer sans avoir à redémarrer son ordinateur et perdre son travail » (affirmation extraite des slides de présentation à l'installation de Windows XP).
2) LES SENTIMENTS. Aussi incroyable que cela puisse paraître, l'utilisateur de base s'attache émotivement et en moins de trois semaines au système qu'il utilise, au point de vraiment prendre très mal toute critique contre ce système. Dans la plupart des cas, vous verrez le visage du sujet devenir très grimaçant, ce qui est une mauvaise chose parce qu'il conservera contre vous une rancoeur dont il ignorera l'origine. Au pire, vous le verrez fondre en larme (c'est pratiquement arrivé à un copain, et je ne me moquais pas de lui).
Tout cela est très irritant lorsque de meilleurs systèmes existaient bien avant la suprémacie de Windows. Cela devient carrément un problème lorsque certains cas auraient pu être réglés en moins de temps qu'il n'en faut pour le dire avec les outils appropriés (en général la dernière KNOPPIX suffit), mais qu'un DSI borné restant à un « je ne veux pas voir de CD de Linux traîner » vous empêche de le faire ...
Bien souvent, en informatique, on privilégie le mysticisme aux critères techniques.
[^] # Re: C'est un peu idiot de devoir mettre un titre pour un commentaire non
Posté par Obsidian . En réponse au message Ou sont définis les répertoires standard pour #include <> ?. Évalué à 2.
En ce qui concerne les caractères spéciaux, utiliser les mots-clés < et > devrait te permettre d'afficher tes <balises> correctement.
Vala ...
# Le CV
Posté par Obsidian . En réponse au journal Stage de fin d'année dans le cadre de mes études. Évalué à 4.
1) Pas la peine d'essayer de bluffer ton interlocuteur. Des stagiaires, il en voit passer des dizaines par an, donc au travers de ton CV il lit en toi comme dans un livre ouvert. Pas de honte à avoir: Il est normal qu'à 19 ans et en sortant de l'école, ton expérience professionnelle soit réduite. Ce qui va compter le plus, c'est ta motivation et ton initiative. La façon dont tu vas t'exprimer à l'écrit va en dire long à ce sujet.
2) Ton cursus tient largement sur une seule page. Vouloir remplir la première par de la mise en page, et s'étendre sur une deuxième est une erreur de débutant (que j'ai faite à ton âge). Ton CV aura l'air largement plus étoffé si tu ne le dilue pas sur ces deux pages.
3) « Juillet 2002: ... et travail à la chaîne » ! Pas top.
4) Enfin, mets en tête de page le poste pour lequel tu as été formé. Il faut attendre la deuxième page pour le savoir, en l'état actuel des choses. DUT informatique c'est trop vague. Précise ce que tu sais faire, et surtout ce que tu vise: programmation ? administration système ? Technicien micro/réseau ? Support Technique ? Hotline ? etc.
N'hésite pas à prendre conseil auprès des professionnels ou des centres d'orientation si tu veux être sûr de viser juste et de faire un stage qui te plaise. Si tu te loupes, tu ne tireras aucun profit de cette expérience et tu risques de faire perdre beaucoup de temps aux gens qui vont t'accueillir.
Bienvenue dans le monde du travail et bonne chance !
# Et un simple fichier ?
Posté par Obsidian . En réponse au message Une base de donnée intégrée ?. Évalué à 2.
- Elle doit être utilisée par un seul programme ou par plusieurs en même temps ?
- Ta liste d'éléments, elle est toute seule ou il y en a plusieurs, avec des relations entre elles ?
Si c'est la première réponse dans les deux cas, et qu'en plus les opérations d'insertion sont rares, alors tu as plus vite fait de mapper un fichier en mémoire avec mmap() ou mmap64(), de récupérer de le pointeur sur la zone et de le caster, genre:
typedef struct _element
{
char element [128];
unsigned long int checksum;
} Element;
Element * ptr;
ptr= mmap (LesArgumentsQuiVontBien);
Le contenu de ton fichier sera alors immédiatement utilisable comme si c'était un tableau en mémoire.Un petit « ptr[x] » pour retrouver immédiatement l'élément x. Simplicité et rapidité: C'est le système qui s'occupe du chargement/déchargement des pages et de choisir leur granularité.
Pour retrouver tous les éléments, un simple balayage de 0 à n-1 éléments. Techniquement, il n'est pas possible de faire plus rapide. Tu peux ajouter un index à tes « éléments », mais si tu dis que les insertions sont rares, tu peux te permettre de les trier en temps réel. Gain de temps à la lecture grandement amélioré !
Le seul tout petit souci que tu peux avoir apparait lorsque tu modifies la structure de Element: Il faut reconstruire le fichier. C'est exactement la même chose avec un SGBD, sauf que l'opération se fait automatiquement lorsque tu lui demande. Quoiqu'il en soit cela reste très simple: Deux définitions de structures, deux pointeurs ptr1 et ptr2, deux mmaps et une boucle qui scanne tous tes éléments, avec à chaque itération une copie de l'une des structure vers l'autre, et c'est fini.
Bonne chance.
[^] # Re: C'est louche
Posté par Obsidian . En réponse à la dépêche Le DRM ne fonctionne pas, et on le savait.. Évalué à 2.
...fait un peu trop peu (!) parler de lui ...
[^] # Re: mouaich
Posté par Obsidian . En réponse à la dépêche Le DRM ne fonctionne pas, et on le savait.. Évalué à 8.
Mais pourquoi diable faut-il que chaque fois que l'on parle de littérature ou d'art, et d'une manière générale de culture, on fasse référence aux classiques ?
Loin de moi l'idée de remettre en cause l'immense contribution apportée au patrimoine de l'humanité par ces grands auteurs, mais nom d'un chien, ils ne sont pas tout seuls !
On nous distille cette vérité toute faite depuis l'école, et comme l'Education Nationale est pratiquement le seul sésame pour arriver à faire quelque chose de sa vie en France, ceux qui réussissent et qui donc définissent les standards sont ceux qui ont adhéré et apprécié les oeuvres définies par les programmes.
Moi, cela me dérange. En suivant cette voie, un auteur ne peut être s'il ne suit les traces de ces « modèles », et restera de toute façon qu'un « ordinaire » tout au long de sa vie, à moins que se produise le miracle qui brusquement va le faire entrer au panthéon, au club très fermé des gens qui nous montrent la voie.
J'ai beaucoup plus d'estime pour quelqu'un qui va aller faire l'effort de dénicher une perle rare, un livre presqu'anonyme et en révéler toutes les subtilités, plutôt que pour quelqu'un qui va se gargariser d'oeuvres archi-connues sous prétexte que c'est culturellement correct.
Sur tous les grands lecteurs, combien sont capable d'apprécier le monde et l'histoire de la bande dessinée ?
Si bon nombre de personnes sont (heureusement) encore capables d'apprécier un bon morceau de musique dite « classique », sur tout ceux qui vont vous parler de Mozart, Beethoven, Brahms, Chopin, Bach ... combien sauront vous parler de John Williams, de Danny Elfmann ou Jerry Goldsmith ?
D'autre part, beaucoup de ces auteurs ou compositeurs sont devenus des « génies » parce qu'ils étaient pionniers en leur domaine. Qui se souviendra du 10ème homme à avoir marché sur la Lune ? Qui se souviendra dans 100 ans des plus grands morceaux composés à la fin du vingtième siècle ?
La plupart des « classicistes » le sont en fait soit parce qu'ils ont une banale affinité pour ce style, soit parce qu'on leur a toujours dit que c'était Bien™.
Ben moi, je ne les crois plus.
[^] # Re: relativisons quand même
Posté par Obsidian . En réponse à la dépêche Le marché des logiciels libres est arrivé à pleine maturité. Évalué à 7.
Moi-même, j'y ai mis les pieds pour une mission de migration fin 2000.
A l'époque, l'un des responsables informatiques était assez passionné et nous expliquait en détail, à moi et un pote aussi Linux que moi, la stratégie suivie pour réécrire Access (je ne sais pas d'où ils tenait ses sources).
Il nous a dit « Quand je vois Linux, je rigole ! », ne sachant pas qu'il a avait à faire à deux passionnés d'Unix. Il a fait une drôle de tronche quand il s'en est rendu compte.
Un mois après, nous étions mis dehors, à quelques jours d'intervalle et pour un motif assez nébuleux ... je ne sais pas si cela a pesé dans la balance ... :-)
[^] # Re: Eon
Posté par Obsidian . En réponse au journal Ne déménager pas.. Évalué à 2.
D'ailleurs sur http://www.geog.ouc.bc.ca/physgeog/physgeoglos/e.html(...) , on trouve pas mal d'infos interressantes:
Eon: Longest geologic time unit.
Mais aussi:
Eddy: A localized chaotic movement of air or liquid in a generally uniform larger flow.
Ce qui explique bien des choses et colle d'une manière générale assez bien à l'esprit de la Tribune ... :-)
[^] # Re: mouaich
Posté par Obsidian . En réponse à la dépêche Le DRM ne fonctionne pas, et on le savait.. Évalué à 2.
Toujours est-il que pour moi, une console de jeux, cela fonctionne avec une cartouche ! J'ai pris l'arrivée de la PSX et de ses CD comme un sacrilège ! :-)
Effectivement, vers la fin des années 80 je payais mes jeux vidéos environ 200 francs. C'est vrai que depuis on les a vu doubler, mais il ne faut pas oublier que:
1) En 15 ans, les prix augmentent.
2) Les jeux vidéos sont devenus une industrie comparable à celle du cinéma. On ne peut - malheureusement - plus envisager écrire un jeu vidéo tout seul, par exemple. D'autre part, cela nécessite d'être rompu à toutes les dernières technologies, et évidement, de connaître parfaitement la 3D car aujourd'hui, « jeu vidéo » est pratiquement synonyme de « simulation » (Rha, les jeux de plateforme: nostalgie ... :-) ).
A mon avis, la seule raison pour laquelle le prix des jeux se stabilise autour de 60 euros est qu'un jeune ne peut s'offrir un logiciel de jeu pour l'équivalent de 500 francs ou plus, spécialement s'il a une durée de vie de quelques mois tout au plus, et que d'une manière générale personne n'a envie de le faire.
# Eon
Posté par Obsidian . En réponse au journal Ne déménager pas.. Évalué à 3.
Personnellement, de son temps, je ne crois pas que le chevalier d'éon avait l'ADSL ... :-)
[^] # Re: Le communiqué chez Mandrake
Posté par Obsidian . En réponse au journal Dépèche Reuters : Mandrakesoft remporte un contrat avec le ministère de la Défense. Évalué à 8.
Plus précisément: Un OS qui ne risque pas d'envoyer un missile au mauvais endroit et/ou au mauvais moment.
[^] # Re: ghostview
Posté par Obsidian . En réponse au journal Microsoft France conseille Linux. Évalué à 3.
Par contre le fait que ce PDF-là fasse planter gv est probablement dù au fait que ledit document doit avoir été écrit avec Word. C'est mal prti pour réduire le TCO ... :-)
# Laptops
Posté par Obsidian . En réponse au message Linux et Dell. Évalué à 3.
[^] # Re: Décidement !
Posté par Obsidian . En réponse au journal ANPE C'est quoi ce site ?. Évalué à 2.
# Debian ?
Posté par Obsidian . En réponse au message [Debian] Installer Fedora à partir des iso sans les graver. Évalué à 2.