Concernant LUFS :
- ça ne risque pas d'être intégré un jour ou l'autre au noyau, l'API est très différente et en C++ (comme l'implémentation d'ailleurs).
- c'est pas vraiment trivial d'implémenter un nouveau fs dedans (nécessité de recompiler le tout... en tout cas à l'époque où j'avais voulu faire un truc dessus)
- La dernière version date du 30 octobre 2003. Je considère le projet comme abandonné devant un autre plus prometteur nommé fuse.
Alors, fuse
- est en C
- semble plus clean (en tout cas pour ce que j'en ai fait) et est à coup sûr plus actif
- pourrait être bientôt intégré au noyau Linux (en tout cas c'est ce que j'ai lu...).
- a depuis peu un tout nouveau site tout beau : http://fuse.sourceforge.net/
On peut se demander pourquoi Linux n'utilise pas ce genre de truc depuis 14 ans, ça permet de décharger _énormément_ le noyau et donc les efforts du programmeur puisqu'on peut désormais utiliser les bibliothèques partagées (un exemple : la libsmbclient permet de faire un fs smb/CIFS stable et complet en quelques lignes de code plutôt que d'utiliser l'immonde smbfs du noyau !). Des gros fs comme coda/intermezzo gagneraient également énormément à être implémentés de cette manière...
Petite question hors-sujet pour ceux qui connaissent bien les arcanes du hurd ou de la conception d'OS : pourquoi vouloir absolument scinder l'OS en de multiples processus serveurs ayant chacuns leur espaces d'adressages distincts ? OK pour la sécurité/sûreté mais ce que je veux dire c'est que ça pénalise tout de même pas mal les performances (changements de contextes, cache invalidé...) et il y a peut-être d'autres moyens de virer du code hors du noyau sans en passer par là. N'y aurait-il pas par ex. moyen de faire que (si l'utilisateur le configure ainsi) le hurd puisse utiliser davantage le concept de bibliothèques partagées (i.e. des bouts de code mappés dans l'espace d'adressage de l'appli en cours) plutôt que de "serveurs" ? Par exemple, on pourrait à mon avis fort bien imaginer que toute la pile IP, le firewalling, etc soit implémenté dans une (ou des) DLLs, idem pour les pilotes de périphériques, etc. Il me semble (mais je ne suis pas sûr, qqun peut confirmer ?) que c'est un peu l'idée des exokernels, et qu'apparemment ça booste bien les perfs et ça rassemble le meilleur des deux mondes (système rapide, modulaire et tout petit noyau).
kernel code is inherently more difficult to extend than user space code, especially because we can re-use user space shared libs in user space code. For example, writing a user space filesystem (Gnome-VFS, libferris...) should be easier than writing a kernel one, but those are not "true" filesystems...
1) is it planned to integrate in the "official" kernel something like fuse or lufs in order to write true filesystems in user space ?
2) would it be theoretically possible to move major parts of the kernel (ip stack, netfilter, device drivers, VFS...) into userland shared libs in order to make the kernel part lighter & more real-time and the "user part" more easily extensible ? (without loss of performance, for exemple that would avoid context switches for any system call belonging to this "user part").
Vraiment dommage de pas avoir une version libre de qt pour windows, il y'a un port libre de la version linux mais je crains que ce dernier suive difficilement le rythme des releases de trolltech.
Y'a pourtant un autre gros toolkit en C++ bizarrement méconnu qui s'appelle FOX-toolkit et qui est franchement bien abouti (multiplateforme, LGPL, rapide, stable, complet, facile à utiliser, wrappers pour {python,ruby,ada...}. Y'a qu'un défaut à mon sens : le look est "windowsien" et il n'est pas encore thémable, ce sera pour la version 2 (mais ce qui compte c'est avant tout d'avoir du code propre, stable et qui marche vite non ?)).
Bravo pour l'initiative ! (en fait ça fait longtemps que j'en rêvais et ils l'ont fait !)
Par contre, malgré tous ses défauts, M$-Office a au moins l'avantage de s'ouvrir très vite, à comparer avec la lourdeur de Ooo (même avec le pré-chargement). Cela suffit à décourager des utilisateurs potentiels d'Ooo.
Du coup, je m'interroge sur la réactivité / utilisabilité de cette solution pour les utilisateurs "non convaincus" à la base : pour utiliser (quotidiennement) PDFcreator (qui utilise ghostscript) pour passer du .doc en PDF je peux dire que malgré tous ses atouts la vitesse n'est pas son point fort (encore pire qu'une ouverture avec Ooo) => si on rajoute une couche serveur / réseau en Python qu'est-ce que ça doit être... ! (des retours sur ce point ?)
J'imagine aussi que l'export en RTF est plus véloce mais du coup la mise en page peut être en partie perdue non ?
Oh !
Bon, ayant deja utilise des formats binaires et l'ayant regrette, je me dois de reagir.
Je n'ai pas dit que le stockage binaire était la solution parfaite ou universelle. Simplement si une "couche d'abstraction" était proposée pour distinguer "l'inferface utilisateur" et "l'interface programme" pour la config, chacun pourrait choisir s'il préfère maintenir des fichiers textes (convertis / "compilés" ensuite vers la base de registres qui ne serait qu'un cache) ou un éditeur distinct qui utiliserait directement la lib (dans mon exemple berkeley DB) pour écrire dedans.
Il me semble que KDE utilise déjà un schéma similaire (même si le format binaire n'est qu'un cache sur des fichiers txt), et que e17 adopte aussi la même approche (avec edb)...
En tout cas en ce qui me concerne j'aurais vite fait mon choix, car j'estime que le problème du stockage / récupération de paires "clé = valeur" est résolu depuis longtemps, de manière efficace par les SGBD, et que par conséquent ce n'est pas au programmeur de refaire ce boulot en moins bien.
Ca oblige a parser du binaire. A tenir compte du big/little endian
?!?
Mais non, on ne parse rien ! Pour le programmeur tout doit être transparent (avec une lib dédiée).
Tout ce que le programmeur voit, c'est qu'il peut insérer / lire (rapidement puisque c'est indexé) des paires clé = valeur, sans rien avoir à parcourir puisque c'est la DB qui le fait pour lui... Par contre avec des fichiers txt c'est le programme lui-même qui doit faire tout le boulot (=> code bloat, sauf peut-être s'il utilise un truc comme gconf (que je ne connais pas donc je ne jugerai pas)). La chaîne "ma_cle = 120" prend 12 octets sans signification pour la machine alors qu'un stockage binaire {clé = "ma_clé", valeur = 120} est moins gourmand et surtout beaucoup plus vite retrouvé et "compris"...
Par exemple, un nom d'utilisateur, c'est du texte, pas du binaire
Bien sûr, mais tu fais une distinction superflue entre texte et binaire. Un fichier "binaire" (i.e. non 100 % ASCII) peut très bien contenir des chaînes de caractères ASCII (pour les clés comme pour les valeurs) et sans conversion aucune. Pour l'endianness, on stocke les données comme on veut (et dans tous les cas au pire ça prend moins de cycles de convertir l'endianness que de convertir un nombre de l'ASCII vers le binaire !)
il faut un editeur specifique pour une base BerkeleyDB
Rien n'empêche d'imaginer des convertisseurs ASCII<->DB pour les durs de durs qui veulent absolument utiliser vi ! Par contre on n'est plus _obligé_ de se taper la conf au format texte
Outils de dump/recovery. Ils existent aussi pour les fichiers texte. Mon prefere s'appelle "cp"...
OK. Mais normalement le problème de l'intégrité dans les bases de données est résolu depuis longtemps aussi (regardes combien de données critiques sont stockées (en binaires) par les SGBD). Si la base supporte les transactions normalement ça ne devrait pas poser problème ! D'autre part pour l'utilisateur lambda un fichier texte "corrompu" sera au moins aussi difficile à restaurer, à moins qu'il n'ait le courage de se replonger dans la doc...
Concernant le CPU, tu economises quelques dizaines de millisecondes a chaque lancement du programme. Ca doit te faire gagner grand maximum une 10aine de secondes dans une journee. Wow ! Ce n'est pas comme si on avait une boucle qui itere des milliers de fois sur ce genre de choses !
Nan, bien sûr, mais j'ai surtout voulu insister non pas sur le CPU mais sur le code bloat vu qu'actuellement une quantité non négligeables de code est écrit juste pour parser la conf. Effectivement je ne sais pas trop comment ça se passe avec gconf ou libconf, et si l'un de ces systèmes était adopté de manière universelle le pb serait résolu puisqu'il suffirait que le "backend" soit suffisamment modulaire pour qu'on puisse au choix utiliser du txt ou du binaire...
Je prefere glibc qui implement des fonctions de lecture de fichiers texte (fgets, fputs) comme couche d'abstraction, mais c'est mon avis :)
Je préfère une espèce de "libconf universelle" qui serait utilisée par tous et serait suffisamment modulaire pour ne pas contraindre le programmeur et l'utilisateur à un schéma particulier ! fgets/fputs ce n'est pas une couche d'abstraction puisque l'appli dicte encore _comment_ enregistrer ses données (ce qu'on voulait justement abstraire).
J'ai longtemps pensé le contraire en fait, en voyant les m... qu'engendrait un windoze tout cassé (au point que le 1er truc que je faisais après une install était de sauvegarder user.dat et system.dat).
Mais le pb est là :
- avoir un "vrai" panneau de config universel (graphique ou toute autre nouvelle idée) sera une illusion tant que le système actuel perdurera. Ou plutôt même s'il existait il impliquerait énormément de code superflu et autant de bogues potentiels (un parser pour chaque type de fichier de config... Sans parler de la gestion d'erreurs, etc...)
- le "code bloat" pris par les parsers en questions existe déjà... dans tous les logiciels ! Si une registry existait ça ferait autant de lignes de codes qu'on pourrait balancer à la poubelle pour rendre les softs plus légers & plus fiables.
- rester avec le système actuel ("moi je fait tout à la main avec vi") est bien dans l'esprit des geeks mais je constate qu'après plus de 10 ans d'existence et des efforts considérables de la part des mandrake & co Linux est toujours perçu comme difficile d'accès...
Reste à voir comment ils l'implémentent. Pour ma part je préfèrerais un format binaire "natif" (ça évite de parser du texte à chaque fois et ça économise donc du CPU) avec un truc "standard" comme par ex BerkeleyDB, qui disposent tout de même de fonctionnalités de dump/recovery. Après, libre aux geeks d'implémenter une forme de "panneau de config" sous forme de fichiers textes et de parsers si ils veulent. L'important est de séparer la récupération de la config par les applis de la saisie des infos de config (panneau de config ou fichiers textes) pour que le système soit adaptable aux besoins de l'utilisateurs (et AHMA BerkeleyDB me semble être un bon choix pour une "couche d'abstraction").
De tt façons il me semble que certains y ont déjà pensés depuis longtemps, même si l'implémentation différait (genre Ximian qui voulait mettre les fichiers de config en xml si je ne m'abuse)...
Musique = pas de pb (en tout cas pour du mp3. Après, je sais pas si le ogg est + gourmand en ressources...)
X + window manager "léger" = pas de pb non plus du moment que tu ne charges pas avec des trucs gourmands comme KDE.
Par contre pour ce qui est traîtement de texte, ça risque d'être + chaud : en effet, depuis OpenOffice, Linux a "enfin" une suite bureautique comparable à MS Office. Le pb c'est qu'il n'y a à peu près que celle là, et qu'elle n'est pas du tout légère ! (à voir pour la version 2.0, ils vont apparemment alléger tout ça avec une lib toolkit à part...).
Comme j'imagines que tu ne veux pas revenir à la sale époque du win95+word, tu peux AMHA essayer des traîtements de textes "alternatifs" comme :
- abiword / GNUmeric
- SIAG office
- Wordperfect 7 (je sais, sapusépalibre)
- LyX / LaTeX si ça se prête à tes usages
- (qqun sait si Applixware existe tjs ?)
- StarOffice 5 si elle se révèle plus légère que OpenOffice mais je ne suis pas sûr
- un éditeur HTML WYSIWYG comme nvu + CSS + le "imprimer" dans firefox ?
Du reste à mon avis la distrib elle-même importe peu, du moment que tu la configures bien. D'une manière générale hormis les mastodontes incontournables comme Mozilla & OpenOffice (pour lesquels il manque un "concurrent léger") tu as tjs le choix pour les autres catégories de logiciels (par ex mettre windowmaker ou icewm à la place de KDE, etc...).
Hmmm, cela ne se limite pas à Moz, Regardes aussi OpenOffice ! Regardes la lenteur générale de X + GDK/GTK ou QT/KDE !
Si au moins on pouvait avoir un système de widget implémenté comme une extension (unique) au protocole X, et rendu côté serveur (comme PicoGUI), et un serveur X implémenté au dessus d'une lib graphique 2D/3D (comme OpenGL) optimisée pour être en bas de la pile...
Apparemment SQLite est récent. Qqun peut me dire pourquoi ils ont réimplémenté eux-mêmes toutes les fonctions de stockage (hash, arbres, transactions...) alors qu'il suffisait d'écrire un frontend SQL à Berkeley DB 4 qui gère déjà très bien (et depuis longtemps) tout le "sale boulot'" ?
D'ailleurs, je serais curieux de voir ce que pourrait donner la comparaison SQLite vs {BerkeleyDB + frontend SQL "bien écrit"} niveau benchmarks... ça au moins ce serait comparable (contrairement à du "SQlite vs MySQL" de base, qui est un peu absurde vu que MySQL est un serveur !).
N.B.: J'ai vu que MySQL disposait aussi d'un mode "bibliothèque", dans lequel on peut se passer de serveur (MySQL devient simplement une bibliothèque à linker, comme SQLite). Si on veut comparer les performances entre les 2 il faut utiliser MySQL de cette façons... Qqun sait ce que ça donne ?
Pourquoi se borner aux deux seules solutions :
- soit on continue dans la voie actuelle (protocole X bas niveau + toolkits (GTK/QT) gourmands)
- soit on recommence tout à zéro (Fresco/Y)
=> On pourrait très bien imaginer d'étendre le protocole X (de même qu'il existe plein d'autres extensions comme Render, etc...) avec des appels de haut niveau (à la GTK) pour gérer le rendu du toolkit côté serveur ! (et si ça a du succès QT et GTK pourraient en partie être réécrits pour n'être que des "wrappers" autour de cette extension).
Il me semble que ce genre de solution résoudrait le problème sans casser la compatibilité ou tout recommencer à 0 puisque les deux "modes" seraient possibles. (dites moi si je me trompe)
Autre chose tant que j'y suis : je trouve que ça pourrait être pas mal si on séparait aussi (côté serveur) nettement la partie "driver graphique" de la partie "serveur", de manière à avoir une bibliothèque "à la SDL" qui parle directement au hardware sans avoir à se taper des couches intermédiaires (comme X, puisque actuellement il me semble que SDL est au dessus de X et non en dessous, le contraire serait plus logique non ?), ça serait pratique pour les jeux et ça rendrait le serveur X plus modulaire.
(je sais, SDL existe au dessus du framebuffer mais dans ce cas on pert tous les bénéfices des drivers graphiques accélérés de X, idem dans le cas de DirectFB où les drivers sont réécrits en partants de 0).
Bon, je sais, << les "y'a qu'à" et les "faut qu'on" sont les prédateurs de l'homo bénévolus >>, mais vu l'ampleur c'est pas vraiment le genre de truc qu'on peut expérimenter tout seul dans son coin... ;)
[^] # Re: heeeuu
Posté par karteum59 . En réponse à la dépêche Hurd : nouvelle version de Debian GNU/Hurd et avancée du port sur L4. Évalué à 6.
- ça ne risque pas d'être intégré un jour ou l'autre au noyau, l'API est très différente et en C++ (comme l'implémentation d'ailleurs).
- c'est pas vraiment trivial d'implémenter un nouveau fs dedans (nécessité de recompiler le tout... en tout cas à l'époque où j'avais voulu faire un truc dessus)
- La dernière version date du 30 octobre 2003. Je considère le projet comme abandonné devant un autre plus prometteur nommé fuse.
Alors, fuse
- est en C
- semble plus clean (en tout cas pour ce que j'en ai fait) et est à coup sûr plus actif
- pourrait être bientôt intégré au noyau Linux (en tout cas c'est ce que j'ai lu...).
- a depuis peu un tout nouveau site tout beau : http://fuse.sourceforge.net/
On peut se demander pourquoi Linux n'utilise pas ce genre de truc depuis 14 ans, ça permet de décharger _énormément_ le noyau et donc les efforts du programmeur puisqu'on peut désormais utiliser les bibliothèques partagées (un exemple : la libsmbclient permet de faire un fs smb/CIFS stable et complet en quelques lignes de code plutôt que d'utiliser l'immonde smbfs du noyau !). Des gros fs comme coda/intermezzo gagneraient également énormément à être implémentés de cette manière...
Petite question hors-sujet pour ceux qui connaissent bien les arcanes du hurd ou de la conception d'OS : pourquoi vouloir absolument scinder l'OS en de multiples processus serveurs ayant chacuns leur espaces d'adressages distincts ? OK pour la sécurité/sûreté mais ce que je veux dire c'est que ça pénalise tout de même pas mal les performances (changements de contextes, cache invalidé...) et il y a peut-être d'autres moyens de virer du code hors du noyau sans en passer par là. N'y aurait-il pas par ex. moyen de faire que (si l'utilisateur le configure ainsi) le hurd puisse utiliser davantage le concept de bibliothèques partagées (i.e. des bouts de code mappés dans l'espace d'adressage de l'appli en cours) plutôt que de "serveurs" ? Par exemple, on pourrait à mon avis fort bien imaginer que toute la pile IP, le firewalling, etc soit implémenté dans une (ou des) DLLs, idem pour les pilotes de périphériques, etc. Il me semble (mais je ne suis pas sûr, qqun peut confirmer ?) que c'est un peu l'idée des exokernels, et qu'apparemment ça booste bien les perfs et ça rassemble le meilleur des deux mondes (système rapide, modulaire et tout petit noyau).
# Kernel & user space libs
Posté par karteum59 . En réponse au message Interview Alan Cox. Évalué à 1.
1) is it planned to integrate in the "official" kernel something like fuse or lufs in order to write true filesystems in user space ?
2) would it be theoretically possible to move major parts of the kernel (ip stack, netfilter, device drivers, VFS...) into userland shared libs in order to make the kernel part lighter & more real-time and the "user part" more easily extensible ? (without loss of performance, for exemple that would avoid context switches for any system call belonging to this "user part").
[^] # Re: Interview de Bryce Harrington
Posté par karteum59 . En réponse à la dépêche Sortie d'Inkscape 0.40. Évalué à 3.
Y'a pourtant un autre gros toolkit en C++ bizarrement méconnu qui s'appelle FOX-toolkit et qui est franchement bien abouti (multiplateforme, LGPL, rapide, stable, complet, facile à utiliser, wrappers pour {python,ruby,ada...}. Y'a qu'un défaut à mon sens : le look est "windowsien" et il n'est pas encore thémable, ce sera pour la version 2 (mais ce qui compte c'est avant tout d'avoir du code propre, stable et qui marche vite non ?)).
http://www.fox-toolkit.org(...)
(n.b. peut-être que lorsque swtfox sera plus abouti on entendra davantage parler de ce tookit pq apparemment ça rame nettement moins que swt/gtk...)
# Vitesse export PDF ?
Posté par karteum59 . En réponse à la dépêche Publication du Linbox-Converter, logiciel libre de conversion de documents MS-Office.. Évalué à 2.
Par contre, malgré tous ses défauts, M$-Office a au moins l'avantage de s'ouvrir très vite, à comparer avec la lourdeur de Ooo (même avec le pré-chargement). Cela suffit à décourager des utilisateurs potentiels d'Ooo.
Du coup, je m'interroge sur la réactivité / utilisabilité de cette solution pour les utilisateurs "non convaincus" à la base : pour utiliser (quotidiennement) PDFcreator (qui utilise ghostscript) pour passer du .doc en PDF je peux dire que malgré tous ses atouts la vitesse n'est pas son point fort (encore pire qu'une ouverture avec Ooo) => si on rajoute une couche serveur / réseau en Python qu'est-ce que ça doit être... ! (des retours sur ce point ?)
J'imagine aussi que l'export en RTF est plus véloce mais du coup la mise en page peut être en partie perdue non ?
# .doc c'est libre ?
Posté par karteum59 . En réponse à la dépêche Lille, conférences logiciel libre et Install Party. Évalué à -1.
Ce serait peut-être bien de leur dire que OpenOffice ça existe (à défaut de LaTeX ou abiword...)
[^] # Re: Moi je trouve que c'est une bonne idée
Posté par karteum59 . En réponse à la dépêche Une base de registre pour Linux ?. Évalué à 1.
Bon, ayant deja utilise des formats binaires et l'ayant regrette, je me dois de reagir.
Je n'ai pas dit que le stockage binaire était la solution parfaite ou universelle. Simplement si une "couche d'abstraction" était proposée pour distinguer "l'inferface utilisateur" et "l'interface programme" pour la config, chacun pourrait choisir s'il préfère maintenir des fichiers textes (convertis / "compilés" ensuite vers la base de registres qui ne serait qu'un cache) ou un éditeur distinct qui utiliserait directement la lib (dans mon exemple berkeley DB) pour écrire dedans.
Il me semble que KDE utilise déjà un schéma similaire (même si le format binaire n'est qu'un cache sur des fichiers txt), et que e17 adopte aussi la même approche (avec edb)...
En tout cas en ce qui me concerne j'aurais vite fait mon choix, car j'estime que le problème du stockage / récupération de paires "clé = valeur" est résolu depuis longtemps, de manière efficace par les SGBD, et que par conséquent ce n'est pas au programmeur de refaire ce boulot en moins bien.
Ca oblige a parser du binaire. A tenir compte du big/little endian
?!?
Mais non, on ne parse rien ! Pour le programmeur tout doit être transparent (avec une lib dédiée).
Tout ce que le programmeur voit, c'est qu'il peut insérer / lire (rapidement puisque c'est indexé) des paires clé = valeur, sans rien avoir à parcourir puisque c'est la DB qui le fait pour lui... Par contre avec des fichiers txt c'est le programme lui-même qui doit faire tout le boulot (=> code bloat, sauf peut-être s'il utilise un truc comme gconf (que je ne connais pas donc je ne jugerai pas)). La chaîne "ma_cle = 120" prend 12 octets sans signification pour la machine alors qu'un stockage binaire {clé = "ma_clé", valeur = 120} est moins gourmand et surtout beaucoup plus vite retrouvé et "compris"...
Par exemple, un nom d'utilisateur, c'est du texte, pas du binaire
Bien sûr, mais tu fais une distinction superflue entre texte et binaire. Un fichier "binaire" (i.e. non 100 % ASCII) peut très bien contenir des chaînes de caractères ASCII (pour les clés comme pour les valeurs) et sans conversion aucune. Pour l'endianness, on stocke les données comme on veut (et dans tous les cas au pire ça prend moins de cycles de convertir l'endianness que de convertir un nombre de l'ASCII vers le binaire !)
il faut un editeur specifique pour une base BerkeleyDB
Rien n'empêche d'imaginer des convertisseurs ASCII<->DB pour les durs de durs qui veulent absolument utiliser vi ! Par contre on n'est plus _obligé_ de se taper la conf au format texte
Outils de dump/recovery. Ils existent aussi pour les fichiers texte. Mon prefere s'appelle "cp"...
OK. Mais normalement le problème de l'intégrité dans les bases de données est résolu depuis longtemps aussi (regardes combien de données critiques sont stockées (en binaires) par les SGBD). Si la base supporte les transactions normalement ça ne devrait pas poser problème ! D'autre part pour l'utilisateur lambda un fichier texte "corrompu" sera au moins aussi difficile à restaurer, à moins qu'il n'ait le courage de se replonger dans la doc...
Concernant le CPU, tu economises quelques dizaines de millisecondes a chaque lancement du programme. Ca doit te faire gagner grand maximum une 10aine de secondes dans une journee. Wow ! Ce n'est pas comme si on avait une boucle qui itere des milliers de fois sur ce genre de choses !
Nan, bien sûr, mais j'ai surtout voulu insister non pas sur le CPU mais sur le code bloat vu qu'actuellement une quantité non négligeables de code est écrit juste pour parser la conf. Effectivement je ne sais pas trop comment ça se passe avec gconf ou libconf, et si l'un de ces systèmes était adopté de manière universelle le pb serait résolu puisqu'il suffirait que le "backend" soit suffisamment modulaire pour qu'on puisse au choix utiliser du txt ou du binaire...
Je prefere glibc qui implement des fonctions de lecture de fichiers texte (fgets, fputs) comme couche d'abstraction, mais c'est mon avis :)
Je préfère une espèce de "libconf universelle" qui serait utilisée par tous et serait suffisamment modulaire pour ne pas contraindre le programmeur et l'utilisateur à un schéma particulier ! fgets/fputs ce n'est pas une couche d'abstraction puisque l'appli dicte encore _comment_ enregistrer ses données (ce qu'on voulait justement abstraire).
[^] # Re: Moi je trouve que c'est une bonne idée
Posté par karteum59 . En réponse à la dépêche Une base de registre pour Linux ?. Évalué à 0.
J'ai longtemps pensé le contraire en fait, en voyant les m... qu'engendrait un windoze tout cassé (au point que le 1er truc que je faisais après une install était de sauvegarder user.dat et system.dat).
Mais le pb est là :
- avoir un "vrai" panneau de config universel (graphique ou toute autre nouvelle idée) sera une illusion tant que le système actuel perdurera. Ou plutôt même s'il existait il impliquerait énormément de code superflu et autant de bogues potentiels (un parser pour chaque type de fichier de config... Sans parler de la gestion d'erreurs, etc...)
- le "code bloat" pris par les parsers en questions existe déjà... dans tous les logiciels ! Si une registry existait ça ferait autant de lignes de codes qu'on pourrait balancer à la poubelle pour rendre les softs plus légers & plus fiables.
- rester avec le système actuel ("moi je fait tout à la main avec vi") est bien dans l'esprit des geeks mais je constate qu'après plus de 10 ans d'existence et des efforts considérables de la part des mandrake & co Linux est toujours perçu comme difficile d'accès...
Reste à voir comment ils l'implémentent. Pour ma part je préfèrerais un format binaire "natif" (ça évite de parser du texte à chaque fois et ça économise donc du CPU) avec un truc "standard" comme par ex BerkeleyDB, qui disposent tout de même de fonctionnalités de dump/recovery. Après, libre aux geeks d'implémenter une forme de "panneau de config" sous forme de fichiers textes et de parsers si ils veulent. L'important est de séparer la récupération de la config par les applis de la saisie des infos de config (panneau de config ou fichiers textes) pour que le système soit adaptable aux besoins de l'utilisateurs (et AHMA BerkeleyDB me semble être un bon choix pour une "couche d'abstraction").
De tt façons il me semble que certains y ont déjà pensés depuis longtemps, même si l'implémentation différait (genre Ximian qui voulait mettre les fichiers de config en xml si je ne m'abuse)...
[^] # Re: Pour quel usage ?
Posté par karteum59 . En réponse au message Quel distrib choisir pour un vieux pc. Évalué à 3.
X + window manager "léger" = pas de pb non plus du moment que tu ne charges pas avec des trucs gourmands comme KDE.
Par contre pour ce qui est traîtement de texte, ça risque d'être + chaud : en effet, depuis OpenOffice, Linux a "enfin" une suite bureautique comparable à MS Office. Le pb c'est qu'il n'y a à peu près que celle là, et qu'elle n'est pas du tout légère ! (à voir pour la version 2.0, ils vont apparemment alléger tout ça avec une lib toolkit à part...).
Comme j'imagines que tu ne veux pas revenir à la sale époque du win95+word, tu peux AMHA essayer des traîtements de textes "alternatifs" comme :
- abiword / GNUmeric
- SIAG office
- Wordperfect 7 (je sais, sapusépalibre)
- LyX / LaTeX si ça se prête à tes usages
- (qqun sait si Applixware existe tjs ?)
- StarOffice 5 si elle se révèle plus légère que OpenOffice mais je ne suis pas sûr
- un éditeur HTML WYSIWYG comme nvu + CSS + le "imprimer" dans firefox ?
Du reste à mon avis la distrib elle-même importe peu, du moment que tu la configures bien. D'une manière générale hormis les mastodontes incontournables comme Mozilla & OpenOffice (pour lesquels il manque un "concurrent léger") tu as tjs le choix pour les autres catégories de logiciels (par ex mettre windowmaker ou icewm à la place de KDE, etc...).
[^] # Re: gtk2+ xft
Posté par karteum59 . En réponse à la dépêche L'éditeur HTML Nvu 0.40 est sorti. Évalué à 7.
Si au moins on pouvait avoir un système de widget implémenté comme une extension (unique) au protocole X, et rendu côté serveur (comme PicoGUI), et un serveur X implémenté au dessus d'une lib graphique 2D/3D (comme OpenGL) optimisée pour être en bas de la pile...
# BerkeleyDB ?
Posté par karteum59 . En réponse à la dépêche Ça bouge du côté de SQLite !. Évalué à 4.
D'ailleurs, je serais curieux de voir ce que pourrait donner la comparaison SQLite vs {BerkeleyDB + frontend SQL "bien écrit"} niveau benchmarks... ça au moins ce serait comparable (contrairement à du "SQlite vs MySQL" de base, qui est un peu absurde vu que MySQL est un serveur !).
N.B.: J'ai vu que MySQL disposait aussi d'un mode "bibliothèque", dans lequel on peut se passer de serveur (MySQL devient simplement une bibliothèque à linker, comme SQLite). Si on veut comparer les performances entre les 2 il faut utiliser MySQL de cette façons... Qqun sait ce que ça donne ?
[^] # Re: Long coup de gueule
Posté par karteum59 . En réponse à la dépêche Traduction en français du "Encourage Women in Linux HOWTO". Évalué à 4.
Bon OK je sors... -> []
[^] # Re: Mouais
Posté par karteum59 . En réponse à la dépêche Traduction en français du "Encourage Women in Linux HOWTO". Évalué à 6.
Au fait, comment il faut appeler une femme chasseur alpin ? :o)
[^] # Re: Y.org
Posté par karteum59 . En réponse à la dépêche XFree86 a de moins en moins la côte. Évalué à 1.
- soit on continue dans la voie actuelle (protocole X bas niveau + toolkits (GTK/QT) gourmands)
- soit on recommence tout à zéro (Fresco/Y)
=> On pourrait très bien imaginer d'étendre le protocole X (de même qu'il existe plein d'autres extensions comme Render, etc...) avec des appels de haut niveau (à la GTK) pour gérer le rendu du toolkit côté serveur ! (et si ça a du succès QT et GTK pourraient en partie être réécrits pour n'être que des "wrappers" autour de cette extension).
Il me semble que ce genre de solution résoudrait le problème sans casser la compatibilité ou tout recommencer à 0 puisque les deux "modes" seraient possibles. (dites moi si je me trompe)
Autre chose tant que j'y suis : je trouve que ça pourrait être pas mal si on séparait aussi (côté serveur) nettement la partie "driver graphique" de la partie "serveur", de manière à avoir une bibliothèque "à la SDL" qui parle directement au hardware sans avoir à se taper des couches intermédiaires (comme X, puisque actuellement il me semble que SDL est au dessus de X et non en dessous, le contraire serait plus logique non ?), ça serait pratique pour les jeux et ça rendrait le serveur X plus modulaire.
(je sais, SDL existe au dessus du framebuffer mais dans ce cas on pert tous les bénéfices des drivers graphiques accélérés de X, idem dans le cas de DirectFB où les drivers sont réécrits en partants de 0).
Bon, je sais, << les "y'a qu'à" et les "faut qu'on" sont les prédateurs de l'homo bénévolus >>, mais vu l'ampleur c'est pas vraiment le genre de truc qu'on peut expérimenter tout seul dans son coin... ;)