Johann Deneux a écrit 276 commentaires

Je vais sans doute passer pour un utopiste, mais je pense que l'argent ne doit pas être le moteur de la recherche sur les médicaments.
Des découvertes touchant à un domaine aussi important doivent être accessibles et utilisables par et pour tous.
Une recherche biomédicale basée uniquement sur une logique de profits, c'est forcé d'avoir des effets négatifs:
- Seules les maladies consistuant un marché intéressant sont traitées
- Déterminer le prix d'un médicament en fonction de l'offre et de la demande. Ca devient dangereux surtout quand les brevets permettent un monopole
D'ailleurs, les US ont récemment menacé une compagnie pharamaceutique (Bayer) de passer outre son brevet sur un médicament contre l'anthrax. Que les principaux défenseurs des brevets considèrent de passer outre les brevets devrait montrer leur danger.

J'ai pas dit que j'aimais les brevets. Le mieux pour l'humanité, c'est que quelqu'un qui découvre un truc nouveau ne garde pas son secret pour lui. La coopération est à la base du progrès. Il faut rester cohérent. Quand on milite pour le droit d'accéder au code source, prétendre que le secret industriel est une solution viable me semble contradictoire. On est bien d'accord sur le fait que le droit à l'exploitation exclusive d'une découverte est néfaste.

Dans la section "le secret des logiciels", tu dis qu'on peut protéger efficacement les logiciels par le secret. Il n'est donc pas nécessaire d'utiliser les brevets. En tant que défenseur du logiciel libre, je dois dire que je préfère encore la protection par les brevets plutot que par l'obscurantisme. En effet, les brevets, pour tout dangereux qu'ils sont, ont l'avantage de forcer le dépositaire d'un brevet à publier ses découvertes.

il serait peut être temps de penser à de nouveaux processeurs qui seraient plus petits, moins chauds (plus de ventilation, devenu un rêve utopique)

