Miguel Moquillon a écrit 449 commentaires

Oui tout à fait. Avec FUSE qui sera intégré dans le noyau à partir du 2.6.14 je crois, ça pourrait devenir intéressant.
Fini les gestionnaires de fichiers qui font tout ou des outils lourdaux pour des tâches simples. Ceci pourrait rendre les programmes plus petits et donc moins soumis aux bogues. De plus, ceci unifierait un tant soit peu l'accès et la manipulation des données.
Chaque programme serait dédié à une usage précis.
Reste à faire de même pour le système graphique : remplacer ce lourdaud de X par un environnement qui respecterait la philosophie d'Unix, sous forme par exemple de système de fichiers comme pour Plan9.

Et pourquoi pas pour une fois respecter l'une des philosophies Unix : tout est fichier. Autrement dit, tes boites email, qu'ils soient distant ou non, soient montés comme un système de fichier. Il suffit alors d'utiliser juste les interfaces d'entrée/sorties des systèmes de fichier.
Mais c'est vrai, la tendance actuelle est de faire comme pour MacOsX ou Windows et mettre au chiotte les principes même d'Unix (un outil fait qu'une seule et unique chose et le fait bien, tout est fichier, etc.), juste pour faire plaisir aux nouveaux venus, pour surtout ne pas perturber leurs petites habitudes ... les pauvres petits.

Il faut croire à tes explications que, effectivement, je n'ai pas compris la même chose que toi. Je n'ai pas encore écouté ton mp4, j'espère que je pourrais l'écouter sous GNU/Linux.

Je suis d'accord que la gestion de la mémoire ce n'est pas simplement faire du malloc/mmap/... mais aussi gérer ses données comme par exemple sa taille ... qui peut dépendre de l'architecture matérielle sous-jacente. je suis d'accord aussi que c'est au langage de gérer au mieux la gestion mémoire en fonction de l'architecture sous-jacente. Mais là, contrairement à ce que tu dis, les langages de haut niveau ne sont pas pour autant mis hors jeu, au contraire...

De plus, ce qui fait gagner la majorité des cas en performance, c'est l'optimisation globale et non locale.
Et sur ce point, un certain nombre de langages de haut niveau gère très bien cela, et surtoût mieux que nous pourrions le faire dans la plupart des cas. Je m'explique sur ce point. Dans des applications complexes, tu peut effectivement avec un langage de bas niveau optimiser un certain nombre de choses, mais cette optimisation se fait localement et non globalement ; autrement dit, tu as optimisé les parties de l'application qui finalement ne seront peut-être utiles que dans 20% dans le meilleur des cas tout simplement parce que ton application est trop complexe pour avoir un aperçu globale de ces optimisations (leur pertinence, etc.). Le tout se durcit si en plus ton application doit être multi-plateforme : la particularité de chaque plate-forme doit être prise en compte ! Ceci est particulièrement pertinent avec les SGBDR.
Faire de l'optimisation pour faire de l'optimisation ne sert à rien ! L'optimisation est un moyen, pas un but en soit.

Au jour d'aujourd'hui, les compilateurs de certains langages haut niveau (malheureusement pas ceux que l'on utilise au quotidien) ont atteint une grande maturité et permettent d'écrire des programmes multi-plateforme d'une grande efficacité, en tout plus éfficace et bug free que si on avait à les écrire en optimisant nous même avec un langage de bas niveau (qu'il soit ou non équipé d'un compilateur performant). Et le progrès de ce côté là continue.
Par contre, je suis d'accord que ce n'est pas parce que ton langage, ton framework ou autre permet d'optimiser globalement ton appli en fonction de l'architecture sous-jacente que tu dois pour autant ne pas te préoccuper dans certains cas des problématiques d'optimisation de ton code. De la même façon, ce n'est pas parce que tu programmes avec un langage de bas niveau (donc soit disant plus performant) ou de haut niveau (il sait faire les optimisations mieux que moi) que tu dois choisir des technos ou faire une conception à chier qui finalement conduit à produire un bousin (souvent parce que c'est la mode).

Contredire tout mon post en relevant juste une phrase, qui plus est n'est pas fausse ? Tes binaires toi. Ca ne doit pas être drôle la vie avec toi.
Pour préciser nos écris respectifs :
la couche graphique d'Eclipse, SWT, est bien du Java, mais elle est native. Autrement dit SWT est un front-end au-dessus d'un back-end qui est un toolkit natif (Gtk2, Motif, etc.);
Ce qui fait qu'effectivement, l'exécution d'Eclipse est plus rapide que si cette couche était du Swing - on peut comparer par exemple Netbeans 4 et Eclipse (j'ai travaillé avec les deux).
Pourtant, malgré cela, Eclipse (ou tout autre programme Java) reste plus lourd que l'environnement graphique Squeak qui lui est codé tout en Smalltalk ! Ce qui prouve encore que l'on peut trouver des grandes disparités entre les langages ou frameworks dits de haut niveau, et que ce n'est pas toujours les meilleurs technos qui s'imposent.

Ca n'a rien à voir. Dans le cas des outils Mozilla, ce sont les technos utilisées (XUL) et les choix de conceptions qui aboutissent, en partie, à cette lourdeure.

Les accès mémoire sont gérés par l'OS. Celui-ci exporte des appels système pour réserver de l'espace mémoire. Les applis ne font qu'appel à ces appels systèmes soit directement soit au travers de fonctions de librairies.
Par contre, le choix de ces appels et quand peut permettre des améliorations de performance. Ainsi par exemple, sous Linux et d'autres Unix il est plus "performant" de faire appel à mmap une fois pour toute pour allouer toute la mémoire qu'aura besoin l'application et de l'utiliser pour les variables à allouer dans le tas que d'utiliser de multiples malloc.
Dans ce cas, par exemple, les langages de haut niveau qui gèrent automatiquement la mémoire sont dotés d'algorithmes (soit le runtime soit le compilateur) très poussés pour gérer de façon à peu près optimale la mémoire (pour les compilateurs par une analyse sémentique en une ou plusieurs passes).
De la même façon, depuis les années 80 (le garbadge collecting existe bien avant ces années), les algorithmes et les techniques de garbadge collecting se sont bcp améliorés.

Aussi, de nos jours, les problématiques de gestion de mémoire sont moins pertinantes qu'il y a quelque temps et ne méritent plus que l'on s'y consacre autant de temps avec des langages de bas niveau (excepté prog système, embarqué, noyau, ...).

Rendons à César ce qui appartient à César : grâce à GNOME ;)

En effet, les langages objets s'imposent, mais à part SmartEiffel et Lisaac, aucun ne résoud la liaison dynamique coûteuse en performance (par vidage du cache du processeurs et impossibilité d'inliner le code).

