sepas a écrit :



Un système de fichiers gérant les liens????

 Donc, une appli tourne, tu updates le fichier et tu espère que ça va continuer de tourner correctement?       


 Dans ce que tu dis, ça suppose donc que ton fichier est en mémoire, le nouveau ne sera pas utilisé tant que tu ne l'as pas relancé, donc pas trop d'intérêt.       


 Et imagine que ce ne soit pas le seul fichier de l'application qui soit modifié...un ancien executable veut aller chercher une bibliothèque qui a été updaté aussi. Tu fais comment?

Non, le fichier n’a pas à être en mémoire, les deux versions coexistent sur le disque. Et, oui, ça tourne correctement, pourquoi pas ? En revanche ta dernière remarque est juste mais il suffit que chaque application signale ses dépendances dans son manifeste, voire qu’elle chargent tout au début. Et puisque de plus en plus d’OS interdisent le chargement dynamique afin de forcer une stricte séparation des pages de données et de code avec contrôle matériel…

 





charon.G a écrit :



Cette technique ne résoud rien si on doit mettre à jour des bibliothèques systèmes utilisées par la quasi totalité des applications. Dans ce cas sous Linux aucun processus n’est en réalité mis à jour avant de rebooter.  



Je dirais plutôt que cette technique ne résout rien si tu dois mettre à jour des biblios utilisées par des composants qui ne se ferment jamais.  Mais en réalité ça résout quand même pas mal de choses, le disque est simplement un peu alourdi jusqu’au prochain reboot, le risque est surtout que ces applis ne soient pas rebootées avant longtemps et conservent leurs failles de sécurité. Mais là aussi on peut imaginer des palliatifs, comme un avertissement donné à l’utilisateur, une date limite avant reboot ou des MAJ marquées “critiques”.

@PCI

Je hais vraiment votre nouveau système d’édition. " />

* Impossible de scinder une quote.

* Impossible de rajouter une ligne non-citation après une citation si jamais on a bouffé la ligne ajoutée par défaut.

* Pas de mode preview pour faire ça à la main (et je ne me rappelle jamais votre format pour désigner le message cité)

* Sélection-suppression hasardeuse des lignes.

* Insertion inutile d’espaces à certains débuts de ligne.

* Autres comportement erratiques dont les règles exactes de reproduction m’échappent. 



Comme 99.99% des éditeurs wysiwyg JS il est désagréable et erratique. Je ne vous blâme pas d’échouer là où tous les autres échouent et je comprends l’intérêt pour les profanes mais si éventuellement vous pouviez proposer une option pour avoir le vieil éditeur ou au mois une version simplifiée…

 

charon.G a écrit :



C’est ce que j’expliquais si tu tentes de mettre à jour la libc par exemple. Elle ne sera jamais déchargé. On est obligé de redémarrer. Et en réalité ça ne résoud rien puisque les applications restent avec la mauvaise version en mémoire ,donc rien n’est mis à jour. Entre le reboot et ce cas c’est la même chose…. 



Considère un serveur web sur ce genre de systèmes : tu crées ton serveur Apache en te basant sur des processus légers recyclés toutes les 30 minutes et voilà. La vulnérabilité sera rapidement éliminée sans avoir nécessité de reboot du système et d’indisponibilité.



C’est avant tout orienté vers les serveurs à haute disponibilité où parfois une machine n’est pas redémarrée pendant plusieurs années. Tout comme on a des architectures logicielles (plugins how swap), matérielles (PCI hot swap) ou des langages (erlang) conçus pour permettre un remplacement à chaud on a des systèmes d’exploitation qui le permettent.







charon.G a écrit :



Ce qui serait une

solution c’est un OS où tu bloques le chargement dynamique de code et tu

 charges  les bibliothèques dans des SIP (software isolated process)

séparées. Du coup tu es capable d’arrêter , mettre à jour et redémarrer

une bibliothèque sans devoir fermer toutes les applications qui les

utilisent.



Mais là ce serait beaucoup plus radical comme design et tu créerais un problème beaucoup plus gros : la communication inter-processus est bien plus fastidieuse et tu dois te coltiner des problèmes de compatibilité des API plus neuves ou anciennes à tous les étages. Qui plus est, non, tu n’élimines pas le problème puisque l’exécutable lui-même ne peut pas être mis à jour ainsi.







sepas a écrit :



De plus en plus, il y a des interactions entre les applis.

Comment fais-tu pour les applications à multiples instances comme un browser par exemple. Tu aurais un browser d’une version et un autre d’une autre version lancée sur la même machine?



