TImaniac a écrit 6420 commentaires

L'écrasante majorité des licences Windows vendues, le sont par des revendeurs/intégrateurs, qui ont tout loisir d'installer Firefox et de le mettre comme navigateur par défaut.
Ce sont des choix politiques des revendeurs, et non des choix techniques.

En revanche pourquoi ne peut on pas *vraiment* désinstaller IE [1] ?
Quel est l'intérêt pour l'utilisateur ?
L'OS a besoin d'une stack HTTP, par exemple pour Windows Update. Ils pourraient faire autrement, c'est sûr, mais c'est comme ca.
La majorité des distributions Linux ont besoin d'une stack TCP/IP pour faire fonctionner leurs gestionnaires de packages, pourtant ils pourraient faire autrement, pourquoi on ne vire pas la stack TCP/IP du kernel ?

L'option "Set Program Access and Defaults" est une vaste blague : pourquoi choisir alors qu'il serait si simple de désinstaller les logiciels Microsoft que je n'utilise pas ?
En quoi est-ce plus simple pour l'utilisateur ?

Si j'étais à leur place, dans un objectif mercantile, je ferais certainement de même, mais il faut assumer et comprendre les plaintes des utilisateurs et de l'Union Européenne.
Les plaintes ne viennent généralement pas des consommateurs, mais des concurrents.

Pour la pile TCP/IP bien sûr que si. Ne serait-ce que parce que le matériel en face ne parle que comme ça (routeurs, etc).
L'OS n'est pas censé offrir des moyens d'accéder aux routeurs & co qui sont des périphériques externes.
L'OS est juste censé proposé un moyen d'accéder à la carte réseau.
D'ailleur pourquoi TCP/IP ? pourquoi pas un autre niveau des couches de protocole comme Ethernet ou HTTP ?
D'ailleurs les OS arrivaient très bien à se passer de pile TCP/IP avant que ces protocoles existent, et pourtant il existait déjà des cartes réseaux.

Sans shell, l'utilisateur (pas le programmeur hein !) n'a aucun moyen d'accéder à son périphérique-disque dur.
Un shell est une interface utilisateur comme une autre. Tu peux très bien utiliser Windows (un OS donc) sans shell, avec une autre interface utilisateur. Que l'interface soit graphique ou texte n'y change rien, les rôles de ces interfaces sont identiques et y'en a pas une qui est plus censé faire parti de l'OS que l'autre.

La pile TCP/IP n'est pas nécessaire pour discuter avec la carte réseau.
Le "shell" n'est pas nécessaire pour discuter avec les périphériques de la machine.

Le point commun de ces logiciels, c'est qu'ils ne mettent pas en avant un format proprio de chez Microsoft
Wordpad permet de lire des fichiers dans un format proprio
L'explorateur de fichier permet d'accéder à des systèmes de fichier proprio
Le diaporama de photo permet d'accéder à des formats d'images proprio
IE se veut feature-complete.
L'explorateur Windows se veut feature-complete
Le gestionnaire de photo de Windows se veut feature-complete
Le solitaire se veut feature-complete

Pour avoir uniquement le nom du fichier et non son chemin complet :
from file in new DirectoryInfo(@"/etc").GetFiles() select file.Name;

Moi je propose qu'on intente un procès à Microsoft pour qu'ils suppriment de Windows :
Wordpad
Notepad
Valc
Paint
Magnétophone
Solitaire
Et puis tiens aussi l'explorateur de fichier
Le gestionnaire des fichiers zip
Le diaporama de photo
Le défragmenteur
C'est vrai quoi, tout ces logiciels ont des alternatives et leur présence par défaut dans Windows tue la concurrence !

Oué le problème, c'est le C++.
Si tu veux vraiment faire ca, le plus simple est de faire une lib qui exporte une API en C (tu peux wrapper du C++ si tu veux).
Après une fois que t'as fais ca, tu peux facilement utiliser des méthodes C en C# de manière portable.
En gros tu t'arranges pour compiler ton code C/C++ dans une lib dynamique, .so sous linux et .dll sous Windows.
Après tu lis ca :
http://www.mono-project.com/Interop_with_Native_Libraries