Rhhhaaaa (soupir d'envie). Un PC silencieux. En ce moment, je cale le coté gauche de ma tour avec mon pied, sinon le boitier vibre contre le corps de la tour, fixée à la carte mère, fixée à deux immenses PII avec des ventilaux vrombissants.

Bon tout le monde s'en fout sans doute, mais qu'est-ce que ce serait bien, un PC sans ventilo....

C'est normal, c'est pas du C ansi. D'ailleurs gcc le dit:

[johann@localhost tmp]$ gcc -ansi -pedantic-errors -c tst1.c
tst1.c: In function `f':
tst1.c:3: ANSI C forbids variable-size array `tab'

Et ils sont portables sur combien de plateformes tes makefiles ?
Parce que les outils de dev de Windows permettent de générer des projets portables ? C'est vrai ? Pour SunOS, MacOS, GNU/Linux ?

Est-ce qu'ils gèrent bien les dépendences ?
A priori, c'est fait pour ça. Je suis pas sur que VC++ (par exemple) s'en tire aussi bien dès qu'on sort des sentiers battus. Comment intégrer proprement des outils tels que Lex et Yacc par exemple ? Je dis pas que c'est pas possible, je connais mal VC++. Mais je pense pouvoir me débrouiller sous n'importe quel environnement pour faire ce genre de truc si j'ai le droit d'utiliser le clavier pour taper un Makefile. Le pro de VC++ aura forcément plus de mal.

Ça s'est vachement amélioré le niveau de la fac maintenant, il en sort de vrais génies qui résolvent d'un coup un problème qui fait chier toute l'industrie depuis des années. Je suis impressioné.
Ta tendance à prendre les gens pour des cons est assez irritante. C'est pas parceque t'as jamais été copain avec les Makefiles qu'il faut prendre ton cas pour une généralité. Y'a d'autres gens ici qui bossent ou qui ont bossé dans l'industrie.Tous les projets portables que je connais utilisent des Makefiles.

Les problèmes que tu décris ne sont pas liés aux Makefiles en eux-mêmes. Ils sont plutot dû au fait que chaque environnement a son propre compilo avec ses propres outils, que la portabilité du C++ n'est pas géniale, que les librairies n'ont pas le même nom, que les bugs à contourner ne sont pas les mêmes partout... C'est vrai, c'est embêtant, mais le pauvre make (jeu de mots non voulu;) n'y est pour rien.

Une tentative pour régler ce problème est l'utilisation d'outils comme configure, Imake et consorts. C'est vrai que ça marche pas super bien. Mais il y a au moins un effort de fait dans la bonne direction. Comment VC++ (ou Borland C++) aborde-t-il le problème ?

La notion de fichier source n'a rien à voir avec la programmation en soi, il y a des langages qui ignorent ce concept, et la tendance des IDE est précisément de t'en abstraire. Ou même tu as carrément des langages comme Java ou la structure des fichiers est définie par le nommage des classes.
Ca ne constitue en rien une excuse pour mettre du code n'importe où. Moi j'aimais bien le concept des petits fichiers textes tout bêtes. On pouvait utiliser n'importe quoi pour les éditer. J'arrive pas à voir en quoi la tendance des IDE à éliminer la notion de fichier est positive. A part rendre dépendant de l'outil en question. Mais ça c'est plutot positif pour l'éditeur de l'IDE en question. Pas vraiment pour le développeur.

Ca dépend des critères que tu prends en compte. Perso, je m'en fiche des IDE. Par contre j'apprécie la disponibilité des outils gnu. Si je code avec VC++, je vais avoir un mal fou à réutiliser un projet sous d'autres plateformes. Je risque même d'être bien embêté si je change de version de VC++.
Par contre, gcc, make et compagnie se trouvent sur un peu toutes les plateformes.

Pour le support c++ de gdb, ca dépend beaucoup des versions de gcc et de gdb utilisées. Mais c'est vrai que j'ai pesté à de moultes occasions contre gdb en déboguant du c++ (les classes utilisant la STL sont illisibles, la STL elle-même est impénétrable).

Quand on n'utilise qu'un seul compilo avec la même librairie c++ standard, on prend le risque d'écrire du code qui ne marche qu'avec le compilo en question.
Avoir plusieurs compilos, c'est toujours un plus pour apprendre à coder proprement.

dire que la copie illicite de logiciel finance le piratage, c'est du n'importe-quoi.
Ben moi, ca me semble évident ;) Si ca avait été écrit en trois lignes, ca aurait peut-être mérité une fortune, ama.

Si quelqu'un rajoute quelque chose et le mets dans une license propriétaire, c'est pas bien, mais il ne t'enlève rien de ce que tu avais avant.

Tout au plus, t'empêche-t-il d'avoir quelque chose de plus.

En théorie, oui. En pratique, n'importe qui peut s'amuser à mettre des droits d'auteur sur une oeuvre du domaine public, et attaquer ensuite les auteurs des versions publiques originales. Comment prouver que la version publique a le droit d'exister, étant antérieure à la version privée ? Dans le cas d'oeuvres d'art célèbres, le problème ne se pose pas. Pour des logiciels connus de peu de gens, si.

Ca me fait penser: pour qu'un logiciel soit effectivement protégé par droits d'auteur, il faudrait déclarer le logiciel en question auprès de je-ne-sais-plus-quel-organisme. Ca permet de résoudre les éventuels litiges qui pourraient survenir sur la paternité d'une oeuvre.

de même ne parlez pas d'un QT ou GTK "serveur", le but de ces toolkits est de faire abstraction du systeme graphique en dessous



par exemple QT fonctionne sur windows (et bientot macos X) permettant a une application QT de s'affranchir de savoir si c est GDI ,QUARTZ ou X11 en dessous. TRES important.



Et alors ??? Je vois pas en quoi l'introduction d'une couche réseau dans un toolkit changerait quoi que ce soit au niveau d'abstraction. Le programmeur n'aurait même pas à s'en préoccuper. Le changement tel que je le vois marcherait avec la totalité des applications existantes sans qu'il soit nécessaire de changer quoi que ce soit.



