Miguel Moquillon a écrit 451 commentaires

Hum ... je n'ai pas d'onglet ACL qui appairait.
Je regarderai ça de plus près ce soir, chez moi.

QtDesigner > Glade, c'est ton opinion, pas la mienne en tout cas.

Ce n'est pas une question d'opinion ici, c'est une question d'expérience, la mienne, en dehors de toute préférence pour Gtk+ ou Qt.

c'est quand toi savoir faire phrases correctes ?

Quand toi sauras correctement lire et écrire français ...

Suffit de drag'n'dropper avec le bouton du mileu, ainsi quand tu drop
ton menu apparait

Putain, juste par l'utilisation du bouton du milieu ! Merci de l'info.
Et tu connaîtrais un moyen pour lui dire de le faire tout simplement avec le bouton gauche de la souris ?

C'est aussi déjà possible ... tu fais afficher le panneau information quand tu es dans le repertoire : tu te retrouves ainsi avec un gros icone à gauche (dans le panneau). Et tu drag'n'drop ton image sur ce gros icone. (ainsi tu peux mettre les pochettes d'album sur tes repertoires de zic)

Ok ... donc si je comprend bien : depuis le début avec GNOME je suis complètement à la ramasse

Usine à gaz ?
Donc rox-filer serait une usine à gaz parce qu'il implémente la plupart des choses que j'ai énuméré pour Nautilus ?
Konqueror permet de faire tout ce que j'attends d'un gestionnaire de fichier graphique avec accès à des systèmes de fichier distant et pourtant il est moins lourd que Nautilus ... du moins pour l'instant.

Sinon, par rapport à l'accès aux systèmes de fichier distants, l'idéal serait le support de FUSE dans ces gestionnaires de fichier ; ainsi pour un répertoire, on pourrait lui dire d'utiliser FUSE pour un montage via SSH ou autre. Ceci permettrait d'alléger les Nautilus et Konqueror de leur gestion en interne des protocoles réseaux d'accès à des systèmes de fichier distants.

A part le lien absolu, tu reproches quoi au menu actuel ?

Ben qu'il y en a pas tout simplement.
Mais un autre commentaire m'a appris l'incantation précise pour faire ce que j'ai cherché et n'ai jamais trouvé de façon naturelle.

Euh ... oui ? C'est pas le cas ?

Ben non. Il ne propose qu'un ensemble d'icônes à attacher à celui par défaut du dossier. Ce qui, parfois suffit, mais d'autre fois non.

Nautilus supporte les ACLs depuis un moment. T'as entendu parler de EICIEL ?

Oui et je l'ai même installé, mais je ne vois pas le rapport avec Nautilus. Lorsque j'ai installé EICEL, c'était un programme à part entier et Nautilus ne me permettait toujours pas de gérer les ACL (donc il n'y avait pas, apparemment de lien, entre les deux).

C'est déjà le cas, suffit d'un glisser déposer sur l'icône de ton dossier soit sur le panel de gauche, soit dans la fenêtre propriétés.

- Ha oui ? Je trouve ça vachement ergonomique. Mais bon, merci de l'info, je saurais comment faire maintenant.

Si tu mets de côté IB, Glade est pas trop mal comparé à la concurence.

Mais malheureusement encore en deçà d'un QtDesigner ...

Sinon, je trouve dommage que, parce que j'ai cité des limitations, on moinsisse mon commentaire. Apparemment, il y en a qui n'aime pas les critiques ...

Reste encore du chemin à faire, dû moins sur ces deux points au moins :
- Nautilus ne supporte toujours pas les ACL et la gestion des liens avec le FTP (+ d'autres bricoles qui font que je lui préfère d'autre programmes).
C'est quand Nautilus nous proposera un menu contextuel avec ce que l'on désire de faire lorsque l'on prend et glisse un fichier (répertoire) d'un endroit à l'autre ; un menu qui propose au moins les opérations suivantes : "copier", "déplacer", "créer un lien relatif", "créer un lien absolu")
C'est quand Nautilus nous proposera de choisir n'importe quel icône pour un dossier ?
C'est quand Nautilus nous proposera de lier un répertoire avec une action (par exemple, un répertoire Musiques/ pourra être lié avec un lecteur de musique par
exemple) ?

- Glade est à la ramasse par rapport à ce qui se fait en terme d'éditeur d'IHM. Le top étant InterfaceBuilder ou en libre Gorm (de GNUstep). Pour avoir utilisé sa dernière version il y a quelque jour, j'en ai pleuré ! C'était vraiment parce que j'avais besoin d'une IHM en Gtk+ ...

