Je viens juste d'installer la dernière d'Ubuntu dans une VM.
1/2 heure pour trouver comment ouvrir un xterm avec cet environnement
graphique tout pourri. En plus, y'a pas de compte root. Faut faire un
"sudo bash". Dans mon home, pourtant tout neuf, y'a déjà plein de
répertoires débiles qui ne servent à rien comme "Téléchargement, Mes
documents, etc..". C'est vraiment une distrib pour windosistes mal
dégrossis. C'est vraiment censé permettre à mémé de passer à Nunux ou
c'est une distrib pour que les jean-kevin se la pêtent ?
Bon, du coup je file installer FreeBSD...
--
syncing file systems... done
Press any key to reboot.
Le 13-06-2013, Nicolas George nous expliquait dans fr.comp.os.linux.debats :
Doug713705 , dans le message , a écrit :
Perso j'ai une préférence pour sqlite qui rend un service équivalent pour les maigres besoins en matières de BD des applis que je code.
Ça évite l'horreur du client-serveur incompréhensible inhérent aux bases de données SQL, mais ça reste un langage complètement nul pour interroger une structure de données inadaptée à la plupart des problèmes.
Néanmoins, si tu connais une alternative efficace à SQL je suis preneur.
Pour stocker quel genre de données ?
Du classique, du texte associé à des indexes le tout stocké dans des tables qu'il faut croiser dans tous les sens.
-- Doug - Linux user #307925 - Slackware64 roulaize ;-) Without freedom of choice there is no creativity. -- Kirk, "The return of the Archons", stardate 3157.4
Le 13-06-2013, Nicolas George nous expliquait dans fr.comp.os.linux.debats :
Doug713705 , dans le message
<il6o8axorb.ln2@actarus.chainon-marquant.org>, a écrit :
Perso j'ai une préférence pour sqlite qui rend un service équivalent
pour les maigres besoins en matières de BD des applis que je code.
Ça évite l'horreur du client-serveur incompréhensible inhérent aux bases de
données SQL, mais ça reste un langage complètement nul pour interroger une
structure de données inadaptée à la plupart des problèmes.
Néanmoins, si tu connais une alternative efficace à SQL je suis preneur.
Pour stocker quel genre de données ?
Du classique, du texte associé à des indexes le tout stocké dans des
tables qu'il faut croiser dans tous les sens.
--
Doug - Linux user #307925 - Slackware64 roulaize ;-)
Without freedom of choice there is no creativity.
-- Kirk, "The return of the Archons", stardate 3157.4
Le 13-06-2013, Nicolas George nous expliquait dans fr.comp.os.linux.debats :
Doug713705 , dans le message , a écrit :
Perso j'ai une préférence pour sqlite qui rend un service équivalent pour les maigres besoins en matières de BD des applis que je code.
Ça évite l'horreur du client-serveur incompréhensible inhérent aux bases de données SQL, mais ça reste un langage complètement nul pour interroger une structure de données inadaptée à la plupart des problèmes.
Néanmoins, si tu connais une alternative efficace à SQL je suis preneur.
Pour stocker quel genre de données ?
Du classique, du texte associé à des indexes le tout stocké dans des tables qu'il faut croiser dans tous les sens.
-- Doug - Linux user #307925 - Slackware64 roulaize ;-) Without freedom of choice there is no creativity. -- Kirk, "The return of the Archons", stardate 3157.4
Nicolas George
Doug713705 , dans le message , a écrit :
Du classique, du texte associé à des indexes le tout stocké dans des tables qu'il faut croiser dans tous les sens.
Ce genre de données, ça n'existe essentiellement pas. On invente de force ce type de structure quand on est coincé à utiliser une base de données relationnelle, mais la plupart des données finales ont une forme qui ne correspond pas du tout à cette structure.
C'est mon principale reproche à du SQL : c'est le « quand on n'a qu'un marteau, tout ressemble à un clou » poussé au point de pourrir l'esprit des développeurs, qui se retrouvent même incapables de reconnaître que leurs données n'ont rien à voir avec un clou.
Doug713705 , dans le message
<vkip8ax22j.ln2@actarus.chainon-marquant.org>, a écrit :
Du classique, du texte associé à des indexes le tout stocké dans des
tables qu'il faut croiser dans tous les sens.
Ce genre de données, ça n'existe essentiellement pas. On invente de force ce
type de structure quand on est coincé à utiliser une base de données
relationnelle, mais la plupart des données finales ont une forme qui ne
correspond pas du tout à cette structure.
C'est mon principale reproche à du SQL : c'est le « quand on n'a qu'un
marteau, tout ressemble à un clou » poussé au point de pourrir l'esprit des
développeurs, qui se retrouvent même incapables de reconnaître que leurs
données n'ont rien à voir avec un clou.
Du classique, du texte associé à des indexes le tout stocké dans des tables qu'il faut croiser dans tous les sens.
Ce genre de données, ça n'existe essentiellement pas. On invente de force ce type de structure quand on est coincé à utiliser une base de données relationnelle, mais la plupart des données finales ont une forme qui ne correspond pas du tout à cette structure.
C'est mon principale reproche à du SQL : c'est le « quand on n'a qu'un marteau, tout ressemble à un clou » poussé au point de pourrir l'esprit des développeurs, qui se retrouvent même incapables de reconnaître que leurs données n'ont rien à voir avec un clou.
Doug713705
Le 13-06-2013, Nicolas George nous expliquait dans fr.comp.os.linux.debats :
Doug713705 , dans le message , a écrit :
Du classique, du texte associé à des indexes le tout stocké dans des tables qu'il faut croiser dans tous les sens.
Ce genre de données, ça n'existe essentiellement pas. On invente de force ce type de structure quand on est coincé à utiliser une base de données relationnelle, mais la plupart des données finales ont une forme qui ne correspond pas du tout à cette structure.
C'est mon principale reproche à du SQL : c'est le « quand on n'a qu'un marteau, tout ressemble à un clou » poussé au point de pourrir l'esprit des développeurs, qui se retrouvent même incapables de reconnaître que leurs données n'ont rien à voir avec un clou.
Si tu veux bien me donner une recette pour m'aider à mieux formaliser mes données...
-- Doug - Linux user #307925 - Slackware64 roulaize ;-) Without freedom of choice there is no creativity. -- Kirk, "The return of the Archons", stardate 3157.4
Le 13-06-2013, Nicolas George nous expliquait dans fr.comp.os.linux.debats :
Doug713705 , dans le message
<vkip8ax22j.ln2@actarus.chainon-marquant.org>, a écrit :
Du classique, du texte associé à des indexes le tout stocké dans des
tables qu'il faut croiser dans tous les sens.
Ce genre de données, ça n'existe essentiellement pas. On invente de force ce
type de structure quand on est coincé à utiliser une base de données
relationnelle, mais la plupart des données finales ont une forme qui ne
correspond pas du tout à cette structure.
C'est mon principale reproche à du SQL : c'est le « quand on n'a qu'un
marteau, tout ressemble à un clou » poussé au point de pourrir l'esprit des
développeurs, qui se retrouvent même incapables de reconnaître que leurs
données n'ont rien à voir avec un clou.
Si tu veux bien me donner une recette pour m'aider à mieux formaliser
mes données...
--
Doug - Linux user #307925 - Slackware64 roulaize ;-)
Without freedom of choice there is no creativity.
-- Kirk, "The return of the Archons", stardate 3157.4
Le 13-06-2013, Nicolas George nous expliquait dans fr.comp.os.linux.debats :
Doug713705 , dans le message , a écrit :
Du classique, du texte associé à des indexes le tout stocké dans des tables qu'il faut croiser dans tous les sens.
Ce genre de données, ça n'existe essentiellement pas. On invente de force ce type de structure quand on est coincé à utiliser une base de données relationnelle, mais la plupart des données finales ont une forme qui ne correspond pas du tout à cette structure.
C'est mon principale reproche à du SQL : c'est le « quand on n'a qu'un marteau, tout ressemble à un clou » poussé au point de pourrir l'esprit des développeurs, qui se retrouvent même incapables de reconnaître que leurs données n'ont rien à voir avec un clou.
Si tu veux bien me donner une recette pour m'aider à mieux formaliser mes données...
-- Doug - Linux user #307925 - Slackware64 roulaize ;-) Without freedom of choice there is no creativity. -- Kirk, "The return of the Archons", stardate 3157.4
Nicolas George
Doug713705 , dans le message , a écrit :
Si tu veux bien me donner une recette pour m'aider à mieux formaliser mes données...
Il n'y a pas de recette, il suffit de te demander quelle est la structure des données telles que tu en as besoin dans ton programme, et pas telles que l'outil te l'impose. Examiner la manière dont les données sont stockées en mémoire et manipulées après lecture depuis la base de données est probablement un bon point de départ. En général, ça va être quelque chose de plutôt arborescent, avec quelques liens transversaux et éventuellement des sous-arbres fusionnés.
Doug713705 , dans le message
<ugjp8ax22j.ln2@actarus.chainon-marquant.org>, a écrit :
Si tu veux bien me donner une recette pour m'aider à mieux formaliser
mes données...
Il n'y a pas de recette, il suffit de te demander quelle est la structure
des données telles que tu en as besoin dans ton programme, et pas telles que
l'outil te l'impose. Examiner la manière dont les données sont stockées en
mémoire et manipulées après lecture depuis la base de données est
probablement un bon point de départ. En général, ça va être quelque chose de
plutôt arborescent, avec quelques liens transversaux et éventuellement des
sous-arbres fusionnés.
Si tu veux bien me donner une recette pour m'aider à mieux formaliser mes données...
Il n'y a pas de recette, il suffit de te demander quelle est la structure des données telles que tu en as besoin dans ton programme, et pas telles que l'outil te l'impose. Examiner la manière dont les données sont stockées en mémoire et manipulées après lecture depuis la base de données est probablement un bon point de départ. En général, ça va être quelque chose de plutôt arborescent, avec quelques liens transversaux et éventuellement des sous-arbres fusionnés.
pehache
Le 13/06/13 17:41, Nicolas George a écrit :
Doug713705 , dans le message , a écrit :
Perso j'ai une préférence pour sqlite qui rend un service équivalent pour les maigres besoins en matières de BD des applis que je code.
Ça évite l'horreur du client-serveur incompréhensible inhérent aux bases de données SQL, mais ça reste un langage complètement nul pour interroger une structure de données inadaptée à la plupart des problèmes.
Ca me rassure. Je n'ai jamais développé en *SQL (sinon à titre d'exercice) mais quand quand j'en ai lu (dans des scripts PHP) j'ai toujours trouvé ça mal foutu et incompréhensible au possible. Je finissais par me dire j'étais neuneu pour ne pas comprendre ce qui semble évident à tout le monde.
Le 13/06/13 17:41, Nicolas George a écrit :
Doug713705 , dans le message
<il6o8axorb.ln2@actarus.chainon-marquant.org>, a écrit :
Perso j'ai une préférence pour sqlite qui rend un service équivalent
pour les maigres besoins en matières de BD des applis que je code.
Ça évite l'horreur du client-serveur incompréhensible inhérent aux bases de
données SQL, mais ça reste un langage complètement nul pour interroger une
structure de données inadaptée à la plupart des problèmes.
Ca me rassure. Je n'ai jamais développé en *SQL (sinon à titre
d'exercice) mais quand quand j'en ai lu (dans des scripts PHP) j'ai
toujours trouvé ça mal foutu et incompréhensible au possible. Je
finissais par me dire j'étais neuneu pour ne pas comprendre ce qui
semble évident à tout le monde.
Perso j'ai une préférence pour sqlite qui rend un service équivalent pour les maigres besoins en matières de BD des applis que je code.
Ça évite l'horreur du client-serveur incompréhensible inhérent aux bases de données SQL, mais ça reste un langage complètement nul pour interroger une structure de données inadaptée à la plupart des problèmes.
Ca me rassure. Je n'ai jamais développé en *SQL (sinon à titre d'exercice) mais quand quand j'en ai lu (dans des scripts PHP) j'ai toujours trouvé ça mal foutu et incompréhensible au possible. Je finissais par me dire j'étais neuneu pour ne pas comprendre ce qui semble évident à tout le monde.
Doug713705
Le 13-06-2013, Nicolas George nous expliquait dans fr.comp.os.linux.debats :
Doug713705 , dans le message , a écrit :
Si tu veux bien me donner une recette pour m'aider à mieux formaliser mes données...
Il n'y a pas de recette, il suffit de te demander quelle est la structure des données telles que tu en as besoin dans ton programme, et pas telles que l'outil te l'impose. Examiner la manière dont les données sont stockées en mémoire et manipulées après lecture depuis la base de données est probablement un bon point de départ. En général, ça va être quelque chose de plutôt arborescent, avec quelques liens transversaux et éventuellement des sous-arbres fusionnés.
Effectivement, une structure arborescente est souvent ce que j'ai en tête mais après, je la stocke comment cette structure ? Dans un fichier plat ? En retrouver une au milieu de 20 000 enregistrements risque d'être coton.
Pour moi l'intérêt de SQL est de permettre de retrouver rapidement les données et de les croiser.
C'est essentiellement sur ce point que je n'ai pas vraiement d'alternative à SQL (mais il est vrai que je ne me suis jamais trop posé la question).
-- Doug - Linux user #307925 - Slackware64 roulaize ;-) Without freedom of choice there is no creativity. -- Kirk, "The return of the Archons", stardate 3157.4
Le 13-06-2013, Nicolas George nous expliquait dans fr.comp.os.linux.debats :
Doug713705 , dans le message
<ugjp8ax22j.ln2@actarus.chainon-marquant.org>, a écrit :
Si tu veux bien me donner une recette pour m'aider à mieux formaliser
mes données...
Il n'y a pas de recette, il suffit de te demander quelle est la structure
des données telles que tu en as besoin dans ton programme, et pas telles que
l'outil te l'impose. Examiner la manière dont les données sont stockées en
mémoire et manipulées après lecture depuis la base de données est
probablement un bon point de départ. En général, ça va être quelque chose de
plutôt arborescent, avec quelques liens transversaux et éventuellement des
sous-arbres fusionnés.
Effectivement, une structure arborescente est souvent ce que j'ai en
tête mais après, je la stocke comment cette structure ?
Dans un fichier plat ? En retrouver une au milieu de 20 000
enregistrements risque d'être coton.
Pour moi l'intérêt de SQL est de permettre de retrouver rapidement les
données et de les croiser.
C'est essentiellement sur ce point que je n'ai pas vraiement
d'alternative à SQL (mais il est vrai que je ne me suis jamais trop
posé la question).
--
Doug - Linux user #307925 - Slackware64 roulaize ;-)
Without freedom of choice there is no creativity.
-- Kirk, "The return of the Archons", stardate 3157.4
Le 13-06-2013, Nicolas George nous expliquait dans fr.comp.os.linux.debats :
Doug713705 , dans le message , a écrit :
Si tu veux bien me donner une recette pour m'aider à mieux formaliser mes données...
Il n'y a pas de recette, il suffit de te demander quelle est la structure des données telles que tu en as besoin dans ton programme, et pas telles que l'outil te l'impose. Examiner la manière dont les données sont stockées en mémoire et manipulées après lecture depuis la base de données est probablement un bon point de départ. En général, ça va être quelque chose de plutôt arborescent, avec quelques liens transversaux et éventuellement des sous-arbres fusionnés.
Effectivement, une structure arborescente est souvent ce que j'ai en tête mais après, je la stocke comment cette structure ? Dans un fichier plat ? En retrouver une au milieu de 20 000 enregistrements risque d'être coton.
Pour moi l'intérêt de SQL est de permettre de retrouver rapidement les données et de les croiser.
C'est essentiellement sur ce point que je n'ai pas vraiement d'alternative à SQL (mais il est vrai que je ne me suis jamais trop posé la question).
-- Doug - Linux user #307925 - Slackware64 roulaize ;-) Without freedom of choice there is no creativity. -- Kirk, "The return of the Archons", stardate 3157.4
Nicolas George
Doug713705 , dans le message , a écrit :
Effectivement, une structure arborescente est souvent ce que j'ai en tête mais après, je la stocke comment cette structure ? Dans un fichier plat ? En retrouver une au milieu de 20 000 enregistrements risque d'être coton.
Ça dépend du volume total des données, de la granularité de leur utilisation (si tu as toujours besoin de consulter presque tout, ce n'est pas la peine d'optimiser les accès individuels ; si tu sais toujours ce que tu veux lire, ce n'est pas la même chose que si tu dois chercher) et de leur modification, de la durée de vie de l'application (une application graphique ou un serveur dédié, qui peut garder les données en mémoire, ce n'est pas pareil qu'un CGI qui doit repartir de 0 à chaque fois rapidement), etc.
Tu peux utiliser un fichier structuré (JSON ou XML par exemple). Ou des fichiers structurés dans une structure de répertoires. Ou bien une table Berkeley-DB (associative clef -> valeur), avec des valeurs en JSON ou bien qui se pointent les unes vers les autres, etc.
Une structure que j'aime bien, quand elle est applicable, parce qu'elle est très facile à implémenter dans un langage interprété et très fiable, c'est la structure uniquement journalisée.
Pour moi l'intérêt de SQL est de permettre de retrouver rapidement les données et de les croiser.
C'est essentiellement sur ce point que je n'ai pas vraiement d'alternative à SQL (mais il est vrai que je ne me suis jamais trop posé la question).
Oui, c'est hélas assez vrai : SQL est une infection, mais c'est sur cette infection uniquement qu'un trouve du travail déjà fait.
Doug713705 , dans le message
<8cbs8axjdg.ln2@actarus.chainon-marquant.org>, a écrit :
Effectivement, une structure arborescente est souvent ce que j'ai en
tête mais après, je la stocke comment cette structure ?
Dans un fichier plat ? En retrouver une au milieu de 20 000
enregistrements risque d'être coton.
Ça dépend du volume total des données, de la granularité de leur utilisation
(si tu as toujours besoin de consulter presque tout, ce n'est pas la peine
d'optimiser les accès individuels ; si tu sais toujours ce que tu veux lire,
ce n'est pas la même chose que si tu dois chercher) et de leur modification,
de la durée de vie de l'application (une application graphique ou un serveur
dédié, qui peut garder les données en mémoire, ce n'est pas pareil qu'un CGI
qui doit repartir de 0 à chaque fois rapidement), etc.
Tu peux utiliser un fichier structuré (JSON ou XML par exemple). Ou des
fichiers structurés dans une structure de répertoires. Ou bien une table
Berkeley-DB (associative clef -> valeur), avec des valeurs en JSON ou bien
qui se pointent les unes vers les autres, etc.
Une structure que j'aime bien, quand elle est applicable, parce qu'elle est
très facile à implémenter dans un langage interprété et très fiable, c'est
la structure uniquement journalisée.
Pour moi l'intérêt de SQL est de permettre de retrouver rapidement les
données et de les croiser.
C'est essentiellement sur ce point que je n'ai pas vraiement
d'alternative à SQL (mais il est vrai que je ne me suis jamais trop
posé la question).
Oui, c'est hélas assez vrai : SQL est une infection, mais c'est sur cette
infection uniquement qu'un trouve du travail déjà fait.
Effectivement, une structure arborescente est souvent ce que j'ai en tête mais après, je la stocke comment cette structure ? Dans un fichier plat ? En retrouver une au milieu de 20 000 enregistrements risque d'être coton.
Ça dépend du volume total des données, de la granularité de leur utilisation (si tu as toujours besoin de consulter presque tout, ce n'est pas la peine d'optimiser les accès individuels ; si tu sais toujours ce que tu veux lire, ce n'est pas la même chose que si tu dois chercher) et de leur modification, de la durée de vie de l'application (une application graphique ou un serveur dédié, qui peut garder les données en mémoire, ce n'est pas pareil qu'un CGI qui doit repartir de 0 à chaque fois rapidement), etc.
Tu peux utiliser un fichier structuré (JSON ou XML par exemple). Ou des fichiers structurés dans une structure de répertoires. Ou bien une table Berkeley-DB (associative clef -> valeur), avec des valeurs en JSON ou bien qui se pointent les unes vers les autres, etc.
Une structure que j'aime bien, quand elle est applicable, parce qu'elle est très facile à implémenter dans un langage interprété et très fiable, c'est la structure uniquement journalisée.
Pour moi l'intérêt de SQL est de permettre de retrouver rapidement les données et de les croiser.
C'est essentiellement sur ce point que je n'ai pas vraiement d'alternative à SQL (mais il est vrai que je ne me suis jamais trop posé la question).
Oui, c'est hélas assez vrai : SQL est une infection, mais c'est sur cette infection uniquement qu'un trouve du travail déjà fait.
jp willm
Le 13/06/2013 08:43, Doug713705 a écrit :
C'est ce que disent tous ceux qui n'ont jamais utilisé openbox.
Mais j'ai essayé :o)
Je ne suis peut-être pas encore assez compétent pour pouvoir l'apprécier ?
Blague à part, je trouve openbox un peu aride quand on veut paramétrer vite fait son environnement à l'aide d'un gestionnaire qui obéit au clic.
-- http://perso.orange.fr/willms/index.html
Le 13/06/2013 08:43, Doug713705 a écrit :
C'est ce que disent tous ceux qui n'ont jamais utilisé openbox.
Mais j'ai essayé :o)
Je ne suis peut-être pas encore assez compétent pour pouvoir l'apprécier ?
Blague à part, je trouve openbox un peu aride quand on veut paramétrer
vite fait son environnement à l'aide d'un gestionnaire qui obéit au clic.
C'est ce que disent tous ceux qui n'ont jamais utilisé openbox.
Mais j'ai essayé :o)
Je ne suis peut-être pas encore assez compétent pour pouvoir l'apprécier ?
Blague à part, je trouve openbox un peu aride quand on veut paramétrer vite fait son environnement à l'aide d'un gestionnaire qui obéit au clic.
-- http://perso.orange.fr/willms/index.html
Doug713705
Le 15-06-2013, jp willm nous expliquait dans fr.comp.os.linux.debats :
C'est ce que disent tous ceux qui n'ont jamais utilisé openbox.
Mais j'ai essayé :o)
Je ne suis peut-être pas encore assez compétent pour pouvoir l'apprécier ?
Blague à part, je trouve openbox un peu aride quand on veut paramétrer vite fait son environnement à l'aide d'un gestionnaire qui obéit au clic.
Pour paramétrer openbox il faut y passer un peu de temps au début, surtout pour comprendre la structure de la configuration.
Ensuite pour paramétrer le tout il vaut mieux un éditeur de texte qu'un clickodrome.
Une fois tes raccourcis clavier définis, tes menus paramétrés et tes thèmes mis en place il n'y a plus guère de raison d'intervenir sur la configuration mis à part pour ajouter une application au menu (ce qui se fait en 30 secondes avec un éditeur de texte).
Pour tout ça le wiki d'openbox est vraiment très bien fait et la section openbox de celui d'Archlinux est un parfait complément.
Have fun. -- Doug - Linux user #307925 - Slackware64 roulaize ;-) Without freedom of choice there is no creativity. -- Kirk, "The return of the Archons", stardate 3157.4
Le 15-06-2013, jp willm nous expliquait dans fr.comp.os.linux.debats :
C'est ce que disent tous ceux qui n'ont jamais utilisé openbox.
Mais j'ai essayé :o)
Je ne suis peut-être pas encore assez compétent pour pouvoir l'apprécier ?
Blague à part, je trouve openbox un peu aride quand on veut paramétrer
vite fait son environnement à l'aide d'un gestionnaire qui obéit au clic.
Pour paramétrer openbox il faut y passer un peu de temps au début,
surtout pour comprendre la structure de la configuration.
Ensuite pour paramétrer le tout il vaut mieux un éditeur de texte qu'un
clickodrome.
Une fois tes raccourcis clavier définis, tes menus paramétrés et tes
thèmes mis en place il n'y a plus guère de raison d'intervenir sur la
configuration mis à part pour ajouter une application au menu (ce qui
se fait en 30 secondes avec un éditeur de texte).
Pour tout ça le wiki d'openbox est vraiment très bien fait et la section
openbox de celui d'Archlinux est un parfait complément.
Have fun.
--
Doug - Linux user #307925 - Slackware64 roulaize ;-)
Without freedom of choice there is no creativity.
-- Kirk, "The return of the Archons", stardate 3157.4
Le 15-06-2013, jp willm nous expliquait dans fr.comp.os.linux.debats :
C'est ce que disent tous ceux qui n'ont jamais utilisé openbox.
Mais j'ai essayé :o)
Je ne suis peut-être pas encore assez compétent pour pouvoir l'apprécier ?
Blague à part, je trouve openbox un peu aride quand on veut paramétrer vite fait son environnement à l'aide d'un gestionnaire qui obéit au clic.
Pour paramétrer openbox il faut y passer un peu de temps au début, surtout pour comprendre la structure de la configuration.
Ensuite pour paramétrer le tout il vaut mieux un éditeur de texte qu'un clickodrome.
Une fois tes raccourcis clavier définis, tes menus paramétrés et tes thèmes mis en place il n'y a plus guère de raison d'intervenir sur la configuration mis à part pour ajouter une application au menu (ce qui se fait en 30 secondes avec un éditeur de texte).
Pour tout ça le wiki d'openbox est vraiment très bien fait et la section openbox de celui d'Archlinux est un parfait complément.
Have fun. -- Doug - Linux user #307925 - Slackware64 roulaize ;-) Without freedom of choice there is no creativity. -- Kirk, "The return of the Archons", stardate 3157.4
william
On 2013-06-15, Doug713705 wrote:
Pour paramétrer openbox il faut y passer un peu de temps au début, surtout pour comprendre la structure de la configuration.
Ensuite pour paramétrer le tout il vaut mieux un éditeur de texte qu'un clickodrome.
Une fois tes raccourcis clavier définis, tes menus paramétrés et tes thèmes mis en place il n'y a plus guère de raison d'intervenir sur la configuration mis à part pour ajouter une application au menu (ce qui se fait en 30 secondes avec un éditeur de texte).
ok mais n'est pas le cas de n'importe quel environement ?
On 2013-06-15, Doug713705 <doug.letough@free.fr> wrote:
Pour paramétrer openbox il faut y passer un peu de temps au début,
surtout pour comprendre la structure de la configuration.
Ensuite pour paramétrer le tout il vaut mieux un éditeur de texte qu'un
clickodrome.
Une fois tes raccourcis clavier définis, tes menus paramétrés et tes
thèmes mis en place il n'y a plus guère de raison d'intervenir sur la
configuration mis à part pour ajouter une application au menu (ce qui
se fait en 30 secondes avec un éditeur de texte).
ok mais n'est pas le cas de n'importe quel environement ?
Pour paramétrer openbox il faut y passer un peu de temps au début, surtout pour comprendre la structure de la configuration.
Ensuite pour paramétrer le tout il vaut mieux un éditeur de texte qu'un clickodrome.
Une fois tes raccourcis clavier définis, tes menus paramétrés et tes thèmes mis en place il n'y a plus guère de raison d'intervenir sur la configuration mis à part pour ajouter une application au menu (ce qui se fait en 30 secondes avec un éditeur de texte).
ok mais n'est pas le cas de n'importe quel environement ?