Hum ... un peu présomptueux de ta part de déclarer qu'aucun à part Eiffel (SmartEiffel ici qui n'est qu'une implémentation d'Eiffel) et Lisaac (qui pour l'instant semble abandonné (?)) ne résoud le coût de la liaison dynamique. Il existe un très grand nombre de langages objet et je ne pense pas que tu les connaissent suffisamment tous pour te permettre une telle assertion.
Exemple d'Haskell (qui certe n'est pas réellement un langage objet).

Sinon, quant à la lenteur d'exécution de code des langages de haut niveau, ils peuvent être relative. Voir par exemple le C++ avec Eiffel ; dans l'ensemble, avec la dernière version de SmartEffeil (2.2), c'est kif-kif. Voir aussi Squeak (une implémentation de Smalltalk) qui est pourtant un langage à typage dynamique.
De toute façon, qu'un programme soit écrit avec un langage de bas niveau ne suffit pas pour qu'il soit performant. Voir GNOME par exemple. En effet, avec la complexité des applis et le choix de technologies dans ces langages, ils atteignent leur limites et peuvent être même plus lourds qu'un même programme écrit avec un langage de haut niveau. Déjà, il n'y a qu'à voir, dans la catégorie langages de haut niveau, la différence de perfs entre un programme graphique Java (par exemple Eclipse) avec l'environnement graphique Squeak.

Malheureusement, comme tu le soulignes, ce sont plutôt des langages "lent", aux choix techniques des fois douteuses, qui vont prendre le dessus parce que derrière il y a un veritable rouleau compresseur marketing pour les imposer : Java et C#.