Pas besoin de recompiler ton code C# d'une plateforme à l'autre, une modif dans le fichier de conf et tu utilises le .so sous linux et le .dll sous Windows.

Oué j'ai oublié de citer cet avantage également, la compilation AOT sert aussi à déployer sur des plateformes comme l'iPhone, qui ont une protection interdisant l'utilisation de compilateur JIT.

Je connais pas de bouquin sur GTK# et la doc officielle est vraiment light.
A vrai dire, le plus simple est généralement de se référer à la doc de GTK+.

Tu peux donner un exemple de méthode dans les API Windows ou .NET qui a ce défault (par curiosité) ?

Après si tu veux vraiment comparer, faudrait tester avec un helloworld en java pour voir le temps effectif de démarrage de la jvm sans tenir compte du temps d'exécution du programme.

Tu vas rire, on a inventer les méta-données pour ca : offrir un moyen de stocker des informations sur le contenu lui-même, sans altérer ce dernier.
Après si t'aime pas les méta-données et l'utilisation qui en est faite, rien ne t'empêche d'utiliser des formats sans méta-données. (genre des fichiers textes et des fichiers RAW).

Je ne connais aucune application qui supporte intégralement le format ODF.
A ma connaissance le format ODF est suffisament "ouvert" pour qu'aucune application puisse supporter l'intégralité des utilisations qui puisse en être faite. (exemple : aucune contrainte sur les types d'image qui peuvent être embarqués)
Je ne connais aucune certification SO/IEC 26300:2006 qui garantie que telle ou telle implémentation permette de lire tous les documents ODF.
Je ne connais aucune suite de tests de référence pour une tester une implémentation ODF.
Comme tu le vois, je ne connais pas grand chose, donc si t'as des informations :)

Ils font aussi des logiciels libres :
WiX (CPL)
ASP.NET Ajax Control Toolkit (Ms-PL)
DLR (Ms-PL)
IronPython (Ms-PL)
IronRuby (Ms-PL)

Moué enfin le support il est dans wordpad. J'ai pas de windows7 pour tester, mais si le support de l'ODF est le même que le support des .doc dans WindowsXP, c'est vraiment très très limité.
Quelqu'un a testé ?

les libs toussa, c'est une problématique qui n'est pas propre à mono ou java, n'importe quel soft qui utilise des libs externes doit les lire et les charger en mémoire.
Ce qu'il faut retenir, c'est que mon exemple t'as clairement montré que le temps de chargement du runtime est négligeable (j'ai refait le test après avoir redémarrer ma machine), et c'est bien le principal.

Grande différence. La première fois je n'avais encore jamais lancé java sur cette machine. La deuxième fois si.
Oué mais la différence, c'est pas le temps de démarrage de la jvm, c'est juste que lors de la première exécution, la jvm a trouvé des optimisations judicieuses qui ont été "enregistrées" et utilisées lors du 2ème démarrage.
Ca vient du mode de fonctionnement de java qui fonctionne initialement comme un interpreteur puis compile les méthodes qui sont souvent utilisées.

Mono marche pas pareil. le bytecode exécuté est conçu dès le départ pour être compilé et exécuté en code natif (contrairement au bytecode java initialement prévu pour être interprété). Cela dit on retrouve un problème similaire : au début de l'exécution du programme, il faut compiler le code avant de l'exécuter, et ca prend plus de temps qu'après. Mais ca n'a rien à voir avec le temps de chargement du runtime en mémoire en soit. Ce problème peut être contourner en "précompilant" l'application en code natif sur la machine cible, l'application démarrera alors plus vite (même au démarrage de ta machine). Imagine si j'avais utilisé cette possibilité pour mon hello world ;)