- Et c'est quand que l'on peut passer d'un workspace à un autre via la roulette de la souris sur le bureau (et non dans le pager) ? C'est quand avec la roulette de la souris on va pouvoir plier une fenêtre ? Etc.

D'aucune manière nous disons "Acceleo = MDA"

Ok, donc j'ai mal interprété le texte suivant sur la page principale :
Acceleo est un générateur de code qui permet de transformer des modèles vers du code ( approche MDA ).

Générer le code depuis un PSM n'a aucun intérêt, toutes les informations sont déjà là

Justement non. Le PIM n'a aucune information de plate-forme, PHP+PEAR par exemple. Il ne dispose donc pas d'information suffisante pour la génération de code.
D'où le PSM. De plus le PSM a un intérêt à partir du moment que l'on sache gérer son cycle de vie ... ce que n'offre actuellement aucun outil de ma connaissance; raison probable pour laquelle la transformation PIM vers PSM est vue comme inefficace.

"comme les langages de programmations ne sont pas MOF compliant,"
C'est faux, ils peuvent tout à fait l'être cependant l'intérêt est nul

C'est vrai, les langages de programmations ne sont pas MOF compliant : leur grammaire ne s'appuient pas sur MOF.

Par contre je suis d'accord qu'il est plus simple de modifier du code qu'un modèle.

Ha MDA, ce bon buzz word utilisé à tout va par les anciens AGL pour rester dans le vent !
Du MDA ? Non. De la simple génération d'un modèle UML vers un langage de programmation. Voilà c'est tout.

