Qui définissent tous une VM :) C'est parcqu'il y a production direct de code machine qu'il n'y a pas de VM. Une VM est une abstraction par nature virtuelle, in fine c'est toujours du code machine qui s'exécute.
C'est faux et archi faux. Tu as tous les LISP, tous les *ML, Scade sont compilé et n'ont pas de VM et te garantisse que jamais un pointeur ira se balader n'importe où. C'est le compilo qui fait ça.
Je te dirais même que cette propriété à la con, est une pure expérience du C.
Les risques juridiques sont bien évidemment réels, mais nous savons que ces risques existent également pour tout un tas de logiciels libres autres que Mono.
Tu dois avoir des infos que je n'ai pas. Ou alors, tu fais références aux problèmes globals des brevets logiciels.
Mais il faut être gonfler pour mettre ce risque sur le même plan que le risque juridique anti-FLOSS venant de MS.
"pourquoi utiliser une techno Microsoft alors que nous avons les notres, dans le libre ?" etc.
Quand C# est sorti, c'était vraiment je refais un Java purement MS...
Sinon, comme je l'ai dis plus bas : disons bye bye à XMLHttpRequest. Non ?
ben non, c'est standardisé aujourd'hui. Ce n'est pas un produit, c'est juste une spécification qui supporté par tout le monde (interopérable).
Les langages qui font ca sont obligés d'insérer des métadonnées dans l'exécutable, bref de définir un modèle d'information de plus haut niveau, une VM.
Le C définit depuis toujours des symbole pour le link, le link dynamique, et le debug. Cela n'a rien à voir avec une VM qui traduit du bytes code !
Comme si le mot clé protected t'offrais une quelconque sécurité. Tu prends un pointeur et tu vas te balader n'importe où dans ton objet, le mot clé n'est qu'une vision du compilateur, à l'exécution il n'y a aucun contrôle.
Utilise 2 processus, c'est fait pour. En plus aujourd'hui, il y a mini 2 coeurs à disposition.
ADA propose au sein de son langage une abstraction des threads, il défini une VM.
n'importe quoi. C'est pas parce que l'on te trouve plein de contre exemple qu'il tout appelé VM ! Ada comme toutes les langages t'offre une abstraction statique, qui est traduit par le compilateur. Une VM le fera en plus à la volé.
La question est de savoir si le langage s'appui directement sur les instructions machines où s'il forme un sur-ensemble constituant une machine virtuelle et permettant de partir du postulat que des services supplémentaires sont offerts.
C'est évident et Ada pond du code machine ! (essaye gnat)
Le bytecode .NET ou Java défini une VM avec la notion de classe, de méthode, de paramètres, d'héritage, de types énumérés, etc.
Quand tu décompiles, tu retrouves tout ça, optimisation ou pas.
si c'est vrai cela veut dire que le compilo qui génère du bytecode n'optimise rien, ce qui serait surprenant.
Non, c'est "by design" qu'une VM comme Java ou .NET empêche celà.
C'est "by design" que du code natif laisse faire tout et n'importe quoi.
C'est pas pour rien qu'un OS est obligé pour contourner le problème de s'appuyer sur les rings matériels offerts par le processeur pour cloisonner les processus et donc gérer les droits utilisateurs.
L'OS ne contourne ne rien du tout. Il utilise une protection hardware parfaitement et totalement étanche : la gestion de la mémoire virtuelle. Quand une VM fait cela, elle s'expose à un bug, tu peux aussi exposer des bugs sur le hardware mais c'est plus rare... (et beaucoup plus facile à vérifier).
C'est la différence entre une garantie donné par une barrière comme le hardware, et une "gestion" qui est _censé_ être bien faite.
Un des buts d'une VM est d'abstraire le code machine qui n'offre de base aucune sécurité, pour justement proposer un modèle de machine (VM) entièrement contrôlable par l'environnement d'exécution. Bref, by design encore une fois, une VM est conçu pour avoir une maîtrise complète du code exécuté.
Un OS n'a que vaguement la main à travers les appels systèmes et s'appui sur le hardware in fine.
Ce que tu décris, cela s'appelle de la gestion de processus, c'est la raison première de l'existence des OS. Pourquoi encore rajouter une couche ?!
En quoi cela demande une VM ? GTK en fournis il me semble ?
- sandboxing C'est pas simple à faire dans le même process, mais avec 2 process, cela commence à être plus simple.
- gestion des exceptions (le C++ doit intégrer un morceau de runtime pour ca) Oui et alors ? C++ ne tourne pas sur une VM et dispose de la gestion d'exception en quoi faut-il une VM pour ça ?
- protection contre les débordements (on parle de garantie, une lib n'offre pas de garantie) C c'est vrai, c'est faux en ocaml, en lustre, et tout les langages formels. On peut aussi parler des langages de scripts mais certain fonctionnent avec une VM, il pourrait faire sans.
- gestion mémoire (on parle de garantie, pas de l'utilisation parfaite et sans erreur d'une lib) idem, tu penses au C,C++.
- déployer une applet web (recompiler dans le navigateur n'est pas une option). comme le javascript ?
- proposer pleins de langages interopérables Dans une certaine limite, je crois qu'il avait essayé de faire tourner du Fortran dans .NET et ils ont vite laisser tomber. Sinon, les autres langages passe par les API C, mais c'est vrai que c'est lourd.
Non, juste que le langage C n'offre aucune garantie de comportement d'une implémentation à l'autre.
Il ne faut pas exagérer non plus. Le C est proche du cpu mais tout de même.
Sans parler du fait que tu es obligé d'avoir 2 binaires (voir n si tu as n architecture).
Exacte mais est-ce tellement génant ?
Y'a des techniques pour limiter la casse au niveau OS (comme c'est le cas dans le dernier noyau linux), mais il n'y a aucune garantie offerte.
Il y a aussi des techniques de compilation pour protéger les débordements de buffer. Mais il faut voir que ce n'est qu'une partie du problème, et que cela ne couvre rien des problèmes de haut niveau comme les "SQL injection", le X-site-scritping, et autre.
Une VM garantie tous les accès mémoires, garantie qu'il y a bien un objet au bout et que tu es bien autorisé à y accéder.
Sauf que tu compares C et une VM, cette propriété existe aussi dans d'autre langage compilé comme ocaml, haskel et autre. Enfin, tout les langage formels quoi :)
Mais elles garantissent surtout, et contrairement au C, que la mémoire utilisée puis devenue inutile puisse être libérée ou réutilisée avant la fin du programme.
ça c'est la théorie.
En pratique, des bouts de mémoire peuvent y échapper selon le type d'algo utilisé (cf la discussion sur le sujet dans la news sur le nouveau langage).
Une des VM les plus utilisé, arrête le code en cas de pénurie de mémoire, et fait une recopie total de la mémoire utilisée puis libère la 1er partie, cela double les besoin mémoires, et cela freeze le code pour un temps certain si il y a beaucoup de mémoire !
Prends 2 personnes au hasard avec de l'informatique dans le CV, quel est la probabilité que la personne ingénieur (ou ayant un DESS) en informatique fasse plus l'affaire qu'une autre personne sans diplome ?
Ce que tu poses comme problème idéologique est en fait un problème de risques juridiques. Je ne sais pas si le "risque" s'étudie en philo, mais c'est un concept très courant en économie.
Ici, on parle du risque juridique que représente l'entité Microsoft sur les développements lié à Mono et l'environnement C#, .NET.
Cela a dérapé sur des concepts techniques comme la quasi inutilité des VM (sauf si on ne peut pas utiliser 2 process pour intégrer des plugin par exemple ou la portabilité de binaire). Mais cela n'est pas le sujet de base.
Le texte de RMS et de la FSF est de dire que MS fait peser un risque juridique beaucoup trop grand sur les développements mono.
Qu'est-ce qui fait dire ça ?
* Les menaces répétés mais jamais démontré de violation de brevet par Linux
* Le raid sur TomTom avec le brevet sur la Fat
* L'accord avec Novell également sur les brevets pour gagner de l'argent sur le dos du libre
* La "promesse" toute récente qui a été faite mais dont on est loin d'être sûr de savoir que Mono est couvert.
Il y a aussi le passif
* "Linux est un cancer"
* Les documents halloween
* La succession des procès anti-trust perdu
* Le combat pour rendre le serveur samba incompatible avec leur OS
* La corruption des instances de l'iso avec l'inscription de tout plein de nouveau pays votant comme par hasard toujours dans le sens de MS.
Bref, le passif est lourd. Google fait peur par sa taille, pose des problèmes sur la respect de la vie privé mais n'a pas cet énorme passif sur la communauté FLOSS.
Alors là, je m'insurge contre ton commentaire complètement déplacé. C'est une attaque ad hominem, sans aucun rapport, et qui en plus sous entends qu'un type qui a fait des études littéraires serait nécessairement moins compétent que toi dans tout les domaines.
Tu n'as rien compris à mon message. Pour être plus claire, je ne cherche pas à lui expliquer de la philo, et lui essaye de m'expliquer des choses en me prenant de haut, alors que j'ai fait beaucoup d'étude dans le domaine (et je passe les années d'expérience). Et c'est lui qui as parler de ses études.
Ce n'est pas du tout une question de gueguerre débile ("Cela sert à quoi les études littéraires ?"), mais d'essayer de faire croire que l'on maitrise son sujet.
Elle est très précise justement. Tu as un code exécutable et distribuable. Ce n'est pas un cache, c'est les instructions effectivement exécutées par le cpu.
Pourquoi tu poses cette question ? C'est pour faire plus gros, plus sale , moins propre, plus effrayant et incompréhensible que les versions proposées avant ?
[^] # Re: Pourquoi Mono ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 3.
Mais pas les API (.NET ASP ?) qui sont elle breveté et ne font pas partie de la "promesse" de MS.
Donc, non ce n'est pas pareil.
"La première sécurité est la liberté"
[^] # Re: Pourquoi Mono ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Drôle
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Pourquoi Mono ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
En quoi gérer des processus seraient moins bien ? (comme Chrome en fait ?)
"La première sécurité est la liberté"
[^] # Re: Pourquoi Mono ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Bientot, C avec ses info de debug va être qualifier de tourner en VM :)
"La première sécurité est la liberté"
[^] # Re: Pourquoi Mono ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Euh... il faut bien lui dire si tu veux compiler pour x86 ou x86-64...
Pourquoi quand je change d'option mon sizeof me rend pas la même chose ? 4 et 8 dans l'autre ?
Pour mettre sizeof() et non 4, dans ton code.
"La première sécurité est la liberté"
[^] # Re: Pourquoi Mono ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 3.
C'est faux et archi faux. Tu as tous les LISP, tous les *ML, Scade sont compilé et n'ont pas de VM et te garantisse que jamais un pointeur ira se balader n'importe où. C'est le compilo qui fait ça.
Je te dirais même que cette propriété à la con, est une pure expérience du C.
"La première sécurité est la liberté"
[^] # Re: Pourquoi Mono ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Pourquoi Mono ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
oui mais aujourd'hui, il y a valgrind, et cela change tout.
Surtout qu'il arrive parfois qu'on ne sache pas quand exactement libérer la ressource, sauf à compter les références manuellement.
C'est souvent le problème d'une mauvaise encapsulation, non ?
"La première sécurité est la liberté"
[^] # Re: Pourquoi Mono ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Tu dois avoir des infos que je n'ai pas. Ou alors, tu fais références aux problèmes globals des brevets logiciels.
Mais il faut être gonfler pour mettre ce risque sur le même plan que le risque juridique anti-FLOSS venant de MS.
"pourquoi utiliser une techno Microsoft alors que nous avons les notres, dans le libre ?" etc.
Quand C# est sorti, c'était vraiment je refais un Java purement MS...
Sinon, comme je l'ai dis plus bas : disons bye bye à XMLHttpRequest. Non ?
ben non, c'est standardisé aujourd'hui. Ce n'est pas un produit, c'est juste une spécification qui supporté par tout le monde (interopérable).
"La première sécurité est la liberté"
[^] # Re: Pourquoi Mono ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 3.
Le C définit depuis toujours des symbole pour le link, le link dynamique, et le debug. Cela n'a rien à voir avec une VM qui traduit du bytes code !
Comme si le mot clé protected t'offrais une quelconque sécurité. Tu prends un pointeur et tu vas te balader n'importe où dans ton objet, le mot clé n'est qu'une vision du compilateur, à l'exécution il n'y a aucun contrôle.
Utilise 2 processus, c'est fait pour. En plus aujourd'hui, il y a mini 2 coeurs à disposition.
ADA propose au sein de son langage une abstraction des threads, il défini une VM.
n'importe quoi. C'est pas parce que l'on te trouve plein de contre exemple qu'il tout appelé VM ! Ada comme toutes les langages t'offre une abstraction statique, qui est traduit par le compilateur. Une VM le fera en plus à la volé.
La question est de savoir si le langage s'appui directement sur les instructions machines où s'il forme un sur-ensemble constituant une machine virtuelle et permettant de partir du postulat que des services supplémentaires sont offerts.
C'est évident et Ada pond du code machine ! (essaye gnat)
Le bytecode .NET ou Java défini une VM avec la notion de classe, de méthode, de paramètres, d'héritage, de types énumérés, etc.
Quand tu décompiles, tu retrouves tout ça, optimisation ou pas.
si c'est vrai cela veut dire que le compilo qui génère du bytecode n'optimise rien, ce qui serait surprenant.
"La première sécurité est la liberté"
[^] # Re: Pourquoi Mono ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 3.
C'est "by design" que du code natif laisse faire tout et n'importe quoi.
C'est pas pour rien qu'un OS est obligé pour contourner le problème de s'appuyer sur les rings matériels offerts par le processeur pour cloisonner les processus et donc gérer les droits utilisateurs.
L'OS ne contourne ne rien du tout. Il utilise une protection hardware parfaitement et totalement étanche : la gestion de la mémoire virtuelle. Quand une VM fait cela, elle s'expose à un bug, tu peux aussi exposer des bugs sur le hardware mais c'est plus rare... (et beaucoup plus facile à vérifier).
C'est la différence entre une garantie donné par une barrière comme le hardware, et une "gestion" qui est _censé_ être bien faite.
Un des buts d'une VM est d'abstraire le code machine qui n'offre de base aucune sécurité, pour justement proposer un modèle de machine (VM) entièrement contrôlable par l'environnement d'exécution. Bref, by design encore une fois, une VM est conçu pour avoir une maîtrise complète du code exécuté.
Un OS n'a que vaguement la main à travers les appels systèmes et s'appui sur le hardware in fine.
Ce que tu décris, cela s'appelle de la gestion de processus, c'est la raison première de l'existence des OS. Pourquoi encore rajouter une couche ?!
"La première sécurité est la liberté"
[^] # Re: Pourquoi Mono ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Pourquoi Mono ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
- introspection
En quoi cela demande une VM ? GTK en fournis il me semble ?
- sandboxing C'est pas simple à faire dans le même process, mais avec 2 process, cela commence à être plus simple.
- gestion des exceptions (le C++ doit intégrer un morceau de runtime pour ca) Oui et alors ? C++ ne tourne pas sur une VM et dispose de la gestion d'exception en quoi faut-il une VM pour ça ?
- protection contre les débordements (on parle de garantie, une lib n'offre pas de garantie) C c'est vrai, c'est faux en ocaml, en lustre, et tout les langages formels. On peut aussi parler des langages de scripts mais certain fonctionnent avec une VM, il pourrait faire sans.
- gestion mémoire (on parle de garantie, pas de l'utilisation parfaite et sans erreur d'une lib) idem, tu penses au C,C++.
- déployer une applet web (recompiler dans le navigateur n'est pas une option). comme le javascript ?
- proposer pleins de langages interopérables Dans une certaine limite, je crois qu'il avait essayé de faire tourner du Fortran dans .NET et ils ont vite laisser tomber. Sinon, les autres langages passe par les API C, mais c'est vrai que c'est lourd.
"La première sécurité est la liberté"
[^] # Re: Pourquoi Mono ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Non mais en pratique, c'est le cas.
Non, juste que le langage C n'offre aucune garantie de comportement d'une implémentation à l'autre.
Il ne faut pas exagérer non plus. Le C est proche du cpu mais tout de même.
Sans parler du fait que tu es obligé d'avoir 2 binaires (voir n si tu as n architecture).
Exacte mais est-ce tellement génant ?
Y'a des techniques pour limiter la casse au niveau OS (comme c'est le cas dans le dernier noyau linux), mais il n'y a aucune garantie offerte.
Il y a aussi des techniques de compilation pour protéger les débordements de buffer. Mais il faut voir que ce n'est qu'une partie du problème, et que cela ne couvre rien des problèmes de haut niveau comme les "SQL injection", le X-site-scritping, et autre.
Une VM garantie tous les accès mémoires, garantie qu'il y a bien un objet au bout et que tu es bien autorisé à y accéder.
Sauf que tu compares C et une VM, cette propriété existe aussi dans d'autre langage compilé comme ocaml, haskel et autre. Enfin, tout les langage formels quoi :)
"La première sécurité est la liberté"
[^] # Re: Pourquoi Mono ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
ça c'est la théorie.
En pratique, des bouts de mémoire peuvent y échapper selon le type d'algo utilisé (cf la discussion sur le sujet dans la news sur le nouveau langage).
Une des VM les plus utilisé, arrête le code en cas de pénurie de mémoire, et fait une recopie total de la mémoire utilisée puis libère la 1er partie, cela double les besoin mémoires, et cela freeze le code pour un temps certain si il y a beaucoup de mémoire !
"La première sécurité est la liberté"
[^] # Re: Pourquoi Mono ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: Pourquoi Mono ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: Pourquoi Mono ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Ici, on parle du risque juridique que représente l'entité Microsoft sur les développements lié à Mono et l'environnement C#, .NET.
Cela a dérapé sur des concepts techniques comme la quasi inutilité des VM (sauf si on ne peut pas utiliser 2 process pour intégrer des plugin par exemple ou la portabilité de binaire). Mais cela n'est pas le sujet de base.
Le texte de RMS et de la FSF est de dire que MS fait peser un risque juridique beaucoup trop grand sur les développements mono.
Qu'est-ce qui fait dire ça ?
* Les menaces répétés mais jamais démontré de violation de brevet par Linux
* Le raid sur TomTom avec le brevet sur la Fat
* L'accord avec Novell également sur les brevets pour gagner de l'argent sur le dos du libre
* La "promesse" toute récente qui a été faite mais dont on est loin d'être sûr de savoir que Mono est couvert.
Il y a aussi le passif
* "Linux est un cancer"
* Les documents halloween
* La succession des procès anti-trust perdu
* Le combat pour rendre le serveur samba incompatible avec leur OS
* La corruption des instances de l'iso avec l'inscription de tout plein de nouveau pays votant comme par hasard toujours dans le sens de MS.
Bref, le passif est lourd. Google fait peur par sa taille, pose des problèmes sur la respect de la vie privé mais n'a pas cet énorme passif sur la communauté FLOSS.
"La première sécurité est la liberté"
[^] # Re: Pourquoi Mono ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 1.
Tu n'as rien compris à mon message. Pour être plus claire, je ne cherche pas à lui expliquer de la philo, et lui essaye de m'expliquer des choses en me prenant de haut, alors que j'ai fait beaucoup d'étude dans le domaine (et je passe les années d'expérience). Et c'est lui qui as parler de ses études.
Ce n'est pas du tout une question de gueguerre débile ("Cela sert à quoi les études littéraires ?"), mais d'essayer de faire croire que l'on maitrise son sujet.
"La première sécurité est la liberté"
[^] # Re: Pourquoi Mono ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: Un autre bonne raison de ne pas utiliser Mono
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 1.
Je ne vois pas d'autres explications.
"La première sécurité est la liberté"
[^] # Re: Pourquoi Mono ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Franchement, les arguments du style "tu fais pire que moi", à part ridiculiser leur auteur, je ne vois pas leur utilité.
"La première sécurité est la liberté"
[^] # Re: Pourquoi Mono ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Pourquoi Mono ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 0.
"La première sécurité est la liberté"