boubou a écrit 1384 commentaires

Mais à la base tout ce qui est produit par l'employer est propriété de l'employeur.

Seulement pour le logiciel. Pour tout le reste, il faut une mention explicite dans le contrat de travail pour que l'employeur obtienne la propriété de la production de l'employé.

Attention, il n'est pas clair que tu sois propriétaire du compte-rendu. Quand tu produits un document en tant que salarié, il faut impérativement que ton contrat de travail comporte une clause de cession pour que tu ne sois pas propriétaire de ce que tu produits (mémoire, etc.). De ce fait, les entreprises font assez systématiquement signer une cession, même pour un stage. Si tu as une telle clause dans ton contrat, ta boite est vraisemblablement propriétaire du document. D'autre part, le statut des étudiants n'est pas celui des salariés. Il faudrait donc consulter un spécialiste pour savoir si ton établissement de formation n'est pas propriétaire de ton mémoire conjointement avec ta boite.

remarque la recherche éffectuer par les salariés de l'état est propriété de l'état

Faux. Le code de la propriété intellectuelle est relativement clair à ce sujet. En France, les oeuvres (hors logiciel) produites par un enseignant sont la propriété de l'enseignant. C'est aussi le cas des thèses qui sont la propriété du thésard. De façon générale, les juristes s'accordent à dire que les oeuvres des chercheurs de l'état français restent la propriété de ces chercheurs (il y a une différence subtile entre les enseignants et les chercheurs, essentiellement au niveau de la jurisprudence, mais bon...).