Et MDA ? C'est bien plus que ça ! Pour ceux qui ne connaissent pas, voici, grosso modo c'est qu'est MDA (Model Driven Architecture) :
- D'abord, à la source, un modèle indépendant de toute considération technique (donc de plate-forme, mais pas seulement, de frameworks aussi) : le PIM (Platform Independent Model). C'est ce que en gros on appelle le modèle d'analyse dans l'USDP (Unified Software Development Process). Le langage de modélisation utilisé pour écrire ce modèle doit respecter le MOF (un méta-langage de modélisation en gros). UML respecte le MOF. Le cycle de vie du PIM doit être géré.
- A partir du modèle PIM, peut-être généré plusieurs PSM (Platform Specific Model) à l'aide d'un ensemble de règles de transformation qui prennent en compte les choix techniques pour la future implémentation. Ceci est réalisable parce que le PSM respecte aussi le MOF. C'est en gros ce que l'on appelle le modèle du design dans USDP pour avoir une analogie. Le cycle de vie du PSM doit aussi être géré.
- A partir du PSM peut avoir lieu alors la génération vers un langage de programmation. Sauf que là, comme le langage n'est pas MOF compliant, cette partie, même si elle est indiquée (indiquer ne signifie pas spécifier) dans le MDA, ne fait pas partie vraiment du MDA. Pour s'en sortir, comme les langages de programmations ne sont pas MOF compliant, des langages MOF compliant (ce que l'on appelle aussi les profils UML) sont écrits afin de réaliser plus facilement cette génération ou plus exactement pour cacher ce problème; mais la partie transformation de ce qui est écrit dans ces derniers langages vers le langage de programmation est à la discrétion, actuellement, de l'AGL et n'entre pas dans le champs de spécification du MDA.

Vous aurez compris, les AGL ou autres outils travaillant sur les modèles UML existant sur le marché, malgrès leur "MDA compliant", ne couvrent que le dernier aspect ... et qui n'entre pas vraiment dans le champs du MDA. Cherchez l'erreur.

9P2000 (ou v9fs) est juste un FS parmi d'autre rajouté dans Linux pour profiter de ce système de comm.
9P2000 est la brique de base sur laquelle est contruit Plan9 : en gros dans Plan9 tout est service et le système de fichier sert d'annuaire de ceux-ci. Même les pilotes : si je me souviens bien, par exemple, un pilote sur un Plan9 distant en kernel-space peut service sur un Plan9 local en user-space.
Il faut savoir que Plan9 a été conçu par le père fondateur d'Unix, Ken Thompson, avec d'autres personnes, en vue de pousser jusqu'au bout les concepts même d'Unix ; en gros de faire ce qu'aurait dû être Unix. Et 9P2000 est ce qui permet à Plan9 d'atteindre cet objectif.

Linux est utilisé presque partout dans cette machine !
Certes les noeuds de calcul fonctionnent avec un noyau propriétaire extrêmement léger (réduit à sa plus simple expression) mais les noeuds d'entrée/sortie utilisent Linux. Les noeuds de service ainsi que le front end se basent quand à eux sur Suse Linux SLES 10.

... et IBM travaille à porter Plan9 sur chaque noeud de Blue Gene.
Et pourquoi choisir Plan9 me demanderiez vous ?
Simple : ces monstres s'apparentent de plus plus à des systèmes distribués dont chaque noeud est en étroite communication via des liens réseaux dédiés. Il est donc nécessaire, afin de profiter au mieux de ce type d'architecture, de disposer sur chaque noeud (noeud de calcul et d'entrée-sortie) d'un OS qui repose sur une architecture distribuée et qui offre donc l'opportunité aux services sur les noeuds de pouvoir aussi être répartis. C'est ce que permet justement Plan9 avec son protocol 9P2000.

Est-ce le signe d'un renouveau pour Plan9 ?
(il existe déjà une distribution de Plan9 : Inferno, vendu par Via Nuova
http://www.vitanuova.com/
)


Quelques liens pour en savoir plus :
http://domino.research.ibm.com/comm/research_projects.nsf/pa(...)
http://www.graverobber.org/

et un article sur slashdot qui en a parlé :
http://slashdot.org/article.pl?sid=07/06/19/1215253&from(...)

Le langage Eiffel est un très bon langage mais qui n'a pas réussi à percé pour différents motifs et je pense essentiellement dû au décalage entre l'attente des développeurs/décideurs et ce qui était fourni.

Maintenant, il aura d'autant plus de mal avec d'une part le Eiffel de NICE et le Eiffel de l'ECMA. Sur lequel pouvons nous vraiment miser ? Décidément, Meyer n'a jamais su vraiment profiter ou créer les opportunités qu'il fallait.
A côté de ceci, il y a l'arrivée de nouveaux langages objets comme par exemple Lisaac ou Io, et ceci sans parler du renouveau de Smalltalk, toutjours imité, mais jamais vraiment égalé (si ce n'est peut-être par Self), avec par exemple Squeak, seaside, ... et probablement dans un future plus ou moins proche, StrongTalk.
De plus actuellement, l'environnement des langages objets utilisés dans l'industrie s'est grosso-modo bipolarisé avec d'un côté la plateforme Java et de l'autre C# et sa plateforme .NET.

Je te remercie de ta réponse.
Donc, si j'ai bien compris, je peux lui conseiller un portable keynux (le Studio DX qui est compatible GNU/Linux) mais sans OS (puisque leur installation de Mandriva est à désiré). Il ne restera plus alors qu'à installer une Ubuntu par exemple.

Ce serait vachement mieux si le module de génération JEE utilisait le framwork spring (avec spring-hibernate), et donc spring-mvc (voir spring-webflow) en lieu et place de struts. Ceci en attendant que la communauté évolue et finit par accepter les couches IHM Web orientées composant comme wicket par exemple au lieu de se battre avec des taglib dans du jsp.

... peut-être pas très légère mais pas "horriblement lourd(e)"

Je suis désolé, mais OpenOffice est bien _horriblement_lourd_ et il tout de même dommage (déplorable) de devoir disposer d'un processeur très puissant avec de la RAM qui va bien pour qu'il daigne de paraître juste lourd.

Signé un utilisateur habituel d'OpenOffice (ou plus exactement du writer et du impress)

Mais bon, c'est la tendance depuis un certain nombre d'années d'écrire du lourd (X11, OpenOffice, Mozilla, ...)

C'était peut-être ironique, mais tu n'étais pas loin de la vérité : la Grande Guerre (ou la première guerre mondiale) a été une revanche des français sur leur défaite de 1870 et la perte à cette date de l'Alsace-Lorraine. Depuis cette défaite, les enfants de la république n'ont cessé d'être matraqués par l'idée de revanche et par le patriotisme.
Voir http://fr.wikipedia.org/wiki/Guerre_franco-allemande_de_1870 pour plus d'informations.

un langage (presque) tout objet, à prototypes, non typé, à liaison retardée (late binding), (généralement) interprété,

En quoi ces caractéristiques font d'un langage un mauvais langage ?
Ce ne sont pas ses caractéristiques qui font d'un langage un mauvais langage, ce sont avant tout l'implémentations de ces derniers et l'expressivité que le langage t'offre qui fait qu'un langage est soit mauvais, soit bon.
Prends l'exemple de Self, un langage tout objet à prototypes (sans concepts de classes contrairement à Javascript), père de référence des langages objets à prototype modernes (io, slater, lisaac, etc.).
(Self est un langage typé fort, à liaison dynamique et à VM.)

Seulement lorsque tu veux sauvegarder ta méthode, l'environnement te crie dessus si jamais les variables ne sont pas initialisées, ne sont pas utilisées, etc. Et l'environnement, c'est Smalltalk (en effet, Smalltalk n'est pas un langage au sens habituel du terme mais un véritable environnement de dév et d'exécution d'objets)
Donc, finalement ...

