Schwarzy a écrit 333 commentaires

J'ai acheté cette écran sur un coup de tête. Il me sert de moniteur pour mon serveur et occasionnellement de second moniteurs pour ma carte vidéo dual head.

Très bonne qualité. Les noirs sont presques parfait (mais pas encore un bon CRT [j'ai un 19" Misubishi]). Presques parce que c'est pas encore un noir de CRT.

Ce qui me fait juste chier c'est que j'ai un pixel mort (couleur rouge!).

Pour le reste, j'ai utilisé ce moniteur pour la TV et les DVD. C'est plus que correcte. Par contre il faut être en face du LCD sinon, les noirs tourne très vite en brillance.
Le seule vrai problême, c'est qu'il n'y a pas de DVI et que l'entrée utilise un cadrage automatique lorsque la résolution n'est pas native du LCD (1280x1024). Donc pour les jeux c'est pas tjrs la joie. Le truc est de trouver un écran avec les bordures bien colorées et de refaire un cadrage auto.

Avec 16 ms de temps de réponse les jeux et autres animations sont très bien. Mais attention, certraines personnes peuvent avoir une sensibilité accrus et même 16 ms n'est pas suffisant.

Perso, c'est pas encore aujourd'hui qu'un LCD va remplacer mon CRT.

Ben ma petite expérience sur le sujet au niveau de Windows NT:

NT 4 - Mes essais de défragmentation n'ont jamais été vraiment utile. Je n'ai jamais eu de gain de perfs. De plus la fragmentation est tjrs restée faible sur 1 an 1/2 d'utilisation.

Win2k - C'est toujours du ntfs mais une révision supérieur. Après un peu plus d'un an d'utilisation sur un laptop, je suis dans l'obligation de défragmenter tous les mois. Le fait que le dd de laptop est plus lent qu'un desktop accentue le problème.
Pire, un fichier systême qui est très sollicité était dans un état de fragmentation énorme et ralentissait le boot. Un utilitaire sur www.sysinternal.com permet de défragmenter au boot les fichiers systèmes. Le boot de 2/3 minutes a pu être ramené vers 1 minute.
J'ai aussi noté une croissance impressionnante du nombre de block systeme avec le temps (aucune idée sur l'origine). Je dois maintenant maintenir au moins 25% disponible sur la partition pour pouvoir défragmenter correctement.

WinXP semble souffrir des mêmes défauts. A noter que la compression des fichiers pendant les temps d'inactivité de la machine 'tue' les performances du FS avec le temps (genre 2/3 mois) si vous faites beaucoup de manip sur la même partition.

J'ai eu des partitions ext2 jusqu'à 3 ans d'age avec un taux de fragmentations tjrs inférieurs à 5 %. Le 5 % étant sur des partitions biens remplis. Jamais les perfs n'en ont souffert de facon significative.

Je veux bien y croire si MS confirme que c'est sans les marges bénéficaires (qui sont d'environ 80% sur Windows et Office pour rappel). Au passage, cela expliquerait la faible qualité du code chez MS.

Yes, I speak fuch*ng american business english !

Perso, pour le peu de manip d'image que je fais et que je veux automatiser, j'ai utilisé ImageMagick en ligne de commande. Il existe aussi une interface de programmation C++. Je crois que l'ensemble est libre (enfin j'ai rien vu dans les packets qui soient dans non-free sur la SID de Debian).

Pour moi, Gimp est d'abord un programme intéractif de retouche d'image et les plugin sont la pour être utilisé au coup par coup. Je ne vois pas Gimp comme un outil de traitement à la chaîne. Toutefois, Gimp est peut-être capable d'être utiliser dans ce contexte.

O_o

