L'article commence par une description du PDG de Ximian comme étant « leader du projet Gnome », ce qu'heureusement il n'est plus.
La suite est une succession de perles monumentales. J'aurais aimé avoir le temps de traduire l'article, mais je vais me contenter d'extraits :
- « J'espère que Gnome 3.0 sera en partie écrit en .NET, et Gnome 4.0 complètement basé dessus » ;
- « Perl et Python sont très limités, car on ne peut pas réutiliser de code C/C++ avec » ;
- « Microsoft développe des technologies très intéressantes, et .NET est un travail incroyable » ;
- « le logiciel libre est toujours en retard » ;
- « le modèle de sécurité de .NET est très beau » ;
- « dans le monde Windows, on ne parle pas de protocoles propriétaires ».
Note personnelle : merci pour tout ce que tu as fait, Miguel, mais on préférait quand tu écrivais du code utile.
Note du modérateur : J'ai laissé la news telle quelle. Les opinions sont donc celles de Jar Jar Binks et non de LinuxFR.
Aller plus loin
- The Register (4 clics)
# super mais...
Posté par Guillaume Lefevre . Évalué à 10.
- priez pour que microsoft ne s'amuse pas a changer toutes les semaines .NET
- perl et python peuvent utiliser des librairies via des bindings...
- dans le monde de Windows on ne parle pas... et la marmotte dans le chocolat enrobee dans du papier alu et hop au micro-onde..
[^] # Re: super mais...
Posté par Nicolas Roard (site web personnel) . Évalué à 10.
«Enfin, ce qui nous a motive le plus etait la solution moderne qu'ils nous ont propose : non proprietaire, puisqu'il s'agissait de Microsoft»
(voir http://fr.news.yahoo.com/020130/60/2gsp1.html(...) )
A se demander si ce n'est pas le nouveau cheval de bataille des commerciaux de microsoft !
Enfin ceci dit, je pense que peu de personnes avaient encore beaucoup d'illusions sur MDI ...
[^] # Re: super mais...
Posté par kalahann . Évalué à 10.
Unix, c'est propriétaire puisse que c'est pas assez répandu pour que tout le monde connaisse. Windows est un standard parce qu'il est répendu! à quoi ça sert d'avoir les specs que personne ne lit?
D'ailleurs dans unix tout est caché dans des fichiers de config illisibles pour empêcher les utilisateurs de modifier convivialement les paramètres de l'os... alos que microsoft fait tout pour développer des zolies interfaces pour pouvoir modifier la base de registre avec des noms si... parlants et précis!
</ironie>
:
PS: hé guile, elles sont bonnes mes balises, là? :)
[^] # Re: super mais...
Posté par Guillaume Lefevre . Évalué à -4.
[^] # Re: super mais...
Posté par Benjamin . Évalué à 6.
"Nous allons continuer à améliorer la répartition de notre chiffre d'affaires, en mettant l'accent sur nos logiciels environnements distribués. En parallèle, il nous faut maintenir notre activité grands systèmes propriétaires, grace à Linux notamment."
J'ai pas compris sa phrase...ptet une mauvaise traduc
[^] # Re: super mais...
Posté par ceituna (site web personnel) . Évalué à 10.
Quand tu t'appeles IBM, et que tu dis au client qu'il sa'agit de logiciel libre, qu'il n'est pas lié à IBM, bla bla bla, ca marche à 100%...
Par contre, le client ne sait pas que l'architecture matérielle est peu documentée, qu'il est 100% dépendant de IBM, qu'il en profite pour lui refourger des solutions non libres (Lotus Notes, etc...).
Je connais bien l'exemple, car ds ma boîte, ils sont emm... parcu'ils ont du Notes qui accepte même pas le POP/SMTP -> IBM dvt les nouvelles apllis.. ;)
[^] # Re: super mais...
Posté par PLuG . Évalué à 10.
Mais par contre Notes supporte le SMTP (sinon avec Notes on ne pourrait pas envoyer/recevoir de mail sur Internet.) et POP je ne sais pas mais je crois IMAP. De plus il est consultable avec des clients WEB si on le veut bien (admin notes linux compliant).
[^] # Re: super mais...
Posté par nodens . Évalué à 1.
et pis, le client tourne sous wine (bon, d'accord, il y a mieux, mais au moins, on peut avoir sa babasse sous linux et administrer du notes), et de la doc à ce sujet est fournie par IBM.
Cela dit, si c'est juste pour la messagerie, notes sux. mais pour le workflow et tout le bordel, si quelqu'un a une alternative sous linux (avec zope, peut-être ?) je suis preneur...
[^] # Re: super mais...
Posté par Guillaume Lefevre . Évalué à 4.
[^] # Re: super mais...
Posté par VACHOR (site web personnel) . Évalué à 10.
[^] # Re: super mais...
Posté par pasBill pasGates . Évalué à -4.
Quand au sandbox, faut peut-etre lire ce qu'il dit avant de dire n'importe quoi. Il parle du cote modulaire de la sandbox ou tu peux specifier des securites differentes pour des parties de code differentes dans le MEME soft, et ils ont pas pique ca a Java vu que Java n'a pas ca.
Quand au run-time Intel, c'est con t'es encore a cote de la plaque, ils ont fait ca car Intel voulait pouvoir utiliser le code de Mono dans ses softs(et ils ne voulaient pas entendre parler de GPL), le run-time d'Intel est en licence X11 aussi.
Faudrait voir a eviter de hurler si tu prends meme pas la peine de lire correctement le texte.
[^] # Re: super mais...
Posté par Gnurou (site web personnel) . Évalué à 10.
Perl je connais pas mais avec Python, je le fais tous les jours. Et si tu veux automatiser le processus tu as un superbe utilitaire (libre) qui s'appelle SWIG (http://www.swig.org(...)) qui te génère les wrappers tout seul. Et oui, tu peux faire hériter tes classes Python d'une classe C++. Etant donné que SWIG génère également les wrappers Perl, je ne vois pas ce qui l'en empêcherait également - mais je n'irais pas plus loin car je ne connais pas assez ce language.
[^] # Re: super mais...
Posté par pasBill pasGates . Évalué à -10.
- deriver une classe Perl en Python
- deriver une classe Python en C++
- deriver une classe Java en Perl
- ...
Bref toutes les combinations.
Alors t'as le choix de t'emmerder a faire des wrappers, utiliser 15 outils differents avec leurs usages differents et leurs particularites et perdre du temps et ajouter des bugs potentiels, ou utiliser un systeme qui fait tout ca de maniere transparente.
[^] # Re: super mais...
Posté par Jar Jar Binks (site web personnel) . Évalué à 10.
En plus, l'intérêt de réutiliser des classes C++ en Python est assez évident pour moi. L'intérêt de réutiliser des classes python en C++ est totalement nul.
[^] # Re: super mais...
Posté par pasBill pasGates . Évalué à -1.
- Tu ecris tes objets dans le langage qui convient le mieux pour la tache, disons en langage Y.
- Tu reutilises cet objet dans le langage X, a l'exterieur de l'objet il n'y a ABSOLUMENT AUCUNE difference quel que soit le langage, car justement tous les problemes concernant l'integration de langages differents sont effaces, ca devient totalement transparent.
Le resultat est que tu as potentiellement moins de bugs, car tu peux maintenant utiliser le langage le plus approprie pour une tache, et le reste du soft s'en moque totalement.
Quand a utiliser du Python en C++, ben je sais pas, au hasard creer des GUI simplement et rapidement contrairement a C++, ou autres, chaque langage a ses atouts.
[^] # Re: super mais...
Posté par lorill (site web personnel) . Évalué à 4.
mais pour ton histoire de gui, tu la fais en Python, tu fais le reste en C++, et tu utilise ton C++ a partir de Python. y'a pas besoin de l'opération inverse ici...
[^] # Re: super mais...
Posté par pasBill pasGates . Évalué à -8.
[^] # Re: super mais...
Posté par Jar Jar Binks (site web personnel) . Évalué à 2.
[^] # Re: super mais...
Posté par pasBill pasGates . Évalué à -5.
Resultat tu y gagnes en :
- vitesse de developpement
- simplicite du code, donc moins de bugs potentiels
Perl est baleze pour traiter les chaines de caracteres, tu utilises ca pour faire ce dont t'as besoin et le mettre sous forme d'objet, tu appelles cet objet depuis C++, t'as gagne des heures et t'as bcp moins de bugs compare a ce que ca t'aurais pris de faire la meme chose en C++.
[^] # Re: super mais...
Posté par Jar Jar Binks (site web personnel) . Évalué à 3.
Mais tu ne m'as pas expliqué l'intérêt, si tu fais un programme en C++ et une interface en python, d'appeler l'interface depuis le programme au lieu de faire le contraire. C'est plus sale et plus compliqué.
[^] # Re: super mais...
Posté par pasBill pasGates . Évalué à 0.
Chaque tache est independante et regroupee dans un objet, cet objet s'occupe d'afficher la GUI si il y en a une et faire la tache.
Resultat, ton soft va appeler l'objet qui affichera la GUI, et la GUI Python appelera peut-etre d'autres objets C++ derriere, mais elle serait dans ce cas appellee par C++.
Faut pas voir le mot GUI comme un truc qui represente tout le soft, ca peut-etre une partie infime du soft cachee dans un coin.
Sinon, je suis d'accord avec toi, Perl c'est fait pour les psychopathes, ou peut-etre que ca rend psychopathe...
[^] # Re: super mais...
Posté par Paerro Trime . Évalué à 6.
Tu fait ton objet dans le langage que tu veux, et tu t'en sert dans un autre de tes langages favoris, ya pas besoin du CLR pour ça.
Je croyais que les dernières itérations de COM faisaient tout ça aussi ?
signé : un psychopathe, fier de l'être.
[^] # Re: super mais...
Posté par Gnurou (site web personnel) . Évalué à 10.
Dans un projet que je développe, on a justement besoin d'appeler des méthodes d'objets Python existants à partir du code C++ (comme quoi, ca peut quand même servir de temps en temps), car il s'agit d'évènements déclenchés dans un packetage de données dont on veut qu'il soit totalement indépendant du reste. Enfin bref. Python propose toute un API C te permettant de manipuler ses objets, alors même que l'interpréteur tourne. Sachant qu'en général les méthodes Python que l'on rappelle ainsi utilisent des méthodes et objets C++ que l'on a wrappés avec SWIG, la boucle est bouclée: on a du C++ qui appelle du Python qui appelle nos fonctions en C++... C'est extrèmement puissant et absolument génial, et en plus le code Python reste bien évidemment portable sans aucune recompilation. Et on peut faire cela depuis des années. Et on n'a pas besoin de passer par une VM.
Bref, tout ca pour dire qu'on n'a pas attendu après .net ;)
[^] # Re: super mais...
Posté par Philippe F (site web personnel) . Évalué à 10.
Ce que propose .NET, c'est que ce genre de chose n'aura aucun cout. Ce sera exactement la meme chose d'appeler du C++, du JAva, du C#, de l'Ada du perl ou du python.
Reponse a Jar Jar Binks : l'interet, c'est qu'il y a des bibliotheques ecrites dans des langages tres variees, et tu pourras enfin les utiliser facilement sans pour autant etre contraint par le langage de la bibliotheque.
Imaginons que t'as une super biblio d'algo en C++ qui te permet de faire des calculs sur des surfaces a n dimensions (genre un truc pousse en math). T'as un super bon Gui en python. T'as des super traitements a faire sur des tres gros fichiers textes en perl. Et bien l'integration de tout ca dans une seule appli sera triviale. Je ne dis pas que c'est pas possible a coup de swig et autres a l'heure actuelle. Je te dis simplement que ce sera 10 fois plus facile avec .NET .
C'est pas parce qu'on defend le logiciel libre qu'il faut etre aveugle aux qualites d'un systeme, meme propose par Microsoft.
[^] # Oui, mais...
Posté par pas_moi . Évalué à 10.
Le problème, c'est que facilité ne va pas très bien avec efficacité: prenons deux personnes qui n'ont presque jamais touché un ordi et demandons leur de faire un rapport/une thèse, l'une avec MS Word et l'autre avec LaTex... Dans les premiers jours, l'utilisateur de Word ira sûrement plus vite que l'autre (les clicodromes, quoi qu'on en pense, facilitent le travail), mais après quelques temps, l'utilisateur LaTex se sera mis en place son petit environnement, aura compris quelques principes de la mise en page et finalement avancera bien plus plus vite que l'autre utilisateur (les clicodromes sont faciles à utiliser mais ne poussent pas les utilisateurs à apprendre de nouvelle façon de faire ce qu'ils savent faire)... LaTex n'est franchement pas facile quand on le découvre mais il est bien plus efficace une fois qu'on le connaît.
Ce que Microsoft nous propose, c'est d'automatiser l'interfaçage entre les langages... ce sera peut-être plus facile qu'en lançant tout plein de commandes à la main comme actuellement, mais je ne pense pas que ça puisse devenir plus facile à utiliser que des Makefile bien faits dans une arborescence bien étudiée. .Net va sûrement plaire à ceux qui développaient en VB et qui veulent passer à d'autres langages plus performants, mais je ne pense pas que ça intéresse les développeurs qui ont déjà un niveau suffisant pour savoir tapper:
> cd $PROJET/src/gui
> make cpp-interfaces
> cd $PROJET/src/core
> make py-interfaces
> cd $PROJET/src
> make
Bien sûr, rien n'empêche de mettre ces commandes dans un script (ou dans le Makefile principal) et d'associer ce script à un bouton dans son éditeur clocodrome préféré. Je préfère me simplifier le travail à ma façon mais faut admettre que l'utilisateur lambda n'en a généralement pas le temps (ou la volonté).
[^] # Re: Oui, mais...
Posté par pasBill pasGates . Évalué à -2.
Sinon, ca interesse DEJA des developpeurs ayant un niveau suffisant pour taper quelques lignes en command-line, tout simplement parce qu'ils gagnent du temps en n'ayant plus a creer des wrappers et ajouter du code donc des bugs potentiels, ca n'a rien a voir avec etre facile pour les neophytes, ca simplifie et accelere le developpement pour tout le monde.
[^] # Re: Oui, mais...
Posté par pas_moi . Évalué à 5.
ils gagnent du temps en n'ayant plus a creer des wrappers
Tu te trompes de commentaire: d'autres t'ont déjà expliqué ailleurs qu'il y a des outils qui créent les wrappers automatiquement, donc ils n'ont plus à être créés à la main. Rendre automatique ce qui est déjà automatique sur d'autres systèmes, voila la grande nouveauté de .Net??
Bon, encore une fois, tu n'es là que pour pourrir le débat (à part nous dire que c'est mieux parce que ça fait ce que l'on sait déjà faire, tu n'avance aucun argument). Je suis désolé d'avoir une opinion de tes commentaires qui me forcent à éviter de lire ce que tu racontes (tout n'est pas c*n, mais dans la globalité je ne comprends même pas que l'on puisse soutenir des positions comme celles que tu cherches parfois à défendre) donc je laisse tomber le débat... désolé, mais comme on dit poliment: «tu m'énerves» à ne faire avancer que tes idées, sans regarder que bien souvent les autres détruisent les principes sur lesquelles tes idées reposent (et ne me demande pas d'exemples, je n'en ai pas sous la main et je n'ai pas envie de chercher pendant des plombes vu que tu nieras tout et relanceras d'autres idées, comme d'hab.).
[^] # Re: Oui, mais...
Posté par pasBill pasGates . Évalué à -6.
Soit tu crees des makefiles qui creent des wrappers pour tout ce que tu ecris dans tous les langages possibles, et la bonjour le merdier avec des tonnes de fichiers inutiles, soit tu dois le faire a la main en specifiant quelles fonctions/objets wrapper.
Tu ne PEUX PAS remplacer ce que fait .NET pour l'interoperabilite des langages avec des makefiles, c'est simplement pas POSSIBLE.
Sinon, si tu crois qu'un developpeur experimente sous Windows utilise Visual C++ tel quel sorti de la boite tu te gourres lourdement, ca se configure aussi, je vois pas un seul truc que tu ne pourrais pas faire sous VC++ que tu peux faire sous un environnement ligne de commande, tout simplement parce que VC++ contient AUSSI un environnement ligne de commande et que tu peux utiliser les 2 en meme temps si ca te chante.
[^] # Re: Oui, mais...
Posté par Guillaume Laurent (site web personnel) . Évalué à 4.
C'est rien à coté de ceux qui lui répondent.
je t'explique qu'avec les outils de développement[...]
Tu n'expliques rien du tout, tu affirmes sans savoir, en ressortant des clichés. Je serais très étonné que tu ais la moindre expérience de développement en entreprise, particulièrement quand tu sors des anneries comme celles-ci :
Grace à Microsoft, les décideurs anticipent rapidement sur la vitesse de développement de leur personnel: c'est la même vitesse dès les premiers jours, alors qu'avec les outils libres, chacun se met en place ses outils, ses scripts/Makefiles et après quelques jours (bien souvent, ça se met en place en cours de développement) la productivité est bien meilleure.
Quand tu développes en équipe, tout le monde utilise les mêmes outils (à part l'éditeur). Personne ne se fait ses propres makefiles dans son coin, il y a toujours un framework existant sur lequel tu te bases, avec en général un cout non nul sur la productivité.
Bon, encore une fois, tu n'es là que pour pourrir le débat
Non, il avance des arguments valables, que vous niez à toute force en croyant savoir de quoi vous parlez. On est plusieurs au boulot à lire ce thread, tous Linuxiens confirmés je précise (depuis 94 pour les plus anciens), et on se bidonne en voyant les réponses de certains. Preuve que les neuneux ne sont pas forcément tous sous Windows.
Il n'y a pas de débat, vous ne voulez pas débattre. Vous voulez simplement qu'on vous dise ce que vous avez envie d'entendre, que MS c'est mal, que .Net c'est de la merde, que Miguel est un enfoiré, etc... Vous ne voulez surtout pas qu'on remette en cause vos petites convictions de rebelles à 2cents. C'est à cause de gens comme vous que Linux a tant de mal à s'imposer. On a jamais fait avancer les choses avec une paire d'oeillères sur la tête.
[^] # Re: Oui, mais...
Posté par Annah C. Hue (site web personnel) . Évalué à 1.
C'est sûr qu'avec des arguments tels celui-ci, le débat va pas voler bien haut.
Ton post, à part cracher sur ceux qui n'ont pas la même vision des choses que toi, ne contient rien de bien probant, tes arguments étant du même acabits que ceux de tes opposants.
Par exemple : Quand tu développes en équipe, tout le monde utilise les mêmes outils (à part l'éditeur).
Sûrement pas. Certains chez nous utilisent Vim, d'autres notepad, certains emacs, tous ont leur environnement différents (j'ai mes scritps mes makefiles à moi que personne d'autre n'utilise), mais on travaille pourtant ensemble sur des projets communs. Et je ne pense vraiment pas qu'on soit sous des manches à couilles en informatique. Alors, qui a tord, qui a raison ? Tu considère peut-etre que tu es très supérieur à nous pour avoir le même environnement que tes collègues ? Moi ça me donne plutôt l'impression inverse.
Les défenseurs de .NET parlent généralités, les attaquants lui opposent des FAITS, comme d'habitude sur les trolls microsoftiens.
Alors permet moi de me marrer en lisant ton post qui est du même niveau que ceux que tu critiques si ardemment.
Et oui, mon post ne fait pas avancer le schmilblick, je ne critique pas .NET car je n'ai pas la prétention de connaitre tout ses tenants et aboutissants.
[^] # Re: Oui, mais...
Posté par Guillaume Laurent (site web personnel) . Évalué à 4.
C'est pas un argument, mais une constatation. Entre le scoring systématiquement négatif des posts de pbg et les "arguments" qu'on lui oppose, ça me semble assez clair.
Ton post, à part cracher sur ceux qui n'ont pas la même vision des choses que toi
Quelle "vision" ? Je n'en ai aucune, j'ai juste eu une petite presentation sur .Net à ma boite il y a quelque temps, je ne sais pas exactement ce que ça peut faire. J'ai juste une impression globalement positive du truc, C# à l'air d'être un bon langage, pour le reste je ne sais pas. Ce sur quoi je crache, ce sont les réactions bornées de la plupart des gens ici. "Open Source, Closed Mind".
Sûrement pas. Certains chez nous utilisent Vim, d'autres notepad, certains emacs
Tu as bien lu le "à part l'éditeur" ?
Tu considère peut-etre que tu es très supérieur à nous pour avoir le même environnement que tes collègues ?
Non, avoir le même environnement que ses collègues est une obligation, au moins pour le build et la gestion des sources, c'est évident. Les scripts qui génèrent nos Makefiles et tous le système de build font quelques milliers de lignes et sont maintenus depuis des années. Je ne vais pas les refaire pour le plaisir, et si je veux que mon code soit compilé avec celui de tout le monde, il est normal que je m'intègre. Et ça a toujours été comme ça dans toutes les boites où j'ai travaillé.
Les défenseurs de .NET parlent généralités, les attaquants lui opposent des FAITS
Non, je n'ai vu passer aucun "fait", juste des poncifs. Je n'ai vu personne dire "je code sous .Net, voilà ce que je sais".
[^] # Re: Oui, mais...
Posté par #3588 . Évalué à 4.
J'espère qu'au moins tu n'es pas surpris. C'est le contraire qui aurait été étonnant !
Les défenseurs de .NET parlent généralités, les attaquants lui opposent des FAITS, comme d'habitude sur les trolls microsoftiens.
Très juste et c'est très important : en particulier parce que c'est bien MS qui sera le premier à implanter .NET, évidemment. Le long terme, on sait pas trop ce que ce sera, mais le début de .NET, ce sera MS. Or MS sait faire de bons trucs sur le papier, mais c'est souvent catastrophique dans la réalisation, au départ (meme si ca peut etre bon, c'est quand meme pas terrible par rapport à ce que ça aurait pu etre). Alors parler de .NET, pour l'instant c'est très vaporware, parce qu'il faudrait que ce soit bien implanté et répandu pour confronter la théorie à la pratique, et pour savoir ce qu'il en est vraiment.
Sur le papier, Java aussi ça a l'air parfait. Et puis en pratique, il y a les défauts qu'on connait. Memes si ces défauts disparaissent progressivement (ca devrait finir par aller plus vite que du code compilé par exemple), au début c'était pas ça. Quand je vois le temps que mets MS à sortir quelque chose de potable (W2K a du etre leur 1er OS digne de ce nom), je me dis que réussir un projet comme .NET dès le départ c'est pas franchement gagné. Et si c'est aussi ouvert qu'on le dit, je serais pas surpris de voir des concurrents faire mieux assez rapidement (je parle pas des initiatives libres, celles là je suis sceptique). Bref sur la conception, c'est tout beau, c'est plein d'avantages. Cette intégration de plusieurs langages, c'est vraiment très puissant (si on en a besoin). Si MS réalise ses promesses, oui ce sera surement très bien. Mais il y a ce si. Et si l'implémentation n'est pas à la hauteur, c'est clair que pour beaucoup de projets, pour lesquels .NET serait un petit plus mais ne serait pas fondamental, auraient intéret à utiliser d'autres solutions, déja existantes. Memes si elles sont "artisanales", si elles ont leurs limites, si elles sont en places et fonctionnent bien, il n'y a aucun intéret à migrer vers quelque chose qui serait mieux en théorie mais médiocre en pratique. Et puis, comme autre plateforme, il faut voir que .NET apporte autant d'inconvénients que d'avantages par rapport à Java, dont l'implémentation est moins douteuse, meme si le début a été laborieux.
[^] # Re: Oui, mais...
Posté par Jar Jar Binks (site web personnel) . Évalué à 2.
Ce sont des petites marmottes qui vont exécuter le bytecode ?
[^] # Re: Oui, mais...
Posté par #3588 . Évalué à 3.
Note que j'ai laissé un futur "vague", je n'ai pas voulu l'affirmer pour le jdk qui est actuellement en beta. Néanmoins il semble que ce soit déja le cas avec cette nouvelle jvm, pour des programmes qui s'y pretent bien.
C'est toujours une JVM qui exécute le bytecode. Par contre l'époque où les marmottes interprétaient le bytecode est révolu. L'époque où les marmottes ne faisaient que JIT-compiler aussi. Maintenant les marmottes sont intelligentes et optimisent le code quand elles le compilent. Et elles peuvent le faire mieux que lors d'une unique optimisation comme c'est fait pour du compilé : elles peuvent déterminer, en fonction de ce qui se passe à l'exécution, comment optimiser au mieux. Ce qui est inaccessible au code compilé une fois pour toutes.
Si tu sais compiler/optimiser aussi rapidement qu'exécuter, une machine virtuelle qui adapte cette compilation/optimisation à l'exécution est a priori bien meilleure qu'une classique compilation unique en natif.
[^] # Re: Oui, mais...
Posté par pas_moi . Évalué à 5.
Haaa, enfin quelqu'un qui parle posément, sans forcer sur le troll. Pour ma part, quand je m'intéressait aux développements sur la 3D, beaucoup de bonnes doc se trouvaient sur le site R&D Microsoft, où certaines techniques utilisées aujourd'hui dans des jeux comme Black&White étaient expliquées avec quelques années d'avance, le tout gratuitement!! Les idées proposées par MS ne sont pas toutes pourries comme certains le crient un peu trop fort, mais entre l'idée et l'implémentation il y a bien souvent trop de marge et ça finit en n'importe quoi, ce qui est regrettable pour les acheteurs, mais intéressant pour le libre qui y récupère parfois quelques idées (et aussi des clients :-).
Le truc qui m'embête dans ce que tu dis, c'est:
ca devrait finir par aller plus vite que du code compilé par exemple
Bondieu d'bondieu d'bondieu: comment un code interprété peut-il être plus rapide qu'un code compilé? Je veux bien admettre que les VM fassent des progrès, mais ce n'est pas une raison pour imaginer que les compilateurs vont se dégrader pendant ce temps là...
Le jour où les processeurs comprendront le bytecode Java, il ne devrait plus y avoir de différence, mais en attendant les compilateurs auront toujours le moyen de faire du code plus performant que n'importe quel interpréteur.
[^] # Re: Oui, mais...
Posté par #3588 . Évalué à 4.
Voir réponse à Jar Jar Binks. Les premières VM Java ne faisaient qu'interpréter. Mais une VM peut aussi compiler en natif, et exécuter. Il ne faut pas oublier que c'est du bytecode qu'il faut compiler, ce n'est pas du langage de haut niveau. Ensuite, idem pour l'optimisation du code natif. Un exemple simple. Quand tu fais de la compilation classique, tu vas dire au compilo de mettre telles et telles fonctions en inline, parce que tu sais que c'est une bonne optimisation. Ce genre de choix tu le fais 1 fois pour toutes, et tu ne vas pas pouvoir le faire partout. Ce travail là, c'est aussi ce que peut faire une VM intelligente, en analysant le bytecode. Et plus elle est intelligente, plus elle va savoir quoi optimiser en inline et à quel moment (pour rester sur cet exemple). Bon, faut pas me demander plus de détails sur le "comment", sur l'intelligence de la VM. Et pour ce qui est de la prochaine JVM, je sais juste d'après des collègues qui ont essayé la beta que le gain de vitesse est vraiment remarquable, et que c'est du à l'application de ces principes. Donc, comme je l'ai dit dans l'autre post, etre plus rapide que du compilé ça doit etre possible avec cette nouvelle jvm, dans certains cas qui s'y pretent bien, mais ce n'est surement pas encore le cas général.
Par contre, si les recherches avancent dans cette direction, il est clair qu'il y a matière à avancer là où du coté compilation ça parait plus figé. (pas besoin que les compilateurs se dégradent).
[^] # Re: Oui, mais...
Posté par pas_moi . Évalué à 2.
Tu parles justement de compilation classique... Si un VM est capable d'optimiser des fonctions par rapport aux données du programme exécuté, qu'est-ce qui empêche le compilateur de générer du code capable de ces même "prouesses"?
Il y a quelques temps, j'ai bossé sur un projet dont l'un des buts est justement d'obtenir de la génération de code à la volée, en fonction de paramètres donnés pendant l'exécution. Pour l'instant c'est hyper lourd à mettre en place, mais les principes sont là. http://compose.labri.fr/prototypes/tempo/(...)
[^] # Re: Oui, mais...
Posté par #3588 . Évalué à 1.
Oui on peut envisager des choses de ce coté là. Mais la VM voit l'exécution, le compilateur non. La VM voit que telle fonction est très utilisée à un instant du programme, moins après. Ses choix se feront au fur et à mesure. Le compilateur ne peut pas prévoir comment va se dérouler l'exécution (en particulier puisque plusieurs exécutions peuvent etre très différentes). La seule solution, c'est ce que tu dis, générer du code à la volée. C'est ca qui me paraissait plus simple ou naturel pour une VM que pour du natif (la VM a de toutes facons besoin de générer le code, et elle dispose du bytecode.)
[^] # Re: Oui, mais...
Posté par pas_moi . Évalué à 2.
La VM est chargée d'exécuter alors que le compilateur produit du code autonome. Dans le code produit par le compilateur, rien n'empèche d'intégrer une sorte de profiler/optimiseur et ainsi choisir d'inliner certaines fonctions/boucles de la même manière qu'une bonne VM. Ca peut paraître compliqué, mais si une VM peut le faire, un compilo aussi.
Pour en revenir à la spécialisation de code, il y a un exemple assez intéressant qui faisait partie des tests: prenons la fonction int interpreter(char* bytecode, int size), chargée d'interpréter du bytecode Java. Le test consistait à spécialiser cette fonction en donnant au spécialiseur le bytecode... résultat, on obtenait une fonction sans paramètre qui n'était autre qu'une version compilée du bytecode!! Grace à ce projet, il suffit donc d'écrire l'interpréteur d'un langage pour obtenir en quelques commandes un compilateur pour ce même langage :-) C'est-y pas beau.
[^] # Re: Oui, mais...
Posté par #3588 . Évalué à 0.
Oui en fait ces deux approches vont vers la meme solution, dans leur partie optimisation. Après tout bytecode et natif sont des "langages" pas si éloignés que ca, bien des techniques d'optimisation du bytecode fonctionneront aussi sur le natif.
[^] # Re: Oui, mais...
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Lesquels ?
Et puis, comme autre plateforme, il faut voir que .NET apporte autant d'inconvénients que d'avantages par rapport à Java, dont l'implémentation est moins douteuse, meme si le début a été laborieux.
Donc, en résumé : .Net ça peut être bien mais ça peut aussi pas l'être, et si ça l'est pas alors il vaut mieux ne pas l'utiliser. Et il vaudra mieux utiliser des solutions qui marchent, ou Java, même si c'est pleins de défauts que tout le monde connait.
Y a rien à redire, je suis d'accord :-).
[^] # Re: Oui, mais...
Posté par #3588 . Évalué à 1.
Les défauts classiques qui sont reprochés à Java, et c'était surtout le cas sur les premières implémentations : la vitesse principalement, aussi bien pour lancer une jvm qu'à l'exécution. Il y aussi eu des versions assez buggées.
Les reproches sont souvent nombreux à l'égard de Java, suffit de chercher un peu. Je ne détaille pas car personnellement, pour l'utilisation que je peux avoir à en faire, je trouve les inconvénients négligeables par rapport aux gains. Mais il y en a qui ne vont pas vouloir de Java pour ce genre de raison. Il est tout à fait possible que ça ne convienne pas.
Donc, en résumé : .Net ça peut être bien mais ça peut aussi pas l'être, et si ça l'est pas alors il vaut mieux ne pas l'utiliser. Et il vaudra mieux utiliser des solutions qui marchent, ou Java, même si c'est pleins de défauts que tout le monde connait.
Non. La plateforme, le langage, tu les choisis en fonction de ton projet. Et tu ne choisis pas non plus seulement à partir de ce qu'est ce langage ou cette plateforme sur le papier, tu te dis qu'il faut aussi tenir compte de ce qui est disponible comme implémentation. Enfin tout ça c'est des évidences. Et dans le cas de .Net, on ne sait pas si ce sera valable, ni quand ça le sera.
[^] # Re: Oui, mais...
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Tu sera d'accord aussi pour dire que rejeter une plateforme simplement parce qu'elle vient de MS n'est pas forcément une bonne chose, non ? MS peut aussi avoir de bonnes idées, ils n'embauchent pas que des cons, loin de là.
[^] # Re: Oui, mais...
Posté par #3588 . Évalué à 1.
Sur le plan technique, oui.
Par contre je vois de bonnes raisons de rejeter .Net, et ce n'est pas lié au fait que ce soit MS, mais que MS soit en situation de monopole. L'essentiel du framework a beau etre "ouvert" et normalisé indépendamment de MS, MS n'a pas caché que des extensions plus proprio étaient prévues. Je préfère par exemple Java meme si c'est Sun qui fait la norme, parce que là au moins toutes les spécifications des extensions sont fournies. Et il y a tous les effets pervers d'un monopole, si MS ne suit pas *exactement* les spécifications, le standard de fait ce sera leur implémentation, pas le standard officiel. Donc .Net, je le rejette parce que pour l'instant je le considère néfaste sous cet aspect. Mais ce n'est pas du tout pour des raisons techniques.
MS peut aussi avoir de bonnes idées, ils n'embauchent pas que des cons, loin de là.
Bien d'accord oui. D'ailleurs ce qui est surprenant avec MS c'est la piètre qualité de certaines implémentations, alors qu'il y a de très bonnes idées coté conception. Ils donnent l'impression d'avoir des gens très bons, et d'avoir beaucoup de bonnes choses en recherche et conception, mais qui sont pas mal gachées dans les implémentations de certains produits.
[^] # Re: Oui, mais...
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Là aussi, je suis d'accord. Il y a une bonne part de "hype", et MS n'est pas un enfant de choeur. Mais si les idées sont bonnes, et je pense qu'elles le sont (au moins, C# est vraiment un bon langage), tenter d'en faire une implémentation libre est une bonne chose. Je dirais même que c'est presque necessaire, afin d'établir une forme de "contre-pouvoir". Le libre ne pourra pas lutter contre .Net en proposant des wrappers python autour de libs C.
D'ailleurs ce qui est surprenant avec MS c'est la piètre qualité de certaines implémentations
En fait MS ne fait pas forcément pire que la plupart des autres boites, et même globalement je pense qu'ils font souvent mieux, si tu prends en compte la taille de leurs produits. Simplement leur position de leader fait que tout le monde est au courant de leurs merdes, et leur pratiques commerciales n'arrangent pas les choses.
[^] # Re: Oui, mais...
Posté par pas_moi . Évalué à 8.
Va falloir que je revérifie ce que j'ai fait depuis quelques années... je passe peut-être trop de temps sur DLFP mais j'ai quand même le temps de faire mon boulot de développeur.
Quand tu développes en équipe, tout le monde utilise les mêmes outils
Quand tu lances un développement, tu ne peux pas savoir à l'avance toutes les taches qu'il sera bon d'automatiser. Ca se fait petit à petit en utilisant les outils que les autres ont déjà mis en place pour se simplifier la vie. Oui tout le monde est sensé utiliser les mêmes outils, ça n'empêche pas de chercher à se simplifier le travail puis de proposer ses petits scripts aux autres développeurs.
Preuve que les neuneux ne sont pas forcément tous sous Windows
Ha bon, t'es pas sous Windows :-) (désolé, elle était trop facile)
MS c'est mal
Tu me trouves où j'ai dit ça ou tu arrêtes de me prendre pour un con. Quand j'explique que les outils Microsoft forcent l'utilisation de certaines méthodes de travail, je ne dis pas que c'est de la merde. Le outils libres impliquent aussi des méthodes de travail, la différence étant que l'éventail des possibilités est plus large avec le libre (à mon avis).
.Net c'est de la merde
Je n'ai pas dit ça, le principe de .Net est bon: simplifier la vie du développeur, je ne peux pas être contre en tant que développeur; par contre, je me base sur des outils comme le Visual C++ que j'ai pas mal utilisé (et qui m'a bien plu pour commencer à développer, mais qui m'a rapidement freiné par rapport à ce que j'arrive à faire maintenant avec les outils libres) et j'imagine, peut-être à tort, que MS va reprendre de principe du développement assisté à base de clicodrome.
Miguel est un enfoiré
Là, tu me pêtes les couilles (je suis désolé de la grossièreté, mais au moins le message est clair). Soit tu réponds à mon commentaire, et je n'ai jamais parlé de Miguel, soit tu réponds à ceux qui disent que Miguel raconte n'importe quoi. Pour ma part, Miguel peut dire ce qu'il veut, aucun décideur n'est capable de dire ce que sera l'informatique dans 2 ans donc j'évite de débattre ce que les Nostradamus modernes racontent.
Vous ne voulez surtout pas qu'on remette en cause vos petites convictions de rebelles à 2cents
/sbin/trolld: segfault
C'est à cause de gens comme vous que Linux a tant de mal à s'imposer
/sbin/trolld: respawning too fast
On a jamais fait avancer les choses avec une paire d'oeillères sur la tête
C'est con que tu dises ça à moi, je développe autant sous Windows que sous Linux (avec un ch'tit peu d'HP-UX et de Solaris, mais ça ne compte pas assez pour que je puisse parler de ces systèmes à part pour dire que je n'ai pas été franchement emballé)... je me considère tout de même assez bien placé pour faire des comparaisons. Ce n'est pas avoir des oeillères que de donner son avis avec des arguments, par ça l'est de répondre à cet avis avec des troll et des attaques à deux balles qui n'ont rien à voir avec ce qui est raconté.
[^] # Re: Oui, mais...
Posté par Guillaume Laurent (site web personnel) . Évalué à 2.
OK, là je suis d'accord.
Tu me trouves où j'ai dit ça ou tu arrêtes de me prendre pour un con.
Je ne parlais pas pour toi en particulier, mais de la majorité des réponses ici. Par contre je reconnais m'être trompé à ton sujet, je te fais donc mes excuses.
[^] # Re: Oui, mais...
Posté par pas_moi . Évalué à 1.
[^] # Re: Oui, mais...
Posté par Christophe Boyanique . Évalué à -1.
Bon désolé tu vas te retrouver à -218 (moi aussi d'ailleurs) pour avoir osé critique l'homo-linuxfr de base :(
Je considère moi aussi que .net c'est mal pour plein de raisons; mais quand je vois les «débats» ici franchement j'ai honte tellement cela est pathétique.
[^] # Re: Oui, mais...
Posté par pas_moi . Évalué à 1.
[^] # Re: super mais...
Posté par Jar Jar Binks (site web personnel) . Évalué à 8.
Outre le coût financier du truc, je me permets de douter qu'une quelconque méthode utilisant une machine virtuelle n'ait aucun coût en matière de vitesse et d'utilisation mémoire.
[^] # Re: super mais...
Posté par Jar Jar Binks (site web personnel) . Évalué à 4.
Imaginons que t'as une super biblio d'algo en C++ qui te permet de faire des calculs sur des surfaces a n dimensions (genre un truc pousse en math).
Ce genre de systèmes est totalement exclu pour tout calcul numérique. Je te rappelle que pour ce genre d'applications, les performances sont absolument critiques. On ne va pas s'amuser à les foutre dans une machine virtuelle pour gagner 5 minutes sur le développement de la GUI...
[^] # Re: super mais...
Posté par pasBill pasGates . Évalué à -6.
[^] # Re: super mais...
Posté par Epsos . Évalué à 2.
Waouh la revolution.
Champion de la mauvaise foi comme revolution la
Epsos (j'm'authentifierai une autre fois)
[^] # Re: super mais...
Posté par pasBill pasGates . Évalué à -3.
[^] # Re: super mais...
Posté par Aza . Évalué à 2.
Ce que je vois surtout c'est qu'un mec super baleze en C++ va utiliser du C++ partout dans son projet. Peut etre qu'il aurait été plus vite avec un autre langage mais
1°) il aurait fallu qu'il connaissent les autres langages aussi bien que le C++ ce qui n'est pas dit. Il ira peut etre même bien plus vite en C++ qu'en perl juste parcequ'il connait mieux le C++
2°) il utilisera un framework pour faire le boulot chiant et aura déja une base qui marche pour tout écrire en C++
Bref, utiliser plein de langages différents dans un projet c'est bien beau mais je ne connais pas beaucoup de monde capable de faire ca correctement.
[^] # Re: super mais...
Posté par Philippe F (site web personnel) . Évalué à 0.
Mais le multi-langage reste utile:
- quand tu as des biblio ecrites dans des langages que tu ne veux pas utiliser
- quand le langage apporte vraiment un gain enorme. J'ai vu un systeme avec un gui en C++, un traitement d'IA en prolog, des traitements en perl, parce que chaque tache etait tres grosse a traiter et necessitait vraiment un langage adapte.
Ca marchait en corba d'ailleurs. Corba, c'est vrai que c'est bien mais c'est le marteau piqueur. Un bouquin de 1000 pages et 100 lignes de code avec trois classes differentes pour 10 lignes de code util, j'ai vecu.
Donc en fait, c'est surtout pour l'utilisation de bibliotheques que c'est pratique et pour ca, swig marche tres bien. Ok, vous avez gagne.
N'empeche, je suis toujours degoute quand je fais un truc sous Windows en 10 min alors qu'il m'aurait fallu au moins une semaine avec des outils libres pour faire la meme chose.
[^] # Re: super mais...
Posté par jice (site web personnel) . Évalué à 2.
heu...
je crois qu'on ne peut pas appeler du c++, de l'ada, du perl ou de l'obiwan kenobi de façon transparente, car ce n'est pas du vrai c++, ada, perl, python, mais une façon d'écrire du c sharp "qui ressemble à" ada, perl, etc. afin de convaincre les développeurs à venir à point net.
bref, encore une fois m$ changerait^Waméliorerait-il des standards ? ;)
m'enfin, moi je dis ca, je dis rien ;)
[^] # Re: super mais...
Posté par Gnurou (site web personnel) . Évalué à 9.
Si je veux dériver une classe Perl (language de script donc), je le ferais en Perl car j'aurais accès au code source. C'est aussi simple que ça. Avoir tous les languages qui peuvent interopérer entre eux, c'est bien, mais ca ne sert qu'à combler une lacune: le code source n'est pas disponible, on ne veut pas qu'il le soit alors on rajoute des couches pour pouvoir réutiliser quand meme. On se prend le chou avec une VM qui ne sera jamais aussi performante que du natif, on déguise les défauts en avantages et on enrobe ca à la sauce marketting. Et hop, .net.
Autant je vois l'intéret de pouvoir appeler du code C ou C++ à partir de Python ou Perl, autant dériver une classe d'un language interprété vers un autre language interprété me semble inutile (limite stupide).
Tu prends du code Perl ou Python, c'est soit du texte, soit du bytecode pour une machine virtuelle. Evidemment tu ne peux pas hériter avec cela. Mais je préfère largement ca à un système qui met tous les langages au meme niveau de vitesse que les plus lents (les interprétés) juste pour avoir le plaisir de les voir interopérer.
L'avantage de Perl et de Python est qu'ils sont portables jusque dans le bytecode. Avec .net, certes tu peux faire en sorte de dériver une classe Python dans du C++. Mais la conséquence directe de cela est que le code généré par Python ne fonctionne plus que sur .net - fini la portabilité. Dans ce cas quel est l'avantage d'utiliser un langage de script si c'est pour qu'il ne fonctionne que sur une plate forme?
[^] # Re: super mais...
Posté par pasBill pasGates . Évalué à -8.
- Tu n'ecris pas ton soft selon le langage
Mais
- Tu utilises le langage approprie pour ton soft
C'est ca l'idee derriere l'interoperabilite des langages. Si tu veux deriver une classe Perl, tu la derives avec le langage le plus approprie pour ce que tu vas faire de la classe, tu la derives pas en Perl parce qu'elle a ete ecrite en Perl.
Le coup des codes sources pas accessibles c'est completement bidon et ca n'a rien a voir, je ne vois absolument pas le rapport avec la choucroute, faudra m'expliquer le rapport, c'est les gens comme toi et moi qui vont ecrire les softs qu'ils veulent, je vois pas le rapport avec du code sans le source.
Quand a deriver des classes d'un langage interprete dans un autre, ben exemple simple:
Perl est baleze pour la gestion des chaines de caracteres contrairement a la plupart des autres langages, resultat tu utilises une classe ecrite en Perl pour traiter tes chaines, et tu ecris le reste du soft dans ton langage prefere.
Sinon t'as a premiere vue pas compris comment .NET fonctionne.
Ton soft est compile avant execution, y compris les parties interpretees de ton soft, car TOUT le soft a ete prealablement transforme en un langage intermediaire. Faut bien voir qu'un langage n'est pas specialement interpete ou compile, c'est independant de cela, je pourrais t'ecrire un interpreteur C et un compilateur Lisp.
[^] # Interprétation/Compilation ...
Posté par Jean-Yves B. . Évalué à 10.
Tu as raison dans l'absolu mais il ne faut pas exagérer. Compiler des langages où le typage est mou genre Python ... ce n'est pas vraiment compilé. Pareil pour le LISP. C'est compilé certes, mais l'environnement d'exécution est tel que l'on peut appeller ça de l'interprétation quelque part.
Juste mes 2E-2 EUR
[^] # Re: super mais...
Posté par Gnurou (site web personnel) . Évalué à 1.
Le coup du code source accessible n'est pas pour autant bidon - placons nous dans le cas où je veux un programme natif (désolé mais les VM à outrance à la Java et compagnie, j'aime pas trop). Si j'ai le code source à disposition, j'arriverais bien plus facilement à faire interopérer des objets écrits dans des langages différents - car je pourrais générer des wrappers par exemple. Voila pourquoi je sous-entendais que si tu utilise des logiciels dont tu as le code, l'intérêt est moins évident.
Pour l'histoire de Perl et des chaînes, ce n'est plus totalement vrai. Bien d'autres langages ont repris le même système et sont aussi performants maintenant - et quand bien même tu voudrais le faire avec perl et C++ c'est possible. Pour Perl/Python je n'en sais rien.
[^] # Re: super mais...
Posté par Bertrand Mathieu . Évalué à 3.
Enfin si tu veux juste utiliser un objet écrit dans un autre langage, il y a il me semble une autre solution que le wrapper: IDL et son copain Corba. Mais je ne suis pas un spécialiste, c'est peut-être une bêtise.
Bon sinon j'admet je n'ai pas regardé ce qu'offre .NET, donc je ne m'avancerai pas à critiquer le système. Par contre si quelqu'un peut expliquer comment fonctionne l'interopérabilité automatique évoquée plus haut, je suis tout ouïe.
[^] # Re: super mais...
Posté par Stephane JUTIN . Évalué à 0.
Franchement, sur ce coup-là, la mauvaise foi de linuxfr est patente : on score tout les postes de PBPG en négatif (pourtant informatif puisque décrivant l'architecture .NET), on réponds avec des arguments du style "ouais, c'est vrai qu'on peut pas le faire, mais bon comme j'ai décidé que ça servait à rien, j'ai raison quand même" jusqu'à ce qu'il se lasse devant un tel mur d'incomprehension et on a ensuite le culot de l'accuser de faire la même chose que ce que fait LinuxFr à savoir répondre sans cesse.
C'est d'autant plus dommageable que il y a mon avis de vrai raisons fondé pour lui répondre ...
Sinon sur .NET lui-même, quand j'étais dans ma boite de stage, les commerciaux nous avaient apris un truc de marketing : ça consiste à inventer un mot ou un sigle (qui désigne un truc que tout le monde connait mais qui n'avait pas nom) pour vendre un produit, et il nous citaient l'exemple de Checkpoint qui avait inventé le mot "stateful" pour qualifier un firewall.
Les commerciaux avait voulu appliquer cette stratégie, ils avaient inventé le mot "bidule chouette" (bon ok, c'était un autre mot mais je veux préserver les innocents), je me souviens encore de l'air ébahi des techniciens quand on leur avait anoncé qu'on était "bidule chouette" ("on est quoi !").
Ensuite dans leur discours commercial ils balançaient aux clients : les concurrents, ce ne sont pas des concurrents,ils ne sont pas "bidule chouette" - ce que faisait Checkpoint pour démolir les autre firewalls (style Kernel 2.2) en disant ce ne sont pas des concurrents ils ont pas "statefull -.
Je sais c'est con, mais ça attrape bien le DSI moyen qui lit son 01 Informatique et qui est toujours à l'affut d'un nouveau mot savant.
MS a déja appliqué ce genre de stratégie marketing : je pense à l'invention du mot DHTML pour désigner l'association du JavaScript et du DOM : un truc qui existait déjà donc mais qui n'avaient pas nom avant.
Franchement, quand je vois tout ces gens qui sautent comme des cabris sur leur chaise (désolé pour la référence) en criant ".NET", je me demande si tout ça ne révèle pas là encore plus du discours marketing que de la réelle innovation.
La plupart des gens qui parlent de ".NET" ne savent même pas ce que c'est ! Et je ne pense que MS ne souhaite pas que les gens démystifient leur discours marketing, n'est-ce pas justement une chose interéssante que pourrais faire LinuxFr au lieu de scorer tout les postes de PBPG en négatif.
Expliquer aux gens que .NET ce n'est que l'assemblage de techno existantes et apprendre au x gens à séléctionner parmis ce coktails les ingrédients qui les intéressent et eux seulement.
Pour l'instant le coktail se compose de :
- un langage clone de Java (C#) - essayant de profiter de l'expérience acquise sur Java pour améliorer la syntaxe sur quelques points - qui génére du bytecode (pardon de l'Intermediate Language)
- une bibliothéque standard (style JDK) baptisée CLR
- un protocole de RPC via XML (SOAP) comme DCOM ou Corba mais qui passent à travers les firewalls
(supporté par Perl je crois)
- les technologies habituelles de MS : ASP, ADO pour l'accès au BD ...
Bref rien d'aussi révolutionnaire que MS voudrait nous le faire croire ...
Que PBPG me corrige si j'ai tort, je serais ravi d'en apprendre plus sur .NET :-)
[^] # Re: super mais...
Posté par PLuG . Évalué à 1.
humm, je ne sais pas si c'est réellement checkpoint qui a inventé le mot "statefull". mais entre un firewall type kernel 2.2 (ipchain) et un firewall type kernel 2.4 (iptable), il n'y a pas de comparaison. Ce que l'on appelle communément désormais "statefull", qui consiste a traiter les flux en fonction de leur etat (state), connecté, en relation ... FAIT TOUTE LA DIFFERENCE.
on ne peux pas comparer FW-1 et linux-2.2 pour cette raison. un firewall qui ne se souvient pas des etats des connections est obligé de laisser entrer tous les ports hauts (1025-65535) pour laisser passer les réponses aux requetes émises par les clients du réseau interne, ce qui représente beaucoup de tracas en terme de sécurité.
linux-2.2 est comparable aux routeurs avec acl de cisco. cisco ne les vends pas en temps que "firewall".
linux-2.4 est concurrent de FW-1 (checkpoint) et des pix (cisco). A mon avis il est meme meilleur car plus configurable.
bref, "statefull" n'est pas juste un argument marketing comme tu le laisses entendre. Pour .NET que je ne connais pas, si c'est un middleware sans plus que les autres (corba, ...) alors c'est du discours de marketing. mais il faut bien voir une chose: corba est (etait ?) plein de promesses mais les specs étant incompletes, les implementations ont du les étendre a leur facon pour être utilisable. résultat: plusieurs implémentations de corba qui n'intéragissent pas entre elles. C'est peut etre cela qui a fait de la place a un .NET aussi !!!
[^] # Re: super mais...
Posté par Stephane JUTIN . Évalué à 0.
C'est le commercial de mon ex-boite qui me la dit et ce gars la avait l'air de bien connaitre le marché de la sécurité (d'un point de vue commercial) et d'un point de vue technique il avait un fw perso sous OpenBSD pour son ADSL (ce qui est pas mal pour un commercial qui est sensé être nul en technique).
... flux en fonction de leur etat (state), connecté, en relation ... FAIT TOUTE LA DIFFERENCE.
J'ai jamais dis que c'était bidon d'un point de vue technique, juste que l'invention marketing était de mettre un mot sur le concept, et de le repéter, le répeter ... jusqu'à ce que ça rentre dans la tête des gens ...
Ils se trouve que là c'était une vrai nouveauté technique mais bon là où s'est très fort, c'est que ça marche aussi quand s'en est pas une !
Prends le Charisma Engine d'ATI, c'est pas inutile comme truc un Transform & Ligthing, mais bon ils auraient pu s'abstenir de donner un nom au machin.
C'est ce que je te disais tout à l'heure vis à vis du DHTML, c'est bien le DHTML, simplement sur ce coup-là MS a plus inventé le nom que la technique qui existaient déjà avec Netscape (Javascript + DOM).
[^] # Re: super mais...
Posté par Bertrand Mathieu . Évalué à 0.
[^] # Les services Web
Posté par Stephane JUTIN . Évalué à 1.
Je m'explique avec l'avénement de la programmation objet (C++) on nous avait promis la disponibilité de composants "sur étagères" , et que la programmation disparaitrait au profit d'un simple assemblage de légo, ça ne c'est jamais concrétisé
Avec l'avénement de Corba, on nous avais promis la même chose, avec un modèle de facturation d'objet à l'usage, ça ne s'est jamais concrétisé...
Maintenant, avec les services Web, on nous promet la facturation d'appel SOAP, rien de différent de ce que promettaient Corba il y a dix ans (avec la seule différence que SOAP passe plus facilement un firewall que IIOP).
Jusqu'ici, le seul vrai service Web, c'est Passeport, et le principe d'une authentification centralisé entre les mains d'une entreprise privée pose des problèmes de respects de la vie privée.
En attendant, je crois qu'il existe des implémentations SOAP pour de nombreux langages, et comme Passeport est sensé être basé sur SOAP je pense qu'un programme en PERL devrait pouvoir s'authentifier via Passeport si tel en était le désir de son programmeur.
[^] # Re: super mais...
Posté par VACHOR (site web personnel) . Évalué à 3.
Traduire : outil pour neuneu.
Par ailleurs, il existe des gens compétents qui se passent sans problème d'outils pour neuneux, même si ce n'est pas la majorité, cette dite majorité utilisant pour une très large part M$ zindoze (le système qui fabrique des neuneux, (c) M$ 1985-2004).
[^] # Re: super mais...
Posté par pasBill pasGates . Évalué à -7.
Vaut mieux etre un gars qui perd du temps a faire un truc au final peut interessant et qui peut amener des bugs en plus dans ton soft alors qu'il y a un soft qui se charge automatiquement de tout faire a ta place et sans bugs.
Au final je me demande qui c'est le plus idiot, celui qui utilises les outils dispo pour se faciliter la vie, ou celui qui se fait chier pour rien alors qu'il y a tout ce qu'il faut pour lui simplifier la vie.
Un jour l'illumination te viendra peut-etre, et tu te rendras compte que le but de l'informatique c'est d'automatiser les taches repetitives, simplifier la vie des gens,...
Mais bon, a premiere vue t'as plus de facilite a balancer des attaques debiles dans le genre de celle-ci qu'argumenter sur le fond de la chose.
[^] # Heu , C'est pas pour dire mais
Posté par adolphos . Évalué à 1.
Il n'y a pas de contre indication.
Je te le dit, parce que moi, je suis incompétent. Et bien en souris ou au clavier, c'est pareil : je suis toujours incompétent.
En plus, cocher une case ou ecrire "machinchose on"
le résultat est le même mais tu gagnes du temps avec un petit clic.
(Le prix Nobel pour l'inventeur de la Souris, c'est pour quand ?)
Tu ne serais pas un peu snob, toi ?
Parce que, laisses moi te rappeler, les vrai programmeurs, ils utilisent exclusivement l'assembleur, pas des truc de pédales.
et ed, pas VIM ou Emac.
[^] # Re: Heu , C'est pas pour dire mais
Posté par PLuG . Évalué à 0.
exemple: dans DNS sous windows, pendant longtemps on ne pouvait mettre que 2 serveurs. (je ne sais pas maintenant). Pourquoi limiter à 2 ??
alors que dans resolv.conf, tu en met autant que tu veux.
pour NTP sous w2k, je ne sais pas gerer une liste de serveur avec des poids différents.
avec FW-1, quand tu veux activer l'anti-spoofing, tu as quelques choix dans un menu planqué (puisque l'anti-spoofing se fait par interface et que FW-1 ne gere pas de regles par interface, ils ont du ajouter un truc ailleur ...). J'ai rencontré des configurations ou les choix prévus ne donnent pas satisfaction ... => perdu. Alors qu'avec iptables, je fais l'anti-spoofing que je veux, personne n'a pensé POUR MOI de quoi j'avais besoin.
le probleme est pas tant dans le mulot, mais plutot dans le fait que la représentation graphique est orientée en fonction des solutions PREVUES PAR LE DEVELOPPEUR. Si le developpeur n'a pas prévu ton probleme, tu perds.
# YESSSSS
Posté par Christophe Merlet (site web personnel) . Évalué à -10.
Peut-on espérer 200 commentaires et... -50 pour moi ?
[^] # Re: YESSSSS
Posté par Loup Ysengrin . Évalué à -4.
Troll ? En tout cas y'en a qui sont intarissables, voir la contrib de pasBillpasGates, d'un volume impressionant à défaut du reste.
[^] # Caillous vendus séparément [...]
Posté par Youssef Oualmakran (site web personnel) . Évalué à 5.
http://www.fosdem.org/schedule/(...)
Attention !!!!
Seul les 450 PREMIERS ARRIVES auront une place assise !!!!
P.S : Caillous non fournis
P.S-2 : Avec l'aimable colaboration de RMS
[^] # 162 messages, 442Ko ! Le Délire !
Posté par adolphos . Évalué à -4.
Pour le mega octet, MDI et Linuxfr se sont associés.
Aussi, Vous pouvez faire encore mieu !
Car FT a besoin de vous !
Merci !
(Et n'oubliez pas de poster vos promesses de post)
[^] # Re: YESSSSS
Posté par Christophe Merlet (site web personnel) . Évalué à -1.
# nimportenawak
Posté par kalahann . Évalué à 10.
Mais au fait, qui est le vrai leader de gnome? Car il me semble que MDI ne l'est plus... J'ose espéré que ce genre de conneries (c'est le mot qui convient) ne donnera lieu à rien. Pouvoir communiquer avec des applis .Net, ou que des applis gnomes *puissent* être développées en .Net je veux bien, mais baser des logiciels libres sur des fondations pourries, non merci...
En tout cas c'est Scott MacNealy qui va être drôlement content! Avec Gnome qui est censé être inclut dans les prochaines versions de solaris, il va lui aussi manger de la sauce krosoft...
Ahhh, peut-être qu'enfin, on aura le suport NetBios dans le kernel?
[^] # Re: nimportenawak
Posté par imr . Évalué à 10.
mdi dirait "fessez moi avec une pelle" qu'il n'en recevrait pas autant. Là, il est sur d'en recevoir pendant un moment:
-personne du libre lui pardonnera ce cirage de pompe (pour être poli) intégral.
-il sera pas pour autant bien considéré chez son nouveau payeur de factures.
Par ailleurs les petites remarques du register sont assez savoureuses:
"It's strategic for us - lots of people will develop applications in .NET
Really? We'd always figured it was a defensive move. The technology is really RPC under a new name, and Microsoft's been doing that for ten years It's not about attracting new developers, is it? "
Personnellement, j'ai une trop haute idée idée des gens qui participent à gnome pour croire qu'ils vont laisser passer ce genre de truc... et je parle même pas de Sun.
[^] # moi je verrai bien le scénario suivant :
Posté par Le_Maudit Aime . Évalué à 10.
2- le reste de la communauté ne suit pas et un fork a lieu
3- ximian continue son histoire d'amour avec MicroMou et porte evolution sur .net
4- on continue comme si ximian et MdI n'existaient pas.
sans déconner kde ou gnome : quelle importance ? Dans quel état sera [star,open]-office est bien plus intéressant.
Si Sun arrive à déveloper un TTX qui aurait la légéreté d'abiword avec les fonctionnalités de "Mot Pour Fenètre(r)" alors là ca va chier.
et Si Sun DECIDE que Star Office sera inter dépendant avec LEUR version de Gnome, je ne donne plus très cher de MdI.
A Mon humble avis, Ximian s'est aperçu que repackager gnome ne rapportait pas un rond (c'est le travail des distribsz) et .net est arrivé comme solution de rechange pour leur business plan totalement merdique. Toutes les conneries de MdI sur .net, cela lui permet aussi d'exister médiatiquement.
Il avait déjà fait le coup avec ses critiques sur UNIX qui n'étaient pas formellement infondées, mais quels résultats ?
en rêvant un peu : j'aimerai bien voir une discussion Mdi - Linus Torvalds.
[^] # Re: moi je verrai bien le scénario suivant :
Posté par Yusei (Mastodon) . Évalué à 9.
À mon avis ça serait décevant comme duel, Linus se soucie trop peu de l'aspect politique du libre pour que ça dégénère. Ici la plupart des trolls se basent sur l'idée de trahison, alliance avec l'ennemi, etc.
[^] # Re: moi je verrai bien le scénario suivant :
Posté par Neryel . Évalué à 10.
[^] # ce serait pas mal quand même
Posté par Le_Maudit Aime . Évalué à 7.
Mdi: et alors Gnome 3.0 sera partiellement basé sur .net
LT: quand est-ce que tu codes ?
Mdi: et gnome 4.0 complètement basé sur .net
LT: quand est-ce que tu codes ?
etc.
bon finalement même le troll nous fait rêver (c:
[^] # Re: moi je verrai bien le scénario suivant :
Posté par imr . Évalué à 10.
kde ET gnome sont importants.
Quand j'ai besoin d'un desktop j'utilise kde2 de la même maniére que j'utilisais gnome avant kde2 (et je l'aurais utilisé me si kde1 avait été gpl, par pure préférence).
Et quand je lis ce que sera gnome2 je salive.
Et comme les 2 projets sont en émulation, ca profite à tout le monde...
Et quand je lis qu'un type important dans l'histoire de gnome et influent dans son développement veut le faire aller dans la direction .net par la suite, ce point là dépasse les histoires de politique ou de trahison ou de biz modéle. C'est un point important, et selon son inclinaison, inquiétant.
Donc je vote avec toi pour que gnome continue son chemin indépendemment de ximian et surtout de ms avec une nuance:
1/MdI oriente le nouvo gnome vers .net,
2/tout le monde rigole et lui dit "tu réves?". pas besoin de fork, il est engagé alors au service des bugs de nt.
[^] # à propos de gnome et kde
Posté par Le_Maudit Aime . Évalué à 10.
On a mis KDE et Gnome. Malheuresement la SuSE boote par défaut sur KDE, donc on a essayé de mettre le choix entre les 2 au démarrage de [K,G,X]DM.
Et finalement les utilisateurs ont choisi .... IceWM considéré comme plus rapide plus léger etc.
Le seul avantage de Gnome/KDE que je vois par rapport aux anciens windows managers, c'est CORBA/KDOC, et c'est là où l'importance de SUN me semble valoir la peine d'être notée.
[^] # C'est KPart
Posté par wismerhill . Évalué à -3.
[^] # Re: C'est KPart
Posté par Philippe F (site web personnel) . Évalué à 10.
# Ah ça me rassure !
Posté par Infernal Quack (site web personnel) . Évalué à -10.
Je comprends mieux maintenant, ils veulent aider le projet GNOME ;)
hop -1 et [jesors] :)
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # moi ca me fait plutot rire... ou pas
Posté par Sylvain Dusart (site web personnel) . Évalué à -3.
-1 car très très private
# Juger sur les actes, pas sur les paroles
Posté par f l . Évalué à 10.
Ca fait combien de temps que MDI est hait par une partie de la communauté pour ses déclarations? Un bail...
D'ailleurs a chaque fois qu'il déclare quelquechose, ca trolle violemment entre les pro et les anti MDI.
A chaque fois il y a des commentaires du genre "cette fois il a pété les plombs" "il abandonne la philosophie GNU, il va nous faire du propriétaire" "blah blah blah Microsoft".
Mais je trouve qu'on a pas trop a se plaindre jusqu'a présent. Par ex, evolution, qui a été développé par les gros mechants de chez Ximian, est vraiment un logiciel formidable! Et GPL!
Miguel peut declarer ce qu'il veut, je prefere le juger sur son boulot. Et pour le moment je trouve qu'il a fait du bon boulot.
<TROLL>
Et si ca se trouve, .NET est vraiment LA technologie de l'avenir et MDI a de bonnes raisons de s'y intéresser
</TROLL>
[^] # Juger sur les actes, pas sur les paroles
Posté par kalahann . Évalué à 10.
Oui, peut-être. D'ailleurs je trouve C# vraiment bien du moins sur le papier, par rapport à C++ et à Java. Mais peut-on faire confiance à la démarche de microsoft? Désolé, mais je ne crois pas. En tout cas je suis trop méfiant pour croire que ça pourrait nous servir.
Quand à MDI... Ca existe encore des pro-MDI?
soit c'est un visionnaire, soit c'est un mégalo...(qualités techniques mises à part) mais je crois avoir mon idée :)
[^] # Re: Juger sur les actes, pas sur les paroles
Posté par Yusei (Mastodon) . Évalué à 10.
Autant on peut se méfier d'un Outlook.NET (avec VBA.NET inside, ILOVEYOU.NET powered ;), autant un nouveau langage, tant mieux.
[^] # Re: Juger sur les actes, pas sur les paroles
Posté par kalahann . Évalué à 10.
regarde java: il a pas mal changé dupuis son lancement. Qui va décider des changements? Microsoft va-t-il "donner" le langage à un organisme qui le standardisera, en perdant le contrôle dessus?
Et les API... Seront-elles libres, ou est-ce qu'on devra se les retaper entièrement?
[^] # Re: Juger sur les actes, pas sur les paroles
Posté par Yusei (Mastodon) . Évalué à -1.
C'est ce que je voulais dire en disant que MS pouvait faire "n'importe quoi", et que c'était sans importance. Si on a à un moment un compilateur C# fonctionnel, et que c'est un bon langage, qu'est-ce que ça peut faire que MS fasse un MS-C# pas tout à fait compatible ?
Au pire on aura toujours la version fonctionnelle de départ, et ça sera ça de gagné.
[^] # Re: Juger sur les actes, pas sur les paroles
Posté par PAtrice Manac'h . Évalué à 5.
Bien entendu, Microsoft fait parti du commité de pilotage du langage et pourra donc influencer sur son évolution. Mais dans le cadre de l'ECMA...
[^] # Re: Juger sur les actes, pas sur les paroles
Posté par jeanmarc . Évalué à 5.
On sait maintenant que microsoft a pris conscience du facteur "open source" chez les développeurs qui est un danger pour leurs produits. Ils font des incursions dans ce sens mais contraints et forcés.
Donc, c# est bien soumis à l'ECMA mais il ne faut pas croire que ça soit par pure philantropie. Connaissant leur force de persuasion et leurs ressources, on peut être sûr qu'ils gardent le contrôle sur leur langage.
[^] # Re: Juger sur les actes, pas sur les paroles
Posté par Paerro Trime . Évalué à 7.
C'est la plateforme qui a beaucoup évolué.
[^] # Re: Juger sur les actes, pas sur les paroles
Posté par reno . Évalué à 10.
Euh honnetement moi ça m'a donné l'impression d'un clone de Java avec un petit peu de "sucre syntaxique" par dessus et rien de changé pour l'essentiel..
De toute manière le language Java n'a rien d'extraordinaire.
C'est l'ensemble des librairies et la portabilité qui fait l'interet de Java.
Quand au .Net, personellement ça m'a l'air d'un concept marketing aussi fumeux que le Push.
[^] # Re: Juger sur les actes, pas sur les paroles
Posté par kalahann . Évalué à 8.
Mais il y a aussi des conneries: par exemple, le mécanisme d'exceptions de java qui est excellent, qui devient complètement permissif sous C#
Mais c# est LOIN d'être révolutionnaire!
[^] # C# plus mieux bien que les autres...
Posté par Frédéric Desmoulins (site web personnel) . Évalué à 10.
Je ne vois vraiment pas ce que C# apporte de plus que Java ? J'aimerai qu'on m'explique. Java a desormais une API trés trés large, forte de son expérience. Franchement, en analysant du code C# on retrouve à quelques choses pret exactement la meme syntaxe qu'en Java et la même API de base. Certains avanceront sans doute que C# est plus rapide car il a l'avantage d'être compilé en natif. Alors de 2 choses l'une, si vraiment la performance est un besoin critique, du code Java peut aussi etre compilé pour donner un binaire (cf. Manta, JET...), l'autre, dans la plupart des cas, le couple bytecode/VM est la solution la plus élégante pour plusieurs raisons, notamment pour faire évoluer son soft sur plusieurs architectures sans se prendre la tête.
Non, non vraiment je ne vois pas ce que C# à de mieux. Si un expert C# pouvait m'éclairer ?
[^] # Re: C# plus mieux bien que les autres...
Posté par PAtrice Manac'h . Évalué à 10.
[^] # C# plus mieux bien que les autres...
Posté par kalahann . Évalué à 8.
[^] # Re: C# plus mieux bien que les autres...
Posté par babar33 . Évalué à -2.
[^] # Re: C# plus mieux bien que les autres...
Posté par Thomas Cataldo (site web personnel) . Évalué à 10.
- JBoss est un serveur d'applis J2EE libre et la version 3.0 (beta) apporte le clustering.
- SAPDB est une base de données libre dont le niveau est proche de celui d'oracle (il manque le clustering). Cette base est 100% compatible avec oracle 7 pour la syntaxe de requettes)
Ce qui bloque souvent la pénétration du logiciel libre dans l'informatique d'entreprise, c'est l'attitude du décideur pressé, qui pour éviter de ce vautrer et que ca lui retombe dessus, choisis sans réfléchir les produits les plus chers. Choisir un cluster de serveurs sun avec weblogic et oracle parallel server dessus, ca évite de réfléchir. Et au moins, si ca merde, on peut pas te demander de corriger le code, ou te reprocher d'avoir choisi une solution inconnue.
[^] # Re: C# plus mieux bien que les autres...
Posté par PAtrice Manac'h . Évalué à -2.
[^] # Re: Juger sur les actes, pas sur les paroles
Posté par Jar Jar Binks (site web personnel) . Évalué à 10.
[^] # Re: Juger sur les actes, pas sur les paroles
Posté par Jean-Yves B. . Évalué à 10.
[^] # Re: Juger sur les actes, pas sur les paroles
Posté par Eric Leblond (site web personnel) . Évalué à 10.
[^] # Re: Juger sur les actes, pas sur les paroles
Posté par kadreg . Évalué à 8.
C'est un journal anglais qui annonce le décès de la reine mère tous les deux mois.
# RMS Power
Posté par Christophe Merlet (site web personnel) . Évalué à 7.
On se rattrapera l'année prochaine !
[^] # Re: RMS Power
Posté par Frédéric VANNIERE (site web personnel) . Évalué à -1.
Il faut garder un juste milieu.
[^] # Re: RMS Power
Posté par Yusei (Mastodon) . Évalué à 7.
Et le juste milieu c'est 50% de propriétaire et 50% de libre ?
[^] # Re: RMS Power
Posté par reno . Évalué à 7.
- quand il a demandé au développeur de KDE de s'excuser
- quand le programmeur Russe arrété suite à la plainte d'Adobe a été libéré, il a regretté qu'il ne soit pas battu contre la DMCA.
Je ne me souviens plus exactement mais son commentaire n'était vraiment pas malin..
Enfin bref, nul n'est parfait..
[^] # kde/QT vs stallman
Posté par - - . Évalué à 2.
monter en epingle par QT
(d ailleurs a la linux expo, un employé de QT nous a a fait l historique de la "guerre" stallman...
le fameux "beg for forgiveness"
ben vi, stallman est un jusqu'au boutiste du "libre" , bon , mais c'est vieux tout ca
en ce qui concerne Dimitri, Stallman a regretté qu il ne cherche pas à se defendre pour essayer de contrer la loi DMCA
mais bon, RMS a fait sa part pour faire connaitre le cas de Dimitri
et RMS fait suffisament de lobbying anti brevet (il a d ailleurs clairement expliqué cela encore a la liunx expo) pour qu'on puisse ignorer les "details" et s'attacher au résultat
s'agit pas de glorifier quelqu un
pourquoi toujours ces histoires de glorification ?
quand on dit "merci à linus " c pas qu on glorifie linus ,mais on apprecie son kernel
si on dit "merci miguel de Icaza" pour gnumeric ou evolution,,c pas non plus le glorifier
et meme si on dit "on est d accord avec RMS" c pas qu on glorifie RMS
il faut relativiser
cela dit, que Stallman demande a QT de "s excuser" ,mais quelle importance ?
faut il decortiquer toute parole qui n'ont aucune influence pour la communauté ??
que stallman critique le developpement de la GLIBC vis a vis de hurd et linux CA oui c'etait important, polemique, sujet a troll etc, tout ce que vous voulez , parce que ca concerne les _projets_ qui nous ont tous federés ici
les paroles de MDI sont ici importantes ( a savoir si c est les siennes) parce que concerne un projet pour linux.
et non une simple boutade comme Linus torvald peut en dire des centaines par mois
# C'est une provoque comme MDI sait si bien le faire !
Posté par Samuel Pajilewski . Évalué à 2.
Je pense que dans le future proche on aura affaire a 2 grosse philosophies/techniques qui regiront le monde Informatique :
- Microsoft, son .NET, ses allies : Les PME/PMI, les boutonneux, les pseudos informaticiens/admins, la quasi totalité des etudiants, les constructeurs de PC...
- Sun, IBM et J2EE avec leurs allies de circonstances : AOL, Sony, Real Network, les grosses compagnies qui en ont ras le bol de payer une license par poste, une petite communauté d'etudiant pro Linux, les vrais informaticiens, les adversaires dechus de Microsoft.
MDI a choisi son camp : c'est un droit.
Je suis surpris par le nombre de personnes qui aiment Microsoft et leurs produits : Beaucoup d'etudiants parlent de la Xbox, de IE 6, de Microsoft et Office XP, de .NET...
Les etudiants en informatique ne jurent que par ça (excepté 3 ou 4 gars pas comme les autres).
C'est un peu comme en politique ou en guerre : un homme retourne vite fait sa veste pour tenir avec le plus fort du moment. Helas pour lui, le plus fort sur le papier c'est pas toujours le plus fort qui gagne...
[^] # Re: C'est une provoque comme MDI sait si bien le faire !
Posté par Yusei (Mastodon) . Évalué à 2.
Sauf qu'on n'a toujours pas de solution libre pour utiliser Java. Je ne sais pas où en est GNU classpath mais c'est pas gagné. Alors les pro-logiciels-libres tu les met où ?
AMHA pendant encore longtemps on aura plutot trois camps, et les "vrais informaticiens" (bouuh le troll) resteront en dehors de tout ça.
[^] # Re: Parlons en des etudiants en informatique !
Posté par Thibauld Favre (site web personnel) . Évalué à 10.
Je suis persuad'e que certains ont fait IF (informatique) parce qu'ils etaient super forts a Counter Strike et que les autres ont fait IF parce que faut quand meme avouer que c'est cool de pouvoir recuperer des divX avec Morpheus ! Les passion'es, qui sont vraiment interess'es par l'informatique, il n'y en a pas tant que ca ! Resultat : ils se plaignent tous les jours que Word est une grosse Daube mais ils se precipitent tous (et s'en vantent !) pour installer Office XP et meme WinXP (avec les licences originales biensur) !
Anecdote : mercredi apres midi : conference "reseau". Le directeur technique du reseau metropolitain universitaire de Lyon (Gilles Rech) vient faire une conference. Forts remous dans la salle lorsque au detour d'une question celui-ci a dit qu'une fois le nouveau firewall en place, le reseau fasttrack serait inaccessible ! Reaction a ma gauche : "Hein ?? Mais pourquoi y veut couper Morpheus ? C'est pourtant bien !". Le conferencier explique alors, comme il l'aurait fait a une classe de seconde, que Morpheus et consors, ca propage les virus et qu'il faut mettre un ordi sur son ordi et DL les nouvelles signatures tous les jours.. On croit rever mais le pire c'est qu'il faut leur expliquer !!
Plus tard, comme anecdote, il dit que lorsqu'il a recu son diplome (INSA) le directeur lui a demand'e s'il pensait que MS-DOS ou Unix avait un avenir... Je pensais que tout le monde avait compris ! Reaction a ma gauche (toujours le meme) : "Ah ? Ca a eu de l'avenir MS-DOS ?" Je lui ai immediatement propos'e de lui preter un bouquin pour qu'il acquiert un minimum de culture info ! Il a accept'e (ouf)...
Tout ca pour dire que c'est pas des etudiants en info qu'il faut attendre du soutien ! La plupart programment ou savent faire de la gestion de projet/qualit'e, mais la grande majorite n'a pas idees des outils qu'ils utilisent ! Leur seule preoccupation est d'aller jouer en sortant des cours et/ou d'aller recuperer le dernier film sur le reseau. Alors inutile de dire que pour ceux la, quand on leur dit "Linux", ils s'enfuient en courant ! Ils ne sont libres qu'au travers de microsoft !
Une note positive neanmoins, etant au club Linux de l'INSA, on s'apercoit clairement que le nombre d'eleves qui arrivent a l'INSA et qui s'interessent a Linux est en constante augmentation d'annee en annee. Mais cela sera-t-il suffisant pour sauver tous les autres moutons ignorants ?
[^] # J'arrive...
Posté par aThom . Évalué à -8.
[^] # Re: Parlons en des etudiants en informatique !
Posté par kalahann . Évalué à 3.
[^] # Tu as toutafait raison !
Posté par Samuel Pajilewski . Évalué à 10.
[^] # Re: Tu as toutafait raison !
Posté par Pierre Tramo (site web personnel) . Évalué à 10.
[^] # Re: Tu as toutafait raison !
Posté par Sylvain Rampacek (site web personnel) . Évalué à 10.
[^] # Re: Tu as toutafait raison !
Posté par Jylam / jylam.lnxsce (site web personnel) . Évalué à 1.
(j'ai pu m'en rendre compte pendant mois ou j'ai preparé un port win->nuxe, ou il a bien fallut convertir de l'asm en C).
[^] # Re: Tu as toutafait raison !
Posté par reno . Évalué à 10.
[^] # Re: Tu as toutafait raison !
Posté par Pierre Tramo (site web personnel) . Évalué à 7.
[^] # Re: Tu as toutafait raison !
Posté par Jean-Yves B. . Évalué à 10.
[^] # GVIM en mode easy: -y
Posté par B. franck . Évalué à 2.
il est excellent pour les "diff(s)"
pour le multi-fenêtrage vertical/horizontal
et son mode easy (option: -y) est spécial
pour les notepadiens ou plutôt "notepadaic",
lobotomisés au ctrl-x/v
[^] # Re: Parlons en des etudiants en informatique !
Posté par arf . Évalué à 10.
[^] # Re: Parlons en des etudiants en informatique !
Posté par Littleboy . Évalué à 8.
[^] # Re: Parlons en des etudiants en informatique !
Posté par Nicolas Peninguy (site web personnel) . Évalué à 9.
[^] # Re: Parlons en des etudiants en informatique !
Posté par Jean-Yves B. . Évalué à 3.
[^] # Re: Parlons en des etudiants en informatique !
Posté par Nicolas Peninguy (site web personnel) . Évalué à 3.
[^] # Re: Parlons en des etudiants en informatique !
Posté par Jean-Yves B. . Évalué à 2.
[^] # Re: Parlons en des etudiants en informatique !
Posté par indy . Évalué à 2.
Les écoles vont elles rester crédibles en abandonnant les environnements Unix ?
[^] # Re: Parlons en des etudiants en informatique !
Posté par Littleboy . Évalué à -2.
J'ai pas du bien comprendre ce que m'a dit mon informateur alors.
[^] # Polytech'Nantes
Posté par Erwan . Évalué à 2.
Tout est en multiboot NT/Linux, oui, mais les 3/4 des etudiants se mettent sous NT pour faire telnet sur le serveur Linux (Tequila, a une epoque... Je crois qu'il n'existe plus) quand on avait besoin d'Unix.
La difference avec la fac de sciences c'est que la-bas biens qu'ils soient tout aussi windowsiens qu'a l'Ireste ils vont sous Linux pour ne pas se faire lyncher par les admins ou leurs collegues.
Conclusion, a Polytech c'est la liberte, a la fac la "dictature du libre". C'est vrai, beaucoup d'etudiants font des choix que je juge errones, mais bon...
[^] # Re: Parlons en des etudiants en informatique !
Posté par Loic Jaquemet . Évalué à 6.
[^] # Re: Parlons en des etudiants en informatique !
Posté par Rin Jin (site web personnel) . Évalué à 5.
Je n'ai pas tant l'impression que ce soit les profs ou les micros présent à l'école qui vont changer quoi que ce soit mais plutôt la mentalité des éléves.
J'ai fait un DUT électronique (GEII). Dans mon IUT, il y avait toute une salle pour des stations HP sur lesquelles il y avait, entre autre soft, un routeur pour circuits imprimé, un peu lourd d'un premier abord mais trés puissant dès qu'on le maitrise un peu. Pas besoin de connaitre Unix pour l'utiliser, juste la souris. Que s'est-il passé? Certains éléves ont installé un programme similaires sous windows...
Mes profs était pourtant loin d'être pro MS, c'est grâce à eux que moi et quelque autres avons connu Linux.
[^] # Re: Parlons en des etudiants en informatique !
Posté par richard bonichon . Évalué à 3.
100% Solaris (pour les informaticiens) , 100 % NT pour les autres sections :-)
L'accès internet (géré par les élèves!!!!) est administré avec Linux...
Mais bon on a aussi nos fans de MS dans l'amphi....
[^] # Re: Parlons en des etudiants en informatique !
Posté par ceituna (site web personnel) . Évalué à 1.
C'est pas que je veux dire du mal de l'ENSEEIHT, mais le collègue m'a avoué jamais avoir fait du Linux, et très rarement du Solaris... Alors ma cops, qui fait l'ENSEEITH, elle a jamais touché un Unix quelconque... :~(
[^] # Tiens, il y a eut des changement depuis mon époque :)
Posté par kadreg . Évalué à 6.
Par contre l'admin de l'époque n'avait jamais entendu parler de linusque. Je me souviens d'une présentation en amphi sur l'installation de linux, ou l'admin sys était venu, et n'en revenait pas de découvir un OS libre (mais à qui je doit payer les licenses ?). Je suis pas mécontent de voir dans quel sens ça a évolué.
[^] # Re: Parlons en des etudiants en informatique !
Posté par Thibauld Favre (site web personnel) . Évalué à 4.
En effet, je fustigeais les _eleves_ (du moins la plupart) du depart info de l'INSA. Mais le depart en lui-meme est assez ouvert d'esprit.
Comme je l'avais deja dit au detour d'une autre news, en 3IF les TPs C++ se font sous kdevelop, je suis pas sur que beaucoup d'autres ecoles le font !
On a jamais appris Visual Basic (encore heureux) et comme seul outil Visual, on apprend Visual C++. Sinon, tous les cours mettent l'accent sur les normes et les standards (exemple: POSIX, tres tres succinte description de DCOM au profit de CORBA, RMI et SOAP...). Non dans l'ensemble je pense que le corps enseignant fait un effort, meme s'il reste un long chemin a parcourir...
[^] # Re: Parlons en des etudiants en informatique !
Posté par togno . Évalué à 6.
mes 2 cents
[^] # Re: Parlons en des etudiants en informatique !
Posté par ceituna (site web personnel) . Évalué à 1.
Je te dis ça alors que je suis parti de Bx car je ne voulais pas faire ce qui s'appelait alors L'ENSERB, mais je tiens à rappeler que c'est la seule école en france à dvt du linux à ce point...
Qui est-ce qui organise le LSM ?
Qui est le principal promoteur de l'ABUL ???
Quand je me souviens qu'à l'époque (1995 je crois), mon frère me présentait ses développements sous Linux, et moi comme un con je lui ai dit : "Bof, ton truc, c'est rigolo, mais ca ne sortira jamais des facs..."... Maintenant, c'est moi qui lui explique le fonctionnement de Linux et qui essaye de le convaincre...
Je vais me lancer dans la mode... ;=)
[^] # tout n'est pas si noir
Posté par - - . Évalué à 1.
on a une forte part d'unix (dont _beaucoup_ de linux)
les machines etudiantes sont sous linux/windows NT
(avec du gnome et pas mal de softs dispos de base)
et pas mal de TP info se font _sous_ linux
(un exemple, j ai fait faire des TP sous php/mysql )
y a bien sur du windows
y a bien sur des salles libres services sous windows avec foule de gens qui se croient malin qui tentent (pitoyablement) d installer, kazaa, morpheus etc.. pour s'ecraser mollement sur notre firewall mais bon... ainsi vont les choses
j'ai aussi découvert recemment une autre race de ptit malin, ceux qui tentent d installer en catimini dans leur compte unix des plugins pour linux (flash) ou des softs de telecharments en version linux.
comme quoi.
[^] # fac de nantes & ireste
Posté par Erwan . Évalué à -2.
ayant fait l'ireste et ayant donne quelques cours en deug j'y connais quelque chose...
La plupart des profs n'en a rien a foutre de l'OS, ils font de la recherche c'est tout.
(-1 car un peu prive...)
[^] # Re: Parlons en des etudiants en informatique !
Posté par tanguy_k (site web personnel) . Évalué à 4.
[^] # Re: Parlons en des etudiants en informatique !
Posté par babar33 . Évalué à 5.
[^] # Re: Parlons en des etudiants en informatique !
Posté par arf . Évalué à 3.
"La fac c bien pour la théorie, les concepts dérrieres... Les ecoles d'ingenieurs c pas mal pour aller bosser dans l'industrie, et encore ca depend desquelles..."
Pour avoir eu l experience des 2 approches
(IUT info à nantes orientes SSII) et la
fac info de Nantes (+theorie) je peut t assurer
que les concepts c est pas mal de les avoir.
Si j avais arreter apres mon IUT, j aurai peut
etre pu bosser en SSII mais sans savoir ce que
je faisais... Quand tu as la theorie tu peut
te former (enfin normalement) sur n importe quoi
apres. L ideal c est qd meme d avoir fait les
deux. Voila c est tout !
[^] # Re: Parlons en des etudiants en informatique !
Posté par Eric Leblond (site web personnel) . Évalué à 5.
[^] # Re: Parlons en des etudiants en informatique !
Posté par Benjamin François (site web personnel) . Évalué à 10.
En licence/maîtrise, nous avions 3 salles de TP : une première sous NT, une autre de Terminaux X reliés à un serveur Linux, un Digital Unix, et un AIX, et une dernière salle de VT100 reliés au même serveur.
Lors des pauses du midi, les salles NT étaient bondées, la salle VT100 vide (fallait pas rêver non plus) et la salle TX occupée par 1-2 personnes. Qualle différence entre se logger sous NT pour lancer Netscape ou bien se logger sur le kdm pour lancer le même soft ? Aucune. Alors pourquoi restent-ils sous NT ? C'est le mystère. J'en ai même vu qui préféraient ne rien faire plutôt que se logger sur les TX, alors qu'ils utilisaient régulièrement ces TX en TP (on ne peut donc pas dire qu'ils ne savaient pas s'en servir !)
Et on ne peut même pas accuser l'admin : certes, tout n'était pas parfait (je dois avouer que le serveur Linux avait quelques soucis, notemment le sendmail), mais au moins on était pas bridés : choix du desktop et/ou WindowManager, large panel de softs installés (même des jeux, c'est dire, ça sentait la full install de Mandrake ^^; ) bref l'utilisation était relativement agréable.
Le plus gros problème AMHA vient de la trop grande théoricité des enseignements, quelle que soit la fac ou l'école, mis à part des cas isolés. Même les TPs sont trop "spécifiques". Moi, j'aimerais des TPs où on m'apprend à changer une carte mère. Où on m'apprend à installer OpenBSD. Je n'ai jamais vu ça nulle part, si quelqu'un en a eu vent dans l'enseignement supérieur, ça m'intéresse.
Au final certaines personnes se sont retrouvées avec une Maîtrise en poche sans avoir jamais utilisé Linux en dehors qu'en TP. D'ailleurs je ne suis pas persuadé que ces personnes sachent installer ne serait-ce qu'un Windows.
Je suis actuellement en école d'ingénieurs, et je retrouve quasiment le même comportement, certes à un degré inférieur, et pourtant :
les serveurs accessibles sont un Linux Red Hat doté uniquement d'un KDE ultra instable (j'ai freezé une station en changeant le fond d'écran... ) ou un Solaris avec un fvwm antédiluvien (je parle du numéro de version, hein) ultra-pénible d'utilisation. Bilan : les personnes qui ne connaissaient pas Unix en arrivant n'ont strictement aucune envie de s'y plonger. Les rares sous Linux ont généralement des Mandrake "parce que c'est facile", ce que je trouve, pour des futurs ingénieurs en informatique, un peu lèger (attention messieurs les drakeux, je ne critique pas la distro mais la démarche). Certains ne savent même pas encore ce qu'est une adresse IP ou un serveur FTP, mais auront prochaînement un beau diplôme tout neuf avec leur nom dessus.
Alors ouais, ce ne sera pas simple, mais il y a très certainement des choses à changer. Je ne prétends pas pouvoir récrire les programmes (je ne sais pas qui s'en occupe pour le supérieur, sont-ce des pontes de l'EN ?), je ne désire forcer personne à installer GNU/Linux ou BSD, mais en intéressant les gens, en leur montrant quel plaisir on peut avoir à utiliser ces OS, on arrivera peut-être à les motiver. Il est clair qu'un VI ne persuadera pas un abonné à Visual * : montrez-lui Ajunta, ou KDevelop. Un intégriste de IE vous tanne que c'est le meilleur browser, montrez-lui Galeon. Il vous déclare vouloir regarder ses DivX récupèrés avec eDonkey, montrez lui eDonkey et mplayer ... la liste est longue, et vous verrez : parfois il suffit que ça soit eye-candy pour en motiver certains. Par la suite, ils seront bien amenés à creuser sous cette couche "jolie" pour en tirer la substantifique moëlle.
Eh beh p*tain, j'ai fait un peu long :)
[^] # Pourquoi ? Mais pourquoi ?
Posté par Jean-Yves B. . Évalué à 5.
C'est toujours le cas dans l'école où je suis. Je connais pléthore de collègues qui refusent de se logguer sous Unix à moins que le TP à faire ne soit à faire sous Unix.
Sous NT il y a Netscape 4.whatever et le même sous Solaris®. Les deux se lancent aussi facilement. Il y a le support du Flash© sur les deux systèmes. Du java aussi. Les machines sont derrière le même proxy filtrant.
Pourtant, ils préfèrent rester sous NT. Quand je leur demande (assez régulièrement) pourquoi, la réponse est : « ben parce que ... euh ... voilà, quoi ». C'est un raison valable (la préférence personnelle), mais de là à s'empêcher d'utiliser un truc, c'est très très fort.
Le plus fun c'est que j'avais remarqué le même comportement dans la fac où j'étais avant à partir du moment où NT a été introduit : tous les nioubis plus 80% des anciens sont passés sous NT, sans raison valable si ce n'est : c'est NT. Et de la même façon ils préféraient ne pas se logguer plutôt que se logguer sous Unix (même pour faire un TP). Et ce quand bien même ils l'avaient fait toute l'année précédente sans jamais avoir de problèmes.
Je fais plutôt partie de la tribu des unixiens hardcore de l'école où je suis et pourtant une machine reste une machine, sous NT ou non. Je ne suis pas sectaire au point de remettre mon boulot à plus tard sous prétexte de ne pas avoir de machine Unix dispo. Les fans NT seraient moins ouverts ? (oui, j'éxagère)
Si quelqu'un a la solution de mystère, je suis preneur !
[^] # Re: Pourquoi ? Mais pourquoi ?
Posté par Emmanuel Blindauer (site web personnel) . Évalué à 0.
Y a IE sous NT, et netscape 4 sous linux
A l'utilisation (fontes de merde,
lenteur, plantages)
les etudiants font vite le choix.
Chez nous c'est comme ca on a des 98 et des linux, les gens preferent rebooter sous win pour surfer.
[^] # Re: Pourquoi ? Mais pourquoi ?
Posté par Jean-Yves B. . Évalué à 3.
IE a été désinstallé sous NT, il n'y a que Netscape 4 sous NT, le même que sous Unix (politique admin d'uniformité des logiciels génériques sur toutes les plate-formes).
Les packs de fontes installés sous Unix sont de très bonne qualité.
Remarque non recevable ici.
[^] # Re: Parlons en des etudiants en informatique !
Posté par Eric Leblond (site web personnel) . Évalué à 2.
Ça c'est de l'électronique, dans 90% des entreprises tu n'auras jamais ça à faire, alors pourquoi perdre des heures de cours si nécessaire pour enseigner des choses vraiment utiles à des incultes cf :
> D'ailleurs je ne suis pas persuadé que ces personnes sachent installer ne serait-ce qu'un Windows.
Comme tu le dis toi même, façe au niveau de certains étudiants, il faut assurer un service minimum. L'école donne des pistes à explorer, entrebaille des portes à ouvrir tout grand, elle ne peut pas faire beaucoup plus. C'est dommage, mais si jamais tu te retrouves devant une classe tu comprendras alors qu'il est difficile de faire autrement. Au mieux, on peut aiguiller celui qui avance.
> Alors ouais, ce ne s ..... Par la suite, ils seront bien amenés à creuser sous cette couche "jolie" pour en tirer la substantifique moëlle.
Parfaitement d'accord avec toi sur ce point.
[^] # Re: Parlons en des etudiants en informatique !
Posté par Aza . Évalué à 1.
>mystère.
Dans le même genre durant mes études je m'occupais de la salle internet en libre accès. Les serveurs etaient (ils doivent l'etre toujours) sous FreeBSD mais les clients etaient sous Windows pour diverses raisons (dont nottament le fait que certains cours sur dreamweaver etait fait dans cette salle).
J'ai bien essayé de mettre quelques clients linux sur des postes en douce. Et bien il n'y avait quasiment que trois personnes (dont moi et un autre admin) qui utilisait la machine. J'ai même fait le test de mettre netscape en plein écran, on voyait même pas que c'etait un linux de loin, le gars avait juste a taper son URL comme avec IE, et bien non personne ne les utilisait. Ca devait sentir de loin, je comprends pas.
N'empeche qu'est-ce que j'ai regretté de pas avoir eu l'autorisation de tout migrer sous linux. Sans ces maudits cours de dreamweaver dans la salle....
[^] # Re: Parlons en des etudiants en informatique !
Posté par phq . Évalué à 8.
[^] # Re: Parlons en des etudiants en informatique !
Posté par Philippe F (site web personnel) . Évalué à 4.
[^] # Re: Parlons en des etudiants en informatique !
Posté par Jar Jar Binks (site web personnel) . Évalué à 4.
[^] # Re: Parlons en des etudiants en informatique !
Posté par Sylvain Rampacek (site web personnel) . Évalué à 1.
5 salles de PCs sous NT (pour les DEUG et filières non info).
4 salles de TX sur un serveur sun bi-proc 450Mhz 2GoRAM sous solaris 8.
Pour les filières infos, les TPs se font tous sur les TX, en DEUG, c'est généralement NT et les autres filières, ça dépend.
Les projets sont à faire sous nux ou win/cygwin... (ça dépend).
Mais dès que c'est possible de le faire sous win, les étudiants courent sous win (genre JAVA).
Bon, après, il y a quelques étudiants qui utilisent que *nux...
Du côté des profs, ça dépend... certains ne parlent que de linux mais bien souvent, c'est dualboot !
En conclusion, je vois que c'est pareil un peu partout... ça me rassure.
[^] # Re: Parlons en des etudiants en informatique !
Posté par Thierry GRAUSS . Évalué à 1.
Les salles NT sont toujours pleines et les salles UNIX vides.
Malheureusement, sur les 3 années, on n'est que 3 élèves pro-linux (pour les premières année, je ne sais pas) et on n'a que le prof d'Unix qui soit à font pro-Unix (et même anti-microsoft :). Beaucoup d'élèves ont installés linux chez eux mais ne l'utilisent que rarement et font tout sous NT.
En première année on n'avait même pas d'accès en salle Unix (réservé aux deuxièmes et troisièmes années). Tous les TP de C, C++, Génie Logiciel, base de données (access beurk) se font en salle NT. Nous n'avons que les TP d'UNIX et de PROLOG qui se font en UNIX (même le TP Latex se fait en NT).
De même, en première année, pour le projet de langage C, j'avais demandé au prof si je pouvais utiliser GTK comme interface graphique éventuelle et je me suis fais incendier (le programme devais impérativement tourner sur le NT de l'École), heureusement qu'ils avaient Allegro et j'ai pu alors programmer chez moi.
[^] # Re: Parlons en des etudiants en informatique !
Posté par Philippe F (site web personnel) . Évalué à 1.
C'est grace a eux que j'ai decouvert le logiciel libre et je les en remercie. Avec un admin pas trop refractaire et des eleves motives, on peut faire beaucoup de choses.
[^] # Re: Parlons en des etudiants en informatique !
Posté par Yann KLIS (site web personnel) . Évalué à 4.
[^] # Paul ! Une Tourtel ! Attends, ... deux !
Posté par Jean-Yves B. . Évalué à 9.
Juste pour être sûr que l'on parle de la même chose : il y a les étudiants qui vont en cours et ceux qui lisent en plus des bouquins à côtés (et ne viennent pas toujours en cours).
Il y a les étudiants qui recopient la solution du TD au tableau sans réfléchir et ceux qui posent des questions ou répondent (modulo le fait que parfois on est fatigué et que bon, là on recopie).
Il y a les bachoteurs qui aiment le par coeur et ceux qui aiment les applications.
Si tu regardes en arrière ton enseignement secondaire (que tout le monde est sensé avoir suivi en France), on ne t'apprend jamais à penser par toi même. Tu dois démontrer le théorème comme la prof l'a fait texto.
J'éxagère bien sûr, mais dans une grande majorité c'est ça.
Finalement, et en réfléchissant encore un peu, c'est comme ça depuis toujours : au moyen-âge on suivait le prêtre et on brulait la
voisinesorcière. Les esprits critiques n'ont jamais été majorité, car ils sont souvent un danger à court terme pour le groupe (source d'instabilité).<fatalisme>
Bref, c'est comme ça.
</fatalisme>
De là a avoir peur ... Après tout les gens sont libres d'être libres ou non.
<cynisme>
Et puis les lemmings meurent en masse en général, donc à terme sont sensés disparaître du pool génétique :)
</cynisme>
[^] # Re: Paul ! Une Tourtel ! Attends, ... deux !
Posté par PLuG . Évalué à 0.
vive la prepa, où on ne te demande jamais un truc vu en cours lors des partiels... et les concours d'entree en Ecole dans lesquels les questions sont souvent hors programme pour voir ceux qui se demerdent bien !!
effectivement, mais ca met la barre un peu haut pour beaucoup de monde ...
Enfin une derniere chose: il y a ecole d'informatique et ecole ...
je m'explique: le thread a commencé au sujet de L'INSA. A mon epoque (arg !) l'INSA n'etait pas une ecole en informatique, c'etait une Ecole (derivee de la fac plutot) avec une option informatique DE GESTION.
Par contre, les mines avaient une vraie section informatique (reseau/imagerie/IA), l'EERIE aussi.
Ce sont des Ecoles ou les cours parlaient plus d'algo, d'optimisations, de theories et ou les TP et les pojets permettaient de mettre en pratique tout cela avec ses petits doigts. Je ne vois pas l'interet de VB car dans AUCUN projet on a eu une interface utilisateur a faire ... (a si une sous Motif quand meme pour un soft de filtrage numerique).
Bref y'avait que des stations Unix, windows c'etait sur les PC des etudiants, linux etait pas tres avancé... il permettait de bosser chez soit et de recompiler direct sur HP/SUN ce qui etait deja pas mal !!
[^] # Re: Paul ! Une Tourtel ! Attends, ... deux !
Posté par Alphonse Oncle . Évalué à 2.
C'est vrai que maintenant que tu le dis je me rappelle avoir eu pas mal de problemes avec certains profs car je ne faisais pas exactement comme cela avait ete fait en cours. J'essayais de comprendre la chose et donc de raisonner et non d'apprendre betement pas coeur. Et ca c'est pas tjs apprecie... argh
"Après tout les gens sont libres d'être libres ou non."
Encore faut il en avoir conscience.
[^] # Re: Parlons en des etudiants en informatique !
Posté par koopa . Évalué à 1.
En fait ca dépend vraiment des écoles, l'an dernier j'étais encore à l'ENSIMAG (école d'info de Grenoble) et je peux te dire que là bas c'est 100 % Unix (serveurs + TX + logiciels libres/gratuits).
Les 10 PCs Windows sont surtout utilisés pour leurs lecteurs de disquettes 3p5 et leurs lecteurs Zip et non pour leurs logiciels.
Tous les élèves savent se servir un minimum d'Unix, et nombreux sont ceux qui vont jusqu'à installer Linux sur leurs machines personnelles, histoire de pouvoir faire les projets chez eux.
Il me semble quand même que Unix est ce qu'il y a de mieux pour servir de support à une formation d'ingénieur en informatique.
[^] # Re: Parlons en des etudiants en informatique !
Posté par Marc (site web personnel) . Évalué à 0.
[^] # Re: Parlons en des etudiants en informatique !
Posté par Marc (site web personnel) . Évalué à 0.
[^] # Re: C'est une provoque comme MDI sait si bien le faire !
Posté par bleh . Évalué à 3.
- Sun, IBM et J2EE avec leurs allies de circonstances : AOL, Sony, Real Network, les grosses compagnies qui en ont ras le bol de payer une license par poste, une petite communauté d'etudiant pro Linux, les vrais informaticiens, les adversaires dechus de Microsoft.
Le "les vrais informaticiens" me fait sauter au plafond. Sur quoi te bases tu pour dire qu'un informaticien qui utilise MS est, de facto, un mauvais. C'est parfaitement péremptoire et débile. Moi je juge les gens sur leur travail pas sur la couleur de leur voiture ou le style de leur chaussettes. J'utilise GNU/Linux depuis longtemps et j'ai pas l'impression d'être plus fort, plus intelligent que d'autre personnes, qui écrivent des programmes super sous MSWindows.
Le SE ne fait pas tout, pourtant dans mon école, on ne programme que sous openVMS. Plus alternatif tu peux pas. Dois-je en conclure qu'on est tous des "vrais" informaticiens ?
Je trouve ce sentiment de supériorité lié à GNU/Linux extremement agaçant. Encourager les gens à utiliser GNU/Linux ce n'est certainement pas arriver en disant "oula t'utilise MS, t'es vraiment un gros naze, rejoins les élus, passe à Linux". J'imagine le jour où ces gens-là utiliseront OS9 ou QNX.
# un bon plan ??
Posté par EvilTheCat . Évalué à 2.
De toute façon que gnome se dirige vers le .Net ou pas, on aura toujours des alternatives et ça poussera peut-etre plus de gens/societe à investir dans d'autres projets que gnome ...
[^] # Re: un bon plan ??
Posté par sensei . Évalué à 10.
On va pas commencer les amalgames de m***e...
Miguel De Icaza, c'est pas gnome, c'est Ximian !
Traduction : c'est pas gnome qui se dirige vers .NET.
Gnome est et restera libre simplement parce que s'il ne l'est plus, qui l'utilisera encore ?
Les pro-LL -> tout le monde chez KDE,
les pro-.NET -> tout le monde sur sa copie piratée de Windows...
Donc arrêtez de dire des co***ries...
Merci !
Sinon, j'ai gagné (ouais !! trop de chance !!) un bouquin C# où est expliquée la plateforme .NET...
Ben, je trouve qu'il manque parfois sous *nix une telle cohérence entre les différents éléments...
Mais je suis d'accord, c'est aussi un avantage (si, si, vous savez, la diversité...)
[^] # Re: un bon plan ??
Posté par aThom . Évalué à 2.
M'enfin bon ca n'engage que moi.
[^] # cohérence
Posté par Le_Maudit Aime . Évalué à -2.
C'est dans son code qu'on la recherche la cohérence. Quand il s'agit d'assembler des solutions, là cela devient vraiment plus difficile.
[^] # explication ...
Posté par EvilTheCat . Évalué à 0.
[^] # Re: explication ...
Posté par sensei . Évalué à 2.
[^] # Re: explication ...
Posté par Benjamin . Évalué à -1.
[^] # Re: explication ...
Posté par kalahann . Évalué à 2.
[^] # Re: explication ...
Posté par Benjamin . Évalué à 2.
[^] # Re: explication ...
Posté par lorill (site web personnel) . Évalué à 4.
[^] # Re: explication ...
Posté par sensei . Évalué à -1.
[^] # Re: explication ...
Posté par kalahann . Évalué à 2.
[^] # Re: explication ...
Posté par PAtrice Manac'h . Évalué à 2.
[^] # Re: explication ...
Posté par kalahann . Évalué à 1.
[^] # Re: explication ...
Posté par Jean-Yves B. . Évalué à 5.
[^] # Re: explication ...
Posté par Jar Jar Binks (site web personnel) . Évalué à 2.
[^] # Re: explication ...
Posté par Yusei (Mastodon) . Évalué à 3.
[^] # Re: explication ...
Posté par cornofulgur . Évalué à 2.
[^] # Re: explication ...
Posté par babar33 . Évalué à 5.
# API
Posté par imr . Évalué à 5.
[^] # Re: API
Posté par Benjamin . Évalué à -3.
# Tssssss...
Posté par Jar Jar Binks (site web personnel) . Évalué à 10.
# Java et .Net
Posté par Jar Jar Binks (site web personnel) . Évalué à 3.
Non je demande ça parce que plein de gens semblent utiliser ces, mais j'ai de plus en plus l'impression que c'est juste pour faire plaisir aux décideurs pressés. J'ai beau chercher, je ne vois pas de réel intérêt. Niveau vitesse, c'est loin du C et assimilés. Niveau portabilité, c'est carrément pas la joie (l'abstraction apportée par la machine virtuelle est parfaitement illusoire). Niveau rapidité de développement, ça ne vaut pas les langages vraiment haut niveau comme python. Niveau maintenabilité, modularité... ça dépend énormément du programmeur et de toute façon ces méthodes n'apportent rien de plus.
Bref, quand on veut faire des logiciels qui marchent, ça sert à quoi ?
[^] # Re: Java et .Net
Posté par Yusei (Mastodon) . Évalué à 7.
Il y a aussi pas mal de trucs qui sont plus compliqués à mettre en oeuvre avec d'autres langages, comme le RMI (vous moquez pas: Remote Method Invocation) qui, comme son nom l'indique, permet d'appeler des méthodes d'un objet distant.
Personnellement, même si je n'aime pas Java, je lui trouve pas mal de raisons d'êtres, et j'aimerais bien en voir une implémentation (complète) libre.
Yusei (ruby rulez)
[^] # Re: Java et .Net
Posté par Nelis (site web personnel) . Évalué à 1.
Java est un BON langage, qui fonctionne TRES bien, qui a une excellente API et dont la portabilité fonctionne de manière plus que satifsaisante ...
Alors, SVP arretons un peu les trolls à deux balles sur Java ...
[^] # Re: Java et .Net
Posté par Jar Jar Binks (site web personnel) . Évalué à 1.
[^] # Re: Java et .Net
Posté par Nelis (site web personnel) . Évalué à 1.
A propos d'arguments, je peux avoir les tiens pour dire que c'est "un machin qui ne sert à rien" ? As-tu déjà programmé *sérieusement* en Java ? Ou au moins regardé les spécifications de près ? Qu'est-ce qui fait que Java est un machin et que C/C++/Perl/Python/Ada/Eifel/... n'en sont pas ?
Enfin, si sérieusement tu as envie de t'intéresser à Java, je serais heureux de t'aider !
# Reaction mitigee
Posté par Philippe F (site web personnel) . Évalué à 10.
Il a reussi a imposer une interface graphique en partant d'une grosse merde (windows 3), alors qu'il existait des concurrents bien meilleur.
Il a reussi a rentrer dans le lard du marche unix avec Windows NT, pourtant une grosse merde aussi a la base (ca a peut-etre change).
Il a loupe le premier virage internet mais le rattrappe avec IE et IIS.
Il va probablement rentrer dans le lard a Apple avec XP. Il en profite pour degager RealPlayer et Java qui commencaient a lui casser les couilles.
Alors on critique Microsoft pour plein de raisons, mais il ne faut jamais oublier que Microsoft est tres fort. Pas seulement par sa machine marketing et commerciale. Ils savent tres tres bien reagir et corriger leurs erreurs. En general, ils font ca bien avant que ca ne leur soit fatal.
Par exemple, sur les virus les macros, on commence a atteindre un seuil critique. A mon avis, bientot ils feront des vrais produits securises parce que sinon, ils risquent de perdre des clients. Ca ne sera pas parfait mais suffisamment mieux pour justifier de rester a Windows.
D'un point de vue Dev, que peut-on reprocher a la plateforme Microsoft ? En gros pour faire une appli, soit on utilise VB mais ca devient quand meme vite limite, soit on utilise VC++ et les MFC. Mais voila, les MFC datent des annees 80, et c'est un gros tas de boue par dessus des appels systemes en C, melanges avec du pseudo objet et une communication par boucle d'evenement. On peut dire qu'ils ont 5 a 10 ans de retard en terme d'interface graphique.
Si on veut faire du dev en autre chose qu'en C++ sous Windows, on va faire du Delphi ou du Java. On sent bien que Microsoft ne controle pas cette zone.
Donc Microsoft lance .NET . Ils vont repondre aux problemes suivants, tous d'un coup:
- on pourra faire facilement des interfaces graphiques dans un langage avance. Exit les MFC, qui auraient deja du partir depuis longtemp. Ils recuperent les developpeurs en Swing et en Delphi.
- tout comme Java, c'est sense etre portable a mort. Ils touchent directement les gens qui ont toujours ete sensibles au "Write once, run Anywhere" qui malheureusement pour Sun, est un echec.
- ils supportent tous les langages en meme temps. C'est un coup tres fort. Jusqu'a present, pour ne pas faire de microsoft, il suffisait de vouloir faire du perl, du python, du java, du delphi, de l'eiffel. Maintenant, ce n'est plus le cas. C'est a mon avis leur coup le plus fort. Ils font les partenariats qu'il faut et vont les faire marcher jusqu'a pouvoir dire qu'ils supportent tous les langages.
- ils vont plus loin que Java puisqu'ils unifient les plate-formes et les langages. Le nombre de raisons de ne plus faire du microsoft va beaucoup diminuer.
En plus de repondre a des problemes qu'on a sous Windows, microsoft attaque unix aussi directement. Quel est le plus gros probleme de Unix ? La fragmentation:
- aucune appli n'a de methode standard pour parler a une autre. Heureusement, on commence a voir des choses avec Bonobo, DCOP ou SOAP, mais ca reste encore tres fragmente et incompatible.
- aucune appli n'a de methode standard pour reutiliser des composants d'une autre appli. La aussi Gnome et KDE commencent a nous apporter des solutions, mais c'est tardif.
- la diversite des langages se fait a un cout tres eleve. Pour gtk, les binding se font a la main et ont donc beaucoup de retard. Pour Qt, c'est tres complique de faire des bindings (merci le C++).
A cause de tout ca, il y a des milliers d'appli inachevees et concurrentes qui ont du mal a beneficier de l'existant. On est presque toujours obliger de reprendre a la base parce qu'a chaque fois qu'il existe qqch qui pourrait servir au dev d'une autre appli, ce n'est pas comme il faut.
La facon la plus portable de faire un composant reutilisable est aujourd'hui de faire une bilbiotheque. Mais ca veut dire que vous ne pouvez faire de composant qu'en C ou C++. Cela veut dire que les nouveaux langages (perl python, ruby, ...) ne pourront pas en beneficier tout de suite, il faudra wrapper la bibliotheque. En plus, ca ne marche que dans un sens. Une bonne bibliotheque ecrite en perl est inutilisable en python/C/Ada/C++/Ruby/... Il faudra la redevelopper dans pratiquement chacun de ces langages.
Aucun de ces problmes ne se pose avec .NET. Toutes les applis sont capables de communiquer entre elles et de reutiliser en tant que composant, ce quel que soit le langage dans lequel elles ont ete ecrite.
Moi je vois dans .NET une excellente manoeuvre de la part de Microsoft. D'ici 10 ans, Java sera marginalise et Microsoft aura pris une plus grande part encore de developpeurs que ce qu'ils ont actuellement. Ils auront recupere des gens de perl, de python, de ruby, de Eiffel, de Java... Les autres coderont en C# pour Windows mais seront persuade de faire un truc portable.
La question: Microsoft sera-t-il honnete jusqu'au bout avec les specifications de .Net ? A mon avis, non. Un jour, ils vont "craquer" et introduire les petites "ameliorations" Windows et Microsoft. Mais ils le feront tres tard, quand la plateforme aura deja ete adoptee. Et ca ne diminuera qu'un peu l'interet de .NET . Un programme perl.NET pourra toujours communiquer avec un programme python.NET .
Donc il faut bien comprendre que .NET apporte beaucoup de solutions. En plus, cela arrive apres Java, donc ils peuvent tirer des lecons des erreurs et des succes des autres.
Quand on lit la page de MDI, on ressent qu'il "souffre" des problemes d'UNIX que j'ai cite plus haut (en gros, le manque de communication inter-appli). .NET apporte une solution, je comprends qu'il s'y interresse. MDI a lance Gnome pour repondre a ces problemes. Je comprends qu'il soit emballe par .NET et ce n'est pas forcement la chose la plus stupide a faire que de baser Gnome dessus.
En tout cas, vu l'importance que .NET va prendre par la suite, mieux vaut que Unix ne soit pas encore plus marginalise en ayant pas de .NET du tout. Sinon, ca va etre tres dur d'en vendre a des entreprise. Y a qu'a voir comment ca nous coute de ne pas avoir Word et Excel, on a pas besoin de ca en plus.
[^] # Re: Reaction mitigee
Posté par Toufou (site web personnel) . Évalué à 2.
les sockets et les IPC System V ce n'est pas standard ? Il suffit de spécifier le protocole de communication. Je ne vois pas la différence avec la spécif d'un composant.
- aucune appli n'a de methode standard pour reutiliser des composants d'une autre appli. La aussi Gnome et KDE commencent a nous apporter des solutions, mais c'est tardif.
La programmation par composants c'est peut-être bien sur des gros dévelopements serveurs (je ne connais pas du tout le domaine, mais même là je doute) mais je n'arrive toujours pas à voir l'intéret au niveau client par rapport à une librairie. Plus tu t'approches du besoin métier / utilisateur, plus tu dois personnaliser ton interface et tes structures: la réutilisation se restreint de plus en plus. Alors avoir des composants style browser html dans ton appli, à part bouffer des ressources (non tout le monde ne change pas un parc de 100 machines tous les ans), ça sert à quoi ?
[^] # Re: Reaction mitigee
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Est-ce que tu vois la différence entre la commande 'cat' et un parser ?
[^] # Re: Reaction mitigee
Posté par Toufou (site web personnel) . Évalué à 1.
N'importe quoi, cat et un parser n'ont pas les mêmes fonctionnalités/usages. Alors que là on parle d'une communication interprocessus selon deux méthodes différentes.
[^] # Re: Reaction mitigee
Posté par Jean-Yves B. . Évalué à 10.
Les IPC SysV c'est un moyen de transmission (mémoire partagée et de quoi gérer la synchro et l'exclusion mutuelle).
Définir un protocole c'est comme écrire un parser, c'est presque toujours une solution ad-hoc. Les IPC SysV ne sont pas un moyen standard de communiquer entre processus, ce sont des supports (nuance) de communication entre processus.
cat est un moyen de transmission, il passe les données du support fichier vers un autre support fichier : c'est juste (j'éxagère) un printf ("%s", mmap (open (fichier))). Il n'interprète rien.
Un parser (plutôt un interpréteur d'ailleurs) c'est un moyen de traduction, les données ont une signification contrairement au passage dans cat.
La comparaison est à peu près valable car tu comparais un vrai protocole de communication (où les messages ont une signification) à un moyen de faire passer les messages (les IPC).
[^] # Re: Reaction mitigee
Posté par Toufou (site web personnel) . Évalué à 5.
Ce qui me gène vraiment en fait c'est que je trouve que l'approche par composants a un mauvais rapport fonctionnalités/ressources comsommées. Et c'est aussi une infâmie à stabiliser manifestement, le modèle étant nettement plus complexe que les méthodes habituelles. Ca me fait un peu penser à l'approche RISC/CISC pour les processeurs ou a l'approche micro noyau vs monolithique: on va avoir des composants bien plus complexes que ce dont on a généralemnt besoin et ce, au au prix d'une perte de performances et d'une maintenance énormes.
Pour résumer ma pensée:
1- je doute fortement qu'on puisse réellement réutiliser la plupart des composants existants car ils seront trop généralistes, peu adaptés aux situations sur le terrain et bien trop gourmands pour ce qu'on veut en faire.
2- ce genre d'approche transforme et déplace la difficulté de conception mais ne la diminue pas: on se prend la tête à adapter l'existant tant bien que mal au lieu de se prendre la tête à concevoir du nouveau: bof.
3- on augmente considérablement le niveau requis pour se servir de ces choses: il faudra connaitre des mécanismes supplémentaires aux existants pour pouvoir se servir correctement de ces outils. Déjà qu'en 2 ans d'IUT ou en 3 ans d'école d'ingé on a juste le temps de comprendre les bases, je me demande ce qui sortira des écoles: des spécialistes .net qui ne comprennent rien aux réseaux ?
4- je continue à penser que ce modèle (comme tout modèle) est adapté à certaines situations mais pas à toutes. Tout faire touner dessus simplifiera certaines choses mais complexifiera d'autres.
Je n'ai jamais participé à un grand projet, donc je ne peux pas voir l'intéret de ces modèles dans ce cas, mais pour le cas du developpement des applications que M. tout le monde a sur son bureau,je ne vois vraiment pas d'autre intéret que ceux cités par le post d'origine => une tentative de prise de pouvoir par MS en déplaçant le problème sur un terrain dont il maîtrisera la norme et les outils. Qu'on récupère des idées et qu'on offre un support pour ne pas s'isoler, pourquoi pas ? Mais se lier étroitement à ces technologies comme le désire MDI me semble un bon moyen d'envoyer direct gnome à la poubelle (déjà qu'il n'est pas super utilisable...) en le complexifiant au delà du besoin et de la capacité de maintenance des developpeurs.
[^] # Re: Reaction mitigee
Posté par Philippe F (site web personnel) . Évalué à 10.
C'est bien la le probleme. Il faut specifier le protocole de communication, et comme toutes les applis sont developpees de facon completement independantes, aucune n'a un protocole de communication commun. Pour celles qui en ont un.
Sous KDE, je sais que si j'utilise DCOP, je pourrais deja communiquer avec toutes les applis KDE. Je n'ai pas besoin de toutes les patcher une par une avec mon protocole de communication que j'ai perdu du temps a developper, je peux reutiliser de l'existant (applis + protocole) et ca me permettra de me concentrer sur mon appli a moi. C'est hyper important.
La difference entre un composant et une bibliotheque, c'est que le composant est bien plus integre dans ton appli. La ou une bibliotheque ne fait que fournir des points d'entrees, le composant va fournir des mecanismes d'integration standard que tu n'aura pas a gerer. Pour illustrer, les composants KDE sont bases sur des bibliotheques partagees (donc il y a bien un rapport). Quand tu demandes le composant, KDE va prendre en charge lui-meme:
- la localisation du composant dans ton systeme
- l'utilisation du composant le plus approprie selon tes besoins preferences (il peut y en avoir plusieurs qui sont concurrents - gecko vs kthml, kvim vs kwrite)
- le chargement dynamique de ce composant (evidemment, tu peux mettre tout en statique mais c'est plus lourd)
- l'integration des menus du composants dans le menu de ton appli
- l'integration des racourcis clavier
- la gestion de la configuration
- la gestion de l'affichage.
> Alors avoir des composants style browser html dans ton appli, à part bouffer des ressources
Ca a l'air de te surprendre, mais parfois tu as besoin de composants, et pas pour le plaisir de bouffer des resources. Par exemple, toujours sous KDE, si tu tapes info:// ou man://, tu peux acceder a une page man ou info. Ils auraient pu redevelopper tout l'affichage de ces pages mais ils ont prefere convertir rapidement les pages man/info en html avec des outils existants et utiliser le composant html.
Autre exemple, tu as un client mail, un client news, un environnement de dev, un editeur de page web. Tous ont besoin de developper un editeur de texte. Il est beaucoup plus efficace de developper un ou deux composants "editeur de texte" qui pourront etre utilises par toutes les applis, et ameliores par plusieurs personnes en meme temps, plutot que chacun developpe son editeur de texte. Passons du temps la ou c'est util, pas la ou des tas de gens ont deja passe du temps.
[^] # Re: Reaction mitigee
Posté par Benjamin . Évalué à 0.
[^] # Re: Reaction mitigee
Posté par imr . Évalué à 3.
http://klotski.berlios.de/kvim/(...)
[^] # Re: Reaction mitigee
Posté par Toufou (site web personnel) . Évalué à 3.
- l'intégration:
à part l'intégration visuelle (affichage dans ton appli et intégration des menus du composant) que tu peux difficilement faire avec deux applications séparées, le reste, si ces applications sont bien faites, tu peux le faire avec des mécanismes plus simples sans s'arracher les cheveux.
- réutilisation de l'existant:
ton exemple est une forme de non réutilisation de l'existant: pourquoi transformer les pages de man/info en html au lieu de lancer l'application dédiée sur la bonne page ?
- paramétrage du composant:
Avec ton exemple, tu te retrouves comme avec msdn où on peut se servir de l'aide pour aller surfer sur le net. Bon ce n'est pas bien grave mais si tu veux l'empecher, bon courage. Tu illustres ce que j'ai dit dans un post au dessus: si le composant est trop générique (ou a trop de fonctionnalités), dans la plupart des cas, tu passes autant de temps à bidouiller un bridage, un ajout où une modif qu'à refaire le composant avec des libs de plus bas niveau.
[^] # Re: Reaction mitigee
Posté par Philippe F (site web personnel) . Évalué à 3.
Oui, mais si toutes les applis etaient bien faites, il n'y aurait meme plus besoin d'ecrire du code. Mais oui, tu peux reecrire un systeme de composant a chaque fois que tu reecris une appli. L'interet me parait cependant limite.
> sans s'arracher les cheveux.
En ce qui concerne KPart, c'est un "nobrainer". Utiliser un kpart, ca consiste en gros a rajouter 10 lignes a ton widget principal. Pas d'arrachage de cheveux chez KDE donc, ils ont pense a tout. Chez Gnome c'est un peu plus complique, mais ca reste gerable.
> pourquoi transformer les pages de man/info en html au lieu de lancer
> l'application dédiée sur la bonne page ?
Tu chipote mais voice ma reponse:
- les pages de man sont 10 fois plus jolies avec konqueror
- je n'ai jamais reussi a utilise le programme info, alors que sous konqueror, c'est vraiment facile. C'est encore plus joli sous Gnome (notez l'effort d'ouverture et l'honnetete de ma part sur ce point, c'est pas tous les jours que je note des superiorites du cote de Gnome).
- info2html, c'est pas KDE qui l'a ecrit
- ca permet plus d'integration. On peut penser par exemple a un help center qui va te faire des recherches sur tous les systemes d'aides installes sur ton ordinateur (info, man, KDE help, Gnome help et j'en passe) pour t'afficher facilement le resultat de ces requetes dans une belle page.
> on ce n'est pas bien grave
Comme tu dis. Mieux vaut une bonne aide qui permette d'aller sur le net, que passer du temps a reecrire un composant bugge pour gerer l'aide dans ton appli.
> mais si tu veux l'empecher, bon courage.
Je parie que c'est moins de 10 lignes avec Qt. Qt est vraiment trop bien fait.
T'as pas l'air de realiser mais tout les trucs "qu'on pourrait faire si tout etait bien code et qu'on a que ca a foutre", c'est mieux si d'autres gens les ont codes pour nous.
[^] # Re: Reaction mitigee
Posté par Toufou (site web personnel) . Évalué à 2.
"si toutes les applis etaient bien faites, il n'y aurait meme plus besoin d'écrire du code.". Je pense que c'est aussi le problème de l'approche par composant, si c'était bien fait ce serait plus simple, plus léger et plus stable.
Pour ma part, je n'ai jamais vu un seul environnement basé là dessus (KDE/Gnome/Windows) qui n'ai pas ces défauts:
- en utilisation: lenteur, taille et instabilité. Ce que je constate c'est que GTK+ sans gnome c'est petit, rapide, stable et répond à 99% de mes besoins. Je parie qu'on a la même chose avec QT sans les parties OLE-like de KDE.
- en programmation: c'est décrit en détail dans mes autres posts.
Quand tu me dis mais non c'est chouette, ça marche et on peut en mettre partout c'est un peu comme si je disais le Hurd c'est bien, ça marche et on peut en mettre partout: c'est chouette oui, ça marche, non, on peut en mettre partout oui mais bon, on peut éviter de s'emmerder avec ça dans 50% des cas.
[^] # Re: Reaction mitigee
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Tu "paries", où tu "sais" ?
- en programmation: c'est décrit en détail dans mes autres posts.
Si tes posts pouvaient décrire en détails tes compétences réelles en programmation, ça donnerait un peu plus de poids à tes arguments.
Tout ce qu'on peut voir chez toi pour l'instant, c'est un gros préjugé : "les composants c'est pas bien". Ajouté au fait que tu ne sais clairement pas de quoi il s'agit (cf. ton premier post où tu ne fais pas la distinction avec des sockets).
[^] # Re: Reaction mitigee
Posté par Toufou (site web personnel) . Évalué à 1.
- je parie: parce que je n'utilise pas régulièrement KDE/QT, je ne peux donc pas savoir.
- la distinction avec les sockets: vu les éléments pertinents que tu a donné dans ton post à ce sujet, je n'ai pas compris ce que disais. Si tu as lu les posts qui le suivent, tu aurais dû t'en apercevoir.
- un préjugé: non, je me sers de composants au boulot sous Delphi et VB (je suis développeur). Les problèmes que je décris sont ceux que je rencontre tous les jours. Alors, je ne connais pas en détail le fonctionnement interne des composants que j'utilise, ce que je sais c'est que je ne peux pas les utiliser pour des problèmes de performance et de stabilité. Avec 64Mo, ce dont je dispose au boulot, il ne faut même pas penser à inclure un composant ActiveX style IE/Word/Excel dans une application et pourtant j'aimerais bien pouvoir le faire.
Ce qui me gène dans l'approche 'composants':
- actuellement, je n'ai vu aucune application raisonablement stable (c-a-d, qui crashe moins d'une fois par jour) utilisant ce genre de systeme alors que j'ai des applis GTK (que j'utilise chez moi, c'est pour ça que j'en parle) ne crashent pas pendant plus d'une semaine et en les utilisant tous les jours.
- les connaissance requises pour manipuler ce genre de concept sont nettement au delà de celles qu'il faut pour faire les même choses sans cette approche (ne serait-ce que parce qu'il faut connaitre des mécanismes de communication, des methodes, etc. en plus de ce qu'il fallait savoir avant). Excuse moi de ne pas être un dieu en prog, même si j'aime bien comprendre un minimum de ce que j'utilise dans mes programmes.
- dans 90% des cas, j'ai (enfin, les gens à mon boulot) un mauvais rapport ressources/fonctionnalités/maintenance/stabilité par rapport à de l'objet classique, et dans les petits projets l'approche objet elle même n'est pas forcément rentable. Et des petits projets, je pense qu'on est nombreux à en faire.
- la réutilisation, c'est bien joli sur papier mais c'est extrèmement difficile en vrai. Une facture chez les assureurs ne ressemble pas structurellement et "comportementalement" à une facture chez un garagiste.
- comme je te l'ai déjà dit ça augmente encore plus le risque de problèmes dûs au code caché (comme pour de l'objet, mais avec en plus des mécanismes de communication opaques)
Ce qui me gène dans vos posts (P. Fremy et toi), c'est que j'ai l'impression que vous présentez l'approche composant/réutilisation un peu comme on a présenté l'objet, les bases de données objet ou le micro noyau: c'est LA manière de faire, LA solution miracle. Je dis juste que je ne le pense pas, que je pense que c'est juste une manière de faire et j'explique pourquoi. Je n'ai rien contre l'objet ou le composant, mais je trouve techniquement idiot de le mettre à toutes les sauces à tout prix.
[^] # Re: Reaction mitigee
Posté par Guillaume Laurent (site web personnel) . Évalué à 2.
Ouhlà, je comprends ta douleur. Pour une machine de développement, c'est beaucoup trop petit.
actuellement, je n'ai vu aucune application raisonablement stable...
Konq est entièrement basé sur des composants et ne crashe pas une fois par jour chez moi (je dirais 1 fois par semaine max, très tolérable par rapport à Netscape4 :-).
les connaissance requises pour manipuler ce genre de concept sont nettement au delà de celles qu'il faut pour faire les même choses sans cette approche
Pas d'accord, elles sont moindres je trouve. Si tu veux connaitre toute la mécanique à fond oui, mais rien ne t'y oblige. Je ne crois pas qu'un programmeur puisse actuellement appréhender une appli complète. Est-ce que tu sais exactement ce qui se passe quand tu fais un malloc() ? Quand tu appelles une fonction (l'empilement/dépilement des arguments, etc...) ? Quand tu ouvres un fichier sur le disque ? Moi pas. Il est normal de "déleguer" certaines choses.
et dans les petits projets l'approche objet elle même n'est pas forcément rentable
Si, c'est quasiment toujours rentable. Faire de l'objet ne signifie pas deriver des classes dans tous les sens, justement il y a un thread la dessus dans la news sur C# et Gosling :
http://linuxfr.org/2002/02/05/6980,0,0,0,0.php3(...)
Ce qui me gène dans vos posts (P. Fremy et toi), c'est que j'ai l'impression que vous présentez l'approche composant/réutilisation un peu comme on a présenté l'objet, les bases de données objet ou le micro noyau: c'est LA manière de faire
Non, je ne dis pas (ni Philippe je pense) que les composants sont LA façon de faire. C'est juste un outil de plus, qui, lorsqu'il est utilisé à bon escient, marche très bien et est très puissant. C'est hélas vrai qu'il y a eu pour toutes les nouvelles techno des gens qui ont confondu "outil qui aide" et "outil qui doit être utilisé".
[^] # Re: Reaction mitigee
Posté par imr . Évalué à 10.
-.NET est une bonne idée car cela pallie certaines faiblesses du monde ms
-Il n'y a pas d'équivalent à .NET dans le monde unix
-Ces besoins du monde ms que .NET satisfaient existent aussi dans le monde unix
-.NET va etre partout car ms est incontournable (au sens monopolistique du terme: la barriére d'application) et efficace.
tes conclusions sont:
-avoir un .net sous unix est une bonne idée
-mettre gnome sous .net n'est pas la plus mauvaise idée possible.
quelques réponses:
-Ne pas avoir un .NET sous unix, c'ést rendre la monnaie de sa piéce à microsoft avec java. Microsoft a refusé que java fonctionne correctement sur ses plateformes, a mis des batons dans ses roues pour qu'il ne soit pas accepté comme standard dans l'esprit des développeurs et des décideurs.
Maintenant, micrsoft essaie le pari inverse. Implémenter le .net de micrsoft, c'est leur permettre de pouvoir dire "Mais .NET fonctionne PARTOUT!!!"
Donc, stratégiquement c'est une trés mauvaise idée.
-tu sembles tenir pour acquis que .NET va fonctionner. m$ est une société qui peut survivre à des échecs terribles, qui peut tourner le dos du jour au lendemain à une stratégie couteuse sans faire faillite mais n'est pas une société dont tous ses projets fonctionnent, et n'est pas non plus une société qui n'a jamais laissé tomber ses développeurs quand le vent a tourné.
Néanmoins, même si .NET était un succés, je ne lierais jamais l'avenir d'un projet libre à un projet micrsft. Les récentes déclarations sur la gpl et le mouvement du logiciel libre laisse penser que mcsft a l'intention de leur nuire.
-si .NET répond a des besoins des projets du libre, comme tu le dis et je n'ai pas de raison de ne pas le croire, il faut donc que ce soit projet du libre qui réponde à ces besoins car lui seul pourra garantir le maintien de leur indépendance et la prise en compte de leurs réels besoins.
Un projet de micrsft n'a jamais eu d'autres finalité que d'obtenir et de maintenir leur monopole. Il ne donnera jamais d'autre fruit.
A partir de ce point, établir gnome sur .NET est bien la PIRE idée possible.
L'idéal serait une nouvelle perle comme samba l'est:
Un projet capable de batir des ponts entre les 2 mondes; qui satisfait pleinement les besoins qu'on peut avoir de smb, qui permet de dire "mais ca marche sous UNIX!!", et qui permet au monde UNIX de garder sa spécificité et d'apporter ses propres réponses à ses propres problémes.
Bref d'utiliser smb, sans baser ses solutions de voisinnage réseau sur lui.
# De notre agence de presse DLFPN
Posté par imr . Évalué à 10.
Il se serait dés à présent mis à s'autoriser des commentaires sur sa nouvelle égérie:
""OK there are two security models in place - one is the Windows NT security model; which is actually a pretty [pauses] You've seen security holes in Microsoft products - buffer overflows - they're not problems in the security architecture - that happens with Unix too. They happen to be really bad at managing their bugs, and not providing fixes on time, but that's another issue. That's the NT security system."
La réaction du géant américain fabricant de consoles à manettes géantes trés respecté des ménagéres de + de 50 ans ne s'est pas faite attendre:
http://slashdot.org/article.pl?sid=02/02/02/2012227&mode=flat&a(...)
Gageons que l'on peut s'attendre à d'autres commentaires avisés du désormais célébre MDI qui fera ainsi gagner beaucoup de temps à la si sympathique firme américaine qui a redonné tout son sens au jeu monopoly.
Ainsi un "insider" de la firme nous aurait donné une "raodmap" d'ors et déja trés apréciée dans les hautes sphéres micromicrosoftienne grace à l'influence du nouveau venu:
-s'autoriser pleins de commentaires sur CORBA par rapport à rpc qui est "vraiment un vieux machin".
-implémentation de CORBA dans SOAP
--s'autoriser pleins de commentaires sur le fait que les processus d'intercommunication sont mal fait dans le monde windos
-implémentation de BONOBO avec CORBA dans SOAP
-s'autoriser pleins de commentaires sur le fait que le monde windos sux
-implémentation de DCOP avec BONOBO avec CORBA dans SOAP
-s'autoriser pleins de commentaires sur le C++
-réécriture de dcop en C
-s'autoriser pleins de commentaires sur n'importe quoi
-réimplémentation de DCOP_C avec BONOBO avec CORBA avec SOAP
-s'autoriser pleins de commentaires sur la difficulté à trouver des noms de singe dont personne à jamais entendu mais ça c'est la faute de la télé ...
-implémenter un nouveau truc dans quelquechose
Pendant ce temps, dans le laboratoire secret de la FSF:
RMS: des nouvelles, mon disciple ???
ESR: je t'ai déja dit, si tu m'appelles comme ça, je te flingue.
RMS:ok ok, ils ont reçu le colis ?
ESR: ouaip! Ils croient que c'est un nouvel allié puissant dans la force.
RMS:héhé le plan se déroule à merveille. D'aprés mes calculs, ils auront perdu 30% du marché en un an!!!
# ximian...top classe !!
Posté par lulu tirpoi . Évalué à -10.
Une vraie mer"" ce truc, ça recupere tous les softs "gnome" qui ne sont lançable que de ximian.
J'ai essayé de lancer gaim sous kde, le résultat fut impressionnant: lancement du bureau ximian dans kde !!!. Ensuite pour désinstaller ce truc il n' y a qu'une seule solution, oubliez Red cArpet ça marche pas,il essaye tout simplement d'installer 2 packages pour aussitôt les désinstaller, resultat: plantage!!! Donc faut seulement refaire une install complete pour virer cette mer"" !!!
Alors tout ce que disent les mecs de Ximian, j'ai comme des frissons dans le dos, ils devraient bosser pour micrososft et laisser linux tranquille.
Voilà c'etait tout
[^] # Re: ximian...top classe !!
Posté par Yusei (Mastodon) . Évalué à 3.
En suite pour désinstaller, vu que ça vient sous forme de rpms c'est pas bien compliqué, ta distrib est pas livrée avec un utilitaire graphique pour ça ?
Enfin si t'es pas content avec, enlève le (reflexes windowsiens, formatter et réinstaller ?), personne ne t'oblige à l'utiliser.
(hop, -1)
[^] # Re: ximian...top classe !!
Posté par lulu tirpoi . Évalué à -3.
J'ai fait un raccourci bureau de gaim et evolution sur le bureau kde et le résultat (dommage je n'ai pas de shoot d'écran!) c'est l'affichage tout simplement d'un crash gnome (j'etais sous kde!).Après evidemment c'est vrai que ça faisait longtemps que je n'avais pas eu un reflexe windowsiens mais virer chaque RPMs, j'suis pas sûr que c'etait plus rapide (une 60ene).
Merci tout de même de me laisser la possibilité de le virer. :-)
[^] # Re: ximian...top classe !!
Posté par Frédéric RISS . Évalué à 1.
Ximian fourni une distribution de gnome... Et si tu n'installes que du Ximian, tout marche correctement (tu l'as dit toit même, tu avais accès à ces programmes depuis le menu gnome). Avant que tu installes Ximian Gnome, tu avais des liens dans les menus BlackBox et KDE parce que c'était des packages de distribution et comme chaque distribution a sa propre façon d'organiser les menus, seuls ses paquets peuvent garantir d'avoir les liens partout.
Ximian fourni des paquets qui vont sur plusieurs distribs, je ne vois pas comment ils pourraient gérer les choses qui sont extérieures à leur paquets.
nb : je n'utilise pas Ximian Gnome, je dis pas que c'est bien, je dis juste qu'il faut un peu réfléchir avant de hurler et de raconter des conneries.
nb2 : Quand une appli gnome plante, c'est normal de voir un rapport de crash de Gnome.
[^] # Re: ximian...top classe !!
Posté par lulu tirpoi . Évalué à -5.
C'était mon experience sous ximian desktop avec la mandrake 8.1 c'est tout. Alors peut-être que sur une autre distrib, avec un autre ordinateur et un autre utilisateur ça plante pas!
Nb: j'ai trouvé le truc tellement bien au debut que je l'ai même installé sur 2 machines sur lesquelle,j'ai eu les même prob ensuite.
Nb2: j'espere que je n'ai pas trop hurlé de dit de conneries ce coup ci?
Nb3: Ximian desktop sous Mandrake 8.1 c'est de la mer"".
# et DotGNU dans tout ca ?
Posté par Dams Nadé (site web personnel) . Évalué à 10.
".GNU" (http://www.dotgnu.org/(...)). Le compilateur C# *libre* de .GNU a depasser fin 2001 le quart de million de lignes de code, donc ca bosse...
"The DotGNU project was originally started in reaction to Microsoft's .NET strategy, for which it will be a complete replacement (and not just a Free Software implementation)."
MDI a surement l'intention de developper avec ".GNU".... Chacun pense ce qu'il veut, mais on en est meme pas a la version 2 de Gnome. Alors pour l'eventuelle version 4, on a le temps de voir venir tout ca et .Net/.Gnu de se stabiliser pour voir ce que ca donne reellement..
[^] # Re: et DotGNU dans tout ca ?
Posté par Jar Jar Binks (site web personnel) . Évalué à -2.
Donc rien à voir avec Mono, ça veut dire que c'est complètement autre chose, et que ça ne sera pas compatible (et de toute façon, on s'en fout).
# Cet article est un hoax !
Posté par adolphos . Évalué à 3.
Une suite de citations visiblement saucissonnées dans le but de provoquer un scandale.
De plus, les phrases du copain sont ambiguës à souhait.
Par exemple, que veut vraiment dire le "Well in the Windows world they use SOAP they do not talk about proprietary protocols. " - Dans le monde windows, ils utilisent SOAP .Ils ne parlent pas de protocoles propriétaires.- ?
C'est incompréhensible car Tous Le Monde sait que MST utilise COM et DCOM, format proprio. Veux-t-il dire que les spécifications .Net ne parle que de SOAP comme broker ?
On dirait un ivrogne interrogé par un autre.
Et même en supposant que cet article a un fond de vérité, je ne vois pas trop le danger pour Gnome.
.Net est un framwork, une couche d'API supplémentaire sur celle déjà existante.
En quoi est-ce que ceci remettrait en cause le coté Libre de Gnome ?
Ca permet de programmer plus rapidement, c'est ce que vise le MDI. Donc d'augmenter le nombre, la qualité et l'étendue des progs libres. Et en plus, le portage Windows==>*nix sera super facile.
Bien sur, MST voudra modifier ses Spéc. Mais s'il le fait trop, les programmeurs windows retomberont dans la situation actuelle, ou des couches sédimentaires d'API se sont accumulés dans un vaste bordel archéologique.
Ce sera un frein puissant.
Sans compter que les développeurs ont actuellement pas mal de choses nouvelles à assimiler et que ca va prendre du temps.
Et de tout façons, le but principal de MDI sera atteint : augmenter la productivité des programmeurs Gnome.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.