Si le projet en restait là, c'est la plus inquiétante partie de .NET qui disparait. C'est à mon avis un très grave échec pour Microsoft et un signe de la défiance croissante que l'entreprise suscite
.NET rétrécirait-il comme peau de chagrin ?
Apparemment, aucune des sociétés contactées par Microsoft ne s'est résolue à utiliser les services Hailstorm (l'ensemble de services web permettant de stocker les données personelles des utilisateurs sur un serveur Microsoft et donc d'y accéder sur n'importe quel ordinateur). Microsoft a donc décidé d'enterre le projet.
Si le projet en restait là, c'est la plus inquiétante partie de .NET qui disparait. C'est à mon avis un très grave échec pour Microsoft et un signe de la défiance croissante que l'entreprise suscite
Si le projet en restait là, c'est la plus inquiétante partie de .NET qui disparait. C'est à mon avis un très grave échec pour Microsoft et un signe de la défiance croissante que l'entreprise suscite
# Cool !
Posté par Nicolas Roard (site web personnel) . Évalué à 10.
[^] # Re: Cool !
Posté par Éric (site web personnel) . Évalué à 10.
Ce n'est pas qu'ils se sont dit que ce n'etait pas bien et ont rebroussé chemin, c'est qu'ils n'ont pas reussi à aller sur le chemin en question.
[^] # Re: Cool !
Posté par Korbinus (site web personnel) . Évalué à 3.
[^] # Re: Cool !
Posté par kalahann . Évalué à -4.
[^] # Re: Cool !
Posté par kesako . Évalué à 10.
S'il arrivent a vendre le soft aux entreprises ce sera deja pas mal
[^] # euh...oui mais...
Posté par David Bosman . Évalué à 10.
c'est une stagnation pour Microsoft, mais le Logiciel Libre n'y gagne rien de concret et n'avance pas d'un milimètre : il ne perd pas là où Microsoft espérait gagner, c'est tout.
Par contre je voudrais pas jouer les mère chagrin, mais je me demande si on peut vraiment se réjouir de voir Microsoft reconnaître si _vite_ son erreur.
Pour le néophyte comme moi, Microsoft paraît être une des rares boîtes qui a les moyens de supporter un échec commercial et au final d'un tirer quelque chose d'utile à sa stratégie à moyen/long terme.
L'objectif de crosoft à ce stade n'est probablement pas tant d'imposer telle forme de logiciel, ou de "comportement informatique"(je caricature), mais bien de créer une situation où ils seront les seuls à proposer des solutions "utilisables", voire "légales".
Et le plus gros problème pour crosoft c'est "GNU & Co". Le prestige et la qualité des produits Libre, la mauvaise image de crosoft elle-même, les critiques des consommateurs ET citoyens : tout cela sont des choses qu'ils doivent corriger. Qu'ils _veulent_ corriger pour disqualifier l'alternative Libre, non ?
La solution Libre disqualifiée, ils resteront les seuls pour proposer leurs solutions : les solutions qu'ils voudront, aux conditions qu'ils choisiront, de la qualité qu'ils décideront.
Et là, la question ne se posera plus vraiment de savoir si c'est bien ou pas.
Enfin c'est une esquisse, mais pas absolument irréaliste...
S'ils ont retenus une leçon, ils ne feront plus la même erreur, et c'est une évidence qu'un adversaire qui est apprend et qui s'adapte est un dangereux adversaire...
Particulièrement s'il connait SES propres faiblesses ET celles de son adversaire !
(j'évite de lister ici les faiblesses auxquelles je pense, ça dégénererait vite en querelle de colchers (remplis de trolls))
En gros
# Attendons la suite.
Posté par Eddy . Évalué à 10.
Mais je crois qu'il vaut mieux etre paranao avec MS, et voir ce qui va remplacer ce qui est retire.
J'ai du mal a croire que MS va accepter de passer pour de si gros cretins en retirant le projet sur lequel ils avaient bati leur strategie de comm depuis au moins 1 an.
[^] # Re: Attendons la suite.
Posté par nemerid . Évalué à 10.
En ayant lu la nouvelle précédente, je ne pense plus que ce soit de l'ordre de la paranoia que dire d'être extrêmement méfiant sur la façon dont ils veulent enfreindre nos libertés !
[^] # Re: Attendons la suite.
Posté par Def . Évalué à 10.
Ce ne sera pas une bd centrale chez MS, ce qui techniquement, juridiquement et marketingement (?) semblait infaisable. Parcontre, un boite pourrait acheter HailStorm et s'en servir en interne.
[^] # Re: Attendons la suite.
Posté par Euclide (site web personnel) . Évalué à 10.
Et la je ne vois pas qu'elle est le problème personnelement (dans le concept d'un hailstorm local)
# Défiance ?
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 7.
<ironie>
Mince alors !! Que va devenir FreeBSD sans .Net ?
</ironie>
[^] # Re: Défiance ?
Posté par kalahann . Évalué à -4.
[^] # Du mieux dans l'avenir de Gnome
Posté par Jak . Évalué à -2.
[^] # Re: Défiance ?
Posté par Nicolas Roard (site web personnel) . Évalué à 10.
Ca n'a absolument rien à voir avec Hailstorm. Critiquer, oui, mais avec de vrais arguments si possible...
¹ si ça vous rappelle une certaine technolologie de Sun, c'est normal. Si vous trouvez marrant que MDI soit charmé par un langage orienté objet comme C#, après avoir défendu le droit de programmer objet en C, c'est aussi normal.
[^] # Re: Défiance ?
Posté par bleh . Évalué à 5.
C'est un peu court. Il est vrai qu'au niveau technologique il n'y a pas de différences fondamentales mais on ne peut pas dire que dot Net est le java de MS. Il y'a quand même pas mal de différences :
- Au niveau de l'interopérabilité, sur .Net, les langages sont compilés et executés dans le cadre du CLR du coup ils peuvent interopérer et partager du code. Et même au niveau des langages de scripts, pour java l'interopérabilité est limitée (quelques fonctions seulement) tandis sur .Net (à prendre au conditionnel) il y'aura un meilleur niveau d'interopérabilité entre VB, C# et les autres langages.
- .Net utilise des protocoles standard d'application distribué comme UDDI, WSDL, SOAP et XML, java, en comparaison, lui, ne supporte que son protocole binaire RMI (équivalent à SOAP/XML). Ca implique que l'interopérabilité sera conservé même sur des plate-formes où .Net n'a pas été porté.
Bon je pourrais citer d'autres différences et nuances mais ça dépasse largement le cadre de la discussion. Ce que je voulais faire remarquer c'est que dire que .net est le java de MS est, à mon avis, réducteur. L'idée principale de .net n'est pas vraiment originale, je l'admets, mais après tout, avant Java et .net, DCE avait déjà jeté les bases des applications distribuées. Je comprends parfaitement que MDI ait été attiré par cette technologie, maintenant, il faut voir concrètement ce que ça va donner.
[^] # Re: Défiance ?
Posté par Nicolas Roard (site web personnel) . Évalué à 8.
Il y'a quand même pas mal de différences
Ben oui j'allais pas faire un article de trois pages sur .Net , donc comme effectivement il n'y a pas de différences fondamentales ce n'est pas gênant de rappeller rapidement la non-nouveauté que constitue .Net, contrairement à ce que veut nous faire croire Microsoft...
les langages sont compilés et executés dans le cadre du CLR du coup ils peuvent interopérer et partager du code. Et même au niveau des langages de scripts, pour java l'interopérabilité est limitée
Oui c'est plutôt un bon point pour .Net ; même s'il existe une tripotée de langage permettant de cracher du bytecode jvm (python, ada (!) ...) je ne sais pas s'il est possible d'avoir une interopérabilité entre deux .class ? remarque c'est à tester ... si ça se trouve ça marche.
Maintenant j'ai tendance à penser que la disponibilité de plusieurs langages sur .Net n'est pas vraiment importante : je pense que la plupart des gens vont utiliser C# (pour diverses raisons : matraquage publicitaire, langage plutôt correct, etc.) . A comparer à la situation actuelle avec les jvm, ou quasiment tout le monde programme en java et non en d'autres langages.
java, en comparaison, lui, ne supporte que son protocole binaire RMI
Pardon ? et ça c'est quoi : http://xml.apache.org/soap/(...) ?
dire que .net est le java de MS est, à mon avis, réducteur
Réducteur, forcèment, ce n'est pas un clone 1:1 de java donc il y a des différences. Maintenant, elles ne sont pas si importantes qu'on veut bien le dire, en pratique.
Je comprends parfaitement que MDI ait été attiré par cette technologie
C'est clair. Ce qui est marrant c'est qu'après avoir bataillé avec un langage comme C pour créer des applis graphiques (plus de 800000 lignes pour Evolution, vous trouvez ça normal ?), il découvre qu'un langage orienté objet, c'est peut être un poil plus efficace. Faut se souvenir que l'argumentation de MDI était entre autre que C++ est pourri et qu'on peut tout faire soi même en C (vous avez dit : réinventer la roue ?) ... bon...
<digression>
C++ n'est pas parfait, mais il apporte un tas de méthodes pour simplifier la vie des programmeurs. Il n'y a qu'à voir, les types de KDE sont moins nombreux que ceux de Gnome, (ils sont juste 3-4 sur KOffice si je me souviens bien) pourtant ils avancent très vite. Ce qui est du amha à l'utilisation d'un framework bien foutu (Qt + classes KDE) et à l'utilisation d'un langage OO.
On retrouve ce principe avec GNUstep : utilisation d'un (véritable) langage objet (ObjectiveC), et d'un framework particulièrement bien fichu (NeXTStep). Résultat les développements avancent très vite.
Bref on ne peut qu'être d'accord sur l'intérêt que porte MDI sur un langage objet (C#) associé à un framework consistant.
</digression>
maintenant, il faut voir concrètement ce que ça va donner
Exactement; on retombe toujours sur le même problème. D'un autre côté il faut voir que la techno java est robuste, fiable, très bien documentée, et disponible actuellement ...
[^] # Re: Défiance ?
Posté par bleh . Évalué à 1.
<digression aussi>
Je me suis un peu emballé, je pensais surtout au modèle d'objets distribués promus par java, dans ce cas on parle bien des packages java.rmi et java.rmi.server. Et le fait que seul java supporte ce protocole binaire n'enlève rien à ses qualités (entre autre la simplicité par rapport aux RPC) ni à ses défauts (mécanisme de nommage).
Maintenant, c'est parfaitement vrai qu'il existe des classes permettant de gerer les messages de SOAP (javax.xml.soap, javax.rpc.*) mais quelque part (ça n'engage que moi), on sent que tout ça a été implémenté parce qu'il y'avait de la part de programmeurs java l'envie de respecter des protocoles standards plutôt que uniquement rmi. Surtout parce qu'aucun système objets distribué ne permettait de travailler avec java à part peut-être Corba au prix d'une configuration de celui-ci
</digression aussi>
[^] # Re: Défiance ?
Posté par Nelis (site web personnel) . Évalué à 3.
Je ne suis pas d'accord ... RMI existe surtout en tant que protocole efficace pour faire du Java <-> Java. Mais Java supporte CORBA, SOAP & co. Je n'ai jamais senti de la part de Sun une envie de pousser RMI comme "protocole qui doit remplacer les autres" ... Simplement pour faire des objets distribués en Java, RMI est plus simple et plus performant ...
# Grmmbl...
Posté par core . Évalué à -5.
Je suis tout à fait engagé contre Microsoft mais je pense que la meilleure façon de s'en débarasser c'est d'agir, et pas de se masturber la neurone en constatant un soi-disant "très grave échec".
C'était juste un mot d'humeur de quelqu'un qui serait assez heureux de trouver sur LinuxFR des news aussi abondantes et de qualité que sur Slashdot...
[^] # Re: Grmmbl...
Posté par Benoît Sibaud (site web personnel) . Évalué à 6.
Puisque l'on en est à l'humeur, n'hésite pas à en proposer (si possible sans trop de fautes, parce que ça facilite le boulot des modéros merci).
Si vous trouvez qu'il n'y a pas assez de nouvelles techniques, idem, proposez-en.
Rappel : les modéros modèrent. Les proposants proposent.
[^] # Re: Grmmbl...
Posté par Sebastien . Évalué à 8.
J'ose esperer qu'il s'agit bien là d'ironie (après tout, on est vendredi). Car la qualité des news de slashdot est plus que discutable. Je ne parle même pas des trolls à n'en plus finir qui peuplent les commentaires.
/. est victime de son succès, mais ce n'est plus la qualité qui prime. Il suffit d'ailleurs de voir le nombre de fois ou les news doivent être remaniée après leur publication tellement elles sont imprécises ou carrements fausses (cf "slackware is dead", c'était le pompom).
Bref, quand à linuxfr, pour augmenter la qualité des news... et ben on n'a plus qu'à se bouger le cul pour que ce soit encore meilleur.
[^] # Re: Grmmbl...
Posté par qdm . Évalué à 10.
Effectivement, dire que c'est un très grave échec, c'est un raccourci. Mais je pense que si par exemple dans 10 ans Microsoft est sous les 50 % de PdM, ce moment aura été le déclic. La première fois qu'un grand nombre de sociétés ont refusé les avantages d'un projet Microsoft en pensant au risque d'éviction.
Donc ce front là reste à surveiller mais à mon sens, il a perdu son importance stratégique pour quelques temps. Les 5 axes ou il faut se battre sont :
1° Améliorer continuellement les softs libres
2° Eduquer les utilisateurs
3° Exercer une pression pour que le réglement du procès antitrust soit décent et pas la mascarade proposée.
4° Se battre contre les brevets logiciels
5° Se battre contre le DMCA
# C'est un changement d'utilisation de .NET, pas un abandon
Posté par darkleon (site web personnel) . Évalué à 10.
Par contre Microsoft vendra une solution "HAILSTORM" pour chaque entreprise afin que les fichiers clients soient gérés en interne à chaque entreprise.
Donc le boulot de Microsoft n'est pas perdu, ils vont le vendre différement, au lieu d'avoir un "HAILSTORM" Microsoft, on aura des centaines de mini-hailstorm.
[^] # Re: C'est un changement d'utilisation de .NET, pas un abandon
Posté par kesako . Évalué à -3.
Que preferez vous chers confreres ?
(allez hop -1)
[^] # Re: C'est un changement d'utilisation de .NET, pas un abandon
Posté par Jak . Évalué à 2.
Ouais, ouais, ouais ... C'est quoi l'avantage par rapport à un montage NFS/Samba ou une connexion X11/Citrix à un serveur d'appli dans ce cas ?
Je demande, hein, c'est tout ...
[^] # Re: C'est un changement d'utilisation de .NET, pas un abandon
Posté par Wi][ish . Évalué à 4.
MicroSoft semble justement vouloir faire tomber Samba, (cf la news http://linuxfr.org/2002/04/12/7917,0,0,0,1.php3(...) )
Ca pourait faire partie de la même stratégie.
[^] # Re: C'est un changement d'utilisation de .NET, pas un abandon
Posté par Jak . Évalué à 5.
J'évoque en fait 4 possibilités :
-Un serveur d'appli Unix et des terminaux X.
-Un serveur d'appli Windows et des terminaux Citrix
-Un serveur de fichiers Unix et un montage par NFS des répertoires utilisateur
-Un serveur de fichiers Windows et un montage par le protocole qui va bien (CIFE ? ça serait Samba si les clients étaient des Unix) des répertoires utilisateurs.
Ce que je veux savoir, c'est par rapport à une de ces 4 solutions (dont 2 sont 100% Microsoft), que peut apporter .NET ? De concret, j'entends ...
# Mouais ...
Posté par Jak . Évalué à 10.
Quelle proportion de gens cela touche-t-il ? Déjà, il faut avoir un accès à Internet généralisé, et avoir un débit conséquent (bah oui, un .DOC, ça monte vite à 1 ou 2 Mo). Si il faut passer un quart d'heure à chaque fois avant de commencer à bosser dessus, je ne suis pas sûr que ça ait du succès.
Et puis qui a réellement besoin de pouvoir accéder à ses documents de n'importe où dans le monde ? Un représentant ? Il a en général un ordinateur portable avec ce qu'il faut dessus.
Ou alors, dans le cadre d'une grosse société, avec un réseau intranet important, à travers un pays ? Là, je ne suis même pas convaincu qu'un terminal X/Citrix ne puisse pas faire l'affaire pour se connecter au serveur d'appli central. Voire, avec simplement un montage NFS/Samba de son propre répertoire dès le login d'un utilisateur où qu'il soit sur une machine de l'intranet. En gros, il va falloir à Microsoft convaincre ce type d'utilisateur (ça existe, en plus) de l'intérêt de ce système.
Personnellement, je n'arrive pas à voir ce qu'il y a de si formidable dans cette technologie, et surtout de réellement utile.
Peut-être, justement, que pour mettre en place des projets de cette envergure, avec des protocoles à définir, sans assurance qu'il y ait un marché pour cela, il vaut mieux laisser ça au Logiciel Libre, comme .GNU par exemple. Je doute qu'il y ait un soucis de rentabilité, derrière .GNU, et si ils parviennent à quelque chose d'utilisable, alors, en reprenant les protocoles, chacun pourra proposer une solution à la Hailstorm.
Évidemment, le problème, c'est que c'est ouvert, et donc que Microsoft ou Sun ou un autre ne peuvent pas proposer simplement leur solution propriétaire.
Un peu come TCP/IP, finalement...
[^] # Re: Mouais ...
Posté par kesako . Évalué à 0.
Je ne vois pour l'instant qu'un seul but : vendre de nouvelles machines de nouveaux routeur, reseaux etc... et de nouveaux logiciels.
[^] # Re: Mouais ...
Posté par Jak . Évalué à 3.
Pour une petite PME, un serveur d'appli, et tous les employés sur des TX, ça ne fait qu'une machine à administrer, c'est beaucoup plus simple.
.NET, ça me fait aussi penser aux opérateurs de téléphonie mobile qui veulent amener Internet aux téléphones portables (déjà avec le GPRS) : à qui ça va servir vraiment (sans compter les 2 ou 3 geeks fortunés prêts à payer 1 Euro le Mo téléchargé ...) ? Je parle d'une utilisation courante, bien sûr. Comme le WAP, maintenant que j'y songe ...
[^] # Re: Mouais ...
Posté par jeanmarc . Évalué à 10.
Non, non! Il faut UN PC nouvelle génération pour chaque employé et un maximum de serveurs avec écrans plats 17'' pour que les admins puissent faire leur boulot et gérer les mails et le partage de fichiers de façon optimale.
Quoi l'innovation? Quoi la logique? Quoi l'investissement intelligent?
Je te parle de toute une économie florissante et toi, tu rales pour des broutilles.
Comment ça, microsoft se rince au passage à chaque achat de nouveau pc? S'ils ne faisaient pas des systémes de plus en plus performants et répondant aux besoins des utilisateurs (la dame de pique en réseau) et que tout le monde utilisaient des systèmes tirant parti des performance des pcs, ils ne s'en vendraient pas autant! Normal qu'ils s'en mettent un peu sous le coude!
Pff, un serveur central et des terminaux X! Y'a qu'un linuxien pour penser à des trucs aussi iiréalisables! La seule solution valable est .NET.
Ca permettra à tout le monde d'avoir ses propres fichiers et mêmes ses propres applications sur la machine de quelqu'un d'autre. Bon, bien sûr il faudra acheter de nouveaux serveurs et que tout le monde soit connecté mais c'est ce qui fait avancer l'économie! De plus, on peut compter sur l'expertise de microsoft pour que notre confidentialité soit respectée grâce à l'engagement de Bill Gates de faire de la sécurité prioritairement au niveau sécuritaire!
Vous ne comprenez même pas ce que Hellstorm aurait pû nous apporter en matière de facilité d'achat de nouveau pc directement sur le net et pour empêcher les petits hackers de nous voler nos cartes bleues sur le net!
[^] # Re: Mouais ...
Posté par patton . Évalué à 2.
[^] # Re: Mouais ...
Posté par Pol . Évalué à 2.
Par exemple, tu peux acheter en ligne, chez des marchands différents sans avoir à fournir d'info CB, de password ou autre a chaque fois. Et surtout tu peux utiliser ce compte avec ton téléphone mobile (WAP), ou ton PDA, ou depuis n'importe quel ordinateur sur internet et tout est centralisé et homogène.
En bref (du point de vue maketing) c'est le rève : un protocole unique pour les acteurs professionnels, un accès unique, homogène et sûr (marketing, j'ai dit !) pour les utlisateurs ce qui pourrait permettre le démarrage du e-commerce ; et enfin (surtout) une colossale vache à lait pour celui qui parviendra à s'imposer sur le créneau.
Pas la peine de de s'attarder sur le côté discutable autant pour la sécurité que pour la confidentialité de fournir ses infos personnelles à krosoft, tout le monde est déjà convaincu. Par contre le concept se défend tout à fait, et je suis persuadé qu'on le verra resortir dans pas longtemps (d'ailleur je crois me souvenir qu'il y a un projet opensource de lancé)
mes .2 ¤ sur la question
[^] # Re: Mouais ...
Posté par Jak . Évalué à 1.
C'est d'ailleurs pour ça que j'ai déjà dit quelque part qu'un projet OpenSource (.GNU) a plus de chances de s'imposer dans la mesure où il n'est pas prévu pour être rentabilisé, et que le jour où le marché sera prêt à accepter ces choses, il sera là, et il ne sera pas imposé de force.
[^] # Re: Mouais ...
Posté par Pol . Évalué à 1.
Et ils pairaient volontier pour ce service.
# Liens en français
Posté par anonyme512 . Évalué à 2.
et
http://fr.news.yahoo.com/020412/85/2jp9z.html(...)
# dontnet-fr.org
Posté par vrm (site web personnel) . Évalué à 0.
[^] # Re: dontnet-fr.org
Posté par kesako . Évalué à -1.
[^] # Re: dontnet-fr.org
Posté par Jak . Évalué à -4.
Je crois que le gars qui s'occupe du site était venu expliquer son point de vue ici, à l'époque. Pas complètement obtu, ce qui l'intéressait, c'était la technologie .NET, un peu comme Miguel DeIcaza, finalement.
[^] # Re: dontnet-fr.org
Posté par Christophe Lauer . Évalué à -4.
[^] # Re: dontnet-fr.org
Posté par Dugland Bob . Évalué à -1.
La grande blague :
http://www.dotnet-fr.org/intro_dotnet_tmr.php3(...)
C'est con pour un mec qui veut vendre des technos Microsoft !
Il a pas compris en quoi c'était génial (sur certains points) mais pas super nouveau.
[^] # Re: dontnet-fr.org
Posté par DotNETfr . Évalué à -2.
Euh, vas-y, explique-moi. Je n'ai pas compris *quoi* selon toi ?
[^] # Re: dontnet-fr.org
Posté par Dugland Bob . Évalué à 2.
Je ne vois pas *pourquoi* la CLR le ferait alors que la sémantique du langage (ou le compilo pour les langages de bas niveau) peut s'en occuper.
"Au final, que représentent 10% de pénalité sur les performances si ceci permet dobtenir une fiabilité et une disponibilité aujourdhui non atteignables."
Les 10% sortent d'un chapeau que je ne veux même pas voir (c'est super variable en fait voir : http://www.bagley.org/~doug/shootout/(...) ). D'autre part, parseonne n'a attendu .NET pour développer des applications fiables de transactions financières en Smalltalk.
C'est justement les applications utilisateur qui peuvent gagner (avoir un Word, un Autocad ou un Rose qui ne plante pas, le rêve).
L'intérêt que je trouve à la démarche est de répondre à la question : peut-on limiter la coloration d'une VM vers le langage qu'elle implante pour ensuite n'avoir qu'une seule instance des infrastructures dans le système ?
Cette démarche comporte un risque (dont Microsoft se fout) c'est de coincer les développeurs dans un langage particulier, en diminuant ainsi leur potentiel d'apprentissage.
[^] # Re: dontnet-fr.org
Posté par DotNETfr . Évalué à 0.
Je ne vois pas *pourquoi* la CLR le ferait alors que la sémantique du langage (ou le compilo pour les langages de bas niveau) peut s'en occuper.
C'est ok dans les cas courants, si on considère les cycles classiques de compilation/exécution. Mais avec .NET, il est possible de générer du code à la volée (cf. Code DOM).
"Au final, que représentent 10% de pénalité sur les performances si ceci permet dobtenir une fiabilité et une disponibilité aujourdhui non atteignables."
S'clair... ;-)) Je croyais avoir utilisé un conditionnel, du genre : "il semblerait que l'overhead ne serait que de l'ordre de 10%". Ma formulation est très mauvaise, c'est exact.
Peut-on limiter la coloration d'une VM vers le langage qu'elle implante pour ensuite n'avoir qu'une seule instance des infrastructures dans le système ?
Honnêtement, je crois vraiment que Microsoft a encouragé plusieurs sociétés/universités à "porter" une version de leur langage vers .NET (donc dans la CLR) pour servir de "preuve de concept" que des langages aussi différents que le Cobol Objet, Perl ou Eiffel pouvaient s'y exécuter, donc pouvaient y trouver tout ce dont ils ont normalement besoin.
Mais je peux être passé à côté de qquechose...
Au passage, pour ceux que ça intéresse, voici un lien vers un doc titré "Technical Overview of the Common Language Runtime (or why the JVM is not my favorite execution environment)". Ok, c'est sur le site de MS Research...
http://research.microsoft.com/~emeijer/Papers/CLR.pdf(...) (PDF)
CL
[^] # Re: dontnet-fr.org
Posté par Dugland Bob . Évalué à 2.
"il est possible de générer du code à la volée"
c'est normalement pas incompatible, mais j'ai pas vérifié dans le CLR. Faut que je me renseigne.
" Microsoft a encouragé plusieurs sociétés/universités à "porter" "
Je sais, mais je ne suis pas convaicu cette par cette démarche quelles concessions faut-il faire pour rentrer dans CLS ?
"It would be unfair to state that the CLI as it is now, is already the perfect multi-language platform."
En dehors de la prétention de cette phrase, je crains le pire.
"Cobol Objet, Perl ou Eiffel"
hem, j'aurais cité Haskell,O'Caml, clean, self, smalltalk (c'est déjà fait). Et les autres paradigmes que je ne connais pas encore.
Ceci dit, on pourra surtout mesurer la frontière de ce qui est faisable.
# Impossible abandon
Posté par Chadom (site web personnel) . Évalué à 1.
- L'identification
- Le payement en ligne (qui decule +/- de l'identification).
Les autres parties ne sont pas primordiales, mais celles-ci oui. Surtout qu'ils savent très bien que l'OS ne sera (n'est ?) plus le nerf de la guerre et ne sera peut-etre meme plus rentable vue la concurrence qui monte...
# Y'en a qui sont à la rue
Posté par Dugland Bob . Évalué à -9.
Personellement, l'intérêt que je trouve à .NET est surtout d'avoir une machine virtuelle géante (avec un vrai système de gestion de la mémoire) et une biblothèque de classes communes, ça va peut-être diminuer la bricole en C/C++ et tendre vers de vrais logiciel.
[^] # Re: Y'en a qui sont à la rue
Posté par Obsidian . Évalué à 6.
En ce sens, Unix est bien plus adapté à cette tâche que les OS de Redmond qui ne savent faire que ce pourquoi ils ont été conçus en usine.
Aujourd'hui les personnes qui ont failli passer à coté de l'Internet ("Internet n'est qu'un petit réseau habité que par des étudiants et des bidouilleurs: Pourquoi investir dans un créneau qui ne nous rapportera pas un centime de bénéfice ?" dixit Bill) et qui étaient incapables de produire un socket TCP/IP avant 1995 (Sous 3.11, c'est Trumpet Winsock, le favori, je ne me souvient pas que MS-TCP/IP existant déjà) voudraient nous expliquer comment ca marche ?
A croire que chaque jour, les illuminés de Redmond découvrent l'informatique ! C'était déjà le cas quand ils ont commencé le projet Windows en 1985. A cet époque, ils ont visiblement voulu produire un système "révolutionnaire" entièrement axé sur l'interface graphique, alors qu'au même moment le mac comme X-Window existaient déjà, ce dernier étant capable de gérer l'affichage à travers une connexion distante ! Moralité: Ils ont produit un système entièrement dépendant de l'interface graphique, donc congénitalement limité.
Ils semble aujourd'hui que le destin remette çà: "Et que je parle de com, com+, dcom, .net et tout qui vont soi-disant uniformiser tous les échanges entre les logiciels", alors qu'il n'existe même pas sous NT, en 2002, une dizaine de commande que l'on puisser piper pour combiner les effets".
Pour terminer, je dirai que .net, com etc va bien finir par fonctionner car ils rendent - Windows - meilleur qu'il ne l'est, même si cela n'est en rien comparable avec ce qui existe à coté, et aussi parce que Microsoft usera encore de son poids et de son marketing surdéveloppé pour le vendre.
Dans "Visite guidée du secteur DOA", pour les initiés, on pouvait lire "Prenez des frites MacDonald, elles ont toutes la même longueur, et rentrent parfaitement dans leur cornet. qu'importe si elles ont un vieux goût de buvard". L'informatique suit le même concept. Tout un marché parallèle s'est développé autour des nouvelles technologies et aujourd'hui, l'important est de faire fonctionner ce marché parallèle, les technologies elles-mêmes ne sont qu'un prétexte.
Mais il est clair que, tout comme Windows n'était à la base que la réponse -tardive- de Microsoft à ce que devenait l'informatique, .Net est un effort visant à obstruer la voie ouverte au préalable par Corba ou Java.
Aujourd'hui les applications sont tellement lourdes que seul 10% du temps système utilisé sert à la tâche elle-même, tout le reste étant perdu en overhead. Si tu prends un programmeur contemporain, que tu lui donne une machine de l'époque, et que tu lui demande de réaliser un logiciel de l'époque, crois-tu qu'il en sera vraiment capable ?
En ce sens, on assiste à un faux progrès.
Conclusion: Revois ta copie.
[^] # Re: Y'en a qui sont à la rue
Posté par Dugland Bob . Évalué à 4.
le vrai système de gestion de mémoire, c'est un système de GC évolué, beaucoup plus souple que le système de ma grand-mère malloc/free
diminuer la bricole en C/C++ : je vois pas le rapport avec Windows, les noyaux sont coincés entre ADA et C.
Je vois pas le rapport entre machine virtuelle géante et ordinateur universel, relis la phrase, le but serait d'avoir dans le système une seule instance de chaque infrastructure nécessaire pour faire tourner un langage de haut niveau. Et l'intégration de ces p*tains de tags-bit dans les procs x86(désolé, cette absence m'énerve !).
Unix n'a rien qui se rapproche de près ou de loin avec le CLR(ou alors je l'ai pas vu) et ça ne fait en rien de Windows un meilleur OS (pour quelle application d'abord ?)
Microsoft a préféré privilégier les échanges DDE et OLE entres applications plutôt que le pipe. J'ai pas d'avis sur la question.
Le fait que tu croies que cette idée vienne de Microsoft : 1) cette idée (le CLR et une bibliothèque de classes commune) vient de Smalltalk entre 1972 et 1980.
2) n'est pas suffisant pour en faire une mauvaise idée.
Tendre vers de vrais logiciels : c'est pas clair comme phrase, c'est plutôt tendre vers une meilleure qualité, je ne développe pas pour 2 raisons : tu n'as pas l'air d'avoir une culture énorme du sujet (sinon, tu aurais compris l'allusion) et je suis en désacord total avec une mode en vogue sur comp.objects (remplacer le typage par des tests) mais plutôt en phase avec comp.lang.functional.
# Un pitit lien avec du retard
Posté par Guillaume BARON . Évalué à 0.
http://www.dotgnu.org/(...)
Vala qui est fait !
Oui, je sais j'arrive un peu tard, mais vieux motard que jamais ;-)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.