François B. a écrit 363 commentaires

Si tu as à ta disposition une implémentation des classes de la version 1.4 du SDK, ça ne devrait normalement pas poser de problème. C'est ce qui est fait par exemple avec Jikes qui n'est qu'un compilateur ; comme il ne contient pas d'implémentation des classes de base, il faut lui spécifier où les trouver (en ligne de commande ou par la variable d'environnement JIKEPATH).

Maintenant, il faut savoir qu'il existe des compilateurs Java qui ne sont pas capables d'utiliser d'autres classes de base que celles pour lesquelles ils ont été prévus. Cela t'empêche alors d'imposer tes propres classes.

Mais je ne connais absolument pas Manta, alors je ne peux pas dire ce qu'il en est dans ce cas ...

Non ! Il ne faut pas confondre version 1.1 du LANGAGE Java, et version 1.1 de la PLATEFORME Java.
Je dirais même, pour être complet, qu'il ne faut pas non plus confondre avec la machine virtuelle Java et son bytecode associé.

Je vais donc résumer rapidement les 3 entités :
- le langage Java est l'ensemble de règles syntaxiques à respecter pour coder en Java. Pour simplifier, il s'agit du format du fichier source.
- la plateforme Java est l'ensemble des classes qui sont utilisables par une application Java (application indépendante, applet, servlet, JSP, JavaBean, EJB ...). Dans cet ensemble, il y en a qui sont obligatoires (dans les sous paquets de java.*) et d'autres qui sont optionnels (les autres paquets).
- le bytecode Java est le format de fichier utilisé pour le code précompilé. Il est ensuite utilisé par la JVM, ou machine virtuelle Java. Il faut bien comprendre le du bytecode n'est pas forcément généré à partir de code Java (j'ai entendu parler d'un compilateur de bytecode à partir d'Ada).

