Obsidian a écrit 5292 commentaires

Je ne voudrais pas dire de bêtises car je ne peux absolument pas citer mes sources, mais il me semble que même en cas d'erreur sur le prix, le magasin ne peut pas vendre à perte. C'est à vérifier ...

Plutôt que « lynx », Je te conseille « links », qui fonctionne décidément très bien et qui fait des efforts sur la mise en page. Lynx, lui, est très parresseux sur ce point.

Moi j'ai racheté un 6128+ avec son écran, le paddle, la cartouche de Burnin'Rubber et des disquette 3'' originales, le tout pour ... 10 euros ! :-)

Du coup j'ai rejoué à ... Obsidian ! Parce que les émulateurs c'est sympa, mais cela ne remplace pas une machine originale. C'est un peu comme voler en avion ou sur simulateur !

J'ai aussi déssassemblé le jeu. Du coup, après 15 ans de perplexité et d'incertitude, j'ai enfin découvert à quoi servait ce satané « Room Seeker » !

A+ tous !

Par défaut, lesdits « fichiers spéciaux » dans /dev occupent réellement une entrée du catalogue (et un inode !), même s'ils ne référencent aucun contenu stocké sur le disque. Les noms hda, hdb etc ne sont que des mnémoniques pour que l'utilisateur s'y retrouve, même s'ils sont standardisés, mais ce qui fait l'efficacité du fichier spécial, ce sont ces deux numéros MAJOR et MINOR qui vont eux réellement dire au kernel à quelle routine on souhaite causer.

Le problème est qu'à terme cela bouffe beaucoup d'inodes, et que surtout, il faut tous les créer lorsque tu installes de nouveaux périphériques ou compile une nouvelle fonction dans le noyau. On utilise mknod pour faire cela.

Pour éviter ces inconvénients, les mainteneurs de ta distrib préférée te les créent tous une fois pour toutes dans /dev. Si derrière le périph ou la fonction n'existe pas, le noyau répondra simplement « No such device » lorsque tu essaieras de lire ou d'écrire dans ce fichier.

Mais quand même, dans un souci d'efficacité, est apparu dans le noyau un nouveau filesystem, devfs. Celui-ci fonctionne exactement de la même manière que /proc, c'est-à-dire qu'une fois ce volume monté sur un répertoire (en l'occurence /dev) tout ce que tu vois dedans est simulé par le kernel.

Le noyau émule donc les /fichiers /dev standard et, pas bête, il ne génère que ceux qu'il sait gérer. Voila pourquoi sur une distrib normale, tu vas voir apparaitre tous les hda*, et lorsque tu montes devfs, seuls les disques présents apparaissent.

Enfin, tu n'es pas sans savoir que lorsque tu fais mount, le volume concerné masque le contenu du répertoire sur lequel il est monté (sans l'écraser). Lorsque que tu le démontes, ce qu'il y a en dessous reparaît. Donc si ton devfs est monté sur un répertoire /dev déjà plein de fichiers spéciaux, il est très probable - et c'est heureux - que tu ne constates aucune différence de fonctionnement.

Maintenant le devfs, on aime ou on aime pas:

Avantages:
- Tu récupères tous les inodes inutilement accaparés sur ton disque.
- Tu n'as pas maintenir ton répertoire /dev à jour, le noyau le fait pour toi.
- La liste des /dev est infiniment plus claire.
- Tu sais immédiatement ce que le noyau sait gérer ou pas, et tu sais qu'un /dev présent pointe forcément sur une routine qui fonctionne.
- Lorsque tu charges un nouveau pilote, en utilisant un module (modprobe), le noyau peut lui assigner dynamiquement un couple de numéros MAJOR/MINOR. Autrement, il faut attendre que l'autorité qui s'occupe de l'affectation de ces numéros t'en attribue un, ce qui sera forcément très long et probablement très incertain car ces numéros sont en nombre limité.

