Miair Patreau a écrit 191 commentaires

>C'est vrai bloquer un site web, qui servira a deposer des nouveaux brevets n'est pas mieux que de tuer des gens (par des guerres ou revenrsement de pouvoir, pasque les mechants ils essaient d'utiliser des medicaments generiques), ou en laisser crever...
Plutôt d'accord. Quand on dit "ça vaut pas mieux," ce n'est généralement qu'une façon de parler. Toujours est-il que cette idée reste du côté de la balance qui me paraît mauvais.

>Certes c'est pas la meilleure méthode, mais depuis le temps que ce bat ce genre d'association, ou les pays (generalement pauvres), aupres d'instances internationales pour obtenir, des petits droits qui ne resterons au plus qu'1 an ou 2...
Ce n'est pas que ce n'est pas la meilleure méthode, c'est que ce n'est même pas une méthode. Ça fera seulement savoir au webmestre qu'un bon paquet d'internautes n'aiment pas cette institution. Ce n'est pas un petit plus dans le bon sens pour aider ceux qui en ont besoin, c'est faire chier des gens et rien d'autre, une espèce de vengeance. (et je n'aborde pas de problème légal ou moral)

>Lorsque les brevets logiciels seront passé en europe, et que la LEN entrera en application, ca ne sera meme plus la peine de compter sur ce genre de site...
Pas forcément faux, mais si tu veux dire que c'est maintenant ou jamais, il me semble que tu t'avances. Si les brevets logiciels et la LEN se mettent à casser trop vite toute forme de communication, ça pourrait bien conduire à leur annulation. Difficile de savoir.

D'accord. Mais bien que cela ne soit probablement pas illégal, (pas de procès d'intention,) je pense que ça ne justifie pas d'attaquer délibérément un site web (car c'est bien la finalité de la chose une fois faite en groupe, de fait.)

Avant tout, J2EE peut être grossièrement résumé en disant que c'est une spécification très détaillée de serveur d'application (fait pour fonctionner en java.)

Qui dit "serveur d'application" dit "logiciel serveur" : on ne "voit" pas tourner J2EE (au plus il affichera de temps en temps ce qui se passe sur le terminal texte depuis lequel il a été lancé.) Mais globalement on ne voit pas plus sa présence qu'on ne voit celle de sshd ou ftpd. C'est pas bien grave vu qu'en général on est censé faire tourner ça sur un monstre de calcul octoprocesseur branché sur le réseau d'entreprise, et auquel c'est tout juste si on a laissé un clavier et un écran en mode texte (c'est pas que c'est nécessaire, mais c'est l'utilisation courante, quoi...)

Par conséquent, à quoi ça ressemble... À tous les programmes qui utilisent les services du serveur, tout simplement. Dans la mesure où on peut s'en servir comme serveur d'application web (voire même serveur web aussi,) le fameux programme en question peut être un simple navigateur. Mais dans la mesure où le principe de J2EE c'est d'utiliser des EJB, et que le principe des EJB, c'est de les filer aux programmes qui en ont besoin pour qu'ils discutent directement avec le serveur pour faire tel ou tel traitement de l'information, ben... N'importe quel genre de programme peut interagir (facilement, je veux dire, que ça prend pas des plombes à programmer,) avec un serveur d'application J2EE. Et donc n'importe quel genre de programme peut être "la partie visible" d'un serveur J2EE.

A quoi sert un serveur J2EE (ou un serveur d'application en général ) ? A tout les traitements informatiques dont on peut avoir besoin dans sa boîte. C'est une sorte d'interface entre systèmes de bases de données, bases de données tout court, serveurs webs, traitements et calculs spécifiques à l'entreprise, logiciels des utilisateurs finaux (genre pas besoin de s'assurer que le programme de conversion AutoCad vers PDF marche sur toutes les machines de la boîte : on le met sur le serveur d'application et pour s'en servir les utilisateurs finaux se servent d'un petit client tout léger et bien intégré à leur environnement.)

C'est plus clair ? (Je teste mes capacités de pédagogue, ici, hein, pas d'ingénieur...)

Il y a un 'h' et un suel 'l' à rlhâreus.

======> []

Il y a aussi le fait que des exploits exceptionnels (non, je veux parler des vrais exploits, ces trucs vachté réussis et impressionants) sont un peu trop souvent rapportés comme étant "le cas général." Quand l'information sur la performance n'était pas fausse, mais que c'était pas bien malin de prétendre que c'est le cas partout, toujours.