Oui, tu aurais certaines pages utilisant une ancienne version et d’autres utilisant la nouvelle. Ca demanderait un peu de gymnastique au niveau de la communication inter-processus pour faire face à des API trop vieilles ou trop récentes mais la communication IPC est assez rare et ça n’aurait rien d’extraordinaire pour des applications conçues pour ce genre d’environnement. Au pire le dév peut s’en tirer avec un message d’erreur disant qu’il faut redémarrer l’application.



Mais encore une fois ce genre de choses est avant tout conçu pour le serveur, voire ci-dessus.









sepas a écrit :



Et si un fichier de conf est utilisé par plusieurs applis, chacun utilise le fichier mais dans une version différente?



Non, les écritures ne sont pas versionnées par défaut. Le système le permet mais ne l’impose pas. Tout comme sous Windows tu peux mettre à jour un fichier en demandant à ce que le changement ne soit effectif qu’au prochain redémarrage.

charon.G a écrit :



Pour chrome OS t’es mignon mais j’ai trouvé une étude sur d’amérique du nord . Chrome os c’est 0,2% du trafic web ,c’est pire que Linux.





0,2% du trafic desktop. Aucun PC desktop n’était encore vendu avec ChromeOS à ma connaissance.

 



Pour les BSOD tu n’as apparemment pas compris mon message. Si windows 10 intègre les technos Midori tu n’auras plus de BSOD sur ce système provoqué par des erreurs logicielles.



99% des ordinateurs n’en ont plus depuis des années et pourtant tu penses que l’avantage sera significatif au point d’inverser les tendances du marché ?





Sans compter que le système de SIP n’est pas étendu aux driver mais à tout type d’extension. Fini par exemple les shell extension qui font planter l’explorateur. Quand l’extension ou le driver plantera , la cause sera très facilement repérérable. J’ai moi -même codé un analyseur de fichiers dumps kernel.  Ca ne marche pas toujours car les drivers partagent le même espace mémoire avec le noyau.



Encore une fois tout ça est assez anecdotique et la contrepartie sera une plus grande difficulté du développement des communications inter-processus et un coût en performances. Je pense que ça va malgré ça dans le bon sens mais ce ne sera pas un avantage commercial.





Pour la sécurité en effet ça se jouera surtout sur les serveurs. Mais ça tombe bien Windows 10 devrait sortir en version serveur. de plus Midori a été vraiment pensé pour les appareils connectés. C’est évident que la sécurité est importante pour ces appareils qui rentrent complètement dans notre vie.



Encore une fois je ne pense pas que la sécurité est un avantage commercial significatif sauf sur serveurs. Et sur serveurs la sécurité est déjà établie par des solutions de virtualisation, Midori apportera simplement un gain sur les perfs via une solution plus rapide. Ceci est (enfin) un avantage commercial significatif mais c’est un critère parmi d’autres.





Ce qui me gène dans ton raisonnement c’est que google sont des dieux et quoi que Microsoft fasse ils ne réussiront pas.



Windows est semble impossible à sauver du fait de l’écosystème android, de l’interchangeabilité des OS avec la domination des technos web, de la pression vers l’ouverture des sources et les standards, surtout depuis Snowden. L’avenir de MS est sur le service (y compris SOA, nuage, etc), pas sur Windows. L’OS de demain s’appellera Chrome ou Firefox et Windows sera un produit open source populaire ou une solution closed source pour les dinosaures avec des besoins de maintenance, ou une techno exclusive au nuage de MS.



Et, oui, tout ça est encore loin d’être complet, nombre de ces tendances sont encore immatures et bien des problèmes restent à résoudre. Mais c’est toutefois inévitable.



Ces tendances ne me plaisent pas. Mais on n’y peut rien.

charon.G a écrit :



Si tu regardes les papiers sur Singularity. Microsoft le dit clairement le mécanisme inter-processus est beaucoup plus rapide qu’un système classique(déjà débattu la dessus et tu sais pourquoi). La creation d’un SIP est aussi très peu couteux en performance(ca se rapproche d’un thread). Si ce n’était pas le cas ils n’auraient jamais pu l’utiliser pour des drivers. 



Quand je dis que la communication IPC est fastidieuse je ne parle pas de performances : le partage de zone mémoire est interdit (sauf exception via buffer dédié) et tout doit être copié, les échanges possibles doivent être spécifiés de façon statique sous forme d’un automate à états finis pour que le système puisse prouver qu’il n’y aura pas de deadlock, etc. C’est beaucoup plus fastidieux pour le programmeur que de simplement appeler une fonction d’une DLL, c’est le coût de la sécurité. Ce qui est acceptable parce que la communication IPC est rare.







