Articles précédents : Sécurité
- [0] Appel à communication SSTIC 06
- [30] Anonymat avec des Logiciels Libres
- [19] Début du support de la sécurité pour Debian testing
- [194] Comment des vendeurs essaient de breveter les solutions à des failles de sécurité qui leur sont fournies
- [0] La troisième édition du concours de sécurité informatique « Challenge SecuriTech » se déroulera du 11 juin au 1er juillet 2005.
- [23] Faille de sécurité dans les protocoles IPSec
- [11] Le projet PaX compromis
- [47] Nouvelle faille dans les noyaux 2.4 et 2.6
- [99] Deux failles de sécurité pour les noyaux Linux 2.4.x et 2.6.x
- [28] Mise à jour critique pour Firefox 1.0PR
Liens connexes
- talweg, le site (2099 hits)
- Mono (698 hits)
- log4net (337 hits)
- DLFP : talweg, solution de portail captif (684 hits)
Dépêche modérée par
Dépêche éditée par
L'utilisation de ce framework .NET sous Linux le rend désormais compatible avec Apache 1 et 2. Son installation est plus facile, Mono fourni l'ensemble des outils nécessaires à son fonctionnement, de la classe d'accès Http à la gestion des certificats X.509. Seuls les logs s'appuient sur un composant externe : Log4Net, une bibliothèque maintenue par la Fondation Apache, qui permet un grand nombre de scénarios.
Ce développement a permis à l'équipe talweg, en collaboration avec Gonzalo Paniagua Javier le créateur et mainteneur de mod_mono, de contribuer au projet Mono, mais aussi de constater la facilité de maintenance offerte par le couple C#/Mono. Du point de vue technique, beaucoup d'améliorations ont été apportées. Les outils proposés par le framework ont permis d'intégrer le proxy, un meilleur choix dans la réécriture de l'adresse a permis l'utilisation d'un seul certificat SSL de type wildcard.
Le principe premier de talweg : la garantie de l'identité des personnes utilisant le réseau en évitant les mécanismes d'usurpation, est bien sur conservé. Ce principe a une incidence très intéressante : il est possible de communiquer sur Msn Webmessenger ou de lire ses messages sur Gmail à travers un canal chiffré.
Pour tous ceux qui souhaiteraient tester en quelques minutes cette solution, un live CD existe.
![[fr]](../../../images/fr.png)
talweg, le site (2099 hits)![[en]](../../../images/en.png)
Mono (698 hits)-
log4net (337 hits)
-
DLFP : talweg, solution de portail captif (684 hits)
> Lire les commentaires (68 commentaires, moyenne: 3,5).
C# et le libre...
Ca me fait toujours bizare quand je vois parler de Mono... Ok, c'est libre, et il semble que ce soit vraiment bien. Mais est-ce qu'il n'aide pas à promouvoir C# et donc les solutions propriétaires Micro$oft?
Ca rajoute une corde à leur arc: "Vous pouvez même faire tourner ca sous linux si par hasard vous migrez vers cette plateforme... Donc évitez de le faire en Java, en PHP ou en je ne sais quoi... Et continuez a faire du 100% Micro$soft..."
Je ne sais pas trop quoi en penser. Pas pour, pas contre, juste besoin d'avoir un peu l'avis de tout le monde pour essayer de comprendre un peu mieux comment appréhender ce genre de solution...
JMS
-
[^]Re: C# et le libre...
Posté par phentex () le 21/01/2006 à 03:56. (lien). Évalué à 8.Je partage ton avis.
Sans être pour ni contre, j'avoue que le "cas Mono" me laisse un quelque peu perplexe, une impression de cul entre deux chaises...
Actuellement en auto-formation C# pour un projet scolaire, je ne suis pas en mesure de disserter sur le sujet. Je serais curieux de connaître les diverses réactions...
J'avoue que se former à C#/Mono sous Ubuntu en feuilletant les pages de spec MSDN aux couleurs MS est une expérience plutôt inabituelle :)--
ggggnnnnnnnnnnnnnnnnn (interprétation libre)
-
[^]Re: C# et le libre...
Posté par Franck () le 21/01/2006 à 04:18. (lien). Évalué à 4.C# en tant que langage est standardisé.
Par ailleurs, .NET existe et c'est en fait. Son succès est assuré que Mono existe, ou non. Tu n'as qu'à lire la presse dite "professionnelle" pour t'en convaincre. Tant qu'à faire, ne vaut-il pas mieux suivre le train et porter certaines parties du framework sous Linux ?
Enfin, je pense que Java et C# (je parle des langages) ont tout à fait leur place pour réaliser des applications clientes sous Linux. Quand on pense qu'une tripotée d'applis Gnome est encore écrite en C (souvent bien, mais ce n'est pas le problème), un langage moderne ou deux en plus n'est pas un luxe. Et puis ça fait une alternative à Python.
Il semblerait que côté Gnome, C# ait largement pris le pas sur Java. Probablement en raison des freins à la distrib de la VM Java. Dommage, Java est arrivé bien avant, et j'ai tendance à privilégier ceux qui innovent (même si l'orientation objet de Java est discutable, tout ça...).-
[^]Re: C# et le libre...
Posté par Elephant (page perso, ) le 21/01/2006 à 09:52. (lien). Évalué à 8..Net est standard. Ok
Maintenant je reste marqué par une conférence Microsoft à Lille en juin 2005 où le conférencier expliquait que ok, c'était standard et donc portable sur d'autres OS, mais que Microsoft ne réfléchissait et ne réfléchirait pas le développement de .Net pour autre chose que ses produits.
Dans le fond, c'est de bonne guerre. Mais le passage au .Net 2.0 (vers octobre-novembre chépu) en nouveau standard a causé quelques changements et effectivement on sent qu'ils ne pensent pas aux autres.
Le but actuel de MS étant de pouvoir tout faire en .Net, sans exeption (le détail que j'ai noté, l'appartion d'une classe pour gérer le port série qui n'existait pas en 1.0)
.Net (ne confondons pas avec c#, on peut imaginer tous les langages en .Net) n'est qu'un clone de Java datant d'une époque où Microsoft et Sun étaient en concurrence. Il y a quelques légères différences, mais les deux ont le même esprit. Et dans cette optique Java présente beaucoup beaucoup plus de possibilités du à son ancieneté.
Il fallait vraiment des soucis avec les machines virtuelles java pour qu'on tourne autant sur .Net.
J'ai beau très bien connaître le .Net (12h de .Net par semaine, ça aide), je ne suis pas franchement convaincu de son intérêt pour le monde du Libre.-
[^]Re: C# et le libre...
Posté par louis perrier () le 21/01/2006 à 10:12. (lien). Évalué à 3.Je ne pense pas que le format de fichier word soit mieux que l'odt, mais openoffice le supporte. quand on est minoritaire c'est une approche obligatoire.
majoritaire => je verouille le marché.
minoritaire => je suis compatible avec le majoritaire.
De plus .Net est une techno interessante vu de loin (je ne pratique pas), ce serait bête de s'en privé.
C'est un débat creux, comme :
- faut il porter KDE sous windows,
- les outils linux doivent ils être présent sous windows et "enrichir" ce système.
Je pense que si l'ont s'interesse à linux, ce n'est pas pour utiliser les même méthodes que microsoft, au contraire. Et je suis persuadé que c'est payant.-
[^]Re: C# et le libre...
Posté par Elephant (page perso, ) le 21/01/2006 à 12:14. (lien). Évalué à 6.De plus .Net est une techno interessante vu de loin (je ne pratique pas), ce serait bête de s'en privé.
Autant que le Java en fait.
Une fois perdu l'intérêt de l'environnement visual Studio .Net, c'est vraiment, à mes yeux, à égalité avec le Java, quelques milliers de librairies d'importance secondaire en moins.
Microsoft fait quelques avancées pour transformer l'affrontement avec le Libre en une sorte de "coexistence pacifique". C'est le discours tenu par les conférenciers Microsofts que j'ai pu rencontrer.
Je reste quand même dubitatif et j'attends de voir comment les choses évoluent.-
[^]Re: C# et le libre...
Posté par Philippe Fremy (page perso, ) le 23/01/2006 à 08:54. (lien). Évalué à 4.Je ne connais pas les coulisses de java et .NET mais a lire pas mal d'articles sur le sujet, il semble que .NET ait une architecture de meilleure qualite que java et permette de faire des choses que java ne fait pas.
Le seul exemple que je connaisse avec precision, c'est python. Jython, l'implementation de python en java est deux fois plus lente que l'implementation de reference. Ironpython, l'implementation au dessus du CLR (la VM de .NET) est plus rapide que l'implementation de reference.-
[^]Re: C# et le libre...
Posté par Boa Treize (page perso, ) le 24/01/2006 à 06:12. (lien). Évalué à 8.Le fait que qu'au moins une personne travaille a plein temps sur IronPython alors que Jython n'a pratiquement pas évolué en cinq ans y est peut-être aussi pour quelque chose...
-
[^]Re: C# et le libre...
Posté par _flo_ () le 28/01/2006 à 17:52. (lien). Évalué à 1.Et bien sun n'avait qu'a embaucher la personne s'occupant de jython. C'est ce qui s'est passé pour ironpython, ce n'etait pas un projet microsoft au depart...
Par contre je ne connais pas bien les subtilités de leur licence "shared source" sous laquelle il est diffusé. On a le droit de regarder mais pas de modifier, c'est ça?
-
-
-
-
-
[^]Re: C# et le libre...
Posté par Vador Dark (Jabber id, ) le 21/01/2006 à 13:23. (lien). Évalué à 6.Tiens bas, puisqu'on distingue bien les VM des langages, une chose me vient à l'esprit.
Y a-t-il une grosse différence entre une JVM, et une VM ".Net"?
Dans ce cas, ne peut-on pas imaginer bien séparer les VMs des langages? (je veux dire, plus que simplement dans le discours). Ainsi, on aurai deux "architectures" de VM(JVM, et VM .Net, sans compter les autres), et des compilos. On peut déjà balancer du Python sur une JVM, ou sur du .Net, du Java sur du .Net, et il n'est pas impossible qu'on ait un jour du C# sur les JVM.
-
[^]Re: C# et le libre...
Posté par boubou (page perso, ) le 21/01/2006 à 13:34. (lien). Évalué à 10.Pfiou, ça en fait des idées reçues dans un même post...
Alors dans l'ordre :
.Net est standard. Ok
C'est faux (ce n'est pas de toi, mais bon). Une petite partie de .NET est standardisée. Ce qui en plus ne veut pas dire qu'on peut l'implémenter librement (cf le mp3). Pour des détails : http://apiacoa.org/publications/vulgarisation.html#lm-java-d(...)
Mais le passage au .Net 2.0 (vers octobre-novembre chépu) en nouveau standard a causé quelques changements et effectivement on sent qu'ils ne pensent pas aux autres.
C'est sûr que comme le standard évolue par l'intermédiaire de l'ECMA et que la commission contient des gens comme Novell, MS fait ce qu'il veut et ne pense pas aux autres...
.Net (ne confondons pas avec c#, on peut imaginer tous les langages en .Net) n'est qu'un clone de Java datant d'une époque où Microsoft et Sun étaient en concurrence.
Quel raccourci saisissant et faux... Le mieux je pense est l'auto-contradiction. .NET a été pensé pour faire du multi-langage, ce qui est une différence fondamentale avec la JVM de Sun. Les mécanismes d'interfaçage de bas niveau sont fondamentalement différent entre .NET et la JVM, ce qui permet à .NET de récupérer des bibliothèques existantes beaucoup plus facilement. Les opérations prévues dans la VM de .NET sont assez différentes de celles de la JVM, elles ne sont pas prévues pour être interprétables facilement, par exemple (il faut donc un compilateur JIT pour avoir de bonnes performances). .NET possède des modes de passage de paramètres beaucoup plus riche que ceux de la JVM, ce qui facilite l'implémentation de langages comme le Pascal, par exemple, etc. Ces différences sont fondamentales et dire que .NET est un clone de Java, c'est exactement comme dire que Java est un clone de C++, c'est un raccourci totatement faux. Sans compter ce qui est prévu pour les versions suivantes de .NET, avec une forte inspiration fonctionnelle dans C#.
Il y a quelques légères différences, mais les deux ont le même esprit.
Oui, c'est le même esprit : machine virtuelle + langage orienté objet avec garbage collecting. Mais les différences sont énormes quand on y prète attention et surtout les langages phares (C# et Java) évoluent dans des directions assez différentes.
Et dans cette optique Java présente beaucoup beaucoup plus de possibilités du à son ancieneté.
Mouais, ça dépend pour quoi et sur quelle plateforme.
Il fallait vraiment des soucis avec les machines virtuelles java pour qu'on tourne autant sur .Net.
La différence fondamentale, c'est que Mono est soutenu par Novell alors que Classpath est un travail de bénévoles, avec un peu de soutien de RedHat. Mais bon, vu le succès énorme de choses comme JBoss, je pense que Java n'a pas de soucis à se faire à court terme, d'autant que Classpath sera très bientôt compatible à 100% avec java 1.4 (on peut quand même faire tourner azureus et eclipse avec classpath, par exemple). Classpath couvre actuellement 98% de l'api 1.4 (cf http://www.kaffe.org/%7Estuart/japi/htmlout/h-jdk14-classpat(...) ).
J'ai beau très bien connaître le .Net (12h de .Net par semaine, ça aide),
Encore du boulot...-
[^]Re: C# et le libre...
Posté par Croconux () le 21/01/2006 à 19:47. (lien). Évalué à 10..NET a été pensé pour faire du multi-langage, ce qui est une différence fondamentale avec la JVM de Sun.
Mouais, le multi langage c'est quand même une grosse blague. Ok, on peut utiliser d'autres langages que C# sur .NET mais à condition de revoir complètement son code. C'est surtout un argument commercial pour inciter les boites qui ont des softs écrits dans d'autres langages à switcher. Au final 80% des dévelopeurs .NET codent en C#, les 20% restant sont des dévelopeurs VB qui ont migré. Les autres langages sont négligeables. Quel est l'intérêt de faire du Python en .NET par exemple ? Les perfs ? Oups, pas vraiment. Le framework ? Ah, oui, il faut tout recoder parce qu'on peut utiliser les classes du framework .NET mais pas celles du framework Python. On peut coder avec les syntaxe Python des programmes Python qui ne tourneront que sur .NET. Un peu strange, non ?
Les mécanismes d'interfaçage de bas niveau sont fondamentalement différent entre .NET et la JVM, ce qui permet à .NET de récupérer des bibliothèques existantes beaucoup plus facilement.
Ca permet de s'interfacer avec des bibliothèques natives donc adieu la portabilité, mais ça c'est un peu le but de Microsoft. Une bonne partie du framework ne fait que fournir un wrapper autour des libs de Windows. Il est possible de réimplémenter à partir de rien l'équalent dans Mono mais qui peut garantir que le comportement sera rigoureusement identique ? D'autant que seule une petite partie de framework est standardisée. .NET a surtout été pensé pour offrir un gain de productivité aux dévelopeurs Windows. Ca ne va pas plus loin.-
[^]Re: C# et le libre...
Posté par Boa Treize (page perso, ) le 21/01/2006 à 20:13. (lien). Évalué à 5.Pour Python, c'est un peu particulier, tout comme Jython d'ailleurs. Le but n'est pas de porter ses programmes mais de scripter rapidement des classes existantes. Dans les deux cas c'est super agréable.
Mais effectivement, pour les autres langages, c'est plus du pipo mercatique qu'une réelle solution : les langages sont adaptés à la sauce .Net, il faut donc par exemple porter son appli COBOL vers COBOL.Net.
Je ne crois pas que beaucoup de boîtes s'amusent à ça. Soit elles réécrivent l'existant en C#, soit elles font une surcouche C# et conservent leur coeur de métier en COBOL.-
[^]Re: C# et le libre...
Posté par golum () le 23/01/2006 à 10:56. (lien). Évalué à 4.Puisqu'on est en plein débat|troll multilangage sur CLR/ Python
01 net vient de publier un article à ce propos
http://www.01net.com/article/302185.html
-
-
[^]Re: C# et le libre...
Posté par TImaniac (page perso, ) le 22/01/2006 à 11:10. (lien). Évalué à 7.Ok, on peut utiliser d'autres langages que C# sur .NET mais à condition de revoir complètement son code.
Ca dépend pour migrer quoi. Si c'est pour migrer la partie métier d'une plate-forme, celle-ci utilise très peu de bibliothèques externes, il y a donc très peu d'effort à faire et de réécriture. C'est même d'ailleur tout l'intérêt.
Au final 80% des dévelopeurs .NET codent en C#, les 20% restant sont des dévelopeurs VB qui ont migré. Les autres langages sont négligeables.
Des sources ! Des sources !
Une étude a sorti ces statistiques :
http://www.forrester.com/Research/Document/Excerpt/0,7211,37(...)
"However, of those who report using .NET as a platform, about 42% are not currently using VB.NET or C#"
Donc y'a quand même 42% de projets (dans cette étude) qui utilise un autre langage .NET. Donc c'est que du pipo marketing le "multi-langage". D'ailleur l'étude ne montre pas le pourcentage relatif entre C# et VB.NET, mais s'ils les ont mis ensemble ca doit avoir un rapport.
D'ailleur on se demande pourquoi y'a autant de job proposé en C# que VB.NET
http://www.dedasys.com/articles/language_popularity.html
D'ailleur on se demande pourquoi Borland vend Delphi .NET si c'est purement marketing sans aucun retour financier.
http://www.borland.com/us/products/delphi/index.html
D'ailleur on se demande pourquoi Fujitsu vend NetCobol pour .NET si c'est purement marketing. Juste pour le fun sans doute... D'ailleur des petites PME comme l'Euronext ont migré sur .NET grâce à ca, mais c'est purement marketing, ca sert à rien le multi-langage.
http://www.netcobol.com/
Dans ma boîte on utilise autant le C# que le C++ managed, parcque le 2ème permet de faire des choses que le premier ne permet pas. (Wrapper des classes C++ natives). Mais c'est purement marketing le multi-langage, ca sert à rien.
Ca permet de s'interfacer avec des bibliothèques natives donc adieu la portabilité
Pourquoi ce raisonnement falacieux ? Si les bibliothèques natives sont portables, il n'y a aucun problème. cf GTK. Et .NET offre même un mécanisme d'appel de code natif qui est justement portable. JNI n'est pas portable par exemple, il faut recompiler.
.NET a surtout été pensé pour offrir un gain de productivité aux dévelopeurs Windows.
Et Mono tente d'apporter les mêmes gains aux développeurs Linux et MacOSX.
Ca ne va pas plus loin.
D'où l'intérêt de Mono.-
[^]Re: C# et le libre...
Posté par boubou (page perso, ) le 22/01/2006 à 15:40. (lien). Évalué à 3.Pourquoi ce raisonnement falacieux ? Si les bibliothèques natives sont portables, il n'y a aucun problème. cf GTK. Et .NET offre même un mécanisme d'appel de code natif qui est justement portable. JNI n'est pas portable par exemple, il faut recompiler.
??? En quoi JNI n'est pas portable, c'est justement fait pour ? Et en quoi la recompilation pose un problème de portabilité ? L'avantage de .NET sur JNI c'est que la VM de .NET est plus souple que la JVM et peut donc s'interfacer plus simplement avec des bibliothèques natives. Avec JNI, on a une grosse couche d'interfaçage lourdingue, en tout cas plus lourde que celle de .NET. C'est un gros avantage, mais ce n'est pas une raison pour raconter n'importe quoi.-
[^]Re: C# et le libre...
Posté par TImaniac (page perso, ) le 22/01/2006 à 17:00. (lien). Évalué à 2.Et en quoi la recompilation pose un problème de portabilité ?
Effectivement ca n'empêche pas la portabilité en général, autant pour moi. Ca empêche la portabilité binaire chère à Java.
-
-
[^]Re: C# et le libre...
Posté par Croconux () le 22/01/2006 à 18:30. (lien). Évalué à 3.Des sources ! Des sources !
Expérience personnelle. Au boulot j'utilise .Net depuis près de 2 ans, j'ai eu l'occasion de participer à diverses conférences et d'échanger avec des utilisateurs de .Net dans d'autres boites j'avoue avoir croisé très peu de personnes ne codant ni en C# ni en VB : Des gens de la DGA et de l'Inria essentiellment. Il s'agissait de projet de recherche "en l'air" qui n'ont pas vocation être passé en production. Pour ce qui est des boites qui ont pour impératif de sortir quelque chose qui marche dans un délai raisonable, je n'en ai vu aucun. Beaucoup de boites recompilent leur ancien code pour .Net mais tous les nouveaux développements se font en C#. D'où l'existence de Cobol.net, etc.
C'est la même chose chez nous : On a pas mal de code en Delphi qu'on envisageait de passer en .Net mais il va rester en natif pendant encore un bon moment, le temps que Borland sorte une version un peu moins buguée. Quand on a testé c'était totalement inutilisable. Déjà les vieilles versions sont assez fabuleuses (compilation en boucle, "erreur interne Exxx" de façon aléatoire, crashes de l'IDE, ...) mais là c'était vraiment la totale. Le commercial de chez Borland était un peu emmerdé pour nous démontrer les qualités de son produit...
-
-
[^]Re: C# et le libre...
Posté par boubou (page perso, ) le 22/01/2006 à 15:37. (lien). Évalué à 2.Je te parle de technique, pas de l'utilisation de cette technique. Le fait que la VM de .NET soit pensée pour le multi-langage est une différence fondamentale avec la JVM, même si cette fonctionnalité est peu utilisée.
A part ça, Timaniac a très bien répondu sur la portabilité : depuis quand une bibliothèque native n'est pas portable ?
-
-
[^]Re: C# et le libre...
Posté par TImaniac (page perso, ) le 22/01/2006 à 11:17. (lien). Évalué à 1.Ce qui en plus ne veut pas dire qu'on peut l'implémenter librement (cf le mp3)
C'est faux. Jusqu'à preuve du contraire Microsoft ne détient aucun brevet sur .NET. (sinon pointe moi la page officielle du brevet(s)). Et jusqu'à preuve du contraire, la plupart des logiciels libres violent également potentiellement un ou plusieurs brevets logiciels. Le problème c'est les brevets logiciels en général.
la commission contient des gens comme Novell, MS fait ce qu'il veut et ne pense pas aux autres...
C'est vrai que les autre participants comme Intel et HP sont des gros noobs. D'ailleur le premier n'y connaît strictement rien en langage et compilation.-
[^]Re: C# et le libre...
Posté par boubou (page perso, ) le 22/01/2006 à 15:35. (lien). Évalué à 7.Ce qui en plus ne veut pas dire qu'on peut l'implémenter librement (cf le mp3)
C'est faux.
Tu as quelques problèmes de lecture, comme toujours quand il s'agit de .NET. Je me contente ici de rappeler que standard ne veut pas dire librement implémentable, ce qui est vrai, car il existe des standards comme mp3 qu'on ne peut pas implémenter librement dans certains pays.
Jusqu'à preuve du contraire Microsoft ne détient aucun brevet sur .NET.
Le brevet sur une grande partie de l'API de .NET est en cours d'étude par le bureau des brevets américains. Pour l'instant, le brevet est rejeté, de façon non définitive. Ce qui est amusant, c'est que d'après l'expert du bureau qui a examiné la demande, celle-ci est entres autres non valide car elle prétend breveter des choses qui le sont déjà (cf http://portal.uspto.gov/external/portal/pair et saisir le numéro de demande 10/087027). Donc, une partie de l'API de .NET est couverte par des brevets (qui ne semblent pas appartenir à Microsoft). Donc tu as raison et ça ne prouve pas que .NET peut être implémenté librement...
Et jusqu'à preuve du contraire, la plupart des logiciels libres violent également potentiellement un ou plusieurs brevets logiciels.
Oui, oui, et potentiellement, par effet tunel, ton cul peut traverser ta chaise. Timaniac, tu ne sais vraiment pas argumenter. Ce n'est pas parce que quelque chose est pourri que ça justifie d'utiliser autre chose qui est tout aussi pourri...
Le problème c'est les brevets logiciels en général.
Ba oui, et ça s'applique donc à .NET.
C'est vrai que les autre participants comme Intel et HP sont des gros noobs. D'ailleur le premier n'y connaît strictement rien en langage et compilation.
Mon pauvre, dans ton évangelisme forcené tu ne comprends même pas l'ironie. Je suis tout à fait d'accord avec toi, MS ne contrôle pas complètement l'évolution de .NET, en tout cas pas la partie standardisée.-
[^]Re: C# et le libre...
Posté par TImaniac (page perso, ) le 22/01/2006 à 17:15. (lien). Évalué à 4.car il existe des standards comme mp3 qu'on ne peut pas implémenter librement dans certains pays.
Moi je traduis juste tes sous-entendus : quand tu parles du problème du mp3, c'est parcqu'une société a des brevets logiciels sur des algo liés au format mp3, et qu'elle peut donc vendre des licences d'utilisations, et de ce fait empêche une implémentation "libre". D'une manière générale, rien n'empêche une implémentation libre de standard, sauf en cas de brevets logiciels.
Donc tu as raison et ça ne prouve pas que .NET peut être implémenté librement...
Pas plus que le HTML peut être implémenté librement, pas plus que le standard XY peut être implémenté librement, etc. On est bien d'accord : les brevets logiciels ca pu, ca met en danger tous les logiciels libres.
Oui, oui, et potentiellement, par effet tunel, ton cul peut traverser ta chaise. Timaniac, tu ne sais vraiment pas argumenter. Ce n'est pas parce que quelque chose est pourri que ça justifie d'utiliser autre chose qui est tout aussi pourri...
Je ne sais pas argumenter ? Ben j'élargi juste ton raisonnement. Pour toi rien ne prouve qu'on peut implémenter librement .NET. Moi j'élargi pour montrer que c'est un problème général et pas spécifique à Mono. Enfin puisque tout est pourri, commencons par arrêter d'utiliser ce noyau Linux qui violent des centaines de brevets.
Ba oui, et ça s'applique donc à .NET.
Ce que je n'aime pas, c'est qu'on soulève à chaque fois le problème des brevets logiciels pour Mono... Effectivement Mono a ce problème, comme tous les autres, et ensuite ? Tous les logiciels libres sont donc pourris ? Moi je vais me mettre à faire pareil tiens. Dès que quelqu'un parle de Python ou KDE (je dis n'importe quoi) : "oué mais c'est pas libre, rien nous garantie que ces technos ne violent pas de brevets logiciels". C'est une façon simple et pratique de dénigrer une techno sans éléments tangibles. Un autre exemple appliqué au monde de l'automobile (vendeur Mercedes) : "BMW c'est dangereux, rien ne vous prouve que vous allez pas vous envoyer dans le décor au prochain virage" Genre c'est un problème spécifique à BMW.
Mon pauvre, dans ton évangelisme forcené tu ne comprends même pas l'ironie.
Désolé mais ca ne transpirait pas l'ironie. Un petit smiley aurait aidé ;)-
[^]Re: C# et le libre...
Posté par boubou (page perso, ) le 22/01/2006 à 18:13. (lien). Évalué à 10.Moi je traduis juste tes sous-entendus
Il n'y en avait aucun. Il y a ici comme dans de nombreux endroits une incompréhension de l'impact des brevets sur les standards, je ne fais qu'essayer de passer un message.
quand tu parles du problème du mp3, c'est parcqu'une société a des brevets logiciels sur des algo liés au format mp3, et qu'elle peut donc vendre des licences d'utilisations, et de ce fait empêche une implémentation "libre".
Oui, exactement, et alors ?
D'une manière générale, rien n'empêche une implémentation libre de standard, sauf en cas de brevets logiciels.
Dans tes rêves. Il y aussi le problème des marques, la propriété au sens du copyright de certaines apis, etc. Ceci dit, le problème de .NET est bien lié aux brevets, au moins pour la partie standardisée. Pour la partie qui est propriété de MS, je pense qu'il y a d'autres moyens de protection.
Pas plus que le HTML peut être implémenté librement, pas plus que le standard XY peut être implémenté librement, etc. On est bien d'accord : les brevets logiciels ca pu, ca met en danger tous les logiciels libres.
Sauf que c'est beaucoup plus complexe que ça. Par exemple, les standards du W3C sont obligatoirement en royalty free. Les auteurs d'un standard W3C comme XML, HTML, etc. sont dans l'obligation 1) de révéler leurs brevets concernés par un standards 2) de fournir une licence royalty free. Pour l'instant, il n'existe aucun problème avec de très nombreux standards du W3C, comme HTML, XML, etc. Au contraire, il existe de gros problèmes avec d'autres standards comme mp3, mpeg4, la fat (dont le brevet n'a finalement pas été invalidé), etc.
Ce que je te reproche, c'est de toujours te réfugier, comme tous les fans béats de Mono, derrière des considérations générales sur les brevets pour défendre la possibilité d'une implémentation libre de .NET, alors que ce framework pose des problèmes spécifiques : 1) il est l'oeuvre de MS 2) MS défend maintenant sa "propriété intellectuelle" de façon assez sérieuse par diverses techniques dont les brevets (alors qu'historiquement ce n'était pas trop le cas) 3) .NET est très novateur sur certains points, ce qui rend possible des brevets sans prior art 4) MS a tenté de protéger l'API complète, même si pour l'instant le brevet n'a pas été validé.
Je ne sais pas argumenter ? Ben j'élargi juste ton raisonnement. Pour toi rien ne prouve qu'on peut implémenter librement .NET. Moi j'élargi pour montrer que c'est un problème général et pas spécifique à Mono. Enfin puisque tout est pourri, commencons par arrêter d'utiliser ce noyau Linux qui violent des centaines de brevets.
Le problème n'est pas spécifique à Mono, mais .NET pose des problèmes spécifiques, cf au dessus.
Ce que je n'aime pas, c'est qu'on soulève à chaque fois le problème des brevets logiciels pour Mono... Effectivement Mono a ce problème, comme tous les autres, et ensuite ?
Non, pas comme tous les autres, Mono vise à être la COPIE CONFORME d'un produit qui est au coeur de la stratégie de Microsoft. Si tu ne comprends pas qu'être la COPIE CONFORME de quelque chose est différent d'intégrer des éléments qui pourraient être brevetés, je ne peux rien pour toi.
Moi je vais me mettre à faire pareil tiens. Dès que quelqu'un parle de Python ou KDE (je dis n'importe quoi) : "oué mais c'est pas libre, rien nous garantie que ces technos ne violent pas de brevets logiciels".
Il est vrai que tu dis parfaitement n'importe quoi, surtout pour Python. Python, comme par exemple Caml ou Ruby, est très innovant et n'est pas une copie d'autre chose. Il est possible que Python viole des brevets, mais ce n'est certainement pas la copie de quelque chose inventée par d'autres.
C'est une façon simple et pratique de dénigrer une techno sans éléments tangibles.
Et voilà, tu te dévoiles. Tu te trompes d'adversaire, mon cher. J'admire .NET et C# qui sont pour moi l'étape logique après Java. Excepté deux ou trois conneries, C# est à mon avis strictement mieux que Java, ditto pour le framework. La techno est merveilleuse et les promesses pour la version 3 sont impressionnantes. Mais voilà, c'est une techno microsoft qui fait partie de sa stratégie actuelle et ça pose de nombreux problèmes non techniques.
Un autre exemple appliqué au monde de l'automobile (vendeur Mercedes) : "BMW c'est dangereux, rien ne vous prouve que vous allez pas vous envoyer dans le décor au prochain virage" Genre c'est un problème spécifique à BMW.
Belle comparaison débile. Et si je te parle de la classe A et du test de l'élan, tu te rends mieux compte du caractère débile de ta comparaison ? Encore une fois, tu devrais lire les commentaires des autres avant de répondre de travers avec ton cathéchisme pro-mono. J'ai passé des jours et des jours à me documenter sur le sujet, à lire des dizaines d'articles, blogs, brevets, etc. pour écrire mon article dans Linux Mag. Tu me confonds avec un trolleur de base, donc récapitulons pour ta future réponse :
1) techniquement, C# et .NET sont de très belles choses que j'admire
2) je connais le sujet-
[+] [^]Re: C# et le libre...
Posté par TImaniac (page perso, ) le 22/01/2006 à 19:31. (lien). Évalué à -1.Oui, exactement, et alors ?
Ben alors voilà pourquoi je disais "traduire" tes sous-entendu, tu parlais de mp3 mais pas directement de brevets logiciels.
Il y aussi le problème des marques, la propriété au sens du copyright de certaines apis, etc.
Oué enfin les marques c'est pas un problème, au pire on parle plus de .NET, "Common Language Runtime" ca risque pas d'être déposable, etc. D'ailleur les termes employés à l'ECMA ne sont pas les mêmes que MS, on a par exemple "IL" à l'ECMA et "MSIL" chez MS. Quand aux copyright, ben on a pas les sources (à part Rotor), donc on risque pas de copier grand chose. Argumente bon sang :)
Par exemple, les standards du W3C sont obligatoirement en royalty free.
Et ? quel est le rapport avec ce que je dis ? Si l'entreprise BrevetsLogiciels Inc. s'apercoit qu'elle détient un brevet que violent un standard du W3C ? Eolas ca te rappelle quelque chose ? Je trouve ca beaucoup plus dangereux, ces brevets existant vraiment et leurs possesseurs ont des objectifs peu scrupuleux (faire cracher du pognon à un max de sociétés). Pour moi c'est autrement plus important. T'en penses quoi ?
1) il est l'oeuvre de MS
Oui et ? XML est en partie l'oeuvre de MS, HTML aussi, CSS aussi, etc. Mono n'est pas simplement .NET, et n'est donc pas l'oeuvre de MS de toute façon.
2) MS défend maintenant sa "propriété intellectuelle" de façon assez sérieuse par diverses techniques dont les brevets (alors qu'historiquement ce n'était pas trop le cas)
Oui et ? IBM fait pareil, Sun fait pareil, toutes les entreprises font pareil. Et tous ont des brevets qui peuvent potentiellement "enmerder" un LL.
3) .NET est très novateur sur certains points, ce qui rend possible des brevets sans prior art
Ah ? .NET c'est surtout l'intégration de nombreux technos au sein d'une même plateforme, c'est ce qui fait sa force, mais je vois difficilement comment c'est brevetable. Mais bon vas-y donne nous un exemple de partie "novatrice" que MS a breveté.
4) MS a tenté de protéger l'API complète, même si pour l'instant le brevet n'a pas été validé.
Oué mais en attendant ces brevets ne concerne pas Mono puisqu'ils n'existent pas.
Et voilà, tu te dévoiles. Tu te trompes d'adversaire, mon cher.
Je me dévoile ? Genre c'est la première fois qu'on a les mêmes conversations :)
Je me trompes pas d'adversaire, je lis bien que tu "vente" certains méritent de .NET. Pourtant tu fais un papier (bien construit au passage) à la conclusion "tendancieuse" puisque tu conclus au danger des brevets logiciels sur Mono. Moi je vois pas l'intérêt de prendre Mono comme cas particulier.
. Et si je te parle de la classe A et du test de l'élan, tu te rends mieux compte du caractère débile de ta comparaison ?
Oui ben désolé, comme toutes les comparaisons elles sont débiles. Mais je penses que tu as saisies l'idée ;)
Moi ce que je comprend pas dans ton discours, c'est pourquoi tu n'élargi jamais ton raisonnement que tu appliques à Mono au reste des LL. MS a de nombreux brevets, ils peuvent très bien attaquer par exemple une implémentation de JVM qui viole un brevet (ayant conclu un accord avec Sun, ils n'attaqueront pas Sun) : pour moi c'est beaucoup plus dangereux comme position d'implémenter un produit concurrent à MS. Pourquoi ton papier ne parle pas de ça ?
1) techniquement, C# et .NET sont de très belles choses que j'admire
2) je connais le sujet
Ben pour ma part :
- je suis pas du genre à dire faire de la pub "gratuite", un peu comme je vois souvent (oué mais "Python c'est mieux", "Python c'est the best, etc.)
- mon objectif est non pas de montrer que Mono est exempt de tout risque, mais qu'il est dommage de "s'acharner" sur un seul projet, alors que le problème est beaucoup plus général.
Puisque tu écris bien et que tu aimes faire des enquêtes approfondies, fais nous un beau papier pour LinuxMag sur les risques des brevets logiciels sur les standards du W3C, en prenant Eolas comme bel exemple. MS peut être tout aussi dangereux avec ses brevets potentiels sur le XML (pauvre XHTML). Tu t'attaqueras après au format OpenDocument, qui doit bien en violer un tas également (encore XML, ressemblances avec MS Office, etc.)-
[^]Re: C# et le libre...
Posté par boubou (page perso, ) le 22/01/2006 à 20:48. (lien). Évalué à 6.Argumente bon sang :)
C'est sur que tu argumentes. Les copyrights autour des headers ou des interfaces (.h en C par exemple) ne sont pas des choses très claires. Il n'est pas certain qu'on puisse implémenter une bibliothèque 100% compatible avec un header donné sans infreindre les droits des auteurs du header.
Et ? quel est le rapport avec ce que je dis ?
Le rapport est que AUJOURD'HUI les auteurs d'un standard du W3C ne peuvent pas avoir de brevets contraignants dessus, ce qui n'est pas le cas d'autres standards.
Si l'entreprise BrevetsLogiciels Inc. s'apercoit qu'elle détient un brevet que violent un standard du W3C ?
C'est la merde, et alors ? Ce que tu fais semblant de ne pas comprendre, c'est que Mono pose d'AUTRES problèmes que le problème standard des brevets logiciels.
Eolas ca te rappelle quelque chose ?
Oui, Eolas ça me rappelle ça : http://www.theregister.co.uk/2004/03/05/eolas_web_patent_nul(...)
Pour moi c'est autrement plus important. T'en penses quoi ?
Autrement plus important que quoi ? Les brevets sont un problème graves, nous sommes d'accord. MS cherche à en obtenir sur .NET, c'est donc grave. Pour les standards du W3C, il y a un danger EN MOINS c'est que les inventeurs ne cherchent pas à empêcher l'implémentation de leurs inventions. Mais bon, je me demande pourquoi je perds mon temps à te répéter ça, tu refuses de comprendre.
Oui et ? XML est en partie l'oeuvre de MS, HTML aussi, CSS aussi, etc.
Exact et ce sont des standards du W3C, donc MS NE PEUT PAS DEMANDER AUTRE CHOSE QUE DU ROYALTY FREE. Tu ne sais pas lire ?
Mono n'est pas simplement .NET, et n'est donc pas l'oeuvre de MS de toute façon.
Tu le fais exprès de répondre à côté ?
Oui et ?
Et les conditions de l'ECMA autorisent MS à faire du RAND, c'est-à-dire à demander du fric pour avoir une licence de ses brevets. Toi comprendre ?
Ah ? .NET c'est surtout l'intégration de nombreux technos au sein d'une même plateforme, c'est ce qui fait sa force, mais je vois difficilement comment c'est brevetable. Mais bon vas-y donne nous un exemple de partie "novatrice" que MS a breveté.
Lis la demande de brevet, je t'ai donné au moins 10 fois les liens.
Genre c'est la première fois qu'on a les mêmes conversations :)
Je corrige ta propagande.
Pourtant tu fais un papier (bien construit au passage) à la conclusion "tendancieuse" puisque tu conclus au danger des brevets logiciels sur Mono. Moi je vois pas l'intérêt de prendre Mono comme cas particulier.
Parce que tu ne comprends pas la différence avec d'autres cas, ce qui prouve que tu n'as pas lu l'article, ni mes messages d'au dessus. Dernière répétition : beaucoup de logiciels libres n'ont pas pour but de faire un clone 100 % compatible avec un logiciel propriétaire, potentiellement protégé par des brevets. Beaucoup de logiciels libres ne sont pas présentés comme l'avenir radieux de Gnome, etc.
tu n'élargi jamais ton raisonnement que tu appliques à Mono au reste des LL
Cf au dessus pour le cas particulier de Mono. Pour le cas général, relis l'article, je dis bien que les brevets logiciels sont dangereux.
MS a de nombreux brevets, ils peuvent très bien attaquer par exemple une implémentation de JVM qui viole un brevet (ayant conclu un accord avec Sun, ils n'attaqueront pas Sun)
C'est sûr que MS n'aurait jamais utilisé cet argument contre Sun au moment où ils se battaient comme des chiffoniers autour de Java (je mets un smiley :-)
pour moi c'est beaucoup plus dangereux comme position d'implémenter un produit concurrent à MS
Gni ? Java est antérieur à .NET et des implémentations open source de la partie qui rapporte du fric (J2EE) existent et dominent même le marché depuis longtemps. Je ne vois pas de quoi tu parles, donc.
Pourquoi ton papier ne parle pas de ça ?
De tes fantasmes ?
je suis pas du genre à dire faire de la pub "gratuite",
Ah, ah, ah. Genre les délires sur JNI au dessus ?
mon objectif est non pas de montrer que Mono est exempt de tout risque, mais qu'il est dommage de "s'acharner" sur un seul projet, alors que le problème est beaucoup plus général.
Oui, car tu ne comprends pas que Mono n'est pas Linux, car Mono est une copie 100% compatible d'un logiciel de MS, alors que Linux n'a jamais été une copie d'un Unix existant (je prends Linux comme exemple parmi tant d'autres). Le but de mon article, par exemple, était d'étudier les dangers liés à Mono, pas de gloser dans le vide sur le danger des brevets comme tu le fais. Faire du concret pas du vent.
MS peut être tout aussi dangereux avec ses brevets potentiels sur le XML (pauvre XHTML)
Non, car MS ext co-inventeur de XML au sein du W3C et qu'il a donc renoncé à demander autre chose que du royalty free sur ce standard. Tu es vraiment incroyable. Est-ce que ça t'arrive de lire ce à quoi tu réponds ?
Tu t'attaqueras après au format OpenDocument, qui doit bien en violer un tas également (encore XML, ressemblances avec MS Office, etc.)
Quel puissance dans l'argumentation ! Donc parce que certains logiciels libres pourraient courrir les mêmes risques que Mono, il ne faut pas parler de ces risques ou seulement le faire de façon globale ?
Bon aller, tu vas encore gagner, comme d'habitude, j'abandonne.-
[+] [^]Re: C# et le libre...
Posté par TImaniac (page perso, ) le 22/01/2006 à 21:32. (lien). Évalué à -2.c'est que Mono pose d'AUTRES problèmes que le problème standard des brevets logiciels.
Légalement je ne vois pas d'autres problèmes. Tout à coup tu me sors de ta poche le copyright et les marques déposées. Pour le 2ème je vois pas, pour le copyright des .h je m'étais jamais posé la question... cela dis en .NET y'a pas de .h :) Enfin bon je vois mal le copyright s'appliquer au noms de méthode contenus dans les méta-données d'un assembly...
Pour les standards du W3C, il y a un danger EN MOINS c'est que les inventeurs ne cherchent pas à empêcher l'implémentation de leurs inventions.
De toute façon c'est pas les "inveteurs" qui vont chercher à enmerder d'autres implémentation, sinon je vois pas leur intérêt à standardisé. Le vrai risque provient de société tierce comme Eolas qui n'ont aucun intérêt dans la standardisation, juste du ponion à se faire. Il a fallu que tout le monde se mette en émoi et que le brevet subisse plusieurs passages aux tribunaux...
Et les conditions de l'ECMA autorisent MS à faire du RAND, c'est-à-dire à demander du fric pour avoir une licence de ses brevets. Toi comprendre ?
Oui moi y'en a très bien comprendre. Mais là tu supposes que les brevets en question soit validés.
C'est sûr que MS n'aurait jamais utilisé cet argument contre Sun au moment où ils se battaient comme des chiffoniers autour de Java
Oué mais à mon avis y'avait autant de brevets de part et d'autre.
Gni ? Java est antérieur à .NET et des implémentations open source de la partie qui rapporte du fric (J2EE) existent et dominent même le marché depuis longtemps. Je ne vois pas de quoi tu parles, donc.
Java antérieur et ? VB aussi avait sa machine virtuelle :) Java n'a rien inventé... et Java 1.5 pompe des trucs de .NET.
Genre les délires sur JNI au dessus ?
J'ai réctifié ma phrase. JNI c'est pas "binairement" portable. C'est pas fondamentalement gênant, mais c'est embêtant je trouve, surtout pour Java où le "runeverywhere" est de rigueur.
Oui, car tu ne comprends pas que Mono n'est pas Linux, car Mono est une copie 100% compatible d'un logiciel de MS, alors que Linux n'a jamais été une copie d'un Unix existant
C'est vrai que Linux n'a jamais tenté d'avoir une certaine compatibilté avec les Unix. Sans blagues :)
Non, car MS ext co-inventeur de XML au sein du W3C et qu'il a donc renoncé à demander autre chose que du royalty free sur ce standard. Tu es vraiment incroyable. Est-ce que ça t'arrive de lire ce à quoi tu réponds ?
Mais non je suis pas incroyable :) MS peut très bien breveter des méthode d'enregistrement par exemple, comme ils ont voulu (j'ai pas tout suivi) le faire avec leur format Office XML entre autre. Ils ont peut être pas de brevets sur le format en soit mais sur des méthodes indispensable pourquoi pas.-
[^]Re: C# et le libre...
Posté par gnap gnap (page perso, ) le 24/01/2006 à 12:56. (lien). Évalué à 4.« Mais non je suis pas incroyable :) MS peut très bien breveter des méthode d'enregistrement par exemple, comme ils ont voulu (j'ai pas tout suivi) le faire avec leur format Office XML entre autre. Ils ont peut être pas de brevets sur le format en soit mais sur des méthodes indispensable pourquoi pas. »
Ce qui est épatant reste tout de même ta volonté de bondir d'un truc à l'autre tout ça pour ne pas remettre en cause ton parti pris de départ.
A chaque fois apparaît un nouvel argument qui en appelle un autre ; mais dans l'ensemble, la question de départ reste dans l'oubli.
(là, on pourrait se demander comment il serait possible de trouver une méthode indispensable pour générer un fichier XML qui serait brevetable... une méthode indispensable pour générer un fichier texte ?)-
[^]Re: C# et le libre...
Posté par TImaniac (page perso, ) le 24/01/2006 à 14:49. (lien). Évalué à 0.C'est de bonne guerre, il me sort bien le coup des (TM) et (C) tu trouves ca mieux toi :)
-
[^]Re: C# et le libre...
Posté par gnap gnap (page perso, ) le 26/01/2006 à 08:18. (lien). Évalué à 2.Ok, c'est de bonne guerre. Mais pour quoi tu guerroies, au fond ? Quel est l'enjeu ?
-
[^]Re: C# et le libre...
Posté par boubou (page perso, ) le 26/01/2006 à 16:00. (lien). Évalué à 2.Bon, je te reponds quand même, finalement. Tu as écrit "D'une manière générale, rien n'empêche une implémentation libre de standard, sauf en cas de brevets logiciels." C'est faux, surtout à cause des premiers mots. Je n'ai pas dit que le problème des interfaces ou des marques s'appliquait à .NET, j'ai juste dit qu'il existait. Adobe a par exemple longtemps prétendu que la liste des mots clés de postscript était sous son copyright et qu'on ne pouvait donc pas implémenter un interpréteur postscript sans son accord (qu'il donnait de façon automatique, mais c'est un autre problème). Autre exemple, le fait que les api java comportent le mot java implique que Sun peut chercher des poux dans la tête de toute implémentation concurrente sans même évoquer de brevets (encore une fois, ce n'est pas un problème pratique car on obtient très facilement une licence d'implémentation de Java, c'est automatique quand on télécharge l'api). Autre exemple, on ne peut pas dire qu'on fait un compilateur Ada s'il ne passe pas certains tests.
La liste est longue. Le droit d'implémenter un standard n'est pas une chose automatique, même en l'absence de brevet.-
[^]Re: C# et le libre...
Posté par TImaniac (page perso, ) le 26/01/2006 à 16:14. (lien). Évalué à 2.Effectivement, mais autant je trouve le copyright de Adobe sur PostScript douteux, je comprends mieux le cas Java, qui peut être une marque déposée. (je suppose que c'est d'ailleur le cas). J'avais jamais penser à ca, cela dis ca peut aussi s'inscrire dans des exceptions comme le reverse engineering, parfoislégitimisé par l'interopérabilité qui en découle.
-
-
-
[^]Re: C# et le libre...
Posté par Ontologia (page perso, ) le 18/02/2006 à 01:22. (lien). Évalué à 2.A chaque fois apparaît un nouvel argument qui en appelle un autre ; mais dans l'ensemble, la question de départ reste dans l'oubli.
Comme font les énarques, tu veux dire ?
-
-
-
-
-
[^]Re: C# et le libre...
Posté par karteum59 () le 23/01/2006 à 11:28. (lien). Évalué à 4.J'admire .NET et C# qui sont pour moi l'étape logique après Java. Excepté deux ou trois conneries, C# est à mon avis strictement mieux que Java, ditto pour le framework. La techno est merveilleuse et les promesses pour la version 3 sont impressionnantes.
Je connais assez peu .NET mais je me pose régulièrement une question : pourquoi est-on obligé de passer par une machine virtuelle ? En effet, les avantages de .NET sont à ma connaissance :
- l'indépendance de la plate-forme (principal avantage de la VM, mais à mon avis ce n'était pas le but recherché par Microsoft)
- une API vaste et unifiée (mais pas besoin de créer une nouvelle plate-forme avec VM pour ça, c'est juste une histoire de mettre les moyens pour coder un bon framework et le rendre accessible depuis plein de langages)
- multi-langage (je vais peut-être dire une connerie mais il faut vraiment une VM pour ça ? y'aurait pas moyen de faire autrement, comme par exemple définir une ABI à laquelle tout le monde se conformerait ?)
- langages de haut niveau comme c#/delphi.NET/<votre_langage_favori> avec garbage collector, programmation fonctionnelle & co... (il existe déjà des langages compilés qui font tout ça, cf OCaml. Au pire il suffirait de coder un frontend c# pour gcc => pas besoin de VM non plus !)
Le principal avantage que je vois est d'avoir une machine virtuelle commune et bien optimisée pour les langages comme Perl/Python/Ruby (même si c'est aussi le but de Parrot, qui est apparemment spécialisée dans ce type de langages faiblement typés). A part ça, j'ai l'impression que le "manque" que .NET vient combler l'est / le serait tout aussi bien avec la mise au point d'une API bien foutue (style QT) + l'intégration de langages de haut niveau dans gcc (comme le D ou OCaml) + ABI facilitant l'interopérabilité du code objet entre différents langages.
Donc en gros, pourquoi l'avenir de l'informatique passerait t-il forcément par un dispositif avec une machine virtuelle ? (c'est quand même plus gros/lourd/lent que d'avoir un code qui s'execute directement non ?). Surtout que
- les logiciels libres n'ont besoin que d'une API portable (possibilité de recompiler pour chaque architecture)
- Microsoft ne recherche à mon avis pas vraiment à favoriser la portabilité (je ne vois pas quel est leur intérêt de promouvoir une telle architecture)
- les autres éditeurs de logiciels (propriétaires) peuvent être intéressés par l'aspect multi plates-formes, mais là encore une simple API portable (comme QT) résoud la majeure partie du problème (il suffit de compiler pour chaque architecture, mais ça reste la même base de code)-
[^]Re: C# et le libre...
Posté par TImaniac (page perso, ) le 23/01/2006 à 12:33. (lien). Évalué à 3.l'indépendance de la plate-forme (principal avantage de la VM, mais à mon avis ce n'était pas le but recherché par Microsoft)
MS doit supporter plusieurs architectures matérielles : x86, x64 plus les proc de PDA/smartphone (ARM, etc.) L'indépendance vis-à-vis d'une plateforme matérielle est donc bien un but recherché par MS.
- langages de haut niveau comme c#/delphi.NET/<votre_langage_favori> avec garbage collector, programmation fonctionnelle & co... (il existe déjà des langages compilés qui font tout ça, cf OCaml. Au pire il suffirait de coder un frontend c# pour gcc => pas besoin de VM non plus !)
Faut bien voir que la VM n'est qu'une "vision", une sorte d'abstraction pour les programmeurs et compilateurs. Mais à l'exécution tout ca est compilé en code natif (JIT), voir même avant (AOT), bref après ca marche comme OCaml ou du code compilé avec gcc. Faut bien voir que gcc propose intrinsèquement la même architecture avec un code intermédiaire entre le frontend et le backend (commun à tout le monde). La différence c'est que gcc n'offre pas (ou très peu) de services supplémentaires (à l'exécution). S'il y a des différences de perf, c'est pas lié à la présence du code intermédiaire pour la VM, mais justement aux services associés : GC, sécurité, reflection, etc. Après tout est une question d'objectifs. Si les VM ont du succès aujourd'hui par rapport à hier, c'est que les services qu'elles offrent sont plus intéressant que les pertes de performances qu'elles engendrent (avant c'était trop pénalisant, aujourd'hui ca peut le rester dans des parties critiques).
Donc en gros, pourquoi l'avenir de l'informatique passerait t-il forcément par un dispositif avec une machine virtuelle ?
Pour l'ensemble des services qu'elles offrent, qui permettent de gagner en productivité.
-
[^]Re: C# et le libre...
Posté par djano () le 23/01/2006 à 12:59. (lien). Évalué à 2.Donc en gros, pourquoi l'avenir de l'informatique passerait t-il forcément par un dispositif avec une machine virtuelle ? (c'est quand même plus gros/lourd/lent que d'avoir un code qui s'execute directement non ?). Surtout que
- les logiciels libres n'ont besoin que d'une API portable (possibilité de recompiler pour chaque architecture)
- Microsoft ne recherche à mon avis pas vraiment à favoriser la portabilité (je ne vois pas quel est leur intérêt de promouvoir une telle architecture)
- les autres éditeurs de logiciels (propriétaires) peuvent être intéressés par l'aspect multi plates-formes, mais là encore une simple API portable (comme QT) résoud la majeure partie du problème (il suffit de compiler pour chaque architecture, mais ça reste la même base de code)
C'est justement dans ta derniere phrase que vient l'interet: pas de recompilation car la VM s'en charge avec une compilation Just In Time
=> c'est portable sur toutes les architectures sans recompiler soi meme (puisque la VM le fait!)
Ce que cherche Microsoft, c'est de faire tomber le plus de gens possibles dans leur technos. Comme tout editeur de langage "industriel". Java en fait de meme et se vante meme du nombre de developpeurs total. Tout ca pour qu'un developpeur soit interchangeable avec un autre pour maintenir et faire evoluer le logiciel ecrit en C/C++/Java/.Net, etc...
Donc il faut a Microsoft quelque chose de plus fort que Java: .Net. Il y a les avantages de Java + des choses mieux (normal: ca a ete fait apres) + une tres bonne integration a sa propre plateforme.
J'espere avoir repondu a tes interogations ;-)
-
[^]Re: C# et le libre...
Posté par boubou (page perso, ) le 23/01/2006 à 13:58. (lien). Évalué à 4.c'est quand même plus gros/lourd/lent que d'avoir un code qui s'execute directement non ?
Non. Une VM peut faire dynamiquement des optimisations de très haut niveau qui ne sont pas possible à implémenter statiquement. Par exemple quand tu as une interface X et une référence x vers un objet de type X, quand tu appelles une méthode disons f (x.f) la méthode réellement exécutée est choisie dynamiquement, ce qui pose des tas de problèmes (pas d'inline, look up dans une table, etc.). Une VM peut faire de l'analyse de code et supprimer le dispatch dynamique dans certaines conditions. D'autres exemples sont la gestion fine du garbage collector (réglage de certains paramètres au vol) ou encore la façon donc la VM .NET engendre les templates au vol (avec partage du code si nécessaire et spécialisation si ça peut apporter quelque chose en terme de performances).
Contrairement à ce que raconte Timaniac, il est bien entendu parfaitement possible de faire du garbage collecting sans utiliser de VM, de même que de la reflection, etc. En fait, il y a assez peu de choses qu'on ne peut pas faire sans VM, à condition d'intégrer un runtime dans l'exécutable, c'est à dire une sorte de bibliothèque chargée de fournir de façon transparente certains services. C'est ce système qui permet de compiler OCaml en natif.
En fait, beaucoup de gens (comme Timaniac) confondent runtime et VM. L'intérêt d'une VM, c'est bien qu'elle a accès à un code de haut niveau (le code de la VM). Elle peut donc prendre des décisions fines sur ce code qu'elle ne pourrait pas prendre à partir d'un code objet, parce que le bytecode Java ou .NET est de plus haut niveau, tout simplement. Timaniac a quand même raison sur un point (ça lui arrive), c'est que la sécurité vient en partie de ce code de haut niveau qui est en général vérifiable : la VM peut s'assurer qu'il ne contient pas de buffer overflown et d'autres bugs qui pourraient mettre en péril son modèle de sécurité. Ce n'est pas parfait, mais ça offre un niveau de sécurité largement supérieur à celui des plugins écrits en C pour Gimp, par exemple.
Au final, le principal intérêt des VMs ce sont justement les performances, ce qui est assez paradoxal. L'autre intérêt, c'est la programmation en couche : développer une VM de base, ce n'est pas très difficile (il existe une bonne dizaine de JVM open source, par exemple), car ça reste de bas niveau. Quand la VM existe, développer un compilateur n'est pas non plus super difficile car la VM est de bien plus haut niveau que l'assembleur, par exemple. En gros, on a donc intercalé un niveau d'abstraction entre le hardware et le compilateur, ce qui est assez cool.
Ceci dit, comme le montre l'exemple de GCJ, compiler nativement un langage comme Java ne pose pas de problèmes particuliers.-
[^]Re: C# et le libre...
Posté par karteum59 () le 23/01/2006 à 14:31. (lien). Évalué à 2.Non. Une VM peut faire dynamiquement des optimisations de très haut niveau
A une certaine époque, j'avais lu (dans un bouquin de Perl qui parlait aussi un peu de Java) que la VM Java était d'assez bas-niveau (un peu comme un assembleur) alors que celle de Perl était de très haut niveau (appels directement traduisibles en appels de fonctions C), ce qui expliquait la différence de vitesse entre Perl et Java. Je pensais que la CLR était un peu comme la JVM, une sorte "d'émulateur" pour un proc virtuel, avec donc des instructions de très bas niveau...
Maintenant, si je comprends bien, la CLR possède des instructions de plus haut niveau que la JVM, permettant davantage d'optimisations en tout genre ?
Mais à l'exécution tout ca est compilé en code natif (JIT)
Oui, mais je me dis que ça prend du temps de faire tous ces traitements (suffit de voir le temps de chargement d'une appli Java, ou le temps de compilation d'un programme C++ pour se dire qu'il vaut mieux les faire une fois pour toutes qu'à chaque lancement de l'appli). Du coup est-ce qu'on arrive quand même à concilier légèreté / rapidité de lancement avec toutes les optimisations en question ?
voire même avant (AOT)
Quand la VM existe, développer un compilateur n'est pas non plus super difficile car la VM est de bien plus haut niveau que l'assembleur
Donc il existe une manière de compiler du .NET en natif ? (comme avec gcj ?)
Ah, pendant que j'y suis, on parle beaucoup de Mono mais quid de DotGNU ? le second est une vraie alternative ou pas ?-
[^]Re: C# et le libre...
Posté par TImaniac (page perso, ) le 23/01/2006 à 15:07. (lien). Évalué à 2.Je pensais que la CLR était un peu comme la JVM, une sorte "d'émulateur" pour un proc virtuel, avec donc des instructions de très bas niveau...
Un émulateur serait plutôt ce qu'on appelle un "interpréteur" : il lit bêtement à la suite les instructions de la machine virtuelle, les interprêtes, et les exécute. C'est ce qui se passe par exemple avec l'interprêteur Perl. C'est comme ca que fonctionnait les JVM initialement. Maintenant l'environnement d'exécution "compile" le bytecode en code natif avant de l'exécuter.
Donc il existe une manière de compiler du .NET en natif ? (comme avec gcj ?)
.NET a été conçu pour être compilé dès le départ, c'est donc assez naturelle. sous Mono ca donne :
mono --aot monprog.exe
Pour java c'était plus compliqué, vu que ce n'était pas conçu pour dès le départ. La plupart des JVM mixait donc du JIT et de l'interprétation. GCJ a démontré que c'était cependant possible de tout compiler avant.-
[^]Re: C# et le libre...
Posté par Black Fox (page perso, ) le 23/01/2006 à 20:55. (lien). Évalué à 3..NET a été conçu pour être compilé dès le départ, c'est donc assez naturelle.
On peut rajouter que microsoft en tire partit pour visual studio 2005 ou le Framework 2.0 par exemple : L'installeur compile le code pour la plateforme cible à l'install.-
[^]Re: C# et le libre...
Posté par TImaniac (page perso, ) le 23/01/2006 à 21:10. (lien). Évalué à 4.Le framework .NET 1 (et donc Visual Studio 2003) propose déjà ca grâce à ngen.exe :
http://msdn.microsoft.com/library/default.asp?url=/library/e(...)
C'est pas bien compliqué de faire en sorte que l'installeur effectue cette opération.
-
-
-
[^]Re: C# et le libre...
Posté par boubou (page perso, ) le 26/01/2006 à 16:14. (lien). Évalué à 2.Maintenant, si je comprends bien, la CLR possède des instructions de plus haut niveau que la JVM, permettant davantage d'optimisations en tout genre ?
Non, elles sont comparables et toutes les deux de haut niveau (mon message parlait autant de la JVM que du CLR) : le tas est avec garbage collecting, la notion d'objet est native à la VM, de même que la gestion des threads, etc.
Du coup est-ce qu'on arrive quand même à concilier légèreté / rapidité de lancement avec toutes les optimisations en question ?
Réponse courte : non. Réponse longue : des gens travaillent la dessus. Par exemple tu peux avoir une JVM qui partage le code compilé entre tous les programmes qu'elle héberge, un peu comme ton OS partage le code des libs entre les process. On peut aussi sauvegarder la version compilée de quelque chose sur le disque pour la réutiliser au prochain lancement. En fait, en terme de vitesse du code le problème est plus ou moins résolu pour des applis qui doivent tourner quelques minutes au moins. Le démarrage est certe lent par rappot à du C, mais sur le long terme, on arrive parfois même à faire mieux que du C. Par contre, au niveau occupation mémoire, ce n'est pas gagné, surtout en Java. Le langage possède quelques limitations (que n'a pas C#) qui font qu'il est très gourmant en mémoire et ça risque de ne pas changer tout de suite.
-
-
[^]Re: C# et le libre...
Posté par TImaniac (page perso, ) le 23/01/2006 à 15:20. (lien). Évalué à 2.Non. Une VM peut faire dynamiquement des optimisations de très haut niveau qui ne sont pas possible à implémenter statiquement.
Il y a aussi des optimisations liées à la machine cible : en C "standard", il faut choisir les optimisations (386, 686, etc.) et filer autant de versions, avec un compilateur JIT, celui-ci peut déterminer "à la volée" les optimisations éventuelles.
Contrairement à ce que raconte Timaniac, il est bien entendu parfaitement possible de faire du garbage collecting sans utiliser de VM, de même que de la reflection, etc
Eh oh j'ai jamais dis ca :) Il y a bien des GC pour C++ par exemple. Comme il y a des possibilité de reflection également en C++ avec certains outils. Mais c'est pas en standard dans le langage. Et pour la sécurité (les AppDomain par exemple), j'ai beaucoup plus de doute sur la faisabilité (mais bon ca doit pouvoir se faire). Un environnement d'exécution comme Java ou .NET/Mono propose ces services en standard, et potentiellement pour tous ceux qui ciblent le code intermédiaire de ces VM. La VM constitue plutôt l'ensemble d'instructions "imposées" qui permet de contrôler et d'obtenir un certain nombre de garanties à l'exécution du code natif résultant.
En fait, beaucoup de gens (comme Timaniac) confondent runtime et VM.
J'ai pourtant tenté d'expliqué que la VM n'était qu'une "vision" du programmeur, et qu'à l'exécution c'était kif kif bourriqot. D'ailleur je parles dès que possible d'"environnement d'exécution", plutôt que de VM.
Ceci dit, comme le montre l'exemple de GCJ, compiler nativement un langage comme Java ne pose pas de problèmes particuliers.
Euh ca fait quand même un moment qu'ils courraient après ;)
Et puis au final un bout de code compilé avec GCJ tourne généralement moins vite qu'un bout de code tournant sur la JVM de Sun donc bon l'intérêt... Cela dis ca reste utile pour faire du JIT sans aucune interprétation.
(désolé pour les sources, mais http://shootout.alioth.debian.org/debian/ ne tient plus compte de GCJ, me demande pas pourquoi)-
[^]Re: C# et le libre...
Posté par boubou (page perso, ) le 26/01/2006 à 16:08. (lien). Évalué à 2.Eh oh j'ai jamais dis ca :)
Oups, désolé, tu as dit que gcc n'offrait pas ça (ce qui est faux).
Et pour la sécurité (les AppDomain par exemple), j'ai beaucoup plus de doute sur la faisabilité
Oui, tu remarqueras que c'est exactement ce que je dis dans le post auquel tu réponds :-)
Euh ca fait quand même un moment qu'ils courraient après ;)
Non, ils courrent après Java, c'est à dire après les apis. La difficulté dans le clonage de Java, c'est l'api monstrueuse, pas la compilation. C++ est beaucoup plus difficile à compiler que Java, par exemple.
Et puis au final un bout de code compilé avec GCJ tourne généralement moins vite qu'un bout de code tournant sur la JVM de Sun donc bon l'intérêt...
L'intérêt, c'est l'occupation mémoire plus faible, la facilité de distribution, etc. Quant au bench que tu cites, c'est de la merde. Il faut vraiment être un âne (je ne parle pas de toi) pour utiliser des benchs qui tournent aussi vite et prétendre que c'est représentatif de quelque chose...-
[^]Re: C# et le libre...
Posté par TImaniac (page perso, ) le 26/01/2006 à 16:25. (lien). Évalué à 2.u as dit que gcc n'offrait pas ça (
elle est où l'option --gc dans le compilo ? :)
Oui, tu remarqueras que c'est exactement ce que je dis dans le post auquel tu réponds
Bah oué je confirmes mes doutes également c'est tout :) Mais comme quoi y'a bien des services qui sont propres aux environnement d'exécutions "managés" ;)
pas la compilation. C++ est beaucoup plus difficile à compiler que Java, par exemple.
Compiler Java n'est pas difficile, mais compiler Java en natif comme le fait GCC c'était visiblement pas évident puisqu'ils avaient l'air d'être tout fier de le faire et qu'ils sont le seul à le proposer...
Quant au bench que tu cites, c'est de la merde. Il faut vraiment être un âne (je ne parle pas de toi) pour utiliser des benchs qui tournent aussi vite et prétendre que c'est représentatif de quelque chose...
Autant pour comparer 2 langages je trouves effectivement que c'est de la merde généralement, autant pour comparer 2 implantations je vois pas en quoi c'est de la merde, sachant que le temps de 'lancement' n'est généralement pas pris en compte...
En tout cas les bench semblent refléter la réalité, il suffit de comparer gcc et le compilo d'intel par exemple pour voir qu'on retrouve bien graphiquement ce qu'on constate de manière empirique :)
L'intérêt, c'est l'occupation mémoire plus faible, la facilité de distribution, etc.
En fait GCJ est parti dans "Extra" me demande pas pourquoi...
http://shootout.alioth.debian.org/sandbox/benchmark.php?test(...)
Ben même si ce sont des benchs de merde, visiblement l'occupation mémoire semble pas spécialement améliorée avec GCJ... Après faut voir sur une appli réelle et comparer... Mais bon des premiers tests de Eclipse sur Fedora que j'avais fais, question rammmage ca avait pas l'air d'apporter quoique ce soit :)
Quand à la facilité de distribution, je trouve que c'est plutôt un désavantage : le bytecode a l'avantage d'être portable, la phase de JIT est pour moi le meilleur compromis : tu distribues un seul binaire, et tu profites de l'exécution native.
-
-
-
-
-
-
-
-
-
-
-
[^]C# est en avance sur son temps
Posté par pvincent () le 24/01/2006 à 09:24. (lien). Évalué à 4.
Par ailleurs, .NET existe et c'est en fait. Son succès est assuré que
Mono existe, ou non. Tu n'as qu'à lire la presse dite
"professionnelle" pour t'en convaincre.
C'est là ou je tique, qu'est ce que la presse dite "professionnelle" ?
Moi, de ce que j'ai lu dans la presse purement "commerciale", c'est des articles qui disent que .NET c'est super, génial, parfait. Sur ce point tout le monde est d'accord.
Ce qui me fait rire, c'est que ce type de message, ca fait depuis 2001 qu'on l'entend. En gros, C# avant même que ca existe, c'était déjà super mature. On avait droit à des super-interviews de technicien M$ qui nous disait que leur environnement (téléchargeable en version Beta pour tout le monde) était déjà super opérationnel depuis des années sur des serveurs de prod avec pleins de références de grandes sociétés, etc...
J'exagère si peu :
Reprenez un bon vieux magazine de 2001 ou de 2002, je suis sûr que vous trouverez un article qui vous dit que .NET ca fait des années qu'ils l'utilisent...
-
-
[^]Re: C# et le libre...
Posté par Xavier Maillard (Jabber id, page perso, ) le 21/01/2006 à 13:33. (lien). Évalué à 4.Perso ca me fait la meme chose que les gens qui utilisent les drivers proprios de chez Nvidia ou ATI sous GNU/linux.
Mono est libre. Point barre. Et si certains ont voulu porter C# sous nos plate-formes, c'est que C# doit avoir des qualites (le cote "invente par Microsoft" ne change rien a l'affaire).-
[^]C#, Python, Java
Posté par Grumbl (page perso, ) le 21/01/2006 à 15:05. (lien). Évalué à 2.J'avoue ne pas voir quel intérêt peut avoir C# par rapport à Python, tout en constatant que Google emploie Python (ce qui est une belle preuve de viabilité de l'implé.de base Python, là où je ne connais aucune preuve de ce genre pour quelque imple C# que ce soit)
-
[^]Re: C#, Python, Java
Posté par LeMagicien Garcimore () le 21/01/2006 à 16:23. (lien). Évalué à 3.J'avoue ne pas voir quel intérêt peut avoir C# par rapport à Python
Au hasard et en passant rapidement : un typage fort et un orienté objets un peu mieux gaulés ?-
[^]Re: C#, Python, Java
-
-
-
Proxy transparent ?
Quelle différence avec un proxy comme Squid ?
-
[^]Re: Proxy transparent ?
Posté par earxtacy (Jabber id, ) le 21/01/2006 à 08:38. (lien). Évalué à 1.La communication chiffrée..SSL, c'est plus dur a faire marcher avec squid avec une espece de reverse proxy ssl, perso j'ai jamais réussi, c'est pas documenté
et je sais meme pas si c'est faisable.
Personne m'a répondu: https://linuxfr.org/forums/41/11386.html-
[^]Re: Proxy transparent ?
Posté par Arnaud Desmons (page perso, ) le 21/01/2006 à 09:01. (lien). Évalué à 4.Moi je te réponds d'utiliser VultureNG : http://vulture.open-source.fr qui gère le SSL ;-)
-
[^]Re: Proxy transparent ?
-
-
[^]Re: Proxy transparent ?
Posté par yoho (page perso, ) le 23/01/2006 à 18:59. (lien). Évalué à 4.Oui, mais de là à appeler un bête proxy https un "portail captif sécurisé"... C'est très hype comme terme, ça fait mieux que "proxy" ou "mandataire".
-
[^]Re: Proxy transparent ?
-
Quid des perfs ?
Salut,
Moi, ce qui me frenne le plus à utiliser Mono, ce sont les performances. Souvent dû à l'imaturité du projet. Donc qu'en est-t-il des perfs ? Pour le web notemment, mais aussi pour des applis clientes de bureau.
E Ultreïa !
-
[^]Re: Quid des perfs ?
Posté par Arnaud Desmons (page perso, ) le 21/01/2006 à 09:11. (lien). Évalué à 2.Oui en fait ça semble être vraiment une application mod_mono (du genre mod_php) qui fait elle même les requêtes vers les applications.
En mod_perl on est vraiment au coeur d'Apache et cela permet par exemple de passer le relai à mod_proxy une fois les phases d'authentification et redirections effectuées par mod_perl. Ça n'a rien a voir au niveau perf je pense.
-
[^]Re: Quid des perfs ?
Posté par Sigmatador () le 22/01/2006 à 11:27. (lien). Évalué à 1.J'ai vu plusieurs bench sur le net ou la JVM .NET mais aussi celle de Mono était de loin bien plus performante que la JVM JAVA de SUN (pas celle d'IBM) dans certain cas, et seulement de peu dans d'autre. L'impartialité de ce genre de bench me laisse souvent perplexe vu que souvent la société qui l'effectue est financée (directement ou non) par l'un des 2 parties.
Néanmoins, si on considère qu'elles sont a peu près equivalentes, contenu de l'ancienneté d'age de la JVM de SUN, un excellent travail semble avoir été fourni du coté des machines virtuelles .NET-
[^]Re: Quid des perfs ?
Posté par fmaz fmaz () le 22/01/2006 à 13:06. (lien). Évalué à 1.On peut aussi se dire que même si les deux langages/environement de travail sont différents, ils partagent un certain nombre de choses et donc qu'une partie du travail fait pour la première a profité à la seconde. Un exemple évident est celui du ramasse miette.
C'est d'ailleurs exactement pour ce genre de choses que les brevêts ont été inventés.
-
[^]Re: Quid des perfs ?
Posté par Romain Guy (page perso, ) le 23/01/2006 à 10:25. (lien). Évalué à 4.Et chaque fois que j'ai vu ces benches il y avait une faille grave dans ledit bench : code non fourni, tests non equivalents, etc. Les performances de .NET et Java sont equivalentes et dans les deux cas tu trouveras toujours un moyen de dire que l'un est plus rapide que l'autre. En pratique...
-
lapin compris
Je ne connais pas du tout le sujet et je ne comprend rien à la dépêche.
C'est quoi un « portail captif » ? Pourquoi « L'utilisation de ce framework .NET sous Linux le rend désormais compatible avec Apache 1 et 2 », quel rapport avec une compatibilité avec apache ? Et ça veut dire quoi une compatibilité apache avec - apache n'est-il pas simplement un serveur respectant un protocole (http) ?
En quoi « la garantie de l'identité des personnes utilisant le réseau en évitant les mécanismes d'usurpation, est bien sur conservé » est un « principe » ?
Je veux bien croire que c'est mon ignorance qui fait que j'ai l'impression de lire une langue qui m'est inconnue, toutefois je pense que la dépêche gagnerait à être compréhensible par tous.
-
[^]Re: lapin compris
Posté par sylware () le 21/01/2006 à 14:16. (lien). Évalué à 10.Bah... encore de la propagande .Net sur linuxfr. C'est normal, si ils peuvent récupérer des devs du libre pour bosser sur leur plateforme, ça facilitera le (re-)passage vers le côté sombre de la force (un peu de troll ça fait du bien).
Il faut savoir que beaucoup de leaders du libre ont bien compris les choses, on parle de JAVA trap aussi bien que de .Net trap. Et il n'y a pas que Stallman.
Il ne faut pas rêver, une partie de .Net a beau être normalisée, avec un peu de jugeote, il n'est pas difficile de comprendre qu'au bout du compte, c'est la grosse boîte qui décide de tout. La grosse boîte sait qu'elle lead .Net donc elle sera automatiquement valorisée: dans l'esprit des gens (et surtout des décideurs) Mono est derrière.
Impact commercial garanti.
Je vous laisse aussi le soin d'apprécier l'élégance des 'brevets logiciels' (Arg! Toujours du mal avec cette absurdité) déposés sur le reste des APIs...
Bref... pour dire qu'il y a libre et libre. Le libre a atteind un stade qui va attirer les convoitises: aujourd'hui de plus en plus de projets se définissent libres parce qu'ils ont une licence qualifiée de libre.
Beaucoup semblent avoir oubliés que la licence n'est qu'une protection légale. Attention, je n'en diminue pas l'importance mais:
Non, le libre ne se réduit pas à une licence. Il y a beaucoup plus derrière.
Donc, j'invite tous le monde a réfléchir sur ce sujet. En effet, à partir d'aujourd'hui il va falloir commencer à voir un peu plus loin que le bout de son nez.
Pour ma part, selon ma perception de la réalité .Net c'est Niet.
-
[^]Re: lapin compris
Posté par ZooL (page perso, ) le 21/01/2006 à 22:23. (lien). Évalué à 0.Pour ce qui est du concept de portail captif, un ptit tour sur les liens liés à talweg auraient répondu à ta question. (RTFA, comme on dit sur slashdot ;))
Le principe désigne la "philosophie" du portail captif. Le but est qu'une fois passé le portail, on soit sur de qui fait quoi.
Pour les autres questions, je dois dire que je ne sais pas vraiment, et que j'aurais apprécié plus de longueurs sur la question. Par contre, sur le pourquoi c'était pas compatible avec apache, je pense avoir une idée.
J'avais assisté à une conférence sur talweg à l'université de Metz, mais je dois dire que j'ai pas saisi tous les aspects.
Donc en gros : quand tu te connectes avec ton wifi, tout est bloqué, tu ne peux accéder qu'à la borne et autres ordis en wifi. Dès que tu vas utiliser ton butineur, tu vas être redirigé vers une page web d'authentification (qui se trouve donc sur un serveur web, comme par exemple apache). Talweg va fournir une sorte de service de proxy ssl (pour éviter que tout le monde puisse espionner ce que tu télécharges). Maintenant, en allant sur leur site, tu verras qu'ils récrivent les adresses web à la volée. Par exemple, http://www.google.fr devient https://u—www—google—fr.my.talweg.
Surement que dans toutes ces actions, certaines n'étaient pas possibles en mod_perl, mais sont maintenant possibles en mod_mono.
-
[^]Re: lapin compris
Posté par TImaniac (page perso, ) le 22/01/2006 à 11:25. (lien). Évalué à 2.Pourquoi « L'utilisation de ce framework .NET sous Linux le rend désormais compatible avec Apache 1 et 2 », quel rapport avec une compatibilité avec apache ?
Bêtement parcque les mod_perl pour Apache1 et Apache2 n'ont pas les mêmes API. C'est 2 modules différents pour 2 serveurs web différents.
Mono propose des APIs unifiés, quelque soit la version d'Apache utilisée.-
[^]Re: lapin compris
Posté par gnap gnap (page perso, ) le 24/01/2006 à 13:02. (lien). Évalué à 3.Donc ça n'a rien à voir avec le choix technologique, ça a juste à voir avec le fait que les auteurs de mod_perl aient cassé la compatibilité descendante avec mod_perl pour apache2.
Donc là dedans, .NET ou pas est indifférent.
C'est déjà plus clair.-
[^]Re: lapin compris
Posté par TImaniac (page perso, ) le 26/01/2006 à 17:09. (lien). Évalué à 2.Si ca à voir. Les auteurs de mod_perl ont cassé la compatibilité parcqu'ils étaient essentiellement constitués d'API "perlisé" de Apache. Apache a cassé la compatibilité, mod_perl a donc pété au passage. Et donc toutes les applis qui les utilise comme talweg.
.NET propose pour talweg tous les API dont ils avaient besoins qui se trouvait dans mod_perl, mais cette fois si avec l'indépendance vis-à-vis du serveur Apache 1, puisqu'on peut facilement imaginer faire tourner l'appli sur un autre serveur web comme Apache 2 ou IIS.
C'est tout l'intérêt de plateforme complètes et intégrées comme .NET ou Java : les APIs sont unifiés et on y trouve de tout en "standard", évitant d'avoir à se trimbaler des dépendances vers 15000 bibliothèques externes dont on n'est pas sûr de la pérénité dans le temps.
-
-
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.