Je parlais d'environnement hostile (un serveur est rarement considéré comme dans un environnement hostile -- de plus le PC n'est pas fait pour ça). Linux peut-être utilisé dans l'embarqué, je ne dit pas le contraire. Mais lorsque tu te retrouves à faire face à des environnements hostiles (en général le petit embarqué) et que tu dois faire du stockage de quelques données, linux et ces systèmes de fichier ne sont pas adaptés à moins d'avoir une batterie pour faire atterrir le systeme en douceur. Dans ce cas, on se reporte sur des environnements propriétaires où les structures de données (OS et application) sont adaptés pour ne pas se corrompre (c'est d'ailleurs assez proche du journaling parfois mais pas tout à fait parce que l'on rajoute aussi du CRC un peu partout). ce genre de système n'est pas un foudre de guerre en terme de vitesse mais c'est très robuste.

Au passage, si Linux est le plus utilisé en embarqué, c'est parce qu'il offre une pile TCP/IP et du stockage. L'embarqué (le high-end) a maintenant pas mal de capacité de ce coté grâce aux progrès technologique et la disponibilité du code source permet de construire des solutions flexible. Par exemple, une borne d'accès Wifi est idéale pour acceullir Linux (réseau et pas de stockage donc tout en RAM pour les data).
Si tu n'as pas besoin de la pile réseau et de faire du stockage Linux n'est plus très interressant. On se retrouve à ce niveau vers le petit embarqué, d'ailleurs QNX se débrouille mieux en terme de consommation mémoire dans ce contexte.

Ce que tu cherches est très spécifique à cause de l'arrêt brutale de la machine. Un process qui meurt, le systeme d'exploitation peut reprendre avec moins de problème. C'est du software qui doit pouvoir tourner en mileu hostile. Personnellement, pour travailler sur ce genre de chose, jamais je ne ferais confiance à Linux (et encore moins Windows !). Non, pas qu'ils sont mauvais mais parce qu'ils n'ont jamais été prévus pour les milieux hostiles. Comme je suppose que tu n'as pas le choix sur la plateforme de développement, je te conseille d'ajouter un onduleur/batterie au systeme. Si la courant vient à lacher, il y aura assez d'énergie pour assurer un arrêt en douceur. Prévoir aussi un arrêt en douceur du process en interceptant les demandes d'arrêt (signaux ou autres) de la part du systeme d'exploitation.

Ca marche mais si la partition n'a pas été correctement close, il faut absolument faire un fsck /dev/ma_partition pour que le journal des modifications soit parcouru et la partie ext2 de la partition soit valide.

Ben si tu as pensé à ne pas manipuler ta partition (genre tu as fait un reboot de linux). Il y a encore moyen de t'en sortir avec ça:

http://recover.sourceforge.net/linux/recover/(...)

Mais ca ne marche qu'avec ext2/3. il faut aussi le faire avec un CD de boot (knoppix peut-être) et à stocker les fichiers sur un autre support (NFS via réseau, clé USB, lecteur ZIP, second DD, etc ...).

De la concurrence pour Apple sur le terrain du design d'ordinateur ? :)

C'est vrai que faire du COM avec python, c'est sympa. C'est peut-être même la seule facon sympa d'en faire. Parce que avec d'autre language, c'est imcompréhensible et j'ai vite mal au crâne.

Par contre, il reste toujours le problème d'un manque de documentation correctes pour bien des interfaces. Peut-être qu'on a pas donné assez de pognon à MS. Ou alors j'ai pris l'habitude d'avoir la documentation gratuitement avec Linux ... (oui oui c'est un troll :) )

Je sais pas si tu l'avais déja lu mais voilà la situation de l'ACPI avec Linux, tel que j'ia pu l'apprendre aux détours de forums de discussions: - Les portables actuelles ont une implementation basée sur la version Windows de l'ACPI. Cette version est défaillante (et incomplète ?). Les constructeurs de portables (et PC) ont conçus les tables ACPI dans les BIOS par rapport à cette version défaillante et non par rapport aux specifications officiels . - Les mainteneurs de l'ACPI pour Linux refusent de tenir compte des bugs de la version Windows (ca se comprend). En consequence, les tables ACPI présentes dans le BIOS pour assurer la gestion d'énergie se plante fréquemment avec l'implémentation Linux de l'ACPI. - Toutefois, ces mêmes tables sont réécrites par des volontaires au cas pas cas pour différents hardware. Elle remplacent les tables Windows présentes dans le BIOS. Je n'ai aucune idée de l'avancement de ces réécritures. Bref, si l'ACPI fonctionne très mal sous Linux, c'est MS qui est à blâmer. Bien sûr, il n'y a pas que Linux qui en souffre. Le meilleur support pour la gestion d'energie est aujourd'hui disponible via l'APM. Mais il est de moins en moins supportés au profit de l'ACPI (version Windows).