Ouai, sauf que quand tu creuses vraiment tu arrêtes de dénigrer pour le plaisir. De fait, beaucoup de personnes en dehors des maths rédigent leur thèse en word. D'autre part, si tu vas sur cyberthèse (http://mirror-fr.cybertheses.org/index.html(...) ), le site piloté par lyon 2 et montréal, tu t'apperçois que LaTeX est parfaitement prévu (cfhttp://mirror-fr.cybertheses.org/ressources.html#chaine(...) ).

C'est surtout une connerie. Avec des raisonnements aussi foireux, on abandonne unix parce que la plupart des serveurs sont basés sur des process et non pas des threads et que le surcoût par rapport aux threads est non négligeable. Le truc, c'est que les performances, c'est assez compliqué. J'ai écris la version multi-thread (enfin 2 threads...) de freecraft, un clone de warcraft. Avant, la gestion du son était basée sur select, maintenant, c'est avec un thread. Il n'y aucun doute sur le fait que la solution par thread est meilleure, en particulier en cas de forte charge (l'idée est que tout rame, pas seulement le son, ce qui rend le jeu lent mais jouable). Le problème principal, c'est trop de threads. En cas de forte charge sur un serveur HTTP, il vaut mieux 50 threads (apache 2.0) que 50 process (apache 1.x). Mais bon, arrêtons de nourrir ce mini-troll.

En général, avec un pool de thread et une approche déconnectée, on arrive à faire des choses très bien en Java. En gros, tu alloues disons 50 threads (au pif) à ton appli. Quand un client arrive tu lui attribues un thread au hasard dans les threads libres et tu exécutes sa requête. Si le protocole est déconnecté, c'est-à-dire si le client se déconnecte après la réponse à sa requête, tout se passe bien. Si j'ai bien compris, Volano a une approche connectée et ils sont donc relativement obligés en Java 1.3 et avant d'avoir un thread par client, afin de garder la connexion ouverte tout en étant toujours capable de répondre aux nouveaux clients. Ce genre d'architecture ne monte pas trop en charge. Bien entendu, les io non bloquantes sont en grand pas en avant pour résoudre certains problèmes, mais ce n'était pas un problème pour certaines formes de client serveur, en particulier pour tout ce qui est basé sur HTTP qui est un protocole déconnecté. La plupart des applications Java sont justement orientées servlet, ejb et compagnie, c'est-à-dire HTTP à la base. Voilà, je suppose que ça répond à ta question (ou à ton sarcasme, mais bon...).

Je suis plus mitigé. Je pense que le modèle Volano n'est pas le bon pour les applications serveurs, parce qu'il correspond à un cas vraiment très particulier. Dans un serveur normal, on ne démarre pas 1000 threads, on utilise un pool de threads par exemple. De plus, la version 1.4 du jdk permet l'utilisation de construction à la select et donc rend obsolete une partie de la solution volano (à mon avis).

Je suis bien d'accord avec toi sur l'importance pour Java du côté serveur. Il y a justement tout un travail en ce moment sur l'évaluation des performances des moteurs de servlet, d'EJB, etc. On trouve un article très intéressant à ce sujet sur http://www.cs.rice.edu/CS/Systems/DynaServer/index.html(...) On y découvre que l'essentiel du temps de calcul est perdu dans les communications entre les couches de l'application multi-tier proposée. Sauf erreur de ma part, ce genre de chose n'est pas du tout testé par Volano (il s'agit de communication RMI, pas socket).

Bref, tout ça pour dire que l'évaluation de performances, c'est un domaine de recherche à part entière et que c'est bien délicat.

Volano (attention au point à la fin de ton url http://www.volano.com/benchmarks.html(...) ), c'est très intéressant comme bench, mais c'est fondamentalement merdique. En effet, le serveur utilise un très grand nombre de threads afin d'obtenir des entrées/sorties non bloquantes. C'est effectivement une technique (obligatoire en java 1.x avec x<4), mais c'est très coûteux en terme de performance pour le système.

En fait, un programme blindé de threads fait ramer une machine, qu'il soit programmé en java, en C, en C++, etc. C'est la multiplication des threads qui pose problème. De ce fait, Volano donne une mesure de qualité d'une JVM, mais pour une application très particulière, ce qui n'est pas vraiment généralisable. Il existe d'autres benchs qui testent d'autres aspects, comme par exemple ceux inclus dans la bibliothèque de calcul matriciel colt (cf http://tilde-hoschek.home.cern.ch/~hoschek/colt/(...) ). Cependant, de façon assez générale, les machines IBM restent les plus rapides.

Une note au passage, un des intérêts (entre autres !) du jdk 1.4 est de proposer des entrées/sorties non bloquantes basées sur le principe de l'appel system select (en général, c'est beaucoup plus efficace qu'avec plein de thread).

Franchement, la JVM blackdown en open source, j'y crois pas trop. Sauf erreur de ma part, les modifications de portage effectuée par blackdown sont déjà en GPL (avec des clauses d'exception, étant donné que la GPL n'est pas compatible avec la licence "open source" de Sun). Mais comme l'essentiel de la JVM vient de Sun, il faudrait que Sun passe son code sous une licence open-source. A mon avis, ce n'est pas pour demain (sauf peut être si IBM rachète Sun, sait-on jamais).

La discussion apache/sun ne porte pas sur le code de Sun, mais plutôt sur ce qui sort du community process, c'est-à-dire les spécifications (cf http://jakarta.apache.org/site/jspa-agreement.html(...) ). En gros, Sun est d'accord pour que Java (en tant que plateforme, c'est-à-dire la JVM et surtout les apis) soit implantable en open source et donnera gratuitement les programmes permettant les tests de compatibilité d'une implantation avec le standard (ce don n'est prévu que pour les implantations open-source). De plus, une implantation open source compatible pourra être qualifiée et donc obtenir le droit de se revendiquer Java officiellement (exit les problèmes actuels d'implantation en open source de J2EE). Enfin, Sun aidera les groupes open source (lire apache, à mon avis) à passer les tests (aide financière et humaine, a priori).

C'est sûr qu'on est loin des brevets puants de MPEG 4, mais bon, ce n'est pas encore de l'Open source.

Très intéressant, ton post. Quelques remarques :

Sur les interfaces et les classes abstraites :
J'irais plus loin que toi. Je pense que l'interface est le terme "objet" pour désigner un type abstrait, quelque chose qui est au moins aussi vieux que l'objet. Un type abstrait, c'est une catégorie de "machins" qu'on peut manipuler pour construire un algorithme. Pour définir un type abstrait, on fait en gros la liste des opérations disponibles sur les "machins" en question. Bien sûr, actuellement on parle objet, donc on ne dit pas "machin", mais objet. Mais bon, sur le fond c'est la même chose. Effectivement, comme C++ ne possède pas la notion d'interface, on l'implante en ce langage par une classe abstraite. A ce niveau, d'ailleurs tu fais une erreur. De fait en C++, une classe abstraire permet justement de représenter la notion d'interface et permet donc plus de chose que le partage de code.

Pour distinction entre récupération de code (héritage au sens classique des langages objets) et celle de type, je pense que la meilleure chose est tout simplement de ne pas appeler la deuxième héritage. Effectivement en Java une interface peut hériter d'une autre, mais c'est de l'implantation. Au niveau de la conception, il s'agit d'une relation sur les types abstraits : on définit un type abstrait dérivé à partir d'un autre type (c'est la notion de sous-typage de Sather). Ce genre de construction dépasse largement le cadre de la programmation objet. C'est utilisé par exemple dans les schémas XML.

sur la définition de DP
Là, je ne suis pas d'accord avec toi. Certains DP sont justement écrits pour faciliter la réutilisation de code (sans parler d'héritage). C'est le cas par exemple de la plupart des DPs de structure qui permettent d'adapter un code existant pour l'utiliser à partir d'un autre code existant. Bien entendu, il n'y a pas de magie : utiliser du code C++ dans une appli Java c'est lourdingue.

sur le Singleton
Alors là, non ! Un Singleton pur, c'est une seule instance, mais tout le monde comprend quand on parle de Singleton pour désigner une classe qui contrôle son nombre d'instances, même si ce n'est pas exactement un (je pense aux pools de Thread, par exemple).
D'autre part ta phrase "Une classe sans état est une classe qu'on n'instancie pas (modifiant static en java)." ne veut pas dire grand chose. Il existe effectivement (en Java) des classes qu'on n'instancie pas. Ce sont de "fausses" classes, c'est-à-dire des groupes de méthodes de classe (celles qui ont le modifieur static), c'est-à-dire une sorte de petite bibliothèque (je pense en particulier à la classe Math qui joue le rôle en Java de math.h en C). Je pense que l'auteur voulait parler dans son article d'objet sans état, c'est-à-dire d'objet sans variable. Par exemple quand on construit un Comparator en Java (un ordre), il est très classique que celui ni ne contienne pas de variable. L'objet joue alors le rôle d'un pointeur sur fonction orienté objet (et d'ailleurs, on utilise souvent une classe anonyme pour programmer ça en Java). L'objet est bien entendu instancié !

Notons quand même que "sensés être"!="sont". Par exemple Visiteur/Visitable, c'est quand même très adapté aux templates. En Java, c'est implantable, mais c'est lourdaux. Il y aussi beaucoup de DP spécifiques, par exemple les DPs orientés Entreprise Java Beans, les DPs orientés Thread (le bouquin de Doug Lea) qui sont relativement spécifiques à Java, etc. Pour le reste, on est bien d'accord, Java c'est le langage de prédilection des patterns modernes (MVC, ça date de smalltalk !).

J'aime beaucoup le "Il suffit de feuilleter ces publications" qui introduit ensuite des jugements à l'emporte pièce sur les publications scientifiques. On pourrait écrire des pages entières pour réfuter en partie tes dires. Bien entendu, chaque domaine a ses problèmes, et comme je l'ai dit dans mon post précédent, certains thésards (et chercheurs) sont mauvais, de même que certains ingénieurs. Cependant, certaines revues (et conférences) de haut niveau proposent un contenu scientifique de très grande qualité. Dans mon domaine par exemple, Neural Networks et Neural Computation sont vraiment excellentes. Je défie quiconque de trouver un exemple des articles dont tu parles dans ces revues.

De plus, tu déplaces complètement le problème. Tu qualifies hativement le milieu de la recherche (que tu ne connais pas, car à moins d'étudier scientifiquement ce milieu (comme l'ont fait de nombreux philosphes et sociologues), il faut y vivre pour acquérir un minimum de compréhension des mécanismes) de "chiant, con et hypocrite" et je ne retrouve dans ton post (à part des attaques personnelles, cf plus bas) qu'une suite d'accusations relativement gratuites sur la qualité des publications en vue de subventions. Je veux bien lire dans tes "arguments" une dénonciation de l'hypocrisie, mais, au risque de me répéter, tu généralises à partir de cas particuliers, certes déplorables, mais plutôt rares.

Tu sembles confondre aussi la situation américaine avec la situation française. D'après mes contacts américains, il y a effectivement aux USA une évaluation au nombre de publications (et aussi au nombre de brevets), ce qui n'est pas exactement le cas en France. Toutes les commissions de spécialistes (et le Conseil National des Universités) comptent bien sûr les publications, mais elles tiennent bien entendu compte de la qualité de la revue et de l'originalité du travail. Si j'écris trois fois le même papier, je me fais allumer. La situation est moins nette aux USA. De plus, la système des co-signatures systématiques est très courant aux USA, alors qu'en France ce n'est pas vraiment le cas.

Je ne peux que reconnaître que sur le fond tu as raison pour la course au fric. Les subventions publiques sont souvent insuffisantes, en particulier pour les labos qui ont des gros frais de fonctionnement comme ceux de physique (gros équipement) ou de chimie (matière première). Ce n'est pas vraiment le cas en informatique (un PC, ça ne coûte pas grand chose). Il faudrait cependant pas carricaturer : on peut parfaitement faire de la recherche en France sans faire de course au fric, mais il faut accepter de ne pas aller dans beaucoup de conférences. En général, la subvention CNRS ou Universitaire est suffisante pour un congrès par personne et par an.

Passons maintenant aux attaques personnelles. Remarque préliminaire : quand on cite, on le fait correctement, mais bon... D'abord je ne stigmatise pas la course au fric. Je dis juste que la liberté du public est énorme car la contrainte financière est moins forte. Je ne dis pas qu'il faut que la recherche soit pure ou désintéressée. Peut-être que tu as des problèmes avec certains chercheurs, mais dans une "discussion" évite de répondre à des positions qui n'apparaissent pas dans le texte auquel tu prétends répondre. Sinon, effectivement, j'ai une double activité. Je fais de la recherche plutôt théorique (cf mes papiers), mais je travaille aussi pour des entreprises. Pour l'instant, j'ai fait verser mes honoraires à mon laboratoire, ce qui me permet de renouveller mon matériel et de partir en mission plus facilement qu'avec les crédits centraux. Comme tu peux le constater, je travaille pour des entreprises sur des thèmes qui n'ont pas tous vraiment de rapport avec mon thème de recherche. C'est l'avantage du public, je pense. Je suis libre de faire de la recherche, mais aussi de rester en phase avec l'évolution technologique en travaillant pour des entreprises. Pour le marketing, si tu avais fait un peu de travail scientifique, tu saurais qu'obtenir certaines données (par exemple des données bancaires ou des chiffres de ventes) est extrêmement difficile. Quand une entreprise me donne accès à de telles données et me paye pour les analyser, c'est une occasion en or de tester mes méthodes. Comme seuls les résultats de l'analyse (ni les méthodes, ni les outils) sont la propriété de la boîte, je ne vois pas de problème.

Ta philosophie, si je comprends bien, c'est de répondre des conneries à des conneries, c'est ça ?

Parce que nous sommes d'accord, j'aimerais beaucoup connaître une boite qui embauche un thésard comme un ingénieur plus 5 ans. Déjà que les thésards ont beaucoup de mal à faire prendre en compte leur trois ans de thèse comme de l'expérience...

Effectivement, certains thésards (pas seulement en info) sont très nuls, ce qui est totalement inadmissible. Mon expérience personnelle est qu'il n'y en a pas beaucoup plus que des ingénieurs complètements nuls (même en provenance des écoles les plus prestigieuses).

Nous sommes d'accord, un DEA ne sert pas à grand chose après une bonne école d'ingénieur. On peut d'ailleurs se demander qui t'a conseillé d'aller en DEA, vu que le but premier est quand même très largement la recherche.

Ton délire sur les thèses est amusant. Bien entendu, il existe de mauvais labos, mais j'aimerais bien quand même quelques arguments sur "environnement académique chiant, con et hypocrite", parce que vraiment, j'ai beau chercher, je ne vois pas de quoi tu parles. D'autant qu'au niveau enfermement, le privé ridiculise le public. Au risque de paraître extremiste aux yeux de certains, je me permettrai de rappeler que le but d'une entreprise, c'est de faire du fric. Ca n'empêche pas systématiquement de faire des choses intéressantes, mais bon, la liberté est objectivement très inférieure à celle du public, même en tant que thésard.

<<on se croirait presque sous Java>>

Ah le gros piège de base. Mort aux trolls.

Je crois que comme dans beaucoup de grosses boites, il y a des cons et des moins cons. D'un côté des choses comme Squeak, de l'autre une défense complètement acharnée des droits de propriété intellectuelle qui a conduit entre autre à la loi Mickey (cf l'interview de Stallman qui mentionne ça http://lwn.net//2002/features/rms.php3(...) ) qui étend la durée de la protection d'une oeuvre...

J'ai lu quelque part que SUN a aussi des problèmes de ce genre, avec des développeurs qui rêvent de mettre Java vraiment en open-source, et de l'autre des cercles dirigeants qui rêvent d'un monopole SUN à la place du monopole de MS.

Le monde réel est bien compliqué...

Eh, eh... Bon, c'est sûr que le tien rulez plus que le mien (de id), mais bon...

Sinon, je trouve que ça s'améliore, en particulier qu'il y a des discussions un peu moins flamesque qu'avant. Toujours quelques boulettes sur les news acceptées ou sur l'orthographe de ces mêmes news, mais bon globalement, c'est plutôt pas mal. Les XP c'est aussi assez sympa, même si on a une forte tendance à voter selon l'opinion présentée dans un post plutôt qu'en fonction de son intérêt...

On est d'accord, il y a un problème, mais où ? Dans la tête de ceux qui préfèrent gagner 2x dans le privé ou dans celle de deux qui préfèrent gagner x dans le public ? J'ai une réponse, mais je suis sûr que beaucoup de gens ne la partagent pas...

On pourrait aussi se dire que l'état devrait mieux payer ses chercheurs, mais bon, nos deux guignols de candidats principaux ne parlent que de réduction d'impôts ou preque, alors bon...

Ouai, ça dépend ce que t'appelle bien payé.

Je suis Maître de conférences (MdC, ouai, c'est pompeux) à Dauphine. Un Mdc, c'est un mélange d'enseignant et de chercheur. Je suis au 4ème échelon de la classe normale des MdC. On monte les échelons à l'ancienneté (j'ai 31 ans). Mon salaire mensuel net (le brut n'est pas comparable avec les salaires bruts du privé, nous ne payons pas les mêmes charges) hors prime est d'environ 15000 F (disons 2300 euros pour faire rond). J'ai le droit à un mini treizième mois d'environ 7000 F. Je trouve que ce salaire est parfaitement correct. Bien entendu, par rapport à mon niveau d'études, il y a de quoi rigoler. J'ai une thèse en maths appliquées (bac+8, donc) et je suis ancien élève de l'Ecole Normale Supérieure. Mes collègues ont tous des thèses et sortent tous des meilleurs écoles d'ingénieurs (X, mais aussi Centrale, Télécom, etc.).

Les salaires des chercheurs des établissements publics sont tous du même ordre que le mien. Quand on se débrouille bien (bonnes publications en particulier), on peut passer Professeur (sur concours) et le salaire augmente en conséquence. Sauf erreur de ma part, un prof en fin de carrière gagne facilement le double de moi.

Moralité, les salaires ne sont pas extraordinaires, mais on ne mendie pas dans la rue. Par contre, les moyens pour faire de la recherche (achat de matériel, de livres, déplacement dans d'autres labos, etc.) sont très très insuffisants et c'est ça le vrai problème : beaucoup de gens sont tentés par les brevets pour faire vivre leur labo. Personnellement, je vends plutôt de l'expertise, comme ça je reste maître de mes idées. Mais bon, ce n'est pas toujours facile...

C'est marrant cette tendance à qualifier de troll toute discussion. Prosper est une surcouche de seminar, un peu comme LaTeX est une surcouche de TeX. En théorie, en bidouillant prosper, on doit pouvoir retrouver toutes les possibilités de seminar. Dans la pratique, l'intérêt de prosper c'est justement de t'éviter de bidouiller (exactement comme l'intérêt de LaTeX sur TeX), donc, dans la pratique, on ne manipule pas seminar quand on fait du prosper. De fait, certains fonctionnalités de seminar "disparaissent".

Définition complètement fausse. Le partage du temps, c'est le partage du temps, point à la ligne. Le scheduling, c'est l'ordonnancement, c'est-à-dire l'algorithme qui décide dans quel ordre les processus actifs vont être exécutés par le processeur. De plus, une machine mono-processeur actuelle est effectivement multi-tâches, car les entrées-sorties, les calculs, l'affichage, le son, etc. sont chacun géré par des composants différents qui peuvent être actifs en même temps.

C'est étrange comme remarque (je parle des développeurs de Proxy). Franchement, les threads Linux sont en gros des threads posix gérés par le noyau, donc je ne vois pas trop. Il y a bien un truc compliqué au sujet de la gestion des signaux, point sur lequel les threads linux ne respectent pas le standard posix.

La seule idée qui me vient concerne le modèle d'implantation des threads linux : c'est un modèle one-to-one, c'est à dire qu'un thread applicatif correspond à un thread noyau. Ca veut dire qu'avoir 1000 threads dans une application sous linux, ça risque de ramer à mort. Mais il faut être crétin pour avoir 1000 threads dans une application. Ceci étant, certaines implantations des threads sont basées sur des modèles très compliqués many-to-many (cf http://pauillac.inria.fr/~xleroy/linuxthreads/faq.html(...)) qui correspondent en gros à avoir un double ordonnancement, à la fois au niveau utilisateur et au niveau noyau : en gros, un groupe de thread de l'application est représenté par un thread noyau. Ca permet de faire des applications de bourrin, genre 1000 threads, justement.

Le problème, c'est que beaucoup de développeurs pensent que threads => performances, et on arrive à des trucs débiles (toujours les 1000 threads).

Sauf erreur de ma part, prosper ne permet pas d'avoir une version résumée des slides sous forme d'un article dont chaque page contient un ou deux slides en petit. Pour diffuser des copies papier d'un cours, la solution du résumé est vraiment très agréable car elle permet en plus d'insérer des remarques qui n'apparaissent pas sur les slides.

Par contre, tu as parfaitement raison pour la création de styles, prosper est beaucoup plus simple. C'est d'ailleurs pourquoi je conseille (et utilise) prosper pour les "petits" documents.

Et non. J'accepte (comme tout le monde, je pense) deux défitions des logiciels libres. La défition de l'open source (cf http://www.opensource.org/(...)) qui interdit explicitement ce que tu proposes, et la définition de la FSF qui interdit elle aussi ce que tu proposes. Dans la pratique, un logiciel libre peut toujours être obtenu gratuitement, par exemple en copiant une version obtenue officiellement par quelqu'un. Bon, nous sommes d'accord, il faut toujours payer le support, mais bon, il faut aussi payer l'ordinateur, donc...

C'est très facile à utiliser, mais moins puissant que seminar (cf http://www.tug.org/applications/Seminar/(...)). Si tu veux faire une présentation vite fait, utilises prosper. Si tu veux faire un gros document (genre 150 slides), il y a quand même pas mal de choses en plus dans seminar (je sais, prosper est construit sur seminar, mais bon, il cache pas mal de choses).

<<Libre n'implique pas forcément d'être gratuit>>

Si, justement. Ca veut dire que tu peux payer pour obtenir le logiciel, mais que tu peux aussi ne pas payer. Donc, de fait, libre ça implique gratuit. Par contre, tu as parfaitement raison pour l'implication inverse qui est clairement fausse.