BorisSchapira.com

Inquirer sont les champions toutes catégories de la mauvaise foi en ce qui concerne Widows Vista. Il y avait d’autres articles exclusivement basé sur l’envie de pourrir windows sans arguments ni faits. J’émets des gros doute sur leurs infos maintenant.

“De toute façon l’informatique ça marche jamais, et Windows ça marche jamais !”

Valve est couillon : au lieu de monter leurs applis sur des libs bidons, ils feraient mieux d’utiliser OpenGL et SDL, Quake le fait, Unreal le fait, ils ne sont pas moins doués a priori. Si ça leur coûte max de frics, ils n’auront qu’à réfléchir avant d’agir la prochaine fois.

Le coup du lock de fichier, c’est pitoyable :). Je crois que c’est le seul système au monde qui ait ce problème, et comme tu dois t’en doûter, j’en connais une tripotée (dont 99% des ingés informatiques n’ont même pas entendu parler…). C’est juste que chez ‘crosoft, on sait toujours pas implémenter correctement de la prise de ressource.

à ce soir ! ;) (pas pu aller au geek machin-chose d’hier, dont je trouve l’appelation un peu buzzy — sacré FdM ! –, parce que des vrais geeks pure souche, ça m’étonnerait qu’il y en ait eu beaucoup, tout simplement pour cause de concert ayant terminé assez tard… Dommage, je mets facilement la révolution )

A quoi bon passez à Windows Vista quand on sait que ce n’est qu’une transition vers Windows 7 ? :cry:

Oui et pourquoi passer à WIndows 7 d’ailleurs, qui sera peut-être lui aussi une simple transition ? EN raisonnant comme ça on n’avance pas beaucoup.

non car vista n’apporte rien par rapport à xp, à voir avec la suite …

Ah ah, si je dis “VxWorks” ou “Nucleus”, aucune application professionnelle ? Le problème est typiquement celui de la gestion de la prise de ressource : il est impossible d’ouvrir plusieurs fois en écriture un fichier sous windaube (et en lecture aussi me semble-t-il bien), et la gestion des file descriptor est très mauvaise, puisque le système ne repasse pas derrière la fin d’un programme pour tout bien désallouer. Leur problème est très concrètement celui d’un système coopératif, où c’est le programme userpace qui détermine s’il fout ou non en l’air le système… Sous Linux, on peut supprimer un fichier en cours de lecture, et le récupérer tant que toutes les applis l’ayant ouvert n’aient pas fait de close dessus ; il suffit de prendre le PID de l’appli, de regarder dans /proc//fd/ là où ça pointe vers le fichier (pourtant supprimé), et tout simplement le dumper avec un cat. C’est actuellement la gestion la plus puissante qui soit sur tous les systèmes (y compris propriétaires qui valent des zillons de dollars ; non, c’est pas windaube, même pas CE ).

Notons tout de même que l’accès en concurrence en écriture sur un fichier n’est pas déterminé (selon POSIX ou les standard UNIX, d’ailleurs ? C’est dans tous les cas un problème à la conception du kernel, surtout en multitasking, puisqu’un vrai write bien implémenté est préemptible) ; à éviter donc (mais à ne pas empêcher ! Et encore moins pour les lectures multiples en RO, gérer plusieurs seek à la fois n’est pas sorcier quand même !). Il suffit juste au final de gérer des listes chaînées, avec redondances des stockages (dans des structures) pour optimiser les accès aux informations. Le kernel Linux en est rempli (et le BSD très certainement aussi), visible dans /proc notamment. Chez m$, il semble que la solution de facilité consistant à mettre une sorte de lock/mutex sur la prise de ressource ait été choisi (le premier qui prend a gagné, penser à tout nettoyer à la fin, et en cas de plantage, bah… heu….) ; clair que ça prend deux secondes à coder, et vive ensuite les problèmes de fichiers non destructibles, y compris (ça c’est le plus drôle) après reboot (ce n’est donc pas stocké en mémoire vive à tous les coups… mais où alors ?! C’est ce qu’ont dû découvrir les gars qui ont pondu le “Unlocker”, très certainement à coups de débugger sur le système, avant d’aller jardiner en mémoire à cet endroit-là…).

Sinon, pour OpenGL, beuh, c’est pas nouveau, inventé par SGI y’a un bout de temps déjà, c’est l’implémentation des derniers standards dans les puces/drivers pour une accélération de ouf qui est à la bourre, mais ça n’empêche pas Quake et Unreal de très bien tourner quand même ; et si plus de dév abandonnaient les systèmes troués pour les standards propres, ça irait bien mieux…

Dommage pour Paris-Carnet (tiens, y’avait pas Fred non plus, ça crève tant que ça cette techno-fashion ? ^^ J’essaierai d’être de la prochaine, si je suis libre…), rdv pour la prochaine édition alors !

@ palpatine : “il est impossible d’ouvrir plusieurs fois en écriture un fichier sous windaube (et en lecture aussi me semble-t-il bien)” si si c’est possible, au moins pour la lecture !

Si j’essaie avec deux wordpad sur un fichier, ça passe. Si je fais un coup de word, c’est le drame : impossible de supprimer, impossible d’éditer avec un autre programme (et de beaux messages d’erreurs très explicites sur le sujet, le summum du user-friendlyness ). Deux hypothèses : wordpad met tout en buffer et close le fichier (ce qui semble bien être le cas si l’on considère qu’ouvrir un fichier énorme charge tout bien dans la mémoire d’un seul coup, le travail s’effectuant donc sur un buffer entier, ce qui est logique aussi mais pas très optimisé), soit word (et bien d’autres) font un appel de lock du fichier, mais je ne suis pas programmeur windaube (anciennement oui), je n’en ai jamais entendu parler, et je voudrais bien voir la tête du truc (un appel à l’API de win, retranscrit dans la base de registres ? Les idées les plus folles sont possibles ^^).

Il se pourrait que deux appels RO passe, mais deux RW soient interdit. Il faudrait compiler une appli de test pour ça, je ne vois pas quel programme pourrait bien m’ouvrir un fichier connu en RO seulement :/ (et pis je teste ça sous un citrix très minimaliste, faut dire). Quelqu’un se dévoue pour rétro-ingénieurer ?

Laisse tomber ! Je partageais des fichiers avec un vieux serveur Novell. Depuis que j’ai mis un nouveau serveur Windows c’est la cata !