J'ai découvert les applications "snapshots" et "periodic-snapshots" sous
freeBSD, et j'ai décidé de m'en inspirer pour créer des équivalents
linux (en utilisant LVM, bien que ce soit beaucoup moins commode).
Par contre, les deux applications BSD d'origine sont écrites en
bourne shell. Ça ne me paraît pas optimal... Je pense les récrire en
perl. Par ailleurs, pour des raisons à la fois de commodité personnelle
et de conformité avec les habitudes "GNU", je pense conserver à peu
près la même syntaxe, mais en appliquant les normes "GNU" du genre
mettre "--" devant les paramètres, par exemple "snapshot --list" plutôt
que "snapshot list".
Qu'est ce que vous en dites? Je suis preneur de toute suggestion (de toute
façon pour les applis je les ai déjà commencées :)
Our enemies are innovative and resourceful, and so are we. They never stop thinking about new ways to harm our country and our people, and neither do we.
manu@netbsd.org (Emmanuel Dreyfus) writes:
Emmanuel Florac <eflorac@imaginet.fr> wrote:
Par contre, les deux applications BSD d'origine sont écrites en
bourne shell. Ça ne me paraît pas optimal... Je pense les récrire en
perl.
Pourquoi pas en C?
Et pourquoi pas en assembleur? Ou même se farcir le binaire à la
mimine, après tout, l'assembleur ne génère pas toujours les bits que
l'on voudrait.
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we.
Our enemies are innovative and resourceful, and so are we. They never stop thinking about new ways to harm our country and our people, and neither do we.
DINH Viêt Hoà
(Emmanuel Dreyfus) writes:
Emmanuel Florac wrote:
Par contre, les deux applications BSD d'origine sont écrites en bourne shell. Ça ne me paraît pas optimal... Je pense les récrire en perl.
Pourquoi pas en C?
Et pourquoi pas en assembleur? Ou même se farcir le binaire à la mimine, après tout, l'assembleur ne génère pas toujours les bits que l'on voudrait.
Ceci dit, il y a besoin de perf pour cette application ? il ne suffit pas d'avoir des perfs au niveau du support noyau ?
-- DINH V. Hoa,
"Ma tuxitude me beastifie" -- sunZ
manu@netbsd.org (Emmanuel Dreyfus) writes:
Emmanuel Florac <eflorac@imaginet.fr> wrote:
Par contre, les deux applications BSD d'origine sont écrites en
bourne shell. Ça ne me paraît pas optimal... Je pense les récrire en
perl.
Pourquoi pas en C?
Et pourquoi pas en assembleur? Ou même se farcir le binaire à la
mimine, après tout, l'assembleur ne génère pas toujours les bits que
l'on voudrait.
Ceci dit, il y a besoin de perf pour cette application ?
il ne suffit pas d'avoir des perfs au niveau du support noyau ?
Pourquoi pas en C? Et pourquoi pas en assembleur? Ou même se farcir le binaire à la
mimine, après tout, l'assembleur ne génère pas toujours les bits que l'on voudrait.
Parcequ'un humain code souvent moins optimisé en assembleur qu'un compilateur C.
-- Emmanuel Dreyfus Publicité subliminale: achetez ce livre! http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
Emmanuel Florac
Le Fri, 10 Sep 2004 10:02:29 +0200, Eric Masson a écrit :
Le temps effectif de pose d'un snapshot est assez faible, c'est la phase de préparation qui est la plus longue :
OUi, oui, en fait si j'ai bien compris, on crée le fichier snapshot dans ls FS "imagé", et ce fichier grossit bien sûr en fonction de l'espace utilisé. DOnc le snapshot prend de l'espace au FS "imagé" alors que dans le cas de LVM c'est un espace distinct, ce qui est au demeurant moins pratique.
-- L'esprit qu'on veut avoir gâte celui qu'on a. Jean-Baptiste Louis Grisset.
Le Fri, 10 Sep 2004 10:02:29 +0200, Eric Masson a écrit :
Le temps effectif de pose d'un snapshot est assez faible, c'est la phase
de préparation qui est la plus longue :
OUi, oui, en fait si j'ai bien compris, on crée le fichier snapshot dans
ls FS "imagé", et ce fichier grossit bien sûr en fonction de l'espace
utilisé. DOnc le snapshot prend de l'espace au FS "imagé" alors que dans
le cas de LVM c'est un espace distinct, ce qui est au demeurant moins
pratique.
--
L'esprit qu'on veut avoir gâte celui qu'on a.
Jean-Baptiste Louis Grisset.
Le Fri, 10 Sep 2004 10:02:29 +0200, Eric Masson a écrit :
Le temps effectif de pose d'un snapshot est assez faible, c'est la phase de préparation qui est la plus longue :
OUi, oui, en fait si j'ai bien compris, on crée le fichier snapshot dans ls FS "imagé", et ce fichier grossit bien sûr en fonction de l'espace utilisé. DOnc le snapshot prend de l'espace au FS "imagé" alors que dans le cas de LVM c'est un espace distinct, ce qui est au demeurant moins pratique.
-- L'esprit qu'on veut avoir gâte celui qu'on a. Jean-Baptiste Louis Grisset.
Emmanuel Florac
Le Fri, 10 Sep 2004 22:49:41 +0200, Emmanuel Dreyfus a écrit :
Par contre, les deux applications BSD d'origine sont écrites en bourne shell. Ça ne me paraît pas optimal... Je pense les récrire en perl.
Pourquoi pas en C?
Parce que je pense que ce serait idiot :) Ce serait beaucoup plus long et compliqué, alors qu'il s'agit de lancer quelques commandes et de faire quelques tests du genre "présence de fichier/point de montage" etc. Typiquement le genre de truc qu'il ne faut _surtout_pas_ faire en C.
Par ailleurs, pour des raisons à la fois de commodité personnelle et de conformité avec les habitudes "GNU", je pense conserver à peu près la même syntaxe, mais en appliquant les normes "GNU" du genre mettre "--" devant les paramètres, par exemple "snapshot --list" plutôt que "snapshot list".
A part introduire une syntaxe incompatible avec la version BSD et avoir à taper deux caractères de plus, y'a un interet à cette modification?
Fondamentalement pas vraiment, sinon comme je le disais à se conformer aux normes "GNU". Le gros avantage c'est la clarté de la syntaxe : les paramètres sont précédés de -- (ou - pour les carctères simples), les valeurs n'ont rien. La distinction est beaucoup plus claire, donc je trouve que c'est mieux. On peut aussi préférer la norme X (paramètres avec un seul -).
De toute façon la syntaxe ne pourra pas être exactement identique à la version BSD, parce que le mécanisme sous-jacent est assez différent. Simplement aussi proche que possible, parce que 1) ça m'évite à moi de réinventer la roue (n'oublions pas que la paresse est la qualité première du programmeur, c'est d'ailleurs pour ça que je ne le ferai pas en C!) et 2) ça sera quand même plus commode pour ceux qui connaissent l'outil FreeBSD qui n'auront pas besoin d'effort pour comprendre la logique de fonctionnement de l'outil.
-- L'esprit qu'on veut avoir gâte celui qu'on a. Jean-Baptiste Louis Grisset.
Le Fri, 10 Sep 2004 22:49:41 +0200, Emmanuel Dreyfus a écrit :
Par contre, les deux applications BSD d'origine sont écrites en
bourne shell. Ça ne me paraît pas optimal... Je pense les récrire en
perl.
Pourquoi pas en C?
Parce que je pense que ce serait idiot :) Ce serait beaucoup plus long et
compliqué, alors qu'il s'agit de lancer quelques commandes et de faire
quelques tests du genre "présence de fichier/point de montage" etc.
Typiquement le genre de truc qu'il ne faut _surtout_pas_ faire en C.
Par ailleurs, pour des raisons à la fois de commodité personnelle
et de conformité avec les habitudes "GNU", je pense conserver à peu
près la même syntaxe, mais en appliquant les normes "GNU" du genre
mettre "--" devant les paramètres, par exemple "snapshot --list" plutôt
que "snapshot list".
A part introduire une syntaxe incompatible avec la version BSD et avoir
à taper deux caractères de plus, y'a un interet à cette modification?
Fondamentalement pas vraiment, sinon comme je le disais à se conformer
aux normes "GNU". Le gros avantage c'est la clarté de la syntaxe : les
paramètres sont précédés de -- (ou - pour les carctères simples), les
valeurs n'ont rien. La distinction est beaucoup plus claire, donc je
trouve que c'est mieux. On peut aussi préférer la norme X (paramètres
avec un seul -).
De toute façon la syntaxe ne pourra pas être exactement identique à la
version BSD, parce que le mécanisme sous-jacent est assez différent.
Simplement aussi proche que possible, parce que 1) ça m'évite à moi de
réinventer la roue (n'oublions pas que la paresse est la qualité
première du programmeur, c'est d'ailleurs pour ça que je ne le ferai
pas en C!) et 2) ça sera quand même plus commode pour ceux qui
connaissent l'outil FreeBSD qui n'auront pas besoin d'effort pour
comprendre la logique de fonctionnement de l'outil.
--
L'esprit qu'on veut avoir gâte celui qu'on a.
Jean-Baptiste Louis Grisset.
Le Fri, 10 Sep 2004 22:49:41 +0200, Emmanuel Dreyfus a écrit :
Par contre, les deux applications BSD d'origine sont écrites en bourne shell. Ça ne me paraît pas optimal... Je pense les récrire en perl.
Pourquoi pas en C?
Parce que je pense que ce serait idiot :) Ce serait beaucoup plus long et compliqué, alors qu'il s'agit de lancer quelques commandes et de faire quelques tests du genre "présence de fichier/point de montage" etc. Typiquement le genre de truc qu'il ne faut _surtout_pas_ faire en C.
Par ailleurs, pour des raisons à la fois de commodité personnelle et de conformité avec les habitudes "GNU", je pense conserver à peu près la même syntaxe, mais en appliquant les normes "GNU" du genre mettre "--" devant les paramètres, par exemple "snapshot --list" plutôt que "snapshot list".
A part introduire une syntaxe incompatible avec la version BSD et avoir à taper deux caractères de plus, y'a un interet à cette modification?
Fondamentalement pas vraiment, sinon comme je le disais à se conformer aux normes "GNU". Le gros avantage c'est la clarté de la syntaxe : les paramètres sont précédés de -- (ou - pour les carctères simples), les valeurs n'ont rien. La distinction est beaucoup plus claire, donc je trouve que c'est mieux. On peut aussi préférer la norme X (paramètres avec un seul -).
De toute façon la syntaxe ne pourra pas être exactement identique à la version BSD, parce que le mécanisme sous-jacent est assez différent. Simplement aussi proche que possible, parce que 1) ça m'évite à moi de réinventer la roue (n'oublions pas que la paresse est la qualité première du programmeur, c'est d'ailleurs pour ça que je ne le ferai pas en C!) et 2) ça sera quand même plus commode pour ceux qui connaissent l'outil FreeBSD qui n'auront pas besoin d'effort pour comprendre la logique de fonctionnement de l'outil.
-- L'esprit qu'on veut avoir gâte celui qu'on a. Jean-Baptiste Louis Grisset.
Emmanuel Florac
Le Sat, 11 Sep 2004 03:34:00 +0200, DINH Viêt Hoà a écrit :
Ceci dit, il y a besoin de perf pour cette application ?
Aucune. Il s'agit de parser la ligne de commande, vérifier la présence de certains fichiers/répertoires, créer certains fichiers/répertoires, et lancer quelques commandes qui existent déjà avec divers paramètres en faisant un minimum de traitement de chaîne. On peut le faire en shell très simplement, je préférerais le faire en perl par facilité... En fait le débat c'est "shell ou perl"?
il ne suffit pas d'avoir des perfs au niveau du support noyau ?
Si, mais tout ce qu'il faut existe déjà je n'ai rien à toucher à ce niveau.
-- Il y a toujours un bug de plus. Loi de Lubarsky.
Le Sat, 11 Sep 2004 03:34:00 +0200, DINH Viêt Hoà a écrit :
Ceci dit, il y a besoin de perf pour cette application ?
Aucune. Il s'agit de parser la ligne de commande, vérifier la présence
de certains fichiers/répertoires, créer certains fichiers/répertoires,
et lancer quelques commandes qui existent déjà avec divers paramètres
en faisant un minimum de traitement de chaîne. On peut le faire en shell
très simplement, je préférerais le faire en perl par facilité... En
fait le débat c'est "shell ou perl"?
il ne suffit pas d'avoir des perfs au niveau du support noyau ?
Si, mais tout ce qu'il faut existe déjà je n'ai rien à toucher à ce
niveau.
--
Il y a toujours un bug de plus.
Loi de Lubarsky.
Le Sat, 11 Sep 2004 03:34:00 +0200, DINH Viêt Hoà a écrit :
Ceci dit, il y a besoin de perf pour cette application ?
Aucune. Il s'agit de parser la ligne de commande, vérifier la présence de certains fichiers/répertoires, créer certains fichiers/répertoires, et lancer quelques commandes qui existent déjà avec divers paramètres en faisant un minimum de traitement de chaîne. On peut le faire en shell très simplement, je préférerais le faire en perl par facilité... En fait le débat c'est "shell ou perl"?
il ne suffit pas d'avoir des perfs au niveau du support noyau ?
Si, mais tout ce qu'il faut existe déjà je n'ai rien à toucher à ce niveau.
-- Il y a toujours un bug de plus. Loi de Lubarsky.
DINH Viêt Hoà
Ceci dit, il y a besoin de perf pour cette application ?
Aucune. Il s'agit de parser la ligne de commande, vérifier la présence de certains fichiers/répertoires, créer certains fichiers/répertoires, et lancer quelques commandes qui existent déjà avec divers paramètres en faisant un minimum de traitement de chaîne. On peut le faire en shell très simplement, je préférerais le faire en perl par facilité... En fait le débat c'est "shell ou perl"?
le débat n'est-il pas "reprendre un existant ou tout refaire de zéro ?" ?
Mais, effectivement, dans le monde de l'Open Source, les gens aiment bien faire les choses de zéro avec plus de bugs. (C'est juste une constatation, étant moi-même adepte de la pratique).
-- DINH V. Hoa,
"la chatte de ma petite soeur s'appelle Zoé" -- the captain de soirées
Ceci dit, il y a besoin de perf pour cette application ?
Aucune. Il s'agit de parser la ligne de commande, vérifier la présence
de certains fichiers/répertoires, créer certains fichiers/répertoires,
et lancer quelques commandes qui existent déjà avec divers paramètres
en faisant un minimum de traitement de chaîne. On peut le faire en shell
très simplement, je préférerais le faire en perl par facilité... En
fait le débat c'est "shell ou perl"?
le débat n'est-il pas "reprendre un existant ou tout refaire
de zéro ?" ?
Mais, effectivement, dans le monde de l'Open Source, les gens aiment
bien faire les choses de zéro avec plus de bugs. (C'est juste une
constatation, étant moi-même adepte de la pratique).
--
DINH V. Hoa,
"la chatte de ma petite soeur s'appelle Zoé" -- the captain de soirées
Ceci dit, il y a besoin de perf pour cette application ?
Aucune. Il s'agit de parser la ligne de commande, vérifier la présence de certains fichiers/répertoires, créer certains fichiers/répertoires, et lancer quelques commandes qui existent déjà avec divers paramètres en faisant un minimum de traitement de chaîne. On peut le faire en shell très simplement, je préférerais le faire en perl par facilité... En fait le débat c'est "shell ou perl"?
le débat n'est-il pas "reprendre un existant ou tout refaire de zéro ?" ?
Mais, effectivement, dans le monde de l'Open Source, les gens aiment bien faire les choses de zéro avec plus de bugs. (C'est juste une constatation, étant moi-même adepte de la pratique).
-- DINH V. Hoa,
"la chatte de ma petite soeur s'appelle Zoé" -- the captain de soirées
Emmanuel Florac
Le Sun, 12 Sep 2004 19:07:07 +0200, DINH Viêt Hoà a écrit :
le débat n'est-il pas "reprendre un existant ou tout refaire de zéro ?" ?
Mais non, l'existant est pour FreeBSD, il utilise des mécanismes distincts, on ne peut pas l'adapter simplement sous Linux! J'ai regardé si je pouvais l'adapter, pour commencer, si je faisais l'outil linux en shell je pourrais sûrement emprunter deux trois choses dans l'original, mais c'est tout...
-- entia non sont multiplicanda praeter necessitatem. Guillaume d'Ockham.
Le Sun, 12 Sep 2004 19:07:07 +0200, DINH Viêt Hoà a écrit :
le débat n'est-il pas "reprendre un existant ou tout refaire
de zéro ?" ?
Mais non, l'existant est pour FreeBSD, il utilise des mécanismes
distincts, on ne peut pas l'adapter simplement sous Linux! J'ai regardé
si je pouvais l'adapter, pour commencer, si je faisais l'outil linux en
shell je pourrais sûrement emprunter deux trois choses dans l'original,
mais c'est tout...
--
entia non sont multiplicanda praeter necessitatem.
Guillaume d'Ockham.
Le Sun, 12 Sep 2004 19:07:07 +0200, DINH Viêt Hoà a écrit :
le débat n'est-il pas "reprendre un existant ou tout refaire de zéro ?" ?
Mais non, l'existant est pour FreeBSD, il utilise des mécanismes distincts, on ne peut pas l'adapter simplement sous Linux! J'ai regardé si je pouvais l'adapter, pour commencer, si je faisais l'outil linux en shell je pourrais sûrement emprunter deux trois choses dans l'original, mais c'est tout...
-- entia non sont multiplicanda praeter necessitatem. Guillaume d'Ockham.
Serge Gagnon
On Sun, 12 Sep 2004, "E.F." == Emmanuel Florac wrote:
+> Pourquoi pas en C?
E.F.> Parce que je pense que ce serait idiot :) Ce serait beaucoup plus E.F.> long et compliqué, alors qu'il s'agit de lancer quelques commandes E.F.> et de faire quelques tests du genre "présence de fichier/point E.F.> de montage" etc. Typiquement le genre de truc qu'il ne faut E.F.> _surtout_pas_ faire en C.
http://ied.eng.unipr.it/silve/node88.html
-- Serge Gagnon Quebec, Qc, Canada
On Sun, 12 Sep 2004, "E.F." == Emmanuel Florac wrote:
+> Pourquoi pas en C?
E.F.> Parce que je pense que ce serait idiot :) Ce serait beaucoup plus
E.F.> long et compliqué, alors qu'il s'agit de lancer quelques commandes
E.F.> et de faire quelques tests du genre "présence de fichier/point
E.F.> de montage" etc. Typiquement le genre de truc qu'il ne faut
E.F.> _surtout_pas_ faire en C.
On Sun, 12 Sep 2004, "E.F." == Emmanuel Florac wrote:
+> Pourquoi pas en C?
E.F.> Parce que je pense que ce serait idiot :) Ce serait beaucoup plus E.F.> long et compliqué, alors qu'il s'agit de lancer quelques commandes E.F.> et de faire quelques tests du genre "présence de fichier/point E.F.> de montage" etc. Typiquement le genre de truc qu'il ne faut E.F.> _surtout_pas_ faire en C.
http://ied.eng.unipr.it/silve/node88.html
-- Serge Gagnon Quebec, Qc, Canada
Emmanuel Florac
Le Sun, 12 Sep 2004 23:30:31 +0000, Serge Gagnon a écrit :
http://ied.eng.unipr.it/silve/node88.html
C'était il y a 25 ans, quand le choix c'était Fortran, C, ou assembleur. De nos jours, Eric S. Raymond dit lui-même qu'il n'y a presque jamais de bonne raison d'écrire une appli en C:
It may therefore seem perverse to assert that C and C++ are nowadays almost always the wrong vehicle for beginning new applications development. But it's true.
Et je suis profondément d'accord avec ça. Je ne fais pour ainsi dire jamais rien en C vu que je ne fais pas de programmation système ni rien qui soit demandeur en performance (calculs lourds, interfaces graphiques complexes...). Et je préfère utiliser la puissance d'un langage moderne comme Perl (ou python, ruby, java, mettez ici votre langage préféré...) plutôt que bourne-shell. Shell c'est uniquement une question de "compatibilité maximale". Comme apparemment le débat "perl ou shell" ne semble frapper personne, je vais donc me conformer à l'habitude Debian et écrire la commande en perl, ce qui est mon option préférée de toute façon :)
-- entia non sont multiplicanda praeter necessitatem. Guillaume d'Ockham.
Le Sun, 12 Sep 2004 23:30:31 +0000, Serge Gagnon a écrit :
http://ied.eng.unipr.it/silve/node88.html
C'était il y a 25 ans, quand le choix c'était Fortran, C, ou assembleur.
De nos jours, Eric S. Raymond dit lui-même qu'il n'y a presque jamais de
bonne raison d'écrire une appli en C:
It may therefore seem perverse to assert that C and C++ are nowadays
almost always the wrong vehicle for beginning new applications
development. But it's true.
Et je suis profondément d'accord avec ça. Je ne fais pour ainsi dire
jamais rien en C vu que je ne fais pas de programmation système ni rien
qui soit demandeur en performance (calculs lourds, interfaces graphiques
complexes...). Et je préfère utiliser la puissance d'un langage moderne
comme Perl (ou python, ruby, java, mettez ici votre langage préféré...)
plutôt que bourne-shell. Shell c'est uniquement une question de
"compatibilité maximale".
Comme apparemment le débat "perl ou shell" ne semble frapper personne, je
vais donc me conformer à l'habitude Debian et écrire la commande en
perl, ce qui est mon option préférée de toute façon :)
--
entia non sont multiplicanda praeter necessitatem.
Guillaume d'Ockham.
Le Sun, 12 Sep 2004 23:30:31 +0000, Serge Gagnon a écrit :
http://ied.eng.unipr.it/silve/node88.html
C'était il y a 25 ans, quand le choix c'était Fortran, C, ou assembleur. De nos jours, Eric S. Raymond dit lui-même qu'il n'y a presque jamais de bonne raison d'écrire une appli en C:
It may therefore seem perverse to assert that C and C++ are nowadays almost always the wrong vehicle for beginning new applications development. But it's true.
Et je suis profondément d'accord avec ça. Je ne fais pour ainsi dire jamais rien en C vu que je ne fais pas de programmation système ni rien qui soit demandeur en performance (calculs lourds, interfaces graphiques complexes...). Et je préfère utiliser la puissance d'un langage moderne comme Perl (ou python, ruby, java, mettez ici votre langage préféré...) plutôt que bourne-shell. Shell c'est uniquement une question de "compatibilité maximale". Comme apparemment le débat "perl ou shell" ne semble frapper personne, je vais donc me conformer à l'habitude Debian et écrire la commande en perl, ce qui est mon option préférée de toute façon :)
-- entia non sont multiplicanda praeter necessitatem. Guillaume d'Ockham.