PS: Quand tu réponds à plusieurs posts, réponds à chaque post individuellement. Une énorme réponse à plusieurs posts est illisible et contient de nombreux morceaux hors-sujet (puisque le sujet est situé ailleurs). Enfin, tu fais comme tu veux, c'est juste une suggestion, hein.

Je n'ai jamais dit qu'il fallait déplacer la couche réseau de X vers les toolkits, mais plutot qu'on pouvait récupérer le même modèle et l'insérer au niveau des toolkits pour alléger l'utilisation du réseau.

Si une machine ne dispose pas de la version Qt distribuée, rien n'empêche de retomber sur X11.

Un autre problème réside dans les fonctionnalités "étendues" des cartes nVidia. Je pense à la sortie TV, à la vision stéréo(*). Pendant l'été 2000, je suis pas sûr que la sortie télé était supportée. Pour ce qui est de la vision stéréo, c'est clair, c'est pas supporté sous Linux.

Conclusion: les drivers nVidia pour Linux sont bien si on ne sort pas des sentiers battus.

(*) En utilisant des lunettes à obturateurs, comme les Revelator3D d'ELSA.

Ca me fait penser à une vieille idée que j'ai jamais eu le courage et le temps d'essayer: si on insérait une couche client/serveur réseau au niveau du toolkit ?

Dans l'état actuel des choses, voila ce qui se passe quand on deplace une barre de défilement d'une liste pop-up:

1. Le serveur X detecte un evenement souris et l'envoie au client.

2. Le client X interprète l'événement et demande au serveur X d'effacer de redessiner le contenu de la liste (ce qui demande de nombreuses commandes: il faut effacer redessiner les traits, le texte)



Avec un qt (ou gtk) possédant une couche réseau, tout se passe uniquement sur le "serveur qt (ou gtk)". Les seuls communications qui subisteraient seraient des appels de callbacks définis par l'utilisateur à éxécuter du côté client qt:

1. Le serveur Qt détecte un événement souris. Il regarde le callback associé à cette événement. Le callback est en fait un morce de code de Qt lui-même et peut être éxécuté localement.

2. Le serveur Qt éxécute le callback, qui consiste à redéssiner la liste.

Non, n'importe qui (donc l'auteur également) peut récupérer un soft dans le domaine public et le redistribuer avec la license qu'il veut.
En fait, tout le monde a tout les pouvoirs sur un soft du domaine public.

modèle libre : la boite coule ==> un projet sourceforge avec un pourcentage d'activité de 0% et plus de commits sur le CVS depuis des mois
FreeCiv est un beau contre-exemple. Le mainteneur a changé plusieurs fois, et le jeu continue d'évoluer. Je ne connais pas bien CivCTP, mais je n'ai aucun doute sur le fait que FreeCiv le depassera un jour ou l'autre, si ce n'est deja fait.
C'est vrai que FreeCiv fait un peu office d'exception, mais le fait est la: un jeu tombe dans le libre avec des sources propres *peut* etre repris a tout moment, meme si ca peut prendre du temps.

Oui, en général, il apparaît dans une soupe d'entreprises, un trio de tête qui effectivement domine, mais c'est justement là la loi du marché
C'est bien le problème. La bonne idée du capitalisme est que la concurrence suffit à avoir un système économique sain. Pas besoin d'un gouvernement qui controlle tout et décide comment répartir les fonds. Ne t'y trompes pas, je soutiens cette forme de capitalisme.

Par contre, arrive un moment où seule une poignée de grosses entreprises restent (les "meilleures"). Cette étape-là est néfaste, surtout pour le consommateur. En fait, il ne s'agit plus de capitalisme.

Bien sûr qu'on bénéficie du bouclier des entreprises, sinon, comment aurions nous pu être vaccinés, comment aurions nous pu avoir l'électricité
Les exemples que tu donnes tendent plutot à défendre un système socialiste. EDF a longtemps été la propriété de l'état sans que ça ne pose problème. Au contraire, la Californie a eu de gros problèmes d'énergie il n'y a pas si longtemps. Quant aux vaccins, ils sont en France remboursés par la sécu, alimentée par les employés. Certes, les entreprises payent des impots qui alimentent l'état. Mieux vaut donc avoir des entreprises qui font du bénéfice.

