boubou a écrit 1384 commentaires

Netscape qui libère Mozilla quand IE a déjà gagné la "bataille des navigateurs"

Peut être, mais le résultat c'est qu'on a maintenant un excellent navigateur libre (ce qui fait deux avec konqueror) et ça, c'est vraiment un grand pas en avant. De plus, Mozilla est beaucoup plus qu'un navigateur, donc c'est la fête. N'oublions pas, par exemple, que bugzilla est une contribution majeure de netscape à l'open source.

Bref, les débats sur les motivations, on s'en branle, honnêtement. Si quelqu'un distribue son code sous GPL, on peut l'intégrer dans d'autres logiciels GPL (des morceaux, par exemple), on peut le porter sur d'autres systèmes, etc. Il n'y aucun point négatif.

De plus, l'expérience montre que le passage en Open Source n'est pas synonyme d'abandon. Par exemple, Tomcat est encore développé par des gens payés par Sun (pas seulement, bien sûr), de même pour OpenOffice.org, pour Axis (par IBM), etc. Si MS passe quelque chose en GPL (personnellement, le media player, ça me plairait bien) j'applaudis à tout rompre.

Très bonne réponse de Guillaume !

Il ne s'agit de parallèliser automatiquement (un problème plus que difficile, en général NP complet dans ses incarnations les plus simples), mais bien d'offrir un support qui permet d'équilibrer la charge. Sinon, Zyvad, appeler des objets distants est en pratique quelque chose de très difficile. Bien entendu, la partie simple (disons RMI en Java) est conceptuellement et techniquement assez faicle. Le problème est que la réalité est plus complexe. Par exemple, il faut trouver les objets (d'où les annuaires JNDI), il faut gérer des transactions, éventuellement réparties (d'où JTA et le support des transactions dans les EJB), il faut monter en charge (d'où les state less Session Bean et les Message Driven Bean), etc.

Si tu veux continuer la discussion, on peut faire ça par mail !

Tout pareil pour JNDI. Il manquait des providers dans les premières versions, mais bon, c'est extensible et plutôt cool.

le système Servlet/EJB est le coeur de J2EE

Ouai, sauf que tu disais EJB. D'ailleurs ton premier post faisait déjà la confusion entre deux choses qui n'ont pas beaucoup en commun, les Servlets (et les JSP) d'un côté, les EJB de l'autre. D'autre part, entre le J2SE 1.4 et J2EE 1.4 (version beta) tu auras comme différence (en plus des Servlet/JSP/EJB) toute la partie web services (SOAP etc.), la partie messaging (JMS qui est elle aussi un très gros morceau), JMX, JTA, etc.

Bref, tu peux t'en tirer en amalgamant Servlet/JSP/EJB dans un même sac et là, je suis d'accord, c'est le coeur de la technologie, cependant ça reste tandencieux. De plus, vue la mode actuelle des web services, tu te retrouves maintenant avec un gros morceau de plus dans J2EE.

Que du point de vue marketing, les serveurs d'applications se battent sur les EJB est logique, c'est la partie la plus visible et la plus concurrentielle. De la à ne voir qu'elle, il y a un grand pas.

Ce qui est sûr ce que c'est faux. Ils n'ont pas payé, ils ont demandé un délais pour répondre à SCO. Ils doivent répondre pour aujourdh'ui !

mais la technologie existait

Oui, oui, oui. 1984 pour les premiers filesystems resistant à la fragmentation.

Ceci étant, quand tu vois l'algorithme de mise en page actuel de Word, qui donne toujours des résultats hideux alors que TeX fait mille fois mieux depuis 15 ans...

Je constate aussi que tu ne m'as toujours pas dit quel etait donc ce probleme avec NTFS.

Ce n'est pas documenté et c'est donc la merde pour l'utiliser en conjonction avec Linux. Ok, ce n'est pas une critique technique, mais c'est chiant quand même.

Vastes questions !

Quelques réponses, nécessairement basiques :

