Bien entendu, il fallait être un geek pour se sentir tout excité à l'annonce de cette nouvelle en apparence anodine. Une réécriture d'un logiciel... la belle affaire ! Pourtant, ce projet avait réchauffé le cœur et l'âme des libristes puisqu'il annonçait l'apparition d'une alternative au projet Tomboy, basé sur la très controversée technologie Mono. Tomboy est un logiciel de prise de notes, avec des fonctions d'hyperliens de note en note et des fonctions de synchronisation entre machines. On peut difficilement le qualifier d'indispensable, mais il répond certainement à un besoin réel des utilisateurs. Ce qui provoque la controverse, c'est qu'il est inclus par défaut dans le bureau GNOME [NdM : Tomboy ne fait pas partie de GNOME Core] et qu'il est basé sur Mono qui est la réimplémentation libre du framework .NET de Microsoft.
Le projet Mono a toujours été fort controversé au sein du monde du libre et la réticence à l'utiliser, même après les promesses de non agression de Microsoft, continue d'être farouche. Comme l'a déjà dit Richard Stallman, Mono est bien un projet libre mais si il est utilisé comme une brique essentielle pour construire de nombreux logiciels, alors tout cet écosystème sera mis en danger par un changement de politique de Microsoft. En outre, l'utilisation de Mono, toujours en retard sur son équivalent propriétaire, renforce le standard logiciel de la firme qui reste l'adversaire numéro un du monde du libre.
C'est ce qui explique que la ré-implémentation totale de Tomboy en C++ a été accueillie par des cris de joie. Comme il s'est, de plus, avéré que les performances étaient radicalement améliorées et que Fedora avait annoncé le remplacement de Tomboy par Gnote pour sa version 12, on pouvait penser que la dernière heure de Tomboy était venue et que toutes les principales distributions - à l'exception probable de la très monophile OpenSUSE - allaient basculer vers Gnote.
C'était sans compter sur un petit détail signalé par Hubert Figuière sur son blog. Il n'avait commencé ce projet que pour combattre l'ennui quand il était entre deux emplois et il ne continuerait à travailler dessus qu'aussi longtemps qu'il le pourrait. Hélas, trois fois hélas, Hubert n'a semble-il plus de temps à consacrer à Gnote. Le dernier commit date du mois août et, en réponse à une question sur la date de la prochaine version, Hubert a répondu fin octobre qu'il n'y en aurait plus : « Sorry, there is no release planned. But if somebody wants to take up on maintainership, feel free to contact me. »
Évidemment Fedora se retrouve un peu le bec dans l'eau à proposer par défaut dans sa très prochaine version 12 un logiciel qui n'est plus maintenu. De son coté Tomboy continue son petit bonhomme de chemin puisque le développement n'a jamais ralenti. La version 1.0.0 est même sortie le 21 septembre avec une nouvelle API de synchronisation vers un futur service web en ligne.
C'est maintenant qu'on va voir si Gnote correspondait vraiment à un besoin au sein du monde du libre. La communauté va t-elle mettre ses actes en accord avec ses sentiments anti-Mono et reprendre le développement de Gnote ou bien va t-il juste y avoir des lamentations, sans aucune suite ? Red Hat va t-il confirmer son choix d'opter par défaut pour Gnote et demander à ses développeurs de continuer le développement ou bien est-ce-que tout le monde va sagement s'aligner sur Tomboy ? Et, si c'est cette dernière solution qui s'impose, que vont pouvoir faire les utilisateurs de Gnote sur les systèmes BSD non x86 qui ne sont pas pris en charge par Mono ?
Beaucoup de questions qui attendent des réponses...
Aller plus loin
- Gnote (280 clics)
- Tomboy (138 clics)
- L'annonce de la fin du développement de Gnote (145 clics)
# quel est le besoin ?
Posté par Jean-Max Reymond (site web personnel) . Évalué à 4.
[^] # Re: quel est le besoin ?
Posté par pampryl . Évalué à 9.
Malheureusement, l'existence d'au moins une personne qui fasse évoluer le logiciel semble indispensable (au moins pour les distributions qui voudront l'intégrer)...
[^] # Re: quel est le besoin ?
Posté par grid . Évalué à 2.
ne me dit pas qu'il est setuid quand même. Après, c'est vrai qu'utiliser une appli sans mainteneur, c'est toujours risqué sur le long terme, il faudra un jour migrer.
[^] # Re: quel est le besoin ?
Posté par thedude . Évalué à 0.
C'est pas comme si on avait jamais vu un bufferoverlow avec execution de code dans un programme c/c++.
[^] # Re: quel est le besoin ?
Posté par grid . Évalué à 1.
Va falloir que tu m'expliques.
[^] # Re: quel est le besoin ?
Posté par thedude . Évalué à 5.
Ben s'il faut t'expliquer en quoi une execution de code arbitraire (en user ou en root) est un probeme, je crois qu'on a du boulot la...
[^] # Re: quel est le besoin ?
Posté par grid . Évalué à 1.
donc, oui, explique moi.
[^] # Re: quel est le besoin ?
Posté par thedude . Évalué à 3.
et le fait que l'attaquant utilise justement un buffer overlow comme point d'entree dans la machine et que donc, ca lui donne un acces qu'il n'avait pas, ca t'as traverse l'esprit?
[^] # Re: quel est le besoin ?
Posté par Graveen . Évalué à 3.
Pour une distrib, la pérénité est indispensable.
# Les deux sont bloated
Posté par ribwund . Évalué à 10.
Conclusion: les deux prennent plus de mémoire que emacs.
[^] # Re: Les deux sont bloated
Posté par monde_de_merde . Évalué à 5.
Mais je suis presque certain qu'on va me sortir l'un ou l'autre module complémentaire/fonction presque oublié/utilisation détournée d'Emacs qui permet de faire quasi la même chose que Gnote/Tomboy.
Mais quand même ça m'intrigue ça...
[^] # Re: Les deux sont bloated
Posté par Schnouki (Mastodon) . Évalué à 8.
http://orgmode.org/
Je suis personnellement fan de l'édition de tableaux (et de l'intégration de gnuplot pour avoir rapidement de jolies courbes sans avoir à passer par OOo et consorts).
<troll>C'est l'une des choses qui m'ont fait abandonner vim pour emacs ;-)</troll>
[^] # Re: Les deux sont bloated
Posté par パパフラクス . Évalué à 3.
L'édition de tableau, c'est du grand art, je suis admiratif. Si, si vraiment, essayez!
La gestion des check list est sympa aussi, avec la mise à jour récursive de tous les niveaux.
Le vrai avantage de org-mode, pour moi, c'est qu'il propose pleins d'outils, entièrement en mode texte dans un fichier.
Et ensuite on en fait ce qu'on veut, c'est vraiment très souple.
Dans le même genre, mais qui n'a rien à voir, la calculatrice scientifique incluse dans emacs est assez bluffante. D'ailleurs, à ce niveau là, je n'appelle plus ça une calculatrice!
[^] # Re: Les deux sont bloated
Posté par darkleon (site web personnel) . Évalué à 1.
Blague à part, 14.9MiB pour Gnotes (hors librairies partagées), Tomboy est plus gros de ~8Mib (~23Mib), ça devient vraiment du n'importe quoi pour la gestion des ressources.
Ce ne sont pas les ~200 caractères par notes qui vont aller occuper entre 15 et 20Mib de mémoire vive.
Et pourtant, quand je programme en Python ou Java, je suis le premier à laisser le GB à se débrouiller tout seul (en dehors de d'ajouter variable=null; pour faciliter son travail) à utiliser les fonctions HashMap ou Listes qui doivent bien occuper x fois plus de mémoire qu'un tableau d'octets gérée à la mimine.
Mais x doit surement être inférieur à 10 à la méga louche.
Ok, on a des Gib, mais sans vouloir optimiser en assembleur, il y a une différence entre choisir le mauvais algorithme (occupation mémoire) et un algorithme plus adapté par définition.
C'est exactement le même débat avec la vitesse, ça ne sert à rien de programmer un tri à bulle en assembleur quand un shell sort même en basic sera plus rapide sur des millions d'éléments.
Après il y a les buffers écrans, une zone 640x512 en 24bits, c'est un buffer de ~1Mib, ce buffer est pris du côté de X11 ou de l'application ? (si c'est du côté de X11, c'est pire que j'imaginais).
[^] # Re: Les deux sont bloated
Posté par Mr Kapouik (site web personnel) . Évalué à 3.
Conclusion : Prenez vos notes sous vim !
[^] # Re: Les deux sont bloated
Posté par Sébastien B. . Évalué à 1.
[^] # Re: Les deux sont bloated
Posté par mathieu_c . Évalué à -2.
Emacs date d'une toute autre époque ou les quelques mégaoctets occupé en RAM ont justifié la création de microemacs pour tourner avec les 512 Ko d'un Amiga 500 (entre autres)
Aujourd'hui, Tomboy et Emacs ont une consommation de mémoire ridicule et j'ai du mal a dire qu'une appli est bloated sans qu'elle occupe au moins 512 Mo ...
[^] # Re: Les deux sont bloated
Posté par patrick_g (site web personnel) . Évalué à 9.
Est-ce que tu a cliqué sur le lien signalant l'amélioration de perfs qu'apporte Gnote et que j'ai mis dans la news ?
Extrait :
À froid (après avoir flushé les caches):
* Tomboy = 12.110s
* GNote = 5.138s
À chaud:
* Tomboy = 2.394s
* GNote = 0.909s
[^] # Re: Les deux sont bloated
Posté par thedude . Évalué à 1.
Ce genre d'appli, c'est typiquement le genre de truc qui tourne en permanence, qui est lance automatiquement au demarrage.
Et un os bien concu et bien utilise, tu le redemarres uniquement pour les updates necessitant un reboot, le reste du temps tu veilles/hibernes.
Alors, tres honnetement, gagner 7 secondes une fois par mois, qu'est ce qu'on s'en balance...
# Tomboy plus complet que Gnote
Posté par Loic Dreux . Évalué à 6.
Quand Tomboy est passé en version 1.0, j'ai laisser tombé Gnote car en plus d'être plus abouti, Tomboy possède de nombreux plugins pour Gnome Do, Deskbar ou Tracker,
[^] # Re: Tomboy plus complet que Gnote
Posté par monde_de_merde . Évalué à 0.
D'accord c'est écrit en Mono et c'est inclus dans gnome mais quand même...
[^] # Re: Tomboy plus complet que Gnote
Posté par Jb Evain (site web personnel) . Évalué à 5.
[^] # Basket.kde.org -
Posté par NickNolte . Évalué à 1.
Ce n'est pas un simple carnet de note, là où découperait une image dans un journal pour l'apposer sur une page d'un cahier avec quelques annotations, avec basket, ce que tu as capturé à la souris (texte+images dans un navigateur) est importé aisément dans un des panneaux de basket .
Et puis y a un tas de fonctionnalités: mise en forme, protection par clé, intégré des actions etc...
Dommage que l'interface est alourdie par un tas de boutons.
Je crois d'ailleurs qu'il y a un outil similaire sous Mac OS X.
[^] # Re: Basket.kde.org -
Posté par nicko . Évalué à 2.
[^] # Re: Basket.kde.org -
Posté par Albert_ . Évalué à 2.
et je suis d'accord c'est une des applis kde3 qui me manque vraiment.
[^] # Re: Basket.kde.org -
Posté par Albert_ . Évalué à 2.
[^] # Re: Basket.kde.org -
Posté par cedbor . Évalué à 2.
# Utilité de l'appli
Posté par internet . Évalué à 10.
Je l'ai un peu utilisé au début et je pense que l'outil est beaucoup trop complexe pour la majorité des gens.
D'autre part, de tous les linuxiens que je connaisse, aucun ne s'en sert régulièrement. Les utilisateurs les plus avancés s'en servent quelques jours puis abandonnent, et les débutants ne comprennent pas du tout son intérêt et lui préfèrent les sticky notes (qui sont pourtant très mal foutues).
Du coup, quitte à avoir par défaut une appli qui ne servira pas à tout le monde, autant éviter qu'elle ne ramène des libs en plus…
[^] # Re: Utilité de l'appli
Posté par lezardbreton . Évalué à 3.
# hmmm
Posté par dufour olivier . Évalué à 0.
Je trouve ca super utile a tel point que j'ai chercher un outil similaire pour Windows pour le boulot....
Sinon, bon sur la polémique Mono, c'est comme samba et wine.
Il y a les puristes et ceux qui veulent juste de bon logiciel et pouvoir échanger avec windows.
(je sens que ca va partir en troll si j'en dit trop...)
D'autant plus que ce n'est pas si évident que cela. Personnellement, je trouve la techno .Net intéressante et les problèmes de mono sont liés au techno ADO.NET et ASP.NET qui ne sont pas utilisés dans tomboy ou banshee.
Après Gnote a fait la même chose que mono : copié un bonne outil.
Il est juste dommage de perdre du temps a copier au lieu de créer de bon logiciel (peu importe la techno)...
[^] # Re: hmmm
Posté par patrick_g (site web personnel) . Évalué à 9.
[^] # Re: hmmm
Posté par Ghis . Évalué à 6.
Personnellement j'aurais préféré un environnement homogène, basé sur un seul framework complètement libre portable et bien pensé ou les appli pourraient facilement communiquer entre elles (Il y avait un temps ou j'avais placé beaucoup d'espoir dans le développement de GNUstep, mais il n'a jamais vraiment décollé).
[^] # Re: hmmm
Posté par dufour olivier . Évalué à 6.
On veut laisser le choix mais du coup c'est très hétérogène et beaucoup de forces sont perdus a sans cesse réinventer la roue.
Déjà freedesktop tente de rendre homogène plusieurs points de gnome et KDE et je pense que c'est un mal nécessaire!
Après pour rendre les frameworks interropables c'est pas gagné....
Déjà les frameworks évitent les 10 000 libs qui font la même chose...
Tout le problème est d'avoir un framework qui puisse être multi languages (python, c, c#, vb, java, javascript, ruby, php...) et multi OS open source, patent free avec des languages fortement et faiblement typés.
Mono est celui qui s'en rapproche le plus mais bon le multi OS c'est loin de marcher aussi simplement... le multi langage: ironpython c'est pas tout à fait python.... et patent free est le principal handicape. même si cela permet de migrer des applis windows sous linux et que cela se limite à 2 briques avec des patents. MS a beau jurer, il faudrait avoir une alternative à ADO.NET (qui ne se base pas dessus) sous Mono et et proscrir son utilisation et celle de ASP.NET. Il semble que LINQ se base maintenant sur dblinq mais je ne sais pas si ce dernier utilise ADO.NET. Si ce n'est pas le cas Mono devrais pousser pour isoler ADO.NET dans un package a part. Si ils réussissent cela, j'espère que les querelles s'arrêteront...
Personnellement, j'adore le système de VM qui permet d'éviter le plantage complet d'une machine. Mais quand il faut de la performance brut c'est pas top. Cependant, il est possible d'y remédier via un appel a une bib C via Pinvoke. C'est ce que fait banshee.
[^] # Re: hmmm
Posté par Graveen . Évalué à 2.
[^] # Re: hmmm
Posté par Gniarf . Évalué à 4.
> Tout le problème est d'avoir un framework qui puisse être multi languages (python, c, c#, vb, java, javascript, ruby, php...)
faudrait savoir, là tu tiens à avoir 10 000 langages qui font la même chose... ( python/ruby ou python/php, c# et java, vb et javascript...)
[^] # Re: hmmm
Posté par rewind (Mastodon) . Évalué à 2.
C'est ce que ce sont dit tous ceux qui ont commencé l'écriture d'un DE. Et l'expérience montre qu'il n'y a pas qu'une seule vision de ce que doit être un DE (et tant mieux !)
[^] # Re: hmmm
Posté par tanguy_k (site web personnel) . Évalué à 10.
AHMA KDE/Qt remplit tous ces critères
[^] # Re: hmmm
Posté par 2PetitsVerres . Évalué à -9.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: hmmm
Posté par Albert_ . Évalué à 3.
[^] # Re: hmmm
Posté par 2PetitsVerres . Évalué à 8.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: hmmm
Posté par nomorepost . Évalué à 10.
[^] # Re: hmmm
Posté par Ghis . Évalué à 3.
Mais coté utilisateurs ont se retrouve avec vite une cohabitation d'environnements très disparates et aux fonctions globalement toutes redondantes. En bien sur toute les applications reposant sur ces diffèrent environnements ont souvent du mal à bien communiquer entre elles.
[^] # Re: hmmm
Posté par Graveen . Évalué à 1.
c'est exact, mais on peut argumenter de la même façon avec Java.
Quand je vois un gestionnaire de téléchargement en Java, ou une appli pour piloter le lcd d'un G15 depuis SongBird...
Disons qu'on peut se faire une raison en se disant que la portabilité est à ce prix ?
[^] # Re: hmmm
Posté par patrick_g (site web personnel) . Évalué à 7.
[^] # Re: hmmm
Posté par Camille_B . Évalué à 1.
Tomboy ça tourne sous windows et macosx, il y a des paquets tout prêts.
Je n'ai rien vu de tel pour gnote, les portages ne me semblent pas encore avoir été faits.
[^] # Re: hmmm
Posté par patrick_g (site web personnel) . Évalué à 3.
Tu fais quoi ?
[^] # Re: hmmm
Posté par Jar Jar Binks (site web personnel) . Évalué à -7.
[^] # Re: hmmm
Posté par patrick_g (site web personnel) . Évalué à 2.
[^] # Re: hmmm
Posté par Jar Jar Binks (site web personnel) . Évalué à 1.
[^] # Re: hmmm
Posté par Antoine . Évalué à 5.
[^] # Re: hmmm
Posté par Jakie Kasperwsky . Évalué à 3.
http://live.gnome.org/Tomboy/Installing/Windows
[^] # Re: hmmm
Posté par ploum (site web personnel, Mastodon) . Évalué à 1.
Mes livres CC By-SA : https://ploum.net/livres.html
# Trolling phail
Posté par gaston . Évalué à 1.
Beaucoup de troll qui appelle au troll surtout. patrick_trolling_is_my_way_of_life_g nous a habitué à mieux :)
[^] # Re: Trolling phail
Posté par patrick_g (site web personnel) . Évalué à 1.
Tiens ça ferait un chouette tshirt ça ;-)
Je vais chercher sur le net ou est-ce que je peux me le faire faire.
[^] # Re: Trolling phail
Posté par nomorepost . Évalué à 2.
Si tu t'habilles pas en XXL, ca sera écrit tellement petit que personne ne pourra te reconnaitre.
[^] # Re: Trolling phail
Posté par Calve . Évalué à 2.
Et hop, un tshirt perso qu'il est bien :)
[1] http://www.google.com/search?hl=fr-FR&q=papier%20transfe(...)
# Microsoft va-t-il LIBÉRER .net ?
Posté par Amine "nh2" Brikci-Nigassa (site web personnel) . Évalué à 1.
http://rss.slashdot.org/~r/Slashdot/slashdot/~3/4ztn5Z7xSx8/(...)
Gnote n'aura-t-il plus de raison d'être ?
GNU's Not Unix / LINUX Is Not Unix Xernel
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par O'neam Anne . Évalué à 2.
Ce que Microsoft a mis sous licence Apache, c'est une implémentation de .NET.
Hors, Tomboy était déjà basé sur une implémentation libre de .NET, en l'occurrence Mono.
LinuxFr, parfois c'est bien de la MERDE : https://linuxfr.org/users/c2462250/journaux/ecriture-inclusive-feministes-et-wikipedia#comment-1793140
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par Albert_ . Évalué à 9.
Nope this framework is for mobile devices and the 360.
Microsoft is really dieing in the mobile space right now. WinMo 6.5 Still doesn't have native support capacitive touch screens and the Mobile world is on fire with Android and of course the iPhone.
HTC, LG, and Samsung are all developing or have released Android phones.
Palm and Motorola are now dropping WinMo and going with WebOS and Android.
This is one space where Microsoft is at best an also ran and really is dropping in the race for mind share.
En gros cela sert a rien pour mono sur pc et donc pour tomboy. Toujours aucun interet et mono est toujours 3 trains en retard. Le jour ou ce dernier sera capable de faire tourner le dernier paint.Net sous linux vous faites signes. Autre exemple comme quoi cela sert a rien, en dehors de permettre a Microsoft de faire croire que ce sont des gentils, moonlight qui lague serieux derriere silverlight non pas que je l'utiliserai mais bon. Donc en dehors des trucs venant de la communaute opensource il y a rien qui sert dans .Net pour nous donc autant developper dans un langage et sur une plateforme dont l'evolution ne depend pas uniquement de l'entreprise qui a declare la guerre au mouvement opensource.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par Mathieu Segaud . Évalué à 3.
C'est sûr que s'il s'agit de pleurer sur des techno qui n'auraient AUCUN intérêt dans un environnement unix, être anti-Mono c'est cohérent, dans le plus pur style Roy Schestowitz :)
Y a des trolls moins fatigants et bien plus drôles que celui-ci, et franchement si vous êtes convaincus du contraire, allez sur bn.com, ça fatigue vite et décrédibiliserait n'importe quel mouvement aussi réaliste qu'il soit.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par Albert_ . Évalué à 2.
Apres les problemes juridiques sont encore un truc different. Que des devs du libre veulent utiliser cela (je soupconne que comme ca ils peuvent avoir sur leur CV C# ce qui peut etre utile dans ce monde fagocite par microsoft) je le concoit aussi. Mais par contre en tant que tel cela ne sert a rien pour linux ou tellement peu que cela en est risible vu les efforts humains et financiers mis dedans.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par Gniarf . Évalué à 4.
lesquelles ?
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par Jul (site web personnel) . Évalué à 2.
alternative à CLR : n'importe quel VM ou interpréteur portable (parrot, jvm ...). Chaque language du CLR n'étant qu'un sucre syntaxique.
alternative à .Net (l'intégration système) : ruby, python ont aujourd'hui des systèmes de gestion de paquets (easy-install), de middle ware (webrick), de chrootage système leur permettant d'être relativement proche fonctionnellement.
Le seul truc non existant en libre mais rarement utilisé par les développeurs proprio reste le système de diffusion de paquet/signature/déploiement automagique qui ma foi reste intéressant.
Là où python, ruby et perl sont meilleurs c'est justement sur les repository (cpan). Les bibliothèques de bases du Csharp sur les encodages de mails sont incapables de produire des mails conformes aux rfc par exemple.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par Jar Jar Binks (site web personnel) . Évalué à 3.
Alternative à CLI : les JVM, avec toutes leurs subtiles incompatibilités, quelle recommandation géniale. Et bien sûr, aucune autre VM ne supporte autant de langages que la CLI - à part LLVM, dont la cible est différente (il y a même un compilateur CLI vers LLVM si je ne m’abuse).
Alternative à .Net : la gestion des paquets Python, c’est une véritable farce, qui a été conçue par des gens ne comprenant strictement rien à la production. Et c’est un développeur Python qui te parle. Il faut se battre tous les jours pour avoir quelque chose qui marche de manière pas trop pourrie avec toutes les merdes que les développeurs de setuptools arrivent à inventer. Je ne parle même pas de Ruby, c’est encore pire. Si Python voulait faire les choses correctement, il faudrait justement s’inspirer… du Global Assembly Cache de Mono, une solution propre et ne nécessitant pas de bidouilles ingérables pour les distributeurs.
Quant aux bibliothèques, entre avoir 17 implémentations pourries de chaque fonctionnalité et une qui marche, c’est vite choisi. Pour accéder aux bases de données par exemple, Python tient vaguement la route avec la DB-API, mais la qualité des implémentations est complètement minable par rapport aux versions managées fournies avec Mono, et il manque le support de certaines bases. Tout le reste est à l’avenant.
Bref, j’aime beaucoup Python et je l’utilise tous les jours, mais si aujourd’hui je devais concevoir une nouvelle application de plus de quelques milliers de lignes de code, je le ferais sans hésitation avec Mono. Il faut savoir comparer ce qui est comparable.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par HardShooter . Évalué à 5.
Bah évidement parce que t'aurai beaucoup plus de trucs a implémenter pour faire des milliers de lignes de python
Je suis déjà loin, pas taper...
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par darkleon (site web personnel) . Évalué à 7.
Première phrase, premier Troll.
Esthétiquement, on peut préférer .NET ou JAVA pour la syntaxe et les noms des libs, mais grosso-merdo, ils ont les mêmes limites et les mêmes concepts.
Alternative à CLI : les JVM, avec toutes leurs subtiles incompatibilités.
Je ne veux pas dire, mais travaillant sur JAVA depuis 2000 surtout dans les applis web.
Dans ce cadre là, j'ai rencontré 2 cas, ou il fallait recompiler les jar sur la plate-forme de production, parce qu'on avait pas une JVM du même éditeur sur les postes développeurs, et encore c'était en 2001-2002 avant que la norme J2EE soit mieux respectée.
Alternative à .Net :
Il faut bien comprendre que MS à commencer a pousser .NET quand Linux est devenu une menace plus sérieuse pour eux dans la mesure ou Linux n'est pas limité au x86 pour les applications dont on dispose le source.
Pour distribuer un "binaire" tout en étant indépendant du matériel sous jacent, il faut une VM.
Il y a quelques années, MS annonçait de migrer toutes leurs applications sous .NET pour être indépendant du matériel.
Je constate que depuis que les technologies de virtualisation sont plus courantes, MS se fait plus discret sur cette migration.
Autrement pour Python, je suis d'accord, j'adore ce langage, mais il manque une certaine cohérence pour le choix d'une bibliothèque.
mais si aujourd’hui je devais concevoir une nouvelle application de plus de quelques milliers de lignes de code,
Si les gros éditeurs décidaient du jour au lendemain de basculer tout en Python/Ruby/OCAML/Lisp/Haskell/..., tu aurais exactement les outils qu'ils te manquent à l'heure actuelle qui accompagnerait ce nouveau choix "industriel"
Pour faire des applications "professionnelles" (c'est à dire développé pour une entreprise par elle même ou une société de service), il faut une taylorisation des moyens pour interchanger les développeurs entre projets. Donc il faut pouvoir tenir les développeurs par la main.
Forcément le monde du libre, c'est la liberté de faire ses propres choix, c'est moins cadré.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par Gniarf . Évalué à 6.
bullshit. avec Java on n'avait justement plus besoin que d'une JVM qui tenait la route.
non, le but a été de tuer Java, justement.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par darkleon (site web personnel) . Évalué à 1.
Oui et non, quand .NET a été lancé, les applications "lourdes" java n'étaient plus vraiment une menace, il y en a, mais par rapport à leur coeur de marché, solutions OS + solutions bureautiques, Java ne les menaçaient plus.
Il faut voir qu'au même moment MacOS passait sur x86 après PPC et 68k, MS n'avait pas une telle souplesse dans le choix de leurs plate forme.
Il devenait urgent pour eux d'avoir la possibilité de s'affranchir du matériel.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par Gniarf . Évalué à 6.
oh, il suffisait de ne pas s'en servir, certes. mais comme les assistants de création de code et autres wizards s'en servaient, comment dire... ah, si : ce n'était plus du Java. on les retrouvera dans C#
quand au "lancement de .NET", comment dire, c'est le genre d'évenement monstrueux qui se décide et se planifie sur plusieurs années. à cette époque le rêve d'un OS écrit en Java comme de suites bureautiques écrites en Java ne s'était pas écroulé, des boites comme Corel ou Lotus y croyaient dur comme fer, des grosses comme IBM ou Oracle ont fait plus que s'y interesser.
maintenant oui bon quand des bouts de .NET sont effectivement sortis des labos, tout le monde s'était aperçu depuis longtemps que beaucoup des promesses de Java n'avaient pas été tenus et ne le seront jamais. ça a même sacrément joué en défaveur de .NET au départ : "oh non, pas encore !" vu que les prémisses étaient les mêmes.
> Il faut voir qu'au même moment MacOS passait sur x86 après PPC et 68k, MS n'avait pas une telle souplesse dans le choix de leurs plate forme.
euh, tu voulais qu'ils fassent quoi, vu qu'ils étaient déjà sous x86 ? :) "chef, on est sur la meilleure plateforme du marché, la plus commercialement porteuse et tout et tout, on migre tout sur la plus pourrie juste pour le fun ?" "oh oui chic, tirons-nous une balle dans le pied \o/ et même un boulet \o/"
pour rappel, Microsoft a déjà lourdement influé sur le design des x86 par le passé en imposant ses 4 volontés à Intel "il nous faudrait ça et ça, ça nous serait super utile pour la commutation de taches sous Windows" "non" "SI."
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par darkleon (site web personnel) . Évalué à 3.
La génèse:
http://www.experiencefestival.com/a/microsoft%20.net%20-%20h(...)
En fait c'est un labo MS qui avait fait des proto en J++ car le langage leur permettait de développer plus rapidement, du coup, ils en ont fait un autre estampillé MS only, .NET
Ils avaient quand même bien fait la promo WORA (write once run anywhere) à l'époque, il parlait de migrer Office en .NET rapidement pour le déployer facilment sur plusieurs OS.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par Gniarf . Évalué à 3.
des petits gus comme Hejlsberg (Delphi...)
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par Jul (site web personnel) . Évalué à 5.
Pour Tk/Tcl il suffit d'installer amsn qui marche identiquement sous linux/windows/macOSX et tout le toutim, et ensuite de regarder le source (le gars est bon).
Okay le Tcl est pas sexy. Mais c'est graphique multiplateforme, bien fait, avec une syntaxe ignoble. Mais ça fait le job, et bien. Aucune plate-forme (java, mono, .net, Qt) à mon gout ne fait aussi bien que cela pour un aussi faible coût en ressource, infra et complexité.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par darkleon (site web personnel) . Évalué à 2.
Un truc moderne qui a le meilleur rapport puissance/code/portabilité, c'est REBOL
http://www.rebol.com/prod-view.html
http://rebolzone.free.fr/rbpresentation.php
~700 kio pour l'interpreteur+framework pour faire des programmes client qui rend naturel le passage des données sur le réseau avec d'autres clients ou services REBOL
Quelques programmes d'exemples
http://www.rebol.com/pre-view.html
Gros problème, ce n'est pas un langage libre, du coup ça refroidit. Il y a des bouts de code dans le monde libre, mais pas de solutions de remplacement au cas où. C'est un peu comme le langage D qui me semble intéressant, mais ne pas partager un langage, c'est un peu un non sens.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par Jar Jar Binks (site web personnel) . Évalué à 1.
Wow. Là je crois que tout est dit.
Continue de t’enfoncer tout seul, même pas besoin de répondre.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par darkleon (site web personnel) . Évalué à 5.
C'est bien la technique, mais c'est un moyen, à la fin de la journée ce qui compte ce n'est pas la techno utilisée, mais est-ce que le truc développé répond AU besoin.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par Jul (site web personnel) . Évalué à 4.
Tcl/Tk est peut être une antiquité, mais il fait bien le write once run everywhere ainsi que la compatibilité multiOS que .Net/mono et java sont censés apportés. De plus il est plus portable et simple à installer, et permet de développer rapidement.
Il y a les codeurs qui passent leur temps à devenir les professionels de leurs outils, et les développeurs sont là pour apporter des solutions qui marchent à leur client.
On a peut être pas la même mentalité : je n'aime pas l'informatique, j'aime ce que l'on peut faire avec.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par Camille_B . Évalué à 2.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par dufour olivier . Évalué à 1.
Donc rien a voir avec mono, le fait que ca ne tourne pas sous linux...
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par sifu . Évalué à 1.
Franchement, je trouve que d'une façon général les applications vraiment multi-plateforme ne sont pas légion.
J'espère que le projet KeePass qui a choisi le .Net pour sa version 2.0 s'en sortira bien.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par Albert_ . Évalué à 5.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par TImaniac (site web personnel) . Évalué à 0.
Raisonnement totalement débile, comme d'hab avec toi.
Si demain je développe une application, exemple en Python + Qt, et que par soucis d'intégration et/ou perf je choisi d'appeler des libs natives non portables/portées, dois-je en conclure que celà montre qu'une appli Python/Qt utilisant le framework de Nokia a a peu pres aucune chance d'être multiplateforme ?
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par Albert_ . Évalué à -10.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par tanguy_k (site web personnel) . Évalué à 5.
Dommage il a parfaitement raison.
Ceci dit .NET ne doit pas simplifier l'integration aux differentes plateformes (pas l'objectif de MS) + les differentes GUI (WinForms, GTK#, WPF) n'aident pas. Qt par exemple aide au maximum le developpeur pour s'integrer a chaque OS et a ete pensé pour des le depart.
HS: quelqu'un a des infos sur une eventuelle implementation de WPF de l'equipe Mono ?
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par Albert_ . Évalué à 5.
Donc en dehors des trucs venant de la communaute opensource il y a rien qui sert dans .Net pour nous donc autant developper dans un langage et sur une plateforme dont l'evolution ne depend pas uniquement de l'entreprise qui a declare la guerre au mouvement opensource.
est toujours vrai malgre tout le temps, l'argent et les trolls investit dans mono. Dois t'on vraiment rappeller qu'un des arguments des defenseurs de mono au debut du troll fut que cela permettrait d'avoir facilement un port des applications Windows .Net sur toutes les plateformes supporte par mono. Cela a ete un leure et l'est toujours. J'attend toujours de voir la moindre application un peu consequente venant de Microsoft utilisant .Net donc soit disant portable, a mais non car ils utilisent SYSTEMATIQUEMENT des trucs specifiques a MS windows c'est balot, qui fonctionne sous linux. Vu que cela n'existe pas je ne vois pas l'interet d'utilise une techno qui reste toujours en retard (sur certains points au minimum) par rapport a l'implementation de reference. Alors qu'il existe des framework tel que Qt ou python qui sont multiplateforme et au meme niveau de support sur un nombre consequent de plateforme que ce soit windows, linux, BSD, MacOSX et j'en passe.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par TImaniac (site web personnel) . Évalué à 3.
T'as le droit de ne voir aucun intérêt dans cette techno, laisse les développeurs qui pondent des applications choisir là où sont leurs intérêts.
Que ca te plaise ou non, des gens utilisent Mono, c'est qu'ils y trouvent leurs intérêts.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par Albert_ . Évalué à 2.
C'est SURTOUT pas pour ne pas faire cela vu que cela n'est pas visiblement possible.
'est offrir un certain niveau de compatibilité pour que ceux qui veulent faire du multiplateforme puisse le faire.
Heureusement que l'on a pas attendu Microsoft et .Net pour cela et comme je l'ai deja dit il existe autre chose pour faire cela.
T'as le droit de ne voir aucun intérêt dans cette techno, laisse les développeurs qui pondent des applications choisir là où sont leurs intérêts.
Je leur laisse, je n'ai jamais mis un pistolet sur la tempe d'une personne pour l'obliger a coder dans tel ou tel langage. Je trouve dommage la perte de temps et d'argent qui est mis dans un truc fondamentalement inutile pour le libre c'est tout. Par contre je me permet de contrer les evangeliste redmondien tel que toi en esperant que la propagation de ce truc ne va pas s'intensifier.
Que ca te plaise ou non, des gens utilisent Mono, c'est qu'ils y trouvent leurs intérêts.
Je m'en tape tant que l'on ne me force pas non plus a me taper ce truc et que l'on arrete de pretendre que c'est la panacee et que c'est le meilleur truc qui soit arrive au libre. C'est une techno qui sert globalement a rien et qui n'est pas du tout controle par le libre mais par la compagnie qui a declarer la guerre au libre. Rien que pour cela c'est un truc a eviter sur linux. C'est MON avis et je le partage avec moi meme c'est deja ca.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par nomorepost . Évalué à 1.
1- Tu récris tout en natif pour chaque plateforme.
Tout est parfaitement intégré mais t'as un boulot monstre en dev.
2-Tu écris tout en multiplateforme y compris la partie graphique.
C'est l'approche Java avec Swing/SWT
Le développeur n'a (presque) rien à réécrire mais c'est mal intégré et parfois tu es limité pour faire des trucs simples.
3- Tu essaies de définir un maximum de trucs bas-niveaux communs mais tu intègre nativement le haut niveau.
C'est l'approche Mono qui récupère nativement les parties Gtk et ne veulent pas des libs graphiques Windows pas standard.
Inconvénient tout n'est pas portable "out of the box". C'est un compromis
Chacune des approches a ses mérites et inconvénients, mais toi tu sais mieux que plein de gens que la dernière est forcement mauvaise et comble du comble tu accuses les autres de prétendre le contraire.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par Albert_ . Évalué à 9.
mais toi tu sais mieux que plein de gens que la dernière est forcement mauvaise et comble du comble tu accuses les autres de prétendre le contraire.
Je dis et je maintiens que certaines personnes devraient arreter de lire en diagonal avant d'utiliser les insultes...
https://linuxfr.org/comments/1082672.html#1082672
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par nomorepost . Évalué à 1.
Si j'ai pris la comparaison avec Java, c'est juste à cause de toutes les autres libs et du runtime.
avant d'utiliser les insultes...
Ouah tu discernes des insultes dans cette phrase ?
mais toi tu sais mieux que plein de gens que la dernière est forcement mauvaise et comble du comble tu accuses les autres de prétendre le contraire.
Le simple fait d'être en désaccord avec toi constitue une insulte.
Quelle susceptibilité !
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par Albert_ . Évalué à 3.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par nomorepost . Évalué à -5.
Etonnant !
Je dois vraiment répondre à un tel ramassis de mauvaise foi
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par Albert_ . Évalué à 1.
enfin heureusement que KDE fournit un truc qui permet une bonne integration que ce soit d'un cote ou de l'autre car il faut pas compter sur Gnome pour faire cela.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par TImaniac (site web personnel) . Évalué à 3.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par Albert_ . Évalué à 0.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par nomorepost . Évalué à 2.
C'est petit !
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par Albert_ . Évalué à 1.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par TImaniac (site web personnel) . Évalué à 5.
Waouh, au taf ma prochaine application sera probablement en C++/Qt. Dingue non ?
T'en a pas marre d'être toujours à côté de la plaque dans tes commentaires ?
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par Anonyme . Évalué à -5.
[^] # Commentaire supprimé
Posté par thedude . Évalué à -2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par grid . Évalué à 3.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par Albert_ . Évalué à -1.
1) j'ai paye comme a peu pres tout le monde la taxe Microsoft donc "l'accord" Novell c'est bien avec mon argent qu'il a ete fait.
2) Je sponsorise certaines distribution (que je n'utilise pas forcement d'ailleurs) et lorsque des personnes sont mise dessus pour integrer voir pire developper cet techno c'est donc moi qui paie aussi.
[^] # Commentaire supprimé
Posté par thedude . Évalué à -2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par tanguy_k (site web personnel) . Évalué à 4.
Ah ?
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par gnumdk (site web personnel) . Évalué à 3.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par nomorepost . Évalué à 3.
C'est assez amusant de voir que lorsqu'on déplace la discussion sur le plan technique en justifiant que ca puisse être une approche plausible, tu te réfugies derrière le coté idéologique pour couper court.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par briaeros007 . Évalué à 2.
Mal intégré ? Ca dépend du travail sur le système cible, c'est comme tout.
Tu travaille une fois.
3- Tu essaies de définir un maximum de trucs bas-niveaux communs mais tu intègre nativement le haut niveau.
Qu'est ce que mono définis de "bas niveau" ?
C'est l'approche Mono qui récupère nativement les parties Gtk et ne veulent pas des libs graphiques Windows pas standard.
gtk est déja multiplateforme...
et gtk c'est du haut niveau (c'est un framework complet quand même).
Inconvénient tout n'est pas portable "out of the box". C'est un compromis
Quand le compromis fait en sorte que l'objectif principal du truc est "out", j'appelle ca un compromis de merde. Ensuite chacun fait comme il veut.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par _flo_ . Évalué à 3.
L'objectif principal de .NET est de faire cohabiter aisément différent langages sur une meme "plate-forme", en partageant notamment le meme modele objet. L'objectif de mono est de proposer .NET sur d'autres environnements que Windows, te laisser choisir. Je ne pense pas que le but soit forcément de pouvoir ecrire des applis multi-plateformes en .NET, c'est plus un effet de bord a mon sens.
Ne pas confondre avec Java ou l'objectif est d'etre multi-plateforme, d'ou la lourdeur du JNI par exemple (enfin je crois que c'est fait exprès, rassurez moi?! =)
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par briaeros007 . Évalué à 2.
Il y avait déjà pléthore de solution qui existait bien avant .NET, dont l'une des plus connu, java.
Si pour toi .NET/Mono se résume a ça, m'est d'avis que tu aimes bien réinventer la roue.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par TImaniac (site web personnel) . Évalué à 6.
Mais oui y'a des gens qui aiment bien réinventer la roue, en l'améliorant, etc. On appelle ça la concurrence, la saine émulation, dont tout le monde profite, et même les développeurs Java.
On montrera pas dans le libre le nombre de projet qui ne sont là que pour réinventer la roue : les gens le font parcqu'ils trouvent ca fun, parcqu'ils rajoutent une killer-feature ou je ne sais quoi : parcqu'ils ont envie.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par briaeros007 . Évalué à 3.
Venez juste pas dire que c'est achement mieux que les autres, que ca fait des tas de trucs que les autres ont jamais fait quand c'est faux. C'est tout.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par TImaniac (site web personnel) . Évalué à 5.
Moi je trouve .NET mieux que Java sur certains points, certains d'entre eux ayant d'ailleur été repris par Java depuis, comme quoi c'est qu'il y avait des trucs intéressants dedans.
Mono est né à cause de ça : une socle technique bien plus sexy que Java et une envie de certains hackers d'avoir cette techno en libre sous Linux.
Alors si, je le dis, je trouve Mono/.NET ouachement mieux que Java, de mon point de vue.
Je trouve le langage C# ouachement mieux que le langage Java : event, property, linq, lambda, inférence de type, etc.
Je trouve le socle technique ouachement mieux :
- conçu multi-langages : c'est standardisé et dispo dès le départ.
- conçu pour les langages statiques et maintenant dynamiques, toujours de manière standardisé.
- conçu pour être totalement compilé : tourne par exemple sur iPhone.
- passerelle vers code natif beaucoup plus clean et simple d'utilisation que JNI.
Après tu trouveras sûrement tout ça ailleur, mais pas ensemble : et moi c'est tout ca sur la même plateforme qui la rend sexy. Et c'est pour la même raison que beaucoup de développeurs utilisent Mono.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par darkleon (site web personnel) . Évalué à 4.
Je ne connais pas très bien le C# en dehors de sa syntaxe de base (qui est "C like" comme le java), ce que j'en ai vu, c'est que c'est une réponse à JAVA de MS.
Le côté positif, ça a aussi accéléré le développement JAVA qui s'endormait un peu et qui a reçu un coup de pied au derrière quand MS à mis les bouchées doubles pour séduire les développeur entre la 2.0 et 3.5.
Du coup, ils se font la course, quand un des deux introduit un nouveau truc, l'autre le reprend dans la version d'après.
Après comme je le dit dans un autre post, grosso merdo c'est la même chose, les fonctionalités avancées seront utilisées par 0.01% des développeurs et les bibliothéques disponibles dans chacune des solutions couvrent les besoins application "buisness" .
Perso, je n'aime aucun des 2 langages, je les trouves trop verbeux, mais en milieux entreprise, difficile de ne pas tomber sur l'un ou l'autre des languages.
Néanmoins, pour une entreprise non spécialement MS Fan Boy, JAVA est un choix plus pérenne pour ses applications internes.
Maintenant, si je me trouvais dans une société 100% équipée MS, je partirais plutôt sur un choix .NET.
Je trouve le socle technique ouachement mieux :
...
Je trouve le hardware+assembleur vachement mieux,
- conçu multi-langages : c'est standardisé et dispo dès le départ.
- conçu pour les langages statiques et maintenant dynamiques, toujours de manière standardisé.
- conçu pour être totalement compilé : tourne par exemple sur iPhone.
- passerelle vers code natif beaucoup plus clean et simple d'utilisation que JNI.
^_^
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par TImaniac (site web personnel) . Évalué à 1.
Grosso modo, Java est derrière.
J'ai cité des trucs de C# (et pas des moindres) qui ne sont pas (encore) dans Java : inférence de type, expression lambda, LINQ, event.
C'est pas 0,01%.
Ce sont de grosses différences.
Néanmoins, pour une entreprise non spécialement MS Fan Boy, JAVA est un choix plus pérenne pour ses applications internes.
Il suffit que l'entreprise est un historique d'applications hétérogènes dont certaines sont écrites en VB ou en VisualC++ pour que .NET est un intérêt indéniables : techniquement il est beaucoup plus facile d'intégrer/migrer du code dans ces technos en .NET qu'en Java.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par darkleon (site web personnel) . Évalué à 1.
Je parlais du nombre de développeurs qui sauront utiliser les expressions lambda et les inférences de type (en plus C# supporte la surcharge d'opérateurs, selon le codeur, ça va vite devenir le bordel et tu seras obligé de marquer les types pour rendre le code plus lisible pour l'humain et le compilateur).
C'est super techniquement, mais pour la maintenance et les vérifications des contrats des fonctions on repassera.
LINQ :
Java Persistence Query Language (JPQL) qui provient de Hibernate Query Language (HQL)
Et pour les opérations CRUD, tu as encore plus simple JPA
event : c'est du "sucre syntaxique", c'est une bonne chose, ça rend le code moins verbeux, mais ce n'est pas un changement de paradigme.
Je ne suis pas spécialement fan de JAVA, mais les arguments avancés ne sont pas les bons pour préférer C# ou JAVA.
Il suffit que l'entreprise est un historique d'applications hétérogènes dont certaines sont écrites en VB ou en VisualC++ pour que .NET est un intérêt indéniables
Ton exemple rentre dans la catégorie entreprises 100% MS, et il ne faut pas être con, autant utiliser C#.
Maintenant mon point de vue est biaisé, je n'ai fait que des applications WEB au travail (et des scripts de conversion basiques que je peux écrire en n'importe quel language), donc l'adhérence avec un framework "bureau/application graphique" n'est pas mon soucis principal.
Et c'est la tendance en entreprise.
Maintenant, pour faire une application graphique "lourde" pour entreprise, mon choix de language/framework dépendra de l'OS (MS->.Net, Apple->Objective-C, Linux -> C++ et QT), mais pour le coup, je ne m'ennuirais surtout pas à en faire une en JAVA/SWING.
Pour un projet perso, plutôt python avec éventuellement des functions en C pour des parties de calcul critique. Je connais et je peux récupérer le code sur MS,APPLE,UNIXES
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par TImaniac (site web personnel) . Évalué à 2.
N'importe quel développeur qui lis un tuto.
Franchement tu vois une difficulté à écrire :
var res = maListe.Where(e => e.Value == 2);
N'importe quel développeur est capable d'écrire celà. Et y'a une expression lambda + de l'inférence de type.
Java Persistence Query Language (JPQL)
Dans LINQ, y'a un I pour "Integrated".
En C# aussi il existait NHibernate et son HQL avant.
LINQ, c'est une syntaxe "native" au langage avec tous les atouts que cela comporte. Et c'est pas limité à la persistence.
Bref, y'a aucun équivalent à LINQ dans Java à l'heure actuelle.
Peux tu écrire en Java un truc du style, avec typage fort, vérification par le compilo et complétion dans l'IDE :
var res = from e in maListe where e.Value == 2 orderby e.Name select new {e.Id, e.Name, e.Value.ToString() }
La ligne précédente fait appel à beaucoup trop de concept non présents en Java : types anonymes, inférence de type, lambda.
LINQ s'appui sur tous ces concepts.
event : c'est du "sucre syntaxique", c'est une bonne chose, ça rend le code moins verbeux, mais ce n'est pas un changement de paradigme.
Du sucre syntaxique qui s'appui sur la notion de "délégué", autrement dis de pointeur de fonction. Et ça c'est pas du sucre syntaxique et ca n'existe pas en Java.
Ton exemple rentre dans la catégorie entreprises 100% MS, et il ne faut pas être con, autant utiliser C#.
J'ai dis hétérogène, que y'es 20 40 ou 100% d'appli MS ne change rien : si une seule application critique est codée dans une techno MS, il est beaucoup plus pertinent d'utiliser .NET que Java pour une transition en douceur.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par darkleon (site web personnel) . Évalué à 4.
http://fr.wikipedia.org/wiki/Dissonance_cognitive
C'est de l'auto persuasion pour se dire qu'on a fait le bon choix sur des critères ~équivalents (entre 2 TV de même taille et de même prix et de performances globale équvalentes, on a choisie "la meilleure" parce que, le cadre est plus joli/design plus sobre/le temps de réponse fait 1ms de moins/...)
Je ne nie pas les avancées de C#, ni même de son utilité, ni même des avantages à avoir une syntaxe plus concise.
En fait, on se dispute sur un problème de philosphie sur le degré "d'hackitude" du langage.
JAVA est plus rigide, tout est fait pour que tu codes de manière uniforme et en évitant le plus possible les pièges conceptuels. D'où à mon regret une syntaxe super verbeuse bien indigeste à lire dans certaines parties de code technique.
A contrario, un code super compressé sur une ligne n'est pas forcément plus digeste à lire aussi (cf one liner en perl/bash/...)
Apparement, tu as été séduit par le rapport expression compressé/lisibilité du C#, mais ça ne le rend pas plus puissant intrinsèquement.
Il ne faut jamais oublier qu'à partir du moment ou un langage est "Turing complét", tu peux tout faire (plus ou moins douleureusement en fonction de la spécialisation du langage).
Event
En JAVA tu passeras par une interface, ça rendra le code encore plus lourd à lire et verbeux, mais tu auras une sécurité sur le type de fonctions et la signature à passer. C'est pour cela que JAVA a laissé tomber le pointeur sur fonction du C.
Lambda expression
Pareil, pas de vérification de contrat de signatures sur les types (philosophie non java). Néanmoins, avec les types génériques, et l'interface, je n'y ai pas réfléchi, mais il y a surement moyen de gruger (avec plus de lourdeur syntaxique, je l'accorde).
LINQ
Effectivement, je n'avais pas vu les requête sur une liste d'objet, c'est rigolo la généralisation des principes.
Honnêtement, dans mon dernier projet, les sources de données étaient en BDD, donc c'est la requête SQL qui filtrait, néanmoins, il y a eu 5 ou 6 cas en 18mois ou j'aurais apprécié le principe de LINQ pour faire des filtres sur les collections au lieu de faire une boucle ou une fonction dédiée.
Mais bien évidemment, j'ai trouvé un équivalent sous java en cherchant un peu, mais ça ne fait pas partie des librairies standard.
http://quaere.codehaus.org/.
Peux tu écrire en Java un truc du style, avec typage fort, vérification par le compilo et complétion dans l'IDE
var res = from e in maListe where e.Value == 2 orderby e.Name select new {e.Id, e.Name, e.Value.ToString() }
Surement pas en une ligne, mais un code qui renvoie res avec les mêmes valeurs surement.
Franchement, des coders qui savent parfaitement utiliser la construction qui va bien dans le langage, je n'en connais pas beaucoup, surtout quand dans 90% des cas d'une application "buisness" tu va récupérer une liste, faire un filtre dessus, modifier un champs sur une ligne et réenregistrer cette ligne.
si une seule application critique est codée dans une techno MS, il est beaucoup plus pertinent d'utiliser .NET que Java pour une transition en douceur.
ça c'est n'importe quoi, ça dépend du type d'application.
Je prend un exemple extrême, mais si c'est de la réplication sur plusieurs machines et synchronisation par réseau en //, je pense qu'erlang sera beaucoup plus adapté que n'importe quel autre langage.
Deuxième contre argumentation, le choix de la nouvelle techno dépend du degré de connaissance de cette techno de ceux qui vont faire la nouvelle application. Si personne ne connait C# ni l'a mis en oeuvre, mais que ce sont tous des cadors en "autre langage", c'est "autre langage" qui te permetra une transition en douceur.
Mon but n'est pas de te convaincre d'abandonner C#, au contraire, il correspond à ton style et tu t'amuses avec, mais la liste des caractéristiques techniques d'un langage ne fait pas un programme, c'est le développeur et son degré de maitrise qui le fait.
Et quelque soit le langage, tu vas trouver des situations ou tu trouveras la syntaxe, le framework, des incohérences, bref des situations ou il sera lourdingue et CHIANT à utiliser. Dans les cas ou c'est sa force, tu trouveras le langage génial.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par TImaniac (site web personnel) . Évalué à 2.
Ben en même temps on est sur LinuxFR, Linux, un OS fait par des hackers, utilisé par des hackers, etc.
Il ne faut jamais oublier qu'à partir du moment ou un langage est "Turing complét", tu peux tout faire
Avec une argumentation comme ça, on aurait tous du rester au COBOL.
En JAVA tu passeras par une interface, ça rendra le code encore plus lourd à lire et verbeux, mais tu auras une sécurité sur le type de fonctions et la signature à passer.
C'est évidemment la différence entre C# et le C : le typage fort à travers la notion de délégué. Les délégués sont aux fonctions ce que sont les références aux objets : l'équivalent d'un pointeur mais avec la sécurité du typage fort.
Lambda expression
Pareil, pas de vérification de contrat de signatures sur les types (philosophie non java).
??? Tu peux expliquer ???
Mais bien évidemment, j'ai trouvé un équivalent sous java en cherchant un peu, mais ça ne fait pas partie des librairies standard.
http://quaere.codehaus.org/.
Non non et non, jel'ai pourtant clairement dit, dans LINQ il y a INTEGRATED : syntaxe native du langage. Pas une simple bibliothèque. Je le répète, mais LINQ en C# intègre les notions d'expression lambda, d'inférence de type, de type anonymes, autant de notions puissantes abstentes de Java.
Une requête LINQ est fortement typée, son utilisation ainsi que son résultat est validée par le compilateur.
Surement pas en une ligne, mais un code qui renvoie res avec les mêmes valeurs surement.
Evidemment tu peux arriver au même résultat, là n'est pas la question. La question réside dans la puissance des expressions et dans l'apport au développeur.
En l'occurence le développeur exprime ce qu'il veut obtenir plutôt que de coder une boucle for qui tente de déclarer le comment. L'approche est totalement différente.
Je prend un exemple extrême, mais si c'est de la réplication sur plusieurs machines et synchronisation par réseau en //, je pense qu'erlang sera beaucoup plus adapté que n'importe quel autre langage.
Erlang suppose une réécriture. Je te parle de pertinence dans le cas d'une application critique que l'on souhaite faire évoluer en douceur, justement parcque l'application est critique.
Après oui, si tu pars du principe qu'il y a une réécriture complète, tu peux avoir 36 langages pertinents.
Si personne ne connait C# ni l'a mis en oeuvre, mais que ce sont tous des cadors en "autre langage", c'est "autre langage" qui te permetra une transition en douceur.
J'ai pris le soin de mettre .NET et pas C# : si l'application est codée en VB, la transition se fera naturellement vers VB.NET. Si l'application est codée en C++, la transition se fera naturellement vers C++/CLI. C'est l'un des atouts de la plateforme : un socle commun et plusieurs syntaxes pour s'adapter aux compétences des développeurs.
Ce qui est rigolo, c'est que tu connais pas bien le langage C# mais tu restes persuader que c'est la même chose que Java.
Ils sont évidemment utilisés dans les mêmes contextes, mais il y a des différences notables qui pour moi permettent d'être plus productif. Tu l'admets toi même en disant qu'en Java tu peux faire pareil en plus lourd et plus verbeux. Oui tu peux aussi faire la même chose en Cobol en plus lourd et plus verbeux.
C# n'introduit pas uniquement des raccourcis syntaxiques. A moins que pour toi les paradigmes fonctionnels issus des langages ML ce soit que du sucre syntaxique.
Tu sembles persuader que tout ce qui différencie C# de Java ce ne sont que des choses non maîtrisées par les développeurs et donc globalement peu utilisées : C# est un langage industriel, et généralement la plupart des "raccourcis" correspondent à un besoin réel qui les rendent indispensables : le framework s'appui très fortement sur la notion d'event et de property par exemple.
Depuis le passage à LINQ, le framework de persistance BDD, le framework de collections d'objets ainsi que le moteur XML ont été bouleversés, et pour moi la productivité s'en ressent.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par darkleon (site web personnel) . Évalué à 3.
Je ne suis pas contre C#, mais dans tous tes exemples, on parle d'applications "lourdes" liées à l'écosystème MS.
Je l'ai déjà dit et je le répète, il ne faut pas être stupide, dans les environnements que tu décrits, .NET est évidemment le chemin de migration de moindre résistance (comme le côté obscur, plus facile, plus séduisant, plus raide, mais ce n'est pas plus puissant ^_^ [JAVA et les gros éditeurs sont pultôt du côté obscur aussi pour le développement d'application web]).
Mais ce n'est pas parce que .NET est très bien adapté dans certaines situation ou pour les projets sur lesquels tu travaillent, qu'il faut considérer .NET comme la panacée pour tous les cas.
Comme je le dis dans un autre post, à la fin du projet, ce n'est pas la technologie qui compte (sauf si c'est inmaintenable), mais si ce qui a été fait répond AU besoin concret pour lequel ça a été écrit.
Depuis le passage à LINQ, le framework de persistance BDD, le framework de collections d'objets ainsi que le moteur XML ont été bouleversés, et pour moi la productivité s'en ressent.
Typiquement, ce sont des concepts qui ont une maturation dans d'autres langages/framework que .NET et ont été repris et étendus (il me semble que la persistance BDD, ça a commencé à se diffuser d'abord avec ZODB (python), puis des personnes ont porté le concept sur JAVA, de même que RubyOnRail à pleins de clones dans les autres langages/framework maintenant que le concept à montré son efficacité).
C'est ça l'avantage de la concurrence, pour ne pas se faire dépasser les autres solutions vont adopter les mêmes idées, les pousser un peu plus loin, et ajouter de nouvelles idées.
Si .NET se fait dépasser, il reprendra les nouvelles idées et les améliorations, en ajoutera de nouvelles, et ainsi de suite.
En gros rien de nouveau sous le soleil, à part une intégration de plus en plus complète de tous les concepts.
On le voit bien au niveau OS avec la course au bling-bling et fonctionalités entre Apple et MS.
Mais c'est clair que MS fait un maximum pour faire évoluer .NET le plus rapidement possible et attirer un maximum de développeur (ça à toujours été leur stratégie d'attirer un maximum de développeur sur leur solutions) pour que ce choix s'impose naturellement par effet de masse des compétences acquises.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par TImaniac (site web personnel) . Évalué à 1.
Bien entendu, m'enfin bon on mélange plusieurs trolls simultanément : plateforme vs plateforme et langage vs langage.
Je trouve C# plus productif que Java dans l'absolu, de par leur syntaxe, leur grammaire.
Après choisir telle ou telle plateforme dépends de pleins d'autres critères on est d'accord.
la fin du projet, ce n'est pas la technologie qui compte (sauf si c'est inmaintenable), mais si ce qui a été fait répond AU besoin concret pour lequel ça a été écrit.
Bien entendu, mais on s'en tape. On parle de techno, de langage, et toi tu réponds par un truc qui n'a rien à voir.
Typiquement, ce sont des concepts qui ont une maturation dans d'autres langages/framework que .NET et ont été repris et étendus
Je m'en tape, on compare C# et Java. Pas toto et tutu.
Java n'a pas LINQ, malgré ce que tu répètes une fois de plus : il manque beaucoup trop de concepts dans le langage pour celà.
C'est très commercial comme discours, mais les screenshots sont explicites :
http://msdn.microsoft.com/fr-fr/library/bb397897.aspx
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par darkleon (site web personnel) . Évalué à 2.
...
Je trouve le socle technique ouachement mieux :
Je trouve le langage C# ouachement mieux que le langage Java : event, property, linq, lambda, inférence de type, etc.
...
Après tu trouveras sûrement tout ça ailleur, mais pas ensemble : et moi c'est tout ca sur la même plateforme qui la rend sexy. Et c'est pour la même raison que beaucoup de développeurs utilisent Mono.
m'enfin bon on mélange plusieurs trolls simultanément : plateforme vs plateforme et langage vs langage.
C'est bien pour cela que j'ai réagi à la base, on compare juste la technicité du langage, ou l'environnement complet de développement aux facilités de déploiement.
Dans les applications moderne, c'est la chaîne complète qu'on compare.
Tu prends quelques point fort de .NET et conclue .NET est meilleur.
On peut réinventer en améliorant, en faisant mieux non ?
Moi je trouve .NET mieux que Java sur certains points, certains d'entre eux ayant d'ailleur été repris par Java depuis, comme quoi c'est qu'il y avait des trucs intéressants dedans.
C'est typique des "évangélistes"
- Les autres ont copiés sur nous nos idées, on n'a pas copié les idées des autres, puisque notre roue est mieux, ce qui dénote d'une rupture technologique (hint: tout le monde se copie, ça s'appelle même le progrès).
- La techno 1 est supérieure (aujourd'hui, mais demain ça sera la techno 2 [qui peut être du même éditeur que la techno 1 !], après-demain, ça sera la techno 3, ad libitum).
Quand je lis ce genre de truc, je passe en
Je m'en tape, on compare C# et Java. Pas toto et tutu.
Je suis parti sur des exemples d'autres technologies pour être plus généraliste dans mon propos, je ne suis pas un évangéliste JAVA, je voulais juste faire l'avocat du diable.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par darkleon (site web personnel) . Évalué à 2.
mode avocat du diable
Apparament, le clavier était blo
-->[]
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par TImaniac (site web personnel) . Évalué à 1.
Ah non je prends quelques points fort de C# et conclu que C# est meilleur :)
Dans les applications moderne, c'est la chaîne complète qu'on compare.
Bien entendu qu'on peut comparer toute la chaîne, ce qu'on fait plus ou moins. Mais toi tu rajoutes encore autre chose : l'environnement, le contexte. Ca devient impossible de faire une comparaison purement technique.
Les autres ont copiés sur nous nos idées, on n'a pas copié les idées des autres, puisque notre roue est mieux, ce qui dénote d'une rupture technologique
C'est typiques de gens qui lisent de travers : je n'ai jamais dis que C# n'avait rien copié sur Java, au contraire j'ai parlé de saine émulation. Evidemment que C# est largement inspiré de Java.
Je suis parti sur des exemples d'autres technologies pour être plus généraliste dans mon propos, je ne suis pas un évangéliste JAVA, je voulais juste faire l'avocat du diable.
Vi mais bon ca dessert ton argumentaire, d'autant plus que tes exemples, Python, pour comparer à LINQ, voilà quoi. C'est pas possible de l'envisager dans Python, par nature : Python est un langage dynamique.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par darkleon (site web personnel) . Évalué à 2.
Euh a priori (en dehors des perfs [qui vont s'écrouler]) tu peux toujours ajouter une surcouche dans un un langage dynamique pour faire de l'inférence de type même si ce n'est pas un mécanisme par défaut.
Python supportant les pointeurs sur les fonctions et les expression lambda et les types anonymes, ces points là ne sont pas des contre indications non plus.
Apparement, il y a dejà des briques qui permettent de le faire le même genre de truc en Python, ce n'est peut êre pas aussi "policé" que LINQ, mais il n'y a pas de contre indication technique pour le faire.
http://www.aminus.org/blogs/index.php/2008/04/22/linq-in-pyt(...)
http://sayspy.blogspot.com/2006/02/why-python-doesnt-need-so(...)
Je ne dis pas ça pour argumenter mais pour comprendre si j'ai loupé un truc au passage sur les concepts des langages.
Lambda expression
Pareil, pas de vérification de contrat de signatures sur les types (philosophie non java).
??? Tu peux expliquer ???
Tant qu'à faire, je répond à cette question aussi.
La philosophie JAVA est d'être le plus descriptif possible pour éviter les erreurs d'interprétations par un humain du code.
Comme une fonction lambda est une fonction inline, si je reprends la déclaration C#
del myDelegate = x => x * x;
Note que ton expression marchera pour les types numériques de base. Si tu crée ta classe de nombres complexes, il faudra surcharger l'opérateur "*" pour que ce code marche.
Si tu te limite à un type, tu devra déclarer obligatoirement les types dans ta fonction qui sera déclarée dans une classe:
int mul(int x)
double mul(double x)
sachant que les deux fonctions pour java sont totalement dichotomiques, elles ne prennent pas les mêmes paramètres (signature de fonction différente)
Tu ne peux pas avoir de type anonyme dans la déclaration d'une fonction dans JAVA. Il faut déclarer tous les types des variables en entrée ou en sortie.
Au mieux, ça sera si tu ne veux pas limiter la hiérarchie d'objets.
Object carre(Object x) {...};
et il faudra faire de l'introspection sur x pour connaître la bonne fonction a appeler, ça sera fait au runtime, et ne pourra pas être "précalculé" à la compilation.
Bref 5 pages de codage avec une syntaxe illisible au lieu d'une ligne, tu auras un mécanisme carrément moins performant, donc ça supprime tout l'intérêt de vouloir avoir des fonctions anonyme à type anonymes en JAVA.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par TImaniac (site web personnel) . Évalué à 2.
L'inférence de type est évidemment possible en Python, mais c'est fait en "live" par l'interpréteur : aucun intérêt, c'est le fonctionnement de base de Python.
En C# l'intérêt est d'avoir cette inférence par le compilateur : garantie du typage et complétion en live. Le screenshot de Microsoft est explicite.
Les liens que tu montres montre uniquement qu'on peut avoir la même bibliothèque que LINQ : oui LINQ c'est aussi une bibliothèque de requétage qui peut être reproduit dans n'importe quelle plateforme. Mais c'est aussi une intégration native de la syntaxe dans le langage, ce que ne propose absolument pas Python.
del myDelegate = x => x * x;
Tu ne peux pas écrire celà, tu dois expliciter le type en C# :
Func<int, int> myFunc = x => x * x;
Bref, il n'y a aucune confusion sur le typage.
L'intérêt, c'est de pouvoir passer facilement du code plutôt que des références en paramètre de méthodes :
public void IterateOnList(List maList, Action action)
{
// code ici
}
En Java tu devrais déclarer une classe qui implémente une interface avec une méthode dedans.
Ce qui serait parfaitement inutilisable dans une API du style de LINQ où la plupart des clauses (OrderBy, Where, Select, etc.) prennent une expression en paramètre.
Tu ne peux pas avoir de type anonyme dans la déclaration d'une fonction dans JAVA.
En C# non plus, je te rassures. Un type anonyme est juste un type dont l'on n'a pas besoin d'avoir le nom. Il a un nom interne pour le compilateur pour le suivre comme n'importe quel autre type, mais il évite au développeur de déclarer un type alors qu'il veut juste un type temporaire pour stocker le résultat d'une requête.
Le type anonyme reste un type à part entière : le compilateur vérifie son utilisation plus bas, l'IDE propose toujours la completion.
Bref, en Java une API similaire serait extrêment lourde à l'utilisation sans modification du langage. C# a évolué justement pour rendre cette API utilisable et productive.
[^] # Avec une argumentation comme ça, on aurait tous du rester au COBOL.
Posté par darkleon (site web personnel) . Évalué à 2.
En 2005, le Gartner Group estimait que 75% des données du monde des affaires étaient traitées par des programmes en COBOL et que 15% des nouveaux programmes développés le seront dans ce langage.
COBOL permet d'effectuer des traitements comptables du fait de ses capacités arithmétiques en virgule fixe, notamment pour les traitements par lot où il présente d'excellentes performances (on n'a pas fait mieux depuis)...
Typiquement, ça marche depuis 20ans, maintenance réduite aux migrations techniques, coût déjà amorti, pourquoi refaire dans un autre langage?
(Si un immeuble en pierre est salubre et que ces habitants vivent agréablement, faut il vraiment le refaire en béton [qui est une technique de construction supérieure au niveau technique, au niveau esthétique, c'est plutôt l'inverse] pour le refaire en "mieux").
S'il y a un type "decimal" dans C#, c'est bien pour capter ces développement de comptabilité. Ce n'est pas moi qui le dit, c'est ce que MS annonçait déjà dans .NET1.0
[^] # Re: Avec une argumentation comme ça, on aurait tous du rester au COBOL.
Posté par TImaniac (site web personnel) . Évalué à 2.
Pacque les développeurs sont passionnés et beaucoup plus productifs ou parcqu'il y a un existant et un contexte industriel ?
C'est quand même rigolo, tu vois que le troll technique t'échappe, alors tu pars sur l'environnement du projet.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par darkleon (site web personnel) . Évalué à 2.
Puis aller chercher les contre argumentations et les "work around" en java.
ça donne toujours des idées, et je serais un peu moins ignare.
Rien que pour cela, j'ai apprécié l'échange.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par Mathieu Segaud . Évalué à 0.
Mono n'est pas en retard, Mono n'implémente seulement pas ce qu'il est totalement STUPIDE d'implémenter. comprends-tu seulement ce mot ?
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par Albert_ . Évalué à 1.
Enfin bon je vais arreter la c'est amusant de parler a des murs mais bon au bout d'un moment c'est lassant.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par Amine "nh2" Brikci-Nigassa (site web personnel) . Évalué à 1.
The danger is that Microsoft is probably planning to force all free C# implementations underground some day using software patents.
(...)
The problem is not in the C# implementations, but rather in Tomboy and other applications written in C#. If we lose the use of C#, we will lose them too. That doesn't make them unethical, but it means that writing them and using them is taking a gratuitous risk.
http://www.fsf.org/news/dont-depend-on-mono
Si .net devient un logiciel libre, le problème ne se posera plus !
GNU's Not Unix / LINUX Is Not Unix Xernel
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par patrick_g (site web personnel) . Évalué à 10.
Le problème c'est que, contrairement à ce que tu semble penser, Microsoft n'a pas du tout libéré .NET sous licence Apache.
Ce qui est libéré c'est le framework micro .NET (celui réservé à l'embarqué) => http://en.wikipedia.org/wiki/.NET_Micro_Framework
En plus, comme si le micro framework n'étais pas assez petit, ils ont décidé de ne pas libérer la pile TCP/IP qui était dedans.
Et puis pour faire bonne mesure ils ont aussi décider de ne pas libérer la bibliothèque de fonctions cryptographiques qui était dedans.
Bref c'est le passage sous licence Apache d'un micro-nano bout de .NET.
Les détails ici : http://www.tuxradar.com/content/microsoft-open-sources-net-m(...)
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par Amine "nh2" Brikci-Nigassa (site web personnel) . Évalué à 3.
L'auteur de l'article slashdot considère ce passage comme une étape (next level)... il a sûrement tort, mais on ne sait jamais !
GNU's Not Unix / LINUX Is Not Unix Xernel
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par TImaniac (site web personnel) . Évalué à -1.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par Antoine . Évalué à 7.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par Albert_ . Évalué à 1.
- ils ont peur que l'on trouve le code BSD dedans :)
- TCP/IP ne fait pas aprti de leur "coeur" de metier (un peu comme le moyen d'installer un OS a parti d'une cle usb) du coup ils ont sous traite.
Ils sont amusant chez microsoft ils developpent rien eux-meme on dirait ils ne font que sous traiter a croire que les employes a redmond ne sont payer qu'a troller sur DLFP et/ou a faire du lobby...
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par O'neam Anne . Évalué à 1.
Si jamais Microsoft utilise des brevets pour interdire toutes les implémentations de .NET qui tournent sous Linux, le fait que l'implémentation officielle soit distribuée sous licence libre n'y changera rien ;⋅).
LinuxFr, parfois c'est bien de la MERDE : https://linuxfr.org/users/c2462250/journaux/ecriture-inclusive-feministes-et-wikipedia#comment-1793140
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par Amine "nh2" Brikci-Nigassa (site web personnel) . Évalué à -1.
GNU's Not Unix / LINUX Is Not Unix Xernel
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par BAud (site web personnel) . Évalué à 4.
Pas tout à fait, hormis cas particulier.
La GPL inclut une clause spécifique concernant les brevets :
http://www.gnu.org/licenses/gpl.html §10 Automatic Licensing of Downstream Recipients.
You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License. For example, you may not impose a license fee, royalty, or other charge for exercise of rights granted under this License, and you may not initiate litigation (including a cross-claim or counterclaim in a lawsuit) alleging that any patent claim is infringed by making, using, selling, offering for sale, or importing the Program or any portion of it.
il y a le §11 aussi
Mais pour une licence BSD, qui est aussi une licence libre, il n'y a pas ce genre de protection.
Un logiciel incluant des brevets valides pourrait être distribué sous BSD, sous GPL soit le brevet devient caduque, soit cela ne peut pas être distribué dans le monde entier (uniquement dans les pays ne reconnaissant pas les brevets logiciels).
Presque partout en Europe, les brevets logiciels sont encore illégaux, ce qui fait que nous ne sommes pas touchés.
Aux USA, en revanche, les brevets logiciels s'appliquent, empêchant la diffusion de codeur MP3 par exemple (et autres formats vidéos), quand bien même ce serait sous licence libre.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par TImaniac (site web personnel) . Évalué à 1.
Là seule chose où il n'y a pas vraiment d'alternative et qui n'est pas standardisé, c'est ADO.NET. M'enfin bon c'est pas non plus une API super innovante (difficile à breveter donc) et au besoin créer une nouvelle API ne sera pas bien compliqué.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par Antoine . Évalué à 10.
Le ministre des finances Nicolas Sarkozy a explicitement indiqué qu'il n'y aurait pas de privatisation d'EDF ni de GDF.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par TImaniac (site web personnel) . Évalué à 1.
Faut arrêter vos conneries : IBM, Sun & Co font exactement le même type d'engagement écrit et tout le monde en est content, là c'est exactement pareil.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par Antoine . Évalué à 3.
Ah bon ? Le contrat a été signé avec qui ?
Pas avec moi en tout cas, ni la plupart des autres développeurs de LL.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par Jar Jar Binks (site web personnel) . Évalué à 1.
Au moins aux États-unis, un engagement comme la community promise a justement une valeur légale. Et en Europe, il n’y a pas de problèmes de brevets donc la question ne se pose pas (la propriété intellectuelle du code de Mono n’est pas en cause).
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par lasher . Évalué à 2.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par Antoine . Évalué à 3.
Elle s'applique implicitement quand tu décides d'utiliser ou de redistribuer un LL.
(parce que si tu refuses son application, tu n'as le droit ni d'utiliser ni de redistribuer)
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par claudex . Évalué à 3.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par Antoine . Évalué à 2.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par vida18 . Évalué à 1.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par Jean-Michel Philippe (site web personnel) . Évalué à 2.
1. ils ré-écrivent Java au lieu de l'adopter/forker
2. leur Java-like n'est plus multi plate-forme, contrairement à Java
3. pour faire croire que c'est quand même multi plate-forme, ils sponsorisent Mono
4. on peut consulter le code de .Net, mais pas le réutiliser
5. ils normalisent un nouveau langage mais le bardent de brevets, y compris la base C# si on en croit la récente « community promise »
Tout ceci amène beaucoup de questions :
* quel est l'intérêt de refaire Java en non multi plate-forme ?
* pourquoi sponsoriser Mono au lieu de faire le développement eux-même ?
* pourquoi laisser le code en lecture seule, sinon pour être sûr qu'on implémente les brevets correctement ?
* pourquoi mettre des brevets sur un langage de programmation, ça n'a pas une vocation universelle un langage ?
* etc.
Et donc la seule réponse commune à toute ces questions selon moi est que .Net est l'arme ultime anti-migration vers Linux. Le bateau Microsoft prend l'eau de partout depuis quelques temps, bientôt le seul argument qui restera pour retenir les utilisateurs ne sera plus que « vos applications ne tournent que sous Windows ». Et .Net est là pour ça.
# Mono, toujours en retard sur son équivalent propriétaire... ou pas
Posté par daemontux . Évalué à 7.
Ça dépend dans quel domaine. Certes, WPF ou silverlight ne sont pas ou pas entièrement implémentés, mais à côté de ça mono est multi-plateformes (y compris androïd, iphone), capable de faire du ahead-of-time, de tourner sur du mainframe/supercomputer (en gérant des tableaux 64 bits, ce que .Net ne sait pas faire) ou d'utiliser les instructions SIMD du proc, certaines parties du framework (comme Mono.Tasklets pour les coroutines) n'ont pas d'équivalent .Net et ils ont quelques projets intéressants codés pour mono (voir le client bittorrent monsoon qui peut être lancé via moonlight ou le shell C#).
Sans vouloir faire l'apologie de mono, je voulais juste faire remarquer que contrairement à ce que certains semblent penser ce ne sont pas simplement des "suiveurs" qui se contentent de recopier ce que fait Microsoft avec du retard, ils innovent de leur côté et dans certains domaines c'est .Net qui est en retard...
[^] # Re: Mono, toujours en retard sur son équivalent propriétaire... ou pas
Posté par bubar🦥 (Mastodon) . Évalué à 4.
A t on un exemple d'une fonctionnalité qui a été inventée sur Mono et que MS a reprise pour .NET ?
Merci
[^] # Re: Mono, toujours en retard sur son équivalent propriétaire... ou pas
Posté par Jb Evain (site web personnel) . Évalué à 10.
http://www.advogato.org/person/lupus/diary/27.html
De rien.
[^] # Re: Mono, toujours en retard sur son équivalent propriétaire... ou pas
Posté par bubar🦥 (Mastodon) . Évalué à 2.
merci
# Adversaire ?
Posté par warwick . Évalué à 2.
[^] # Re: Adversaire ?
Posté par Mathieu Segaud . Évalué à 8.
D'où le troll :-)
[^] # Re: Adversaire ?
Posté par Camille_B . Évalué à 4.
Il n'a pas écrit gnote pour concurrencer tomboy et combattre mono :
"And if you still think I hate Mono think again. I worked for the company that pushes Mono (and still wish I was), and I was using Tomboy on all the Linux machines I had (and to be fair I was surprised of the number of people who actually told me they had never used it because it was Mono based... looks like this didn't stop me as I had been using it for as long as I have the laptop I'm typing this on, circa Dec 2005)."
http://www.figuiere.net/hub/blog/?2009/07/27/680-why-i-did-w(...)`
Mais évidemment, notre bon patrick_g, dans sa grande objectivité concernant le cas mono, et dans sa grande intelligence des machine virtuelle, a évidemment considéré que ce petit détail était insignifiant.
Seulement, peut-être ce détail lui aurait-il permit de comprendre la raison pour laquelle gnote est laissé en friche : ça n'est pas seulement un projet fait sur son temps libre, mais c'est également un projet qui n'avait que des buts spécifiques (et quasiment remplis dès les premières versions) et qui n'avait aucune pour fondement le remplacement de tomboy.
Pour le dire plus clairement : l'auteur de gnote continuant d'utiliser tomboy sur ses machines, la nécessité, pour lui, de continuer à travailler sur ce projet est faible.
[^] # Re: Adversaire ?
Posté par patrick_g (site web personnel) . Évalué à 5.
J'essaye autant que possible de présenter des arguments et de ne pas attaquer les gens personnellement.
>>> peut-être ce détail lui aurait-il permit de comprendre la raison pour laquelle gnote est laissé en friche
J'ai indiqué noir sur blanc dans la news qu'Hubert avait annoncé dès le début qu'il pourrait stopper le dev et la maintenance et qu'il ne bosserait dessus qu'autant qu'il le pourrait.
La vraie question posée par la dépêche c'est que Fedora a basculé vers Gnote et que cette bascule a des conséquences pour les gens si Gnote n'est plus maintenu.
[^] # Re: Adversaire ?
Posté par Mathieu Segaud . Évalué à 1.
>>> basculé vers Gnote et que cette bascule a des conséquences
>>> pour les gens si Gnote n'est plus maintenu.
c'est marrant, j'avais l'impression que c'était la faute à Mono, le message subliminal de la dépêche :)
# Prise de Notes
Posté par zflorent . Évalué à -1.
Donc forcément un outil en ligne pour avoir les mêmes infos partout (avec process de synchro pour quand on passe de non connecté à connecté).
Donc un logiciel de prise de note sous Gnome (donc sur un type d'ordinateur assez restreint), c'est gentil, mais ça ne répond pas à mon besoin. Je ne comprend même pas que ça puisse encore intéresser des gens! ;-)
Google Notes est pas mal mais il ne passe pas bien sur mon Gphone... Étonnant, non? On dirait qu'ils n'ont pas envie de développer cet outil chez Google.
Si quelqu'un connaît un remplaçant (gratuit).
zFlorent
[^] # Re: Prise de Notes
Posté par Florent Zara (site web personnel, Mastodon) . Évalué à 2.
Le truc qu'ils ont décidé d'arrêter progressivement il y a quelque temps déjà ? Ca ne m'étonne pas que Google ne développe plus dessus.
http://itdied.com/2009/01/hecatomb-at-google-many-services-s(...)
[^] # Re: Prise de Notes
Posté par TImaniac (site web personnel) . Évalué à 2.
"•WebSync add-in for synchronzing to the upcoming Tomboy Online web service, or your own server running Snowy, or any other server implementing the new Tomboy Web REST API (soon to include Ubuntu One and Midgard)"
[^] # Re: Prise de Notes
Posté par Jérôme Pinot (site web personnel) . Évalué à 5.
[^] # Re: Prise de Notes
Posté par Wawet76 . Évalué à 2.
Par contre je n'ai pas de mode déconnecté.
Tient je devrais regarder si il n'existe pas une appli pour se synchroniser en local une copie d'un dokuwiki. Il me semble qu'il existe des trucs pour faire des snapshot en HTML statique du contenu du wiki. Ça pourrait suffire...
[^] # wget
Posté par Thomas Douillard . Évalué à 0.
# KeepNote
Posté par Luzerne . Évalué à 3.
http://rasm.ods.org/keepnote/
Luzerne GANHIR
# trolllllllll
Posté par dufour olivier . Évalué à -2.
On est passé par la théorie du complot des méchants de Microsoft qui sont derrière tout.BIG BROTHER? et des méchants qui prennent une technologie juste pour leur CV.... mais qui en secret veulent torpiller le libre...
je suis sur que bill gates est le fils de Hitler et sadam et que c'est lui qui a provoqué l'extinction des dinosaures!
Plus sérieusement , je juge les actes et non les personnes (morale)° et il faut savoir faire fie du passé... Et même si MS a pendant longtemps été contre le logiciel libre et l'open source. Ils s'ouvre de plus en plus à l'open source... et ce n'est pas parce qu'une boite est concurrente que c'est un ennemie!
PAIX et AMOUR ;)))))
[^] # Re: trolllllllll
Posté par fedorat . Évalué à 2.
[^] # Re: trolllllllll
Posté par Antoine . Évalué à 5.
[^] # Re: trolllllllll
Posté par claudex . Évalué à 5.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Gnote, Tomboy, xxx...
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 2.
Par contre j'ai deux regrets : pas de possibilité de changer le status d'une tâche en "fait" (par opposition à "à faire") ; et pas de réordonnancement des tâches possible (par exemple avec un niveau de priorité, ou alors par glisser-déposer).
On va me dire "tu peux le faire" ; soit. Mais existe-t-il à votre connaissance un logiciel qui intègrerait déjà ces fonctionnalités et qui fonctionne de la même manière que Tomboy/gnote ?
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Gnote, Tomboy, xxx...
Posté par Albert_ . Évalué à 2.
http://www.rememberthemilk.com/
takstop:
http://tasktop.com/ (mais bon ca c'est l'artillerie lourde)
et sinon dans google tu as un nouveau truc "liste de taches"
Il me semble que c'est ce genre de chose que tu recherches mais je me trompe peut etre.
[^] # Re: Gnote, Tomboy, xxx...
Posté par Juke (site web personnel) . Évalué à 1.
et c'est libre et sans brevets ?
[^] # Re: Gnote, Tomboy, xxx...
Posté par nomorepost . Évalué à 2.
qui est libre comme équivalent de "Remember the milk":
service en ligne:
http://tracks.tra.in/login
sources GPL
http://getontracks.org/
[^] # Re: Gnote, Tomboy, xxx...
Posté par ploum (site web personnel, Mastodon) . Évalué à 2.
C'est libre, sans brevet et probablement inclus dans ta distribution.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Gnote, Tomboy, xxx...
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 2.
[après quelques dizaines de minutes de test]
Bon. J'ai adopté gtg. Les tags c'est super puissant comme truc ! Je vais voir ce que je peux faire quant à l'intégration comme applet gnome.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Gnote, Tomboy, xxx...
Posté par ploum (site web personnel, Mastodon) . Évalué à 1.
C'est une feature qu'on aimerait beaucoup avoir. Si quelqu'un décide de s'y mettre, il recevra tout le support possible :-)
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Gnote, Tomboy, xxx...
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 2.
En tout cas, si je le fais, je ne le ferai pas dans mon coin, bien entendu :)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Gnote, Tomboy, xxx...
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 2.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Gnote, Tomboy, xxx...
Posté par ploum (site web personnel, Mastodon) . Évalué à 1.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Gnote, Tomboy, xxx...
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 1.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
# le problème
Posté par brazz . Évalué à 6.
Il n'en est pas de même pour F-Spot, qui lui, en plus n'a pas vraiment d'alternative clairement établie, seulement quelques unes sur certains de ses aspects. C'est beaucoup plus préoccupant.
La grande question, effectivement, c'est l'utilisation de Mono !
Sans vouloir troller deux jours avant l'heure :) il faut bien reconnaitre que pour le monde du Libre, utiliser quelque chose qui repose à ce point sur le bon vouloir de Microsoft, c'est vraiment se tirer une balle dans le pied ! C'est faire dépendre un côté stratégique du développement, de gens qui ont des intérêts stratégiquement opposés.
On ne comprend pas, en dehors de questions de mode, le besoin frénétique d'utiliser Mono, à part faire plaisir à M. de Icaza -qui aurait mieux fait de se concentrer sur gnome par exemple, au lieu de se disperser sur des futilités contestables- Je trouve cela d'autant plus dangereux que côté garanties, il n'y a rien de très solide, à part des déclarations lénifiantes de MS, qui n'engagent -comme celles des politiques- que ceux qui les écoutent !
On attend avec impatience la nouvelle manie à la mode, l'utilisation massive de Go, même si c'est Ken Thomson qui est derrière, derrière lui il y a une pieuvre semblable à Microsoft !
Derrière ces dérives diverses, c'est aussi une certaine dérive du libre à laquelle on assiste.
[^] # Re: le problème
Posté par TImaniac (site web personnel) . Évalué à 4.
Oué oué oué, comme tous les documents à valeur juridique donc ? La GPL n'engage que ceux qui les écoutent ? Ah ben non.
Faut arrêter les conneries, un engagement écrit n'a pas la même valeur devant un tribunal qu'un discours politique.
Mono ne dépend absolument pas du bon vouloir de Microsoft : techniquement, Microsoft peut faire ce qu'il veut, Mono n'est pas obligé de suivre MS et n'importe qui peut forker.
Juridiquement, Mono est protégé par un consortium (OIN) qui regroupent des tarlouzes sans défenses comme IBM RedHat Sony ou Novell.
Bref l'avenir de Mono ne dépend que de ses contributeurs, comme tous logiciels libres.
[^] # Le problème qui n’en est pas un
Posté par Jar Jar Binks (site web personnel) . Évalué à 1.
J’ai déjà expliqué point par point en quoi tout ceci est un tissu d’absurdités : http://np237.livejournal.com/24790.html
Quant à juger que MDI se disperse en « futilités contestables », renseigne-toi 5 minutes sur ce qu’est Mono avant. Il n’existe aucun, je dis bien aucun, framework de développement libre qui soit à moitié aussi complet que Mono. Tant en termes d’environnement de développement, de qualité et quantité de bibliothèques disponibles, de cohérence, que de nombre de langages supportés.
Il ne t’est jamais passé par la tête que si les gens l’utilisent, ce n’est pas par « besoin frénétique » mais tout simplement parce que c’est plus efficace de développer avec Mono ? Plus efficace même que de développer avec .Net, vu que Mono est plus performant et dispose de bibliothèques (comme Qt# et Gtk# en particulier).
[^] # Re: Le problème qui n’en est pas un
Posté par Albert_ . Évalué à 3.
[^] # Re: Le problème qui n’en est pas un
Posté par dguihal . Évalué à 2.
[^] # Re: Le problème qui n’en est pas un
Posté par Jar Jar Binks (site web personnel) . Évalué à -4.
[^] # Re: Le problème qui n’en est pas un
Posté par Albert_ . Évalué à 1.
[^] # Re: Le problème qui n’en est pas un
Posté par dguihal . Évalué à 9.
GanttProject
Tomcat/JBoss
ArgoUML
BlueJ
OBM
JEdit
SoapUI
Squirrel SQL
Jmeter
ldapbrowser
jxplorer
Regarde sur freshmeat :
Programming languages
Java : 5496 projets
C# : 80 projets
Y'a pas photo
[^] # Re: Le problème qui n’en est pas un
Posté par Mathieu Segaud . Évalué à -1.
sinon pour les projets java libres... désolé, mais non, ça reste des usines à gaz monstrueuses qui clutterent la mémoire plus vite que leurs ombres, mais qui mettent bien du temps à t'infliger leur splashscreen (exemple: ce cher Eclipse dont on me parle... l'appli "entreprise", "professionnelle", qu'on utilise partout pour se la raconter, et ne pas admettre qu'on ne sait pas se servir d'un éditeur de texte et de ses dix doigts.), avant de se crasher lamentablement, mais de ne libérer la mémoire que plusieurs minutes après (à moins d'un kill -9...)
Les _seuls_ projets opensource en java, qui sont pertinents, sont icedtea (mouhaha, c'est mignon), et openfire, qui est la seule implémentation pertinente d'xmpp en serveur libre (à mon humble et personnel avis)
[^] # Re: Le problème qui n’en est pas un
Posté par briaeros007 . Évalué à 7.
Une appli "libre" qui reste en interne, elle est pas vraiment libre, elle est interne. Donc dire que ce sont les autres de mauvaise foi quand on essaie de renommer les contraintes pour que ca passe mieux pour nous, c'est du foutage de geule.
ça reste des usines à gaz monstrueuses qui clutterent la mémoire plus vite que leurs ombres,
Autant que mono.
mais qui mettent bien du temps à t'infliger leur splashscreen
Pas chez moi, et puis c'est quoi ce bench de merde ? "Il a mis 3 sec a m'afficher sa splashscreen" , mais qu'est ce qu'on en a à foutre, du moment que le soft est fonctionnel et utilisable ?
exemple: ce cher Eclipse dont on me parle... l'appli "entreprise", "professionnelle", qu'on utilise partout pour se la raconter, et ne pas admettre qu'on ne sait pas se servir d'un éditeur de texte et de ses dix doigts.
Si tu compare un ide à un simple éditeur de texte, soit tu es très nul, soit tu es très incompétent, soit tu es très de mauvaise foi.
marrant je crois que c'est plutot le troisième choix.
[^] # Re: Le problème qui n’en est pas un
Posté par Mathieu Segaud . Évalué à 2.
>>> nul, soit tu es très incompétent, soit tu es très de mauvaise foi.
>>> marrant je crois que c'est plutot le troisième choix.
pas exactement, seulement, emacs ou vim font de très bon IDE (pour moi)
(sinon, tu sais ce que signifie ta signature ? j'apprécie pas les menaces de mort :-D )
dete kimasu :)
[^] # Re: Le problème qui n’en est pas un
Posté par dguihal . Évalué à 0.
Après que tu t'en contente très bien pour toi.
[^] # Re: Le problème qui n’en est pas un
Posté par Mathieu Segaud . Évalué à -1.
[^] # Re: Le problème qui n’en est pas un
Posté par briaeros007 . Évalué à 2.
(t'as qu'a faire en sorte que j'apprenne toujours qqch ;))
[^] # Re: Le problème qui n’en est pas un
Posté par Mathieu Segaud . Évalué à 1.
je vais t'apprendre la grammaire française alors
[^] # Re: Le problème qui n’en est pas un
Posté par briaeros007 . Évalué à 3.
[^] # Re: Le problème qui n’en est pas un
Posté par dufour olivier . Évalué à 0.
banshee
tomboy
moonlight
monsoon
gbrainy
gnome do
mojoportal
monoosc
log4net
nhibernate
axiom3d
Mais bon après ce qui compte c'est pas le nombre mais la qualité des applications.
[^] # Re: Le problème qui n’en est pas un
Posté par dguihal . Évalué à 2.
-monosc : une truc pour gérer l' openSUSE Build Service, une killer app certainement
- log4net : portage de log4j en .Net
- nhibernate : portage de hibernate en .Net
Ca me fait vraiment peur quand aux "killers features" des applis mono
On dirait plus que t'a gratté les fonds de tirroirs
[^] # Re: Le problème qui n’en est pas un
Posté par Gniarf . Évalué à 2.
(et kikoo Romain Guy \o/ sinon)
[^] # Re: Le problème qui n’en est pas un
Posté par Jar Jar Binks (site web personnel) . Évalué à -2.
Je persiste : un bon logiciel en Java, c’est la perle rare.
[^] # Re: Le problème qui n’en est pas un
Posté par Albert_ . Évalué à 3.
[^] # Re: Le problème qui n’en est pas un
Posté par Jar Jar Binks (site web personnel) . Évalué à -1.
J’adore toujours autant le système de modération sur trollfr ; ou comment une bande de blaireaux qui passe sa journée sur le site auto-entretient sa haute idée d’elle-même en masquant toute idée qui ne rentre pas dans leur filtre.
[^] # Re: Le problème qui n’en est pas un
Posté par Gniarf . Évalué à 2.
scoop : un bon logiciel tout court, c’est la perle rare. les tares de Java ont peu à voir là dedans
[^] # Re: Le problème qui n’en est pas un
Posté par Jar Jar Binks (site web personnel) . Évalué à -2.
[^] # Re: Le problème qui n’en est pas un
Posté par Albert_ . Évalué à 2.
[^] # Re: le problème
Posté par dufour olivier . Évalué à 1.
D'ailleur linux c'est l'implementation libre d'unix....
Comme dit plus haut ce qui repose sur microsoft c'est ADO.NET et ASP.NET le reste c'est normé à l'ecma et/ou sans patent donc pas de problème... qui ne sont pas utilisé sur les logiciels lié a mono.
[^] # Re: le problème
Posté par Almacha (site web personnel) . Évalué à 1.
http://blog.linuxtoday.com/blog/2009/06/why-mono-is-des.html
[^] # Re: le problème
Posté par Albert_ . Évalué à 3.
>> Mono on the whole also enables easier migration - for both developers and users - from legacy CLR frameworks such as Microsoft.NET
It's too bad that while this is a bullet feature, the mono people are not focused on moving Windows dotnet apps to Linux. Surely there are many wonderful MSdotnet apps, right?
[^] # Re: le problème
Posté par briaeros007 . Évalué à 3.
J'appelle pas ça une feature.
En C aussi je peux faire du code portable :P
[^] # Re: le problème
Posté par Jar Jar Binks (site web personnel) . Évalué à 2.
Vous êtes toxiques. Vous ne faites rien pour le logiciel libre. Votre propagande est gerbante et nocive. Si vous arrivez à détruire Mono, vous ne ferez que trouver une nouvelle cible à détruire. J’appelle cette tactique SDD : Scare, Distrupt and Destroy. Faire peur aux clients, désintégrer la communauté et détruire le travail qui a été fait.
Rien de bon ne sortira de cette approche.
[^] # Re: le problème
Posté par Albert_ . Évalué à 2.
Amusant l'esquive sur le fait que en effet il n'existe AUCUN logiciel .NET consequent microsoft qui tourne sous linux malgre l'argument initial.
[^] # Re: le problème
Posté par Antoine . Évalué à 1.
Et alors ? quelle importance ?
.Net Microsoft est une implémentation de .Net, et Microsoft est un éditeur logiciel parmi d'autres.
Dans le même ordre d'idées, les softs utilisant la glibc ne tournent pas sous Windows (sauf peut-être via Cygwin ou autre bidouille), ce n'est pas pour ça que le C ne permet pas d'être portable sous Windows.
Quant au fait que Microsoft utilise des API natives dans ses produits, même réponse : est-ce que le fait qu'on puisse utiliser des API spécifiques Linux en C fait du C un langage spécifiquement non-portable ?
(et ne me rétorque pas que le C, lui, a été imaginé sans le moindre OS de prédilection : car c'est le langage conçu spécifiquement pour écrire Unix)
C'est absolument risible tant de mauvaise foi. C'est à se demander si l'informatique est vraiment ton métier et si tu comprends les notions discutées ici. On dirait plus un militant politique qui s'improvise défenseur d'une cause à laquelle il ne pige rien.
[^] # Re: le problème
Posté par Littleboy . Évalué à 2.
A la base il est astrophysicien, mais il fait un peu de dev en python et C++ (G3D, Image simulator, caldislum, Pyfunl, Milia, Pymilia, ...).
Mais de toute facon, sur certains sujets, il est d'une telle mauvaise foi que ce n'est meme pas la peine de s'embeter a repondre.
[^] # Re: le problème
Posté par briaeros007 . Évalué à 2.
Non non, c'est le concepteur du langage, et le premier à le pousser.
On aurait pu penser qu'ils aient voulu utiliser leur langage pour toutes les fonctionnalités qu'il offre.... ah moins qu'ils considère que cette "fonctionnalité" n'est qu'optionnelle ?
Dans le même ordre d'idées, les softs utilisant la glibc ne tournent pas sous Windows (sauf peut-être via Cygwin ou autre bidouille), ce n'est pas pour ça que le C ne permet pas d'être portable sous Windows.
Faux, et tu donne toi même la solution .Il te faut la libc, que tu as dans cygwin, tout comme il te faut une vm .net que tu as dans mono pour faire tourner un soft .Net sous windows.
Le C est tout a fait portable, si tu n'utilise pas de librairies spécifiques à ton système.... comme .net!
Comme c'est drole.
Le but d'un framework multiplateforme est de proposer justement un ensemble de librairie équivalent sur tous les systèmes. Devoir passer par des libs externe montre que le framework n'est pas (assez) bon .
C'est à se demander si l'informatique est vraiment ton métier et si tu comprends les notions discutées ici. On dirait plus un militant politique qui s'improvise défenseur d'une cause à laquelle il ne pige rien.
Ben vu ce que tu viens de raconter, je pense que ca s'adresse plutôt à toi (y'a qu'a voir ton coup sur la glibc toussa). Ensuite, les attaques ad hominem montre juste ta compétence intrinsèque sur ce sujet.
[^] # Re: le problème
Posté par Antoine . Évalué à 1.
Oui bien sûr, sauf que si tu n'utilises pas de lib spécifique au système il y a bien des choses que tu ne peux pas faire (par exemple lancer des threads, ce qui est certes de nos jours un besoin très très pointu, n'est-ce pas ?). Les plateformes de programmation récentes ont au moins l'avantage de fournir des APIs multi-plateforme pour beaucoup plus de choses que la lib standard du C.
(mais, certes, tu peux coder un hello world en C standard sans grand problème)
Devoir passer par des libs externe montre que le framework n'est pas (assez) bon .
Tout à fait, et donc ? Qu'en déduis-tu sur la portabilité de .Net par rapport à la portabilité du C, contre laquelle on n'a jamais vu notre ami Albert lancer une diatribe ?
[^] # Re: le problème
Posté par briaeros007 . Évalué à 2.
Ben si tu peux lancer des threads avec pthread. Cygwin le comprend.
Les plateformes de programmation récentes ont au moins l'avantage de fournir des APIs multi-plateforme pour beaucoup plus de choses que la lib standard du C.
On parlais pas que de la lib standard, on parlait de librairies tout court. mono ne fait pas partie de la libc à ce que je sache, si ?
Alors comparons ce qui est comparable: a savoir un ajout par rapport à un autre.
Pour faire tourner un programme mono tu as besoin d'une vm mono. Pour faire marcher un programme C, tu as besoin des libs.
Si on se limite à certaines libs "de bases" de la même façon que mono le fait avec les libs qu'ils propose avec : on peut se limiter au sous ensemble fournis par cygwin, ou alors par qt par exemple.
Pas besoin d'une vm ou autre pour faire quelque chose d'interopérable.
Tout à fait, et donc ? Qu'en déduis-tu sur la portabilité de .Net par rapport à la portabilité du C, contre laquelle on n'a jamais vu notre ami Albert lancer une diatribe ?
Que la portabilité de .NET est de la merde car les concepteurs même du langage passe à tire larigot par des libs systèmes même pas standardisé! (contrairement aux libs posix par ex...)
[^] # Re: le problème
Posté par Albert_ . Évalué à 2.
La derniere etant silverlight qui utilise des libs specifique windows donc good bye la portablilite du bousin.
[^] # Re: le problème
Posté par nomorepost . Évalué à 2.
Sont pas fous, hein! Ils vont pas porter des trucs pas libres pour le plaisir d'en boucher un coin à Albert_ !
J'en ai une autre comme celle là. Fais gaffe tu vas pas le croire.
AUCUN jeu en DirectX n'est porté sous Linux !
C'est dingue, hein !
Par contre dans l'autre sens ca marche !
Mono+GTK tout comme PyGTK sous Windows. Ca marche ! Wouah!
Mais on sait pour du multiplateforme, on fait mieux avec PyQt quand on fait gaffe entre les chaines python et les QString ou qu'on se gourre pas avec le ramasse miette et autres drôleries:
http://leroybrice.free.fr/?/Python-Bindings-Tools-For-QtV7
J'ai qu'à coder en C++ alors .
Ben non, moi j'aime pas le C++ et je préfère coder dans le langage qui me plait et en changer sans bidouiller et avec Mono je peux y arriver.
Mais t'es vraiment trop fort ! Albert_
Il n'existe aucun logiciel .NET purement conçu pour Windows qui tourne sous Linux
T'as gagné, Albert_ ou devrais-je t'appeler La Palice .
[^] # Re: le problème
Posté par Jar Jar Binks (site web personnel) . Évalué à 1.
Et alors ? Qu’est-ce qu’on en a à foutre ? Le but de Mono est de fournir une bonne plate-forme de développement libre. Il n’y a que RMS qui tient à ce que son rôle reste cantonné à faire tourner des applications .Net.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.