Non, mais tu peux essayer d'ouvrir 30 connexions FTP à la fois par exemple. Pouvoir surfer, écouter un stream audio, voir téléphoner, sans être systématiquement embouteillé lorsque que tu vas chercher la dernière ISO à la mode est réellement très confortable ! :-)
Bon en même temps, c'est pas une raison pour en abuser. Si tout le monde se restreint, malgré la liberté, à n'utiliser que ce dont il a besoin, cela permettra aux FAI de rester en vie, et surtout de conserver l'autoroute fluide pour les cas où l'on a réellement (et ponctuellement) besoin de 6Mb pour quelque chose d'important.
Alors, également, une info qui peut être profitable à tout le monde:
J'ai recompilé un noyau pour ma machine récement, et me suis mis à me prendre des « Oops » noyau au démarrage, après le lancement de Init et des trucs à RedHat.
Après une brève recherche, je me suis rendu compte que j'avais compilé le noyau pour le mauvais processeur, en l'occurence Pentium 3 au lieu du P2 de la machine en question.
Moralité, surveillez toujours cette entrée car par défaut, le noyau est configuré pour compiler sur le processeur le plus courant. Celui-ci change avec le temps.
Euh, une minute ... J'imagine la publicité est mensongère parce qu'un mainframe IBM coûte autrement plus cher qu'un PC mais quand je lis:
« montrant qu'une infrastructure Intel/Windows coûte sensiblement plus cher qu'une infrastructure mainframe/Linux, pour un usage comme serveur de courriels... »
Cela abonde dans le même sens: Si un mainframe Linux est moins cher qu'un PC Windows (en gros), alors a fortiori un PC Linux est moin cher qu'un PC Windows. Dans ce cas ce n'est plus de la publicité mensongère ...
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 » !
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 !
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 ...
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 ...
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 !
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).
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 ...
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 ...
[^] # Re: augmentation débit
Posté par Obsidian . En réponse au journal Update Free dégroupé. Évalué à 2.
Bon en même temps, c'est pas une raison pour en abuser. Si tout le monde se restreint, malgré la liberté, à n'utiliser que ce dont il a besoin, cela permettra aux FAI de rester en vie, et surtout de conserver l'autoroute fluide pour les cas où l'on a réellement (et ponctuellement) besoin de 6Mb pour quelque chose d'important.
[^] # Re: c'est MON film culte
Posté par Obsidian . En réponse au journal Jason X, roi du Z. Évalué à 2.
[^] # Re: Plus d'infos
Posté par Obsidian . En réponse au journal Crash repete serveur linux. Évalué à 2.
J'ai recompilé un noyau pour ma machine récement, et me suis mis à me prendre des « Oops » noyau au démarrage, après le lancement de Init et des trucs à RedHat.
Après une brève recherche, je me suis rendu compte que j'avais compilé le noyau pour le mauvais processeur, en l'occurence Pentium 3 au lieu du P2 de la machine en question.
Moralité, surveillez toujours cette entrée car par défaut, le noyau est configuré pour compiler sur le processeur le plus courant. Celui-ci change avec le temps.
[^] # Re: C'est pas (que) le journaliste
Posté par Obsidian . En réponse au journal les journalistes sont quand même de grand comique. Évalué à 3.
# Le lien ?
Posté par Obsidian . En réponse au journal les journalistes sont quand même de grand comique. Évalué à 5.
# Plus d'infos
Posté par Obsidian . En réponse au journal Crash repete serveur linux. Évalué à 4.
Peux-tu donner plus d'infos ? Est-ce arrivé du jour au lendemain, suite à une mise à jour logicielle, ou bien est-ce que cela a toujours été le cas ?
Si récement ton serveur s'est mis à faire des crashs sévères et complètement sans raison, il est fort possible que ce soit hardware:
1) Une RAM défectueuse (memtest86).
2) Une machine plus assez ventilée. As-tu rajouté du matériel autour de ton serveur récement ?
Bon courage.
# Mainframe <-> PC
Posté par Obsidian . En réponse à la dépêche Get the facts ! Regardons de plus près.... Évalué à 8.
« montrant qu'une infrastructure Intel/Windows coûte sensiblement plus cher qu'une infrastructure mainframe/Linux, pour un usage comme serveur de courriels... »
Cela abonde dans le même sens: Si un mainframe Linux est moins cher qu'un PC Windows (en gros), alors a fortiori un PC Linux est moin cher qu'un PC Windows. Dans ce cas ce n'est plus de la publicité mensongère ...
Où est-ce que j'ai raté quelque chose ?
[^] # Re: Hum...
Posté par Obsidian . En réponse au journal Dans la suite des erreurs qui font bien rire. Évalué à 4.
# Essaie links
Posté par Obsidian . En réponse au journal DLFP pénible à lire .... Évalué à 7.
[^] # Re: Moi ...
Posté par Obsidian . En réponse au message programmation. Évalué à 2.
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 !
[^] # Re: gestion des périphériques
Posté par Obsidian . En réponse au message gestion des périphériques. Évalué à 5.
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.
# CVS
Posté par Obsidian . En réponse au message Un peu d'aide pour un débutant de sourceforge ?. Évalué à 2.
http://www.akadia.com/services/cvs_howto.html(...)
# Don't ask to ask ! Just ask !
Posté par Obsidian . En réponse au message programmation. Évalué à 3.
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++
[^] # Re: alala
Posté par Obsidian . En réponse au journal Free augmentent les débits. Évalué à 2.
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.
[^] # Re: alala
Posté par Obsidian . En réponse au journal Free augmentent les débits. Évalué à 2.
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 ...
[^] # Re: Remplacer les frames
Posté par Obsidian . En réponse au journal Remplacer les frames. Évalué à 2.
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
Posté par Obsidian . En réponse au journal Le Public de LinuxFr. Évalué à 5.
http://www.uzine.net/article1032.html(...)
[^] # Re: alala
Posté par Obsidian . En réponse au journal Free augmentent les débits. Évalué à 7.
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 !
# Tirer la chasse.
Posté par Obsidian . En réponse au journal Votre commande favorite. Évalué à 3.
$ 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.
# Linux trop haut à la gare de Nice...
Posté par Obsidian . En réponse au journal Linux trop haut à la gare de Nice.... Évalué à -1.
Bon, l'an prochain je m'occupe de çà ! :-)
# De la doc !
Posté par Obsidian . En réponse à la dépêche Une pétition pour obtenir des pilotes ATI de meilleure qualité. Évalué à 4.
Merci d'avance.
[^] # Re: C'est une excellente chose
Posté par Obsidian . En réponse à la dépêche Une pétition pour obtenir des pilotes ATI de meilleure qualité. Évalué à 2.
[^] # Re: C'est une excellente chose
Posté par Obsidian . En réponse à la dépêche Une pétition pour obtenir des pilotes ATI de meilleure qualité. Évalué à 10.
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 ...
[^] # Re: Linux et le Hardware.
Posté par Obsidian . En réponse à la dépêche Une pétition pour obtenir des pilotes ATI de meilleure qualité. Évalué à 7.
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.
[^] # Re: Si ça fait avancer le schimililililili...
Posté par Obsidian . En réponse à la dépêche Une pétition pour obtenir des pilotes ATI de meilleure qualité. Évalué à 9.
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 ...