Il suffit de ne développer qu'avec les composants soumis à l'ECMA et l'on sort du giron de Microsoft
Mouai, ba j'ai besoin d'être convaincu. Si on annonçait demain que OpenOffice.org passait a OOXML et jetait ODF à la poubelle sous prétexte que OOXML est une norme ISO, je suis pas sur que beaucoup de libristes apprécieraient, toi compris.
Quel est le pourcentage de la plateforme .NET certifiée ECMA ? Les évolutions de la plateforme ont elle été certifiées ? Es un vrai engagement de la part de Microsoft ou seulement une croix sur une checklist ?
De plus, imaginons que l'intégralité des applis Linux soit développées en .NET, ça serait quand même un gros aveu d'échec politiquement parlant pour le monde du libre car .NET == Microsoft dans la tête de tout le monde. J'espère que le libre a plus d'ambition que d'être un ersatz des outils Microsoft
L'historique de Microsoft inspire méfiance. Sun, Google, Nokia et quelques autres ont beaucoup moins ce problème.
C'est toujours possible mais ça vide en partie le projet de son contenu
- perte de compatibilité avec les applications Windows
- ralentissement des développements
- guerre interne ect...
C'est un peu comme si Samba, Wine ou Gnash devenaient incompatibles avec les équivalents "upstream" : la raison d'être en serait fortement diminuée.
En dehors des brevets, développer un logiciel libre en Mono c'est tout de même "donner le martinet pour se faire fouetter".
Développer en .NET c'est devenir pas mal dépendant de Microsoft et quand on sait que la politique de cette entreprise n'a jamais été l'interopérabilité, perso j'y mettrais pas les pieds. Ca me parait être du bon sens, peu importe si ces technologies sont un peu plus sexy sur certains aspects.
Que Mono existe pourquoi pas (il existe bien Gnash, Wine, Samba...), mais coder des nouveaux logiciel libres (spécifique Linux en plus) comme Tomboy avec, ça me parait vachement moins cool.
on se retrouve vite fait avec un build de GTK pour The Gimp, un pour Inkscape [...]
Comme pour les applications qui utilisent Qt sous Windows, c'est la philosophie de l'OS. Jusqu'à récemment (VC++ 2005) même la libc et la libc++ étaient livrées avec chaque application. Je crois que c'est même encore le cas pour les MFC. http://en.wikipedia.org/wiki/DLL_hell
Les applications qui utilisent le framework .NET sont en revanche + ou - épargnées.
l'absence de plate-forme unifiée (make de VC++, make GNU via MinGW, scons etc...)
Pour bien comprendre, à la base il y a les Makefile bas niveau format GNU ou VC++ qui sont donc dépendant d'une plateforme/compilateur.
SCons, CMake, Waf, QMake... sont des systèmes de compilation haut niveau multiplateforme. CMake et QMake par exemple génèrent des Makefiles au format GNU et VC++ alors que SCons et Waf reimplementent tout en Python.
La première étape est donc d'utiliser un système de compilation multiplateforme. Mon préféré est CMake (SCons est beaucoup trop lent et j'ai jamais utilisé Waf, encore trop jeune surement). Il faut penser le truc suffisamment adroitement pour pouvoir désactiver des librairies et des bouts de code suivant la plateforme. Les fichiers de build ainsi que le logiciel lui-même seront donc pensés de manière assez modulaires.
La deuxième étape est d'utiliser un langage multiplateforme et des librairies multiplateformes -> pour du C++ l'idéal est donc Qt qui permet de limiter le nombre de dépendances. Boost aussi est assez sympa pour le multiplateforme.
La troisième étape (facultative) est de mettre en place un Buildbot qui recompile automatiquement pour toutes les plateformes et génère les binaires.
Sur le repo, de mon point de vue, toutes les petites librairies (genre zlib, TinyXML...) sont intégrées dans un répertoire 3rdparty et recompilées en utilisant le système de build du logiciel (par exemple CMake). Pour les grosses bibliothèques manquantes sur une plateforme, l'idéal est de commiter les versions binaires (en les mettant à jour régulièrement bien sur). L'idée est de centraliser le bordel et de pouvoir effectuer un checkout sur un PC neuf sous n'importe quel OS/compilo sans devoir installer 10 librairies externes avant de pouvoir compiler le logiciel en question.
Bref porter sous Windows une appli Linux C/C++ qui a pas mal de dépendances et qui n'a pas été pensé pour dès le départ, c'est chaud car sous Windows rien n'est livré avec l'OS et le compilo. C'est principalement le cas pour les applis GTK+ qui se tapent énormément de dépendances en plus de GTK+ (glib, xml, dbus, sql...)
Bien choisir ces outils et librairies permet d'adresser Windows qui accapare ~90% des utilisateurs, bref ca vaut le coup. Firefox et OpenOffice.org n'auraient pas eu le succès qu'on leur connait s'il n'existait pas de version Windows.
Les distribs un bordel sans nom ? oui je suis d'accord, cf le long débat ici http://linuxfr.org/~Dabowl_92/28291.html
Mais comparé aux environnements mobiles que je viens de citer c'est de la pisse de chat.
Il n'y a pratiquement aucune compatibilité au niveau source entre les environnements mobiles. Par exemple Android n'utilise ni une libc conforme et encore moins une plateforme Java standard. Il est impossible de porter une application sous Android, il faut tout redevelopper cf http://linuxfr.org/comments/1035699,1.html
Le seul toolkit/platforme qui sort du lot niveau compatibilité, c'est Qt qui fonctionne sous Windows CE et Symbian.
- Android
- Symbian
- WebOS
Plus tous les autres qui se baladent (Maemo, Qtopia, Moblin, OpenMoko...)
Ca commence à faire beaucoup surtout qu'ils sont + ou - incompatibles entre eux niveau source contrairement à toutes nos distribs Linux :/
Je viens de l'installer et la dernière version date de 2006. Le CVS n'a pas reçu de nouveaux commits depuis plus de 2 ans et le wiki est mort.
Le moteur audio utilisé par musikCube est closed source puisque c'est BASS cf http://www.un4seen.com/
Et puis coder un soft libre en MFC, ça mériterait d'être brulé vif :p
Curieusement d'ailleurs, depuis Qt 4, on trouve pas mal d'applications Qt, puisqu'elles peuvent tourner sous Windows. Depuis Qt 4.5, en LGPL, on a également des applis proprio qui migrent vers Qt, et donc qui sont facilement portables vers Linux, et KDE.
Oui bien sur, Canal+ fait un soft pourri, et c'est la faute a MS...
Tu te trompes de conclusion, j'ai écrit ça :
"Si Windows Media Player n'était pas installé par défaut avec tous les Windows, Canal+ aurait très probablement utilisé une autre technologie"
Si ils pouvaient virer définitivement Windows Media Player, ça serait presque parfait. Ça éviterait de se taper ce genre d'horreur : http://tkrotoff.blogspot.com/2009/06/canal-la-demande-sur-pc(...)
La version N de Windows n'a malheureusement jamais été imposée.
> comment faire puisque tu n'as pas encore, à ce stade, de navigateur ?
Une icône qui lance graphiquement un ftp.exe ftp://mozilla.com/firefox-latest.exe ?
On pourrait imaginer plusieurs icônes relatives aux principaux navigateurs du marché dont IE.
A une époque il y avait bien plusieurs icônes dans Windows pour s'abonner à des FAI.
les gars qui analysent les chiffres dans ce domaine doivent savoir que android est un linux.
En même temps tout le monde s'en fou que derrière Android ça soit du Linux : c'est en fait une plateforme complètement différente.
Si tu veux développer une application sous Android, tu ne peux pas utiliser les libs et outils courants sous Linux : libc, GCC, GTK+, Qt, OpenGL ect... Tu dois coder en Java sur une nouvelle VM (incompatible avec Java SE & ME), avec des libs propres à Android. Via un hack on peut bidouiller et faire du natif mais alors même la libc n'est pas standard !
Ca fait donc de Android une nouvelle plateforme complètement différente et incompatible avec les distribs Linux que nous connaissons. Bref tout ça pour dire que compter Android comme un OS Linux n'a finalement pas beaucoup de sens. D'ailleurs le noyau Linux d'Android doit être désormais très éloigné de nos noyaux à nous. Nokia Maemo et Openmoko sont en revanche des "vrais" OS Linux.
Le marketing Android insiste clairement sur le coté open source, donc si la sauce Android prends ca risque de crédibiliser les logiciels libres et donc nos distribs Linux. Et qui sait, comme Android est ouvert, la libc standard, GTK+ et Qt pourraient être officiellement supportés mais j'ai un gros doute... Je considère d'ailleurs ça comme un véritable frein à l'adoption d'Android.
Si tu prends un Macbook tu pourras tester MacOS X et si ca te convient pas, installer Linux. Maintenant il suffit de te renseigner sur le macbook que tu convoites pour savoir s'il est bien supporté par ta distrib préférée. Mais à mon avis, les macbook sont assez bien gérés : beaucoup de geeks utilisent ca comme desktop Linux.
GENIAL ! merci beaucoup pour le lien
Ca utilise msysgit en fait, dommage qu'il n'existe pas de libgit multiplateforme, ca serait quand meme une approche bien plus "propre"
La fonction que j'utilise en permanence et qui me fait gagner un temps fou, c'est click droit / commit
Tortoise affiche alors une fenetre (cf http://tortoisegit.googlecode.com/files/commit.jpg )
Je peux verifier mon commit, selectionner-deselectionner les fichiers à commiter, voir et modifier les diff de facon graphique...
Quand j'ecris le message de commit, il me corrige les fautes, reconnait les mots contenus dans les fichiers qui vont etre commités (auto-completion sur les noms de classes). On peut voir et utiliser les messages des anciens commits.
C'est bien plus pratique qu'un 'svn diff' avant de commiter et ca permet d'etre sur de son commit et de pas faire de conneries. Pour ma part, je trouve ca tout simplement INDISPENSABLE :)
Et toi tu ne veux pas comprendre que L'un n'empêche pas l'autre signifie y passer un temps non négligeable. Pas uniquement la première fois, mais bien pour :
1- maintenir ton infrastructure qui te permet de générer les packages
2- tester un minimum ce que tu fournis
Tout ça pour 1% du marché...
Et comment tu comptes faire pour supporter Android ? D'apres ce que j'ai compris, il n'est pas possible de faire du natif sur Android, il faut obligatoirement passer par le langage Java et la JVM d'Android (enfin si j'ai bien tout suivi...)
Pour le reste, personnellement je me baserais plutot sur Qt : ca fonctionne sous Windows CE et S60 (Symbian). Par contre ca ne fonctionne pas (aujourd'hui) sur l'IPhone mais j'imagine que les API de l'IPhone sont assez similaires a celles de MacOS X et donc qu'il est tout a fait envisageable de porter Qt sur l'IPhone. Qt est desormais sous licence LGP (+ GPL) et son repository git est ouvert a toutes contributions.
[^] # Re: YaST, Java, Mono..
Posté par tanguy_k (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 6.
Et cela en fait il un argument non valide ?
[^] # Re: Ils font déjà pas mal de coup de pute
Posté par tanguy_k (site web personnel) . En réponse au journal Chomage partiel, Syntec et SSII. Évalué à 4.
[^] # Re: Oh oui fouettez moi !
Posté par tanguy_k (site web personnel) . En réponse au journal Mono: C’est un grave danger et seuls les imbéciles l’ignoreront, jusqu’au jour où il sera trop tard.. Évalué à 3.
Mouai, ba j'ai besoin d'être convaincu. Si on annonçait demain que OpenOffice.org passait a OOXML et jetait ODF à la poubelle sous prétexte que OOXML est une norme ISO, je suis pas sur que beaucoup de libristes apprécieraient, toi compris.
Quel est le pourcentage de la plateforme .NET certifiée ECMA ? Les évolutions de la plateforme ont elle été certifiées ? Es un vrai engagement de la part de Microsoft ou seulement une croix sur une checklist ?
De plus, imaginons que l'intégralité des applis Linux soit développées en .NET, ça serait quand même un gros aveu d'échec politiquement parlant pour le monde du libre car .NET == Microsoft dans la tête de tout le monde. J'espère que le libre a plus d'ambition que d'être un ersatz des outils Microsoft
L'historique de Microsoft inspire méfiance. Sun, Google, Nokia et quelques autres ont beaucoup moins ce problème.
[^] # Re: Oh oui fouettez moi !
Posté par tanguy_k (site web personnel) . En réponse au journal Mono: C’est un grave danger et seuls les imbéciles l’ignoreront, jusqu’au jour où il sera trop tard.. Évalué à 8.
C'est toujours possible mais ça vide en partie le projet de son contenu
- perte de compatibilité avec les applications Windows
- ralentissement des développements
- guerre interne ect...
C'est un peu comme si Samba, Wine ou Gnash devenaient incompatibles avec les équivalents "upstream" : la raison d'être en serait fortement diminuée.
# Oh oui fouettez moi !
Posté par tanguy_k (site web personnel) . En réponse au journal Mono: C’est un grave danger et seuls les imbéciles l’ignoreront, jusqu’au jour où il sera trop tard.. Évalué à 10.
Développer en .NET c'est devenir pas mal dépendant de Microsoft et quand on sait que la politique de cette entreprise n'a jamais été l'interopérabilité, perso j'y mettrais pas les pieds. Ca me parait être du bon sens, peu importe si ces technologies sont un peu plus sexy sur certains aspects.
Que Mono existe pourquoi pas (il existe bien Gnash, Wine, Samba...), mais coder des nouveaux logiciel libres (spécifique Linux en plus) comme Tomboy avec, ça me parait vachement moins cool.
[^] # Re: Mingw ain't dead
Posté par tanguy_k (site web personnel) . En réponse au journal Qt Creator 1.2 & Qt 4.5.2. Évalué à 4.
Comme pour les applications qui utilisent Qt sous Windows, c'est la philosophie de l'OS. Jusqu'à récemment (VC++ 2005) même la libc et la libc++ étaient livrées avec chaque application. Je crois que c'est même encore le cas pour les MFC. http://en.wikipedia.org/wiki/DLL_hell
Les applications qui utilisent le framework .NET sont en revanche + ou - épargnées.
# Et donc ?
Posté par tanguy_k (site web personnel) . En réponse au journal MS enfin clair dans sa com. Évalué à -6.
[^] # Re: Mingw ain't dead
Posté par tanguy_k (site web personnel) . En réponse au journal Qt Creator 1.2 & Qt 4.5.2. Évalué à 10.
Pour bien comprendre, à la base il y a les Makefile bas niveau format GNU ou VC++ qui sont donc dépendant d'une plateforme/compilateur.
SCons, CMake, Waf, QMake... sont des systèmes de compilation haut niveau multiplateforme. CMake et QMake par exemple génèrent des Makefiles au format GNU et VC++ alors que SCons et Waf reimplementent tout en Python.
La première étape est donc d'utiliser un système de compilation multiplateforme. Mon préféré est CMake (SCons est beaucoup trop lent et j'ai jamais utilisé Waf, encore trop jeune surement). Il faut penser le truc suffisamment adroitement pour pouvoir désactiver des librairies et des bouts de code suivant la plateforme. Les fichiers de build ainsi que le logiciel lui-même seront donc pensés de manière assez modulaires.
La deuxième étape est d'utiliser un langage multiplateforme et des librairies multiplateformes -> pour du C++ l'idéal est donc Qt qui permet de limiter le nombre de dépendances. Boost aussi est assez sympa pour le multiplateforme.
La troisième étape (facultative) est de mettre en place un Buildbot qui recompile automatiquement pour toutes les plateformes et génère les binaires.
Sur le repo, de mon point de vue, toutes les petites librairies (genre zlib, TinyXML...) sont intégrées dans un répertoire 3rdparty et recompilées en utilisant le système de build du logiciel (par exemple CMake). Pour les grosses bibliothèques manquantes sur une plateforme, l'idéal est de commiter les versions binaires (en les mettant à jour régulièrement bien sur). L'idée est de centraliser le bordel et de pouvoir effectuer un checkout sur un PC neuf sous n'importe quel OS/compilo sans devoir installer 10 librairies externes avant de pouvoir compiler le logiciel en question.
Bref porter sous Windows une appli Linux C/C++ qui a pas mal de dépendances et qui n'a pas été pensé pour dès le départ, c'est chaud car sous Windows rien n'est livré avec l'OS et le compilo. C'est principalement le cas pour les applis GTK+ qui se tapent énormément de dépendances en plus de GTK+ (glib, xml, dbus, sql...)
Bien choisir ces outils et librairies permet d'adresser Windows qui accapare ~90% des utilisateurs, bref ca vaut le coup. Firefox et OpenOffice.org n'auraient pas eu le succès qu'on leur connait s'il n'existait pas de version Windows.
Ouai je sais je parle trop, j'avais envie :-)
[^] # Re: Trop d'OS mobile OpenSource ?
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Le code source de Palm webOS disponible. Évalué à 4.
Mais comparé aux environnements mobiles que je viens de citer c'est de la pisse de chat.
Il n'y a pratiquement aucune compatibilité au niveau source entre les environnements mobiles. Par exemple Android n'utilise ni une libc conforme et encore moins une plateforme Java standard. Il est impossible de porter une application sous Android, il faut tout redevelopper cf http://linuxfr.org/comments/1035699,1.html
Le seul toolkit/platforme qui sort du lot niveau compatibilité, c'est Qt qui fonctionne sous Windows CE et Symbian.
[^] # Re: Bloat, quand tu nous tiens...
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Sortie de Songbird 1.2. Évalué à 2.
J'imagine à cause de l'utilisation de WxWidgets
# Trop d'OS mobile OpenSource ?
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Le code source de Palm webOS disponible. Évalué à 10.
- Symbian
- WebOS
Plus tous les autres qui se baladent (Maemo, Qtopia, Moblin, OpenMoko...)
Ca commence à faire beaucoup surtout qu'ils sont + ou - incompatibles entre eux niveau source contrairement à toutes nos distribs Linux :/
[^] # Re: Bloat, quand tu nous tiens...
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Sortie de Songbird 1.2. Évalué à 1.
le miraculeux et génial musikCube
Je viens de l'installer et la dernière version date de 2006. Le CVS n'a pas reçu de nouveaux commits depuis plus de 2 ans et le wiki est mort.
Le moteur audio utilisé par musikCube est closed source puisque c'est BASS cf http://www.un4seen.com/
Et puis coder un soft libre en MFC, ça mériterait d'être brulé vif :p
[^] # Re: Doublon ?
Posté par tanguy_k (site web personnel) . En réponse au journal KDE 4.3, ça promet pour juillet !. Évalué à 4.
Des exemples ?
[^] # Re: Et WMP ?
Posté par tanguy_k (site web personnel) . En réponse au journal Windows 7 et IE. Évalué à 3.
Tu te trompes de conclusion, j'ai écrit ça :
"Si Windows Media Player n'était pas installé par défaut avec tous les Windows, Canal+ aurait très probablement utilisé une autre technologie"
# Et WMP ?
Posté par tanguy_k (site web personnel) . En réponse au journal Windows 7 et IE. Évalué à 2.
La version N de Windows n'a malheureusement jamais été imposée.
[^] # Re: Question con que tout le monde se pose
Posté par tanguy_k (site web personnel) . En réponse au journal Windows 7 et IE. Évalué à 8.
Une icône qui lance graphiquement un ftp.exe ftp://mozilla.com/firefox-latest.exe ?
On pourrait imaginer plusieurs icônes relatives aux principaux navigateurs du marché dont IE.
A une époque il y avait bien plusieurs icônes dans Windows pour s'abonner à des FAI.
[^] # Re: Bonsoir
Posté par tanguy_k (site web personnel) . En réponse au message Conseil d'achat entre un macbook et un PC sous linux. Évalué à 2.
Tout à fait, un netbook...
[^] # Re: Statistiques[
Posté par tanguy_k (site web personnel) . En réponse au journal Quand on veut, on peut.. Évalué à 10.
En même temps tout le monde s'en fou que derrière Android ça soit du Linux : c'est en fait une plateforme complètement différente.
Si tu veux développer une application sous Android, tu ne peux pas utiliser les libs et outils courants sous Linux : libc, GCC, GTK+, Qt, OpenGL ect... Tu dois coder en Java sur une nouvelle VM (incompatible avec Java SE & ME), avec des libs propres à Android. Via un hack on peut bidouiller et faire du natif mais alors même la libc n'est pas standard !
Ca fait donc de Android une nouvelle plateforme complètement différente et incompatible avec les distribs Linux que nous connaissons. Bref tout ça pour dire que compter Android comme un OS Linux n'a finalement pas beaucoup de sens. D'ailleurs le noyau Linux d'Android doit être désormais très éloigné de nos noyaux à nous. Nokia Maemo et Openmoko sont en revanche des "vrais" OS Linux.
Le marketing Android insiste clairement sur le coté open source, donc si la sauce Android prends ca risque de crédibiliser les logiciels libres et donc nos distribs Linux. Et qui sait, comme Android est ouvert, la libc standard, GTK+ et Qt pourraient être officiellement supportés mais j'ai un gros doute... Je considère d'ailleurs ça comme un véritable frein à l'adoption d'Android.
[^] # Re: Statistiques
Posté par tanguy_k (site web personnel) . En réponse au journal Quand on veut, on peut.. Évalué à 10.
J'ai bien peur qu'Android soit comptabilisé dans la colonne"Android" et non dans la colonne "Linux".
# Un Macbook ca permet de tester MacOS X en plus de Linux
Posté par tanguy_k (site web personnel) . En réponse au message Conseil d'achat entre un macbook et un PC sous linux. Évalué à 3.
[^] # Re: Git sous Windows
Posté par tanguy_k (site web personnel) . En réponse au journal migrations vers de vrai outils de dev.... Évalué à 2.
Ca utilise msysgit en fait, dommage qu'il n'existe pas de libgit multiplateforme, ca serait quand meme une approche bien plus "propre"
[^] # Re: Git sous Windows
Posté par tanguy_k (site web personnel) . En réponse au journal migrations vers de vrai outils de dev.... Évalué à 2.
Tortoise affiche alors une fenetre (cf http://tortoisegit.googlecode.com/files/commit.jpg )
Je peux verifier mon commit, selectionner-deselectionner les fichiers à commiter, voir et modifier les diff de facon graphique...
Quand j'ecris le message de commit, il me corrige les fautes, reconnait les mots contenus dans les fichiers qui vont etre commités (auto-completion sur les noms de classes). On peut voir et utiliser les messages des anciens commits.
C'est bien plus pratique qu'un 'svn diff' avant de commiter et ca permet d'etre sur de son commit et de pas faire de conneries. Pour ma part, je trouve ca tout simplement INDISPENSABLE :)
# Git sous Windows
Posté par tanguy_k (site web personnel) . En réponse au journal migrations vers de vrai outils de dev.... Évalué à 3.
Il n'y a pas d'équivalent à TortoiseSVN qui est une vraie merveille, c'est une des raisons qui me fait préférer le developpement sous Windows.
Il existe QGit : http://digilander.libero.it/mcostalba/ mais quand j'ai testé c'était pas encore ça.
Pour Mercurial il existe TortoiseHg : http://bitbucket.org/tortoisehg/stable/wiki/Home mais j'ai jamais testé.
Vous utilisez quoi comme outils ?
[^] # Re: Pfff, c'est pas du troll de compet !
Posté par tanguy_k (site web personnel) . En réponse au journal pourquoi Linux n'est pas (encore) prêt pour le bureau. Évalué à 2.
1- maintenir ton infrastructure qui te permet de générer les packages
2- tester un minimum ce que tu fournis
Tout ça pour 1% du marché...
# Android, comment faire du natif ?
Posté par tanguy_k (site web personnel) . En réponse au message Appel a contribution. Évalué à 3.
Pour le reste, personnellement je me baserais plutot sur Qt : ca fonctionne sous Windows CE et S60 (Symbian). Par contre ca ne fonctionne pas (aujourd'hui) sur l'IPhone mais j'imagine que les API de l'IPhone sont assez similaires a celles de MacOS X et donc qu'il est tout a fait envisageable de porter Qt sur l'IPhone. Qt est desormais sous licence LGP (+ GPL) et son repository git est ouvert a toutes contributions.