Inconvénients:
- C'est pas forcément standard
- Il faut de toutes façons avoir un minimum de fichiers spéciaux « ordinaires » dans /dev pour permettre au système de s'initialiser correctement jusqu'à ce qu'il monte devfs
- Le contenu du répertoire est volatile, et donc disparait à chaque démontage/remontage, ce qui exclut la création de liens symboliques dans le répertoire /dev, telles que /dev/cdrom ou /dev/mouse qui permettent de pointer directement le périphérique concerné, spécialement s'il s'agit de périphs amovibles ou USB.

Personnellement, je préfère m'en passer et gérer le système moi-même. Au moins cela libère beaucoup de ressources, cela exclut d'avance beaucoup de pannes et de conflits potentiels, et cela me permet de n'apprendre que l'administration Unix standard, et pas le fonctionnement de tous les outils de maintenance propre à chaque distrib !

Voila, bon courage.

Ben si c'est le CVS qui t'ennuie, lis déjà çà:

http://www.akadia.com/services/cvs_howto.html(...)

Ouais, c'était bien fun la programmation dans les années 80.

Ceci dit, cela m'étonnerais que ta seule préoccupation soit de savoir si des gens l'utilisent encore. Viens-en plutôt au fait et dis-nous sur quoi tu bloques ...

A++

Si tu as 69 DB d'atténuation théorique to installation ne joue pas (le calcul est basé sur la longueur de ton cable, les sections, ....). Tu peux toujours nettoyer ton installation pour avoir une meilleure atténuation pour esperer avoir un débit meilleur.

Ce que je veux dire, c'est que même avec un montage cradingue et aussi déconseillé que possible, mon ADSL fonctionne sans problème, et que donc je suis sûr, connaissant en plus l'état général du téléphone dans ma zone, qu'un débit plus haut passerait sans problème.

Je vais essayer de négocier mais je ne me fais pas trop d'illusions.

Je ne savais pas qu'il y avait déjà 4 versions de la Freebox, et encore moins que la dernière corrigeait le tir en matière d'atténuation.

Malheureusement pour moi, Free ne veut même pas me faire passer en 1024Kb avec mon Sagem :-( Donc c'est pas gagné ...

Le pire dans l'histoire est que, même sachant que la qualité d'une ligne se dégrade très rapidement comme l'on monte en fréquence, je suis sûr que celle de la mienne est suffisament bonne pour permettre le passage du très haut débit. En effet, avant d'arriver jusqu'à mon PC, ma ligne téléphonique passe à travers une rallonge qui l'emmêne jusqu'au 1er étage, se dispatche dans une double prise téléphonique, puis traverse encore le câble RJ11, pas l'original mais un plus long parce que je ne pouvais pas atteindre la fiche du téléphone. Même avec tout cela, mon modem n'a jamais eu de problème à se connecter ...

C'est pourquoi je te suggère d'utiliser <IFRAME>.
La syntaxe est la suivante:

<iframe src="l'url de ta page">

Cela créé une division à l'intérieur de ta page et pas plusieurs cadres indépendants. Essaie, c'est probablement ce que tu cherches à faire.

Qu'est-ce qu'un troll:

http://www.uzine.net/article1032.html(...)

N'empêche que les plus mal lotis ne sont probablement pas ceux qu'on croit. Moi j'habite dans une zone pavillonnaire pas trop vieille (1978 tout de même), à coté d'Evry (préfecture de l'Essonne, en région parisienne) et j'ai toujours eu un téléphone assez correct. Avec tout cela, on aurait pu s'attendre à être équipés assez vite et en technologie de pointe.

Eh bien bizzarrement, toujours pas de dégroupage chez moi, et l'ADSL elle-même est arrivée très tard. Même alors, Free a été vachement frileux car ils ont d'abord anoncé l'arrivée de l'ADSL sur ma ville, puis SE SONT RETRACTES, pour finalement y revenir, mais beaucoup plus tard. Heureusement, j'avais imprimé mon formulaire entre la première et la deuxième étape et j'ai pu m'abonner quand même (et mon modem n'a jamais perdu une connexion en deux ans).

Tout cela ne me gênerait pas si je n'habitais pas 5KM de mon central téléphonique, provoquant une atténuation déclarée de -69Db !

Ca veut dire que je suis condamné à rester à 512K (et donc évidement sans Freebox) pendant encore très longtemps et au même prix, parce que je ne pense pas qu'on vienne spontanément installer une ligne à haut débit et un autocom relais près de chez moi dans une zone réputée « équipée ».

Donc, ceux qui sont encore à 56K, patience ! Lorsque l'ADSL arrivera chez vous, il est probable que ce sera en très haut débit !

Moi c'est:

$ vi ~/bin/cl
#!/bin/sh
rm -f *~
rm -f .*~
rm -f core
rm -f *.bak

$ chmod 755 ~/bin/cl

Et ensuite

$ cl

Pour faire du propre dans mes répertoires de travail.
Je la recrée sur toutes les stations sur lequelles je travaille.

Flûte, j'étais à Antibes il y a 3 semaines ...
Bon, l'an prochain je m'occupe de çà ! :-)