charon.G a écrit :



Pour communiquer avec un dll(une extension) tu utilises un système de channels spécifiés par un contrat

 en Sing#.

Non, les canaux servent à la communication interprocessus, pas aux appels de méthodes dans d’autres DLL au sein d’un même processus. Heureusement ! Sauf si tu décides explicitement d’enfermer une DLL dans un processus isolé.



EDIT : pour clarifier, je parle du format dll, du cooncept de bibliothèques je ne fais pas référence au chargement dynamique dont j’ai moi-même dit quelques messages plus haut qu’il serait interdit.

arno53 a écrit :



Dans les paramètres de NXI –> Options d’affichage –> Editeur BB Code





Hourra ! Mille mercis à toi ! " />







charon.G a écrit :



Sauf que dans ce cas les assembly sont compilés dans le même SIP lors de la phase de l’installation ou embarqué dans l’application. Ma théorie du départ reste valable.





Ta théorie de départ n’était-elle pas justement qu’il faudrait isoler chaque DLL dans un SIP afin de les mettre à jour indépendamment ? Ce dont j’ai justement expliqué que ce serait tout sauf anodin ?

charon.G a écrit :



Sauf que les sip communiquent qu’avec d autres sip. Tu peux avoir des dll dans un meme sip mais ils sont locaux au sip. Donc si tu mets á jour un sip tu peux facilement redémarrer le sip avec ses assemblies liés.il n y a plus de dynamic load library externe partagé





D’accord je vois ce que tu veux dire : parce que les processus légers sont isolés les uns des autres ils peuvent de facto détenir des versions différentes des binaires (pas stricto sensu puisque ces biblios ont été agrégées mais peu importe). Ok.



Cela dit ce n’est pas ce que tu expliquais initialement et tu en reviens finalement au même point qu’avec un système de fichiers versionné : la version existe tant qu’on n’a pas redémarré le processus. C’était le problème qui te dérangeait au départ et qui doit être accepté pour moi sachant qu’on dispose de moyens de le contourner ou amenuiser.







Strimy a écrit :



Ca revient un peu au même principe que les AppDomain de .Net non ? Les assemblies sont chargées dans un domaine, et pour mettre à jour, on décharge le domaine pour le recharger avec les nouvelles versions des assemblies (comme le fait IIS).





C’est exactement la même chose mais je l’expliquerais autrement : la différence entre un thread et un processus c’est que les processes sont isolés les uns des autres (une appli ne peut pas écrire dans la mémoire du noyau).



Traditionnellement cette isolation est avant tout accomplie par des moyens matériels, au niveau de la gestion de la mémoire virtuelle par le CPU.



Mais avec un langage comme dotnet (en excluant le code unsafe et compagnie) on peut prouver qu’aucune de leurs opérations ne causera une rupture de l’isolation (sauf faille du runtime). Dès lors on peut retirer les protections matérielles et avoir une isolation gratuite en termes de performances. C’est cette logique, l’isolation logicielle, qui est commune aux domaines d’applications et aux SIP (software isolated processes).



Cela étant MS maintiendra apparemment une protection matérielle simplifiée en plus des protections logicielles, sans doute pour éviter que des failles ne puissent être déplacées vers le matériel. Je me demande s’ils conservent tout de même le gain de performances dont ils se vantaient.

charon.G a écrit :



Si microsoft corrige un bug dans un dll système comme kernel32.dll,il va être obligé de fermer toutes les applications qui l’utilisent donc de rebooter car impossible. Sur Singularity 99% du temps ils ne toucheront pas à l’assembly wrappé mais juste au code à l’intérieur du SIP système. Du coup ils ont juste à redémarrer le SIP système incriminé et ils ne touchent pas aux applications.





D’accord puisque kernel32.dll ne sera qu’une couche mince faisant l’interface avec le processus sous-jacent où résidera la faille. Cela ça ne concernera que les fonctions systèmes isolées dans un processus à part mais c’est non-négligeable, surtout dans le contexte des MAJ de windows.







charon.G a écrit :



Sinon Microsoft travaille aussi sur ce sujet avec DrawBridge:



Serialization and deserialization of running processes offer end users new functionality even if applications are never migrated to a new machine. For example, instead of closing applications for an OS reboot, the applications could be serialized to persistent storage and then restored after the reboot.



source





Bonne nouvelle, ça fait longtemps que j’attends une transformation du cycle de vie des applis avec une fusion de la RAM et du stockage.