• Tomcat est l'implémentation de référence (i.e. le modèle) de deux spécifications de SUN, les servlets et les JSP (Java Server Page) :
  
  
  
  • les servlets sont une version Java des CGI, c'est-à-dire les extensions côtés serveur d'un serveur web
  
  
  • les JSP sont une sorte de version Java de PHP, à savoir une façon d'insérer du code Java dans des pages web afin de les rendre dynamiques (accès à une base de données, calculs, etc.)
  
  
  
  Tu ajoutes en général Tomcat à apache. Apache se charge des pages statiques et Tomcat de la partie JSP/Servlet. Tomcat est open source et produit par la fondation apache.


• Les Entreprise Java Beans sont une spécification de SUN pour des composants logiciels côté serveur. Il est très difficile d'en donner une description rapide et simple à la fois. L'idée de base est de proposer un environnement logiciel (le serveur d'application) implémentant de nombreux services (gestion des threads, de la connexion à une base de données, des transactions, etc.) puis de permettre l'insertion de morceaux de code (les Beans) dans cet environnement, de la façon la plus simple possible. Ca apporte pas mal de chose, comme par exemple :
  
  
  
  • les EntityBeans (une des catégories de composant) permettent par exemple de fabriquer des données de façon objet tout en ayant une persistance automatique, c'est-à-dire une sauvegarde transparente des objets en question dans une base de données. Normalement tu n'as plus à écrire de JDBC (l'api Java pour attaquer les bases de données).
  
  
  • l'aspect transactionnel (le fait qu'une opération complexe semble être atomique, c'est-à-dire semble s'exécuter comme une seule instruction pour les autres opérations du système) est géré de façon très souple et très automatique dans un serveur d'EJB ce qui est un apport majeur.
  
  


• Globalement, l'idée de tout ce bordel est de simplifier la mise en oeuvre d'applications réparties, c'est-à-dire implémentées par plusieurs machines qui se partagent le boulot. On peut bien sûr faire autrement que d'utiliser ces mécanismes, mais franchement, ça devient vite très difficile. J'ai un cours sur les systèmes répartis (http://apiacoa.org/teaching/distributed/(...) ) qui peut te donner une vague idée des difficultés.


• Finalement, tu peux lire le tutoriel de sun ( http://java.sun.com/j2ee/tutorial/1_3-fcs/(...) ) qui te donnera quelques idées sur J2EE, mais franchement, ça demande beaucoup de lecture...

Merci pour l'exemple. En fait, Guillaume a formellement raison au sens ou on doit écrire l'aspect jointure à la main. C'est beaucoup plus simple que d'utiliser JDBC, mais ça reste un peu SQL sur les bords.

Bien entendu, si tu n'actives pas les options d'optimisation des communications locales. Les serveurs EJB ont tous ce genre d'option (qui sont d'ailleurs en désaccord avec la norme, mais bon) qui permettent de se passer des interfaces locales du point de vue formel, mais en utilisant le même mécanisme de façon transparente (enfin presque, restent les problèmes de sémantique lié au mode de passage des paramètres objets).

ObjectKey

Effectivement. Cf cependant plus haut pour les classes à coder à la main.

oui bien sur, si le code SQL généré me convenait ca serait trés bien, mais je pense que ce n'est pas assez optimisé

Les résultats de bench semblent montrer le contraire.

il me semble que le code généré ne fait pas de jointures tout seul par exemple...

En effet, avec les EJB 1.x. Mais tu sais, les serveurs modernes implémentent les EJB 2.0 et sont en route pour les EJB 2.1. Je suis d'accord avec le fait que CMP 1.1 c'est pas génial. Mais se baser là dessus pour critiquer le J2EE actuel, c'est comme critiquer XP en se basant sur le DOS, c'est n'importe quoi.

ha... je demande confirmation, tu as un lien?

Pour les perfs voir les benchs déjà cités qui montrent que l'introduction de l'interface local ne change pas grand chose? D'autre part, Fleury a déjà dit dans plusieurs papiers et docs que JBoss optimise les appels locaux.

ha... moi avoir 4 ou 5 classes par objet métier, quand tu as un modèle de 300 objets, je trouve ca un peu génant... quand tu vois que tu n'en as qu'une à coder avec JDO...

Argh ! Utilise donc XDoclet, malheureux ! Une seule classe à coder par Bean. Faux vraiment être un troll pour coder ça à la main.

De toute façon, en pratique, tout le monde fait du Session Bean + JDBC, aprés s'être cassé les dents sur les Entity Beans...

Fleury dit exactement le contraire, et j'ai plutôt tendance à le croire lui, désolé.

je ne me plains pas que le SQL soit généré tout seul, je me plains que le SQL généré tout seul soit pourri... et qu'en conséquence on soit obligé de tout coder dans les finders...

Un exemple serait le bienvenu...

mais tu as toujours au moins 3 classes par EJB, voir 4 ou 5

Pourrais-tu développer, ça ne me semble pas très clair, ton truc. Sur le client, tu as le Home et le Remote, sur le serveur le Bean lui-même plus de l'enrobage propre au serveur.

Sans parler des requêtes SQL générées dans les CMP, où on n'a pas de contrôle, on est obligé de coder les méthodes find en SQL...

Ba oui, c'est le but de CMP. Si tu veux du contrôle tu fais tu BMP. Sinon, les find sont codés en EJBQL, pas en SQL.

Ce qui fait le coeur de J2EE c'est bel et bien les EJB

Absolument pas. Il n'y a pas de coeur J2EE, l'intérêt c'est justement l'ensemble, à savoir les servlets, les JSP, JNDI, etc. Bien entendu, le J2SE est toujours une version en avance par rapport au J2EE donc si tu compares J2SE 1.4 à J2EE 1.3, il n'y a plus grand chose de spécifique à J2EE (excepté Servlet/JSP/EJB). Par contre, tout l'aspect web services est spécifique à J2EE 1.4. Comme les specs java sont modulaires, tu peux bien sûr implémenter seulement des morceaux, il n'en reste pas moins que réduire J2EE au morceau le plus compliqué (les EJB), c'est n'importe quoi.

tu n'es pas schématique, tu es faux. Exemples :

les Servlet ne sont pas des beans et sont un moyen très efficace d'implémenter des CGI. Ils font effectivement partie de J2EE, comme les EJB.

Sun a rajouté la possibilité de faire un appel local (en passant donc juste par la mémoire) entre SessionBeans et EntityBeans (ce qui revient à admettre de facto que le pattern Session Facade est la plus réaliste implémentation J2EE)

Bof. L'appel local, c'est simplement la reconnaissance officielle par Sun de ce que font les fabriquants de serveur EJB depuis des années, à savoir optimiser les appels entre EJB. La SessionFacade est un moyen d'optimiser (entre autre) les appels entre la couche de présentation et la couche business. Elle consiste en fait à bien programmer la séparation en couche dans le cas où il n'y a pas collocation de la couche de présentation et de la couche business. Tu peux bien sûr utiliser les interfaces locales pour accéder de la couche web à la couche EJB, mais c'est assez débile car ça te bloque dans l'évolution du système : tu ne pourras plus mettre le serveur d'EJB sur une machine différente du serveur JSP/Servlet.

Quand aux implémentations BMP et CMP, elle s'avèrent être à peu près aussi mauvaises l'une que l'autre.

C'est-à-dire ? Le surcout de l'architecture EJB vient en gros exclusivement de l'aspect RMI. La persistence ne pose en général pas de problème.

Je crois que tu passes complètement à côté de J2EE. Le but des serveurs d'applications n'est pas de faire du RAD, mais simplement de jouer le rôle de middleware, c'est-à-dire en gros de mécanisme d'intégration simplifié. L'intérêt de J2EE, c'est par exemple :

- de simplifier radicalement la gestion des transactions (avec prise de décision au déploiement)
- de simplifier radicalement les problèmes de (re)démarrage d'un service avec le management automatique des instances de Bean
- de simplifier radicalement les problèmes de persistance avec les entity beans
- etc.

Une des idées principales est de déplacer certaines décisions depuis le code vers des descripteurs de déploiement ce qui clarifie grandement le code.

Les cartes ATI et NVidia ont effectivement des modules noyaux, mais tu n'es pas obligé de les utiliser pour l'affichage 2D.

Ton argumentation sur l'effet d'un plantage complet par rapport à un plantage d'X est amusant. Quand X crashe sans faire planter le noyau, les applications peuvent recevoir un signal et sauvegarder leur contexte, ce qui peut limiter la casse. Ca m'est déjà arrivé avec emacs par exemple. D'autre part, que les dommages soient limités ou non, ils sont supérieurs lors d'un crash noyau par rapport à un crash de X. De fait, le noyau linux est réputé pour sa simplicité, de très nombreuses choses étant implémentées en dehors du noyau. Mes lectures concernant windows me font penser que beaucoup plus de choses tournent en mode noyau.

Sinon, je ne connaissais pas le coup du CreateDesktop(). Si c'est aussi simple d'utilisation qu'un chroot, ça règle ne effet le problème du trust entre les fenêtres. Cependant, est ce que cela (ou autre chose) permet de faire l'équivalent d'un chroot ou d'un jail ?

C'est noté pour la stack. Il me semble que tu as affirmé à plusieurs reprises sur ce forum qu'il n'y avait aucun rapport entre NT et 95, et d'un seul coup tu nous dis que tu n'as pas accès au code de 95. Serais-tu donc un pipoteur ?

Pour les drivers graphiques, c'est simple, l'écrasante majorité des cartes graphiques sous linux ne nécessite pas de module noyau. Le support noyau est minimal (en gros il permet d'envoyer des commandes à la carte, par exemple sur le bus agp) et le driver de la carte graphique s'exécute en mode utilisateur. De ce fait, en général quand X plante, ce qui peut parfois arriver, le noyau ne plante pas (en général). J'ai lu dans divers journaux informatiques (pas très sérieux comme source, je l'admets) que les drives de cartes graphiques s'exécutent entièrement en mode noyau sous Windows. C'est une source d'instabilité notoire. Tu peux ne pas me croire, mais ma machine plante très souvent sous XP et jamais sous linux. Je suis presque sûr que cela vient des drivers NVidia car quand je fais des mises à jour, les plantages changent. Le truc fun, c'est que ça plante assez brutalement, genre BSOD....

Nous sommes d'accord sur le fait que l'interprétation de code n'est pas un problème du noyau Windows. Cependant, comme tu l'as dit plusieurs fois ici, et comme l'affirme régulièrement MS, livrer Windows sans IE est impossible. Je te renvoie aux derniers numéros de MISC (5 par exemple) pour une description des vulnérabilités monstrueuses d'IE, en général liées à de graves erreurs de conceptions.

Concernant le trust entre les fenêtres, le problème est bien entendu qu'il faut suivre des "guidelines". L'expérience montre que les gens ne le font pas et qu'il est donc très important que le système empêche les programmeurs de faire des conneries. Les mécanismes de type chroot ou jail permettent de lancer un soft suid root de façon à limiter les problèmes. Je ne pense pas qu'on puisse faire la même chose pour le trust entre fenêtre, i.e. lancer une appli fenêtrée en bloquant le trust. Il y a donc bien un risque (même minime) lié à un mécanisme qui est peut être pratique mais qui n'est pas bien conçu du point de vue de la sécurité.

Je remarque que tu ne réponds pas aux éléments suivants :

- stacks TCP/IP identiques (de l'extérieur hein, on n'a pas vu le code) entre NT et 95, alors que tu prétends qu'il n'y a rien un commun entre les deux systèmes

- drivers graphiques entièrement en mode noyau sous windows alors qu'une infime partie est en mode noyau sous linux (et encore, seulement pour certaines cartes graphiques) : je sais bien que ça n'a rien à voir avec les virus, mais c'est un design qui n'est pas sans conséquence sur la stabilité du système

- interprétation de code non contrôlé

En général, tu passes ton temps à nous dire que Windows est au moins aussi bien conçu que Linux et même que ça tourne mieux, etc. etc. Honnêtement, tu sais bien que sur certains points ce n'est pas vrai comme l'ont montré certains bugs de sécurité graves liés justement à des défauts de conception. Il me semble que le trust entre les fenêtres a été déjà été utilisé dans des softs d'intrusion (je ne connais pas des détails). L'interprétation de code non contrôlé est la base d'un grand nombre de vers Windows et c'est un montrueux défaut de conception peut être pas du noyau mais de Windows qui constitue de fait un noyau plus un ensemble d'applications totalements indissociables de celui-ci (comme ie).

Bref.

vu qu'on ne t'oblige pas a l'utiliser

Ah, ah, ah, la meilleure de la news. Mais bien sûr que si, dans les faits de très nombreuses institutions, entreprises, etc. t'obligent à utiliser les produits de MS, comme word ou ie. Sors ta tête de ton terrier, mon petit.

J'ai écris basé sur les concepts de VMS et tu traduis en tiré de VMS. Pas mal pour l'objectivité. Le propos de mon post était simplement de montrer le ridicule des propos de Ballmer, pas de dire que NT est construit à partir du code de VMS.

stack TCP/IP de BSD

Fyodor indique que les stacks TCP/IP de 95 et de NT sont très très senblables. Quand tu réponds plus haut à mon post, tu racontes des choses peut être vraie (je n'en ai rien à foutre, pour être honnête) concernant les comparaisons des stacks de freeBSD et de NT. Si tu savais lire, tu répondrais à la remarque et tu n'accuserais pas tes contradicteurs de méfaits imaginaires.

Windows a une caracteristique technique qui le rend plus permeable aux virus que Linux (j'ai pourtant demande ce que c'etait, toujours pas de reponse)

Je ne sais pas pour les virus, mais le simple fait que les drivers de carte graphique tournent en mode noyau me semble bien dangereux (et d'ailleurs ma machine plante souvent sous XP et je soupçonne les drivers NVidia). Sous Linux, la partie du code de X qui tourne en mode noyau est beaucoup plus petite que celle de windows (en tout cas, c'est ce que j'ai lu sous la plume de spécialiste), ce qui limite les risques.

Il me semble aussi qu'il y a une histoire de trust entre les fenêtres, i.e. une application qui a le droit d'ouvrir une fenêtre peut transmettre des ordres aux autres applications qui ont des fenêtres ouvertes. Je ne suis pas sûr de ce point, mais dans ta grande honnêteté intellectuelle, tu te feras un plaisir de me corriger.

Enfin, le nombre d'applications qui ont des possibilités d'interprétation de code non contrôlé (cf les différents numéros de MISC sur les problèmes d'IE et d'outlook) montrent que les ingénieurs de MS n'ont pas une culture de la sécurité.

Le niveau de vie dans de nombreux pays d'Asie est assez élevé pour permettre l'achat d'un ordinateur avec un système d'exploitation gratuit ou presque. De plus, les acahts en commun pour un cybercafé sont aussi tout à fait possible. L'Asie ce ne sont pas seulement les paysans de Chine, mais aussi les cadres de Shangai, ceux de Bangkok, de Hong Kong, etc. Les gens qui ont les moyens de se payer un ordinateur ont aussi ceux de se payer des systèmes d'exploitation vendus à des prix raisonnables, ce qui n'est pas le cas de Windows.

Moi pas comprendre. Le prix du PC est élevé parce que Windows est vendu cher (merci Nÿco) ? Mais c'est n'importe quoi, le prix du PC c'est celui du hardware ! Donc tu voulais dire le prix du PC+windows est énorme comparé au salaire, c'est ça ? Mais c'est faux à HK par exemple. Les gens gagnent bien leur vie à HK (enfin, certains).

Et très différente de celle de windows 95, n'est-ce pas ? C'est marrant, parce que tout le monde n'est pas d'accord avec cette dernière affirmation, en particulier des gens qui ne sont pas de rigolos, comme Fyodor (cf http://www.nmap.org/nmap/nmap-fingerprinting-article.html(...) ), l'auteur de nmap.

pays ou le prix d'un PC est enorme compare au salaire Pas tant que ça (cf Hong Kong, par exemple, qui a un niveau de vie très élevé). De plus, windows aussi coûte très cher...