TImaniac a écrit 6423 commentaires

Il est completement trivial d'ajouter une backdoor dans un programme proprietaire qui ne sera jamais trouvée par du fuzzing. Dans un programme open source, il faut faire un patch qui ajoute un bug subtile, en ésperant qu'il ne soit pas remarqué, ni corrigé lorsque le code change. C'est beaucoup moins trivial.

Je parlais de bug, pas de backdoor volontaire. Heartbleed et Shellshock sont des bugs, et ce ne sont que 2 exemples qui ont fait parler d'eux par leur criticité et la popularité des softs associés, à mon avis ils sont loin d'être rares.

Dans un programme open source, il faut faire un patch qui ajoute un bug subtile, en ésperant qu'il ne soit pas remarqué, ni corrigé lorsque le code change. C'est beaucoup moins trivial.

C'est pas trivial mais c'est sans doute pas plus dur que de chercher à corrompre une boîte de dev propriétaire pour qu'il intègre un backdoor (ils acceptent rarement les pull request :-)). Parcqu'un éditeur qui propose une brique aussi populaire que OpenSSH il a une image de marque à défendre, alors prendre le risque de s'aliener tous ses clients en cas de découverte, faut que le risque en vaille sacrément la chandelle. C'est possible que ca arrive mais c'est du même niveau de probabilité que de trouver un heartbleed ou un shellshock, qu'il soit volontaire ou non. Et qui dit bug critique, dit installation potentielle d'un backdoor par derrière, tout aussi invisible que dans ton logiciel proprio.

Bref, pour moi il n'y a pas de meilleur ou pire en matière de sécurité, aucune des 2 approches (libre/proprio) n'apporte de garantie à l'utilisateur.

mais c'est le mieux que l'on puisse faire actuellement.

Ca peut aussi donner l'effet inverse : un faux sentiment de sécurité.
J'ai cité Shellshock mais on peut aussi prendre pour exemple Heartbleed : le code incriminé a été introduit par erreur sous la forme d'un patch, qui a pourtant été relu à l'époque. Et il a fallut là encore 2 ans pour qu'elle soit découverte, dans une brique logicielle pourtant critique d'un point de vue sécurité !
Alors oui, des experts peuvent "contrôler" le code de logiciels libres, mais non seulement ils ne sont pas forcement efficace (cf. exemples précédents) mais ces experts peuvent avoir des intentions toutes aussi opposées (genre un expert de la NSA), et l'ouverture du code devient alors à double tranchant.

c'est que ca met au meme niveau un logiciel entierement libre et qui a été analysé par un tas de gens qui s'y connaissent, et un logiciel proprietaire bourré de spywares.

C'est du FUD pur et simple. Pour rappel beaucoup de bugs sont trouvés par des techniques (fuzzing, etc.) qui ne demande aucun accès au code source et qui s'applique très bien aux logiciels propriétaires.

Je ne dis pas qu'il faut mieux faire du proprio, mais d'un point de vue sécurité, oui c'est pour moi au même niveau : on croit utiliser quelque chose en confiance alors qu'il faudrait être au moins aussi prudent qu'avec un logiciel propriétaire.

Pour ma part, j'ai une confiance totale dans le projet tor car bien que financer en partie par le gouvernement américain, le code est libre et donc beaucoup de gens peuvent regarder le code et c'est ce qui est fait. Autre point, tor est développé en partie par Jacob Appelbaum qui a régulièrement des problèmes avec les autorités américaines lorsqu'il passe la frontière (voir le livre d'Assange). Bref, le code est libre et ça semble une garantie suffisante pour vérifier que la NSA n'y a pas un accès caché (jusqu'à preuve du contraire).

Je pensais que la faille Shellshock présente depuis 20 ans dans un logiciel libre très populaire avait au moins permis d'arrêter ce raisonnement naïf sur la "garantie suffisante" qu'offre l'accès au code source. Ou alors c'est de l'ironie ?

Après vérification il y a beaucoup plus qu'un parseur XML, il y a toutes les libs de base du Framework .NET existant, mais c'est pas sur le même repo, d'où la confusion :
https://github.com/Microsoft/referencesource
Même si ce repo n'évoluera pas, il est destiné à alimenter le repo .NET Core.

L’œil est facilement trompé et de plus il est plutôt difficile de rester objectif.

En même temps c'est le but d'une vidéo non ? Donner une illusion de réel en mouvement à ta rétine.

