C'est vrai que ca a l'air interessant. Mais je me demande a quel point un tel ensemble n'est pas un frein au developpement. Le developpeur de logiciel libre est en general quelqu'un qui a horreur d'avoir des contraintes quand il code.
L'exemple de GnuPedia vs WikiPedia me vient a l'esprit. D'un cote, on a un formalisme tres pousse qui garantit la qualite des articles et qui doivent etre bien rediges et verifies et tout et tout. De l'autre n'importe qui fait n'importe quoi. Au final, WikiPedia produit bien plus d'articles que GnuPedia, d'une qualite strictement croissante et qui au final, est tres bonne.
Evidemment, il faut reflechir a ses buts. Veut-on collecter du savoir ou faire une encyclopedie formalisee ?
Idem pour un projet logiciel libre. On veut ecrire un logiciel ou garantir que le logiciel qu'on ecrit est de bonne qualite ? Notons que bien que la premiere proposition ne garantisse pas la qualite de facon formelle, elle est souvent au rendez-vous tout simplement par la plus grande liberte accordee aux developpeurs.
Apres tout, KDE a fait le travail de Mozilla (un browser, un mailer, ...) avec beaucoup moins de resources (environ 4 personnes sur Konqueror, dont une payee), sans systeme de suivi de qualite formel, et le resultat est plus que comparable (superieur a mon avis).
J'ajouterai que TheKompany developpe de moins en moins de soft bases sur KDE, ils se basent plutot sur Qt directement. Les quelques applications qu'ils ont contribue a KDE n'ont pas recu une modif de leur part depuis plus d'un an et ils n'ont jamais touche au coeur de KDE.
Donc le lien entre KDE et TheKompany est de plus en plus tenu. Qui plus est, le directeur de TheKompany est assez puant et est en train de se faire mal voir par toute la communaute KDE.
Je suis degoute mais on a peut-etre une chance de notre cote, les elections, c'est pour bientot.
Je propose d'organiser une grosse manif, facon CGT. Il faut contacter toutes les assoces, tous les LUGs et s'organiser. On ne peut pas laisser passer ca.
KDE et Gnome ont tous deux la possiblite d'utiliser Gecko, de mozilla.
Mais KDE prefere en general khtml, son propre moteur. Gnome a aussi le sien, gtkhtml, qui est base sur khtml.
Mais il faut voir que c'est pratiquement impossible de reutiliser un composant ecrit en C/Gtk en C++/Qt et vice versa. En revanche, le portage est en general trivial.
Cela dit, theoriquement, bonobo et xpart peuvent s'utiliser reciproquement, avec un peu de boulot mais pas beaucoup. Il faut cependant voir que ca n'interesse personne. Les gars de KDE bossent sur KDE et les gars de Gnome sur Gnome.
Bon sang, mais un seul d'entre vous a-t-il lu la licence de BitKeeper ?
CA N'EST PAS UN LOGICIEL PROPRIETAIRE !!!!
Je repete parce que visiblement, beaucoup sont bouches ici:
BITKEEPER N'EST PAS UN LOGICIEL PROPRIETAIRE !!!!
Alors vos deblateration sur si c'est bien ou pas d'utiliser un logiciel proprietaire, c'est vraiment completement deplace.
Pour les demeures qui sont pas capable de faire un effort de recherche sur la licence de bitkeeper:
- on a les sources de bitkeeper
- on peut modifier les sources de bitkeeper
- on peut redistribuer les sources modifiees de bitkeeper
- on peur redistribuer des binaires de sources modifiees de bitkeeper
Donc je vois mal ou est le proprietaire la dedans.
Maintenant, les petits details:
- c'est gratuit, mais il faut demander pour downloader bitkeeper
- on peut redistribuer uniquement des versions qui passent les tests de non-regression.
- si on utilise la version libre, le repository est accessible et visible pour le monde entier
- il existe une version payante avec les contraintes precedamment citees en moins, le support et quelques trucs en plus.
> Linus a compris que sans le proprio Linux finira par reculer !
Bullshit!
Linus, n'est pas un integriste du libre a la RMS, mais il ne faut pas le prendre pour un con non plus. C'est a mon avis (pour ce qu'il vaut, mais ca fait pas mal d'annees que je le regarde) un defenseur du logiciel libre mais aussi quelqu'un de tres pragmatique. Donc un bon outil, s'il est libre sans etre GPL, passera tres bien. En revanche, jamais Linus ne dependra d'un logiciel proprietaire pour gerer Linux. Ce serait en plus en frein pour tous les autres developpeurs.
Je suis en complet desaccord avec ce que tu dis, le logiciel proprietaire peut certe etre utile de temps en temps, mais ce n'est pas pour ca qu'on va reculer si on en utilise pas.
BitKeeper a ete developpe avec la gestion du Kernel en tete (le mec a pris un annee sabatique pour developper ca) et est tres bien adapte, notamment pour ce qui conerne l'approbation des patch, la replication de la base centrale, la gestion des conflits de patch, et pas mal d'autres trucs qui constituent les spcifites de tres gros projets avec des tres grosses equipes.
Faut bien se rendre compte que CVS, meme si c'est genial par rapport a rcs ou pvcs, ca a un certains nombre de limitations, surtout pour les tres gros projets ou plusieurs equipes travaillent separement.
Et je le repete, ce n'est pas GPL, MAIS C'EST LIBRE!!!!
Moi je me rejouis que Linus quitte un peu sa mentalite je fais joujou avec Linux pour permettre des comportements plus professionnels. J'entends par la que les patch perdus, l'impossibilite de suivre le developpement en cours de route, la difficulte a maintenir des ports separes ou des jeux de patch, c'est hyper lourd a la longue. Vu le nombre de personne qui dependent aujourd'hui de Linux, un peu plus de tenue sur le developpement ferait du bien.
Dans la serie des merdes a eviter, vous pouvez mettre PVCS.
C'est lent, c'est pas securise, ca ne monte pas en charge, c'est impossible de bosser a plusieurs avec ca, il ne fait que du diff fichier par fichier, il n'est pas toujours possible de retrouver l'ancienne version de ses sources.
Bref, a part le fait que Merant a noyauter les organismes de certification ISO, il n'y a aucune raison valable pour utiliser PVCS.
> Tu m'étonnes ! y'en a qui vont sauter au plafond en apprenant qu'il leur faudra utiliser un logiciel propriétaire
> (et payant de surcroît) pour améliorer le rendement du dev du noyau...
Faudrait peut-etre se renseigner avant d'avancer des conneries aussi grosses!
En gros, la BKL te permet de modifier le source, de le redistributer, sous forme de source ou de binaire, a condition qu'il passe les tests de non-regression de BitKeeper.
Les utilisateurs de la version "libre" doivent satisfaire une exigence originale : tous les repository et les changements sont accessibles sur le web. Ce n'est pas un probleme pour un projet libre, mais aucune boite n'accepte ce genre de chose, donc ils securisent leur business.
En ce qui me concerne, je trouve ca libre, et en plus original.
Le DVD apporte beaucoup de choses par rapport au VHS, qui n'a pas l'air d'etre pris en compte dans ce nouveau support:
- choix de la langue et du sous-titre
- bonus tracks
- faible taille. Dans la place de 5 cassettes VHS, tu dois bien pouvoir caser 15 DVD. Sachant que les gens ont de plus en plus tendances a acheter et stocker leur films, c'est un argument qui va jouer.
Malgre ces inconvenients, pour faire decoller le format, il suffit que tous les majors de Hollywood boycottent le DVD pour le D-VHS. Mais ce me parait peu probable, donc effectivement c'est un truc de loser.
> Et pour ce qui est d'etre open source mais pas libre, je n'en ai pas en tete, mais il y en a surement.
Cf ma remarque plus haut sur l'origine du mouvement Open Source.
Ce n'est pas un hasard si la difference theorique entre Open Source et Free Software ne se retrouve pas dans la pratique.
Ca rend la confusion beaucoup moins agacante. Quand quelqu'un dit Open Source la ou il faudrait dire Logiciel libre, pensez juste que c'est un naif qui s'est fait prendre a un argument marketing, pas un imbecile qui n'a rien compris au logiciel libre.
En resume: "Open Source is a marketing term for Free Software".
Le programme marketing de ESR a excellement bien marche. La presse parle partout de logiciel Open Source. Dans 99.99% des cas, elle fait reference a du logiciel libre, mais l'habillage OpenSource lui convient mieux.
Donc certe, c'est irritant car etre libre, c'est different qu'etre ouvert. Mais ce que l'Open Source a apporte en terme de succes au logiciel libre est enorme.
Par ailleurs, si on regarde bien la licence Open Source, on voit qu'elle pose a peu pres autant de probleme qu'une licence libre du point de vue d'une entreprise mentalite close-source. Une telle entreprise veut en general garder le controle des sources, ce que ne permet ni l'Open Source, ni la GPL. Si elle a franchi le cap "je n'ai pas de controle legal sur mes sources", Open Source ou GPL font peu de differences pour elle dans les faits. Sauf qu'elle n'y aurait probablement jamais songe si ca c'etait appele Free Software et non Open Source au depart.
Tu as tout a fait raison. En plus, utiliser plusieurs langages implique des changements de contexte au programmeur qui a du mal a s'adapter. Et il faut un programmeur competent dans plusieurs langages, ce qui peut etre plus dur a trouver.
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.
> tu peux le faire avec des mécanismes plus simples
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.
> Il suffit de spécifier le protocole de communication.
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.
J'oubliais de preciser que du cote eleves, un noyau dur de linuxien maintenaient des logiciels libre sous solaris pour les eleves (emacs, xv, mutt, pine, gcc, good stuff, fvwm, vi, joe, perl, bash, zsh, ... soit en gros le minimum de survie du linuxien de base). Ca veut dire qu'ils avaient la confiance de l'administrateur systeme. Ils ont aussi monte l'informatisation de toutes les chambres d'eleves, avec un serveur linux, qui a fini par grossir. Ils gerent eux-meme les 400 eleves connectes, les miroirs et tout ca (http://www-resel.enst-bretagne.fr(...))
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.
Mais ca reste bien plus lourd qu'un systeme ou l'integration est native. La tu as du wrapper tes classes C++ en python et apres tu te tapes la wrappage python en C qui est quand meme un rien lourd.
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.
Il faut voir que le brevet tue la creation a la source.
D'un cote, un geant comme Microsoft, Sun ou Apple s'amuse a breveter 100 milles trucs differents.
De l'autre Marcel avec son pote Bob developpent un logiciel X. Mais voila, le logiciel X tombe sous un brevet depose par Microsoft. Le fait que ce brevet ne soit pas valide (l'anteriorite et le caractere inventif ne sont en general pas rexpectes), que Microsoft n'ai fait aucune appli comme celle de X, voire n'a jamais utilise la techno brevetee ne change rien. Marcel a le choix entre faire un proces pendant 10 ans a Microsoft ou cesser de developper X. Le choix est vite fait.
Voila comment l'innovation est tuee a la source par les brevets logiciels. Ceux-ci sont senses l'encourager mais en fait, ils ne beneficient qu'aux grosses boites, pour tuer les petites montantes.
Ajoute bien sur a cela qu'un brevet international coute environ 100 kF. Beaucoup de PME sont exit direct pour essayer la technique inverse. Et entre nous, des que tu marches sur les pieds d'un geant, meme si tu as le brevet et tous les droits pour toi, tu as peu de chance de t'en tirer.
Dans son histoire, Microsoft a toujours su tres habilement se retourner.
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.
ecole d'ingenieur: ENST Bretagne.
Tout se fait sur des stations solaris, soit environ une soixantaine de poste. Donc la-bas, quand tu arrives, tu te tapes solaris. A l'epoque, c'etait plutot hyper mal configure, donc on faisait vite l'assimilation unix=truc merdique pas pratique a utiliser. Le Window Manager par defaut etait twm, pas de goodstuff installe, tous les outils conseilles de bases etaient les grosses merdes de sun.
Cela dit, la derniere fois que je suis revenu, ils etaient passes a CDE, ce qui etait deja beaucoup mieux. D'ici quelques annees, ils seront surement sous KDE ou Gnome.
Il y a quand meme une vingtaine de postes sous Windows qui servent en gros a taper les rapports sous Word (bonjour les problemes quand plusieurs promo doivent terminer un rapport pour le meme jour).
J'espere aussi que vu leurs initiatives du cote du libre (picolibre), ils ont fini par mettre des postes sous Linux.
a l'ENST Paris, on trouve des postes sous Linux, des stations solaris, des postes sous windows, et meme une ou deux stations vms. Et l'admin la-bas, c'est pas un blaireau.
Donc ca depend vachement des ecoles d'ingenieur.
Ca peut aussi poser des problemes. Dans mailman, ils se sont plaints que certains "chemins" n'etaient explores que tres rarement et qu'ils ont decouverts des problemes tres tard a cause de ca.
Perso, j'ai souvent le probleme d'une variable mal orthographiee dans une zone qui n'est utilisee que tres rarement. Ca va planter mon appli qui tourne comme un charme depuis des mois, pour un truc stupide, qui n'est pas un bug.
Parfois, un typage pseudo-statique me plairait bien.
# Effet /.
Posté par Philippe F (site web personnel) . En réponse à la dépêche Les Verts et la proposition de directive sur les brevets logiciels. Évalué à 1.
[^] # Re: Software Engeneering de Mozilla
Posté par Philippe F (site web personnel) . En réponse à la dépêche Interview en pagailles. Évalué à 3.
[^] # Re: Software Engeneering de Mozilla
Posté par Philippe F (site web personnel) . En réponse à la dépêche Interview en pagailles. Évalué à 5.
L'exemple de GnuPedia vs WikiPedia me vient a l'esprit. D'un cote, on a un formalisme tres pousse qui garantit la qualite des articles et qui doivent etre bien rediges et verifies et tout et tout. De l'autre n'importe qui fait n'importe quoi. Au final, WikiPedia produit bien plus d'articles que GnuPedia, d'une qualite strictement croissante et qui au final, est tres bonne.
Evidemment, il faut reflechir a ses buts. Veut-on collecter du savoir ou faire une encyclopedie formalisee ?
Idem pour un projet logiciel libre. On veut ecrire un logiciel ou garantir que le logiciel qu'on ecrit est de bonne qualite ? Notons que bien que la premiere proposition ne garantisse pas la qualite de facon formelle, elle est souvent au rendez-vous tout simplement par la plus grande liberte accordee aux developpeurs.
Apres tout, KDE a fait le travail de Mozilla (un browser, un mailer, ...) avec beaucoup moins de resources (environ 4 personnes sur Konqueror, dont une payee), sans systeme de suivi de qualite formel, et le resultat est plus que comparable (superieur a mon avis).
[^] # Re: ximian+sun+qipro=gnome ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Accord Sun, Ximian et Wipro. Évalué à 4.
Donc le lien entre KDE et TheKompany est de plus en plus tenu. Qui plus est, le directeur de TheKompany est assez puant et est en train de se faire mal voir par toute la communaute KDE.
# Manifestons
Posté par Philippe F (site web personnel) . En réponse à la dépêche Brevets logiciels: Découverte d'une collusion entre la BSA et la Commission Européenne. Évalué à 9.
Je propose d'organiser une grosse manif, facon CGT. Il faut contacter toutes les assoces, tous les LUGs et s'organiser. On ne peut pas laisser passer ca.
[^] # Re: Vers l'unification et l'au-delà !!!
Posté par Philippe F (site web personnel) . En réponse à la dépêche RMS encourage la collaboration entre Gnome et KDE. Évalué à 6.
Mais KDE prefere en general khtml, son propre moteur. Gnome a aussi le sien, gtkhtml, qui est base sur khtml.
Mais il faut voir que c'est pratiquement impossible de reutiliser un composant ecrit en C/Gtk en C++/Qt et vice versa. En revanche, le portage est en general trivial.
Cela dit, theoriquement, bonobo et xpart peuvent s'utiliser reciproquement, avec un peu de boulot mais pas beaucoup. Il faut cependant voir que ca n'interesse personne. Les gars de KDE bossent sur KDE et les gars de Gnome sur Gnome.
[^] # Re: Tout dans un fichier = beurk :(=
Posté par Philippe F (site web personnel) . En réponse à la dépêche RMS encourage la collaboration entre Gnome et KDE. Évalué à 4.
J'ai une bonne nouvelle pour vous: c'est exactement ce que fait KDE avec ses .dekstop.
[^] # Re: S'il vous plait arretez avec votre Open Source !
Posté par Philippe F (site web personnel) . En réponse à la dépêche Linus passe un peu la main. Évalué à 10.
CA N'EST PAS UN LOGICIEL PROPRIETAIRE !!!!
Je repete parce que visiblement, beaucoup sont bouches ici:
BITKEEPER N'EST PAS UN LOGICIEL PROPRIETAIRE !!!!
Alors vos deblateration sur si c'est bien ou pas d'utiliser un logiciel proprietaire, c'est vraiment completement deplace.
Pour les demeures qui sont pas capable de faire un effort de recherche sur la licence de bitkeeper:
- on a les sources de bitkeeper
- on peut modifier les sources de bitkeeper
- on peut redistribuer les sources modifiees de bitkeeper
- on peur redistribuer des binaires de sources modifiees de bitkeeper
Donc je vois mal ou est le proprietaire la dedans.
Maintenant, les petits details:
- c'est gratuit, mais il faut demander pour downloader bitkeeper
- on peut redistribuer uniquement des versions qui passent les tests de non-regression.
- si on utilise la version libre, le repository est accessible et visible pour le monde entier
- il existe une version payante avec les contraintes precedamment citees en moins, le support et quelques trucs en plus.
> Linus a compris que sans le proprio Linux finira par reculer !
Bullshit!
Linus, n'est pas un integriste du libre a la RMS, mais il ne faut pas le prendre pour un con non plus. C'est a mon avis (pour ce qu'il vaut, mais ca fait pas mal d'annees que je le regarde) un defenseur du logiciel libre mais aussi quelqu'un de tres pragmatique. Donc un bon outil, s'il est libre sans etre GPL, passera tres bien. En revanche, jamais Linus ne dependra d'un logiciel proprietaire pour gerer Linux. Ce serait en plus en frein pour tous les autres developpeurs.
Je suis en complet desaccord avec ce que tu dis, le logiciel proprietaire peut certe etre utile de temps en temps, mais ce n'est pas pour ca qu'on va reculer si on en utilise pas.
BitKeeper a ete developpe avec la gestion du Kernel en tete (le mec a pris un annee sabatique pour developper ca) et est tres bien adapte, notamment pour ce qui conerne l'approbation des patch, la replication de la base centrale, la gestion des conflits de patch, et pas mal d'autres trucs qui constituent les spcifites de tres gros projets avec des tres grosses equipes.
Faut bien se rendre compte que CVS, meme si c'est genial par rapport a rcs ou pvcs, ca a un certains nombre de limitations, surtout pour les tres gros projets ou plusieurs equipes travaillent separement.
Et je le repete, ce n'est pas GPL, MAIS C'EST LIBRE!!!!
Moi je me rejouis que Linus quitte un peu sa mentalite je fais joujou avec Linux pour permettre des comportements plus professionnels. J'entends par la que les patch perdus, l'impossibilite de suivre le developpement en cours de route, la difficulte a maintenir des ports separes ou des jeux de patch, c'est hyper lourd a la longue. Vu le nombre de personne qui dependent aujourd'hui de Linux, un peu plus de tenue sur le developpement ferait du bien.
[^] # Re: Il y aussi ClearCase
Posté par Philippe F (site web personnel) . En réponse à la dépêche Linus passe un peu la main. Évalué à 4.
C'est lent, c'est pas securise, ca ne monte pas en charge, c'est impossible de bosser a plusieurs avec ca, il ne fait que du diff fichier par fichier, il n'est pas toujours possible de retrouver l'ancienne version de ses sources.
Bref, a part le fait que Merant a noyauter les organismes de certification ISO, il n'y a aucune raison valable pour utiliser PVCS.
[^] # Re: ?! c'est commercial, non ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Linus passe un peu la main. Évalué à 10.
> (et payant de surcroît) pour améliorer le rendement du dev du noyau...
Faudrait peut-etre se renseigner avant d'avancer des conneries aussi grosses!
http://www.bitmover.com/bitkeeper/Sales.Licensing.Overview.html(...)
En gros, la BKL te permet de modifier le source, de le redistributer, sous forme de source ou de binaire, a condition qu'il passe les tests de non-regression de BitKeeper.
Les utilisateurs de la version "libre" doivent satisfaire une exigence originale : tous les repository et les changements sont accessibles sur le web. Ce n'est pas un probleme pour un projet libre, mais aucune boite n'accepte ce genre de chose, donc ils securisent leur business.
En ce qui me concerne, je trouve ca libre, et en plus original.
[^] # Re: peu d'avenir
Posté par Philippe F (site web personnel) . En réponse à la dépêche Contre le DVD, une cassette numérique impossible à copier. Évalué à 2.
- choix de la langue et du sous-titre
- bonus tracks
- faible taille. Dans la place de 5 cassettes VHS, tu dois bien pouvoir caser 15 DVD. Sachant que les gens ont de plus en plus tendances a acheter et stocker leur films, c'est un argument qui va jouer.
Malgre ces inconvenients, pour faire decoller le format, il suffit que tous les majors de Hollywood boycottent le DVD pour le D-VHS. Mais ce me parait peu probable, donc effectivement c'est un truc de loser.
[^] # Re: foutez le camps vite !!!
Posté par Philippe F (site web personnel) . En réponse à la dépêche SourceForge proprietarise en masse. Évalué à 3.
http://www.berlios.de(...)
Ils ont aussi une version anglaise, evidemmant.
[^] # Re: Libre / Opensource / Staroffice
Posté par Philippe F (site web personnel) . En réponse à la dépêche Linux en desktop, c'est possible!. Évalué à 2.
Cf ma remarque plus haut sur l'origine du mouvement Open Source.
Ce n'est pas un hasard si la difference theorique entre Open Source et Free Software ne se retrouve pas dans la pratique.
Ca rend la confusion beaucoup moins agacante. Quand quelqu'un dit Open Source la ou il faudrait dire Logiciel libre, pensez juste que c'est un naif qui s'est fait prendre a un argument marketing, pas un imbecile qui n'a rien compris au logiciel libre.
[^] # Re: Libre / Opensource / Staroffice
Posté par Philippe F (site web personnel) . En réponse à la dépêche Linux en desktop, c'est possible!. Évalué à 2.
Maintenant, d'ou vient le mot open source ?
http://www.tuxedo.org/~esr/faqs/hacker-revenge.html(...)
Et surtout:
http://www.opensource.org/advocacy/case_for_hackers.html(...)
En resume: "Open Source is a marketing term for Free Software".
Le programme marketing de ESR a excellement bien marche. La presse parle partout de logiciel Open Source. Dans 99.99% des cas, elle fait reference a du logiciel libre, mais l'habillage OpenSource lui convient mieux.
Donc certe, c'est irritant car etre libre, c'est different qu'etre ouvert. Mais ce que l'Open Source a apporte en terme de succes au logiciel libre est enorme.
Par ailleurs, si on regarde bien la licence Open Source, on voit qu'elle pose a peu pres autant de probleme qu'une licence libre du point de vue d'une entreprise mentalite close-source. Une telle entreprise veut en general garder le controle des sources, ce que ne permet ni l'Open Source, ni la GPL. Si elle a franchi le cap "je n'ai pas de controle legal sur mes sources", Open Source ou GPL font peu de differences pour elle dans les faits. Sauf qu'elle n'y aurait probablement jamais songe si ca c'etait appele Free Software et non Open Source au depart.
[^] # Re: super mais...
Posté par Philippe F (site web personnel) . En réponse à la dépêche Miguel DeIcaza et .NET. É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: Reaction mitigee
Posté par Philippe F (site web personnel) . En réponse à la dépêche Miguel DeIcaza et .NET. É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 Philippe F (site web personnel) . En réponse à la dépêche Miguel DeIcaza et .NET. É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: Parlons en des etudiants en informatique !
Posté par Philippe F (site web personnel) . En réponse à la dépêche Miguel DeIcaza et .NET. É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: super mais...
Posté par Philippe F (site web personnel) . En réponse à la dépêche Miguel DeIcaza et .NET. É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.
[^] # Re: c'est vrai mais...
Posté par Philippe F (site web personnel) . En réponse à la dépêche Manifestation contre les brevets logiciels à la Linux Expo. Évalué à 10.
D'un cote, un geant comme Microsoft, Sun ou Apple s'amuse a breveter 100 milles trucs differents.
De l'autre Marcel avec son pote Bob developpent un logiciel X. Mais voila, le logiciel X tombe sous un brevet depose par Microsoft. Le fait que ce brevet ne soit pas valide (l'anteriorite et le caractere inventif ne sont en general pas rexpectes), que Microsoft n'ai fait aucune appli comme celle de X, voire n'a jamais utilise la techno brevetee ne change rien. Marcel a le choix entre faire un proces pendant 10 ans a Microsoft ou cesser de developper X. Le choix est vite fait.
Voila comment l'innovation est tuee a la source par les brevets logiciels. Ceux-ci sont senses l'encourager mais en fait, ils ne beneficient qu'aux grosses boites, pour tuer les petites montantes.
Ajoute bien sur a cela qu'un brevet international coute environ 100 kF. Beaucoup de PME sont exit direct pour essayer la technique inverse. Et entre nous, des que tu marches sur les pieds d'un geant, meme si tu as le brevet et tous les droits pour toi, tu as peu de chance de t'en tirer.
# Reaction mitigee
Posté par Philippe F (site web personnel) . En réponse à la dépêche Miguel DeIcaza et .NET. É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: Parlons en des etudiants en informatique !
Posté par Philippe F (site web personnel) . En réponse à la dépêche Miguel DeIcaza et .NET. Évalué à 4.
[^] # Re: C'est KPart
Posté par Philippe F (site web personnel) . En réponse à la dépêche Miguel DeIcaza et .NET. Évalué à 10.
[^] # Re: Le typage dynamique, justement ...
Posté par Philippe F (site web personnel) . En réponse à la dépêche Delphinologie en direct de Linux Expo Paris 2002. Évalué à -1.
Perso, j'ai souvent le probleme d'une variable mal orthographiee dans une zone qui n'est utilisee que tres rarement. Ca va planter mon appli qui tourne comme un charme depuis des mois, pour un truc stupide, qui n'est pas un bug.
Parfois, un typage pseudo-statique me plairait bien.
[^] # Re: Python compilé, bon courage !
Posté par Philippe F (site web personnel) . En réponse à la dépêche Delphinologie en direct de Linux Expo Paris 2002. Évalué à -1.
Donc hop, c'est dans la poche.