Journal Unix, que sont devenus tes concepts ?

Posté par (page perso) .
Tags :
1
25
avr.
2005
Bonjour,

Unix repose sur un certain nombre de concepts, dont celles-ci :
- performance. Le langage C a d'ailleurs été écrit dans cette optique : être suffisamment de bas niveau pour permettre de jouer au niveau de l'optimisation et fournir une syntaxe de haut niveau pour être plus facile à appréhender ;
- les programmes ne font qu'une et une seule chose et ils le font bien et jusqu'au bout. Le système offre un moyen de communication inter-programme qui permet à chacun, par combinaison, d'accomplir des tâches plus complexes ;
- tout est fichier (répertoire, fichier, périphériques, etc.). Le système de fichier devient ainsi un espace hiérarchique de nommage d'objets de nature diverse. L'approche d'Unix est donc filesystem-centric.

Je ne parlerai que de ce dernier point, qui est le concept le plus piétiné par les outils actuels. En effet, les environnements graphiques actuels, quelqu'ils soient, sous Unix, sont application-centric et non filesystem-centric.
Alors que l'on parle de SpotLight avec Tiger et de WinFS avec Longhorn, qui offrent tous deux un moyen à l'utilisateur d'indexer ses documents, donc d'abstraire encore plus leur système de fichiers, Unix, a contrario offrait à l'utilisateur par son système de fichier un moyen efficace de catégoriser ses documents ; tout simplement parce que tout est fichier. Ainsi, l'utilisateur a la main de créer lui même et hiérarchiquement ses catégories (les répertoires) et d'y déposer les documents qu'il souhaite, même de référencer ses documents dans des catégories différentes (avec les hyperliens durs ou symboliques). Et ceci de façon efficace et performante. Mais voilà, pour que ceci puisse marcher et être cohérent, il aurait fallu que les interfaces graphiques soient construites sur les concepts même d'Unix. Au lieu de cela, ils se sont fondés, et continuent encore aujourd'hui à l'aveugle sur le même chemin, sur des concepts à la Mac ou à la MS Windows.

Unix a tous les outils, la plupart datant de son origine, pour répondre de façon efficace aux attentes des utilisateurs. Les technos qui apparaissent dans les systèmes concurrents ne sont là, pour la plupart, que pour palier de mauvaises conceptions ou des conceptions qui se sont avérées erronées pour répondre au mieux aux demandes des usagers.
Un ordinateur manipule de l'information. Son utilisateur manipule des documents contenant de l'information. Sa vision première devrait donc être le document. Or, le concept d'Unix de "tout est fichier" et de filesystem-centric répond à cette attente. Aux IHM de transcrire correctement cette approche.
Ainsi, par exemple, je désirais mettre à jour des fichiers HTML sur mon site Web. Il m'a fallu pour cela, dans le pire des cas, utiliser un client FTP pour récupérer mes documents, ouvrir un éditeur pour les mettre à jour, et réutiliser le client pour rapatrier les modifications. Au mieux, avec par exemple Konqueror, j'utilise l'URL ftp du site Web pour éditer directement les documents en questions (en fait, les documents sont rapatriés dans /tmp et il faut donc quitter l'éditeur pour observer juste les modifs !). Alors que dans une conception filesystem-centric, j'aurait pu monter les système de fichier distant par FTP (ftpfs) sur mon système de fichier localement puis travailler directement sur les documents. Mais là, à la décharge des environnements graphiques, il aurait fallu que cette fonctionnalité puisse être fournie par le noyau Linux sans avoir à incorporer un hack (lua). Mais d'un autre côté, ces IHM l'auraient ils fait ? Après tout, leur gestionnaire de fichiers qui n'est qu'un outil parmi d'autre n'offre pas de moyens efficace de monter un partage samba.