Actuellement, la version du langage est la 1.1. Cette version a été introduite dans le JDK1.1 (d'où la confusion possible ...)
La version de la plateforme est la 1.4 pour la version standard J2SE (implémentation de référence béta pour l'instant) et la 1.3 pour la version entreprise J2EE.
La version du bytecode a changé à chaque version de JDK/SDK. On peut s'en convaincre en regardant l'option -target de javac qui peut prendre les valeurs 1.[1234].

En ce qui nous concerne dans cette nouvelle, il s'agit de la version du langage qui est importante. Hors, la 1.1 est la dernière, bien qu'elle existe depuis le JDK1.1 ...

Il y a quelques temps (environ 3 semaines), je suis allé à une présentation de la BLR en vue de l'ouverture d'un opérateur sur Nancy (je ne me rappelle plus lequel).

En revanche, ce que je me rappelle très bien, c'est que les frais d'installations sont supérieurs à 10000F et l'abonnement à partir de 2000F/mois ...

Personnellement, je ne veux plus en entendre parler !

Hum, il faudrait peut-être dire que segfault est un site satirique ...

Plutôt que script-kiddy, je préfère le terme que j'ai vu utilisé dans une des publications de ITWorld : script-kidiot
Je trouve que ça résume bien toute la bêtise requise pour ce genre d'action : aller sur un site spécialisé dans le piratage, télécharger un script et lancer au petit bonheur la chance. Pas besoin d'être un as, contrairement à ce qu'essaye de faire croire l'avocat (il cherche simplement à lui trouver du travail pour après, vous ne pensez pas ?)

A la fin de la page dont tu donnes l'adresse, il y a un lien vers http://www.qualys.com/alert/remoteshell.html(...) qui est la société qui a "découvert" le truc.

Après lecture, il semblerait que ça soit simplement des exécutables au format ELF (format standard sous Linux pour ceux qui ne connaissent pas) qui seraient la cible. Il serait diséminé dans la nature par mail avec exécutable attaché. Qualys ne parle pas de réplication autonome d'une machine à une autre (ça ne serait alors pas un ver, mais rien n'empèche un ver de répliquer des binaires infectés).

L'exécutable reste totalement fonctionnel, mais il y a un blok de 4K en plus pour caser les 2,8K de code du virus. Il essaye de se répliquer dans le répertoire courant et dans /bin. Il ne semble pas qu'il cherche à obtenir des permissions supplémentaires (il n'a que les droit de l'utilisateur qui a lancé l'exécutable infecté). Il n'essaye pas non plus à se cacher puisque la taille et la date de modification du fichier sont modifiées.

Une fois infectée, la machine envoi une requête HTTP GET sur le port 80 d'un serveur en Grande Bretagne (orinoco.portland.co.uk). Le port 5503 est également ouvert pour obtenir un shell sur la machine infectée.

La société Qualys pense que ce cheval de Troie/virus sera utilisé afin de lancer des DDoS.

Je me rappelle avoir lu il y a un certain temps dans un draft de SVG que leur but était d'utiliser du XML sans pour autant faire exploser la taille des fichiers. Ils ont donc cherché à passer le maximum d'informations tout en restant souple et XML, mais ce n'est plus tellement human readable ...

Il existe une option --enable-svg pour la configuration de mozilla. En revanche, je ne sais pas quel est sont état d'avancement (je n'ai pas de SVG sous la main). Vu sur http://webtools.mozilla.org/build/config.cgi(...)

Sinon Sketch est capable de lire et d'écrire des SVG : http://sketch.sourceforge.net/features.html(...) dans la sections pugins.

Voila, ce sont juste mes 0.02€. J'attend avec impatience que ça soit utilisé plus largement plutôt que les "webmasters" qui utilisent des JPEG avec tous les artefacts de compression lorsqu'on veut présenter un graphique (ou les GIF pas libres et les PNG avec un transparent noir chez certains navigateurs).

Conseiller les entreprises de chiffrer les mails sensibles est une première étape. Mais ce qui est vraiment important, c'est de leur expliquer comment le faire de manière sécurisée.

En effet, beaucoup d'éditeurs se sont déjà lancés sur ce marché qui sera certainement bientôt très porteur. Mais il faut voir comment c'est fait ... Les programmes sont bâclés pour sortir plus vite (ce qui est un comble dans le domaine de la sécurité), les "experts" qui certifient le logiciel sont souvent des juristes (pour anticiper un éventuel jugement ?), et certains placeraient des portes dérobées (je laisse au conditionnel parce que je n'ai aucune preuve, mais il suffit de se rappeler l'affaire de PGP pour se convaincre).

La deuxième étape sera donc d'expliquer que des outils ouverts sont certainement plus sûrs que leurs "équivalents" propriétaires. De même, il faut leur expliquer l'importance de la protection de la clef privée (j'en ai déjà vu trainer dans un "disque partagé" sans protection sur un parc de Windows !). Enfin, il faudra les convaincre qu'il ne suffit pas de chiffrer pour être sûr ... et que la paranoia est peut-être la seule défense contre une faille potentielle : il faut toujours remettre en cause une installation de sécurité.

D'après la FHS, /opt n'est là que parce que ça existe traditionnellement sur les Unices ... Il est conseillé de n'y mettre que les logiciels qui ne pourraient pas fonctionner ailleurs (chemins en dur) ou des logiciels optionnels (donc pas dans le PATH par défaut). Maintenant, toujours d'après la FHS, /opt/{bin,lib,man,...} n'est qu'un bricolage facultatif pour les administrateurs qui n'ont pas trop envie de se casser la tête ! Sur mes machines, ne vont dans /opt que les logiciels qui ne peuvent pas coexister : différentes machines virtuelles Java, des versions différentes d'extensions standard ... Un simple script en perl+bash me modifie les variables d'environnement pour choisir parmi ces versions.

Personnellement, je verrais plutôt KDE (ou GNOME, ne soyons pas sectaires ;-)) dans /usr parce qu'il est en général inclu dans la distribution utilisée. C'est alors au système de paquets de la distribution de gérer tous les fichiers qui doivent aller ailleurs (/etc, /dev, /tmp?).

En revanche, si la distribution ne contient pas de paquet pour le logiciel, alors il doit aller dans /usr/local (contrairement à ce que disent les magazines : "faites simplement ./configure && make && make install", /usr étant souvent la destination par défaut).

Mieux, les logiciels compilés par l'utilisateur, ou installés depuis des binaires bruts (hors paquet) seraient encore mieux dans /usr/local/stow. Ensuite, un petit stow nom_du_répertoire et hop plein de liens sont créé dans les sous répertoires d'/usr/local.

On ne veut plus du logiciel, un petit stow --delete nom_du_répertoire && rm -rf nom_du_répertoire et il disparait sans laisser de trace ... Mais dans ce cas, il ne faut pas oublier un ./configure --prefix=/usr/local/stow/nom_du_répertoire.

Page de stow sur freshmeat : http://freshmeat.net/projects/gnustow/(...)
Homepage de stow : http://www.gnu.org/software/stow/(...)
Téléchargement : ftp://ftp.gnu.org/gnu/stow/(...)
stow nécessite perl 4 ou 5 pour fonctionner.

Oups ... je suis désolé ! Je ne cherchais absolument pas à dénigrer ton travail. En fait, je me basais sur une discussion qui a eu lieu ici où quelqu'un disait qu'il n'y aurait jamais de logiciel libre qui gèrerait la carte vitale, biscote ils ne veulent pas qu'on voit comment ça marche. J'ai sûrement confusionné des informations de droite et de gauche pour finir par générer des conneries ...

Mais bon, je vais essayer de me rattraper aux branches : tu dis qu'un soft utilisant la carte doit être certifié ... mais ça coûte combien la certification ? Là je crois qu'on a une explication au pourquoi il n'y a pas de logiciel libre chez les médecins.

Bien sûr, dans ce cas, 1 octet par caractère n'est plus suffisant. De plus, ça ne l'est déjà pas pour certains alphabets (je pense en particulier aux langues d'Asie).

En ce qui concerne les URL, il faudrait utiliser les tables de caractères UNICODE. Tu trouveras plus d'informations là : http://unicode.org/unicode/standard/WhatIsUnicode.html(...)

Dans le troisième cas, j'ajouterais les mairies, les écoles et les associations. Ce sont en tout cas des exemples qui ont été vécus par le Mirabellug (Nancy, Meurthe-et-Moselle).

Sinon, c'est vrai qu'il est très difficile de parler le soir ...

En ce qui concerne les médecins, tant que les cartes vitales ne seront pas suportées sur autre chose que Windows et MacOS, les autres logiciels ne suivront pas !

Le principal problème dans ce cas là est que ce sont les constructeurs de matériel (les lecteurs de cartes) qui ne veulent pas divulguer les spécifications du lecteur ni déveloper un pilote. Ce serait pour eux une perte du nombre de ventes sur les autres systèmes ...

Sinon, en alternative à DirectX, je fais confiance à SDL, OpenGL et consorts. D'ailleurs, John Carmack semble être également confiant au sujet des ports de jeux grâce à ça. Un extrait d'interview est paru sur http://linuxgames.com(...) , puis taper "carmack directx opengl" dans le champ recherche (je n'ai pas réussi à trouver une URL directe).

Oui, bien sûr, il est contre productif de dire des conneries. Mais dans ce dernier passage, MS dit simplement que des décideurs auraient entendu dire que NT n'est pas évolutif (je n'arrive pas à traduire correctement scalable, désolé).

Mais cette affirmation ne veut rien dire : dans quel domaine ? quelles applications ? Dans tous les cas, il existe des solutions, que ce soit avec NT ou Linux. Mais il faut aussi prendre en considération les coûts, le temps, et le résultat. Personnellement, chaque fois que j'utilise http://google.com(...) , c'est tout juste si je n'écrase pas une larme tellement c'est beau, rapide et précis, et tout ça avec un cluster sous Linux ;-)