Ils ne s'embarassent pas de théories utopistes
Hmm, ça me laisse pensif. A mon avis, si, ils s'embarassent de théories utopistes. Comme l'abollition de l'esclavage. A l'époque, ça devait passer pour une utopie (ça n'avantageait pas les blancs, ça ne rapporterait pas d'argent). Par contre, j'ai peur du poids que prennent les entreprises auprès du pouvoir politique. Elles manquent justement de "théories utopiques". Si aujourd'hui l'esclavage existait encore, je me demande si on pourrait l'abollir.

PS: En écrivant ça, je me demande si je ne confonds pas libéralisme et capitalisme.

Quand une espece (une entreprise) evolue pour survivre, cette espece devient "meilleure". Les plus faibles disparaissent. Ta comparaison, si elle est vraie, montre que le capitalisme actuel conduit naturellement a des situations de monopole. Or cette situation n'est nullement souhaitable pour nous, les consommateurs.

Le temps passe, les entreprises mal gerees disparaissent, ce dont tout le monde beneficie. Puis les meilleures entreprises protegent leur segment de marche, interdisant la croissance de tout nouveau concurrent. La concurrence n'existe plus, ce qui est tres dommageable, surtout pour les consommateurs.

L'idee selon laquelle les consommateurs beneficient de la bonne sante des entreprises n'est vraie que jusqu'a un certain point. Ensuite, l'argent cesse "de vehiculer les elements nutritifs jusqu'a [...] nous".

On tombe vraiment en plein delire. Quelqu'un se rappelle 1984 ? A quand l'interdiction d'eteindre sa web cam et son PC ?

Pourquoi ce serait une victoire pour ton chien ?


-1, parceque bon, voila, euh, vous voyez...

En general, un processus en attente d'un evenenement n'est pas actif (il est endormi).


Il y a des cas ou on est oblige de faire de l'attente active (=tester un registre, par exemple), mais c'est en general a eviter comme la peste.

Certes, mais les processus sont interrompus de toute facon a intervale regulier. Meme le processus qui fait du scheduling en user-mode est interrompu par le scheduler du noyau.


La difference serait donc que les user-threads peuvent etre reschedules plus souvent que ceux du noyau. Mais finalement, on perd moins de temps avec un scheduling par le noyau.


Pour resumer: les user-threads sont interrompus par le scheduler user-mode et le scheduler du noyau, les pthreads linux uniquement par le scheduler du noyau. Pourquoi la 1ere solution serait-elle plus rapide ?

Je ne partage pas completement ton opinion. Un systeme, ca se reinstalle en un tour de main (maximum une journee), compare au temps qu'il faut pour generer la montagne de donnees personnelles. Le mieux est encore de lire ses emails depuis un compte isole, qui ne sert qu'a ca.
Je suis persuade que peu font ca, meme parmi les linux-wise-users qui ont compris qu'il valait mieux eviter le compte root.

Je suis quand meme curieux de savoir comment il fait ???

Bien sur, cela va a l'encontre de certaines libertes et l'etat n'est pas completement separe de la vie economique du pays ce qui peut ne pas sembler logique. Mais il faut pouvoir trouver un compromis entre le qualite de vie des citoyens et l'aide a l'economie du pays.
Je comprend ce que tu veux dire, mais ton dernier paragraphe me choque. La liberte n'est pas seulement une question de "qualite de vie". Si on donne la priorite a l'economie, on se retrouve dans des conditions genantes:
- Doit-on fermer cette usine de mine anti-personnel et mettre au chomage leurs ouvriers?
- Doit-on continuer a accorder des remises de peine, sachant que cela risque de mettre sur la paille des prisons privees (ca existe en Australie, aux US...) ?

Point qui necessite d'etre souligne: les brevets logiciels sont economiquement nefastes.