TImaniac a écrit 6420 commentaires

Un peu comme une manière de dire que le backend de gcc ne serait pas réutilisable (!) ou que gcc ne serait pas bien documenté.

Ben tu vois, c'est pas du tout ambigüe puisque t'as tout compris :)

GCC a tout fait pour rester monolithique :

• licence pas friendly pour les utilisateurs intéressés (Apple & co)
• représentations intermédiaires non pensées pour être réutilisées en dehors du projet GCC lui même : ce qui se traduit en pratique par une absence de politique de spécification des interfaces (interfaces non stables, pas forcement documentées, des optimisations faites à tous les étages et donc pas toujours réexploitables). Un peu le modèle du kernel et de ses API pour les drivers : Il y a une volonté de ne pas offrir une interface clairement spécifiée, documentée, et avec une durée de vie/maintenance acceptable, pour des raisons à la fois politique (emmerder ceux qui font des drivers proprio) et technique (pouvoir casser les API quand on veut pour des besoins d'évolution).

A l'inverse, LLVM fait tout pour être réutilisé par le plus grand nombre. Et ses contributeurs sont d'ailleurs ses premiers utilisateurs.

L'objectif de LLVM est d'avoir effectivement un backend réutilisable : une licence très permissive, une VM (définie par sa représentation intermédiaire) clairement définie et documentée.

Tout l'inverse de GCC : les représentations intermédiaires sont là pour des raisons purement technique. GCC reste politiquement monolithique : pas de lib sous licence permissive (GPL est clairement non friendly pour une bonne partie de l'industrie), pas de volontée d'avoir une telle lib "backend" réutilisable par tous.

En gros tous ceux qui sont enmerdé par la politique de GCC misent sur LLVM.

Ca c'est une définition un brin obsolète. Prends plutôt la définition de Wikipedia EN : http://en.wikipedia.org/wiki/Software_as_a_service

C'est pas simplement un mode de vente, c'est surtout un mode de distribution/utilisation : tu n'as plus le classique CD/DVD à installer, héberger, administrer; le soft est hébergé dans le cloud et tu l'utilises à distance.

Commercialement ca se traduit généralement par un modèle de paiement à la durée d'utilisation.

Il y a plusieurs éléments je penses :

• JSR XXX : si tu n'a pas ton dictionnaire des JSR tu comprends rien.
• Ecosystème Multi-éditeurs/Multi-décideurs : trop de choix pour la même JSR (oui faut suivre). T'es bloqué dès le début du projet par le fait de devoir faire des choix.
• Ecosystème trop vaste : c'est un métier à part entière de le maîtriser.
• Une philosophie "write once, run everywhere" qui nivelle par le bas : pendant que l'autre propose des toolkits d'IHM sexy et propose différents niveau de compatibilité avec l'existant (natif), Java tente péniblement de sortir un JavaFX et propose JNI pour la compatibilité (sic).
• Le language est passé d'un mode "leader" à un mode "suiveur" par rapport à C#
  • pas d'innovation qui ne soit un repompage du concurrent direct.
  • C# a largement pris ses distances en terme de similitudes depuis l'inclusion de l'inférence, des lambda et LINQ : le langage devient fonctionnel.

Tu vas quand même avoir du mal à me faire croire que tu aurais tenu le même discours avant que MS ne les abandonnent