N'as tu jamais démarré mono (pour une raison X ou Y) sur ta machine avant de faire ce test (et sans utiliser preload hein...) ?
C'est pas la question. Que j'ai exécuté mono avant n'y change rien. Idem pour java : avoir exécuté java avant ne change rien.
Ce qui change en java, c'est quand t'as déjà exécuté le même programme avant. Bref, rien à voir avec le temps de démarrage de la jvm en soit. C'est uniquement lié au contexte de ton programme.

Après, un "environnement d'exécution", pour moi ça veut tout et rien dire.
Ben c'est pourtant ca le terme exacte. C'est un runtime, mono, qui s'exécute dans un process, et qui s'arrange pour exécuter ton bytecode, tout comme ton process python exécute ton script, etc.

qui se démerdera pour lire tous les fichiers et foutre tout ton "environnement d'éxécution" en RAM.
Oué bah oué, tu sais, même C++ a un "runtime", php aussi, python aussi, à part le C...
Dès que le langage de programmation se base sur la présence de services (garbage collector, type check, introspection, etc.), il faut un runtime capable de charger ces services additionnels.

Le vrai process qui se lancera sera "mono"
Tu peux compiler ton programme pour qu'il inclu le runtime, et tu le verras pas, et ton programme n'aura à aucun moment le nom "mono".

Ah si si, une machine virtuelle se démarre ! C'est un process comme les autres.
C'est pas la machine virtuelle qui démarre, c'est l'environnement d'exécution qui démarre.

Après peut-être que Mono est mieux foutu de se côté là, mais franchement je pense que ton exemple à été pris "à chaud", avec un mono déjà démarré.
je pensais que ca se voyait, je démarrer mono dans ce test, il n'était pas démarré avant donc.
Mono n'est pas un process qui tourne en tache de fond et qui attend d'exécuter des programmes. C'est pas une VM, c'est un environnement d'exécution qui est démarré à la demande pour exécuter tel ou tel programme, de la même manière que t'appelle perl ou python pour exécuter ton script.
Bref, comme tu peux le constater, le temps de démarrage de l'environnement d'exécution pour un pauvre hello world, c'est peanuts.

Pour Java, y'a des raisons historiques qui font que la première exécution d'une application est plus "lente", mais c'est pas pour autant qu'il y a un process qui tourne en tâche de fond sur ta machine en attente d'une application Java !

Dis donc, c'est très intéressant de mettre en évidence une incohérence sur le fond si t'en a rien à péter du fond.

Windows XP 64 bits détecte très bien 8 Go de RAM.

$ time ./mono.exe test.exe
Hello, world !

real 0m0.140s
user 0m0.015s
sys 0m0.000s

C'est évidemment le temps d'exécution total, t'en déduis ce que tu veux sur le temps de "chargement".

Un machine virtuelle ne se démarrer pas. une machine virtuelle c'est un concept "virtuel", qui n'a pas d'existence réelle par nature.
Le temps de chargement du runtime Mono est ridicule, tu t'en apercevra jamais.
Après une appli Mono peut être plus lente (à démarrer mais pas seulement) qu'une appli C++ évidemment, mais c'est pas lié au temps de démarrage du runtime Mono.

my only friend
the end.

Néanmoins l'appoche de python semble avoir été faite dans un soucis de gain de perfs si j'en crois ce qui a été écrit ailleurs dans cette discussion.
Nan de simplicité : faciliter l'utilisation de lib C sans se poser de question quand aux accès concurrent.
Du coup ils se retrouvent face à un piège : s'ils veulent ajouter le support de la concurrence sans casser l'existant, il sont obligé de mettre des locks partout par défaut (là où normalement le programmeur choisi intelligement où il faut les mettre);.. et c'est globalement 2 fois plus lent lors des tests qu'ils ont fait. Conclusion le choix de départ les conduits aujourd'hui dans une impasse : l'intérêt d'avoir plusieurs threads s'exécutant en parallèle devient de plus en plus intéressant (les machines neuves sont toutes multi-core) mais ils ne peuvent pas y passer sans casser la sémantique ou alors une lourde refonte de l'interpréteur avec un impact désastreux sur les perfs...