Ok. Je vois maintenant l'intérêt qui est plutôt professionnelle. Néanmoins, l'encombrement a toutjours été du côté des écrans et toutes les entreprises n'ont pas encore un écran plat pour chacun de leur employé (par exemple la mienne). Par contre, des UC à faibles encombrement existent depuis un certain temps, voir par exemple le eVectra de HP.
Néanmoins comme tu l'as souligné, le prix de cette solution "multi-utilisateurs" est plus intéressante que celle d'un clients/serveur.

Ok. Merci pour les explication.
J'aurais toutefois encore une question: quel est l'intérêt ?
Je veux dire par là que les personnes sont alors coincées dans la même pièce avec des fils qui trainent partout.
Quite à avoir un écran par utilisateur, autant utiliser un terminal X relié par réseau (WiFi ou ethernet) à ladite machine. Ce terminal peut être un PC portable ou même un iMac (ces machines unité central-écran en un). L'avantage du portable est qu'il est justement ... transportable.

Je n'ai pas très bien compris le terme "multi-utilisateurs" avec X dans ton journal.
Que veux-tu signifier par là ?

Si c'est pour signifier avoir plusieurs consoles graphiques sur une machine, ce qui permettrait à plusieurs utilisateurs d'utiliser le PC lorsqu'une personne s'absente alors que son compte est vérouillé, alors je peux dire qu'aujourd'hui nous pouvons déjà le faire : un serveur X qui tourne dans chaque console virtuelle.
Bien sûr, ceci parait lourd parce que plusieurs instances de X et de window managers ou de desktops tournent, mais bon, qd on utilise du mozilla et de l'OOo qui, il faut l'avouer, sont assez lourdaux comparés aux fonctionnalités offertes, on ne va pas se plaindre.
De toute façon c'est la mode : des applis de plus en plus lourdes pour pas grands choses et tout le monde s'en fout ... parce que la machine de demain est plus puissante que celle de hier. Ben tien.

Un produit GPL n'exclut pas une démarche commerciale dudit produit. Que tu vendes ton produit ou que tu le donnes, selon les termes de la GPL tu dois fournir les sources. Le client ou l'utilisateur peut alors faire ce qu'il veut de ces sources ou du binaire : le donner à un autre, le déployer sur autant de machine, modifier le produit à partir des sources, etc.
Donc, ils ne semblent pas contredire la GPL, à moins que tu ne m'es pas tout dit :)

De naviguer comme il veut ? Faut pas exagérer non plus.
Comme je disais plus haut, le système de lien permet toutefois une navigation aisée et la restriction par rapport à une ouverture sur un nouvel onglet ou une nouvelle fenêtre n'est pas si rebutante que cela.

Ca me fait rappeler les arguments des windowsiens qui se plaignent qu'ils n'aient pas par défaut les droits d'administration de leur machine GNU/Linux ! Que la sécurité c'était trop contraignante ... sur leur habitude.

Si il n'y a que cela et si ça t'intéresse, je peux toujours prendre un peu de mon temps pour changer ça et utiliser une méthode GET. Voir, le paramètrer dans un fichier de conf. Mais faut être patient parce que je n'ai pas bcp de temps en ce moment.

A ce que les données transitent dans le corps de la requête HTTP et qu'un utilisateur ne puisse profiter des URL rewriting ou faire passer des données via URL qui coincideraient avec un trou de sécu du serveur HTTP ou de l'environnement PHP.
Bien sûr, aujourd'hui, ce genre de faiblesse est pluto rare.

J'ai oublié aussi ceci: j'aurais pu passer par une variable de session (qui utilise les cookies) pour enregistrer les informations nécessaires au passage à la page suivante. Ceci aurait effectivement évité d'utiliser du javascript. Toutefois, je ne voulais pas imposé aux utilisateurs l'acceptation de cookies pour simplement visualiser les photos ou parcourir un album. Seule la partie diaporama nécessite ces derniers.

De plus, je pense toutefois que l'on peut parcourir les photos et les albums facilement via les liens proposés et que donc ceci permet de compenser le manque de navigation par onglets ou fenêtres du navigateur.

A envoyer un formulaire via un lien hypertexte par la méthode POST (qui est plus sécurisée que GET). Ce formulaire contient l'information demandé par l'utilisateur ainsi qu'un certain contexte.

Mais je reconnais que par ce biais on perd l'avantage de pouvoir ouvrir une page dans un autre onglet ou fenêtre.