Et pourquoi ? Je suis un fervent défenseur des logiciels libres (c'est pourquoi je traîne par là), et c'est pourquoi j'ai toujours soigneusement évité VB6 ou J#.

Bref: quand on créé un tel antécédent, il ne faut pas s'étonner que le niveau de confiance en prenne un coup!

Justement, Mono a pris les devant en créant une version libre, et on devient indépendant de la stratégie de Microsoft. D'ailleurs la FSF a eu la même idée en lançant un projet similaire. Bon ils ont fédérés personne vu que tout le monde était sur Mono, mais l'intention y était.

Que le jour ou Microsoft décide de faire pareil que pour J# [...] , t'es dans la merde

Tu critiques le problème de la pérénité des solutions proprio avec 1 seule implémentation. Mono n'est pas proprio.

Si aujourd'hui tu choisis C#, t'as Mono, qui reste un logiciel libre avec une forte communauté derrière : la pérénité semble au moins similaire à une plateforme comme Ruby ou Python par exemple. Bref, Microsoft peut changer de stratégie, il ne se passera pas du tout la même chose qu'avec J# ou VB6 pour les utilisateurs actuels.

Autant dire que ca semble bien plus couteux qu'avec Qt

C'est juste pas les mêmes objectifs : l'intérêt n'est surtout pas d'avoir la même IHM partout, mais d'avoir une IHM dédiée parfaitement intégrée sur toutes les plateformes.

Si c'est pour faire la même interface partout, autant faire du web mobile.

ECMA couvre seulement le langage lui même

Non. ECMA couvre bien plus : la VM, le runtime et toutes les libs de base (IO, XML, HTTP, etc.).
Les briques non standardisées sont les briques de haut niveau : WCF (c'est Novell qui a les brevets clés), WF (pas implémenté par Mono), WPF (non plus), ASP.NET (deprecated, remplacé par ASP.NET MVC, sous licence libre).

Il a un risque plus important que pour d'autres logiciels libres

Contrairement à d'autres logiciels libres, Mono est une implémentation conforme, et est donc couvert par les engagements de Microsoft, tout le contraire des plateformes très proches et avec des concepts clairement identiques, type Java/Dalvik ou encore Vala.

vous avez déjà dans votre vie professionnelle eu des projets/appli qui tournent sous mono ?

oui.

Si on veux faire du .net autant prendre carrément du windows non ?

Ben non justement.

Avec mono on n'est on pas de toute façon limité par rapport à ce que l'on a sous windows ?

Non, on a même des choses non dispo sous Windows.

En l'occurence MonoDroid sert à avoir un socle technique commun pour iPhone/Android/WindowsPhone.

Parcque c'est les mêmes auteurs qui font Mono et MonoDroid. Ils ont le droit de publier leur code sous toutes les licences qu'ils veulent, MIT/GPL/Proprio.

La question se serait effectivement posée différement si MonoDroid était réalisé par un tiers.

Ça tombe bien ça, OpenID n'est pas fait pour récupérer des informations sur les gens, juste leur fournir un moyen de s'identifier.

C'est ce que j'essai d'expliquer : OpenID s'est focalisé sur l'intérêt de l'usager final qui s'authentifie. Alors que leurs vrais utilisateurs direct, c'est pas eux.

si c'est pour récupérer des informations sur les gens qu'ils utilisent Facebook, ça prouvent qu'ils cherchent à tirer profit d'informations personnelles, et je ne veux pas avoir affaire à ce genre de boîte.

J'ai cité 2 avantages : récupération de données, et très répandu. Tu peux très bien décider d'utiliser l'authentification Facebook pour le 2ème avantage sans le premier. Là où tu peux effectivement te dire que le site web cherche avant tout ton profile Facebook, c'est quand il ne te laisse pas le choix et que c'est la seule authent possible.

Faut arrêter avec OpenID.
L'idée était bien : pour ta tranquilité personnelle, c'est mieux que Facebook Connect, tu maîtrises ton information.

Mais dans la vraie vie, ceux qui décide d'utiliser OpenID, c'est les concepteurs de site web. Eux n'ont pas d'intérêt d'intégrer OpenID : - Aucune information intéressante à récupérer. - Peu répandu.

Alors oui, le premier argument est exactement ce pourquoi nous aimons OpenID, mais c'est aussi pourquoi il est si peu utilisé par les sites web.
Et oui, le 2ème argument, c'est l'oeuf ou la poule, toussa.

OpenID est mort pour avoir manqué sa cible, cad ses vrais utilisateurs : les concepteurs de site web. Facebook il t'offre sur un plateau des millions d'utilisateurs et des données associées.

Pas la peine d'essayer de pousser OpenID désormais. Il aurait fallu qu'un acteur comme Google ou Apple l'impose d'une manière ou d'une autre, mais ca n'a pas été fait.

C'est dommage, mais c'est la vraie vie.

On pari ?
Donne ta facture total et les forfaits que tu as.

certains disent que c'est à cause de la radioactivité, d'autres disent que c'est génétique, combat sans gagnants pour le moment à ma connaissance

Euh, si tu prends la première page de résultat google pour "luxation de la hanche", tu ne trouveras que des termes "héréditaires" ou "congénitales", et aucune référence au radon. Sans parler du fait que la Bretagne n'est pas la seule concernée (Vendée et Massif Central le sont également).

En ce qui concerne Malpasset, les arrières petits-enfants varois n'en soufrent pas

Ce qui est fort, c'est de comparer l'imapct d'un petit barrage (pourtant dangereux) qui produisant un chouilla d'électricité avec... une centrale nucléaire. Prends un meilleur exemple : les milliers de personnes évacuées pour construire le lac des 3 gorges en Chine ? Les surfaces agricoles perdues ? C'est pas hypothéquer l'avenir de ces gens ?

Faut arrêter de se leurer, il n'y a pas de solution miracle à l'heure actuelle pour produire de l'électricité à grande échelle sans qu'il n'y est d'impact, que ce soit humain et environnemental.

C'est pas trop un problème de secret industriel, mais un problème de subordination : tu peux effectivement dire plein de chose sur ton employeur, mais tu dois éviter d'être trop critique : c'est une cause de licenciement pour faute grave dans le code code du travail en France. Donc ce blog est plein d'infos intéressante, mais clairement on y trouvera pas les choses qui fâchent. Où alors les américains ont plus de libertés que nous ;)

Pour un accident nucléaire, les gens se sente impuissant.

Désolé je retrouve plus ma source, mais j'ai lu un article justement sur les gens qui habitent en aval des barrages hydroliques, et qui vivent avec un risque où ils sont encore plus impuissants : un barrage qui cède, c'est 400 ou 4000 morts en quelques secondes/minutes. Une centrale, tu peux fuire, et t'as pas forcement de séquelles graves si t'habites pas à 50m de la centrale.

Et bien paradoxalement, l'article préicisait que les gens acceptaient plus facilement la situation quand ils étaient directement en aval du barrage que quand ils étaient, toujours en aval, à plusieurs km : psychologiquement, les gens savent qu'ils ne peuvent strictement rien faire en cas de danger, et accepte cet état de fait beaucoup plus facilement.

Histoire de parler tout seul, j'apporte la page pour le nucléaire :

http://www.risquesmajeurs.fr/le-risque-nucleaire

Je me complète puisqu'on a des statistiques mondiales pour els barrages :

Entre 1959 et 1987, trente accidents de barrages ont été recensés dans le monde, faisant 18 000 victimes.

http://www.risquesmajeurs.fr/le-risque-de-rupture-de-barrage

Et si on prend le nombre de victimes en comparaison, il me semble que ce rapport explose, non?

Très difficile à évaluer pour le nucléaire, et surtout par ce que tu entends par "victime" : ça peut aller de la mort direct, au cancer ou à d'autres troubles indirects très difficile à évaluer/corréler.
Pour les barrages, c'est généralement plus simple : 1 noyade par-ci par-là, et parfois de gros dégât (Fréjus, 1959, rupture du barrage, 400 morts).

Ben je te cites :

D'ailleurs la validation d'applications propriétaires, ça ne marche pas, parce que même la procédure de validation d'Apple a laissé passé divers malware 

Dire que ça ne marche pas, c'est dire que ça ne sert à rien. Moi j'explique pourquoi ça sert à quelque chose, bref que ça marche. L'objectif de cette validation est de limiter les risques de malware, et j'explique juste comment cet objectif est atteint.

Il y a quand même une grosse différence avec la validation à priori façon AppStore d'Apple ou Marketplace de Microsoft :

• L'application ne peut pas être une application de cul. C'est con mais cette vérification élimine le cas classique du p0rn.exe où l'utilisateur est d'avantage attiré par le titre que par la réputation de l'application.
• L'application doit être un minimum fonctionnelle et ne doit pas être un copier-coller d'une appli existante : celà élimine pas mal de malwares qui sont de simples repackaging d'applications existantes.

Bref, sur ces plateformes, le réalisateur de malware va devoir :

• faire une application avec un minimum de fonctionnalités qui ne soit pas un repackaging
• devra contourner les tests faits par MS et Apple, sachant que le process est inconnu, avec donc un fort risque de se faire griller (et donc repasser par la case création d'identité - création de compte - paiement): m'étonnerait qu'une appli qui utilise un exploit pour passer root (ce qui est le cas ici) passe inaperçu dans les processes de test.
• ne pourra pas attirer facilement le chaland en jouant sur ses instints reproducteurs.

Sinon oui, en théorie il est toujours possible de faire passer un malware jusqu'à l'utilisateur final sur ces plateformes, mais dans la vraie vie le risque est grandement limité. Le sujet de ce journal en est une preuve flagrante.

Clairement le coup des retours à la ligne est vraiment contre-intuitif : on ne peut pas se contenter d'écrire un commentaire simple, sans formattage, sans devoir réfléchir à cette histoire de retours à la ligne.

De plus c'est invisible : obligé de cliquer sur prévisualiser pour vérifier qu'on a correctement écrit 2 paragraphes...

Sans parler du fait qu'il y a des conflits à la con : genre les espaces à la fin des urls : on a beau ajouter 2 espaces à la fin d'une url, y'a pas de retour à la ligne. Exemple : http://linuxfr.org <== oui y'a 2 putains d'espace et un retour à la ligne là, super non ? Ca serait logique si l'espace était pris en compte dans l'url, mais non, même pas. C'est juste totalement idiot, on se retrouve obligé d'utiliser la syntaxe dédiée aux urls.

Autre remarque : mais pourquoi ne pas proposer un composant WYSIWYG comme il en existe plein ? Garder la syntaxe geek qui fait bander les unixiens, ok, mais proposer quelque chose pour monsieur tout le monde ca serait pas mal non plus non ? Une option dans les préférence pour choisir d'utiliser le mode WYSIWYG ce serait pas mal non ?

Mon avis est proche : oui c'est clairement pour la virtualization et l'accélération 3D, mais non, pas pour la déporter vers le client : d'ailleur quel intérêt ? Autant faire tourner l'appli sur le poste client...
L'objectif est plutôt pour moi de préparer la concurrence des démos effectuées par Microsoft l'année dernière avec la dernière version de RemoteFX : jouer à Crysis avec un bête terminal RDP, le serveur se chargeant de faire le reste.
Et comme par hasard, tout ca se fait avec les dernières technos NVidia/AMD et des cartes 3D "pro" pour serveur.
A mon avis l'objectif est de cibler un maximum de terminaux pas forcement performants (tablettes & co) avec des applis 3D dans le "cloud" (qui a dit jeux ?)
http://en.wikipedia.org/wiki/RemoteFX http://blogs.amd.com/work/2010/07/12/microsoft_remotefx/ http://technet.microsoft.com/en-us/library/ff817602%28WS.10%29.aspx http://www.youtube.com/watch?v=sRbEh_58XmI Tout semble cohérent : une techno concurrente (RemoteFX), un gros marché potentiel (gaming), un environnement naissant (cloud), les acteurs clés (distri serveur avec RedHat et virtualization avec VMWare).

Disons qu'il y a des bonnes raisons techniques à ajouter une couche d'abstraction (suffit de voir le passage programmé de Windows 8 sur plateforme ARM). Ce sont ces mêmes bonnes raisons qui ont conduits Google à intégrer Dalvik.
Après le choix de la techno pour l'abstraction est évidemment politique : ils auraient été un peu concon de choisir un concurrent sachant qu'ils disposent en interne d'un éco-système complet, largement maîtrisé et connu des développeurs.