Ben déjà t'as Office sous Android, pas encore aussi complet que sous Windows mais il avance. De là faire un lien entre Android et Linux il n'y a qu'un pas que je ne franchirai pas.

C' est vrai pour ce qui concerne la nouvelle brique qui s'appelle .NET Core, mais j'ai essayé de montrer dans la dépêche que cette libération s'inscrit dans une démarche plus large qui regroupe d'autre parties essentielles de la stack web : le nouveau compilateur Roselyn et le framework ASP.NET, libérés récemment, qui ne se limite pas à 2 ou 3 classes.
Bref c'est pas uniquement des mots, juste une étape logique supplémentaire pour proposer une stack complète.

Si tout le code était là, il aurait fallu utiliser le passé composé : "Microsoft a libéré". S'ils avaient l'intention de le faire mais que rien n'était là, il aurait fallu utiliser le futur : "Microsoft libérera". Là on parle bien d'une libération "en cours", d'une action qui se déroule en ce moment, ce qui correspond parfaitement à l'utilisation du présent, ce qui explique ton constat : ce n'est que le début, quelques bibliothèques pour le moment.

J’espère que pour Microsoft, ce n'est pas non plus une façon déguisée d'abandonner ses technos.

Bof, il y a une grosse différence : Adobe a "donné" à un tiers le code d'une plateforme existante. Là Microsoft met à disposition des technos nouvelles en cours de développement.

Donc il n'est pas question d'utiliser des parties de ce code pour un autre projet ou même de modifier son runtime "officiel".

Si, la seul contrainte, c'est que ton projet reste compatible avec le standard ECMA-335. Pour ce qui n'est pas couvert par le standard ECMA (les autres API MS), il faut que ca reste compatible avec la doc officielle de MS.

Tu as raison de signaler que c'est une limite importante, qui empêche théoriquement un concurrent de faire un dérivé non compatible (genre le conflit Google/Oracle autour de Java), mais ca laisse tout de même la possibilité de faire plein d'améliorations : correction de bugs, améliorer les performances, faire un portage vers une autre plateforme, etc.

C'est justement parce que Mono a échoué à sortir .NET de la niche Microsoft qu'on en est arrivé là.

Mono est sans doute le runtime alternatif le plus utilisé sur Android et iOS, notamment à travers le moteur de jeu Unity… Si c'est pas sortir de la niche Microsoft ça.

Ce que vise MS à travers cette ouverture de code, et que ne vise pas Icaza avec Xamarin, ce sont les serveurs.

Asp.net 5 tourne déjà sous Linux, suffit de voir la doc d'install sur github, il y a la procédure d'install pour Linux de proposée : https://github.com/aspnet/home
Ce qui manque pour le moment, c'est le runtime de MS, pour le moment il faut le runtime Mono.

La menace des brevets plane toujours;

https://github.com/dotnet/corefx/blob/master/PATENTS.TXT

Mouais enfin là Samsung n'arrête pas de payer à cause de la validité des brevets mais parcque Samsung estime que le rachat de Nokia par MS modifie les conditions de leur contrat. Ne connaissant pas ce contrat, difficile de dire si les autres constructeurs peuvent se permettre de prendre le même chemin que Samsung.

C'est exactement le contexte de cette annonce : Samsung a arrêté de payer depuis quelques mois, MS attaque et a dû publier des chiffres, d'où ce journal.

Windows 8 cela disparait de tous les pc que je vois. En fait la premiere chose que TOUT le monde demande lorsqu'un pc arrive avec ce truc c'est "mets moi windows 7 s'il te plait".

Y'a ta vision et la réalité :

http://www.netmarketshare.com/operating-system-market-share.aspx?qprid=11&qpcustomb=0&qpsp=164&qpnp=25&qptimeframe=M

se fermer les autres marches

Tu te fermes rien du tout : vous vous rendez pas compte que le coût de dev c'est peanuts à côté des coûts marketing et le test/validation d'un business model. S'ils font pas direct une appli cross-platfrom, c'est juste parcque c'est pas un besoin en soit : quand y'a plus qu'à recoder une appli sur une autre plateforme une fois le business model et le succès testé, c'est juste aligner quelques K€, OSEF des gains du Framework compatible.

Ils ont oublié Modern UI ;-)

J'ai dis "Windows". C'est toi qui n'est pas moderne, Microsoft a abandonné cette appellation depuis longtemps :)

Qui utilise Xamarin ?

D'après leur site 15 000 clients.