En effet, le *.doc que tu passes est l'exemple classique du FUD de Microsoft. Ils commencent fort en plus : ils mélangent free = gratuit et free = libre dès le début (première phrase : Despite popular belief in the retail and hospitality markets, the Linux operating system is not free).

Le plus important à mon avis est donc, chacun à son niveau, d'essayer de contrer les dires calomnieux de Microsoft plutôt que de s'écharper ici ... Je sais que certains aiment pratiquer le lancer d'êtres fantastiques poilus (des trolls je crois que ça s'appelle), mais ce n'est pas ça qui va faire avancer le schmillblick !

Pour ceux qui ne seraient pas sûr des arguments qu'ils peuvent utiliser pour essayer de défaire l'endoctrinement de MS, un petit tour par http://www.gnu.org/philosophy/philosophy.fr.html#AboutFreeSoftware(...) s'impose ...

Vu dans les Debian Weekly News d'hier : http://www.debian.org/News/weekly/2001/20/(...)

Debian for professionals. The German computer magazine c't has published a survey in their 17th issue which compares the use of various Linux distributions by different types of users in Germany. One result of the study was the fact that the more people know about Linux the more they use Debian in favour of other distributions like Mandrake, SuSE or RedHat. 28 percent of people with more than five years Linux experience prefer Debian, though only 3 percent of all newbies use it.

