Comme je l'ai deja dit, il y a des raisons pratiques a faire cela, en particulier le fait que comme ils ont pas vu venir l'importance du matos a base de ARM, ils sont partis tres tard dans la course et donc pour rattraper le retard autant mettre le drapeau jaune et ralentir la course.
Mais t'as la science infuse toi dis donc.
Tu crois que Microsoft a commencé à supporter ARM la veille de faire leur démo ? Tu crois qu'ils sont assez con pour ne pas continuer en interne à supporter plusieurs plateformes hardwares, au cas où Intel leur joue un mauvais tour ?
Apple a switché du jour au lendemain du ppc au x86, tu crois qu'ils le proposaient pas avant pour des raisons techniques ou simplement pour des raisons commerciales ?
Tu crois tout savoir alors que tu te contente de ce que tu lis au hasard du net : tu bosses pas chez MS (et moi non plus), tu sais pas ce qu'ils font en interne. Mais le passé a montré qu'ils savaient supporter d'autres plateformes (Itanium par exemple) et qu'ils ont déjà une bonne connaissance/maîtrise de ARM (Windows Mobile, Windows Phone).
Au lieu de s'appuyer sur un standard techniquement abouti, bien défini,
Le problème, c'est que le standard techniquement abouti et bien défini, on l'attend toujours. La roadmap d'HTML5 ne prévoit rien d'abouti avant 2014 (!!!)
De plus les standards en question sont arrivés en tant que réponse à une techno propriétaire (Flash) : Macromedia/Adobe n'avait donc pas le choix d'utiliser y'a 10 ans un standard qui sera abouti dans 3 ans dans le meilleur des cas.
Idem pour Microsoft : y'a 5 ans, HTML5 était loin, très très loin : ils avaient le choix entre attendre 2014 pour concurrencer Flash ou combler le vide concurrentiel. Le résultat est là, Silverlight existe depuis 2007.
Bref, ce n'est pas une question de choix, bien au contraire : ce ne sont pas les standards qui poussent l'innovation mais bien des acteurs isolés. Rien n'empêche ces mêmes acteurs de manger à tous les rateliers le jour où le standard devient mature. C'est ce que fait Microsoft et ce que va sûrement faire Adobe.
Comme ça les gens ont le choix entre un standard qui marche partout, mais sans SDK, et un truc breveté, propriétaire, dispo sur quelques plateformes, mais avec un beau SDK.
Les gens ont le choix entre un truc non abouti, défini par nature comme un ensemble de compromis sans innovations, sans outils pour l'utiliser, et un truc clé en main qui marche aujourd'hui. Oué les gens sont pragmatiques.
Silverlight est la plateforme officielle d'application pour Windows Phone : toutes les applications disponibles utilisent cette plateforme, seule et unique disponible.
Silverlight se base sur .NET qui, by design, propose une couche d'abstraction complète avec la plateforme matérielle : Windows Phone est une première validation des choix stratégiques fait autour de .NET, le passage à ARM pour Windows va dans la même direction.
Silverlight sur Arm, avec les ambitions du prochain windows, spa gagné.
C'est vrai, c'est pas comme si les téléphones Windows Phone tournaient sur des processeurs ARM.
Qu'est ce qu'il faut pas entendre comme conneries.
que silverlight [...] et .Net vont disparaitre du prochain windows ...
Silverlight n'a jamais fait parti de Windows, je vois pas comment il va en disparaître.
.NET fait parti de Windows 8, suffit de tester les builds qui trainent sur le NET.
Les faits et Albert, ca a toujours été à l'opposé.
En même temps il ne parle pas de progrès mais de modernité, pour mieux attirer le client : plus de confort (et donc plus de surface, sièges larges, climatisation), des écrans plus grand, du son DoblyTHXDigitalDeLaMort, qualité numérique, de la 3D (ou pas).
Si on suit ton raisonnement, on ne fait jamais d'investissement.
Déjà c'est une architecture micro-kernel, les drivers ne sont pas dedans : autant que le kernel soit le plus fiable possible, et donc écrit dans un langage plus "sûr". L'idée étant de limiter le C et l'assembleur au strict minimum (bootstrap, HAL). Niveau sécurité, c'est toujours ça de gagné.
Ensuite l'intérêt est de faire tourner le kernel dans le même environnement que les process, pour éviter de le coût des changements de contexte : celà suppose donc d'avoir le même niveau de confiance dans les process que dans le kernel, et donc les mêmes technos (VM/C#/Sing#).
. Qu'on le veuille où non, les drivers utiliseront toujours des pointeurs et c'est dans les drivers que les failles seront trouvées.
Dans Singularity, les drivers sont écrits en Sing# (dérivé de C#) : c'est un langage type-safe qui t'offre un certain nombre de garanties à la compilation contre les bugs les plus classiques, et une vérification de tous les accès mémoires, même par pointeur, afin de t'assurer que la mémoire n'est jamais corrompu (les explications détaillées, notamment à partir de la section 3 dans le doc http://www.cs.kuleuven.ac.be/conference/EuroSys2006/papers/p177-fahndrich.pdf ). Un driver tournant donc dans un environnement "managé", il est isolable, il peut exploser dans son coin, il emporte pas le kernel avec lui dans sa chute.
Sur ce point, l'aspect centralisateur des dépôts est un bon point car les vérifications de l'un participe aux autres. Et puis il est toujours possible de faire tourner tous les analyseurs statiques qu'on veut sur les sources.
Attention, les vérificateurs statiques tournent sur le bytecode et pas sur le code source : bref, chaque "binaire" est vérifié et validé par le kernel lors de son installation. On s'en tapes donc pas mal du côté centralisateur, ce qui compte c'est d'imposer une vérification par le kernel des binaires (qui ne contiennent aucun code natif et invérifiable donc).
Le seul véritable problème dans l'approche de Singularity, c'est l'absence totale de compatibilité avec les softs existants qui produisent du code non vérifable (du code natif). Celà peut paraître rédhibitoire, mais en même temps sur des plateformes "nouvelles" (exemple Windows Phone 7), ils ont franchit le pas : toute application doit être écrite dans du code vérifiable, et vérifier avant mise sur le market.
D'après la doc pointée ci-dessus, ils réfléchissent à intégrer la protection "hardware" à base de ring pour sandboxer les applis natives.
Faut bien voir que tu sors que des phrases approximatives qui font très largement pensé que tu ne sais pas de quoi tu parles : je te parles des WPF/Siverlight/AjaxControl Toolkits, qui sont 3 projets distincts de composants graphiques pour 3 technos Microsoft :
et tu sors un truc vague :
* "les toolkits silverlight : en cherchant bien il y a là encore que des tout petits trucs inutilisable dans un autre cadre". Tu parles des 3 toolkits ou tu parles que du toolkit Silverlight ? On sait pas. Moi j'ai compris que tu parlais des 3 (vu que j'ai cité les 3 simultanément et que t'as employé le pluriel) et que tu disais qu'ils étaient pas utilisable en dehors du toolkit Silverlight. D'où ma réponse sur le fait que les 2 autres toolkits sont également utilisables, puisqu'utilisés, en WPF et en ASP.NET.
Ca ne change de toute façon rien sur le fait que je trouvais que ton niveau de discours puait : tu répondais totalement à côté de la plaque comme tu l'as reconnu.
Si tu voulais réagir uniquement sur ma conclusion, cette réflexion est hors sujet
Pourquoi ce "uniquement" ? Je trouvais pertinent d'ajouter une liste plus complète pour compléter le débat.
Mais bon, si assume parfaitement les conneries que tu dis
Oui j'ai un principe, quoique je dises, j'assumes :)
la même erreur que toi puisque je me suis concentré sur la deuxième partie de ton commentaire
... En reprenant les exemples de la première partie. Et non, je n'ai pas fait la même erreur que toi : j'ai effectivement réagit sur ta "petite conclusion", et c'est bien là dessus que je voulais réagir. Non pas pour contredire ton analyse de la première partie, mais plutôt pour compléter avec d'autres exemples pour modérer ta conclusion.
Et plus qu'insultant tu déformes volontairement mes propos en tronquant de manière flagrante les citations juste au point qui t'arrange pour me faire dire l'opposé de ce que j'ai dit.
J'ai tronqué quoi ? ton "en dehors de Silverlight" ? Tu as cité toi même l'exemple qui te contredis : le DLR, il est utilisable en dehors de Silverlight, à commencer sur le framework .NET "standard" et bien sûr sur Mono.
Que veux-tu que je te dises, j'assumes totalement tout ce que j'ai dis, je n'ai pas l'impression d'avoir déformé quoique ce soit.
Reprenons depuis le début :
Ta théorie : Microsoft n'assume pas ses projets Open-Source et ils semblent faits de manière externe sans ref à Microsoft.
Ensuite je te liste des projets qui te montre le contraire.
Si, si et si : il reste encore suffisamment pour que ce soit inutilisable en dehors de ASP.NET.
J'ai jamais dit le contraire, c'est même mon constat initial : c'est basé sur les technos Krosoft,en l'occurence le pipeline HTTP. Je te rappelle ton argumentaire initiale :
* c'est un tout petit truc dans ASP.NET : non seulement l'argument ne montre pas que c'est un projet non assumé par Microsoft, c'est donc à côté de la plaque, et en plus c'est faux puisqu'il remplace (et non fait abstraction) les 3/4 d'ASP.NET lorsqu'il est utilisé.
* c'est utilisable que sur du proprio : là encore, ca ne démontre absolument pas que c'est non assumé, et c'est totalement faux puisqu'utilisable avec Mono qui n'est pas proprio.
D'une, VS2010 n'est sorti qu'il y a un an mais F# existe depuis 9 ans, et pour l'instant il reste complètement obscure.
Là encore, tu refuses d'admettre mon exemple : quelque soit le succès de F#, son inclusion dans VS2010 montre qu'il est totalement assumé par Microsoft.
je n'ai jamais dis que les logiciels open-source de Microsoft sont juste des trucs annexes développés par un employé seul dans son coin et je te met au défi de trouver un endroit où j'ai pus le dire. Tu commences à m'énerver à déformer volontairement tout ce que je dis.
Je laisserai les gens juger par eux même de la déformation en te citant tout simplement :
c'est très bien que Microsoft fasse de l'open source, mais ça ne semble pas être assumé. Tous les trucs open source un peu intéressant de Microsoft donne l'impression d'être fais de manière externe avec le moins de référence possible à Microsoft.
Puis :
En même temps mono est une implémentation de dot.net, donc en effet c'est utilisable dessus mais tu sais pertinemment ce que je voulais dire
Oui tu veux dire tout sauf admettre que Microsoft fait des projets Open-source totalement assumés. Tu cherches donc à critiquer les projets en question, soit en minimisant leur intérêt (cf toolkits), leur dépendance au proprio (cf. ASP.NET MVC), ou le côté obscure (cf. F#).
D'où ma critique acerbe initial ("ton niveau de discours pu") : tu ne démontres rien en rapport avec ce à quoi tu cherches à répondre (le côté assumé de certains projets MS). Tu te contente de chercher pour chaque exemple une critique négative pour minimiser mes arguments.
c'est juste que toi tu t'en sers beaucoup moins puisqu'il est caché par MVC.
Non non et non : ASP.NET MVC court-circuite une grande partie de l'environnement ASP.NET. Ce n'est pas une surcouche de l'ancien ASP.NET : tout le moteur de rendu des pages est mis totalement de côté ainsi que tous les contrôles qui vont avec : clairement ne reste que le pipeline HTTP.
des produits majeurs en F# j'en connais pas beaucoup. Est-ce que tu peux m'en citer ?
Là n'est pas la question : VS2010 n'est sorti il n'y a qu'un an. Le fait est que Microsoft croit en F#, et le fait qu'ils l'ait mis open-source contredit l'affirmation selon laquelle les logiciels "open-sources" de Microsoft sont justes des trucs annexes développés par un employé seul dans son coin.
Je maintient que ces toolkit sont inutilisables en dehors de silverlight.
Le Silverlight Toolkit est parfaitement utilisable sous Moonlight.
Tu peux me donner un pointeur qui appuie le fait que le DLR soit utilisable avec mono ?
j'ai dit qu'ils étaient inutilisables en dehors de Silverlight ou ASP.NET c'est-à-dire qu'ils n'ont pas d'utilités pour d'autre projets open source et c'est complètement différent.
Ben si, ils sont directement utilisables et utilisées par Mono, autre projet open-source.
Comparer ça aux milliers de lignes nécessaires dans l'OS pour arriver à se passer du concept de ring, c'est osé ;)
Pas tant que ça :
* même simple, le concept de ring reste "hardware" : en cas de faille, t'es pas dans la merde. La simplicité ayant pour seul avantage de diminuer la probabilité, son apparition est critique puisque non corrigeable.
* même simple et non buggé, le concept de ring ne résoud rien s'il y a un bug dans le kernel à travers un appel système : celui-ci peut être exploité et obtient un accès root, ce qui supprime tout le gain de fiabilité offert par la simplicité du ring.
* la "simplicité" a un coup non négligeable (task-switching), qui devient de plus en plus problématique dans un contexte d'architectures et de softs multi-threadés.
Singularity tente une approche différente, l'avenir nous dira si c'était la bonne solution, mais sur le papier c'est pas plus abhérent que le ring, et comparable sur le plan de la sécurité :
* pas d'utilisation des ring hardware : en cas de bug, ca reste patchable. Et puis portable, on le voit aujourd'hui, les architectures CPU bougent.
* pour limiter les bugs dans le kernel, utilisation d'un langage beaucoup plus sûr (Sing# : environnement managé, type-safe, programmation par contrat).
* pour limiter les programmes "dangereux", aucun code natif autorisé, que du code vérifiable ET vérifié avant toute exécution (à l'installation).
* Effet de bord : pas d'utilisation des rings, donc coût de task-switching limité.
Les OS actuels sont "by-design" très mal conçu au niveau sécurité : on fait tourner le code et on prie pour n'avoir laissé aucune faille de sécurité dans les nombreux appels systèmes, qui sont eux-même écrits dans un langage "by-design" nul au niveau sécurité (le langage C). Sans parler des impacts en userland sur les données utilisateurs qui sont difficilement maîtrisables.
Singularity a une approche totalement différente :
* on vérifie en amont que le soft n'est pas dangereux
* on l'exécute dans le contexte d'une machine virtuelle en cas de bug dans l'étape précédente
* on impose un modèle de machine virtuelle qui limite grandement les bugs involontaires des programmeurs pouvant conduire à des failles de sécu.
Kedal, quand tu fais un site en ASP.NET MVC, tu mets de côté la plus grosse partie d'ASP.NET pour ne garder que le pipeline HTTP, bref, tout l'inverse de ce que tu racontes.
◦F# : Devenu libre il y a 6 mois seulement après 8 ans d'existence sans avoir vraiment décollé, c'est ça dernière chance...
En gros t'as pas d'argument. F# est inclu, en standard, dans Visual Studio. Même IronPython et IronRuby n'ont pas eu ce plaisir "de la dernière chance" d'être intégré dans un produit avec une roadmap de maintenance supérieur à une Ubuntu LTS.
◦les toolkits silverlight : en cherchant bien il y a là encore que des tout petits trucs inutilisable
Ton niveau de discours pu : ces toolkits sont tellement inutilisables qu'ils sont utilisés par les 3/4 des applications dans les dites technos.
qui non donc aucune utilité.
Tu sais pas de quoi tu parles, tu n'a jamais développé dans ces environnements. Sinon tu saurais que les toolkits dont je parles sont très très largement utilisés.
sauf qu'il est à peu près impossible de le sortir de silverlight pour l'utiliser de manière indépendante sur une autre implémentation du CLR.
Le DLR se base sur... le CLR, qui est un standard. C'est tellement impossible d'utiliser une autre implémentation que Mono y arrive : t'as fini de raconter des conneries ou t'en a toute une valise ?
Tu juges à l'emporte pièce, sans connaître ce dont tu parles, avec comme seul objectif que d'appuyer ton discours. Tu affirmes, dénigres, sans une once d'argumentation ettayée d'expérience ou de référence, là où une simple recherche google te montre que ce qui te semble impossible ou inutilisable s'avère totalement contredit par les faits.
Par contre, à vous aussi d'être raisonnable dans vos propos.
C'est ça que je trouve scandaleux de la part d'une équipe de sécurité, avoir une confiance aveugle en son système au point de faire tourner tout programme en ring0.
En même temps c'est tout aussi scandaleux de faire confiance aux ring qui s'appuie sur du matos tout aussi potentiellement buggé... sans être patchable. Tu fais quoi demain si tu te retrouves avec une faille de sécu énorme dans une génération de proc grand public ? Le rôle de base d'un OS c'est de faire abstraction du matos, l'idée d'une sécurité qui fait abstraction de mécanisme hardware est donc tout à fait pertinente.
Pour moi, un pourrait potentiellement arriver si les étoiles sont alignées etc... = arrive. Pour toi, c'est un pourrait arriver = peu probable.
Et vu qu'il est impossible de prouver que les étoiles ne seront jamais alignées, il est évident que la meilleur approche consiste uniquement à en diminuer la probabilité.
J'ai 2 réponses :
* qui dit OpenSource, dit souvent "communautaire", il est donc logique que ce soit des projets, même sponsorisés ou initiés par Microsoft, qui essaient de se "démarquer".
* il y a des projets OpenSource de Microsoft qui sont totalement "marqués, par exemple ASP.NET MVC, F# ou les "Toolkits" pour Silverlight, WPF et ASP.NET.
En fait la principale particularité c'est que c'est de l'open-source qui est tournée vers les technos Microsoft et pas les technos Linux. En même tant c'est super étonnant.
En tout cas, leur utilisation était très simple : pouf une url, un proxy typé généré automatiquement et j'utilise mon service au bout de 30 secondes.
Alors oui, fallait éviter de mettre la main dans le camboui et oui c'était vraiment pas efficace au niveau des quantités d'info qui circulent, c'était une hérésie par rapport au protocole HTTP, mais n'empêche qu'en tant qu'utilisateur (développeur qui utilise/produit un service), REST & CO reste une lourde régression en terme de productivité.
Enfin bon, c'est pas comme si XML & co n'était pas encore largement utilisés, même dans les technos "modernes" du logiciel libre.
J'ai une autre définition quand on cherche à émettre une opinion négative en propageant des infos douteuses ("soupçonne", "probablement", "fiasco"), et en plus c'est totalement objectif comme définition tellement c'est gros. Je vous laisse deviner :)
Extrait WIkipedia :
>"Il s'agit d'une technique rhétorique utilisée notamment dans la vente, le marketing, les relations publiques et le discours politique. Elle consiste à tenter d'influencer la perception de son audience en disséminant des informations négatives, souvent vagues et inspirant la peur. "
Microsoft fait depuis très longtemps partie du W3C, alors qu'ils se sont pendant très longtemps assis sur les normes qu'ils contribuaient à créer
Il faut surtout regarder à quoi a participé Microsoft dans le W3C : le W3C c'est pas uniquement (X)HTML + CSS. C'est aussi XML, XML Schema, XSLT, XPath, XQuery, WSDL, SOAP, etc. Autant de normes où Microsoft a été beaucoup plus actif, voir initiateur, et sans s'assoire sur le respect de ces normes.
Microsoft a clairement merdé en balançant il y a plusieurs années un support HTML totalement foireux qu'ils ont traînés comme un boulet jusqu'à aujourd'hui, mais y'a pas que ca au W3C.
Et surtout ça fera une belle démonstration du risque qu'on prend en faisant confiance à une seule entreprise qui travaille sur un langage et dont c'est pas le coeur de métier.
De quel risque parles-tu ? (à part pour les softs proprio comme MonoDroid ou MonoTouch). Mono est un logiciel libre dont Attachmate/novell est seulement le principal sponsor. Au pire le projet perd ce sponsor, et donc potentiellement des ressources pour faire vivre le projet, mais celà reste un projet libre qui peut continuer à vivre avec moins ou d'autres ressources.
En dehors de la communauté, il y a de toutes façon d'autres entreprises/sponsors qui travaillent avec Mono, y contribuent, et ont un intérêt à le maintenir : MainSoft, Unity, etc.
Il faut bien voir que Mono a existé avant Novell (initialement c'était Ximian), il n'y a pas de raison que le projet s'arrête avec Attachmate. Et officiellement, Attachmate a indiqué que les roadmaps produits étaient maintenues.
Si y'a un changement de principe, de 2 principes je dirais même :
1 technique : tu fais abstraction de la notion de machine physique
1 commercial : tu ne paies plus pour un espace et un CPU+RAM, tu paies ce que tu consommes, en temps de calcul et unité de stockage.
Pour comparer avec ton compilateur, c'est à peu prêt comme si tout à coup t'avais un IDE : ca change radicalement la façon de consommer le compilateur, de la même manière que le Cloud change radicalement de consommer de l'hébergement.
Ou prends si tu préfères la transition de l'assembleur au compilateur : apparition d'une abstraction qui offre du même coup tout pleins de fonctionnalités/services. Oui basiquement, ca n'est toujours qu'un moyen de produire un exécutable.
[^] # Re: Netflix
Posté par TImaniac (site web personnel) . En réponse au journal Quelqu'un a un clou?. Évalué à 0.
Url ?
[^] # Re: date création compte
Posté par TImaniac (site web personnel) . En réponse à la dépêche 13 ans de LinuxFr.org : entretiens avec les visiteurs (4). Évalué à 4.
http://linuxfr.org/users/nomorsad
Compte créé le 31/05/2003
[^] # Re: Netflix
Posté par TImaniac (site web personnel) . En réponse au journal Quelqu'un a un clou?. Évalué à 2.
Mais t'as la science infuse toi dis donc.
Tu crois que Microsoft a commencé à supporter ARM la veille de faire leur démo ? Tu crois qu'ils sont assez con pour ne pas continuer en interne à supporter plusieurs plateformes hardwares, au cas où Intel leur joue un mauvais tour ?
Apple a switché du jour au lendemain du ppc au x86, tu crois qu'ils le proposaient pas avant pour des raisons techniques ou simplement pour des raisons commerciales ?
Tu crois tout savoir alors que tu te contente de ce que tu lis au hasard du net : tu bosses pas chez MS (et moi non plus), tu sais pas ce qu'ils font en interne. Mais le passé a montré qu'ils savaient supporter d'autres plateformes (Itanium par exemple) et qu'ils ont déjà une bonne connaissance/maîtrise de ARM (Windows Mobile, Windows Phone).
[^] # Re: gros malin
Posté par TImaniac (site web personnel) . En réponse au journal Quelqu'un a un clou?. Évalué à 6.
Le problème, c'est que le standard techniquement abouti et bien défini, on l'attend toujours. La roadmap d'HTML5 ne prévoit rien d'abouti avant 2014 (!!!)
De plus les standards en question sont arrivés en tant que réponse à une techno propriétaire (Flash) : Macromedia/Adobe n'avait donc pas le choix d'utiliser y'a 10 ans un standard qui sera abouti dans 3 ans dans le meilleur des cas.
Idem pour Microsoft : y'a 5 ans, HTML5 était loin, très très loin : ils avaient le choix entre attendre 2014 pour concurrencer Flash ou combler le vide concurrentiel. Le résultat est là, Silverlight existe depuis 2007.
Bref, ce n'est pas une question de choix, bien au contraire : ce ne sont pas les standards qui poussent l'innovation mais bien des acteurs isolés. Rien n'empêche ces mêmes acteurs de manger à tous les rateliers le jour où le standard devient mature. C'est ce que fait Microsoft et ce que va sûrement faire Adobe.
Les gens ont le choix entre un truc non abouti, défini par nature comme un ensemble de compromis sans innovations, sans outils pour l'utiliser, et un truc clé en main qui marche aujourd'hui. Oué les gens sont pragmatiques.
[^] # Re: Netflix
Posté par TImaniac (site web personnel) . En réponse au journal Quelqu'un a un clou?. Évalué à 5.
Windows Phone 7 Développement d'applications
http://fr.wikipedia.org/wiki/Windows_Phone_7#D.C3.A9veloppement_d.27applications
Application Platform Overview for Windows Phone
http://msdn.microsoft.com/en-us/library/ff402531(v=VS.92).aspx
How to: Create Your First Silverlight Application for Windows Phone
http://msdn.microsoft.com/en-us/library/ff402526(v=VS.92).aspx
[^] # Re: Netflix
Posté par TImaniac (site web personnel) . En réponse au journal Quelqu'un a un clou?. Évalué à 7.
Silverlight est la plateforme officielle d'application pour Windows Phone : toutes les applications disponibles utilisent cette plateforme, seule et unique disponible.
Silverlight se base sur .NET qui, by design, propose une couche d'abstraction complète avec la plateforme matérielle : Windows Phone est une première validation des choix stratégiques fait autour de .NET, le passage à ARM pour Windows va dans la même direction.
[^] # Re: Netflix
Posté par TImaniac (site web personnel) . En réponse au journal Quelqu'un a un clou?. Évalué à 3.
# Albert, le plus fin analyste d'internet
Posté par TImaniac (site web personnel) . En réponse au journal Quelqu'un a un clou?. Évalué à 10.
Qu'est ce qu'il faut pas entendre comme conneries.
Silverlight n'a jamais fait parti de Windows, je vois pas comment il va en disparaître.
.NET fait parti de Windows 8, suffit de tester les builds qui trainent sur le NET.
Les faits et Albert, ca a toujours été à l'opposé.
[^] # Re: Absurdité des chiffres
Posté par TImaniac (site web personnel) . En réponse au journal vilains pirates . Évalué à 6.
En même temps il ne parle pas de progrès mais de modernité, pour mieux attirer le client : plus de confort (et donc plus de surface, sièges larges, climatisation), des écrans plus grand, du son DoblyTHXDigitalDeLaMort, qualité numérique, de la 3D (ou pas).
Si on suit ton raisonnement, on ne fait jamais d'investissement.
[^] # Re: Bonne interview
Posté par TImaniac (site web personnel) . En réponse à la dépêche Linus Torvalds : l’interview anniversaire des 20 ans du noyau. Évalué à 4.
Déjà c'est une architecture micro-kernel, les drivers ne sont pas dedans : autant que le kernel soit le plus fiable possible, et donc écrit dans un langage plus "sûr". L'idée étant de limiter le C et l'assembleur au strict minimum (bootstrap, HAL). Niveau sécurité, c'est toujours ça de gagné.
Ensuite l'intérêt est de faire tourner le kernel dans le même environnement que les process, pour éviter de le coût des changements de contexte : celà suppose donc d'avoir le même niveau de confiance dans les process que dans le kernel, et donc les mêmes technos (VM/C#/Sing#).
Dans Singularity, les drivers sont écrits en Sing# (dérivé de C#) : c'est un langage type-safe qui t'offre un certain nombre de garanties à la compilation contre les bugs les plus classiques, et une vérification de tous les accès mémoires, même par pointeur, afin de t'assurer que la mémoire n'est jamais corrompu (les explications détaillées, notamment à partir de la section 3 dans le doc http://www.cs.kuleuven.ac.be/conference/EuroSys2006/papers/p177-fahndrich.pdf ). Un driver tournant donc dans un environnement "managé", il est isolable, il peut exploser dans son coin, il emporte pas le kernel avec lui dans sa chute.
Attention, les vérificateurs statiques tournent sur le bytecode et pas sur le code source : bref, chaque "binaire" est vérifié et validé par le kernel lors de son installation. On s'en tapes donc pas mal du côté centralisateur, ce qui compte c'est d'imposer une vérification par le kernel des binaires (qui ne contiennent aucun code natif et invérifiable donc).
Le seul véritable problème dans l'approche de Singularity, c'est l'absence totale de compatibilité avec les softs existants qui produisent du code non vérifable (du code natif). Celà peut paraître rédhibitoire, mais en même temps sur des plateformes "nouvelles" (exemple Windows Phone 7), ils ont franchit le pas : toute application doit être écrite dans du code vérifiable, et vérifier avant mise sur le market.
D'après la doc pointée ci-dessus, ils réfléchissent à intégrer la protection "hardware" à base de ring pour sandboxer les applis natives.
[^] # Re: Enfumage
Posté par TImaniac (site web personnel) . En réponse au journal SL2011 : Entretien avec Alfonso, Directeur de la Stratégie Interopérabilité chez Microsoft. Évalué à -1.
Faut bien voir que tu sors que des phrases approximatives qui font très largement pensé que tu ne sais pas de quoi tu parles : je te parles des WPF/Siverlight/AjaxControl Toolkits, qui sont 3 projets distincts de composants graphiques pour 3 technos Microsoft :
http://wpf.codeplex.com/
http://silverlight.codeplex.com/
http://www.asp.net/ajax/ajaxcontroltoolkit/samples/
et tu sors un truc vague :
* "les toolkits silverlight : en cherchant bien il y a là encore que des tout petits trucs inutilisable dans un autre cadre". Tu parles des 3 toolkits ou tu parles que du toolkit Silverlight ? On sait pas. Moi j'ai compris que tu parlais des 3 (vu que j'ai cité les 3 simultanément et que t'as employé le pluriel) et que tu disais qu'ils étaient pas utilisable en dehors du toolkit Silverlight. D'où ma réponse sur le fait que les 2 autres toolkits sont également utilisables, puisqu'utilisés, en WPF et en ASP.NET.
Ca ne change de toute façon rien sur le fait que je trouvais que ton niveau de discours puait : tu répondais totalement à côté de la plaque comme tu l'as reconnu.
Pourquoi ce "uniquement" ? Je trouvais pertinent d'ajouter une liste plus complète pour compléter le débat.
[^] # Re: Enfumage
Posté par TImaniac (site web personnel) . En réponse au journal SL2011 : Entretien avec Alfonso, Directeur de la Stratégie Interopérabilité chez Microsoft. Évalué à 0.
... En reprenant les exemples de la première partie. Et non, je n'ai pas fait la même erreur que toi : j'ai effectivement réagit sur ta "petite conclusion", et c'est bien là dessus que je voulais réagir. Non pas pour contredire ton analyse de la première partie, mais plutôt pour compléter avec d'autres exemples pour modérer ta conclusion.
J'ai tronqué quoi ? ton "en dehors de Silverlight" ? Tu as cité toi même l'exemple qui te contredis : le DLR, il est utilisable en dehors de Silverlight, à commencer sur le framework .NET "standard" et bien sûr sur Mono.
Que veux-tu que je te dises, j'assumes totalement tout ce que j'ai dis, je n'ai pas l'impression d'avoir déformé quoique ce soit.
[^] # Re: Enfumage
Posté par TImaniac (site web personnel) . En réponse au journal SL2011 : Entretien avec Alfonso, Directeur de la Stratégie Interopérabilité chez Microsoft. Évalué à -1.
Reprenons depuis le début :
Ta théorie : Microsoft n'assume pas ses projets Open-Source et ils semblent faits de manière externe sans ref à Microsoft.
Ensuite je te liste des projets qui te montre le contraire.
J'ai jamais dit le contraire, c'est même mon constat initial : c'est basé sur les technos Krosoft,en l'occurence le pipeline HTTP. Je te rappelle ton argumentaire initiale :
* c'est un tout petit truc dans ASP.NET : non seulement l'argument ne montre pas que c'est un projet non assumé par Microsoft, c'est donc à côté de la plaque, et en plus c'est faux puisqu'il remplace (et non fait abstraction) les 3/4 d'ASP.NET lorsqu'il est utilisé.
* c'est utilisable que sur du proprio : là encore, ca ne démontre absolument pas que c'est non assumé, et c'est totalement faux puisqu'utilisable avec Mono qui n'est pas proprio.
Là encore, tu refuses d'admettre mon exemple : quelque soit le succès de F#, son inclusion dans VS2010 montre qu'il est totalement assumé par Microsoft.
Je laisserai les gens juger par eux même de la déformation en te citant tout simplement :
Puis :
Oui tu veux dire tout sauf admettre que Microsoft fait des projets Open-source totalement assumés. Tu cherches donc à critiquer les projets en question, soit en minimisant leur intérêt (cf toolkits), leur dépendance au proprio (cf. ASP.NET MVC), ou le côté obscure (cf. F#).
D'où ma critique acerbe initial ("ton niveau de discours pu") : tu ne démontres rien en rapport avec ce à quoi tu cherches à répondre (le côté assumé de certains projets MS). Tu te contente de chercher pour chaque exemple une critique négative pour minimiser mes arguments.
[^] # Re: Enfumage
Posté par TImaniac (site web personnel) . En réponse au journal SL2011 : Entretien avec Alfonso, Directeur de la Stratégie Interopérabilité chez Microsoft. Évalué à -2.
Non non et non : ASP.NET MVC court-circuite une grande partie de l'environnement ASP.NET. Ce n'est pas une surcouche de l'ancien ASP.NET : tout le moteur de rendu des pages est mis totalement de côté ainsi que tous les contrôles qui vont avec : clairement ne reste que le pipeline HTTP.
Là n'est pas la question : VS2010 n'est sorti il n'y a qu'un an. Le fait est que Microsoft croit en F#, et le fait qu'ils l'ait mis open-source contredit l'affirmation selon laquelle les logiciels "open-sources" de Microsoft sont justes des trucs annexes développés par un employé seul dans son coin.
Le Silverlight Toolkit est parfaitement utilisable sous Moonlight.
Première page de résultat Google me donne http://www.mono-project.com/Release_Notes_Mono_2.8
Le DLR est utilisable et distribué avec Mono : le DLR est utilisé par IronPython et IronRuby.
Ben si, ils sont directement utilisables et utilisées par Mono, autre projet open-source.
[^] # Re: Bonne interview
Posté par TImaniac (site web personnel) . En réponse à la dépêche Linus Torvalds : l’interview anniversaire des 20 ans du noyau. Évalué à 5.
Pas tant que ça :
* même simple, le concept de ring reste "hardware" : en cas de faille, t'es pas dans la merde. La simplicité ayant pour seul avantage de diminuer la probabilité, son apparition est critique puisque non corrigeable.
* même simple et non buggé, le concept de ring ne résoud rien s'il y a un bug dans le kernel à travers un appel système : celui-ci peut être exploité et obtient un accès root, ce qui supprime tout le gain de fiabilité offert par la simplicité du ring.
* la "simplicité" a un coup non négligeable (task-switching), qui devient de plus en plus problématique dans un contexte d'architectures et de softs multi-threadés.
Singularity tente une approche différente, l'avenir nous dira si c'était la bonne solution, mais sur le papier c'est pas plus abhérent que le ring, et comparable sur le plan de la sécurité :
* pas d'utilisation des ring hardware : en cas de bug, ca reste patchable. Et puis portable, on le voit aujourd'hui, les architectures CPU bougent.
* pour limiter les bugs dans le kernel, utilisation d'un langage beaucoup plus sûr (Sing# : environnement managé, type-safe, programmation par contrat).
* pour limiter les programmes "dangereux", aucun code natif autorisé, que du code vérifiable ET vérifié avant toute exécution (à l'installation).
* Effet de bord : pas d'utilisation des rings, donc coût de task-switching limité.
Les OS actuels sont "by-design" très mal conçu au niveau sécurité : on fait tourner le code et on prie pour n'avoir laissé aucune faille de sécurité dans les nombreux appels systèmes, qui sont eux-même écrits dans un langage "by-design" nul au niveau sécurité (le langage C). Sans parler des impacts en userland sur les données utilisateurs qui sont difficilement maîtrisables.
Singularity a une approche totalement différente :
* on vérifie en amont que le soft n'est pas dangereux
* on l'exécute dans le contexte d'une machine virtuelle en cas de bug dans l'étape précédente
* on impose un modèle de machine virtuelle qui limite grandement les bugs involontaires des programmeurs pouvant conduire à des failles de sécu.
[^] # Re: Non, mais oui
Posté par TImaniac (site web personnel) . En réponse au journal De mon objectivité et mon sens critique en lisant un lien de Tristan Nitot. Évalué à 5.
C'est interdit, cf article R417-10 II 1° du Code de la Route.
[^] # Re: Enfumage
Posté par TImaniac (site web personnel) . En réponse au journal SL2011 : Entretien avec Alfonso, Directeur de la Stratégie Interopérabilité chez Microsoft. Évalué à -3.
Kedal, quand tu fais un site en ASP.NET MVC, tu mets de côté la plus grosse partie d'ASP.NET pour ne garder que le pipeline HTTP, bref, tout l'inverse de ce que tu racontes.
En gros t'as pas d'argument. F# est inclu, en standard, dans Visual Studio. Même IronPython et IronRuby n'ont pas eu ce plaisir "de la dernière chance" d'être intégré dans un produit avec une roadmap de maintenance supérieur à une Ubuntu LTS.
Ton niveau de discours pu : ces toolkits sont tellement inutilisables qu'ils sont utilisés par les 3/4 des applications dans les dites technos.
Tu sais pas de quoi tu parles, tu n'a jamais développé dans ces environnements. Sinon tu saurais que les toolkits dont je parles sont très très largement utilisés.
Le DLR se base sur... le CLR, qui est un standard. C'est tellement impossible d'utiliser une autre implémentation que Mono y arrive : t'as fini de raconter des conneries ou t'en a toute une valise ?
Tu juges à l'emporte pièce, sans connaître ce dont tu parles, avec comme seul objectif que d'appuyer ton discours. Tu affirmes, dénigres, sans une once d'argumentation ettayée d'expérience ou de référence, là où une simple recherche google te montre que ce qui te semble impossible ou inutilisable s'avère totalement contredit par les faits.
C'est l'hopital qui se fou de la charité.
[^] # Re: Bonne interview
Posté par TImaniac (site web personnel) . En réponse à la dépêche Linus Torvalds : l’interview anniversaire des 20 ans du noyau. Évalué à 6.
En même temps c'est tout aussi scandaleux de faire confiance aux ring qui s'appuie sur du matos tout aussi potentiellement buggé... sans être patchable. Tu fais quoi demain si tu te retrouves avec une faille de sécu énorme dans une génération de proc grand public ? Le rôle de base d'un OS c'est de faire abstraction du matos, l'idée d'une sécurité qui fait abstraction de mécanisme hardware est donc tout à fait pertinente.
Et vu qu'il est impossible de prouver que les étoiles ne seront jamais alignées, il est évident que la meilleur approche consiste uniquement à en diminuer la probabilité.
[^] # Re: Enfumage
Posté par TImaniac (site web personnel) . En réponse au journal SL2011 : Entretien avec Alfonso, Directeur de la Stratégie Interopérabilité chez Microsoft. Évalué à 4.
Comparer une techno à une drogue vole à peu prêt aussi haut que de comparer la GPL à un cancer.
[^] # Re: Enfumage
Posté par TImaniac (site web personnel) . En réponse au journal SL2011 : Entretien avec Alfonso, Directeur de la Stratégie Interopérabilité chez Microsoft. Évalué à 1.
J'ai 2 réponses :
* qui dit OpenSource, dit souvent "communautaire", il est donc logique que ce soit des projets, même sponsorisés ou initiés par Microsoft, qui essaient de se "démarquer".
* il y a des projets OpenSource de Microsoft qui sont totalement "marqués, par exemple ASP.NET MVC, F# ou les "Toolkits" pour Silverlight, WPF et ASP.NET.
La liste est suffisament longue pour ne pas qualifier leur participation d'infime :
http://www.microsoft.com/opensource/directory.aspx
En fait la principale particularité c'est que c'est de l'open-source qui est tournée vers les technos Microsoft et pas les technos Linux. En même tant c'est super étonnant.
[^] # Re: Participation de MS
Posté par TImaniac (site web personnel) . En réponse à la dépêche La spécification d’ODF 1.2 est terminée. Évalué à 0.
En tout cas, leur utilisation était très simple : pouf une url, un proxy typé généré automatiquement et j'utilise mon service au bout de 30 secondes.
Alors oui, fallait éviter de mettre la main dans le camboui et oui c'était vraiment pas efficace au niveau des quantités d'info qui circulent, c'était une hérésie par rapport au protocole HTTP, mais n'empêche qu'en tant qu'utilisateur (développeur qui utilise/produit un service), REST & CO reste une lourde régression en terme de productivité.
Enfin bon, c'est pas comme si XML & co n'était pas encore largement utilisés, même dans les technos "modernes" du logiciel libre.
[^] # Re: Mauvaise catégorie
Posté par TImaniac (site web personnel) . En réponse à la dépêche La spécification d’ODF 1.2 est terminée. Évalué à 1.
J'ai une autre définition quand on cherche à émettre une opinion négative en propageant des infos douteuses ("soupçonne", "probablement", "fiasco"), et en plus c'est totalement objectif comme définition tellement c'est gros. Je vous laisse deviner :)
Extrait WIkipedia :
>"Il s'agit d'une technique rhétorique utilisée notamment dans la vente, le marketing, les relations publiques et le discours politique. Elle consiste à tenter d'influencer la perception de son audience en disséminant des informations négatives, souvent vagues et inspirant la peur. "
[^] # Re: Participation de MS
Posté par TImaniac (site web personnel) . En réponse à la dépêche La spécification d’ODF 1.2 est terminée. Évalué à 6.
Il faut surtout regarder à quoi a participé Microsoft dans le W3C : le W3C c'est pas uniquement (X)HTML + CSS. C'est aussi XML, XML Schema, XSLT, XPath, XQuery, WSDL, SOAP, etc. Autant de normes où Microsoft a été beaucoup plus actif, voir initiateur, et sans s'assoire sur le respect de ces normes.
Microsoft a clairement merdé en balançant il y a plusieurs années un support HTML totalement foireux qu'ils ont traînés comme un boulet jusqu'à aujourd'hui, mais y'a pas que ca au W3C.
[^] # Re: Dommage pour les développeurs concernés mais ...
Posté par TImaniac (site web personnel) . En réponse au journal Développeurs de Mono virés ?. Évalué à 5.
De quel risque parles-tu ? (à part pour les softs proprio comme MonoDroid ou MonoTouch). Mono est un logiciel libre dont Attachmate/novell est seulement le principal sponsor. Au pire le projet perd ce sponsor, et donc potentiellement des ressources pour faire vivre le projet, mais celà reste un projet libre qui peut continuer à vivre avec moins ou d'autres ressources.
En dehors de la communauté, il y a de toutes façon d'autres entreprises/sponsors qui travaillent avec Mono, y contribuent, et ont un intérêt à le maintenir : MainSoft, Unity, etc.
Il faut bien voir que Mono a existé avant Novell (initialement c'était Ximian), il n'y a pas de raison que le projet s'arrête avec Attachmate. Et officiellement, Attachmate a indiqué que les roadmaps produits étaient maintenues.
[^] # Re: C'est vrai !!!
Posté par TImaniac (site web personnel) . En réponse au journal Mais pourquoi le projet GNU fait-il tout pour priver le monde de liberté ?. Évalué à 3. Dernière modification le 22 avril 2011 à 22:03.
Si y'a un changement de principe, de 2 principes je dirais même :
Pour comparer avec ton compilateur, c'est à peu prêt comme si tout à coup t'avais un IDE : ca change radicalement la façon de consommer le compilateur, de la même manière que le Cloud change radicalement de consommer de l'hébergement.
Ou prends si tu préfères la transition de l'assembleur au compilateur : apparition d'une abstraction qui offre du même coup tout pleins de fonctionnalités/services. Oui basiquement, ca n'est toujours qu'un moyen de produire un exécutable.