Il me semble qu'à l'heure actuelle il est impossible d'avoir une application telle que celle que tu décris : c'est à dire qui soit "platform look compliant" et "plateform specific"

CQFD.

C'est pour cela qu'aujourd'hui les décideurs se concentrent généralement sur 1 ou 2 plateforme dans un premier temps. Etre cross-Platform n'est pas une fin en soit : l'objectif est déjà de tester une appli sur un périmètre précis (exemple typique : iOS), tout en s'assurant que la première impression laissé soit la bonne.

Bref, à budget équivalent, mieux vaut peaufiner une application native sur une seule plateforme que de chercher à faire du cross-Platform.

Le reste ferait des compromis que tu sembles vouloir rejeter.

Ou comment s'assurer que son application fera un bide.

Ca c'est pour les OS grands public. Après comme je l'ai dit plus haut, Qt peut avoir un intérêt dans l'embarqué, là où l'utilisateur n'a que peu d'attache/habitude avec un écosystème.

Et si moi, développeur d'application, je juge que la meilleure façon de parcourir les infos de mon application, c'est verticalement, même sous windows phone, est-ce que je dois sacrifier mon point de vue au nom de la sacrée saint cohérence ergonomique ?

Non tu fais ce que tu veux. Par contre si tu veux que ton application "plaise" à tes utilisateurs, il te faut faire des choix qui ne sont pas forcement identique d'une plateforme à l'autre : les habitudes des utilisateurs varient en fonction de leur plateforme.

Des avantages et des inconvénients sont présents dans les deux camps. Je pense par exemple à Blender qui propose une IHM très singulière

C'est l'autre solution : si tu as des choix esthétiques et ergonomiques fortement marqués, léchés qui contribuent à l'identité de ton application, oui tu peux te permettre d'avoir quelque chose de très similaire sur chaque plateforme. Mais autant dire que c'est très très loin d'être un luxe que peuvent se permettrent 90% des applications que tu trouves sur les stores. Et en général quand tu as ce "luxe", c'est que tu as des moyens, et franchement tu te poses même pas la question d'utiliser Qt : tu parts sur du natif.

A la bourre ?

Nan attend je peux le relancer :)

personnellement je pense que le bon Framework c'est Xamarin.
L'intro du site parle d'elle même :
"Create native iOS, Android, Mac and Windows apps in C#."

Ben si la dernière justement : intégré "Facebook Messenger", application en code natif, dans l'application "Facebook" devenait une obligation.
Imagine le résultat s'ils avaient choisient Qt pour l'application "Facebook" : non seulement c'est compliqué techniquement mais en plus on aurait une expérience utilisateur différente d'une partie à l'autre de l'appli. Tout simplement pas acceptable.

désolé mais je vois pas le truc

Je pense qu'on ne parle pas de la même chose. Tu semble considérer uniquement les OS desktop. Là le débat est beaucoup plus large et intègre Android, iOS et Windows RT (8 et Phone), plateforme maintenant supportées par Qt.
Tout mes exemples d'intégration concernent ces plateformes "modernes", qui vont remplacer à terme les anciennes plateformes : qu'on soit d'accord ou pas, les Google, Apple et Microsoft poussent ces nouveaux environnements, ce qui impliquent des contraintes d'intégration nouvelles, pour des raisons à la fois techniques mais aussi d'attente utilisateur en terme d'expérience.

Peux-tu être plus précis ?

Ben par exemple regarde l'appli 20 minutes sur Windows Phone :
http://screenshots.fr.sftcdn.net/fr/scrn/3346000/3346508/20minutes-fr-02-321x535.png
L'application utilise les codes de design Windows Phone : ensemble des contenus dans une page (panorama) qui défile horizontalement.

Maintenant la même chose sur iOS :
http://actu.meilleurmobile.com/wp-content/uploads/2012/07/20minutes-200x300.jpg
Défilement vertical, menu en haut, etc.

Il y a à la fois des différences graphiques, des différences d'ergo, de navigation, d'architecture d'enchaînement des écrans.

Sans parler de l'intégration avec l'OS : personnalisation de l'écran d'accueil pour afficher les dernières news, téléchargement en background dans un agent "controllé" par l'OS pour éviter le réveille de toute l'application et ainsi avoir un contrôle fin sur les jobs qui tournent, leur durée de vie, la gestion de la batterie, etc.
```

Pour MacOSX je ne sais pas mais pour Android la raison en est tout simplement parceque Qt ne supporte pas encore cette plateforme?

Ben si :
http://qt-project.org/doc/qt-5/winrt-support.html