Bon, alors dans mon éternel désir de dire le moins de bêtises possibles et histoire de me remettre un peu à niveau, quelqu'un pourrait-il nous indiquer un bon site qui fasse un peu l'état des lieux en matière de technologie d'affichage et d'interface standard en ce domaine (DRI, GLX, etc.). Je connais à peu près la signification de tous les sigles et leur principe général de fonctionnement, mais j'aimerais approfondir un peu et surtout ne rien rater (en tout cas pas les principaux).

Merci d'avance.

Ben là, je crois que je n'ai rien à ajouter, donc [+] !

Hmm. Je ne suis pas d'accord avec çà.

Certes, tes arguments sont pertinents, mais:

1) Cela laisse supposer que tout le savoir du fabricant réside dans son pilote. Ce n'est pas totalement exact. De plus, à te lire, tout ce code supplémentaire sert à émuler les générations précédentes, donc celles qui ne sont plus implémentées physiquement sur la carte. Ce n'est donc pas avec que l'on va voler la technologie du fabricant.

2) Un pilote binaire n'est ABSOLUMENT PAS protégé contre le reverse engineering. D'abord il s'agit d'un logiciel relativement réduit, pas d'un système d'exploitation entier, ensuite les pilotes de périphériques de pointe sont souvent les seuls programmes qui soient encore écrits dans un langage proche de la machine (C et pas mal d'assembleur, au moins pour accéder aux registres spécifiques de la carte) ce qui réduit la taille du code à explorer et permet d'éviter de se perdre entre ce qui relève du « code utile » et du padding autogénéré par les langages de haut-niveau. On peut donc facilement mettre une petite équipe de codeurs sur l'affaire qui en fera la synthèse et fournira les premiers résultats en un mois ou deux.

Moi-même j'ai fait le désassemblage (avec un désassembleur maison) des ROMs de mon vieux huit bits et en ai fait le commentaire ligne par ligne. Bon certes, il s'agit d'un logiciel de 1985 mais qui représente tout de même 2x10000 lignes d'assembleur et qui fait office de système d'exploitation complet (langage de prog, interface utilisateur, gestion de bas-niveau de tous les périphs, lecteur de disquettes, etc.).

Il me paraît évident qu'une équipe avec des connaissances à jour, spécialisée en cartes graphiques, et focalisée sur ce sujet précis peut faire de même et obtenir très vite de très bons résultats.

3) Il est tout-à-fait possible pour un fondeur de puces de procéder à la rétro-ingéniérie physique d'un circuit déjà intégré ! Un copain en école d'ingé spécialisée en électronique me l'a montré. Le boitier du circuit a été ouvert et la puce scannée pour en reproduire le masque ou quelque chose qui y ressemble. A partir de là, il fallait déduire la fonction du circuit. C'était un sujet de TP. Bon, là encore, le circuit en question était un 4011 (4 portes logiques NON-ET, le circuit de base), mais là encore en y mettant un peu de temps, on peut rapidement reconnaître les motifs courants et estimer si telle ou telle technologie se trouve dans une puce ou pas.