Mais bon, on voit ça chez les intégristes défenseurs de Linux comme chez les intégristes défenseurs de Windows. (Plus rare avec les autres systèmes, ou alors c'est que je ne sais pas les trouver...)

Oh, allez, Mandrake 8.1, ça ramait pas tellement ! ;-)

Wine, et WineX, ne sont pas des émulateurs, juste des couches de compatibilité Windows. Bien que cela entraîne des couches en plus à traverser, ça évite de passer par certaines routines qui ne servent à rien si on n'est pas dans un environnement Windows.

De fait, quand on utilise une seule configuration de Wine pour lancer n'importe quel logiciel, c'est souvent plus gourmand en ressources que sous Windows (je suis pas trop sûr de comprendre pourquoi, donc je vais éviter d'inventer.) Mais avec une configuration spécialisée pour un logiciel, c'est rare.

Donc ici, le problème n'est pas la perf', c'est la spécificité à un seul jeu (oui, tout cet argumentaire pour dire que je suis d'accord. Et alors ;-) ? )

Bien sûr !

Un objet OLE contient toutes les informations et structures nécessaires pour bien expliquer à un ordinateur la sémantique d'absolument tout ce qu'il contient, par exemple ce qu'est un sommaire, un saut de page, un en-tête, une image ancrée ou interne au texte, un habillage d'image...

C'est qu'ils sont malins, les ordis, de nos jours ! Peu de gens connaissent l'instruction assembleur "UNDRSTD mem32" du Pentium 4, qui lui permet de comprendre un concept humain correctement structuré en binaire ;-)

En pratique, ça pourrait quand même être fait, en reconstruisant toute l'image iso à chaque écriture d'un octet (suffirait de mettre une bonne partie du code de mkisofs dans le module noyau de l'iso9660.)

Oui, j'aime donner des informations techniquement exactes mais sans aucun intérêt et fondamentalement dangereuses d'emploi. Je suis aussi un ingénieur (enfin bientôt, dans quelques mois si tout se passe bien...) --> []

>A mon avis sur ce type d'architecture il ne doit pas y avoir de fork...
'Faut bien créer de nouveaux processus quand même :-). M'enfin j'ai compris l'idée.

Ça veut dire, par exemple, que si je fais un malloc() puis un fork(), mon processus fils continuera à traiter avec la mémoire allouée pour mon processus père, jusqu"à ce que je lui réindique la bonne adresse ? (un exemple parmi tant d'autres...)

Ça complique carrément la programmation, non ? M'enfin bon, je ne vois pas de solution miracle avec ou sans fork(), de toute façon -_-°.

> Moui, fais une recherche sur la news sur ce soft qui avait été passée il y a quelques temps ici. La discussion avait été trés interressante et on y avait parlé d'ailleurs q'autres problémes de facilité d'usage que ceux que seguro essaie de traiter.
oki, merci

En fait, en parcourant un peu le site, je me rends compte que c'est pas vraiment ce dont je parlais (pas du tout, même.) Mais par l'aspect "trouver toutes les actions rendues possibles par tous les programmes installés," (et les difficultés qui en découlent,) ça y ressemble. Et puis, je trouve qu'il y a de l'idée dans seguro.

>Bref, le seul probléme est qu'il faut quelqu'un pour faire ce boulot une fois qui sera utilisé ensuite par tout le monde.
Oh, il y a sûrement d'autres problèmes, aussi. Pas grave ;)

Serait-il possible d'oublier que j'ai répondu ce... cette... Raaaaah lynchez-moi pour ma réponse du dessus. Et que ça fasse mal !!!!

De fait, j'ai prétendu qu'il faut chercher un dossier en ligne de commande, eh ben c'est pareil avec un explorateur de fichier, et ça je l'ai bien zappé. C'est ce que tu voulais dire, je pense. Ouais, enfin c'est pas très visuel de se rappeler un nom de fichier/dossier, alors que se rappeler sa place l'est. Tout dépend de qui on est.

Probablement, mais je suis le genre de mec dingue qui croit au wikipédia, au MIME/type, au projet GNU, au fait qu'il soit un jour possible de se passer définitivement du moindre logiciel propriétaire sans pour autant coder soi-même quelque chose pour remplacer un produit propriétaire...

Bref, à l'argument
"ton truc ça peut pas marcher, il faut lui ajouter énormément de fonctions pour que ça puisse faire ce que fait ce qui existe déjà."
Je réponds
"Eh bah si ceux qui veulent telle fonction l'ajoutent, telle fonction sera là."

Bien sûr, ça peut pas être utile du jour au lendemain, ça pourrait même ne jamais être utile, mais jusqu'ici j'ai pas essayé et je veux essayer ;).