CQFD ! (et a dans 3 ans ;-)) De plus, je ne regrette absoluement pas d'avoir été bizuthé à la Slackware ...

Non, tu n'y es pas : c'est un plagia d'Alan Cox quand il s'est penché sur Nautilus ...
La nouvelle est passée ici : http://linuxfr.org/2001/08/26/4667,0,1,0,0.php3(...)

Non, en effet, Fabien n'a pas de rapport (officiel, même s'il a essayé ;-)) avec le Graoulug. En revanche, il est le président du Mirabellug ... et c'est de ça que parlait le premier anonyme !

François (membre du Mirabellug aussi)

je sens que je vais retourner dormir moi ...

Voilà ce que j'ai relevé avant de laisser tomber :

- dans l'article, il est dit que les BDD ouvertes n'ont pas de système de réplication. MySQL en a un ... (je ne sais pas pour pgSQL)

- dans l'article, l'auteur pense que les gentils de Nusphere se font embêter par les méchants de MySQL AB ... En fait, Nusphere a développé une extension a MySQL, qui est développé par MySQL AB. Il semblerait qu'en plus il y ait des problèmes de marques déposées. Une news est déjà passée là-dessus ici http://linuxfr.org/2001/07/12/4222,0,0,0,0.php3(...)

Devant de telles erreurs, je n'ai pas lu plus en avant. Comme souvent "ZDnet, parce que ça ne vaut rien" !

Justement le concept du Web Service (tout à fait contestable d'ailleurs) est de jouer la carte de la simplicité et de donner un accès à des fonctionnalités avancées via des requêtes HTTP toutes bêtes.

Ce n'est pas toujours possible : si la mise à jour des données passe par la lecture d'un nombre important de fichiers, l'accès direct aux EJB est obligatoire. Dans ce cas, l'utilisateur ne voit pas cette interface, seul l'administrateur de l'appli l'utilise. Et je ne vois pas pourquoi ce type d'appication ne pourrait pas être appelée Web services (c'est peut-être aussi un problème de définition ...)

Mais pour résumer, oui on peut comparer PHP avec les Web Services de Microsoft et/ou les solutions Web utilisant J2EE

Et non on ne peut pas. Je ne connais pas .net, mais en ce qui concerne le J2EE, c'est beaucoup plus que de se placer derrière une URL, ce que fait PHP uniquement (bon, c'est vrai, on peut faire une appli standalone en PHP, mais autant la faire en PERL à ce moment là).

En effet, sur une application tournant sur J2EE, l'accès web n'est pas le seul (Servlet, JSP, Jumpstart ...), on peut également communiquer par le biais des bus objets (CORBA, RMI ...), par messages (JMS ...), par répertoires (JNDI ...) voire directement avec les objets de l'aplication (Entity EJB).

Réfuter ces points serait vraiment cacher la partie immergée de l'iceberg. Il est vrai que l'utilisateur lambda ou le non-informaticien de formation converti "expert Java" en 15 jours ne connait pas cela, mais ça existe. Devoir les réimplémenter dans le cas d'une programmation en PHP serait monstrueux et fastidieux. Enfin, il n'est pas nécessaire d'acheter des environnements J2EE extrèmement coûteux car il existe des solutions libres (jBoss, Enhydra ...)

Donc si le but est simplement de faire quelque chose de réalisable en PHP, alors pourquoi ne pas le faire en PHP ? C'est possible, alors allons y. En revanche, dans le cas d'une grosse application qui doit posséder d'autres points d'entrées que HTTP, alors le J2EE est pour moi incontournable (peut-être aussi .net si quelqu'un a le courage d'essayer de me montrer ses points forts face au J2EE).

Ou pour pouvoir lire nos DVDs achetés légalement sur une machine trop limite pour pouvoir décoder à la volée ... ;-)

Bof ... tant que ça marche, les éditeurs d'"anti-virus" sont contents ! Faut pas chercher plus loin :-/