Un bouquin à avoir pour Linux (et bien d'autres sytèmes) si l'on programme en C ou C++:

"Building Secure Software" de J. Viega et G. McGraw

ISBN 0-201-72152-X

http://www.eyrolles.com/php.informatique/Ouvrages/ouvrage.php3?ouv_(...)

http://www.buildingsecuresoftware.com/(...)

Arf !

c'est vrai qu'après le fiasco "SmartCard for Windows", ils essaient de faire gaffe.

non 100 % ca n'existe pas puisque qu'il dépend du système en-dessus (cf le mail de Christophe Grand sur le dilemme et la superposition des abstraction). Mais il peut prétendre au 99%. Surtout que c'est la même implémentation. Mais il est tout à fait faisable de faire une version liée à Windows en utilisant des bibliothèques Windows only. Je te renvoie à nouveau au mail de Christophe Grand.
Il serait par contre intéressant de conparer Python et Jython.

Si tu démarres dans ce mode fou, fou, fou de la programmation, une petite remarque sur la notion de portabilité.

Même si elle trouve ses racines sur un plan technique, c'est du marketing. Obtenir la portabilité, c'est mettre en place des outils automatiques de test (dit de régression dans un jargon plus technique). Mettre au point de tel outils, c'est long, très long, très très long même, difficile et le boulot le plus dévalorisant.
En conséquence, il est rare de pouvoir avoir des tests de qualité. Les spécifications aident plus les programmeurs (les clients) que les programmeurs qui font l'implémentation. Ils existent toujours des zones de flous qui parasitent la portabilité. Enfin, tu peux intégrer les bugs dans les objectifs de la portabilité. Ce dernier aspect est celui qui casse le plus la portabilité.

Mais, heureusement, avec le temps [genre 10/15 ans], il arrive que des technologies arrivent à approcher les 99 % de compatibilité entre les différentes implémentations. En exemple j'ai l'ANSI C, le Forth dans les languages informatiques. Java, POSIX sont pas trop loin (encore que ... Java 95%, POSIX 90% [au pifomètre :)] ). Win32 ça tient la route (90%) si on suit uniquement la version NT,2k et XP (les 9x,Me c'est de la merde en boîte).

lol, tout à fait dans mon propos, gcc est devenu le « standard » à suivre parce qu'il est le plus répandu.

euh .. tu frises l'insulte là ! Déja prouves-moi que gcc est le plus répandu (et dans quel domaine ?).
De plus si gcc est aussi apprécié, et peut-être répandu, c'est pour sa fiabilité. Je me demande si tu as vraiment programmé en C en jour pour sortir de tels propos. J'ai déja environ 12 ans de C et gcc est une vrai rolls. Je rêve de le voir partout dans l'embarqué parce que j'en ai marre de debugger, et mon code, et le compilo !!!!

Pour être précis. Tous les compilo qu'on trouve aujourd'hui arrivent à suivre ua moins la norme ANSI (1989). Les extensions que l'on trouve existent pour tenir compte des contraintes de la programmation système. Ils s'agit de mots clés ajoutés au language et facilement masquable dans des macros.

Je parle bien de la portabilité du language. Les problèmes liés aux architectures et au matériel existent toujours et sont à imputer au language C et non aux compilo.

A propos de gcc et de BSD, gcc est l'un des premiers programmes qui ait existé dans le projet GNU. Il a rapidement atteint une qualité certaine qui a séduit beaucoup de développeurs dans les années 90 et peut-être même avant.
*BSD, à ses origines, embarquait (je crois) son propre compilo C. Par la suite gcc a pris le dessus.

Juste pour compléter ton propos, on peut encore (sur)vivre avec le C de MS*. Par contre le C++, c'est une merde infame ! C'est simple, il y a deux C++ sur le marché. Celui de MS pour sa plateforme Windows et le "Standard" que tous les autres essayent de suivre.

(*) Au passage, compiler avec GCC via Mingw32 si possible, il trouve plein de bug potentiel que MSVC ne trouvera jamais. http://www.bloodshed.net/dev/devcpp.html(...) est très bien. Dommage qu'au boulot on doit encore ce farcir MSVC :( .

Tu parles de la portabilité du C. Je suis surpris par cette remarque. Je travailles avec différents compilo C et gcc est loin, très loin, d'être un problème. C'est le plus agréable des compilo C car sur le C Ansi/ISO il n'y a pratiquement pas de de bug. Les bugs des compilo sont le problème de la portabilité du C, pas les extensions.

Quant aux extensions du C ajoutées sur gcc, c'est assez courant de les retrouver sur d'autres compilo. Elle sont nécessaire pour faire de la programmation système. Avec quelques macros, on peut s'en sortir pour masquer les extensions. C'est vraiment pas la mer à boire.

Si je comprends bien l'intérêt du format,c'est de pouvoir composer des images avec une grande précision. Puis lors des ajustements de contraste, de luminosité, etc ... on a pas les artefactes du à la basse précision.

Toutefois pour exploiter de tel images, il faut avoir les moyens d'en générer. Si je peux facilement imager que c'est faisable avec des outils de synthèse diverse dont le ray-tracing, existent-ils des appareils de numérisation grand public qui peuvent offrir une telle qualité ?

Je me rectifie pour le son.
Je crois que c'est supporté en natif par linux car c'est compatible AC'97. C'est suffisant pour écouter du MP3 et regarder des vidéos en DivX.

Rapidement et de tête sur la version 'vanilla' des kernels:
- Le coeur du chipset nForce(2) est supporté par le branche 2.4
- pour le son je ne sais plus mais je ne crois pas.
- le SATA ne l'est pas à ma connaissance. Il devrait l'être dans le 2.6 mais de gros problêmes d'accès aux specs existent. Je connais pas la position de NVidia la dessus.
- 10/100 LAN est supporté. Pour le giga-ethernet (pas le gigabyte), je sais pas, mais je pense que cela devrait.
- carte tuner TV. Le bt878 est bien supporté. Je comprends pas ce qu'est le timeshifting. Mais c'est vrai que si la carte à des chips supplémentaires exotiques, il vaut mieux éviter de l'acheter.

Il fait savoir aussi que NVidia fourni ses propres drivers pour Linux. Dans ce cas toutes les fonctionnalités de la cartes sont supportés sauf les trucs très avancés comme le son qui a un support minimal.

Les programmeurs de chez Microsoft ne savent ils pas coder de facon portable ? Je pencherai plutôt pour un problème de culture du groupe. La culture d'entreprise est connue pour être très forte chez MS et je pense que la section Mac doit surement faire bande à part.