Elle change par rapport à l'évolution d'une espèce dont on parle ici. Ne mélangeons pas tout.

Je me permet de répondre ... tardivement :)
Ici, je réagis aux termes "optimisation" et "concurrence" qui ont, pour moi, une signification précise. Optimisation et concurrence sont des moyens, pas des buts ou des processus.

Aussi, l'évolution n'est pas réellement une optimisation des caractéristiques d'une espèce vis à vis de son environnement. Elle s'adapte à celle-ci, mais cette adaptation peut se faire au travers de caractéristiques différentes comme on le voit avec des espèces différentes occupant une même niche. C'est aussi pourquoi, lorsqu'un changement intervient, certaines branches d'espèces disparaissent : parce que certaines sont plus adaptées au changement intervenu que d'autres. Adaptation n'est pas optimisation.

De même que la concurrence. Des espèces sont en "concurrence" sur une même niche et ce n'est pas pour autant que l'une d'elle va disparaitre pour autant. En fait, la concurrence est un moyen de "vie" de certaines espèces qui occupent une même niche mais n'est pas induit par l'évolution.
L'adaptation n'est pas non plus concurrence.
Dans ton exemple de Caulerpa taxifolia, il faut bien voir que l'on parle d'un cas induit par un changement d'environnement provoqué probablement par l'homme (on en est de plus en plus sûr, mais je met un bémole, on ne sait jamais); ce qui est autre chose que l'évolution.

Bonjour,

J'avais écris il y a quelque temps en PHP un album web de photos.
Il est sous GPL. Actuellement, tu n'as pas le téléchargement de la photo lorsque tu cliques dessus la miniature, mais il n'est pas difficile de l'implémenter.
Par contre il ne gère pas les droits des utilisateurs car il est dédié à une et unique chose (dans l'esprit d'Unix): permettre la consultation d'albums photos. Aussi, gèrer les droits d'utilisateurs seraient plus la tâche d'un autre programme qui donnerait alors l'accès à l'album web.
je dois avouer que c'est un programme simple, donc le code est court et simple. Il s'appuit sur le système de fichiers et non sur une base de données.
Tu peux le trouver ici:
http://miguel.moquillon.free.fr/download/wagen-1.4.5.tar(...)

Sinon, voici un exemple du programme:
http://miguel.moquillon.free.fr/miguel/wagen/index.php(...)

Bonjour tout le monde,

Au vue de nombreux commentaires je lis des choses comme :
- l'évolution => optimisation des espèces,
- concurrence des espèces => le meilleur gagne,
- et autres inepties.

Ce commentaire est là pour juste souligner que l'évolution selon la théorie de Darwin repose, en gros, sur l'adaptation générationnelle d'une espèce animale, végétale, etc. à son environnement, cet environnement incluant bien sur les autres espèces (prédateurs, proies ou similaires). Or l'adaptation ne signifie par pour autant "optimisation" ou concurrence (que le meilleur gagne). En effet, des espèces similaires se sont adaptées au fil des générations différemment à leur environnement et pourtant aucun n'a pris le dessus sur l'autre. Par contre, des branches d'une même espèce ont remplacées d'autre parce que plus adaptables à leur environnement, mais surtoût aux changements de celui-ci.

Il ne faudrait pas confondre darwinisme et eugénisme.

On peut ou aimer ou non le XML. L'avantage de ce dernier est de pouvoir être utilisé quelque soit la plate-forme, ce qui n'est pas le cas des Makefiles.

Les fichiers XML pour Maven ou Ant ne sont pas dédiés aux IDE ou AGL mais permettent au contraire une indépendance à ces derniers. A la charge de ceux-ci d'intégrer ou non l'architecture de build via Ant ou celle de projet via Maven. Dans mon cas, j'utilise ant en ligne de commande et non via un IDE et les fichiers ant que je construit peuvent être utilisés aussi bien par ceux qui développement avec NetBeans, Eclipse ou en encore Emacs (avec JDEE).

Par contre, quant aux points positifs et négatifs entre Makefile et fichiers de build XML, je suis dans l'ensemble d'accord avec tes avis.
Je rajouterais ceci : dans des projets conséquents, les Makefiles peuvent devenir assez rapidement illisible, ce qui n'arrive que trop rarement avec les document en XML de par leur nature.