4) Ces arguments sont valables pour des secteurs de pointes comme les cartes graphiques par exemple, pas pour d'autres périphériques telles que les imprimantes, souris, etc.

5) Cela se faisait avant ! Pendant longtemps j'ai eu les spécifications de mes périphériques fournies dans la boite. En 85, quand je branchais un modem sur mon TO8D, j'avais un schéma électronique qui décrivait l'intérieur de l'appareil, les spécifications de chaque port IO, ainsi qu'un exemple de programme en assembleur pour l'exploiter au mieux. Notre foyer avait également fait l'acquisition d'un manétoscope et d'un autoradio, et à chaque fois le schéma était inclus. A partir des années 1990, les spécifications complètes se sont faites plus rares, mais le protocole de communication, au moins la liste des codes reconnues, était toujours disponible et tout le monde trouvait cela normal. C'est donc bien un effet de mode et une mauvaise habitude qui pousse les fabricants à cacher les informations nécessaire à leurs utilisateurs, pas d'autre raison à mon goût ...

Tout est question de rapports de force:

1) Le constructeur n'est pas interressé par Linux;
2) Donc: La communauté le boycotte;
3) Donc: Le constructeur n'est définitivement plus interressé.

C'est l'histoire du prisonier qui n'a ni à boire ni à manger et qui fait une grêve de la faim pour protester.


Au contraire, plutôt qu'un boycott actif, il faut d'abord se demander si le support des cartes ATI serait vraiment aussi profitable à la communauté qu'on veut bien le dire. Si la réponse est oui, alors il faut faire suffisament de tapage pendant suffisament de temps pour le constructeur finissent par croire en notre existence et nous prenne au sérieux.

D'une manière générale, je n'ai jamais compris la frilosité des grands constructeurs vis-à-vis de la publication de leur spécifications. Qu'un éditeur de logiciels ne veuille pas ouvrir son code source, j'arrive à imaginer pourquoi, c'est son fond de commerce, il veut également garder pour lui les astuces de ses meilleurs développeurs, mais dans le hardware, le logiciel est tout-à-fait secondaire, c'est juste une nécessité pour pouvoir faire fonctionner le périphérique.

Alors quand on propose au constructeur de lui écrire le pilote à l'oeil, et de lui ouvrir sans que cela lui coûte un sou de plus l'accès à un segment non négligeable du marché de l'informatique (Linux, et tous les autres OS alternatifs), et que je vois que la majeure partie du temps on se fait recevoir au choix par du dédain, de la méfiance, du mépris ou de l'indifférence, j'en arrive vraiment à croire que les personnes les plus haut placées de ces compagnies ne connaissent rien aux ordinateurs ...

Aurélien, un peu choqué sur le coup.

Posté par Pascal Terjan (page perso) le lundi 23 août à 13:37

Y a un truc qui me laisse perplexe, là ...

C'est étrange que tu aies besoin d'un package particulier pour faire fonctionner ta carte réseau, mais sinon

http://www.rpmfind.net(...)
http://rpm.pbone.net(...)

... te permettront sûrement de retrouver par le Net les packages de ta distribution préférée.

Sinon, tu as quoi comme carte réseau ? un simple « modprobe e100 » en root ne serait-il pas suffisant ?

A++

Il me dit : no screens found.

La détection du moniteur a du foirer. Il faudrait probablement éditer /etc/X11/XF86Config-4 pour remettre un écran « générique » dans la section idoine.

Essaie de lancer en root la programme /usr/X11R6/bin/xf86config . Cela devrait te permettre de recréer sans trop de soucis un fichier de configuration correct.

Bonne chance.

Attention, « lo » comme « Locale » ou « Loopback » est comme son nom l'indique une interface virtuelle émulée par le noyau et qui te renvoie à toi même les paquets que tu lui envoie. Elle sert à gérer les paquets envoyés à 127.x.x.x. Donc il faut que tu laisses ton interfaces « lo » à 127.0.0.1.