Il apparaîtrait que seaside, ou probablement commanche, le navigateur Web avec lequel s'interface seaside, a des problèmes de montées en charge dans un environnement de production. Pour résoudre ce problème, il convient, comme avec Tomcat, de le disposer en arrière d'un Apache et d'utiliser un load balancer.
Voir les liens suivant sur le sujet :
http://onsmalltalk.com/programming/smalltalk/seaside/scaling(...)
http://onsmalltalk.com/programming/smalltalk/scaling-seaside(...)

Sinon, j'aime bien aussi le sujet suivant ("My journey to Linux" ;-)
http://onsmalltalk.com/programming/smalltalk/seaside/my-jour(...)

Pour Debian et Ubuntu, il existe des dépôts pour installer squeak :
deb http://ftp.squeak.org/debian/ testing main
deb-src http://ftp.squeak.org/debian/ testing main
(remplacez testing par stable ou unstable selon la version de votre distrib)

Il y a même un packet pour seaside :-)
Toutefois, il semble que ce soit une version anciènne.

Je recommande donc les images de Damien Cassous qui sont vachement sympa pour rapidement commencer à développer avec.

Au cours de l'évènement DAVDSI, je n'ai pas très bien compris ce qu'il en était de la licence globale et je ne m'y étais finalement pas penché puisqu'elle a été abandonnée par la suite.

J'aimerais bien savoir ce que cette licence apporte réellement au débat sur le droit numérique, à quelle problème elle est censée répondre, qui sont les concernés, et finalement en quoi elle nous impactera dans notre usage de l'outil informatique en général (et donc pas seulement dans son usage sur les oeuvres numériques).
Quelqu'un pour éclairer ma lanterne ?

J'ai lu ton texte long, très long. Je suis développeur et par mon expérience, effectivement :
- écrire un logiciel pour GNU/Linux implique aussi de choisir quelle(s) distribution(s) et quelle(s) version(s) de celle(s)-ci un paquet doit être construit ; ceci conduit donc à un surcoût. Avec des serveurs de builds et de packaging, la problématique est résolue ; toutefois celle-ci n'est pas ou peu possible avec des SSII

- l'ensemble des frameworks/toolkits disponibles est un véritable casse-tête : un choix et une étude est à réaliser. Et il est vrai que cela rebute un certain nombre d'équipes. Pourtant ces différentes possibilités permettent de répondre aux éxigences et besoins dans le développement du produit.

Pourtant, malgrès ces problèmes, GNU/Linux ou des frameworks libres prennent. Alors pourquoi ?
- L'utilisateur n'a que faire de ces problématiques et la seule chose qu'il attend ce sont des outils qui répondent à ses besoins. Or, ces outils existent sous GNU/Linux ; ce qui signifie qu'ils ont été développés par des programmeurs qui ont passé outre les problèmes énumérés. Et au vue des programmes disponibles et de ceux qui sont en cours de réalisation, ces problèmes ne semblent pas si insurmontables que ça.

- L'utilisateur-développeur qui souhaite s'investir sur GNU/Linux va le faire pour l'environnement graphique qui a su faire battre son coeur : il choisira alors soit GNOME, soit KDE, soit Enlightenment ou encore GNUstep. Le problème va plutôt être celui qui voudra rester libre de tout desktop : que choisir ? Un toolkit basé sur Gtk+ ? Sur Qt ? Ou autre ?

Bref, l'ensemble des frameworks qui permettent de développer des applications est une réponse des communautés du libre à celles-ci ; autrement dit ils ont été développé par les développeurs du libre pour les développeurs du libre. Ils n'ont pas été réalisés pour les sociétés de l'industrie du logiciel. Il faut bien comprendre ceci pour appréhender cette différence d'approche qu'il y a avec Windows ou MacOs X.
C'est pourquoi, destinées aux entreprises, des réponses ont commencé à se dessiner : GNUe (http://www.gnuenterprise.org/) en est un exemple.

