Si tu veux mon avis, la version boîte à 200€ ne sert qu'à donner l'impression au consommateur de faire une affaire en achetant le PC dans le rayon d'à côté à 399€.
Tu connais quelqu'un qui a déjà acheter une de ces boîtes ?
Mon avis est que ca ne concerne vraiment pas grand monde.
Dans tous les cas, là encore, la décision de justice ne va pas dans le sens de cet acheteur : rien n'oblige Dell à fournir le PC sans OS, donc ca changera rien à son problème.
Et puis s'il était prêt à foutre 200€ dans une boîte, autant dire qu'il ne sera absolument pas sensible à l'argument de 40€ d'économie ;)
Sur des machines à 600 €, 50€ (qui est plus souvent le prix considéré) ça fait quand même 8%. Ce n'est pas négligeable.
Certes, quand tu sais déjà qu'il existe des alternatives.
Sinon, le consommateur il raisonnera pas comme toi :
"je connais que Windows, Windows est vendu en rayon 200€"
"j'ai entendu dire qu'on pouvait utiliser autre chose, mais pourquoi prendrais-je le risque de devoir acheter Windows plus tard à 200€ ?"
Peut être que Linux correspondra avec ses besoins, mais dans le doute, il va pas prendre de risque et va au contraire se rassurer en se disant que c'est une sacré affaire, qu'il fait de toute façon des économies.
De plus comme précisé, rien n'oblige le constructeur à proposer la même chose sans OS, bref, il ne pourra même pas se dire "40€ d'économisé" puisqu'il n'aura pas forcement de produit identique sans OS sous la main.
i on rajoute tous les logiciels additionnels, on peut assez facilement penser que 10% de la machine au moins est du logiciel. Pire, certains sont réellement inutile
Dans ce cas, fait le calcul jusqu'au bout, les logiciels "inutiles" participent généralement à faire baisser le coût de la machine, Dell étant payé pour les installé, c'est une forme de publicité.
Victoire à demi-teinte :
L'infraction pour vente-liée n'a pas été retenu, le tribunal ayant été sensible à l'argument de Dell :
"Dell expliquait aussi que la vente avec logiciel représente « un usage établi » dans le secteur et qu’elle correspond à « l’intérêt du consommateur ». D’après le fabricant, enfin, il y a « une très faible demande des consommateurs pour des ordinateurs non équipés. »"
La victoire ne concerne donc que l'affichage des prix, le tribunal estimant que logiciels et matériels sont soumis à 2 régimes juridiques différents.
Je n'ai rien vu concernant l'obligation de remboursement.
Bref, ca semble au final être une toute petite victoire qui ne va pas faire avancer grand chose concrêtement.
C'est même à double tranchant : le client voit le Windows version boîte à 200€, et sur l'offre Dell "40€ seulement !". Pourquoi se priver de cet enorme rabais ?
De quel compatibilité du parle ?
Ben justement, je parles pas de l'interopérabilité des formats, qui est un autre problème qui a toute sa place dans le débat, mais de la compatibilité des applications.
Tu dis que c'est naze d'avoir des applications qui tournent sur plusieurs OS, ben moi je te dis que c'est au contraire un sérieux atout si on veut pouvoir changer d'OS avec la même facilité qu'on change de navigateur web.
D'ailleur si tu regardes, Firefox est multi-plateforme, est c'est une des raisons de son succès. S'il s'était cantonner à Linux, on serait encore avec des pauvres sites tout pourri IE-only. Bon il en a presque oublié la plateforme Linux, mais c'est la rançon du succès. Un des arguments que j'utilises quand je switch un utilisateur d'OS, c'est le rassurer en lui disant qu'il retrouvera son navigateur web préféré, son client mail préféré.
Les alternatives sont parfois aussi bien, voir mieux parcqu'intégrés à l'OS, mais ca rassure pas forcement l'utilisateur l'idée de tout changer.
T'es sûr ?
Oui.
Tu dirais encore ça d'une suite bureautique ?
Si tu me trouves une suite bureautique qui est le firefox des navigateurs, oui.
Comment expliques tu le succès du Mac ?
Succès tout relatif. Ca reste loin du succès d'un firefox. Le mac a ses aficionados, son identité marketing, son concept tout-en-un bien foutu. Apple vise les CSP+ qui veulent pas faire comme tout le monde (utiliser Windows) et qui admire autant l'objet pour son esthétique que pour son utilité.
Je vois mal Linux s'imposer sur ce type de public, c'est un marché de niche et ca le restera. Les parts de marché d'Apple ne grandiront que si Apple décide de changer de cible.
Portable ???
Quand ça tourne sous Linux (ou Unix), ça y reste des années.
ca reste que tu peux faire ton application en Tomcat ou PHP, globalement tu peux choisir l'OS de déploiement que tu veux.
Enfin, ne faire qu'imiter un système pour "draguer" des utilisateurs est l'assurance d'avoir un échec
Firefox a imité IE (son moteur de rendu en tout cas), quitte à ne pas être toujours respectueux des standards, pour justement être un maximum compatible et remplacer son concurrent sans douleur pour l'utilisateur. Et ca a marché.
Evidemment, faut pas que le produit se contente de cette imitation, faut aussi qu'il se démarque, comme l'a fait Firefox (nouvelles fonctionnalités, performances, etc.)
Non, les standards sont une partie de la solution.
On se comprend. Mais si ca te fait plaisir d'avoir l'impression de me contredire :)
Après tu te différencie sur les outils qui utilisent les standards. Faire deux OS différents avec comme objectif de faire tourner les même applis, c'est bien naze.
Tu te contredis.
Le problème des applications desktop, contrairement aux applications web, c'est qu'elles ne peuvent s'appuyer sur des standards. Y'a bien posix, mais bon voilà quoi.
Il faudrait un W3C du desktop, ou à défaut imiter le concurrent pour récupérer son contenu (ses applications) et ainsi rassurer les utilisateurs qui pourraient switcher sans douleur.
Certes on peut faire du portable (entre Unix et Windows) mais c'est salement compliqué.
Oui c'est bien le problème. Le web est un contenu plus ou moins indépendant du navigateur, ce qui permet de changer de navigateur sans trop de soucis, d'où le succès possible de Firefox.
Et effectivement pour les applications c'est beaucoup plus compliqué, c'est pourquoi Linux ne pourra pas se contenter d'être meilleur niveau qualité, il lui faudra beaucoup plus pour pallier le soucis de la compatibilité.
Concernant le manque d'applis, c'est un faux problème.
C'est pas un manque d'application, c'est un manque de compatibilité.
Firefox je peux l'installer, l'essayer, j'ai toujours accès à mes "appli web" préférés, le navigateur se fait plus ou moins oublier. On switch pas d'OS comme on switch de navigateur.
Le grand public utilise un nombre (très) limité d'applications.
Le problème du grand public, c'est qu'il achète le dernier jeu à la mode ou la dernière connerie micro-application pour faire ses cartes de visite. Et ca tourne que sous Windows.
Suffit de voir là où Linux a du succès : côté serveur, là où les applications peuvent être plus facilement portable car n'ayant pas besoin de s'intégrer à l'environnement de l'utilisateur.
Après internet est une partie de la solution pour linux : les applis web sont utilisables de la même façon sous Linux et Windows à travers un navigateur. Mais c'est à double tranchant : on ne maîtrise pas ces applications et encore moins ce qu'elle font de nos données, et je crois que je préfères avoir un Linux avec 2% de part de marché et mes données sur mon PC qu'un Linux avec 25% de part de marché et toutes mes données dans un datacenter.
80% ? Rien qu'en France IE n'a que 64% des parts de marché et Firefox 24%. http://www.cnetfrance.fr/news/internet/firefox-3-depasse-int(...)
Ce que montre la réussite de Firefox, c'est que le facteur "monopole" et "vente liée" est loin d'être bloquant, bref, c'est pas le blocage principal pour la diffusion de Linux.
Non je crois que le principal soucis, c'est la compatibilité.
Firefox a pu s'imposer, car globalement il permet d'accéder aux même contenus que IE. Ce fut certes laborieux au début, mais Firefox a su adapté son moteur de rendu pour s'adapter aux sites conçus pour IE. Il y a ensuite eu un engrenage : Firefox prend des parts de marché, il devient un navigateur dont il faut tenir compte, on adapte les sites en conséquence.
Pour Linux, si on compare ce qui pourrait s'apparenter aux sites web, c'est les applications. Et là pour Linux, c'est loin d'être aussi glorieux que Firefox. Y'a certes Wine, Samba, Java & co, mais on est bien loin d'une compatibilité de la majeur partie des sites web. Chaque OS a son environnement avec des contraintes techniques propres, qui ne rend pas les applications portables out-of-the-box.
Celui qui développe un site uniquement pour IE, il pourra s'afficher sous Firefox, éventuellement dégradé, mais on aura accès au contenu. Pour les applications, si le développeur ne pense pas multi-plateforme, à moins d'un coup de bol avec Wine, y'a pas de miracle.
Sans parler des moyens de distributions commerciaux qui ne mettent alors en avant que la compatibilité Windows, ce qui ne poussera jamais l'utilisateur à acheter.
Bref, on peut remplacer IE par Firefox, mais on peut pas remplacer Windows par Linux sans faire de grosses concessions sur le contenu : les applications.
Et là dessus, Microsoft est largement meilleur que Linux : c'est la cathédrale vs le bazar niveau bibliothèque, documentation, outils etc.
Ce qu'il faudrait, c'est imposer la portabilité avant de penser à imposer Linux. Pour ca il faut pousser des frameworks comme Qt.
Il y a malheuresement d'autres freins comme l'intégration dans l'environnement bureautique. Chaque OS a ses spécificités, et les applications desktop qui ont du succès s'intègrent généralement fortement sur le bureau, au risque de s'y retrouver dépendant :-/
Mais tout Qt est fait en C++, je pense pas que tu te rends compte de la masse de travail que c'est de faciliter la taches de binders en ayant une autre API, et la maintenance.
C'est tout le problème de la philosophie Qt. Si tu veux pas faire de C++, ben pas d'bol, t'es considéré comme un développeur de seconde zone.
C'est effectivement un choix de Nokia, ils font comme ils veulent, je trouve ca juste dommage, je peux ?
Ils te conseillent pas de l'utiliser bien évidemment.
"Qt's ActiveX and COM support allows Qt for Windows developers to:"
Comme déjà dis, ils le conseillent officiellement, et j'ai rien vu concernant la portabilité, notamment dans la section limitation, sur la page concernée : http://doc.trolltech.com/4.5/activeqt-dotnet.html
On est quand même en droit de trouver ca dommage de conseiller d'utiliser un truc pas portable avec un framework portable non ?
Un langage ne s'appuie pas sur des librairies , ERREUR.
T'es comique, tu cites juste LINQ qui est le parfait contre exemple de ce que tu dis :)
Enfin quand je disais langage, je parlais de plateforme, on se comprend.
Linq, syntaxiquement très étrange dans un langage et absolument pas implementable facilement sur nunux.
Etrange ou innovant ? Moi je trouve ca génial à l'utilisation : ca pousse à écrire du déclaratif / fonctionnel plutôt que l'impératif classique, et je trouve ca pas plus mal.
Quand à la difficulté d'implémentation sous Linux, laisse moi rire, Mono l'implémente très bien C# 3.
Supposons que sur mon appli Qt avec ActiveQt sous Windows, je fais du C# .Net avec fct A du framework 3.5.
ActiveQt est une interface COM, technologie vieille de 10 ou 20 ans, qui tourne concrêtement que sous Windows aujourd'hui. C'est pas un problème de .NET Mono ou autre. C'est un problème de portabilité de ActiveQt en soit, qui fait que ce n'est une solution utilisable que sous Windows.
En fouillant un peu tu trouvera des features non cross platform dans Qt, mais le manuel dit : "Utilise les a tes risques et peril".
Mais je suis d'accord avec ca, je critique pas le fait que y'es des trucs pas cross-plateforme par ci par là, ce que je critique c'est le manque de considération général pour les autres plateformes/langages que C++. C'est dommage c'est tout.
Non non j'aime comment est fait le binding Qt, Qyoto, qui se base sur les outils de binding de KDE. Ce que j'aime pas, c'est l'attitude de Nokia qui ne facilite pas vraiment la tâche des binders en proposant une API uniquement en C++ et qui conseille dans la doc des solutions proprio comme s'il existait que des CLI proprios sous un OS proprio. Je trouve pas ca dans l'esprit de Qt qui est un framework multiplateforme et bien plus mis en avant sous Linux à travers KDE que sous un certain environnement proprio.
Je me demande pourquoi Novell a passé un accord avec Microsoft si c'était si sécure que cela sinon...
troll FUD patent detected. bip bip.
L'accord concerne pas uniquement mono mais tous les logiciels inclus dans les distributions Linux de Novell.
Si tu parles du récent accord, il concerne moonlight, qui par nature intègre du code à Microsoft : les foutus codecs bourrés de brevets (et pas uniquement des brevets de MS). Mais c'est pas le sujet, Moonlight ne m'intéresse pas, et n'a vraiment aucun rapport avec ce Qyoto.
Juste pour se mettre une partie de la communauté à dos?
Je suppose que dans la tête des commerciaux de Novell, ca rassure les clients, quitte à se mettre à dos la communauté. Je dis pas que c'est malin mais je suppose que c'est le raisonnement.
Je ne me sers plus de cet OS (à mon grand plaisir) depuis des années et je ne suis pas comme certains je vais pas ramener ma fraise la où elle n'a rien à faire.
Eh ben c'est parfait ! t'en à rien à branler de MS.NET alors ! Rien à péter du retard de Mono sur la compatibilité avec les libs de .NET ! Rien à péter des bindings Qt proprios pour COM/.NET ! Que du bonheur, on va enfin pour en revenir à ce qui nous intéresse, Qt open source et le binding Qyoto !
La base technique de la version 2 car la version 3 n'est pas normalisé
Ce qui est chiant, c'est que tu trolls en même temps que tu découvres de quoi tu parles. Le socle technique n'a pas bougé depuis 4 ans et est toujours en version 2.0. Son implémentation dans mono est stable depuis un bon moment, la norme ISO est toujours d'actualité, tout va bien.
Le socle technique s'appelle CLI pour Common Language Runtime, autrement dit, rien à péter de la version de C#, de VB ou d'IronPython au dessus, si tu fais un binding pour la CLI, c'est un problème parfaitement indépendant du langage, la CLI a été conçu pour ça.
tu ne réponds jamais qu'à ce qui t'arrange et tu cherches tout sauf une discutions constructive.
Je te retourne la critique : moi je chercherais à discuter technique de binding, portabilité, vous préférez troller sur MS.NET.
Désolé de ne pas vouloir troller sur ce que tu veux.
Qui plus est dans mon cas je précise bien de façon systématique C#/.Net et si j'ai tord donne moi le lien ou je peux récupérer un environnement C#/.Net complet pour Linux.
C'est tout à fait ce que j'ai voulu dire : vous parleinz de MS .NET, c'est votre délire trollesque à tous les 2, et n'insistez pas, ca m'intéresse pas comme débat de discuter d'un produit proprio qui ne tourne que sur des plateformes proprios.
me faire passer pour un taré qui devrait aller dans un asile avec ses "délires"!
Eh ca m'arrive de délirer sans aller à l'asile :) Sérieux, je passe mon temps à essayer de recadrer le débat sur la partie technique normalisée, la CLI, qui m'intéresse et intéresse sans doute du monde sur LinuxFR parcqu'implémenté par Mono et Portable .NET. T'as visiblement qu'un objectif : discuter des produits commerciaux de Microsoft et de ses problèmes spécifiques, va sur windowsFR si ca existe, mais moi ca m'intéresse pas.
On ne doit pas vivre dans le même monde car je vois beaucoup plus d'applications java sous linux que d'application mono
Oué chacun son desktop effectivement. Moi mon Ubuntu avec son environnement de base, cad Gnome, vient avec F-Spot, Banshee et Tomboy. Sans chercher à faire de comparaison avec Java, ca reste que des développeurs ont visiblement trouvés un intérêt à coder des applications avec mono, et les utilisateurs ont trouvés suffisament d'intérêts dans ces applications pour qu'elles soient utilisées dans une distribution populaire. Bref, mono n'a plus à démontrer son intérêt.
Et tu as du mal à comprendre que certaines personnes n'apprécient pas cela?
A part les gens qui codent pour un produit proprio (MS.NET) sur une plateforme proprio (Windows), ca gène qui sous Linux ?
Tu semble dire d'un côté que C#/.Net c'est normalisé
Y'a la base technique et j'ai jamais dis autre chose : la VM et les libs de base. C'est absolument tout ce qui nous intéresse dans le débat technique de Qyoto.
Oué enfin quand tu vois que c'est indiqué que les bindings C# sont stables et mature alors que le fameux binding, Qyoto, est même pas déployable sous Windows out-of-the-box, ca fait peur.
et pas Gtk?
Ben de ce que j'ai essayé de faire comme binding, c'est moins chiant.
Ca s'automatise beaucoup plus simplement.
En particulier avec Mono qui propose une façon élégante, simple et portable de faire des bindings, pour peu que les ABI de la bibliothèque bindée soit portable. Et c'est tout le problème de C++ et son name mangling.
Ouh le vilain troll C versus C++.
Enfin un qui rentre dans le bon troll :)
Tu essayes de faire dériver le débat avec ta première question.
Non, depuis le départ j'essai de parler d'une seule chose : Qyoto, binding .NET/Mono, Qt.
Les dérives sur la portabilité de l'implémentation propriétaire de la CLI par Microsoft, c'est ton délire et le délire de ____.
'aurais d'ailleurs bien du mal à citer une seule killer app en .Net qui tourne sur Linux et Mac.
Le problème c'est déjà de trouver des killer-app, ensuite de trouver des killer-app qui tournent exclusivement en .NET et sans utiliser de bibliothèques spécifiques à tel ou tel système. C'est le problème des killer-apps, c'est que généralement elles sont bien car intégrés dans leur environnement, et portabilité rime rarement avec intégration parfaite.
Quand on parle de .Net, on parle de l'implémentation de Microsoft.
Je pensais qu'en parlant de Qyoto sur LinuxFR on pouvait ne pas parler de .NET et avoir un débat technique constructif. Visiblement non.
Aucune application .Net n'est venu de Windows vers Linux
Applications graphiques, effectivement non. Mais des libs pleins. Et le but n'est pas seulement de porter des applications, c'est aussi d'attirer des développeurs Windows à l'environnement Linux. Ce fut mon cas, et je suis pas le seul.
Visiblement on trouve beaucoup plus de geeks motivés pour coder des applications desktop sous Linux avec Mono qu'en Java.
Si tu regardes comment bosse Mono, ils n'utilisent pas du tout ces normes.
Ils se basent dessus.
Ce qu'ils sont obligé de faire, c'est réaliser des tests sur l'implémentation de MS, et implémenter leur code de façon à ce que ces tests passent.
Ben c'est indispensable vu que les 3/4 des libs sont pas standardisées. Mais pour ce qui est du coeur, à savoir la CLI, franchement tu vois quoi comme écart notable par rapport à la norme dans les implémentations MS et Mono ?
Si tu compares à une implémentation d'un stack réseau ou d'un format de fichier tu vas comprendre qu'il y a un problème.
Je vois pas de différence. Aucune implémentation d'un standard est exempt de bug et tout le monde cherche naturellement à être compatible avec l'implémentation de référence.
.Net multiplateforme? Dans un univers parallèle peut être mais dans le monde où je vis ça n'existe pas.
Ca tombe bien, on s'en branle, on parle de Mono, CLI, binding Qt.
Oui C# 3 n'est pas encore normalisé.
Mais bon en l'occurrence C# 3.0 s'appuie toujours sur le même socle technique : la CLI, dont la norme ISO est toujours au goût du jour et correctement implémentées par .NET et Mono. La CLI est par nature indépendante du langage (c'est un de ses intérêts) : si tu fais un binding pour la CLI, il sera utilisable dans tous les langages.
Pourquoi le projet mono ne le fait pas alors?
Parcque Qt est chiant à binder :)
pourquoi les efforts devraient forcement venir de Qt alors que leur librairies est déjà multiplateforme
Ben c'est un effort qui intéresserait tous ceux qui font des bindings, pas plus Mono que d'autres. Je ne demande pas à Qt de maintenir des bindings pour tous les langages de la terre, mono n'est effectivement pas un langage super répendu sur Linux qui mérite plus leur attention qu'un autre langage. Je trouverais juste ca cool s'ils pensaient à ceux qui ne veulent pas faire de C++ et faciliter la vie de ceux qui créent des bindings pour Mono, Python Ruby ou je ne sais quoi. Il leur suffirait de maintenir un seul binding, en C.
Le problème est qu'il est vraiment trop compliqué d'avoir des stats fiables, y'a tellement de configuration matérielles et logiciels que ca devient totalement irréaliste.
Comme qui dirait, en théorie c'est faisable, mais ça marchera jamais en pratique.
"A quoi cela sert de faire un truc portable pour un truc qui ne l'est que théoriquement?"
Ben Mono me semble une implémentation largement conforme de la CLI, y'a sûrement des bugs mais je n'en ai rencontré aucun. Donc en pratique c'est portable, pas que en théorie.
Et si cela se trouve c'est sale mais plus rapide de faire comme ça.
Oué bah oué, c'est le cas. ActiveQt est une interface pour Windows COM, c'est un effet de bord si c'est facilement utilisable dans .NET. Mais ca reste une techno purement MS (même s'il y a eu des tentatives de portages de COM).
quoique si cela se trouve c'est beaucoup plus complexe de faire le truc que tu suggères
C'est effectivement plus complexe, et Nokia le dit d'ailleur très clairement dans son article. Mais cette complexité, tous les bindings de Qt l'ont, c'est un problème lié au choix technique de Qt d'exporter ses API sous la forme de classes C++, qui sont par nature beaucoup plus difficile à binder qu'un API C.
si l'on prend la partie plus multiplateformes de la technos, est énormément plus orientés Gnome/Gtk et donc la aussi les incitations pour Qt sont faibles.
Ben moi j'aurai trouvé ca cool d'avoir une alternative à Gnome/Gtk justement. Visiblement tout ceux qui s'intéresse à Qyoto aussi.
C'est normalement plus facile de montrer un exemple qui dit que telle affirmation est fausse que de démontrer qu'une affirmation est tout le temps vrai.
Excuses-moi, mais j'ai la flemme de te faire un rapport de 5000 pages détaillant chaque paragraphe de la spec CLI/C# pour démontrer qu'elle est effectivement portable.
Moi j'ai pointé un article wikipedia, ca vaut ce que ca vaut, qui dit explicitement que la CLI a été conçu pour être portable.
Si c'est pas le cas, tu devrais trouver rapidement des exemples montrant que la CLI de Mono n'est pas et ne peut pas être compatible avec le standard.
il te donne un contre exemple immédiatement, donc tu corriges très rapidement ton appli pas besoin de la suite de non régression "overnight". C'est sans doute la partie la plus utile.
Ah oué, je vois bien le prouver me dire : "ah regardes quand je lance firefox et le plugin flash, il bouffe les 3/4 de la RAM et 100% du CPU, pendant ce temps là l'application que je valide ne répond plus dans les temps moyens acceptables".
Pourtant c'est un peu tout le problème des OS non temps-réel, et je vois mal ton prouveur être capable d'apréhender tout la complexité des comportements possibles d'une machine qui exécute un environnement qui n'offre pas de garanties temps-réel...
Dans la vérification formel, j'inclus aussi la génération automatique de vecteurs d'entrée pour augmenter le taux de couverture.
Ca me paraît borderline et plus du domaine de la vérification mathématique, on se rapproche du test traditionnel. On arrive également à produire des tests de couverture de code automatiquement sans passer par un vérificateur formel.
(il faut par contre un beau modèle de ton systèm
Oué donc arrache toi pour ton application qui tourne sous Windows ou Ubuntu.
Ben comme je l'ai dis, je critique la politique mono-plateforme de MS donc je trouve pas ca normal, non. Que Linux soit soit un citoyen de seconde zone pour Microsoft, je ne le nie absolument pas, c'est un fait.
Mais je vois toujours pas le rapport. On parlait technique bon sang, pas politique Microsoft.
Et voila encore une tentative de discréditer mes dires uniquement en me liant à d'autres participant de ce site.
Eh c'est toi qui a pondu tout un paragraphe sur ta personne.
is je nier cela ou ais-je dit que dans les fait C#/.Net n'est pas portable.
J'ai depuis le départ pris soin de parler du "socle technique" pour faire référence à la technique pure et simple, la CLI quoi. Ca c'est portable. Et c'est ca qui nous intéresse vu qu'on parle technique. Que .NET soit pas porté pour d'obscure raisons marketing, on s'en branle, c'est pas le sujet. Je vois bien que t'as qu'une envie s'est de le crier haut et fort, mais ca n'intéresse pas grand monde je penses dans ce débat.
Quel est l'apport direct positif de Microsoft à Linux?
C'est pas le sujet, et j'en ai rien à péter de toute façon de savoir ce que MS apporte ou non à Linux.
Le jour où toi ou quelqu'un d'autre arrivera à répondre à cette question on pourra discuter d'ici là je ne subirai que des insultes de ta part (et d'autre) parceque je soulève un point génant pour vous.
Mais ca me gène pas, c'est juste que c'est totalement HS. Trouve quelqu'un d'autre pour troller sur le sujet, ca m'intéresse pas de savoir si MS apporte quelque chose à Linux.
Tiens c'est rigolo mais Qt étant GPL/LGPL je ne vois pas comment cela ne peut pas être libre mais tu veux peut être parler d'un ajout à Qt non officiel?
Je suis pas un spécialiste, mais c'est marqué "The ActiveQt modules are part of the Qt Full Framework Edition. They are not part of the Open Source Versions of Qt."
Ca me paraît donc officiel et pas Open source. Après je suis peut être très mauvais en anglais.
Je n'ai pas mis d'argument?
C'est pas une question d'argument, tu dis juste "c'est dangereux" comme ca pif paf comme un cheveu sur la soupe à la fin d'un paragraphe sans queue ni tête.
Et le lien au dessus qui montre que pour que appliquer à des contrats publics au Portugal tu es forcé de te servir de technologies microsoft non disponible pour la majorité des systèmes concurrents?
Je vois pas le rapport avec la dangerosité de Mono. Juste une critique de la politique commerciale de MS, mais là encore c'est pas le sujet.
Il y a même plainte auprès de la commission européenne alors dire que les arguments sont creux c'est un peu facile tout de même.
C'est un peu ton problème : tu trouves des arguments qui totalement hors contexte ou hors sujet. Tu affirmes des trucs, parfois vrais et argumentés, mais sans rapport direct avec ce à quoi tu réponds.
Maintenant j'arrête avec ton troll à 2 balles, je préfères mon troll technique initial.
Bah ca n'a rien de contradictoire. J'aime bien la techno CLI derrière .NET, et j'aime bien les logiciels libres. Mono me propose de combiner les 2, je vois pas pourquoi je cracherais dessus pour d'obscure position anti-MS primaire.
[^] # Re: Remarque
Posté par TImaniac (site web personnel) . En réponse à la dépêche Dell lourdement condamné pour non affichage du prix du logiciel. Évalué à 2.
Tu connais quelqu'un qui a déjà acheter une de ces boîtes ?
Mon avis est que ca ne concerne vraiment pas grand monde.
Dans tous les cas, là encore, la décision de justice ne va pas dans le sens de cet acheteur : rien n'oblige Dell à fournir le PC sans OS, donc ca changera rien à son problème.
Et puis s'il était prêt à foutre 200€ dans une boîte, autant dire qu'il ne sera absolument pas sensible à l'argument de 40€ d'économie ;)
[^] # Re: Remarque
Posté par TImaniac (site web personnel) . En réponse à la dépêche Dell lourdement condamné pour non affichage du prix du logiciel. Évalué à 2.
Certes, quand tu sais déjà qu'il existe des alternatives.
Sinon, le consommateur il raisonnera pas comme toi :
"je connais que Windows, Windows est vendu en rayon 200€"
"j'ai entendu dire qu'on pouvait utiliser autre chose, mais pourquoi prendrais-je le risque de devoir acheter Windows plus tard à 200€ ?"
Peut être que Linux correspondra avec ses besoins, mais dans le doute, il va pas prendre de risque et va au contraire se rassurer en se disant que c'est une sacré affaire, qu'il fait de toute façon des économies.
De plus comme précisé, rien n'oblige le constructeur à proposer la même chose sans OS, bref, il ne pourra même pas se dire "40€ d'économisé" puisqu'il n'aura pas forcement de produit identique sans OS sous la main.
i on rajoute tous les logiciels additionnels, on peut assez facilement penser que 10% de la machine au moins est du logiciel. Pire, certains sont réellement inutile
Dans ce cas, fait le calcul jusqu'au bout, les logiciels "inutiles" participent généralement à faire baisser le coût de la machine, Dell étant payé pour les installé, c'est une forme de publicité.
# Remarque
Posté par TImaniac (site web personnel) . En réponse à la dépêche Dell lourdement condamné pour non affichage du prix du logiciel. Évalué à 10.
L'infraction pour vente-liée n'a pas été retenu, le tribunal ayant été sensible à l'argument de Dell :
"Dell expliquait aussi que la vente avec logiciel représente « un usage établi » dans le secteur et qu’elle correspond à « l’intérêt du consommateur ». D’après le fabricant, enfin, il y a « une très faible demande des consommateurs pour des ordinateurs non équipés. »"
La victoire ne concerne donc que l'affichage des prix, le tribunal estimant que logiciels et matériels sont soumis à 2 régimes juridiques différents.
(src : http://www.pcinpact.com/actu/news/49582-dell-vente-liee-vent(...) )
Je n'ai rien vu concernant l'obligation de remboursement.
Bref, ca semble au final être une toute petite victoire qui ne va pas faire avancer grand chose concrêtement.
C'est même à double tranchant : le client voit le Windows version boîte à 200€, et sur l'offre Dell "40€ seulement !". Pourquoi se priver de cet enorme rabais ?
[^] # Re: Re:
Posté par TImaniac (site web personnel) . En réponse au journal Progression de Linux. Évalué à 2.
Ben justement, je parles pas de l'interopérabilité des formats, qui est un autre problème qui a toute sa place dans le débat, mais de la compatibilité des applications.
Tu dis que c'est naze d'avoir des applications qui tournent sur plusieurs OS, ben moi je te dis que c'est au contraire un sérieux atout si on veut pouvoir changer d'OS avec la même facilité qu'on change de navigateur web.
D'ailleur si tu regardes, Firefox est multi-plateforme, est c'est une des raisons de son succès. S'il s'était cantonner à Linux, on serait encore avec des pauvres sites tout pourri IE-only. Bon il en a presque oublié la plateforme Linux, mais c'est la rançon du succès. Un des arguments que j'utilises quand je switch un utilisateur d'OS, c'est le rassurer en lui disant qu'il retrouvera son navigateur web préféré, son client mail préféré.
Les alternatives sont parfois aussi bien, voir mieux parcqu'intégrés à l'OS, mais ca rassure pas forcement l'utilisateur l'idée de tout changer.
T'es sûr ?
Oui.
Tu dirais encore ça d'une suite bureautique ?
Si tu me trouves une suite bureautique qui est le firefox des navigateurs, oui.
Comment expliques tu le succès du Mac ?
Succès tout relatif. Ca reste loin du succès d'un firefox. Le mac a ses aficionados, son identité marketing, son concept tout-en-un bien foutu. Apple vise les CSP+ qui veulent pas faire comme tout le monde (utiliser Windows) et qui admire autant l'objet pour son esthétique que pour son utilité.
Je vois mal Linux s'imposer sur ce type de public, c'est un marché de niche et ca le restera. Les parts de marché d'Apple ne grandiront que si Apple décide de changer de cible.
Portable ???
Quand ça tourne sous Linux (ou Unix), ça y reste des années.
ca reste que tu peux faire ton application en Tomcat ou PHP, globalement tu peux choisir l'OS de déploiement que tu veux.
Enfin, ne faire qu'imiter un système pour "draguer" des utilisateurs est l'assurance d'avoir un échec
Firefox a imité IE (son moteur de rendu en tout cas), quitte à ne pas être toujours respectueux des standards, pour justement être un maximum compatible et remplacer son concurrent sans douleur pour l'utilisateur. Et ca a marché.
Evidemment, faut pas que le produit se contente de cette imitation, faut aussi qu'il se démarque, comme l'a fait Firefox (nouvelles fonctionnalités, performances, etc.)
Non, les standards sont une partie de la solution.
On se comprend. Mais si ca te fait plaisir d'avoir l'impression de me contredire :)
Après tu te différencie sur les outils qui utilisent les standards. Faire deux OS différents avec comme objectif de faire tourner les même applis, c'est bien naze.
Tu te contredis.
Le problème des applications desktop, contrairement aux applications web, c'est qu'elles ne peuvent s'appuyer sur des standards. Y'a bien posix, mais bon voilà quoi.
Il faudrait un W3C du desktop, ou à défaut imiter le concurrent pour récupérer son contenu (ses applications) et ainsi rassurer les utilisateurs qui pourraient switcher sans douleur.
[^] # Re: Re:
Posté par TImaniac (site web personnel) . En réponse au journal Progression de Linux. Évalué à 3.
Oui c'est bien le problème. Le web est un contenu plus ou moins indépendant du navigateur, ce qui permet de changer de navigateur sans trop de soucis, d'où le succès possible de Firefox.
Et effectivement pour les applications c'est beaucoup plus compliqué, c'est pourquoi Linux ne pourra pas se contenter d'être meilleur niveau qualité, il lui faudra beaucoup plus pour pallier le soucis de la compatibilité.
Concernant le manque d'applis, c'est un faux problème.
C'est pas un manque d'application, c'est un manque de compatibilité.
Firefox je peux l'installer, l'essayer, j'ai toujours accès à mes "appli web" préférés, le navigateur se fait plus ou moins oublier. On switch pas d'OS comme on switch de navigateur.
Le grand public utilise un nombre (très) limité d'applications.
Le problème du grand public, c'est qu'il achète le dernier jeu à la mode ou la dernière connerie micro-application pour faire ses cartes de visite. Et ca tourne que sous Windows.
Suffit de voir là où Linux a du succès : côté serveur, là où les applications peuvent être plus facilement portable car n'ayant pas besoin de s'intégrer à l'environnement de l'utilisateur.
Après internet est une partie de la solution pour linux : les applis web sont utilisables de la même façon sous Linux et Windows à travers un navigateur. Mais c'est à double tranchant : on ne maîtrise pas ces applications et encore moins ce qu'elle font de nos données, et je crois que je préfères avoir un Linux avec 2% de part de marché et mes données sur mon PC qu'un Linux avec 25% de part de marché et toutes mes données dans un datacenter.
[^] # Re: Re:
Posté par TImaniac (site web personnel) . En réponse au journal Progression de Linux. Évalué à 1.
http://www.cnetfrance.fr/news/internet/firefox-3-depasse-int(...)
Ce que montre la réussite de Firefox, c'est que le facteur "monopole" et "vente liée" est loin d'être bloquant, bref, c'est pas le blocage principal pour la diffusion de Linux.
Non je crois que le principal soucis, c'est la compatibilité.
Firefox a pu s'imposer, car globalement il permet d'accéder aux même contenus que IE. Ce fut certes laborieux au début, mais Firefox a su adapté son moteur de rendu pour s'adapter aux sites conçus pour IE. Il y a ensuite eu un engrenage : Firefox prend des parts de marché, il devient un navigateur dont il faut tenir compte, on adapte les sites en conséquence.
Pour Linux, si on compare ce qui pourrait s'apparenter aux sites web, c'est les applications. Et là pour Linux, c'est loin d'être aussi glorieux que Firefox. Y'a certes Wine, Samba, Java & co, mais on est bien loin d'une compatibilité de la majeur partie des sites web. Chaque OS a son environnement avec des contraintes techniques propres, qui ne rend pas les applications portables out-of-the-box.
Celui qui développe un site uniquement pour IE, il pourra s'afficher sous Firefox, éventuellement dégradé, mais on aura accès au contenu. Pour les applications, si le développeur ne pense pas multi-plateforme, à moins d'un coup de bol avec Wine, y'a pas de miracle.
Sans parler des moyens de distributions commerciaux qui ne mettent alors en avant que la compatibilité Windows, ce qui ne poussera jamais l'utilisateur à acheter.
Bref, on peut remplacer IE par Firefox, mais on peut pas remplacer Windows par Linux sans faire de grosses concessions sur le contenu : les applications.
Et là dessus, Microsoft est largement meilleur que Linux : c'est la cathédrale vs le bazar niveau bibliothèque, documentation, outils etc.
Ce qu'il faudrait, c'est imposer la portabilité avant de penser à imposer Linux. Pour ca il faut pousser des frameworks comme Qt.
Il y a malheuresement d'autres freins comme l'intégration dans l'environnement bureautique. Chaque OS a ses spécificités, et les applications desktop qui ont du succès s'intègrent généralement fortement sur le bureau, au risque de s'y retrouver dépendant :-/
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . En réponse à la dépêche Sortie de Qt 4.5. Évalué à 2.
C'est tout le problème de la philosophie Qt. Si tu veux pas faire de C++, ben pas d'bol, t'es considéré comme un développeur de seconde zone.
C'est effectivement un choix de Nokia, ils font comme ils veulent, je trouve ca juste dommage, je peux ?
Ils te conseillent pas de l'utiliser bien évidemment.
"Qt's ActiveX and COM support allows Qt for Windows developers to:"
Comme déjà dis, ils le conseillent officiellement, et j'ai rien vu concernant la portabilité, notamment dans la section limitation, sur la page concernée :
http://doc.trolltech.com/4.5/activeqt-dotnet.html
On est quand même en droit de trouver ca dommage de conseiller d'utiliser un truc pas portable avec un framework portable non ?
Un langage ne s'appuie pas sur des librairies , ERREUR.
T'es comique, tu cites juste LINQ qui est le parfait contre exemple de ce que tu dis :)
Enfin quand je disais langage, je parlais de plateforme, on se comprend.
Linq, syntaxiquement très étrange dans un langage et absolument pas implementable facilement sur nunux.
Etrange ou innovant ? Moi je trouve ca génial à l'utilisation : ca pousse à écrire du déclaratif / fonctionnel plutôt que l'impératif classique, et je trouve ca pas plus mal.
Quand à la difficulté d'implémentation sous Linux, laisse moi rire, Mono l'implémente très bien C# 3.
Supposons que sur mon appli Qt avec ActiveQt sous Windows, je fais du C# .Net avec fct A du framework 3.5.
ActiveQt est une interface COM, technologie vieille de 10 ou 20 ans, qui tourne concrêtement que sous Windows aujourd'hui. C'est pas un problème de .NET Mono ou autre. C'est un problème de portabilité de ActiveQt en soit, qui fait que ce n'est une solution utilisable que sous Windows.
En fouillant un peu tu trouvera des features non cross platform dans Qt, mais le manuel dit : "Utilise les a tes risques et peril".
Mais je suis d'accord avec ca, je critique pas le fait que y'es des trucs pas cross-plateforme par ci par là, ce que je critique c'est le manque de considération général pour les autres plateformes/langages que C++. C'est dommage c'est tout.
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . En réponse à la dépêche Sortie de Qt 4.5. Évalué à 1.
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . En réponse à la dépêche Sortie de Qt 4.5. Évalué à 3.
troll FUD patent detected. bip bip.
L'accord concerne pas uniquement mono mais tous les logiciels inclus dans les distributions Linux de Novell.
Si tu parles du récent accord, il concerne moonlight, qui par nature intègre du code à Microsoft : les foutus codecs bourrés de brevets (et pas uniquement des brevets de MS). Mais c'est pas le sujet, Moonlight ne m'intéresse pas, et n'a vraiment aucun rapport avec ce Qyoto.
Juste pour se mettre une partie de la communauté à dos?
Je suppose que dans la tête des commerciaux de Novell, ca rassure les clients, quitte à se mettre à dos la communauté. Je dis pas que c'est malin mais je suppose que c'est le raisonnement.
Je ne me sers plus de cet OS (à mon grand plaisir) depuis des années et je ne suis pas comme certains je vais pas ramener ma fraise la où elle n'a rien à faire.
Eh ben c'est parfait ! t'en à rien à branler de MS.NET alors ! Rien à péter du retard de Mono sur la compatibilité avec les libs de .NET ! Rien à péter des bindings Qt proprios pour COM/.NET ! Que du bonheur, on va enfin pour en revenir à ce qui nous intéresse, Qt open source et le binding Qyoto !
La base technique de la version 2 car la version 3 n'est pas normalisé
Ce qui est chiant, c'est que tu trolls en même temps que tu découvres de quoi tu parles. Le socle technique n'a pas bougé depuis 4 ans et est toujours en version 2.0. Son implémentation dans mono est stable depuis un bon moment, la norme ISO est toujours d'actualité, tout va bien.
Le socle technique s'appelle CLI pour Common Language Runtime, autrement dit, rien à péter de la version de C#, de VB ou d'IronPython au dessus, si tu fais un binding pour la CLI, c'est un problème parfaitement indépendant du langage, la CLI a été conçu pour ça.
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . En réponse à la dépêche Sortie de Qt 4.5. Évalué à 1.
Je te retourne la critique : moi je chercherais à discuter technique de binding, portabilité, vous préférez troller sur MS.NET.
Désolé de ne pas vouloir troller sur ce que tu veux.
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . En réponse à la dépêche Sortie de Qt 4.5. Évalué à 1.
C'est tout à fait ce que j'ai voulu dire : vous parleinz de MS .NET, c'est votre délire trollesque à tous les 2, et n'insistez pas, ca m'intéresse pas comme débat de discuter d'un produit proprio qui ne tourne que sur des plateformes proprios.
me faire passer pour un taré qui devrait aller dans un asile avec ses "délires"!
Eh ca m'arrive de délirer sans aller à l'asile :) Sérieux, je passe mon temps à essayer de recadrer le débat sur la partie technique normalisée, la CLI, qui m'intéresse et intéresse sans doute du monde sur LinuxFR parcqu'implémenté par Mono et Portable .NET. T'as visiblement qu'un objectif : discuter des produits commerciaux de Microsoft et de ses problèmes spécifiques, va sur windowsFR si ca existe, mais moi ca m'intéresse pas.
On ne doit pas vivre dans le même monde car je vois beaucoup plus d'applications java sous linux que d'application mono
Oué chacun son desktop effectivement. Moi mon Ubuntu avec son environnement de base, cad Gnome, vient avec F-Spot, Banshee et Tomboy. Sans chercher à faire de comparaison avec Java, ca reste que des développeurs ont visiblement trouvés un intérêt à coder des applications avec mono, et les utilisateurs ont trouvés suffisament d'intérêts dans ces applications pour qu'elles soient utilisées dans une distribution populaire. Bref, mono n'a plus à démontrer son intérêt.
Et tu as du mal à comprendre que certaines personnes n'apprécient pas cela?
A part les gens qui codent pour un produit proprio (MS.NET) sur une plateforme proprio (Windows), ca gène qui sous Linux ?
Tu semble dire d'un côté que C#/.Net c'est normalisé
Y'a la base technique et j'ai jamais dis autre chose : la VM et les libs de base. C'est absolument tout ce qui nous intéresse dans le débat technique de Qyoto.
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . En réponse à la dépêche Sortie de Qt 4.5. Évalué à 2.
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . En réponse à la dépêche Sortie de Qt 4.5. Évalué à 2.
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . En réponse à la dépêche Sortie de Qt 4.5. Évalué à 2.
Ben de ce que j'ai essayé de faire comme binding, c'est moins chiant.
Ca s'automatise beaucoup plus simplement.
En particulier avec Mono qui propose une façon élégante, simple et portable de faire des bindings, pour peu que les ABI de la bibliothèque bindée soit portable. Et c'est tout le problème de C++ et son name mangling.
Ouh le vilain troll C versus C++.
Enfin un qui rentre dans le bon troll :)
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . En réponse à la dépêche Sortie de Qt 4.5. Évalué à 2.
Non, depuis le départ j'essai de parler d'une seule chose : Qyoto, binding .NET/Mono, Qt.
Les dérives sur la portabilité de l'implémentation propriétaire de la CLI par Microsoft, c'est ton délire et le délire de ____.
'aurais d'ailleurs bien du mal à citer une seule killer app en .Net qui tourne sur Linux et Mac.
Le problème c'est déjà de trouver des killer-app, ensuite de trouver des killer-app qui tournent exclusivement en .NET et sans utiliser de bibliothèques spécifiques à tel ou tel système. C'est le problème des killer-apps, c'est que généralement elles sont bien car intégrés dans leur environnement, et portabilité rime rarement avec intégration parfaite.
Quand on parle de .Net, on parle de l'implémentation de Microsoft.
Je pensais qu'en parlant de Qyoto sur LinuxFR on pouvait ne pas parler de .NET et avoir un débat technique constructif. Visiblement non.
Aucune application .Net n'est venu de Windows vers Linux
Applications graphiques, effectivement non. Mais des libs pleins. Et le but n'est pas seulement de porter des applications, c'est aussi d'attirer des développeurs Windows à l'environnement Linux. Ce fut mon cas, et je suis pas le seul.
Visiblement on trouve beaucoup plus de geeks motivés pour coder des applications desktop sous Linux avec Mono qu'en Java.
Si tu regardes comment bosse Mono, ils n'utilisent pas du tout ces normes.
Ils se basent dessus.
Ce qu'ils sont obligé de faire, c'est réaliser des tests sur l'implémentation de MS, et implémenter leur code de façon à ce que ces tests passent.
Ben c'est indispensable vu que les 3/4 des libs sont pas standardisées. Mais pour ce qui est du coeur, à savoir la CLI, franchement tu vois quoi comme écart notable par rapport à la norme dans les implémentations MS et Mono ?
Si tu compares à une implémentation d'un stack réseau ou d'un format de fichier tu vas comprendre qu'il y a un problème.
Je vois pas de différence. Aucune implémentation d'un standard est exempt de bug et tout le monde cherche naturellement à être compatible avec l'implémentation de référence.
.Net multiplateforme? Dans un univers parallèle peut être mais dans le monde où je vis ça n'existe pas.
Ca tombe bien, on s'en branle, on parle de Mono, CLI, binding Qt.
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . En réponse à la dépêche Sortie de Qt 4.5. Évalué à 2.
Mais bon en l'occurrence C# 3.0 s'appuie toujours sur le même socle technique : la CLI, dont la norme ISO est toujours au goût du jour et correctement implémentées par .NET et Mono. La CLI est par nature indépendante du langage (c'est un de ses intérêts) : si tu fais un binding pour la CLI, il sera utilisable dans tous les langages.
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . En réponse à la dépêche Sortie de Qt 4.5. Évalué à 2.
Parcque Qt est chiant à binder :)
pourquoi les efforts devraient forcement venir de Qt alors que leur librairies est déjà multiplateforme
Ben c'est un effort qui intéresserait tous ceux qui font des bindings, pas plus Mono que d'autres. Je ne demande pas à Qt de maintenir des bindings pour tous les langages de la terre, mono n'est effectivement pas un langage super répendu sur Linux qui mérite plus leur attention qu'un autre langage. Je trouverais juste ca cool s'ils pensaient à ceux qui ne veulent pas faire de C++ et faciliter la vie de ceux qui créent des bindings pour Mono, Python Ruby ou je ne sais quoi. Il leur suffirait de maintenir un seul binding, en C.
[^] # Re: Se passer des tests ...
Posté par TImaniac (site web personnel) . En réponse au journal La preuve de programme : où en est-on ?. Évalué à 2.
Comme qui dirait, en théorie c'est faisable, mais ça marchera jamais en pratique.
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . En réponse à la dépêche Sortie de Qt 4.5. Évalué à 2.
Ben Mono me semble une implémentation largement conforme de la CLI, y'a sûrement des bugs mais je n'en ai rencontré aucun. Donc en pratique c'est portable, pas que en théorie.
Et si cela se trouve c'est sale mais plus rapide de faire comme ça.
Oué bah oué, c'est le cas. ActiveQt est une interface pour Windows COM, c'est un effet de bord si c'est facilement utilisable dans .NET. Mais ca reste une techno purement MS (même s'il y a eu des tentatives de portages de COM).
quoique si cela se trouve c'est beaucoup plus complexe de faire le truc que tu suggères
C'est effectivement plus complexe, et Nokia le dit d'ailleur très clairement dans son article. Mais cette complexité, tous les bindings de Qt l'ont, c'est un problème lié au choix technique de Qt d'exporter ses API sous la forme de classes C++, qui sont par nature beaucoup plus difficile à binder qu'un API C.
si l'on prend la partie plus multiplateformes de la technos, est énormément plus orientés Gnome/Gtk et donc la aussi les incitations pour Qt sont faibles.
Ben moi j'aurai trouvé ca cool d'avoir une alternative à Gnome/Gtk justement. Visiblement tout ceux qui s'intéresse à Qyoto aussi.
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . En réponse à la dépêche Sortie de Qt 4.5. Évalué à 2.
Excuses-moi, mais j'ai la flemme de te faire un rapport de 5000 pages détaillant chaque paragraphe de la spec CLI/C# pour démontrer qu'elle est effectivement portable.
Moi j'ai pointé un article wikipedia, ca vaut ce que ca vaut, qui dit explicitement que la CLI a été conçu pour être portable.
Si c'est pas le cas, tu devrais trouver rapidement des exemples montrant que la CLI de Mono n'est pas et ne peut pas être compatible avec le standard.
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . En réponse à la dépêche Sortie de Qt 4.5. Évalué à 2.
En quoi le socle technique/C# n'est pas portable ?
En quoi MS ne respecte pas du tout la norme ISO correspondante ?
[^] # Re: Se passer des tests ...
Posté par TImaniac (site web personnel) . En réponse au journal La preuve de programme : où en est-on ?. Évalué à 2.
Ah oué, je vois bien le prouver me dire : "ah regardes quand je lance firefox et le plugin flash, il bouffe les 3/4 de la RAM et 100% du CPU, pendant ce temps là l'application que je valide ne répond plus dans les temps moyens acceptables".
Pourtant c'est un peu tout le problème des OS non temps-réel, et je vois mal ton prouveur être capable d'apréhender tout la complexité des comportements possibles d'une machine qui exécute un environnement qui n'offre pas de garanties temps-réel...
Dans la vérification formel, j'inclus aussi la génération automatique de vecteurs d'entrée pour augmenter le taux de couverture.
Ca me paraît borderline et plus du domaine de la vérification mathématique, on se rapproche du test traditionnel. On arrive également à produire des tests de couverture de code automatiquement sans passer par un vérificateur formel.
(il faut par contre un beau modèle de ton systèm
Oué donc arrache toi pour ton application qui tourne sous Windows ou Ubuntu.
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . En réponse à la dépêche Sortie de Qt 4.5. Évalué à 3.
Mais je vois toujours pas le rapport. On parlait technique bon sang, pas politique Microsoft.
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . En réponse à la dépêche Sortie de Qt 4.5. Évalué à 2.
Eh c'est toi qui a pondu tout un paragraphe sur ta personne.
is je nier cela ou ais-je dit que dans les fait C#/.Net n'est pas portable.
J'ai depuis le départ pris soin de parler du "socle technique" pour faire référence à la technique pure et simple, la CLI quoi. Ca c'est portable. Et c'est ca qui nous intéresse vu qu'on parle technique. Que .NET soit pas porté pour d'obscure raisons marketing, on s'en branle, c'est pas le sujet. Je vois bien que t'as qu'une envie s'est de le crier haut et fort, mais ca n'intéresse pas grand monde je penses dans ce débat.
Quel est l'apport direct positif de Microsoft à Linux?
C'est pas le sujet, et j'en ai rien à péter de toute façon de savoir ce que MS apporte ou non à Linux.
Le jour où toi ou quelqu'un d'autre arrivera à répondre à cette question on pourra discuter d'ici là je ne subirai que des insultes de ta part (et d'autre) parceque je soulève un point génant pour vous.
Mais ca me gène pas, c'est juste que c'est totalement HS. Trouve quelqu'un d'autre pour troller sur le sujet, ca m'intéresse pas de savoir si MS apporte quelque chose à Linux.
Tiens c'est rigolo mais Qt étant GPL/LGPL je ne vois pas comment cela ne peut pas être libre mais tu veux peut être parler d'un ajout à Qt non officiel?
Je suis pas un spécialiste, mais c'est marqué "The ActiveQt modules are part of the Qt Full Framework Edition. They are not part of the Open Source Versions of Qt."
Ca me paraît donc officiel et pas Open source. Après je suis peut être très mauvais en anglais.
Je n'ai pas mis d'argument?
C'est pas une question d'argument, tu dis juste "c'est dangereux" comme ca pif paf comme un cheveu sur la soupe à la fin d'un paragraphe sans queue ni tête.
Et le lien au dessus qui montre que pour que appliquer à des contrats publics au Portugal tu es forcé de te servir de technologies microsoft non disponible pour la majorité des systèmes concurrents?
Je vois pas le rapport avec la dangerosité de Mono. Juste une critique de la politique commerciale de MS, mais là encore c'est pas le sujet.
Il y a même plainte auprès de la commission européenne alors dire que les arguments sont creux c'est un peu facile tout de même.
C'est un peu ton problème : tu trouves des arguments qui totalement hors contexte ou hors sujet. Tu affirmes des trucs, parfois vrais et argumentés, mais sans rapport direct avec ce à quoi tu réponds.
Maintenant j'arrête avec ton troll à 2 balles, je préfères mon troll technique initial.
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . En réponse à la dépêche Sortie de Qt 4.5. Évalué à 1.