Les journaux sont destinés à des informations qui ne sont pas suffisamment intéressantes
pour être validées en dépêche (sinon n'hésitez pas à proposer votre information en
dépêche), qui sont sans rapport avec Linux ou le libre, ou simplement pour donner votre
avis. Si vous désirez poser une question, merci d'utiliser Derniers journaux de moqui :
- [04/04@12:00] Dictaphone numérique et GNU/Linux ?
- [05/11@21:04] Une machine GNU/Linux pour mon père
- [15/10@09:27] j'ai un rêve ...
- [14/10@09:36] WAGEN
Journal : Unix, que sont devenus tes concepts ?
Posté par Miguel Moquillon (page perso, ) le 25 avril 2005Unix 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 ?
> Lire le journal (132 commentaires, moyenne: 3,2).
Merci !
Non, tu n'es pas seul ! :)
Au contraire: sortons du "tout fichier"
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 Miguel Moquillon (page perso, ) le 25/04/2005 à 12:31. (lien). É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 salvaire () le 25/04/2005 à 15:08. (lien). É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 Jimmy (page perso, ) le 25/04/2005 à 21:03. (lien). É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 !-
[^]Re: Au contraire: sortons du "tout fichier"
Posté par mammique (Jabber id, page perso, ) le 25/04/2005 à 21:52. (lien). Évalué à 1.Haaa... BeFS... (soupir)
-
[^]Re: Au contraire: sortons du "tout fichier"
Posté par Sylvain Briole (page perso, ) le 26/04/2005 à 10:26. (lien). Évalué à 3.URLs dans un boomark.html
Pour une fois, c'est Microsoft qui a mieux appliqué les traditions Unix que Mozilla & co. : les marque-pages sont des fichiers sous IE, alors qu'ils sont contenus dans un fichier sous Mozilla.
-
Unix, que sont devenus tes concepts ?
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, ...
-
[^]Re: Unix, que sont devenus tes concepts ?
Posté par lezardbreton (Jabber id, page perso, ) le 25/04/2005 à 09:44. (lien). É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 L () le 25/04/2005 à 10:05. (lien). É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.-
[^]Re: Unix, que sont devenus tes concepts ?
Posté par Krunch (Jabber id, page perso, ) le 25/04/2005 à 11:24. (lien). É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(...)--
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.-
[^]Re: Unix, que sont devenus tes concepts ?
Posté par Miguel Moquillon (page perso, ) le 25/04/2005 à 12:49. (lien). Évalué à 2.Tout à fait. Plan 9 est au jour d'aujourd'hui le système qui a poussé le plus loin le concept de filesystem-centric. Ce qui est dommage, c'est qu'il soit arrêté d'être développé et qu'aucun autre Unix tente de récupérer ses bonnes idées. J'ai l'impréssion déasagréable que l'on préfère reprendre les idées de MS Windows ou MacOS :(
-
[^]Re: Unix, que sont devenus tes concepts ?
-
-
-
[^]Re: Unix, que sont devenus tes concepts ?
Posté par lezardbreton (Jabber id, page perso, ) le 25/04/2005 à 12:19. (lien). É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 L () le 25/04/2005 à 12:51. (lien). É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.-
[^]Re: Unix, que sont devenus tes concepts ?
Posté par lezardbreton (Jabber id, page perso, ) le 25/04/2005 à 13:09. (lien). É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 L () le 25/04/2005 à 13:46. (lien). É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).
-
-
-
-
-
-
[^]Re: Unix, que sont devenus tes concepts ?
Posté par gnumdk (page perso, ) le 25/04/2005 à 12:25. (lien). É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 ?
-
[+] [^]Re: Unix, que sont devenus tes concepts ?
Posté par L () le 25/04/2005 à 13:28. (lien). É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 !-
[^]Re: Unix, que sont devenus tes concepts ?
Posté par Ph Husson (page perso, ) le 25/04/2005 à 14:19. (lien). É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 L () le 25/04/2005 à 15:46. (lien). É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 !
-
[^]Re: Unix, que sont devenus tes concepts ?
Posté par Matthieu Moy (page perso, ) le 25/04/2005 à 19:27. (lien). É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 free2.org (page perso, ) le 25/04/2005 à 15:17. (lien). Évalué à 2.pour le mail, sylpheed est convivial et léger
-
-
[^]Re: Unix, que sont devenus tes concepts ?
mouai
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 Miguel Moquillon (page perso, ) le 25/04/2005 à 13:05. (lien). É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 Éric (Jabber id, page perso, ) le 25/04/2005 à 13:20. (lien). É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 oops (page perso, ) le 25/04/2005 à 13:50. (lien). É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 anonimulo () le 25/04/2005 à 14:42. (lien). É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 Éric (Jabber id, page perso, ) le 25/04/2005 à 15:48. (lien). É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 oops (page perso, ) le 25/04/2005 à 16:33. (lien). É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 Éric (Jabber id, page perso, ) le 25/04/2005 à 17:17. (lien). É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 RodZilla () le 25/04/2005 à 20:15. (lien). É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 Éric (Jabber id, page perso, ) le 26/04/2005 à 09:55. (lien). É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 RodZilla () le 26/04/2005 à 16:02. (lien). É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 Éric (Jabber id, page perso, ) le 26/04/2005 à 20:15. (lien). É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 Ph Husson (page perso, ) le 27/04/2005 à 21:39. (lien). Évalué à 2.Comme amarok pour le musique en somme?
-
-
-
-
-
-
[^]Re: mouai
Posté par benoar (Jabber id, ) le 25/04/2005 à 15:48. (lien). É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
-
[^]Re: mouai
Posté par Obsidian () le 27/04/2005 à 13:51. (lien). É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 Éric (Jabber id, page perso, ) le 27/04/2005 à 16:04. (lien). É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 Obsidian () le 27/04/2005 à 23:08. (lien). É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
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 qdm () le 25/04/2005 à 09:47. (lien). É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 Pior () le 25/04/2005 à 09:50. (lien). É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 Narishma Jahar () le 25/04/2005 à 09:55. (lien). É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 gnumdk (page perso, ) le 25/04/2005 à 12:30. (lien). É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 gnumdk (page perso, ) le 25/04/2005 à 12:40. (lien). Évalué à 1.il fallait bien sur lire fish://user@machine ;)
-
[^]Re: Kioslave
Posté par Alex () le 25/04/2005 à 12:48. (lien). É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 ?
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 Pior () le 25/04/2005 à 09:54. (lien). É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 Narishma Jahar () le 25/04/2005 à 10:00. (lien). É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 Epsos (page perso, ) le 25/04/2005 à 11:30. (lien). Évalué à 2.dbus est en partie issu de dcop ...
-
-
[^]Re: Et bien ?
Posté par L () le 25/04/2005 à 10:13. (lien). É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.-
[^]Re: Et bien ?
Posté par TImaniac (page perso, ) le 25/04/2005 à 15:54. (lien). É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 L () le 25/04/2005 à 16:20. (lien). É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.-
[^]Re: Et bien ?
Posté par Gof (Jabber id, page perso, ) le 25/04/2005 à 17:02. (lien). É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 Krunch (Jabber id, page perso, ) le 25/04/2005 à 11:55. (lien). Évalué à 4.il suffit de taper l'URL dans la boîte de fichiers.
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.
La question suivante, c'est de savoir comment on peut unifier ca avec Gnome-VFS ou autres.
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(...)--
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.
annuaire vs. moteur
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 Miguel Moquillon (page perso, ) le 25/04/2005 à 13:12. (lien). É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 Mildred (Jabber id, page perso, ) le 26/04/2005 à 03:27. (lien). É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 arno () le 26/04/2005 à 07:03. (lien). É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 Éric (Jabber id, page perso, ) le 26/04/2005 à 09:58. (lien). É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
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 Krunch (Jabber id, page perso, ) le 25/04/2005 à 12:06. (lien). É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.
--
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.-
[^]Re: spotlight, winfs et autres
Posté par CrEv (page perso, ) le 25/04/2005 à 13:03. (lien). É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 Krunch (Jabber id, page perso, ) le 25/04/2005 à 13:25. (lien). É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.
--
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.-
[^]Re: spotlight, winfs et autres
Posté par CrEv (page perso, ) le 25/04/2005 à 15:09. (lien). É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 Krunch (Jabber id, page perso, ) le 26/04/2005 à 12:32. (lien). É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.
--
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.-
[^]Re: spotlight, winfs et autres
Posté par CrEv (page perso, ) le 26/04/2005 à 17:19. (lien). É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
-
[^]Re: spotlight, winfs et autres
Posté par Krunch (Jabber id, page perso, ) le 26/04/2005 à 12:35. (lien). É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) ?
--
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.-
[^]Re: spotlight, winfs et autres
Posté par Sébastien Munch (page perso, ) le 02/05/2005 à 19:52. (lien). É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
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 Krunch (Jabber id, page perso, ) le 25/04/2005 à 11:31. (lien). É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).--
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.
Plan 9 c'est l'avenir
Le langage C a d'ailleurs été écrit dans cette optique : être suffisamment de bas niveau pour permettre de jouer au niveau de l'optimisationHeu 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.
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.
-
[^]Re: Plan 9 c'est l'avenir
Posté par scand1sk (page perso, ) le 25/04/2005 à 10:49. (lien). É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 Pooly (page perso, ) le 25/04/2005 à 12:00. (lien). É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 TImaniac (page perso, ) le 25/04/2005 à 13:34. (lien). É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 Antoine () le 25/04/2005 à 13:34. (lien). É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: bibliothèques vs. facilités natives
Posté par R4f (page perso, ) le 26/04/2005 à 08:37. (
-
-
-
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.