Je voudrais ici revoir certaines choses et les considérer sous un autre angle de vue :

- un ordinateur n'a pas besoin de logiciels pour fonctionner ; je peux l'allumer et il tourne ... certes, je ne peux rien en faire ici, mais le problème n'est pas là. (En effet, ce que je veux ce n'est pas un ordinateur, ce que je désire ce sont des outils qui me permettent de remplir certaines tâches)

- le logiciel a besoin d'un ordinateur pour fonctionner et donc
par là être utilisable ; l'ordinateur n'est qu'un support qui permet à des applications virtuelles de prendre vie. Finalement, la véritable problématique ne serait elle pas autour des logiciels et non des ordinateurs ?

- ensuite, de nos jours, pour qu'un logiciel puisse s'exécuter sur un ordinateur,
un système d'exploitation (SE) est nécessaire, sorte de glu, de conteneur qui s'interface entre la machine et les logiciels utilisateurs : il utilise et gère les ressources particulières de la machine afin de permettre à chaque logiciel de pouvoir fonctionner sans avoir à implémenter eux même les mécanismes d'accès et de gestion de ces ressources matérielles. Le SE peut être un choix important car il conditionne le choix des applications disponibles, notre façon de travailler, et l'efficacité avec laquelle certaines tâches dites systèmes peuvent être remplies (et qui conditionne donc indirectement l'efficacité des applications utilisateurs).

- ce que nous utilisons, ce sont des applications, dites utilisateurs, qui nous permettent de travailler sur des documents (au sens large du terme), d'automatiser des tâches, de se détendre, etc. L'ordinateur n'est que le support matériel qui permet à ceux-ci de s'exécuter, au travers d'un SE.

Note : ce que j'entend par SE est sa plus simple expression : une application d'interfaçage et de gestion des ressources matériels. Par exemple, l'environnement graphique est à mes yeux une simple application. Que cette dernière soit incorporée dans ce que l'on nomme SE n'est qu'un choix technique d'optimisation. De même un environnement texte.

- Pour la persistance, tu as à ta disposition un certain nombre de bases de données objet écrites en Smalltalk : Gemstone, celui que j'ai cité, est le plus connu, sinon il y a aussi Magma ou Glorp.

- L'image est au contraire idéale pour le déploiement car une image peut être chargée via le réseau à partir de ton environnement Smalltalk ou encore il suffit juste alors de saisir en ligne de commande par exemple : squeak monimage quelque soit la plate-forme.

- Dans squeak, toute la gestion de configuration et le travail en équipe est gérée de façon transparente. Pour gérer les différentes versions, en fait l'environnement sauvegarde chaque modification de ton image dans un fichier .changes qui contient toutes les modifications. Ce qui fait que si tu perd ton image, à partir de l'image d'origine, l'image finale peut-être reconstruite à partir de ce dernier fichier. Pour partager ton code et assurer de façon partagée la gestion de configuration, tu as ce que l'on appelle des serveurs squeaksource, équivalent aux sourceforge et l'outil Montecillo pour la gestion des révisions (+ d'autres outils). Tu as même des serveurs qui te permettent de travailler directement à partir de ton navigateur Web en utilisant le plugin squeak correspondant pour ce faire.

Hum, dans un tel monde virtuel, je choisirais alors l'environnement Seaside + squeak + gemstone + "ce qui va bien avec" pour construire une nouvelle application n-tier avec interface Web :-D

Mais, suis je bête, dans un tel monde, nous serions déjà dans des environnements virtuels 3D de type OpenCroquet qui reposerait sur un OS de type Plan9 et la construction de telles applications reposeraient sur le système collaboratif transparent de l'environnement qui lui même reposerait sur l'infrastructure distribuée transparente de l'OS ! Il s'agirait alors plus qu'à récupérer par drag&drop des objets par ci par là et de les assembler en décrivant leur relation (description syntaxique et sémantique), d'écrire de nouveaux objets graphiquement (aussitôt écrit, aussitôt instancié), puis d'exécuter le tout en modifiant à la volée le flot d'exécution pour corriger les éventuels bogues ou pour rajouter des évolutions sans remettre en cause l'exécution courante !

Bref, on a du chemin encore à faire ...