Alors que l'on s'extasie sur les nouvelles technos provenant du monde Mac ou MS Windows, que l'on assiste à de grands discours sur le manque de disponibilité de technos équivalentes et que l'on doit vite faire quelque chose (sic), on continue à piétiner à l'aveugle les concepts fondateurs d'Unix sans s'apercevoir que, finalement, on dispose déjà des fondations pour faire toutes ces choses, voir plus. Manque t'on d'imagination ? Est t'on aveugle à ce point ? Ou tout simplement avons nous oublié qu'Unix, ce n'était pas seulement un système d'exploitation, mais aussi une philosophie derrière ?
  • # Merci !

    Posté par (page perso) . Évalué à 10.

    Non, tu n'es pas seul ! :)
  • # Au contraire: sortons du "tout fichier"

    Posté par . Évalué à 6.

    J'ai une vision à peu près diamétralement opposée, en ce qui concerne le "tout fichier" : pour moi c'est une approche qui date de la préhistoire, comme le "tout est carte perforée", et qui nous pourrit la vie au quotidien.

    Dans le détail:

    http://linuxfr.org/comments/137786.html#137786(...)

    http://linuxfr.org/comments/445967.html#445967(...)

    (Le premier lien est un commentaire de 2002 et depuis mon opinion n'a strictement pas changé)
    • [^] # Re: Au contraire: sortons du "tout fichier"

      Posté par (page perso) . Évalué à 4.

      Pourrais tu stp me dire en quoi le "tout est fichier" est si dépassé puisqu'au contraire, j'ai la nette impréssion qu'il revient encore plus d'actualité ?

      Dire que tout est fichier signifie finalement que tout est information, document (sous forme de fichier) et que c'est la première chose que l'utlisateur manipule. Or, aujourd'hui, quelque soit l'Unix utilisé, on a perdu ceci, ce qui donne des systèmes AMHA bancales, cad non cohérents. Les outils, graphiques, qui manipulent les fichiers ne sont que de simples outils annexes et qui ne vont pas au bout des choses. Peut être que c'est cette impression qui fait que tu crois que c'est dépassé alors que l'on applique même pas ce concept ; c'est d'ailleurs ce qui transpire dans les commentaires que tu cites.
    • [^] # Re: Au contraire: sortons du "tout fichier"

      Posté par . Évalué à -1.

      - gère et stocke tes méta-informations en-dehors du système de fichiers. Peu importe où et comment: dans une feuille de calcul, ou mieux, dans une base de données (SQLite par exemple... j'aime bien SQLite, je t'en ai déjà parlé ?!?)


      Ton rêve c'est ExcelFs? J'ai peur pour l'avenir!
    • [^] # Re: Au contraire: sortons du "tout fichier"

      Posté par (page perso) . Évalué à 4.

      Je ne vois pas en quoi l'idée de "tout est fichier" et ton idée du classement intelligent des données sont incompatbles.

      Tu prônes l'homogénéité, et le "tout est fichier" est une solution plutôt homogène (même si ce n'est pas la seule). Plutôt que d'avoir mes fichiers "bureautiques" dans des répertoire, mes mails dans une archive de ThunderBird et des URLs dans un boomark.html, je préfèrerais que ce soient tous des fichiers indépendants, avec les méta-infos qui vont bien pour faire des super-recherches-de-la-mort, et un filesystem optimisé pour plein de tout petits fichiers.

      Ensuite, on peut donner différents noms à ca, selon le point de vue. Certains parleront de base de données à la WinFS ... Why not, tant que l'implémentation répond au besoin !
  • # Unix, que sont devenus tes concepts ?

    Posté par . Évalué à 2.

    Perso, je m'extasie tellement devant les technologies Mac/Windows maladroitement importées sur Linux que j'en suis venu à utiliser ROX et BlackBox/IceWM (et dans une moindre mesure XFCE) depuis quelques années.

    Le but initial fut de retrouver la joie des mes premiers jours sous Linux où j'appréciais d'avoir fait mon petit bureau léger, personnel et paramétrable exactement comme je le souhaite, sans avoir la bloatitude (bloat attitude ?) des bureaux généralistes tels que KDE/GNOME. Ceux-cidoivent satisfaire le plus grand nombre au prix d'une consommation mémoire exorbitant, et d'une flexibilité qui n'atteint pas celle d'un bureau "assemblé soit même" qu'on ne fait de toute façon qu'une fois tous les 30 février, au plus les jours de pluie intense :)

    Par contre, bien que je n'utilises pas les bureaux GNOME/KDE, j'utilise quelques applications KDE/GNOME : Konqueror pour nettoyer mes espaces FTP en attendant que GFtp sache enfin deplacer les dossiers, Filer-Roller pour manipuler archives compressées et lire les images ISO, KNode pour les nouilles, ...

    « Je vous présente les moines Shaolin : ils recherchent la Tranquillité de l'Esprit et la Paix de l'Âme à travers le Meurtre à Main Nue »

    • [^] # Re: Unix, que sont devenus tes concepts ?

      Posté par . Évalué à 4.

      Tu as arrété GNOME ? Toi ?
      Tout fout le camp :)
      Sinon, à mon avis, l'héritage UNIX me convient parfaitement sur un serveur, mais ne me convient pas du tout sur un desktop. Ce qui me dérange le plus, c'est l'arborescence UNIX qui ne me semble pas du tout intuitive pour un débutant, et même pour un utilisateur intermédiaire.
      Je ne nie pas son intérêt pour un administrateur, mais pour un individuel sur son PC personnel, c'est un poid.
      • [^] # Re: Unix, que sont devenus tes concepts ?

        Posté par . Évalué à 10.

        > Ce qui me dérange le plus, c'est l'arborescence UNIX qui ne me semble pas du tout intuitive pour un débutant, et même pour un utilisateur intermédiaire.

        Unix n'a jamais eu la prétention d'être intuitif pour le débutant. Que les environnements utilisateurs qui tournent dessus le soient, passe encore, mais que l'OS doivent devenir aussi intuitif que Windows et remplacer/masquer une partie du système de fichier (/proc, /dev, /sysfs, ...) avec une opacité nommée "base de registre", non merci, je pense qu'on s'en passera.

        « Je vous présente les moines Shaolin : ils recherchent la Tranquillité de l'Esprit et la Paix de l'Âme à travers le Meurtre à Main Nue »

        • [^] # Re: Unix, que sont devenus tes concepts ?

          Posté par (page perso) . Évalué à 10.

          Sous Plan9, tu peux changer de "namespace" très facilement. C'est à dire que tu peux changer ta vision du système de fichiers. Un peu comme un chroot mais en mieux: tu peux assembler différentes arborescences pour créer la tienne (genre unionfs). À partir de là on peut imaginer un système de fichier plus "user-friendly" avec les trucs "inutiles" en moins qui sera celui de l'utilisateur lorsqu'il se log, tandis que le reste du système ne change pas.

          http://cm.bell-labs.com/sys/doc/names.html(...)

          pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

        • [^] # Re: Unix, que sont devenus tes concepts ?

          Posté par . Évalué à 2.

          Pas besoin d'avoir une base de registre. Il suffit de regarde gobo-linux pour voir que le système de fichier peut être intuitif sans cela. Après, à quoi sert à l'utilisateur /proc, /dev ou encore /sysfs ? S'ils était dans un répertoire /system, ça lui deviendrait tout de suite plus compréhensible.
          Comme tu dis, UNIX n'a pas fait pour êter intuitif pour un débutant, et mon opinion, c'est que c'est très dommage pour un OS qui aimerait passer grand public.
          • [^] # Re: Unix, que sont devenus tes concepts ?

            Posté par . Évalué à 9.

            > Comme tu dis, UNIX n'a pas fait pour êter intuitif pour un débutant, et mon opinion, c'est que c'est très dommage pour un OS qui aimerait passer grand public.

            Unix/Linux, c'est le système d'exploitation, c'est à dire la partie avec laquelle Madame Michou n'a pas de besoin vital d'inter-réagir : cette partie n'a donc pas besoin d'être vicéralement "Michou-friendly". C'est un peu comme le moteur d'une voiture, on conduit tous sans pour autant être des experts en mécanologie voituresque.

            Ce qui doit être "Michou-friendly", c'est ce qui lui permet de faire son travail, car pour Madame Michou, l'informatique est un outil : c'est un moyen et sûrement pas une finalité. Ainsi, ce sont les "environnements de travail" (places-y ce que tu veux dedans) qui vont fournir un niveau d'interaction et d'abstraction à l'utilisateur pour qu'il n'ait pas à se soucier de savoir que /proc/interrupts aurait mieux dans /system/proc/interrupts, d'autant qu'il n'y accède jamais autre que par des outils comme les moniteurs systèmes KDE et GNOME qui présentent des informations "brutes de pommes" sous forme Michounellement compréhensible.

            Alors tu sais, le /proc il faut bien le mettre quelque part, mais une chose est sûre, pour la famille Michou typique de l'utilisateur Grand Public, que le /proc soit dans /system, dans /Système, ou dans "/État Actuel du système", ça n'a aucune importance, c'est le genre de détails uniquement utile au technicien (par technicien, j'entends "toute personne ayant les droits pouvant modifier le système", et par utilisateur, j'entends "toute personne n'ayant pas le droit de modifier le système").

            Par contre, ça n'empêche pas que les choses peuvent être améliorées pour le technicien, et c'est ce que propose Gobo Linux. Parce que soyons clair : que tu mettes Madame Michou sous Gobo Linux ou sous <TaDistribFavorite> Linux, tant qu'elle a son environnement avec ses outils de travail et ses fichiers, elle ne vera aucune différence. Et si elle voit une différence gênante pour son travail dans l'emplacement de /proc, c'est qu'en fait notre Madame Michou n'est pas uniquement une utilisatrice, c'est déjà une technicienne.

            « Je vous présente les moines Shaolin : ils recherchent la Tranquillité de l'Esprit et la Paix de l'Âme à travers le Meurtre à Main Nue »

            • [^] # Re: Unix, que sont devenus tes concepts ?

              Posté par . Évalué à 1.

              Je ne suis que moyennement convaincu en fait par la différenciation que tu fais entre utilisateur/technicien. Madame Michou, si elle veut utiliser son ordinateur va se trouver un jour ou l'autre confrontée à des problématiques de technicienne. Imaginons qu'elle ait besoin d'un périphérique original, elle va être obligée de se plonger dans le système si elle n'a pas un technicien pour l'aider.

              Je ne crois pas que l'informatique puisse un jour permettre de faire une séparation totale entre les deux types d'utilisateur. Je travaillais il y a peu dans une entreprise de grande taille qui avait standardisé ses postes sous Windows XP en essayant de limiter l'accès à C: (contenant programmes et OS) de manière assez poussée. Ainsi, il n'était pas possible d'ouvrir le "poste de travail" et le lecteur C n'apparaissait même pas dans l'explorateur Windows. L'utilisateur avait à sa disposition un accès limité à un lecteur réseau seulement contenant ses fichiers personnels.

              J'en avais discuté avec des personnes dont le métier n'était pas du tout lié à l'informatique, et ceux-ci n'avaient même pas mis une semaine pour trouver un moyen de contourner le système mis en place.

              Bref, les utilisateurs confrontés à l'informatique deviennent très souvent plus "technicien" qu'on ne le croit.
              • [^] # Re: Unix, que sont devenus tes concepts ?

                Posté par . Évalué à 9.

                > Imaginons qu'elle ait besoin d'un périphérique original, elle va être obligée de se plonger dans le système si elle n'a pas un technicien pour l'aider.

                Désolé mais ici (sur Terre), quand on a besoin d'un spécialiste, on fait soit appel à des proches spécialisés qui coûtent un repas, soit on paie des spécialistes qui coûtent ce qu'ils coûtent. Et cela, que ce soit pour les voitures, les ordinateurs, les appareils ménager, ou que sais-je encore. Puis avant d'acheter, les gens (normaux) demandent toujours un avis dans leur entourage, surtout s'ils n'y conaissent rien.

                > Je ne crois pas que l'informatique puisse un jour permettre de faire une séparation totale entre les deux types d'utilisateur.

                C'est en forgeant qu'on devient forgeron. Ce n'est pas parce qu'on a planté trois clous dans sa vie qu'on est forgeron. Là est la différence entre l'expert et les autres (et ça ne s'applique pas qu'à l'informatique : c'est le principe même de la spécialisation).

                « Je vous présente les moines Shaolin : ils recherchent la Tranquillité de l'Esprit et la Paix de l'Âme à travers le Meurtre à Main Nue »

    • [^] # Re: Unix, que sont devenus tes concepts ?

      Posté par (page perso) . Évalué à 10.

      >Ceux-cidoivent satisfaire le plus grand nombre au prix d'une consommation
      >mémoire exorbitant

      Ca commence à me gonfler ce genre de FUD à un franc. C'est bien joile tout ca, mais avec ton fluxbox + firefox + thunderbird, tu es sur de consommer plus de ram qu'un desktop kde avec konqueror et kmail.

      Je me répete mais au taf sur un toshiba satellite k6 300 avec 64 Mo de ram, kde + konqueror + kmail sont utilisables tandis que la meme chose avec twm + firefox + thunderbird et la machine swap comme une malade...
      • [^] # Re: Unix, que sont devenus tes concepts ?

        Posté par . Évalué à 3.

        Ca commence à me gonfler ce genre de FUD à un franc15 centimes d'euros


        :-)
      • [^] # Re: Unix, que sont devenus tes concepts ?

        Posté par . Évalué à -1.

        >Ca commence à me gonfler ce genre de FUD à un franc. C'est bien joile tout ca, mais avec ton fluxbox + firefox + thunderbird, tu es sur de consommer plus de ram qu'un desktop kde avec konqueror et kmail.

        Tu ne peux pas raisonnablement comparer le lancement de 3 applications partageant la même infrastructure applicative (konqueror + kmail sous KDE) avec le lancement de deux instances totalement distinctes du moteur Gecko (ThunderBird et FireFox qui ne partagent pas le même moteur Gecko) sous un autre environnement, surtout sur une machine humanitaire comme la tienne ! Il faut savoir être raisonnable, et le fait que "ça te gonfle" n'est sûrement pas une excuse à la bêtise !

        « Je vous présente les moines Shaolin : ils recherchent la Tranquillité de l'Esprit et la Paix de l'Âme à travers le Meurtre à Main Nue »

        • [^] # Re: Unix, que sont devenus tes concepts ?

          Posté par (page perso) . Évalué à 1.

          Et alors?
          c'est fait exprès qu'ils partagent l'infrastructure pour réduire la consomation
          • [^] # Re: Unix, que sont devenus tes concepts ?

            Posté par . Évalué à 1.

            Sans blague ? On aurait presque dit que c'est ce que je pointais pour dire que sa comparaison n'est pas judicieuse, heureusement que tu es là pour nous éclairer !

            « Je vous présente les moines Shaolin : ils recherchent la Tranquillité de l'Esprit et la Paix de l'Âme à travers le Meurtre à Main Nue »

            • [^] # Re: Unix, que sont devenus tes concepts ?

              Posté par (page perso) . Évalué à 6.

              Pour résumer le thread :

              LiNuCe:
              KDE, ça puxor, ça bouffe de la RAM

              gnumdk:
              Ca bouffe pas tant de RAM que ça parce que ça partage des ressources

              LiNuCe:
              Mais non, ça n'a rien a voir

              Tu crois pas qu'il y a une erreur quelque part. On s'en fout de savoir comment ça marche. Ce qui compte pour l'utilisateur, c'est de savoir si ça swape ou pas.
      • [^] # Re: Unix, que sont devenus tes concepts ?

        Posté par . Évalué à 2.

        pour le mail, sylpheed est convivial et léger
    • [^] # Re: Unix, que sont devenus tes concepts ?

      Posté par . Évalué à 2.

      mc sait le faire , d'ailleurs mc est tellement beau , qu'il laisse a des années lumières les autres
  • # mouai

    Posté par . Évalué à 9.

    Troll sur le langage C
    Un programme ne doit pas seulement être rapide. Il doit aussi est sécurisé, maintenable, évolutif. Le langage C n'est pas toujours adapté à ces besoins.

    Indexation
    Les systèmes d'indexation des documents répondent à un besoin. Retrouver rapidement de l'information dans de fichiers de plus en plus grande.

    Aujourd'hui, l'utilisateur a plusieurs centaines de Mo (voir des giga) de mail, de documents, d'image, de vidéo...

    L'utilisateur ne peux plus classer efficacement l'ensemble de ces fichiers en utilisant une hiérachisation de répertoire. Ca prendrait trop de temps.

    Comment classe-t on des documents sur Unix?
    - On définit une hiérachie complexe de répertoires.

    Mail
    |--Inbox
    |-----Client 1
    |-----Client 2
    |-Projets
    |------ projet1
    |-----DOC
    |------ projet2
    ...

    - Par document, on définit un nom. (avec souvent une extension pour connaitre le type de fichier)

    On a aujourd'hui aucun moyen simple de faire la relation entre un mail, un document et un projet.

    Ce qui manque à l'heure actuelle, ce sont des méta-data pour l'ensemble des fichiers. Certains type de fichier ont été prévu pour garder une trace d'information supérieur au nom (comme les MP3, jpeg, png, doc) mais il faut bien un outil complémentaire pour pourvoir questionner cette base. (une sorte de find ou locate pour des méta-data).

    De plus On devrait permettre à un fichier texte (au mettre titre qu'on connait le proprio) d'avoir des informations externes au fichier permettant de relier un fichier à un projet. (NTFS le permet mais aucun système de fichier unixien ne peut le faire à l'heure actuelle) Si on avait suivit les concepts d'unix, ca aurait du être possible.

    Donc, les concepts d'unix sont amenés à évoluer et c'est tant mieux.
    • [^] # Re: mouai

      Posté par (page perso) . Évalué à 3.

      Tu classes tes documents en fonction d'une hiérarchie de répertoires, mais pas uniquement. Et ceci de la même façon que tu créés des catégories pour classer l'information que tu manipules. S'il s'avère complexe, c'est avant tout par ton fait, et tu aurais la même complexité avec d'autres techniques. Après, c'est une question de point de vue sur ton information (voir Plan 9 par exemple qui résout ce pb de façon élégante). Et non ça ne prend pas trop de temps de créer tes répertoires (catégories) et d'y classer tes docs si tu disposes des outils adéquat (c'est là où le bas blesse, j'en convient, car cela fait belle lurette que nous avons perdu l'aspect filesystem-centric dans nos applications quotidiennes).

      Sinon, effectivement, les besoins évoluent. Mais les bases sous Unix (filesystem-centric) existent et permettent, AHMA, efficacement d'implémenter des solutions répondant à ces besoins. Le pb est que ces bases ne sont même pas prises en comptes. Au lieu de les faire évoluer, les améliorer, on préfère implémenter des idées venant du monde MS Windows ou MacOS qui sont avant tout application-centric.

      Bien sûr, tout n'est pas noir non plus et il y a des tentatives. Par exemple, le système de fichier ReiserFS 4 qui permet d'ajouter des méta données relatives à un fichier ou groupe de fichiers.

      En fait, parce que tout est fichier, tu peux très bien imaginer un fichier de fichiers, ces derniers étant des groupes d'information, et qui permettent de référencer d'autres fichiers ... dans d'autres fichiers ou dans le même fichier composé ! Je pense qu'à ce niveau là (mais peut être que je me trompe) nous sommes limité que par notre perception (qui est tiré de nos connaissances actuelles et de nos habitudes) et par notre imagination.
      • [^] # Re: mouai

        Posté par (page perso) . Évalué à 7.

        > Et ceci de la même façon que tu créés des catégories pour classer
        > l'information que tu manipules. S'il s'avère complexe, c'est avant
        > tout par ton fait

        Meuh non, c'est surtout que tu essayes de classer dans un système à hiérarchie simple des objets qui ne sont pas hiérarchiques. Mes photos de vacance je les met dans /vacance/photo à coté de /vacance/preparation ou dans /photo/vacance à coté de /photo/famille ? ou encore dans /photo/2005/06/18 ? dans /2005/vacance/photos ?
        Et là mon exemple est simple parce que si dans mes photos de vacance j'en ai une qui représente ma cousine au cap d'agde ... va falloir savoir où je la met (vacance ? famille ? cousine ? cap d'agde ? un composé de tout ca ? dans quel ordre ?)
        Classer ça va encore mais quand on recherche la photo de la cousine, on risque vite de chercher dans plein de hiérarchie avant de trouver la bonne. Plus gênant encore quand on cherche toutes les photos (vacances ou pas vacances, 2005 ou 2004) de la cousine et qu'on a classé ça dans /vacance/2005/photos.

        Faire croire que les FS qu'on a sont adaptés aux stockages de documents pour un utilisateur c'est un gros mensonge.
        • [^] # Re: mouai

          Posté par (page perso) . Évalué à 7.

          >Meuh non, c'est surtout que tu essayes de classer dans un système
          >à hiérarchie simple des objets qui ne sont pas hiérarchiques. Mes
          >photos de vacance je les met dans /vacance/photo à coté de
          >/vacance/preparation ou dans /photo/vacance à coté de
          >/photo/famille ? ou encore dans /photo/2005/06/18 ? dans
          >/2005/vacance/photos ?
          >Et là mon exemple est simple parce que si dans mes photos de
          >vacance j'en ai une qui représente ma cousine au cap d'agde ... va
          >falloir savoir où je la met (vacance ? famille ? cousine ? cap d'agde ?
          >un composé de tout ca ? dans quel ordre ?)
          >Classer ça va encore mais quand on recherche la photo de la
          >cousine, on risque vite de chercher dans plein de hiérarchie avant de
          > trouver la bonne. Plus gênant encore quand on cherche toutes les
          >photos (vacances ou pas vacances, 2005 ou 2004) de la cousine et
          >qu'on a classé ça dans /vacance/2005/photos.

          >Faire croire que les FS qu'on a sont adaptés aux stockages de
          >documents pour un utilisateur c'est un gros mensonge.

          Non il n'est pas adapté mais :

          1) Il correspond a ce que fait ton outils ( Unix, filesystem,inodes... )
          2) Il ne demande pas d'intervention utilisateur à part le nom du fichier / répertoire
          3) Est-ce que le temps gagné à chercher "cousine" va être
          vraiment supèrieur au temps pris a tagué toutes tes photos *une par une*.
          Par exemple par rapport à un logiciel permettant le défilement de 8 images par 8 images très rapidement (à la souris / molettes ) à partir d'un répertoire photos
          4) Que ce passe--il si tu n'a pas tagué ( oublis ) une image.

          Le problèmes des méta-données c'est que cela fait intervenir dans la majorité des cas l'utilisateurs pour avoir un système cohérent.
          Cela demande un système plus intelligent et des utilisateurs plus disciplinés.

          En général les logiciels trop "intelligents" ont d'énorme effets de bord.
          Alors qu'un logiciel "outils" ( fait ce que je te demande et pas autre chose ) fonctionne correctement ( à défaut d'être parfait )



          • [^] # Re: mouai

            Posté par . Évalué à 6.

            En effet, à partir du moment où tu veux faire un programme "intelligent", il faut que cela soit très bien fait et jusqu'au bout, sinon c'est pire qu'un programme basique. Pour rester dans l'exemple donné des photos, je prendrais l'exemple de KimDaBa : http://ktown.kde.org/kimdaba(...)

            2) Il ne demande pas d'intervention utilisateur à part le nom du fichier / répertoire

            Oui, mais les possibilités de tri / de recherche ne sont pas suffisants.

            3) Est-ce que le temps gagné à chercher "cousine"

            En fait, tu ne rechercheras pas "cousine" dans ton arborescence parce que ce sera suffisemment chiant pour te décourager. Tu le feras une fois, deux peut-être, puis plus jamais. L'outil "hiérarchie du système de fichiers" te limites cruellement, tu pourras voir facilement les photos de tel évènement, mais pas par exemple les meilleures photos de ta bien aimée, donc tu ne le feras pas. Bref, c'est pas vraiment une quesion de gain de temps, mais plus une question de ne pas laisser croupir les photos dispersées dans de multiples répertoires.


            va être vraiment supèrieur au temps pris a tagué toutes tes photos *une par une*.

            Ca c'est le point crucial. Ne pas se laisser abuser par un screenshot qui dit : il suffit de faire un drag&drop, c'est trivial. La vraie question est : est-ce qu'on pourra le faire pour des milliers de photos.

            Avec une application comme iPhoto d'Apple, je me suis arraché les cheveux. Mais avec KimDaBa, ca va très vite :

            - on peut sélectionner dans un explorateur n'importe quel groupe d'images, notemment il y a une recherche incrémentale très pratique (on clique d'abord sur Cousine, puis on voit qu'il y en a encore 150, donc on clique sur "Location = Paris" pour filtrer)
            - deux modes pour tagguer une sélection : "Toutes en mêmes temps" (toutes les photos d'un répertoire se trouvent typiquement dans un seul lieu) et "Une par une" (pour dire quelles personnes se trouvent sur chaque photo)
            - très bonne utilisation du clavier qui permet d'aller vite. Typiquement pour dire quelles personnes se trouvent sur les photos, je sélectionne les images où y'a quelqu'un, Ctrl-1 (Une par une), touches Précédent/Suivant pour changer d'images, taper le nom suffit à créer une nouvelle personne (pas besoin de cliquer sur un bouton, bref d'utiliser tout le temps tantôt la souris tantôt le clavier comme dans iPhoto), autocomplétion qui fait qu'il suffit dans 90% des cas de taper la première lettre d'un nom de personne utilisé récemment
            - dans la version CVS, il y a en plus un systèmes de tokens qui permet de renseigner les photos pendant un slideshow sans l'interrompre (ce qui serait ultra-chiant), qui roxe pas mal. En gros, à chaque fois que tu vois qu'il manque une personne, tu tapes juste 'p', à chaque fois que tu vois une image à retoucher avec gimp, tu tapes 'g' ), et à la fin du slideshow tu retrouves ces images (touche tapée == 'p') et tu fais les changements d'un coup.

            Bilan : quand je vide mon appareil photo avec une carte de 256Mo, j'y passe en général 1/4 d'heure à les renseigner, ce qui est raisonnable. J'ai ainsi dans les 3000 photos entièrement renseignées et je connais des gens qui sont dans les 11 000. Bref, Ca Marche(TM) !

            4) Que ce passe--il si tu n'a pas tagué ( oublis ) une image.
            Tu peux toujours
            - chercher par répertoire
            - entrer une date / un intervalle
            - chercher [Aucun mot clé/Aucune personne/Aucun lieu] et tagguer les photos manquantes


            1) Il correspond a ce que fait ton outils ( Unix, filesystem,inodes... )

            En soi je m'en fous, le problème ici c'est l'interopérabilité avec les autres logiciels, j'aimerais bien utiliser les fonctions de recherche de KimDaBa dans les applications qui n'ont que la notion de fichier/répertoire. Mais j'ai un bon truc :

            Disons que j'ai 15 photos de ma cousine dans 5 répertoires différents et que je veux utiliser un outre outil qui réclame qu'il soit dans le même répertoire.
            1- dans kimdaba, je clique sur "cousine" et je les sélectionne
            2- je fais un glisser déposer vers un dossier vide de konqueror
            3- konqueror me propose de faire des liens symboliques
            4- lancer l'application, le tour est joué
            5- je peux effacer le dossier après
          • [^] # Re: mouai

            Posté par (page perso) . Évalué à 5.

            > 1) Il correspond a ce que fait ton outils ( Unix, filesystem,inodes...)


            Le fond du discours c'est bien dire que justement, le système tout fichier sur FS hiérarchique dans les bases unix ça n'est plus du tout adapté à la masse de documents qu'à à traiter un utilisateur.
            Le justifier en disant que ça marche ainsi c'est se mordre la queue.

            > 2) Il ne demande pas d'intervention utilisateur à part le nom du
            > fichier / répertoire

            Est ce que réellement taper "photo 2005 vacances" est plus long que de taper le nom et l'adresse du fichier ? je ne pense pas. Ca demande exactement le même niveau d'interactions, ça me semble même plus simple et naturel de fournir des catégories qu'un nom de répertoire/fichier.

            > 3) Est-ce que le temps gagné à chercher "cousine" va être
            > vraiment supèrieur au temps pris a tagué toutes tes photos *une
            > par une*.

            Pour toutes les photos peut être pas.
            Maintenant si j'ai une belle photo de ma cousine que je repère, la marquer quand je sais qu'elle est là (donc pouvoir le faire) est bien plus avantageux que de tout rechercher dans la masse 2 mois après.
            Même chose pour des utilisations moins "massives" que les photos. Le plus souvent j'édite mes documents un à un, et dans ce cas là mettre une série de catégorie est aussi rapide que de mettre un nom de fichier ... bien plus simple et bien plus efficace.

            > 4) Que ce passe--il si tu n'a pas tagué ( oublis ) une image.

            Que se passe t'il si tu as oublié de mettre un nom à ton fichier ? de le mettre dans un répertoire ?

            Le système te force à mettre un nom et une hiérarchie de répertoire. Je ne vois pas pourquoi, si on remplace ça par un système nom+mot clé ça changerait quoi que ce soit.

            Après ta question est peut-être savoir ce qu'il se passe si je tag par lot (toutes mes images de vacances) sans détailler ? ben j'aurai exactement la même problématique qu'avant, pas pire, mais un peu plus simple :
            - je pourrai chercher toutes les photos sans chercher à 150 endroits dans le disque où est-ce que j'ai fait un sous répertoire "photo"
            - la première fois que je recherche ou visualise j'aurai possibilité d'affiner mon classement sur les fichiers/images qui valent le coup

            > Le problèmes des méta-données c'est que cela fait intervenir
            > dans la majorité des cas l'utilisateurs pour avoir un système
            > cohérent.
            > Cela demande un système plus intelligent et des utilisateurs plus
            > disciplinés.

            C'est vite oublier que ton nom+répertoire+hiérarchie c'est déjà une métadonnée, qu'elle fait déjà intervenir l'utilisateur ... quelle différence fondamentale d'interaction si je lui demande une catégorie au lieu d'un répertoire ?
            C'est au contraire avec des répertoires hiérarchiques que tes utilisateurs doivent être disciplinés pour ne pas en mettre de partout et pouvoir retrouver leurs petits (qui ici n'a jamais été confronté à une problématique de "comment organiser ses répertoires parce que ça devient le bordel" ?).
            Avec des systèmes de catégories ça reste une problématique utilisateur mais c'est un système "a plat", qui pose beaucoup moins de problèmes pour les recherches et les choix de stockage.


            Note: je ne dis pas que le système de tag soit la panacée ni même que ce soit forcément une bonne idée à mettre en pratique, mais le système actuel est clairement mauvais à mes yeux (et pour l'instant un système de tag a l'air de répondre à ma problématique à court terme)
            • [^] # Re: mouai

              Posté par (page perso) . Évalué à 2.

              >Le fond du discours c'est bien dire que justement, le système tout
              >fichier sur FS hiérarchique dans les bases unix ça n'est plus du tout adapté à la masse de documents qu'à à traiter un utilisateur.
              >Le justifier en disant que ça marche ainsi c'est se mordre la queue.

              Oui mais il y a l'existant.
              Oublier cela c'est utopique
              Si il n'y avait pas d'existant cela fait longtemps que l'on utiliserait pas un ordinateur, des protocoles et des formats de fichiers tel qu'on les connait actuellement ....

              Note 1 : d'ailleurs tout les systèmes de moteurs de recherche intégré à l'OS repose sur un filesystem "classique".


              >quelle différence fondamentale d'interaction si je lui demande une
              >catégorie au lieu d'un répertoire ?

              Un fichier est unique. Un système par catégorie ( choisi par l'utilisateur ) ne l'ai pas.



              En tout cas je suis impatient de voir ces systèmes là en oeuvre.
              C'est toujours une experimentation interessante même :

              1) si je pense que cela reste réservé à des "power users" de part ca complexité
              2) Que les logiciels qui font cela de façon générique (autre chose qu'un player MP3 avec une base sqlite derière) ne semble pas faire ces preuves ( ex : le GED dans l'entreprise demande un tel effort à l'utilisateur que cela est rarement efficace)


              On arrivera certainement comme souvent à un mixte entre les diverses solutions :
              Utilisation de base pour des données facilement et automatquement indexable ( ex : CDDB / lecteur ogg/mp3 ... )

              Utilisation du bon vieux système de fichiers pour le reste :)


              • [^] # Re: mouai

                Posté par (page perso) . Évalué à 4.

                > Oui mais il y a l'existant.
                > Oublier cela c'est utopique

                Certes, mais laisse moi être utopique un instant.

                Imagines un driver de FS qui fasse que quand on écrit un fichier sous /photo/vacances/2005/ ça écrive simplement un fichier en l'associant aux catégories photo, vacances et 2005 ?
                Imagines que quand j'essaye de le relire, entrer dansle répertoire vacance me rend disponnible dans ce répertoire tous les fichiers sous la catégorie "vacance", que si je rentre dans /vacance/2005 ça me sélectionne les fichiers dispo sous vacance et sous 2005 ?

                Il y a certainement d'autres problèmes à voir mais techniquement ça résoud une bonne dose de compatibilité. Si on réserve ce type de FS aux docs utilisateurs (il ne s'agit pas forcément de changer tout le système qui marche déjà) ça peut être faisable.

                > Note 1 : d'ailleurs tout les systèmes de moteurs de recherche intégré à l'OS
                > repose sur un filesystem "classique".

                Pour l'instant, pour l'instant. Avec ce genre de phrases on n'avancera jamais.
                Ceci dit rien n'empêche de faire mon joli système avec un "vrai" FS comme backend derrière.

                Dans la démarche "moteur de recherche" on a Beagle qui pousse. C'est un "mieux que rien" mais ça ne te permettra jamais de retrouver la photo de ta cousine : il n'y a rien qui permet de spécifier un mot clé ou une méta donnée pour qu'elle soit relue plus tard.

                > Un fichier est unique. Un système par catégorie ( choisi par l'utilisateur ) ne l'ai pas.

                Un fichier est unique, ses categories ou ses répertoires ne le sont pas. Je ne vois aucune différence ici entre le système avec ou sans répertoire. Encore une fois, que je fasse "vacance + 2005 + photo"/photo2002154.jpg ou /vacance/2005/photo/photo2002154.jpg lors de l'enregistrement ça ne change rien, ni pour le système ni pour l'utilisateur.

                > 1) si je pense que cela reste réservé à des "power users" de part ca complexité

                C'est là surtout qu'on rentre en conflit (parce que sur les problèmes de compatibilité ou de développement je suis d'accord qu'il faudra du boulot). Pour moi le concept même d'un entrepot hiérarchique *est* complexe à terme. Il suffit de prendre n'importe quel néophyte ramer pour retrouver ses fichiers et avoir plein de versions à plein d'endroits différents. Et même moi qui commence à avoir trop de fichiers, je galère régulièrement avec le système des dossiers.
                Donner des mots clés me semble toujours plus simple que donner un chemin, au pire c'est équivalent (si tu fais une bijection répertoire-mot clé).


                > Que les logiciels qui font cela de façon générique

                Oui, mais là où je suis d'accord avec l'auteur de la news c'est que ... c'est au FS de gérer la problématique de gestion des fichiers, pas à l'applicatif. Se baser sur l'applicatif veut dire que toutes les applis ne pourront pas relire ton classement.
                Ou alors tu demandes à toutes les applis d'implémenter une lib commune, et tu viens de réimplémenter un système par dessus le système, je n'en vois pas l'intérêt si ça peut être géré directement par le système de fichier.
                • [^] # Re: mouai

                  Posté par . Évalué à 3.

                  c'est au FS de gérer la problématique de gestion des fichiers, pas à l'applicatif.

                  Pas d'accord du tout.
                  Le besoin que tu décris (trouver une photo) n'est pas un besoin universel, c'est juste une opération que tu vas vouloir faire de temps en temps. Faut-il casser (bah oui, casser, parce que modifier les filesystems sous unix de façon aussi radicale, ça doit bien avoir un ou deux effets secondaires) les systèmes de fichiers juste pour retrouver des photos ?
                  Alors qu'il suffirait, en plus du filesystem, de stocker une base de données de mots-clé associés aux fichiers (et tant qu'on y est, pour rester dans le "modèle" unix, il suffirait d'une ou deux commandes pour gérer ces tags et faire les recherches associées ; bah tiens, ça ferait une jolie extension à find aussi).
                  • [^] # Re: mouai

                    Posté par (page perso) . Évalué à 2.

                    > Le besoin que tu décris (trouver une photo) n'est pas un besoin universel

                    Le besoin que je décris c'est "trouver un fichier sans avoir à retenir son identifiant unique complet". Si ça ce n'est pas une problématique de base pour un système de stockage je ne sais pas ce que tu entend par besoin universel.

                    Ca peut être une photo, un programme, un document Word ou tout ce que tu veux, ça revient bien au même. J'ai toujours deux manière d'accéder à un fichier :
                    - par son identifiant (inode ou chemin dans le FS)
                    - en recherchant

                    Pour une recherche la gestion de mots clés me semble mieux résoudre le problème que la gestion de dossiers hiérarchiques arbitraires (et rien n'empêche de présenter mes mots clés sous forme de dossiers si tu préfères, l'inverse n'est par contre pas possible simplement).
                    Ca me parait justement un besoin basique propre au FS ça.

                    > Alors qu'il suffirait, en plus du filesystem, de stocker une base de
                    > données de mots-clé associés aux fichiers

                    Si cette base finit par être intégrée de la même façon qu'un journal ou que les attributs étendus, ça revient pour moi à dire que c'est dans le FS. Après que en interne il stocke et une hiérarchie classique et un mini moteur de mot clé ou qu'il se base uniquement sur le mini moteur ... c'est du domaine de l'implémentation interne et ça ne me concerne pas.
                    • [^] # Re: mouai

                      Posté par . Évalué à 2.

                      Le besoin que je décris c'est "trouver un fichier sans avoir à retenir son identifiant unique complet". Si ça ce n'est pas une problématique de base pour un système de stockage je ne sais pas ce que tu entend par besoin universel.

                      J'entends par là : on passe tout de même plus de temps à créer/modifier/regarder des fichiers qu'à les perdre ou les chercher (ou alors t'es vraiment un gars bordélique et c'est pas un problème de l'OS).

                      [...] c'est du domaine de l'implémentation interne et ça ne me concerne pas.

                      Alors pourquoi autant insister sur le fait que c'est le boulot du filesystem ?
                      Une surcouche aux filesystems existants serait amplement suffisante, et ça aurait le bon goût d'être optionnel (je doute que cette fonctionnalité soit utile en dehors des répertoires des utilisateurs).

                      Hmmm quelqu'un a déja utilisé setfattr et getfattr ? Ça pourrait servir, non ?
                      • [^] # Re: mouai

                        Posté par (page perso) . Évalué à 2.

                        > J'entends par là : on passe tout de même plus de temps à créer/modifier/regarder
                        > des fichiers qu'à les perdre ou les chercher

                        Ce qui ne veut pas dire que le temps perdu à les chercher ne devrait pas être réduit. Sinon on perd plus de temps à dormir qu'à faire les idiots au boulot, est-ce que ça implique que faire les idiots au boulot est productif ?

                        Ca ne veut rien dire ta comparaison. Je perd du temps à chercher des fichiers. Quand je regarde dans mes relations, c'est pour pareil tout le monde (en général ça s'agrave avec la quantité de données, et personnellement mon sous arbre réservé aux documents se compte en Go, sans les musiques ou vidéo)
                        Je perd du temps et j'en perd trop. Que je passe aussi beaucoup à d'autres choses n'a rien à voir, surtout si les autres choses sont productives, elles (comme modifier/lire un fichier).

                        > Alors pourquoi autant insister sur le fait que c'est le boulot du filesystem ?

                        Pour que tout ce qui tourne sur ma machine puisse en profiter ? pour ne pas arriver à la même chose que le super gnome-vfs qui au final n'est pas des masses utilisable car pas supporté par toutes les applis ?
                        Aussi parce qu'à ce moment là ça veut dire que je garde toujours le fait de demander un chemin d'accès à l'utilisateur, et que l'utilisateur ne saura pas quoi donner.

                        Et peut être simplement ... parce que c'est la bonne place pour faire ça. On peut tout faire en espace applicatif, est-ce que ça veut dire que tout doit y être fait ?
                  • [^] # Re: mouai

                    Posté par (page perso) . Évalué à 2.

                    Comme amarok pour le musique en somme?
        • [^] # Re: mouai

          Posté par . Évalué à 6.

          Ca me fait penser à ce que me disait un prof à propos d'XML, et de tous les systèmes hiérachique en général (et donc la philosophie du fs sous unix) : c'est pas mal pour des utilisations simples, mais des fois on a besoin d'un classement des choses un peu plus évolué. C'est ce que tout le monde dit dans les commentaires de ce journal pour l'instant.

          Mais alors, quel système est plus puissant? Bah, c'est pas un truc nouveau : les systèmes relationnels. Et donc, la plupart des BDD actuelles (sachant que beaucoup existent depuis plus d'une dizaine d'années). On n'a plus une vue hiérachique, et on est beaucoup moins limité. Les relations entre les objets (ou fichiers si vous voulez) ne sont plus uniquement pere/fils, mais peuvent etre n'importe quoi. Imaginez qu'on puisse créer des vues (oui, comme en SQL) sur un bout des relations, afin de se simplifier la vie sur l'organisation de ses données.

          Pour faire l'analogie avec les structures de données, les systèmes hiérarchiques sont des arbres, alors que les systèmes relationnels sont des graphes (orientés). Rappelons qu'un arbre est un cas particulier de graphe, c'est un graphe orienté sans cycle. Bon ok, avec les liens (symbolique ou non) on cree un peu plus qu'un arbre (puisqu'on a des chaines, mais pas de cycles, ou l'inverse, mais mes souvenirs sont pas supers frais). Mais ca reste toujours un arbre a la base.

          J'espère que mes explications sont pas trop erronnées, car en relisant je suis pas tout à fait sur de l'exactitude de mes souvenirs sur les structures de données.
        • [^] # Re: mouai

          Posté par . Évalué à 1.

          [troll]
          ln -s ....
          [/troll]
          • [^] # Re: mouai

            Posté par . Évalué à 5.

            Tu peux virer l'option -s !

            Les liens symboliques sont pratiques mais les gens ont un peu trop l'habitude de les utiliser. Ils créent un fichier à chaque fois, consomment un inode, et sont un peu trop souvent utilisés pour remplacer les raccourcis Windows à mon goût.

            Les liens durs permettent précisément de faire ce qui est imaginé par bon nombre de personnes qui ont posté ici : Classer le même fichier dans plusieurs catégories différentes tout en le repérant par un identifiant unique : son inode. Et donc de faire en sorte qu'il n'existe qu'une seule fois sur le disque.

            Bon nombre des prétendues innovations sont en fait des concepts existants présentés d'une autre façon. On risque de cette manière d'introduire, dans le standard d'un système d'exploitation, des doublons sans s'en rendre compte et dont il sera difficile de se débarrasser par la suite.
            • [^] # Re: mouai

              Posté par (page perso) . Évalué à 2.

              Les liens physiques c'est aussi très peu intuitif et très lourd à manipuler. Cas classique : Je veux faire de la place sur le disque. Il faut que je recherche toutes les occurence d'un contenu, et je n'ai pas de commande simple et rapide pour faire ça.
              Le gros défaut : impossible de simplement et rapidement lister tous les noms d'un fichier, impossible aussi (du coup) d'effacer un contenu avec l'assurance qu'il n'est pas référencé ailleurs.

              Ce n'est pas pour rien qu'ils sont si peu utilisés. Ils sont pertinents dans des utilisations bien précises, peu recommandables en règle générale.
              • [^] # Re: mouai

                Posté par . Évalué à 2.

                Tous ces arguments sont vrais et pour autant, j'aimerais quand même les voir un peu plus répandus, car je pense que le principal frein est encore la méconnaissance de cette facilité par les utilisateurs.

                En effet, pour retrouver toutes les instances d'un même fichier (repéré par son inode), il faut utiliser find --inum /, mais au moins on est sûr de le retrouver. Sais-tu en faire de même pour retrouver tous les liens symboliques devenus orphelins ?

                Pire encore : Si les gens font des copies locales du fichier, non seulement l'espace disque ne sera pas libéré, mais il aura été consommé en quantité bien plus importante qu'avec des liens, et pour le coup il n'y aura plus aucun moyen de savoir si le fichier est censé être une copie locale de l'original ou s'il doit maintenant vivre une « vie » propre, surtout s'il a été modifié.

                Avec un lien dur, on ne sait peut-être pas initialement où se trouvent toutes les instances, mais on sait au moins immédiatement combien il y en a.
  • # Kioslave

    Posté par . Évalué à 2.

    Je ne connait pas suffisament la problematique pour dire si c'est faisable ni de la manière de le réalisé (dans le noyau / dans une couche d'abstraction etc...).

    Mais ce que j'imagine comme le plus pratique pour l'utilisateur final (moi) c'est exactement ça. Que kwrite aille directement éditer mon html sur le ftp.

    J'ai trouvé (et encore maintenant malgrès tout) que les kioslaves remplissait vraiment cette fonction. J'aime kde pour ça.

    Mais j'ai un peu déchanté quand je me suis retrouver avec des problèmes de droit sur le fichier *.part que kde n'arrivait pas a renommer...
    Je n'ai pas cherché donc c'est peut être de ma faute mais en tout cas ça montre bien que l'idéal serait de ne pas recourir à ces "bidouilles".
    • [^] # Re: Kioslave

      Posté par . Évalué à 1.

      Je ne connais pas ta config. Mais j'édite mes fichiers sur mon ftp de manière totalement transparente avec Quanta. Je les sauve sur le FTP comme s'ils étaient sur mon disque.
      • [^] # Re: Kioslave

        Posté par . Évalué à 1.

        Oui, moi aussi.
        Je ne l'ai pas dit, mais ça fonctionne souvent très bien.
        Surtout par ftp. Mais sur un serveur en ssh j'ai ce problème.

        Au passage : j'utilise ssh:// au lieu de fish:// que je vois un peu partout.
        Je ne sais pas si il y a des différences. Je n'ai jamais essayé, mais c'est peut être cela.
        • [^] # Re: Kioslave

          Posté par . Évalué à 1.

          La différence c'est que fish:// a besoin du support sur serveur ssh, alors que ssh:// marche partout. (à moins que ce ne soit l'inverse)
          • [^] # Re: Kioslave

            Posté par (page perso) . Évalué à 1.

            C'est l'inverse ;)
            fish utilise la commande ssh, genre quand tu tape sftp://user@machine(...) , il lance un ssh user@ machine ls. C'est un peu usine à gaz
            • [^] # Re: Kioslave

              Posté par (page perso) . Évalué à 1.

              il fallait bien sur lire fish://user@machine ;)
              • [^] # Re: Kioslave

                Posté par . Évalué à 1.

                En fait fish upload un script perl sur la machine distante servant de serveur (.fishsrv.pl si jme rappelle bien) pour gérer les commandes de bases et un peu plus (liste des fichiers, stat de ceux-ci, déplacement, resume des uploads...). Si perl n'est pas sur la machine distante, ce sont les commandes shell qui sont utilisées
  • # Et bien ?

    Posté par . Évalué à 7.

    Alors que dans une conception filesystem-centric, j'aurait pu monter les système de fichier distant par FTP (ftpfs) sur mon système de fichier localement puis travailler directement sur les documents.

    Tu le dis toi mêmes, c'est exactement ce qu'on peut faire avec Konqueror toute application KDE, il suffit de taper l'URL dans la boîte de fichiers.
    La question suivante, c'est de savoir comment on peut unifier ca avec Gnome-VFS ou autres. Si déjà ils utilisaient les mêmes URLs, ce serait un grand pas en avant.

    - les programmes ne font qu'une et une seule chose et ils le font bien et jusqu'au bout.

    Un environnement moderne fait également bien une seule chose, mais du point de vue de l'utilisateur, rejoignant la révolution engendrée par le macintosh : "se servir de sa caméra numérique" par exemple forme un tout, donc on regroupe dans une seule appli gphoto pour télécharger les images / des fonctionnalités d'édition basiques / des capacités de rangement et de recherche des images / des capacités d'export (html, sur CD, ...)

    Bref, ce n'est pas Application-centric, mais User-centric nuanace.

    Par contre du point de vue interne, technique, rien n'empêche de réutiliser les principes fondateurs d'Unix. Et en effet, gphoto2 est développé à part, les bonnes applis sont très modulaires (KIO, Kparts), ...

    Le système offre un moyen de communication inter-programme qui permet à chacun, par combinaison, d'accomplir des tâches plus complexes ;

    Le systèmes des pipes ofre un moyen de communication inter-programmes beaucoup trop limité, intrinsèquement lié à la notion de filtres, qui est avantageusement remplacé par dcop qui offre pour du beurre à toutes les applis des possibilités d'extensions. AmaroK est un formidable example de cela :

    http://amarok.kde.org/wiki/index.php/Scripts(...)
    http://amarok.kde.org/wiki/index.php/Script-Writing_HowTo(...)
    • [^] # Re: Et bien ?

      Posté par . Évalué à 2.

      J'aime bien dcop, c'est effectivement bien pratique.
      Mais dans l'idée de compatibilité : pourquoi ne pas avoir utilisé dbus dans kde ? Peut être cela n'était pas encore au point ?

      C'est quand même dommage de limité ça aux applis kde... il y avait une bonne raison à cela ?
      • [^] # Re: Et bien ?

        Posté par . Évalué à 8.

        La raison c'est que dbus n'existait pas encore quand dcop a été introduit dans KDE. Maintenant encore ils hésitent à remplacer dcop car dbus n'offre pas grand chose d'intéressant en plus, et n'est pas aussi stable.
      • [^] # Re: Et bien ?

        Posté par (page perso) . Évalué à 2.

        dbus est en partie issu de dcop ...
    • [^] # Re: Et bien ?

      Posté par . Évalué à 6.

      > La question suivante, c'est de savoir comment on peut unifier ca avec Gnome-VFS ou autres. Si déjà ils utilisaient les mêmes URLs, ce serait un grand pas en avant.

      L'accès FTP par GNOME VFS, en tout cas tel qu'il est mis en oeuvre dans Nautilus, est loin d'être aussi utilisable que la technologie KDE mise en oeuvre dans Konqueror.

      Personnellement, avec Nautilus, je trouve la chose catastrophique : l'édition distante doit se faire par l'application à laquelle Nautilus passe l'URL du document, alors que Konqueror télécharge une copie localement, puis met la copie distante à jour à l'enregistrement - ce qui rend virtuellement toute application utilisable avec Konqueror, alors qu'avec Nautilus, si l'application ne gère pas le protocole distant, tu l'as dans l'os.

      Peut être est-ce possible de faire en sorte que Nautilus procède comme Konqueror, mais ce n'est pas par défaut d'une part (ce qui est dommage), et je n'ai rien trouvé en ce sens.

      « Je vous présente les moines Shaolin : ils recherchent la Tranquillité de l'Esprit et la Paix de l'Âme à travers le Meurtre à Main Nue »

      • [^] # Re: Et bien ?

        Posté par (page perso) . Évalué à 1.

        En même temps si je fais bouton droit sur un .avi de 700 Mo, lire avec mplayer, et que ce con de KDE commence à le pomper, je préfères largement qu'il se contente de faire comme Nautilus et qu'il passe l'url à mplayer :)

        Comme quoi tout dépend de ce que le soft veut faire avec le fichier, dans un cas le choix de KDE est plus "pratique", dans l'autre pas.
        • [^] # Re: Et bien ?

          Posté par . Évalué à 1.

          Ah ben c'est sûr que toute solution a ces avantages et ces inconvénients. En tout cas en attendant l'hypothèse qu'un jour toutes les applications gèrent de manière transparente les accès distants, je trouve que la solution de Konqueror est la plus approprié pour moi vue l'utilisation que j'en fait.

          Un autre problème que je n'ai pas évoqué mais qui est très ennuyeux avec la solution Nautilus, c'est que si j'accèdes à un FTP via une authentification login/password, l'application à laquelle Nautilus passe l'URL devra de nouveau ouvrir une connection et s'authentifier, alors qu'avec la solution Konqueror, je n'ai pas ce "problème". Par contre, "à cause de ça", Nautilus m'a permi de découvrir que je pouvais ouvrir un fichier via FTP avec authentification directement depuis Vim en lui passant l'URL :)

          Enfin, encore un autre problème que je n'ai pas évoqué : certains FTP n'autorisent qu'une seule connection FTP (ftpctrl + ftpdata) : avec la solution Nautilus, l'application à laquelle Nautilus passe l'URL devra s'authentifier une fois de plus (exemple : Vim). Avec Konqueror, le problème n'existe pas puisque l'application modifie un fichier téléchargé localement via la connection Konqueror.

          « Je vous présente les moines Shaolin : ils recherchent la Tranquillité de l'Esprit et la Paix de l'Âme à travers le Meurtre à Main Nue »

          • [^] # Re: Et bien ?

            Posté par (page perso) . Évalué à 6.

            Konqueror fait en fait les deux, en fonction de l'application.
            (un %u ou un %f dans le fichier .desktop)

            la majorités des applicaitons KDE sont capable d'ouvrir une URL, et enregistrer aussi, si possible. (en utilisant l'API de KIO)

            Si l'application ne sait pas géré les URL, alors le fichier est enregistré sur le disque. Une barre de progression s'affiche, muni un boutton annuler , au cas ou on aurais cliqué sur un .avi de 700Mo



    • [^] # Re: Et bien ?

      Posté par (page perso) . Évalué à 4.

      il suffit de taper l'URL dans la boîte de fichiers.
      La question suivante, c'est de savoir comment on peut unifier ca avec Gnome-VFS ou autres.
      Quoi de mieux donc que de gérer ça directement au niveau du système de fichiers ? Ca serait pas intéressant de pouvoir faire $EDITOR /ftp/example.org/foobar/baz.html ? Pas besoin de gérer ça au niveau de l'application. Sauf éventuellement pour traduire l'URL en chemin d'accès sur le système de fichiers. Et un daemon (factotum dans le cas de Plan9) à part qui s'occupe de l'autentification. Mais là encore, l'application n'a pas à s'en occuper, c'est juste le ftpfs qui doit discuter avec le daemon pour savoir quel user/passwd envoyer au serveur. Le problème de Gnome-VFS et le machin de KDE c'est que c'est spécifique à ces systèmes. Si on fait ça au niveau de l'OS comme sous Plan9 ou Hurd (les translators), on a plus ce problème.

      Pour les pipes j'ai pas creusé la quesion mais les gens de Plan9 l'on fait (je sais pas ce que ça donne par rapport à dcop): http://cm.bell-labs.com/sys/doc/plumb.html(...)

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

  • # annuaire vs. moteur

    Posté par . Évalué à 10.

    Alors que l'on parle de SpotLight avec Tiger et de WinFS avec Longhorn, qui offrent tous deux un moyen à l'utilisateur d'indexer ses documents, donc d'abstraire encore plus leur système de fichiers, Unix, a contrario offrait à l'utilisateur par son système de fichier un moyen efficace de catégoriser ses documents ; tout simplement parce que tout est fichier. Ainsi, l'utilisateur a la main de créer lui même et hiérarchiquement ses catégories (les répertoires) et d'y déposer les documents qu'il souhaite, même de référencer ses documents dans des catégories différentes (avec les hyperliens durs ou symboliques).

    Dire que c'est suffisant, c'est un peu dire que l'annuaire Yahoo est suffisant et qu'on n'a pas besoin du moteur Google pour explorer le Web...
    Classer des documents dans une structure hiérarchique propre et correctement maintenue est un boulot à part entière, qui demande formation et mérite salaire (documentaliste). La plupart des utilisateurs n'ont ni le temps ni l'expérience nécessaires.

    (quant aux hyperliens durs ou symboliques, c'est quand même une plaie à gérer si tu ajoutes/supprimes souvent des fichiers)
    • [^] # Re: annuaire vs. moteur

      Posté par (page perso) . Évalué à 3.

      Le pb vient que l'on ne dispose pas des outils adéquats et qui font correctement le boulot et jusqu'au bout, le tout de façon transparente pour l'utilisateur.
    • [^] # Re: annuaire vs. moteur

      Posté par (page perso) . Évalué à 2.

      A propos des liens ....
      Il est possible de faire deux types de liens relatifs: relatif au dossier courant ou absolu.

      Par exemple dans le dossier "/home/moi/projets/monprojet"
      je peux avoir le lien: "current -> monprojet-0.9pre3"
      ou alors: "current -> /home/moi/projets/monprojet/monprojet-0.9pre3"

      L'avantage des liens relatifs, c'est que si tu déplace le dossier (monprojet) ailleurs, le lien fonctionnera toujours. Ce n'est pas le cas avec le lien absolu.

      Ce que je trouve dommage avec nautilus c'est su'il fait toujours des liens absolus. Et de temps en temps, je me retrouve avec des liens cassés à cause de cela. Du coup, je dois souvent m'en passer ou passer par la console et utiliser "ln" qui marche si bien.
      • [^] # Re: annuaire vs. moteur

        Posté par . Évalué à 1.

        >Ce que je trouve dommage avec nautilus c'est su'il fait toujours des liens absolus.

        Rox-filer a le même comportement. Avoir la possibilité de créer des liens relatifs, c'est une fonctionalité que j'adorrerai voir implémentée. Il se raprocherai encore un peu plus de la perfection :). J'en profite pour lancer un appel dans l'Ether, si un pinguoin se sent motivé... ;)

        PS: Ce journal appelle à la (re)lecture de "l'Histoire des Pinguoins" http://tnemeth.free.fr/fmbl/linuxsf/index.html(...)
        On y retrouve la pupart des protagonistes et/ou concept cités dans ici. Mangez-en c'est bon!
      • [^] # Re: annuaire vs. moteur

        Posté par (page perso) . Évalué à 3.

        Mouais, mais si tu fais du relatif tu ne pourras pas déplacer le lien sans déplacer la cible parce que ça cassera la liaison.
        Les deux ont une raison d'être, le système ne pourra pas déterminer seul ce que tu veux. Si on met du relatif demain les gens se plaindront qu'ils veulent de l'absolu.
        La seule solution c'est de laisser le choix, mais on complexifie pas mal l'interface alors.
  • # spotlight, winfs et autres

    Posté par . Évalué à 9.

    Sans m'opposer à ton argument principale (tout devrait rester fichier, parce que c'est vraiment génial), j'ai quand même un commentaire à faire :

    > Alors que l'on parle de SpotLight avec Tiger et de WinFS avec
    > Longhorn [...] Unix, a contrario offrait à l'utilisateur par son
    > système de fichier un moyen efficace de catégoriser ses
    > documents [...] créer lui même et hiérarchiquement ses
    > catégories (les répertoires) et d'y déposer les documents qu'il
    > souhaite, même de référencer ses documents dans des
    > catégories différentes (avec les hyperliens durs ou
    > symboliques). Et ceci de façon efficace et performante.

    Bah non, justement c'est parce que cette structure hiérarchique n'est pas efficace et performante que des outils offrant un plus haut niveau d'abstraction apparaissent. Bien que le concept de filesystem hiérarchique est vraiment bien dans beaucoup de cas, il arrive rapidement qu'on n'arrive plus à le gérer.
    Est-ce que tu arrives, toi, à classer tes fichiers efficacement avec ce système ?
    En tout cas, l'utilisateur de base, il ne fonctionne pas comme ça.
    L'utilisateur, il veut "la lettre où il parlait de tata mathilde", pas "la lettre envoyée le 24 janvier 2003 à oncle grégoire". Parce que ce qu'il se rappelle, c'est la partie parlant de tata mathilde.
    Et si tu dis de faire des liens symboliques dans tous les sens, bah je te répondrai que c'est une mauvaise utilisation du filesystem pour faire quelque chose d'à peu près équivalent à ces fameux nouveaux outils.
    • [^] # Re: spotlight, winfs et autres

      Posté par (page perso) . Évalué à 3.

      Rien n'empèche de faire un système de fichiers virtuel qui permettrait de monter sa mailbox et d'y faire des recherches sur des mots clés uniquement en utilisant le système de fichiers. Dans ton exemple tu irais chercher dans le répertoire mailbox/tata mathilde/ et tu aurais une liste des mails (un par fichier) qui contiennent l'expression "tata mathilde". Evidemment si on veut que ça soit efficace ça doit être indexé automatiquement par le mboxfs aussi. Mais ça ne remet pas vraiment en cause l'utilisation du système de fichiers pour ce type d'utilisation.

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

      • [^] # Re: spotlight, winfs et autres

        Posté par (page perso) . Évalué à 2.

        Au lieu de monter un système de fichier pour lire une mbox, pourquoi ne pas utiliser des maildir ?
        Si les noms de fichiers n'ont pas l'avantage d'être très lisibles, au moins chaque mail est un fichier, organisés par dossiers tels que visible dans le client mail, avec des répertoires et nom différents selon qu'ils sont lus ou non, qu'ils viennent d'arriver, ...

        Et comme c'est des fichiers, rien n'empèche de faire des grep ou n'importe qu'elle commande pour trouver ce qu'on veut...

        En plus (je sais pas trop comment ça marcherait avec mbox), ça permet aussi la consultation à distance (imap://serveurimap ou même ssh://monserveur/ordi ou il y a mes mails) sans avoir de clients (mais bon, il faudrait des noms plus explicites...)
        • [^] # Re: spotlight, winfs et autres

          Posté par (page perso) . Évalué à 2.

          Ce que je propose dans mon post précédent devrait aussi fonctionner avec maildir. Et si tu y tiens vraiment, tu peux implémenter le maildirfs avec un scrit shell qui utilise grep.

          pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

          • [^] # Re: spotlight, winfs et autres

            Posté par (page perso) . Évalué à 2.

            Ce que je voulais dire c'est qu'avec des maildir il n'y a pas besoin de maildirfs
            Le problème des mbox c'est qu'il y a un fichier par dossier (je crois) alors qu'en maildir il y a un fichier par mail

            En fait c'est : pourquoi vouloir créer un système de fichier représentant chaque mail par un fichier à partir d'une mbox alors que maildir le permet tout en étant sur le système de fichier natif ?

            Faire un mboxfs reviendrait à créer une maildir et mettre les mails dedans, non ? ;-)
            • [^] # Re: spotlight, winfs et autres

              Posté par (page perso) . Évalué à 2.

              Non parce qu'avec maildir tu n'as qu'une seule hiérarchie possible (à moins de s'amuser à faire des ln(1) de partout mais c'est pas vraiment pratique à maintenir). Avec un (maildir|mbox)fs tu peux "créer" des répertoires et "regrouper" les mails de la manière que tu veux à la volée. Tu ne saurais pas vraiment accéder au répertoire "mails/tata mathilde" pour trouver tous les mails concernant tata mathilde avec juste maildir. Tu dois avoir des scripts à côté. Tandis qu'avec un (maildir|mbox)fs comme je le conçois, il y a un script/programme aussi mais tu n'as pas besoin de l'appeller explicitement.

              pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

              • [^] # Re: spotlight, winfs et autres

                Posté par (page perso) . Évalué à 2.

                ha ok, j'avais loupé une partie

                Mais donc ça reviendrait en gros à l'ensemble vue fichiers + vue avec des répertoires virtuels (comme dans la pluspart des clients mails, par exemple les mails non lu, important) mais en généralisant ce principe et le rendre utilisable comme un file système.

                J'ai compris correctement cette fois ? ;-)

                Ce qui serait pas mal, c'est d'étendre les vues au système de fichier

                Mais par contre, c'est le système de fichier qui devrait le faire ou simplement les programmes qui devraient nous faire croire que c'est comme ça.
                Par ex konqueror pourrait nous afficher un maildir de la même manière que dans kmail, avec des dossiers virtuels, ... mais dans konqueror et non dans kmail. Ca ne changerait rien au système de fichier mais no en aurait l'impression...
    • [^] # Re: spotlight, winfs et autres

      Posté par . Évalué à 1.

      C'est pas grep qui fait ça ?
      :-)
      • [^] # Re: spotlight, winfs et autres

        Posté par (page perso) . Évalué à 2.

        mboxgrep(1) pour être précis mais pourquoi ne pas implémenter ça directement dans le système de fichier pour ne pas avoir à appeller le programme explicitiement (cf mes posts précédents dans ce thread) ?

        pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

        • [^] # Re: spotlight, winfs et autres

          Posté par . Évalué à 1.

          euh visiblement tu n'as pas compris mon propos
          je ne parle que de fichiers, de filesystem, et de difficulté à classer ses fichiers.
          en disant "la lettre", je parle de document openoffice writer, pas de courrier électronique.

          et le problème du grep, c'est que ce n'est pas au niveau applicatif, ca reste dans le filesystem. Les outils d'Apple et cie te trouvent le fichier, l'endroit où est le texte que tu cherches, et te le surlignent même peut-être...
  • # 1 fichier != 1 document

    Posté par . Évalué à 8.

    J'ai deux remarques à faire:

    Même si cette approche est généralement vraie, c'est à mon avis une erreur de penser que 1 document est toujours constitué d'un seul fichier.
    Prenons un cas un peu simple, mais qui illustre facilement cela: un fichier HTML avec illustrations, une page d'encyclopédie par exemple. Du point de vue fichier, le seul HTML ne suffit pas à établir le document, il y a des fichiers images liés à celui-ci, et sans lesquels le document n'est pas complet.

    Deuxièmement, l'indexation: il ne s'agit pas seulement de catégoriser (qui est une opération volontaire de la part de l'utilisateur) mais aussi de retrouver. C'est d'ailleurs la même idée derrière le fonctionnement de GMail et Google desktop: les systèmes actuels sont capables de déterminer automatiquement un certain nombre de caractéristiques de tes documents (type: image, mail, traitement de texte; contenu; ...) et de construire des indexs permettant de relier rapidement ces informations avec les documents, donc de les retrouver. Je ne crois pas que le système de fichier constitue à lui seul un moyen efficace de créer des indexs et de chercher rapidement parmi eux. Le système de fichier nécessite de relancer une recherche dans l'ensembles des données si on veut faire une recherche similaire, à chaque fois.

    mes 2 cents
    • [^] # Re: 1 fichier != 1 document

      Posté par (page perso) . Évalué à 4.

      Le système de fichier nécessite de relancer une recherche dans l'ensembles des données si on veut faire une recherche similaire, à chaque fois.
      D'où l'intérêt de tenir l'index à jour lorsque les fichiers sont crées/détruits/modifiés. C'est ce qui est fait avec les système de fichiers journalisés mais à un niveau plus bas. Je vois pas pourquoi ça ne serait pas faisable pour les méta-données "utiles" à l'utilisateur.

      Pour regrouper plusieurs fichiers en un seul document on peut les regrouper dans un .tar.gz et le "monter" comme un répertoire (sous Linux par défaut c'est pas possible mais ya sûrement un module targzfs qui traine quelque part, et au pire c'est pas compliqué à faire avec FUSE ou v9fs).

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

  • # Plan 9 c'est l'avenir

    Posté par (page perso) . Évalué à 10.

    Le langage C a d'ailleurs été écrit dans cette optique : être suffisamment de bas niveau pour permettre de jouer au niveau de l'optimisation
    Heu moi j'avais compris que le C au départ c'était plutôt pour faire un truc portable puisqu'à cette époque pratiquement tous les OS étaient écris entiérement en assembleurs. Donc rien à voir avec les performances il me semble.

    Sinon je crois que ce que tu cherches c'est Plan9 (et peut-être GNU Hurd). Enfin pour l'interface graphique je sais pas trop comment ça marche chez eux mais le "tout est fichier" est encore plus poussé que sous Unix.

    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

    • [^] # Re: Plan 9 c'est l'avenir

      Posté par (page perso) . Évalué à 4.

      J'ajouterais qu'aujourd'hui, l'optimisation est de moins en moins importante (pour les applications classiques du moins), et que le C n'est plus très adapté (justement parce qu'il est de trop bas niveau) à la création d'applications aussi complexes que ce que l'on recherche sur un "desktop"...
      • [^] # Re: Plan 9 c'est l'avenir

        Posté par (page perso) . Évalué à 2.

        le C n'est plus très adapté
        quels sont tes arguments ?
        rien de t'empeche d'appeler des fonctions de hauts niveaux justement...
        Tout repose sur des librairies, si elle sont puissantes, derrieres tu peux faire des trucs puissants, sinon faut recoder.
        • [^] # Re: Plan 9 c'est l'avenir

          Posté par (page perso) . Évalué à 4.

          Quand on veut faire des applications complexes, il faut structurer son application et la rendre maintenable. La pratique la plus courante est de séparer l'application en couche en utilisant les méthodes objet pour faciliter la séparation des responsabilités, la réutilisation, les tests unitaires, etc.

          Ces grosses applications demandent également beaucoup plus de travail d'abstraction, et les détails à-la-con non productifs comme la gestion mémoire sont une énorme perte de temps qui pourrait être consacré à une meilleure architecture ou documentation. (remarque non valable dans toutes les applis)

          Donc le C n'est pas adapté du tout pour les grosses appli "Desktop" qui comportent des millions de lignes et qui sont maintenus par de nombreux développeurs.

          Il suffit pas de faire des "libs puissantes" pour que le C puisse être adapté à faire tout et n'importe quoi.
        • [^] # bibliothèques vs. facilités natives

          Posté par . Évalué à 4.

          Quels sont les bibliothèques puissantes permettant de faire du traitement de chaînes en C, et que valent-elles par rapport aux facilités offertes "out of the box" par Python/Perl/Ruby ?

          Autre exemple, les listes, comparer en termes de facilité d'utilisation :
          - une bibliothèque de listes chaînées pour le C
          - std::list en C++
          - le type liste natif en Python

          Le C est limité, on a beau l'étendre de partout avec des tas de bibliothèques voire des assemblages de macros, il reste que sa sémantique est bas niveau par rapport à beaucoup de langages plus modernes, et qu'on passe plein de temps à écrire des choses qui vont d'elles-mêmes avec ces langages plus modernes.
      • [^] # Re: Plan 9 c'est l'avenir

        Posté par . Évalué à 5.

        >aujourd'hui, l'optimisation est de moins en moins importante

        C'est bien gentil mais ca fait 10 ans que j'entend la meme chose et 10 ans que mes PC successifs ramouillent. Pour donner en exemple mon petit cas particulier, j'ai pas franchement les moyens de changer de PC tout les 2 ans. Et puis en plus, ce n'est pas franchement ecologique.
        • [^] # Re: Plan 9 c'est l'avenir

          Posté par (page perso) . Évalué à 3.

          Si les développeurs s'intéressaient autant aux perfs qu'il le faisait à l'époque ou tout le monde codait en assembleur, on serait en train de s'envoyer du courrier postal pour savoir si emacs est finalement un vaporware ou non.
          Bah oui s'intéressé aux perfs t'imagine la proportion de temps humain que ca prend aux développeurs ?
        • [^] # Re: Plan 9 c'est l'avenir

          Posté par . Évalué à 1.

          C'est bien gentil mais ca fait 10 ans que j'entend la meme chose et 10 ans que mes PC successifs ramouillent. Pour donner en exemple mon petit cas particulier, j'ai pas franchement les moyens de changer de PC tout les 2 ans. Et puis en plus, ce n'est pas franchement ecologique.


          J'aime bien les râleurs qui ne veulent pas faire évoluer leur matériel mais qui veulent un système dernier cri, et qui après viennent râler que « oui mais voilà quoi, ça rame sur mon 486... ».

          Sérieusement, si vous ne voulez pas suivre l'évolution matérielle de manière régulière, il faut assumer derrière, et si la vitesse d'exécution est une priorité absolue, hé bien il faut alors se contenter des logiciels qui ont approximativement l'âge de votre machine !

          Et l'optimisation est effectivement de moins en moins importante, les puissances de calcul disponible étant pléthorique, il serait inutile qu'un programmeur passe des jours entiers à améliorer une partie d'un de ses logiciels pour qu'il se lance 0,001 seconde plus vite.

          Si l'affirmation n'était pas vraie, et bien on ne ferait rien de plus de nos ordinateurs qu'il y a 10 ans ! Or, aujourd'hui, on rippe des DVD, on grave des CD/DVD, on fait du montage vidéo, on lit du DivX, etc., tout ça en écoutant de la musique et en surfant sur internet, et en plus, pour un prix incroyablement plus bas qu'il y a 10 ans.

          Tiens, juste pour rire : sur une revue L'Ordinateur Individuel daté de 1992, je vois dans leur argus du PC un ordinateur PC 486 SX 25 doté de 4 Mo de mémoire, avec une carte graphique 256 couleurs, un disque dur 120 Mo, un lecteur disquette 3"1/2 1,44 Mo, et sans écran (ni lecteur CD, ni carte son évidemment) pour la modique somme de 140.000 francs hors taxes, soit 166.040 francs TTC avec la TVA de l'époque, c'est à dire 25.312 euros aujourd'hui !

          Aujourd'hui, malgré l'inflation depuis 1992, pour moins de 300 euros, tu as une machine qui potentiellement est infiniment plus polyvalente que ce PC à 140.000 francs HT de 1992 !
          • [^] # Re: Plan 9 c'est l'avenir

            Posté par . Évalué à 2.

            Sérieusement, si vous ne voulez pas suivre l'évolution matérielle de manière régulière, il faut assumer derrière, et si la vitesse d'exécution est une priorité absolue, hé bien il faut alors se contenter des logiciels qui ont approximativement l'âge de votre machine !

            Il y en a d'autres qui disent d'être toujours à jour, à cause des trous de sécurité.

            Ensuite, les formats de fichier évoluent parfois. J'ai été obligé d'abandonner il y a quelques années mon navigateur web très léger me donnant entière satisfaction car il ne gérait pas ou peu les feuilles de style qu'a adopter linuxfr. Le site était devenue inutilisable avec ce navigateur.
          • [^] # Re: Plan 9 c'est l'avenir

            Posté par . Évalué à 3.

            Sérieusement, si vous ne voulez pas suivre l'évolution matérielle de manière régulière, il faut assumer derrière
            T'as réflechi avant de dire ça ?
            Sache pour ta gouverne, que pour certaines personnes il ne s'agit pas de volonté mais plus de possibilité. Tout le monde ne peux pas se permettre de faire évoluer régulièrement son matériel comme tu dis.
            • [^] # Re: Plan 9 c'est l'avenir

              Posté par . Évalué à -1.

              T'as réflechi avant de dire ça ?


              Certainement davantage que toi, d'ailleurs, les faits semblent me donner raison.

              Sache pour ta gouverne, que pour certaines personnes il ne s'agit pas de volonté mais plus de possibilité. Tout le monde ne peux pas se permettre de faire évoluer régulièrement son matériel comme tu dis.


              Écoute mon grand, si tu ne peux pas te permettre d'évoluer ton matériel, hé bien comme je l'ai dit, tu assumes : tu n'évolues pas le logiciel, ou alors en connaissance de cause, c'est tout !

              Pas la peine de venir chialer parce que l'évolution aidant, les logiciels font des milliers de fois plus de choses aujourd'hui qu'auparavant, ce qui nécessite davantage de ressources.

              Je ne sais même pas pourquoi je répond à des commentaires aussi stupides et bornés...
              • [^] # Re: Plan 9 c'est l'avenir

                Posté par . Évalué à 6.

                Je ne sais même pas pourquoi je répond à des commentaires aussi stupides et bornés...
                Merci, ca fait toujours plaisir.
                Je suis donc stupide, bravo, n'argumente surtout pas.
                C'est mon premier post dans ce thread et je suis borné, quelle belle réflexion.
                Pour info, au cas où tu n'aurais pas compris, je disais juste qu'il y a une différence entre vouloir et pouvoir et que donc tout le monde ne peut pas upgrader son matos, tu n'es pas d'accord ? Reste dans ton élite, tu as raison, ça passe mieux.
                Tu m'avais habitué à mieux via tes anciens commentaires ( à part ton époque Mandrake sucks).
                En ce qui concerne l'évolution, il est en effet évident que pour la majorité des gens, les PC font des milliers de fois plus qu'écrire et imprimer un texte, surfer et regarder ses mails .....
                • [^] # Re: Plan 9 c'est l'avenir

                  Posté par . Évalué à 1.

                  Merci, ca fait toujours plaisir.
                  Je suis donc stupide, bravo, n'argumente surtout pas.
                  C'est mon premier post dans ce thread et je suis borné, quelle belle réflexion.


                  Oups, j'ai cru que c'était gyhelle qui me répondait ! :-)
                  Cela dit, tu aurais pu faire l'effort de lire ce qui avait été dit auparavant. Je n'ai jamais nié que certaines personnes ne puissent pas évoluer leur matériel, mais tu noteras que dans ce cas, j'ai préconisé de conserver un logiciel adapté, ou de ne pas venir se plaindre de lenteurs parce qu'on fait tourner un système d'exploitation d'aujourd'hui sur un ordinateur d'il y a 5 ans ! :-)

                  Pour info, au cas où tu n'aurais pas compris, je disais juste qu'il y a une différence entre vouloir et pouvoir et que donc tout le monde ne peut pas upgrader son matos, tu n'es pas d'accord ? Reste dans ton élite, tu as raison, ça passe mieux.


                  ÉLite, élite... Il ne faut pas abuser ! La plus récente de mes machines est un Athlon XP 2200+, et le plus ancien dont je me sers encore quotidiennement est un portable P!!!-600 (j'ai quelques Atari, 286,486, pentium, pentium II, et autre qui trainent mais qui ne font pas grand chose...)

                  En ce qui concerne l'évolution, il est en effet évident que pour la majorité des gens, les PC font des milliers de fois plus qu'écrire et imprimer un texte, surfer et regarder ses mails


                  Ce que je voulais souligner, c'est surtout qu'aujourd'hui cela n'étonne plus personne ou presque de graver un DVD en même temps qu'on écoute de la musique et qu'on surfe sur Internet... Pourtant, je me rappelle d'il n'y a pas si longtemps ou mon 486 DX² 66 exprimait quelques difficultés à lire un fichier mp3 en même temps qu'autre chose. D'ailleurs, sur ce genre d'ordinateurs, la décompression mpeg impliquait d'avoir une carte vidéo dédiée (genre sigma design).

                  Bref, les gens qui râlent parce que l'évolution ne permet pas de faire tourner les nouveaux logiciels aussi rapidement sur leurs vieilles machines « préhistoriques » -tout du moins, en comparaison de l'évolution informatique- se trompent complètement. S'ils souhaitent conserver un certain confort d'utilisation, hé bien il faut qu'ils apprennent à se contenter de ce que les capacités de leurs machines leur permet d'avoir.

                  Encore désolé pour la méprise, j'étais persuadé que c'était mon autre interlocuteur qui me répondait, et ça m'a énervé parce que j'ai eu l'impression qu'il n'avait rien lu de ma réponse précédente :-)
          • [^] # Re: Plan 9 c'est l'avenir

            Posté par (page perso) . Évalué à 2.

            Euh, j'ai quand même des doutes : t'es sûr pour le 140000 FRF HT pour un 486 SX25???
            De mémoire, les 486SX tournaient plutôt dans les 30000 FRF HT max'!
            Les DX, par contre, il n'y avait pas, ou presque, de limite....
            • [^] # Re: Plan 9 c'est l'avenir

              Posté par . Évalué à 3.

              Non non, c'est bien un 486 SX 25 :-) Et sur la même page, tu trouves des 386 entre 10.000 et 30.000 francs HT au meilleur prix :-)

              Par contre, dès 1993, les prix ont commencé à chuter monstrueusement. J'ai d'ailleurs acheté mon 486 DX² 66 complet (avec écran 14" couleur, 4 Mo de RAM, disque dur 420 Mo, carte graphique S3 VLB avec 1 Mo de mémoire, carte son Sound Blaster et lecteur CD 2X !) et à l'époque sans système d'exploitation, pour 21.000 francs en 1994, chez NSI Computer, un des tout premiers assembleurs asiatiques de Paris :-) Il a même fallu que je rajoute 700 Francs pour avoir Dos 6.2 et Windows 3.11 à l'époque ! (on avait fait une commande groupée via le BE de l'EFREI, et ils avaient prévu qu'on s'arrangerait « entre nous » pour les systèmes d'exploitation)

              Raaaahhh, que de souvenirs ! La même année, j'achetais ma première extension mémoire de 4 Mo (300 Francs), et une imprimante Canon BJC-4000 (3200 Francs), et j'avais les yeux exhorbité en voyant une personne venir acheté 1 barette de 32 Mo pleine de puces, pour 5000 Francs HT, prix d'ami...
          • [^] # Re: Plan 9 c'est l'avenir

            Posté par . Évalué à 0.

            Si l'affirmation n'était pas vraie, et bien on ne ferait rien de plus de nos ordinateurs qu'il y a 10 ans ! Or, aujourd'hui, on rippe des DVD, on grave des CD/DVD, on fait du montage vidéo, on lit du DivX, etc., tout ça en écoutant de la musique et en surfant sur internet, et en plus, pour un prix incroyablement plus bas qu'il y a 10 ans.

            L'affirmation n'est pas totalement fausse. Beaucoup de programmes sont écrits en VB/Delphi/etc. Une certaine quantité en Java, et bien sûr il y a C et C++, Perl, Python, Ruby, et les autres.

            Pour ne prendre que le cas de Java (mais c'est globalement vrai pour tous les langages), il existe beaucoup de programmeurs qui utilisent les mauvaises structures de données aux mauvais endroits. Ce qui implique que de la mémoire est franchement gâchée (non pas parce que lesdites structures sont mal codées, mais surtout mal employées). Cela fait dire à certains que Java est lent, ce qui est faux depuis un moment maintenant. Idem pour les langages de script.

            Je pense qu'il faut parler d'optimisation en faisant surtout un parallèle avec "bonne conception". Une bonne conception utilise les bonnes structures.

            Pour illustrer : si je me souviens bien, il y avait de gros soucis de perfs avec la VM dans Linux 2.4 (swap continu quasiment dès le départ dans certaines configurations du système). Le fait de changer le modèle pour la VM a résolu en grande partie le problème.

            Il est évident qu'il faut d'abord que "ça marche" et qu'ensuite seulement il est temps d'optimiser.

            Et sinon :


            ordinateur PC 486 SX 25 doté de 4 Mo de mémoire, avec une carte graphique 256 couleurs, un disque dur 120 Mo, un lecteur disquette 3"1/2 1,44 Mo, et sans écran (ni lecteur CD, ni carte son évidemment) pour la modique somme de 140.000 francs hors taxes, soit 166.040 francs TTC


            Ca me paraît vraiment énorme comme prix. A l'époque (à peu près au même moment), mes parents avaient acheté un 386 DX 33 avec 4Mo de RAM, 1Mo de vidéo, 120 Mo de HDD, un écran 14" qui montait jusqu'en 800*600 (1024*768 entrelacé). Le tout pour 14000F TTC.
        • [^] # Re: Plan 9 c'est l'avenir

          Posté par (page perso) . Évalué à 3.

          Hey, j'ai pas dit qu'il fallait bâcler les programmes pour autant !

          Pour info, je développe des programmes de calcul (IA) assez complexes en Java, et avec une bonne conception et quelques astuces, on s'en sort avec des performances environ 10 à 20% moindres qu'un équivalent en C soigneusement optimisé, pour le même algo.
          Sauf qu'en codant en Java, on peut beaucoup plus facilement faire évoluer et tester de nouvelles évolutions des algos (ce n'est pas de l'optimisation à proprement parler), incluant stockage évolué de données et parallélisme, ce qui nous permet au bout de quelques mois de recherche d'avoir des systèmes nettement plus performants que l'équivalent en C, à temps de développement équivalent.
  • # 2 cts

    Posté par (page perso) . Évalué à 2.

    Pour ton problème d'édition distante de fichier tu peux utiliser Vim (vim ftp://ftp.serveur.org/mon_fichier) qui ne nécessite pas de quitter pour voir les mofifs. C'est pratique.
  • # mon avis.

    Posté par (page perso) . Évalué à 4.

    performance. Le langage C a d'ailleurs été écrit dans cette optiqu
    L'informatique a évoluée et de nouveaux besoins sont apparus, les principaux étant la sécurité et la productivité, ainsi que de nouvelles méthodes de programmation : aspect, objet, etc. Et dans ce cadre le C est complètement largué et dépassé.

    les programmes ne font qu'une et une seule chose et ils le font bien et jusqu'au bout.. Le système offre un moyen de communication inter-programme qui permet à chacun, par combinaison, d'accomplir des tâches plus complexes ;
    Là encore l'informatique a évolué : le système de communication inter-programme d'Unix est complètement dépassé : les données ne sont pas structurées, les programmes sont collaboratifs et cherchent avant tout l'intégration avec leur environnement. Un programme n'est plus vu comme une entité distincte mais comme un boite à outil fournissant des services pour d'autres programmes et non pour le simple scripteur shell qui joue avec les pipes.

    Le système de fichier devient ainsi un espace hiérarchique de nommage d'objets de nature diverse.
    Ce principe était surtout nécessaire dans le cadre de l'environnement pré-cité visant à faire communiquer les programmes. Mais là encore l'absence totale d'information sur la nature et la structuration des infos limite clairement l'utilité de simples flux binaires référencés par des fichiers.

    Bref d'une manière générale les bases d'Unix ne sont plus du tout adaptés aux besoins actuels, et heuresement l'informatique évolue.

    La philosophie d'Unix n'était destinée qu'aux informaticiens, et si tu veux uniquement tenir compte de la philo alors oui, Unix est mort, ceux qui survivent sont ceux qui ont su évoluer et s'ouvrir à d'autres utilisateurs (MacOSX, Linux, etc.). Qui s'en plaindra ?
    • [^] # Re: mon avis.

      Posté par (page perso) . Évalué à 6.


      L'informatique a évoluée et de nouveaux besoins sont apparus, les principaux étant la sécurité et la productivité, ...

      Le langage C n'était qu'une illustration au premier point, sur les performances. Pour l'époque il répondait bien aux besoins.
      Maintenant, bien sûr, il y a d'autres considérations à prendre, n'empêche que l'excuse à deux balles de faire des gros lourdaux parce que les machines dans 10 ans seront plus performantes me laissent plutot froid ... ou en colère.


      Là encore l'informatique a évolué : le système de communication inter-programme d'Unix est complètement dépassé ...

      Je parlais du concept : les outils qui rendent chacun 1 et 1 seul service et par la combinaison du tout on accomplissait des tâches plus complexes. Le système de communication inter-processus d'Unix répondait de façon pertinente à celui-ci et ceci était aussi une illustration dans mes propos. Mais comme tu le dis, les besoins évoluent. Or, les solutions eux n'ont pas évolués ou alors sans répondre à ce concept d'Unix.


      Le système de fichier devient ainsi un espace hiérarchique de nommage d'objets de nature diverse.
      Ce principe était surtout nécessaire dans le cadre de l'environnement pré-cité visant à faire communiquer les programmes. Mais là encore l'absence totale d'information sur la nature et la structuration des infos limite clairement l'utilité de simples flux binaires référencés par des fichiers.

      Le système de fichier comme un espace de nommage d'objets n'est pas seulement utile pour les programmes, mais aussi pour l'utilisateur qui intéragit avec l'information. L'objet peut très être considéré comme une information ou un composé d'information. Or, c'est ce dernier que souhaite, AMHA, manipuler l'utilisateur et non telle ou telle appli. Le pb actuel est que le concept de filesystem-centric (donc j'ai donné ici aussi une illustration avec l'espace de nommage) n'est malheureusement plus apréhendé dans la conception des outils actuels. Voir même, par rapport à ce concept, on ne s'attache plus à faire évoluer de façon cohérente les systèmes de systèmes de fichiers pour répondre aux nouvelles attentes des utilisateurs.


      La philosophie d'Unix n'était destinée qu'aux informaticiens, et si tu veux uniquement tenir compte de la philo alors oui, Unix est mort, ceux qui survivent sont ceux qui ont su évoluer et s'ouvrir à d'autres utilisateurs (MacOSX, Linux, etc.). Qui s'en plaindra ?

      Je ne suis pas d'accord avec toi. La philosophie d'Unix était destiné avant tout à la conception d'un système qui réponde aux attentes avancées de ses utilisateurs, qu'ils soient informaticien ou simple secrétaire. Le pb est que si à l'origine ce système a répondu aux exigences de ses utilisateurs (d'où son rapide succès), les différentes sociétés qur Unix n'ont pas prises en compte ses précéptes. Et aujourd'hui il en est de même de la communauté libre.
      Unix, ce n'est pas seulement un noyau. C'est plus que cela. Et je crois bien que cela fait depuis un certain temps qu'Unix est à l'agonie.
      Mais personne s'en plaindra parce que très peu savent ce qu'est Unix et on continuera à s'agacer avec des systèmes bancales, lourdaux, qui simulent des réponses à tes attentes quand ils ne te convainquent pas que tes attentes c'est truc et pas machin.
    • [^] # Re: mon avis.

      Posté par (page perso) . Évalué à 6.

      C'est un point de vue philosophique qui t'es personnel.

      Je ne veux pas confondre accessibilité et nivellement par le bas.
      Je ne veux pas confondre facilité d'utilisation et perte des repères de bases (Xcell n'est pas une base de donnée, word n'est pas un éditeur de texte, powrpoint n'est pas un logiciel de support d'exposé).

      il est vrai que nous vivons dans une société qui cherche le vite, facile, pas chère , maintenant (et plus si affinité). Il est vrai que Microsoft à permis de faire croire à plein de gens (mes parents et nombre de mes amis avec) que tout est facile et se fait en quelques clics de mulot. Mais ce n'est malheureusement pas le cas.
      Effectivement, il y a toujours une manière de faire en 3 clics à la chezmoicamarche (tm), ce que certains geeks nomment ici alagruik, mais cela à beaucoup plus d'implication à court, moyen et long terme. Par exemple pour prendre le cas de powerpoint : il y a tellement de présentations powerpoint merdiques au contenu vide parce que on a pris l'outil pour FAIRE la présentation alors qu'il ne devrait servir , une fois la présentation faite qu' à en faire un "support" visuel.
      Combien d'entreprises (pme tpe) gèrent un carnet d'adresse avec Xcell ?

      L'outil que vous utilisez 'formate' votre manière de travailler et de penser. Je ne veux pas croire qu'il ne reste de la place en ce monde que pour des personnes qui savent faire de tout mais seulement un petit peu et à moitié.

      je veux bien comprendre TImaniac que ta position es marqué par une préférence marqué pour certains éditeurs proprio, mais NON la philosophie d'unix n'est pas reservé qu'aux informaticiens : irais-tu porter tes chaussures à ressemeler à ton boucher (parce qu'il sait à peut près le faire et que tu y passes de toute façon pour acheter ton roti) ? C'est cela le les programmes ne font qu'une et une seule chose et ils le font bien et jusqu'au bout. : les chaussures au cordonnier - la viande chez le boucher ! remarque parfois le steak c'est de la semelle :-)) de là à dire que le modernisme est en marche.

      herve
      • [^] # Re: mon avis.

        Posté par (page perso) . Évalué à 3.

        Arf.
        Si les utilisateurs de powerpoint privilégie la forme plutôt que le contenu, ce n'est pas vraiment de la faute du système : cela a l'avantage d'être intuitif et visuel. Va proposer aux secrétaires de faire une présentation avec transparents sous LaTeX justforfun.

        Il est évident que simplifier la vie des utilisateurs pour qu'ils aille plus vite de manière plus agréable a des revers : l'utilisateur ne prend pas le temps (puisqu'il n'y est pas obligé) de comprendre ce qui se passe. Et c'est là qu'il faut éduquer les utilisateurs. Mais la manière Unix qui consiste à lui demander de réfléchir est beaucoup trop "idéal" et conduit forcement à une impasse : la majorité des utilisateurs s'en balance royalement de savoir le pourquoi du comment, et ils préfèrent cliquetouiller une IHM à la powerpoint plutôt que de se farcire des pipes sous une console Unix pour transformer leur contenu en présentation, en passant par latex et dvi2pdf.

        les programmes ne font qu'une et une seule chose et ils le font bien et jusqu'au bout.
        Seulement la plupart des programmes on leur demande aussi d'être utilisables, et forcer de reconnaître que la philosophie Unix est là sérieusement limitée : il n'y a que des flux de données, en entrée et en sortie, et ces données ne sont pas structurée, non décrites, impossible d'avoir des événements asynchrone, bref, ce sont des modes de communications archaïques et complètement dépassé.

        Au fait, les softs proprio aussi sont basés sur ce principe de faire "une seule chose et le faire bien".
        C'est juste que de la même manière que tu chercheras à combiner des programmes unix pour faire une chaîne complexe de programme, les développeurs de softs proprio prennent des briques logiciels beaucoup plus élaborées (des composants) et les emboîtes les uns dans les autres.

        Il n'y a pas qu'Unix qui a le privilège de ce principe naturel de séparation des responsabilités, c'est même j'ai envi de dire le point commun de toute bonne architecture logicielle.
        • [^] # Re: mon avis.

          Posté par (page perso) . Évalué à 6.

          Si les utilisateurs de powerpoint privilégie la forme plutôt que le contenu, ce n'est pas vraiment de la faute du système : cela a l'avantage d'être intuitif et visuel.


          Si justement, c'est la faute du sytème qui est formaté pour formater les gens suivant cette logique.
          Apprendre peut être intuitif et visuel : mais cela reste quand même un peu vtech (qui a dit XP ?) je doute que dans de vrai formation (médecine, aéronautique ...) on privilégie le intuitif et visuel. Pourquoi ? si c'était si constructif et productif cela se retrouverait aussi dans ses secteurs là non ?

          le problème est que souvent intuitif et visuel sont des mots pour masquer amateurisme et a-peu-près comme motivation est utilisé pour masquer manque de rémunération.

          la majorité des utilisateurs s'en balance royalement de savoir le pourquoi du comment, et ils préfèrent cliquetouiller une IHM à la powerpoint


          Justement c'est au dev d'os et de logiciels de pallier à cela en faisant des UI pour le faire en toute transparence. Il n'est pas difficile de faire un menu au click droit qui fait un truc2ps | ps2pdf avec un verbe : transformer en pdf non ?

          C'est cela, à mon sens, une idée vraiment aboutie de la brique, plutôt que des moteurs très lourds qui font chacun leur pdf, chacun à sa sauce, avec chacun son truc_de_la mort_qui_tu_mais_qui_marche_bien_que_chez_moi, briques proprios qui sont toutes plus ou moins buggées et dont chacun trouve (expérience) le truc pour contourner le bug qui fait qu'il ne pourra pas migrer facilement sur un autre outil qui fait la même chose parce que les bugs ne sont pas au même endroits et que les fichiers de départs ne sont pas réutilisables d'un soft à l'autre.

          La philosophie de unix est une philosophie de réutilisabilité du travail déja fait. Cela reste toujours (surtout en milieu professionnels) un BESOIN. Il est dommage de devoir faire des copier-coller de partie de textes, de tableaux de chiffres pour faire un rapport à son dg en prenant le pps du directeur commercial, qui avait fais un copier-coller des chiffres de la présentation flash du stagiaire en multimédia a qui ont avait donné un rapport du controle de gestion. Ok c'est vachement intuitif (traduction: nous privilégions la forme sur le fond) mais un peu contre-productif.

          Tu serais le premier à applaudir si il existait un système ou la notion de logiciels à disparu au profit de la notion de tache : j'ouvre ma machine et je tape un texte (pas trop fort, la police veille) ensuite je choisie soit de l'imprimer, soit de l'envoyer par mail, soit d'en faire une présentation, soit d'en faire un film, soit d'en faire un fichier audio [mais seulement APRES de l'avoir tappé] : cela serait RELLEMENT user-centric (la seule manière de le faire est d'être filesystem-centric : je fais mon fichier et je l'enregistre comme un fichier son par exemple)

          Actuellement, il faut determiner ce que cela va être, ouvrir le logiciel (souvent il ne correspond pas à la tache mais on sait bidouiller pour que ca marche pas trop mal) et le faire.

          hervé
          • [^] # Re: mon avis.

            Posté par (page perso) . Évalué à 1.

            Tu n'as pas bien compris ce que je voulais dire.

            l. Pourquoi ? si c'était si constructif et productif cela se retrouverait aussi dans ses secteurs là non ?
            C'est productif dans le sens où l'utilisateur pond quelque chose. Avec ta méthode l'utilisateur n'arrivera pas à faire une présentation (faut qu'il se tapes du LaTeX, merci pour lui)
            Evidemment que ce n'est pas une bonne méthode d'apprentissage, mais comme je te l'ai dis, l'utilisateur veut que ca marche direct et qu'il comprenne ce qu'il fait.

            Bon par contre je suis pas sûr que PowerPoint soit le meilleur exemple qui existe, vu que c'est un outil destiné à produire beaucoup de forme pour enrober le fond. Et là LaTeX est une vrai merde quand il s'agit de modifier la forme. Après je suis d'accord que le fond à son importance, mais ca n'a pas beaucoup de rapport avec l'outil là, si le mec il a rien à dire dans sa présentation...

            Il n'est pas difficile de faire un menu au click droit qui fait un truc2ps | ps2pdf avec un verbe : transformer en pdf non ?
            Ca c'est le parfait exemple de ce qu'il ne faut pas faire. LaTeX et ps2pdf sont des softs non réutilisables en dehors de la ligne de commande : impossible d'intercepter des événements, d'appeler des méthodes, etc. Ce sont des softs conçu avec des interfaces primaires verbeuses destinées à des informaticiens ou à des échanges primaire de données brutes en entrée/sortie.

            Pour ce qui est des briques proprio que chaqun fait dans son coin : je suis tout à fait d'accord que c'est dommage, mais c'est inhérant au modèle proprio qui veut que l'on garde ou vend ces composants. N'empêche qu'ils sont généralement parfaitement réutilisable, souvent au sain de l'éditeur de logiciel, cela fait même parti de leurs "atouts".

            Il est dommage de devoir faire des copier-coller de partie de textes, de tableaux de chiffres pour faire un rapport à son dg en prenant le pps du directeur commercial, qui avait fais un copier-coller des chiffres de la présentation flash du stagiaire en multimédia a qui ont avait donné un rapport du controle de gestion.
            Sous LaTeX il sera tout aussi feignant, il fera du copier coller du .tex du patron, non franchement je comprends pas ta remarques là.

            : j'ouvre ma machine et je tape un texte (pas trop fort, la police veille) ensuite je choisie soit de l'imprimer,[...]
            Seulement l'utilisateur sait souvent ce qu'il veut faire avant de le faire. C'est con mais du coup on lui demande d'abord ce qu'il veut faire avant de lui demander le contenu. C'est ce qui fait le succès de tous les Wizards.
            • [^] # Re: mon avis.

              Posté par (page perso) . Évalué à 2.

              Sous LaTeX il sera tout aussi feignant, il fera du copier coller du .tex du patron, non franchement je comprends pas ta remarques là.


              Il est là exactement le problème : tu ne comprends pas ma remarque parce que tu n'imagines pas pouvoir faire autrement que copier-coller.

              tu pourrais faire
              @import sonfichier.tex dans TA présentation (du texte avant et du texte après) puis ... faire un pdf. (même si TON fichier n'est pas un fichier .tex)

              Ca c'est le parfait exemple de ce qu'il ne faut pas faire.LaTeX et ps2pdf sont des softs non réutilisables en dehors de la ligne de commande

              Pourquoi ? tu ne trouves pas qu'avoir la possibilité d'accèder à des outils/fonctions en ligne de commande est plus un avantage qu'un inconvénient. ?
              tu ne trouves pas qu'il est plus simple de faire convert toto.gif toto.png plutôt que d'ouvrir gimp puis ctrl+O puis crtl+S puis ctrl+Q.
              Pourquoi un soft d'animation en svg ne serait-il pas capable de prendre une fichier latex, puis avec une feuille de style, pourrait en faire une animation avec smil, avec exactement le même fichier que celui servant à faire l'impression (autre filtre) ou servant à faire un pdf (autre filtre).

              je crois (c'est mon analyse perso) que tu as du mal à distinguer le contenant du contenu, le logiciel du fichier, l'interface utilisateur et le système d'exploitation. Attention, je ne dis pas que tu es un crétin (milles excuses si mes propos semblent le faire penser), mais la frontière que tu mets entre les deux n'est, à mon sens, pas au bon endroit.

              hervé
              • [^] # Re: mon avis.

                Posté par (page perso) . Évalué à 2.

                tu pourrais faire
                @import sonfichier.tex dans TA présentation

                Non ca marche pas. La plupart veulent faire un copié collé et ensuite personnaliser en modifiant le contenu, pour justement que ca se voit pas trop que c copié collé du patron.

                ourquoi ? tu ne trouves pas qu'avoir la possibilité d'accèder à des outils/fonctions en ligne de commande est plus un avantage qu'un inconvénient. ?
                Houlà non je trouve cela très bien. Ce que je veux dire c'est que le but des appli Graphique est de ne surtout pas faire une surcouche d'un utilitaire en ligne de commande. Et c'est un des gros boulets que l'on traîne de la philosophie Unix : on a cru que les entrée sortie associées à des pipes résoudraient tous les problèmes du communications entre programmes.
                Aujourd'hui si on veut offrir des services réutilisables, on fait une bibliothèque d'API, ou mieux des composants. La ligne de commande devient alors un client/utilisateur de ces API au même titre que l'application graphique. On y gagne largement en souplesse et l'on peut largement bénéficier de toute la puissance d'une interface de programmation riche à base d'objet, événement, thread, etc.
                Mais y'a encore des irréductibles et on se retrouve avec des bousins comme yum qui n'a toujours pas d'interface graphique "friendly" tout ça parcque c'est une application qui ne fait qu'une chose, le fait bien, mais n'est pas réutilisable par autre chose que l'être humain sans contorsions.

                e crois (c'est mon analyse perso) que tu as du mal à distinguer le contenant du contenu, le logiciel du fichier, l'interface utilisateur et le système d'exploitation.
                détrompes toi :)
                • [^] # Re: mon avis.

                  Posté par (page perso) . Évalué à 2.

                  >>tu pourrais faire
                  >>@import sonfichier.tex dans TA présentation
                  >Non ca marche pas. La plupart veulent faire un copié collé et ensuite
                  >personnaliser en modifiant le contenu, pour justement que ca se voit pas trop
                  >que c copié collé du patron.

                  justement parce que copié coller cela veut bien dire ce que cela veut dire : COPIER=plagiat contre @import= travail collaboratif

                  tu vois que ce que tu utilises te formate bien plus que tu ne veux le croire.

                  Mais effectivement nous avons un point de désaccord philosophique entre ton idée d'une integration verticale, des mastodontes avec des API et des libs à inclure avec des softs de plus en plus puissanssivore (moralité je ne peux plus avoir inkscape 0.41 avec mon redhat9 (car prob de lib) et si je met un FC3 sur ma machine de 1 an,elle va ramer trop à mon goût.

                  Alors que des interactions externes ne poseraient pas de problème car si le 'greffon' n'est pas là, cela ne marche pas, mais le soft n'est pas obligé d'embarquer la totalité des greffons en interne.(même si ce n'est que des #include et des link dynamic)

                  hervé
                  • [^] # Re: mon avis.

                    Posté par . Évalué à 2.

                    On peut aussi penser à des "plug-ins" qui n'ont pas l'inconvénient d'être requis ni de consommer de la mémoire pour rien.

                    À noter pour répondre au détracteur des solutions à base de composition de flux E/S que la sérialisation qu'impose des simples flux n'est pas très pratique, certes, mais est tout de même le fondement du système X Window qui permet de faire des choses interressantes assez facilement. Cela permet de relativiser sur "l'horreur" que constitue l'interfacage graphique de programmes ligne de commande (techniquement on déplace juste le niveau du protocole d'échange ce qui implique entre autre qu'il faut parser au cas par cas... génant mais pas rédibitoire et pas forcement synonyme de perte d'informations (dépend de l'application bien sûr)), d'autant que l'horreur en question à l'aventage de ses inconvénients ;) : base du code parfaitement identique. Ce point peut sembler trivial par rapport à des biblio avec une API bien faite, mais dans certains cas ca pourrait faciliter les choses si de nombreuses différentes utilisation de l'API de la solution "propre" peuvent produire des résultats proches mais différents, ce qui ammene une nouvelle source potentielle de problème (cas vécu). Une autre solution est de faire une API d'interface entre la biblio et l'interface pour gérer carrement des scénarios d'utilisation, mais c'est chiant à écrire et on se retrouve avec une solution pas forcement plus simple, finalement.
                    Enfin dernier avantage de l'interfacage de CLI par une surcouche (ici on va s'éloigner un peu du graphique) : la possibilité de creer des scriptages extrement rapidement à divers niveaux (parse d'E/S d'un prog interactif ou enchainement de programmes non interactifs) et très simplement alors qu'aucune intégration n'existe à priori entre la solution de scriptage et les programmes à scripter et qu'une solution équivalente utilisant une intégration de plus bas niveau serait beaucoup plus longue à écrire (cas aussi vécu :)
                    Donc pour moi le bilan est mitigé entre l'interfacage à la barbarre et la solution "propre" ;)
                    Comme partout, il n'y a pas un coté tout blanc et un coté tout noir, et il convient de voir les avantages et inconvénients de chacuns. Il me semble normal qu'une personne habitué aux CLI se tournera vers des solution de filtrage / interface de flux E/S, alors qu'une personne habitué aux GUI se tournera vers une solution a base d'integration de briques (quelquesoit leur implémentation) ce qui a pour effet de bord d'interdire l'acces a l'utilisateur aux échanges entre les dites briques et de créer un système de type boite noire.
                  • [^] # Re: mon avis.

                    Posté par (page perso) . Évalué à 2.

                    tu vois que ce que tu utilises te formate bien plus que tu ne veux le croire.
                    Si ca peut te rassurer j'aime pas faire de copier/coller, j'aime toujours reformuler. Quant à la séparation forme/contenu, je la distingue tellement mal que j'utilise le format DocBook pour mes rapports parcque je trouve que LaTeX ne fait pas de séparation nette.

                    Mais effectivement nous avons un point de désaccord philosophique entre ton idée d'une integration verticale, des mastodontes avec des API et des libs à inclure avec des softs de plus en plus puissanssivore
                    Rin à voir.
                    Moi je préconise juste de fournir les services sous forme d'API plutôt que sous forme de petit programme manipulant des données en E/S, héritage typiquement unixien : après la taille des libs et/ou des appli derrière est un autre facteur.

                    PS : c'est quoi le rapport avec Inkscape ??? Tu comptais faire du dessin vectoriel en ligne de commande à coup de pipe ?

                    (même si ce n'est que des #include et des link dynamic)
                    Voila t'as résolu le problème : le module n'est chargé en mémoire que lorsqu'il est utilisé.
                    • [^] # Re: mon avis.

                      Posté par (page perso) . Évalué à 2.

                      >>(même si ce n'est que des #include et des link dynamic)
                      >Voila t'as résolu le problème : le module n'est chargé en mémoire que lorsqu'il est utilisé.

                      Oui, il est chargé en mémoire que si il est utilisé, MAIS il est obligatoire, même si tu ne l'utilisera jamais.

                      (on tourne en rond :)
                      • [^] # Re: mon avis.

                        Posté par (page perso) . Évalué à 2.

                        MAIS il est obligatoire, même si tu ne l'utilisera jamais.
                        Euh, il est obligatoire que si ton application ne peut s'en passer, sinon ca s'appelle un plugin et son abscence ne gène absolument pas (sauf l'utilisateur qui souhaitait utiliser ses fonctionnalités). Evidemment faut que l'application ai été conçu pour.
            • [^] # Re: mon avis.

              Posté par . Évalué à 2.

              Ce sont des softs conçu avec des interfaces primaires verbeuses destinées à des informaticiens ou à des échanges primaire de données brutes en entrée/sortie.


              Tex a été conçue il y à 20 ans. À l'époque c'était révolutionnaire. Aujourd'hui c'est toujours le meilleur, et de loin. C'est le seul système gérant correctement la typographie scientifique!

              Sous LaTeX il sera tout aussi feignant, il fera du copier coller du .tex du patron, non franchement je comprends pas ta remarques là.


              Non, il inclura le fichier avec \input{}. Le copier-coller avec la souris c'est pour Windaube.

              En lisans LinuxFr, je comprends pourquoi les patrons ne veulent pas embaucher de jeunes diplômés ... clic, clic wizards -> ANPE
        • [^] # Re: mon avis.

          Posté par . Évalué à 3.

          Ce dont très peu de monde à conscience c'est que les utilisateurs débutants (_vraiment_ débutants) ont enormement de mal avec les interfaces graphiques, peut être un peu moins qu'avec un shell, mais pas l'écart n'est pas énorme.

          La différence de facilité d'aprentissage est plutot liée aux nombres de fonctionnalités et de concept necessaire à l'auto-formation plutôt qu'à la représentation de l'information.

          Le fait d'utiliser une interface graphique et d'en comprendre les principaux concepts est un processus acquis et certainement pas inné, et il en est de même pour une interface en ligne de commande. Mettez un débutant devans Win XP et il n'y comprendra rien (il s'avère qu'il comprendra un peu plus une Ubuntu mais c'est une autre histoire...), enfin tout du moins pas suffisement pour être capable de l'utiliser dans de bonnes conditions. Il comprendra encore moins si il a quelques périphériques de marque qui utilisent une interface implantant d'autres paradigmes que ceux de win, le tout créant une interface completement disparate et hétérogène.

          A l'heure actuelle la tendance est plutôt au formatage vers l'interface graphique étant donné le positionnement du leader du marché des SE, et ce bien souvent malheureusement sans même tenir compte des notions les plus élémentaires d'utilisabilité. Plutôt que de souhaiter un formatage inverse vers des interfaces lignes de commande j'aimerai plutôt que les gens apprenent à ce servir de ce qu'il y a de mieux pour répondre à un besoin donné. Et dans ce contexte on se rend compte qu'un bon nombre de besoins dit "modernes" (qui en fait remontent à bien plus longtemps et possèdent donc des solutions depuis tout aussi lontemps mais avaient une proportion moindre étant donné leur non creation systematique que tant à leur donné la tendance du tout graphique) sont en fait résolvable avec des méthodes extremement "basiques".
  • # Hurd : le dernier des unix

    Posté par . Évalué à 5.

    Et le hurd ? Personne ne parle du Hurd ?

    Pourtant, le hurd est vraiment l'Unix qui suis le mieux cette logique.

    Un indexeur n'est pas inutile, mais c'est une faute de vouloir l'utiliser à la place de son navigateur de fichier. Je pense que Spotlight ou WinFS ou Beagle complète find et remplissent un besoin existant, mais ça n'empêche pas que je préfère largement me ballader dans l'arborescence plutôt que dans les recherches.

    On pourrait peut être faire des archiveurs un peu comme les renommeur de mp3 en fonctions des tags : on lui dit de grouper avec le modèle

    $HOME//<thème>// - .

    Et paf, on a ses document bien rangé, les images, les vidéo, etc, maintenant, faut pas faire ça avec n'importe quels documents, seulement ceux qui supportent les méta tags.
    • [^] # Re: Hurd : le dernier des unix

      Posté par (page perso) . Évalué à 3.

      ne pas confondre Beagle et SpotLight avec WinFS : Beagle et SpotLight sont de simples outils de recherche, WinFS est un système complet de fichier orienté base de données. J'espère que tu sauras apprécier la différence avec find ;)
  • # BDD vs fichier

    Posté par . Évalué à 5.

    Pourquoi ne pas utiliser une base de données plutôt qu'un système de fichiers?

    Au lieu d'avoir des mails sous formes de fichiers textes, on aurait une table "mail" avec les champs "sujet", "destinataire", "contenu"...

    Au lieu d'avoir des images sous forme de fichiers binaires, on aurait une table "images" avec les champs "largeur", "hauteur ", "couleurs",...

    En utilisant une BDD objet on pourrait même avoir deux sous tables "bitmap" et "vectorielles" contenant des infos spécifiques.

    Si je crée un jeu vidéo qui utilise des niveaux dans un format particulier, je n'aurai qu'à en faire une nouvelle table faisant référence à la table image -> plus besoin d'écrire d'outils spécifiques pour éditer les images de mon format.

    Pour garder la compatibilité avec les applications existantes il suffirait de mettre une table "fichiers" avec les champs "chemin" et "données".
    • [^] # Re: BDD vs fichier

      Posté par (page perso) . Évalué à 0.

      WinFS est ton ami.
      • [^] # Re: BDD vs fichier

        Posté par (page perso) . Évalué à 5.

        > WinFS est ton ami.

        Pour l'instant WinFS :
        1) C'est du vaporware
        2) S'appuie(rait un jour peut-être) sur NTFS


        • [^] # Re: BDD vs fichier

          Posté par . Évalué à 1.

          2) S'appuie(rait un jour peut-être) sur NTFS

          On peut pas forcément en vouloir de s'appuyer sur l'existant, et l'utilisateur en aura sans doute pas grand chose à foutre que ce soit basé sur ntfs
    • [^] # Re: BDD vs fichier

      Posté par . Évalué à 2.

      Pourquoi ne pas utiliser une base de données plutôt qu'un système de fichiers?

      Ou plutot, coupler une base de données avec le système de fichier. La commande "locate" permet pae exemple de localiser instantanément un fichier selon son nom, car un démon parcours régulièrement le système de fichiers et stocke cette infos dans une base de données.

      Inconvénient, c'est un programme indépendant, asynchrone. Mais on pourrait imaginer qu'il soit mis à jour automatiquement (avec beaucoup plus d'infos) à chaque changement du système de fichiers.

      Mais dans tout les cas, il faut bien garder un système de fichier ... pour stocker la base de données elle même !!
      • [^] # Re: BDD vs fichier

        Posté par . Évalué à 2.

        nosql

        http://www.linux.it/~carlos/nosql/current-doc/NoSQL.html(...)

        Un programme de base de donnees relationnelle, de philosophie unix, non SQL, exactement dans l'esprit que veut defendre ce journal.

        Pourtant un programme dont on ne parle jamais.

        Snif ...

        http://www.linux.it/~carlos/nosql/current-doc/NoSQL.html(...)
      • [^] # Re: BDD vs fichier

        Posté par . Évalué à 1.

        locate pourrait en effet se mettre a jour avec inotify
        jme demande si quelquun travaille déjà la dessus

        Néanmois moi se qui me plarait, et ce qu'une BDD permetrait de faire tout en gardant un système hiérarchique serati un tri "rapide" : en 2 clics ou 2 commandes je pourrai me retrouver avec mes fichiers triés par date, ou triés par catégories (BD, bouquins, presentations... avec ensuite tri par auteur, date...) et pouvoir me ballader dans cette arborescence comme je le fait actuellement.

        Pour ceux qui ont eu la chance d'aller au FOSDEM et voir la conférence de Scott Wheeler sur klink (désormais tenor), celui-ci propose à un plus haut niveau de créer un framework qui stocke des liens entre documents. Par exemple si on sauvegarde une image provenant d'un mail, l'ouverture de cette image permetrait de directement retrouver le mail en question, de renvoyer un mail à tous les destinatires... en regardant un pdf contenant la biographie d'un chanteur Z, on pourrait directement trouver les mp3 de ce même chanteur... j'ai adoré le concept, d'autres on trouvé ça gadget...
      • [^] # Re: BDD vs fichier

        Posté par . Évalué à 3.

        Mais on pourrait imaginer qu'il soit mis à jour automatiquement (avec beaucoup plus d'infos) à chaque changement du système de fichiers.

        C'est comme ca que marche la BD de Beagle, avec inotify.
      • [^] # Re: BDD vs fichier

        Posté par . Évalué à 2.

        ReiserFS semble se rapprocher de ce que je décrivais dans mon premier post, à la fois système de fichiers et base de données. Quelqu'un a déjà essayé?

        Pour moi l'intérêt d'utiliser une BDD ne se limite pas aux recherches. Imaginons que je veuille marqué un ensemble de fichiers comme étant gravé sur un cd, j'utiliserais une commande du style:

        UPDATE file
        ADD tag = 'gravé'
        WHERE
        file.path LIKE '/cdrom/%'
  • # À cause des nouveaux utilisateurs?

    Posté par . Évalué à 0.

    À mon avis, c'est due à l'arrivée massive de nouveau utilisateurs. C'est gens là, ne savent pas que Unix à été conçu pour faire de l'Informatique (dans le sens générale, soit traité l'information) dans les universités et le monde professionnel. De quoi parle ton aujourd'hui: de juckbox mp3, de galerie photos, de bruitage sonore, de thème, de pointeur de souris 3D ... Bref toute la science marketing de MS. Plus il y a d'effets graphiques, et de bruitage sonore, plus ils sont content. À quoi ça sert? À rien, sauf à utiliser de l'électricité pour rien. Je ne dis pas que Linux doit être réservé à des experts. Mais il y a une limite à ne pas franchir. Cela dit, il pourrait être intéressant d'ajouter des metadatas comme sur la première pages des livres aux fichiers. C'est vrai qu'il est difficile de se retrouver dans /etc. On pourrait imaginer une base de donnée indexé par le chemin. La commande mv et autres feraient le travail de mise à jour de la base de donnée. Ainsi on resterait indépendant du noyau.
    • [^] # Re: À cause des nouveaux utilisateurs?

      Posté par (page perso) . Évalué à 0.

      Désolé mais même en tant qu'informaticien j'apprécie de travailler dans un environnement esthétique et animé. Donc non cela ne sert pas à rien, cela contribue au contraire à rendre l'utilisation d'un outil ludique ou professionnel agréable pour tous.
      Alors non ca ne sert pas qu'à bouffer des watts.
    • [^] # Re: À cause des nouveaux utilisateurs?

      Posté par (page perso) . Évalué à 1.

      C'est très bien mais si tu met tout ca dans ta commande mv, il y a un petit problème ...
      En effet, on peut utiliser d'autres programmes pour déplacer des fichiers. Cela m'étonnerait que nautilus utilise mv, par exemple (mais je peux me tromper).
  • # Le my

    Posté par . Évalué à 3.

    Un ordinateur manipule de l'information. Son utilisateur manipule des documents contenant de l'information. Sa vision première devrait donc être le document.


    L'utilisateur interagit avec un ordinateur. Quand je surfe sur internet, je ne manipule pas des documents, je manipule une interface qui me permet d'obtenir de l'information, quand je chatte, je manipule une interface qui me permet de dialoguer, quand je dessine, je manipule une interface...

    Si le seul moyen de l'ordinateur pour rendre une information persistente est de la mettre dans un fichier, je dois faire avec. Il pourrait la mettre dans une base de données, la garder en mémoire...

    L'ordinateur doit rendre des services et ça devrait être son seul objectif.
  • # Peut-être

    Posté par . Évalué à 1.

    ...pour aider à réconcilier environnements graphiques et concepts unix :
    http://www.gobolinux.org/index.php?lang=en_US&page=doc/articles(...)
  • # Distinguer interface grand public / organisation interne du système

    Posté par . Évalué à 2.

    Déjà il n'y aucune raison que les outils grand-public montrent les détails de l'organisation interne du système.
    Par exemple rien n'empeche d'avoir un "google personal" sous Unix (et d'ailleurs des clones sont déjà la). Unix n'empeche personne de stocker des infos dans un SGBD, évidemment.
    D'ailleurs tous les sytèmes offrent des APIs équivalentes à Posix, meme si leurs interfaces graphiques sont différentes.
    Après chacun choisit son interface graphique favorite, tous les gouts sont permis.
    (moi c'est plutot vim/bash/zsh :) )

    Ce qui m'intéresse chez Unix est surtout la fiabilité et la sécurité. 35 ans d'expérience. Il serait dommage de casser les principes de base (notamment des processus communiquants tout en ayant des privilèges différents).

    C'est évidemment améliorable. Les pipes et sockets locales sont accélérables avec de la mémoire partagée (pas besoin de threads pour remplacer un pipe). Des outils comme systrace.org ou UserModeLinux permettent d'ajouter des couches de sécurité. Eros, Coyotos, L4/Linux et L4/Hurd permettront peut-etre un jour que le coeur du système soit démontré sans erreur. Et donc d'avoir des processus fiables cohabitant parfaitement avec des outils conviviaux moins fiables.

    Exemple concret de ce qu'on peut attendre d'Unix: un bug dans un outil convivial comme Firefox ne doit ni endommager ni rendre public tous mes fichiers importants et privés. Dans l'esprit d'Unix, le gestionnaire de bookmarks devrait même être un processus indépendant pour que tous mes bookmarks ne soient pas compromis d'un seul coup par un bug de javascript.

    Avec le développement de la banque à distance, des spywares, et des P2P privés, je pense que les gens vont attacher de + en + d'importance à la sécurité de leur système.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.