J'ai recherché des liens de SuperWiki en rapport à ce que j'ai écrit mais je n'ai rien trouvé de probant.
Pourtant, une fois, en naviguant parmi les liens des sites Smalltalk, je suis tombé dessus une fois.
J'ai trouvé sinon SupersWiki (Super Squeak Wiki) qui est une sorte de Super Wiki pour Squeak. Il permet de partager un projet Squeak via le Web. Je pense qu'il est nécessaire d'utiliser l'environnement Squeak pour acceder aux fonctionnalités 'avancées' : éditer un projet, les objets, etc.
Un exemple de Super Swiki:
http://www.squeakalpha.org:8080/super(...)

Quelque chose comme Maven ?
http://maven.apache.org/(...)

Actuellement, Maven est plutôt centré sur Java, mais rien n'empêche d'écrire des plugins Maven pour supporter d'autres langages, comme d'ailleur des tâches ant peuvent être écrites pour la gestion d'autres langages que Java.

Smalltalk toujours copié (en mal), jamais dépassé :)
La communauté Smalltalk, en s'appuyant sur les propriétés de leur langage, sont toujours en avance dans les technologies.
Ce système de partage de code via le Wiki existe déjà un bon bout de temps dans cette communauté.
D'ailleurs, le Wiki a été inventé à l'origine par la communauté et a été par la suite copié. Maintenant, ils en sont au SuperWiki tandis que nous commençons juste à vraiment utiliser le wiki. Qu'est-ce que le SuperWiki ? Un environnement à la Smalltalk via le Web; autrement dit un environnement d'objets accessibles par tout le monde et modifiable par tout le monde (en très gros).

Sinon, dans le même ordre, la communauté travaille aussi sur un système réseau collaboratif 3D : opencroquet.
http://www.opencroquet.org(...)

Bon je vais peut-être y aller fort là :)

Pourquoi ? Pas assez de courage ? Trop de contrainte ?
Eh bien non, simplement parce que je considère que le Don Quichotisme [...]

J'ai déjà entendu ce genre de propos et j'ai souvent remarqué que c'était de la poudre aux yeux pour ne pas voir son propre manque de courage ou de volonté à sauter le pas.
Ca va, je n'ai pas été trop méchant :) ?

"on n'a jamais raison tout seul contre tous les autres"

Va dire ça à l'Angletterre seul face à l'Europe lors du blitz nazi, avant l'intervention des USA. Ou encore, seul face à l'Europe napoléonniènne.

A mon avis, vouloir agir comme tu souhaites le faire, c'est avoir une logique d'auto-exclusion (d'isolement) qui ne fera pas avancer les choses

Cela fait depuis 2001 que suis passé entièrement sous GNU/Linux. Est-ce que j'ai vraiment fait avancer les choses. Oui et non. Oui parce que je sais de quoi je parle lorsque je met en avant un outil libre en lieu et place de son équivalent propriétaire, que je suis crédible devant ceux que je connaisse lorsque je parle de logiciels libres ... et que j'ai réussi à faire passer des personnes sous ce système. Non, parce qu'au fur et à mesure des années qui s'écoulent, des plus en plus de jeunes et moins jeunes s'emprisonnent dans les technologies Microsoft qui se développent petit à petit mais sûrement sur la surface du monde: MSN est son fer de lance, le multimédia est sa plus sûr arme. Face à ces technos qui ne se connaissent qu'elles mêmes et qui rejettent l'existant (existant, quel existant ? l'informatique c'est Microsoft bien sûr), effectivement, je peux dire que d'une certaine manière je me matiens à une auto-exclusion : je ne communique pas avec mes potes ou des membres de ma familles sous MSN, sous leur blog lui même dans leur espace Web MSN (faut une inscription Passport, beurk), sous NetMeeting, etc.

Moi, je te conseille d'être plus pragmatique, ou plutôt, plus efficace.

Choisir de passer complètement à GNU/Linux ou autre système libre ne se mesure pas AMHA au pragmatisme ou à l'efficacité. Il se mesure à l'aûne de ce que l'on appelle l'"idéalisme" ou encore "nos propres convictions". Le pragmatisme et l'efficacité peuvent se trouver partout même dans la réalisation de nos convictions car ils ne sont pas, en eux-même, des buts à atteindre.