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 ?
Journal Unix, que sont devenus tes concepts ?
25
avr.
2005
# Merci !
Posté par oops (site web personnel) . Évalué à 10.
# Au contraire: sortons du "tout fichier"
Posté par bobert . Évalué à 6.
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 (site web personnel) . Évalué à 4.
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 . Évalué à -1.
Ton rêve c'est ExcelFs? J'ai peur pour l'avenir!
[^] # Re: Au contraire: sortons du "tout fichier"
Posté par Jimmy . Évalué à 4.
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 . Évalué à 1.
[^] # Re: Au contraire: sortons du "tout fichier"
Posté par Sylvain Briole (site web personnel) . Évalué à 3.
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.
# Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Unix, que sont devenus tes concepts ?
Posté par lezardbreton . Évalué à 4.
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.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Unix, que sont devenus tes concepts ?
Posté par Krunch (site web personnel) . Évalué à 10.
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 Miguel Moquillon (site web personnel) . Évalué à 2.
[^] # Re: Unix, que sont devenus tes concepts ?
Posté par free2.org . Évalué à 3.
[^] # Re: Unix, que sont devenus tes concepts ?
Posté par lezardbreton . Évalué à 2.
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.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 9.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Unix, que sont devenus tes concepts ?
Posté par lezardbreton . Évalué à 1.
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.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 9.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Unix, que sont devenus tes concepts ?
Posté par gnumdk (site web personnel) . Évalué à 10.
>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 Anonyme . Évalué à 3.
:-)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Unix, que sont devenus tes concepts ?
Posté par Ph Husson (site web personnel) . Évalué à 1.
c'est fait exprès qu'ils partagent l'infrastructure pour réduire la consomation
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Unix, que sont devenus tes concepts ?
Posté par Matthieu Moy (site web personnel) . Évalué à 6.
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 . Évalué à 2.
[^] # Re: Unix, que sont devenus tes concepts ?
Posté par modr123 . Évalué à 2.
# mouai
Posté par schyzomarijks . Évalué à 9.
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 (site web personnel) . Évalué à 3.
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 (site web personnel) . Évalué à 7.
> 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 (site web personnel) . Évalué à 7.
>à 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 . Évalué à 6.
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 (site web personnel) . Évalué à 5.
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 (site web personnel) . Évalué à 2.
>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 (site web personnel) . Évalué à 4.
> 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 . Évalué à 3.
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 (site web personnel) . É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.
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 . É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 (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 (site web personnel) . Évalué à 2.
> 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 (site web personnel) . Évalué à 2.
[^] # Re: mouai
Posté par benoar . Évalué à 6.
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 mcjo . Évalué à 1.
ln -s ....
[/troll]
[^] # Re: mouai
Posté par Obsidian . Évalué à 5.
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 (site web personnel) . Évalué à 2.
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 . Évalué à 2.
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 Pior . Évalué à 2.
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 . Évalué à 1.
[^] # Re: Kioslave
Posté par Pior . Évalué à 1.
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 . Évalué à 1.
[^] # Re: Kioslave
Posté par gnumdk (site web personnel) . Évalué à 1.
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 (site web personnel) . Évalué à 1.
[^] # Re: Kioslave
Posté par Alex . Évalué à 1.
# Et bien ?
Posté par anonimulo . Évalué à 7.
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 . Évalué à 2.
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 . Évalué à 8.
[^] # Re: Et bien ?
Posté par Epsos . Évalué à 2.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 6.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Et bien ?
Posté par TImaniac (site web personnel) . Évalué à 1.
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.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Et bien ?
Posté par Gof (site web personnel) . Évalué à 6.
(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 (site web personnel) . Évalué à 4.
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 Antoine . Évalué à 10.
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 (site web personnel) . Évalué à 3.
[^] # Re: annuaire vs. moteur
Posté par Mildred (site web personnel) . Évalué à 2.
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 fusible . Évalué à 1.
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 (site web personnel) . Évalué à 3.
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 Sébastien Munch . Évalué à 9.
> 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 (site web personnel) . Évalué à 3.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: spotlight, winfs et autres
Posté par CrEv (site web personnel) . Évalué à 2.
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 (site web personnel) . Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: spotlight, winfs et autres
Posté par CrEv (site web personnel) . Évalué à 2.
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 (site web personnel) . Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: spotlight, winfs et autres
Posté par CrEv (site web personnel) . Évalué à 2.
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 VoixOff . Évalué à 1.
:-)
[^] # Re: spotlight, winfs et autres
Posté par Krunch (site web personnel) . Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: spotlight, winfs et autres
Posté par Sébastien Munch . Évalué à 1.
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 Bertrand Mathieu . Évalué à 8.
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 (site web personnel) . Évalué à 4.
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 Krunch (site web personnel) . Évalué à 10.
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 scand1sk (site web personnel) . Évalué à 4.
[^] # Re: Plan 9 c'est l'avenir
Posté par Pooly (site web personnel) . Évalué à 2.
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 (site web personnel) . Évalué à 4.
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 . Évalué à 4.
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 . Évalué à 2.
Les manipulations «standards» dans plusieurs langages de programmation (comme le Cookbook de Perl) :
http://pleac.sourceforge.net/pleac_perl/arrays.html(...)
Comparer les performances de différents langages en termes de temps, mémoire, nombre de lignes The Computer Language
Shootout Benchmarks http://shootout.alioth.debian.org/(...)
[^] # Re: Plan 9 c'est l'avenir
Posté par gyhelle . Évalué à 5.
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 TImaniac (site web personnel) . Évalué à 3.
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 Anonyme . Évalué à 1.
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 Jllc . Évalué à 2.
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 dab . Évalué à 3.
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 Anonyme . Évalué à -1.
Certainement davantage que toi, d'ailleurs, les faits semblent me donner raison.
É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 dab . Évalué à 6.
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 Anonyme . Évalué à 1.
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 ! :-)
É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...)
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 Sylvain Briole (site web personnel) . Évalué à 2.
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 Anonyme . Évalué à 3.
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 lasher . Évalué à 0.
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 scand1sk (site web personnel) . Évalué à 3.
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 rhizome . Évalué à 2.
[^] # Re: 2 cts
Posté par Miguel Moquillon (site web personnel) . Évalué à 2.
# mon avis.
Posté par TImaniac (site web personnel) . Évalué à 4.
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 Miguel Moquillon (site web personnel) . Évalué à 6.
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.
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 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.
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 hervé Couvelard . Évalué à 6.
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 TImaniac (site web personnel) . Évalué à 3.
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 hervé Couvelard . Évalué à 6.
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.
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 TImaniac (site web personnel) . Évalué à 1.
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 hervé Couvelard . Évalué à 2.
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)
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 TImaniac (site web personnel) . Évalué à 2.
@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 hervé Couvelard . Évalué à 2.
>>@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 Guillaume Knispel . Évalué à 2.
À 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 TImaniac (site web personnel) . Évalué à 2.
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 hervé Couvelard . Évalué à 2.
>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 TImaniac (site web personnel) . Évalué à 2.
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 salvaire . Évalué à 2.
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!
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 Guillaume Knispel . Évalué à 3.
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".
# Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Hurd : le dernier des unix
Posté par TImaniac (site web personnel) . Évalué à 3.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -2.
Ce commentaire a été supprimé par l’équipe de modération.
# BDD vs fichier
Posté par bobefrei . Évalué à 5.
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 TImaniac (site web personnel) . Évalué à 0.
[^] # Re: BDD vs fichier
Posté par oops (site web personnel) . Évalué à 5.
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 Thomas Douillard . Évalué à 1.
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 Jllc . Évalué à 2.
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 garden . Évalué à 2.
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 Alex . Évalué à 1.
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 Bruno Muller . Évalué à 1.
http://gnunet.org/doodle/(...)
[^] # Re: BDD vs fichier
Posté par Alex . Évalué à 1.
Je ne sais pas où trouver la présentation faite au fosdem, dailleurs l'équipe de dev à l'air avare d'info, j'ai néanmoins trouvé ça :
http://www.linuxplanet.com/linuxplanet/reviews/5816/2/(...)
[^] # Re: BDD vs fichier
Posté par Erwan . Évalué à 3.
C'est comme ca que marche la BD de Beagle, avec inotify.
[^] # Re: BDD vs fichier
Posté par bobefrei . Évalué à 2.
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 salvaire . Évalué à 0.
[^] # Re: À cause des nouveaux utilisateurs?
Posté par TImaniac (site web personnel) . Évalué à 0.
Alors non ca ne sert pas qu'à bouffer des watts.
[^] # Re: À cause des nouveaux utilisateurs?
Posté par Mildred (site web personnel) . Évalué à 1.
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 Djax . Évalué à 3.
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.
[^] # Le moyen != le besoin
Posté par Djax . Évalué à 1.
# Peut-être
Posté par Séverin Tagliante-Saracino . Évalué à 1.
http://www.gobolinux.org/index.php?lang=en_US&page=doc/articles(...)
# Distinguer interface grand public / organisation interne du système
Posté par free2.org . Évalué à 2.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.