Encore quelques mots donc:

- Il est évident, dans un système multiutilisateurs, que seul un administrateur peut changer l'IP d'une interface réseau. Donc passer root avant de lancer la commande.

- Essaie ifconfig -a (comme « all ») pour afficher la liste de toutes les inferfaces réseaux reconnues par ton système. Cela t'aidera peut-être à reconnaitre la bonne.

- Si vraiment tu n'as pas d'autres interfaces que « lo » et que tu es sûr d'avoir une carte réseau dans ton ordinateur, c'est que le kernel ne la reconnait pas encore. Donc voir du coté de « modprobe ».

Bon courage.

Le problème principal avec les frames, c'est qu'il brise le concept « une page = un lien ». En effet, si tu te promènes dans un site en utilisant un navigateur latéral, et que tu as fini par trouver les informations qui te plaisent, tu ne peux ni bookmarker la page complète (avec les frames qui vont autour), ni mettre en place un lien vers elle, mais seulement vers la page contenue par un seul frame. Un autre inconvénient: Ce genre de structure est très difficilement référençable par un moteur de recherche.

Pour la place du sommaire dans le document, cela se discute. Certes, il ne fait pas partie de l'information liée au lien que tu as employé (d'autant qu'il est répété sur toutes les pages), mais si on reprend l'exemple de l'impression, l'utilisateur voudra peut-être avoir des enêtes et pieds de page sur son papier, alors qu'ils sont complètements inutiles à l'écran. Il en reste que ceux-ci devront bel et bien être spécifiés par la page HTML. Dans le même esprit, une personne dont la vision est bonne n'a que faire de modules « aural » par exemple, alors qu'ils sont pratiquement nécessaires pour un non-voyant.

Tout cela pour dire qu'un document HTML doit contenir toutes sortes d'informations qui peuvent être utiles à l'utilisateur dans le contexte qu'il a choisi en suivant une URL. C'est ensuite aux CSS de moduler la présentation - voir faire carrément disparaitre - les différentes sections du document en fonction de l'environnement de travail.

Enfin, si cela te saoule (et je le comprends) de réinsérer un même sommaire dans chaque page et de tous les maintenir par la suite, tu peux utiliser <iframe>. Le problème de référencement sera le même, mais au moins ton iframe est soumis aux CSS et se trouve à l'intérieur de la structure de ton document, pas autour.

Quelques précisions maintenant:

- « ifconfig » est une commande standard Unix pour manipuler les InterFaces réseau, qu'elles soient physiques (Ex: « eth0») ou virtuelles (Ex: « ppp0 »).

- Il n'y a que le nom de l'inferface (ici « eth0 ») qui soit obligatoire avec ifconfig. Tous les autres paramètres sont optionels. Ici « 192.168.0.1 » définit la nouvelle adresse et « up » demande au système de l'activer, si ce n'étais pas déjà fait. « down » te permet de la désactiver. Mais il existe aussi « netmask », etc. ---> man ifconfig.

- Je précise pour les windowsiens (les anciens en tout cas) que les modifications prennent effet immédiatement. Pas besoin de rebooter donc ! :-)

- Toutes ces modifications sont dynamiques. Elles ne persisteront pas au prochain reboot. Si tu veux faire quelque chose de permanent, cela dépend du système que tu utilise. Redhat et Mandrake utilisent le répertoire /etc/sysconfig pour y stocker toutes les informations utiles pour remettre le système en état au démarrage. Dans « networking », tu devrait trouver un fichier du style « ifcfg-eth0 » qui contient toutes les informations à passer à ta carte, dont l'adresse IP en face de la ligne « IPADDR ». Ce fichier, évidement, ne sera réinterprêté que lorsque le script qui s'en occupe sera relancé. Donc à un redémarrage, ou éventuellement si tu changes de runlevel (à vérifier).

/sbin/ifconfig eth0 192.168.0.1 up

Avec l'adresse qui te plaît ...