J'avais pas vu les choses comme ça, mais ça peut être une solution. Bon, en fait, je cherchais des gens qui avaient déjà un truc bien pensé à fond (voire codé) passque sinon je me le serais codé, mon utilitaire "de-la-mort-qui-tue-et-mince-j'avais-pas-pensé-qu'on-pourrait-vouloir-faire-ça"

Humouuuuur ;)

Nope. Ça, c'est s'il y a une routine que je fais souvent, je la rajoute dans le menu KDE/Gnome/non j'ai pas appris tous les noms d'environnement de bureau et j'en ai pas honte.

Mais s'il y a une routine que j'ai besoin de faire passer sur 600 fichiers, je voudrais ne pas avoir besoin de lancer un terminal pour ça.

Oui, oui, la ligne de commande est systématiquement mieux que les GUI, ça va plus vite, surtout pour les traitements de texte et les vidéos... ^^;

OK, je me suis mal exprimé, je veux me débarrasser de la ligne de commande dans toutes mes actions quotidiennes, ça va comme ça ?

Tu n'y crois pas, parfait, merci pour ton avis ;)

(et je me débrouille très bien en mode texte, j'aime pas, c'est tout.)

Ça, c'est si je voulais tout faire à partir de rien. C'est pas impossible, d'ailleurs ;). Mais avant, je vais jeter un coup d'?il à ce que m'a indiqué JM. Ça ressemble à une première tentative.

Merci, mais ce que je dis moi, c'est que je veux essayer. Tout ça, je le "sais" déjà, mais je pense que les deux méthodes ont leur place, suivant les gens qui s'en servent, partout et toujours.

Bah en fait, on est assez d'accords. (Et pour le hors-sujet, c'est pas grave, ça m'apprendra à balancer des trucs genre "s'en passer définitivement.")

>Parce que franchement, la solution que tu as l'air de préconiser ressemble fort à la programmation visuelle, qui ne fait que cacher la complexité sous des jolis dessins.

C'en est ;). Mais certains aspects de la complexité disparaissent (plus besoin de retenir 160 drapeaux pour 40 applications courantes) et d'autres se créent (comment ça, "cette opération n'existe pas, voulez-vous la définir ?") Moi, je pense que de la programmation visuelle correspondrait mieux à mes besoins pour ce genre de routines.

Oui, ça ressemble bien à ce que je cherche, je vais parcourir ça, merci.

>C'est tellement hors catégorie, que je suis incapable de le décrire en quelques lignes, désolé...

Ben c'est ce que j'ai essayé de faire, et on a vu le résultat ;) ...

Je m'étonne que tu ne m'aies pas redirigé vers le jeanmishell en le défendant bec et ongles, quand même. (Ici Mayeul, je sais pas si tu connais mon pseudo habituel, donc bon, voilà...)

Exactement

Précisément.

C'est un des cas où je pense qu'une programmation graphique vaut une programmation texte. À condition de reconnaître suffisamment de programmes installés, s'entend.

(Bon, je viens de relire mon journal, que j'avais élagué par rapport à la première version pour le rendre plus court, et je peux blâmer personne s'il voit pas ce que je veux dire. Un peu normal que j'aie dû répondre 3 fois ;).)

> J'vais certainement dire une grosse connnerie

Moins que moi, apparamment, puisque personne n'a compris où je voulais en venir ;)

>Ces soucis mis a parts :-) ca a l'air pas mal non ? :-)

Je sais pas trop. A ce niveau-là, autant faire directement un script "transformer tous les *.png en thumbnail *.jpg" qu'on associe aux dossiers KDE avec un desktop entry, et voilà. Bon, c'est pas si simple à faire, et une fois que c'est fait, ça rend bien servir si on s'en sert tous les jours.

Mais moi, je parlais du cas où on ne peut pas prévoir quel traitement automatisé on va vouloir effectuer. (Comme avec la ligne de commande, donc)