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 :)
On est parti pour un passionnant débat C vs langages interpretés. C'est clair que c'est la grande mode de nos jours de re-ecrire tout l'espace utilisateur en perl ou en shell-script, en disant "mon programme n'est pas critique pour les performances".
T'inquiètes : les modes passent et le C demeure, pour des raisons que nous ne sommes pas sans savoir...
(Ca si c'est pas de la bonne nourriture multivitaminé pour gros troll poilu, je vois pas ce que c'est ;))
Emmanuel Dreyfus wrote:
On est parti pour un passionnant débat C vs langages interpretés. C'est
clair que c'est la grande mode de nos jours de re-ecrire tout l'espace
utilisateur en perl ou en shell-script, en disant "mon programme n'est
pas critique pour les performances".
T'inquiètes : les modes passent et le C demeure, pour des raisons que
nous ne sommes pas sans savoir...
(Ca si c'est pas de la bonne nourriture multivitaminé pour gros troll
poilu, je vois pas ce que c'est ;))
On est parti pour un passionnant débat C vs langages interpretés. C'est clair que c'est la grande mode de nos jours de re-ecrire tout l'espace utilisateur en perl ou en shell-script, en disant "mon programme n'est pas critique pour les performances".
T'inquiètes : les modes passent et le C demeure, pour des raisons que nous ne sommes pas sans savoir...
(Ca si c'est pas de la bonne nourriture multivitaminé pour gros troll poilu, je vois pas ce que c'est ;))
Emmanuel Florac
Le Tue, 14 Sep 2004 12:47:43 +0000, Pascal Bourguignon a écrit :
Si le programme est fini deux fois plus vite avec un autre langage que C, alors on a intérêt à utiliser cet autre langage: on aura le temps d'optimiser là où c'est lent (éventuellement en réécrivant le module critique en C), ou d'innonder le marché avec son logiciel lent mais non vaporware et avoir alors assez d'argent pour acheter une machine plus puissante et plus de RAM.
Pour ce qui est de l'argent, je précise que je ne compte pas le vendre mais plutôt le donner en GPL :)
-- Il y a toujours un bug de plus. Loi de Lubarsky.
Le Tue, 14 Sep 2004 12:47:43 +0000, Pascal Bourguignon a écrit :
Si le programme est fini deux fois plus vite avec un autre langage que
C, alors on a intérêt à utiliser cet autre langage: on aura le temps
d'optimiser là où c'est lent (éventuellement en réécrivant le module
critique en C), ou d'innonder le marché avec son logiciel lent mais
non vaporware et avoir alors assez d'argent pour acheter une machine
plus puissante et plus de RAM.
Pour ce qui est de l'argent, je précise que je ne compte pas le vendre
mais plutôt le donner en GPL :)
--
Il y a toujours un bug de plus.
Loi de Lubarsky.
Le Tue, 14 Sep 2004 12:47:43 +0000, Pascal Bourguignon a écrit :
Si le programme est fini deux fois plus vite avec un autre langage que C, alors on a intérêt à utiliser cet autre langage: on aura le temps d'optimiser là où c'est lent (éventuellement en réécrivant le module critique en C), ou d'innonder le marché avec son logiciel lent mais non vaporware et avoir alors assez d'argent pour acheter une machine plus puissante et plus de RAM.
Pour ce qui est de l'argent, je précise que je ne compte pas le vendre mais plutôt le donner en GPL :)
-- Il y a toujours un bug de plus. Loi de Lubarsky.
Emmanuel Florac
Le Tue, 14 Sep 2004 21:04:14 +0200, Emmanuel Dreyfus a écrit :
Tu sais qu'il paraît que le word6 était écrit en basic, et pourtant il ne ramait pas monstrueusement.
Ah?
En fait c'est probablement faux. Il faut lire les explications de Joel Spolski su le dévelopement de MS Office à la grande époque, c'est très intéressant. En tout cas Word 6 n'est pas écrit en basic mais sous forme de composants C++, peut-être liés avec des bouts de VB mais je ne crois pas...
-- Ne pas savoir de quoi on parle est un avantage dont il ne faut pas abuser. R.Debray
Le Tue, 14 Sep 2004 21:04:14 +0200, Emmanuel Dreyfus a écrit :
Tu sais qu'il paraît que le word6 était écrit en basic, et pourtant
il ne ramait pas monstrueusement.
Ah?
En fait c'est probablement faux. Il faut lire les explications de Joel
Spolski su le dévelopement de MS Office à la grande époque, c'est très
intéressant. En tout cas Word 6 n'est pas écrit en basic mais sous forme
de composants C++, peut-être liés avec des bouts de VB mais je ne crois
pas...
--
Ne pas savoir de quoi on parle est un avantage dont il ne faut pas
abuser.
R.Debray
Le Tue, 14 Sep 2004 21:04:14 +0200, Emmanuel Dreyfus a écrit :
Tu sais qu'il paraît que le word6 était écrit en basic, et pourtant il ne ramait pas monstrueusement.
Ah?
En fait c'est probablement faux. Il faut lire les explications de Joel Spolski su le dévelopement de MS Office à la grande époque, c'est très intéressant. En tout cas Word 6 n'est pas écrit en basic mais sous forme de composants C++, peut-être liés avec des bouts de VB mais je ne crois pas...
-- Ne pas savoir de quoi on parle est un avantage dont il ne faut pas abuser. R.Debray
Pascal PETIT
(Michel Talon) writes:
-il y a aussi un port /usr/ports/sysutils/rsnapshot dont la documentation dit: rsnapshot is a filesystem snapshot utility based on rsync(1). rsnapshot makes it easy to make periodic snapshots of local machines, and remote machines over ssh. The code makes extensive use of hard links whenever possible, to greatly reduce the disk space required.
It is written entirely in perl with no module dependencies, and has been tested with versions 5.004 through 5.8.1.
WWW: http://www.rsnapshot.org
Dans le même genre d'idées, on a : <URL:http://www.mikrubel.org/computers/rsync_snapshots/>
Le principe est simple:
- on comment par créer une sauvegarde à l'aide de rsync (sauvegarde 0)
ensuite on applique le processus suivant :
- s'il existe, on renomme sauvegarde1 en sauvegarde2 - on copie à grand coup de lien hard sauvegarde0 en sauvegarde1 avec la commande "cp -l" - on met à jour sauvegarde0 à l'aide de rsync.
L'avantage, c'est que comme rsync ne modifie pas les fichiers non modifiés, par la magie des liens hard, c'est le même fichier physique qui est utilisé dans sauvegarde0 et dans sauvegarde1.
Si le fichier a changé, on a bien les deux versions sur disque.
C'est tellement pratique que les versions récentes de rsync ont un support pour çà qui évite le "cp -l" (ce qui n'est pas plus mal car "cp -l" a quelques limitations quand on a des liens symboliques qui pointent vers des fichiers inexistant localement).
Le principe est simplissime mais ça permet de conserver un nombre important de versions d'une arborescence à moindre coût.
-- Pascal PETIT
=====> répondre de façon lisible pour continuer à être lu <==== http://www.giromini.org/usenet-fr/repondre.html
talon@lpthe.jussieu.fr (Michel Talon) writes:
-il y a aussi un port
/usr/ports/sysutils/rsnapshot
dont la documentation dit:
rsnapshot is a filesystem snapshot utility based on rsync(1).
rsnapshot makes it easy to make periodic snapshots of local machines,
and remote machines over ssh. The code makes extensive use of hard links
whenever possible, to greatly reduce the disk space required.
It is written entirely in perl with no module dependencies, and has been
tested with versions 5.004 through 5.8.1.
WWW: http://www.rsnapshot.org
Dans le même genre d'idées, on a :
<URL:http://www.mikrubel.org/computers/rsync_snapshots/>
Le principe est simple:
- on comment par créer une sauvegarde à l'aide de rsync (sauvegarde
0)
ensuite on applique le processus suivant :
- s'il existe, on renomme sauvegarde1 en sauvegarde2
- on copie à grand coup de lien hard sauvegarde0 en sauvegarde1 avec
la commande "cp -l"
- on met à jour sauvegarde0 à l'aide de rsync.
L'avantage, c'est que comme rsync ne modifie pas les fichiers non
modifiés, par la magie des liens hard, c'est le même fichier physique
qui est utilisé dans sauvegarde0 et dans sauvegarde1.
Si le fichier a changé, on a bien les deux versions sur disque.
C'est tellement pratique que les versions récentes de rsync ont un
support pour çà qui évite le "cp -l" (ce qui n'est pas plus mal car
"cp -l" a quelques limitations quand on a des liens symboliques qui
pointent vers des fichiers inexistant localement).
Le principe est simplissime mais ça permet de conserver un nombre
important de versions d'une arborescence à moindre coût.
--
Pascal PETIT ppetit-news-corp@shayol.org
=====> répondre de façon lisible pour continuer à être lu <==== http://www.giromini.org/usenet-fr/repondre.html
-il y a aussi un port /usr/ports/sysutils/rsnapshot dont la documentation dit: rsnapshot is a filesystem snapshot utility based on rsync(1). rsnapshot makes it easy to make periodic snapshots of local machines, and remote machines over ssh. The code makes extensive use of hard links whenever possible, to greatly reduce the disk space required.
It is written entirely in perl with no module dependencies, and has been tested with versions 5.004 through 5.8.1.
WWW: http://www.rsnapshot.org
Dans le même genre d'idées, on a : <URL:http://www.mikrubel.org/computers/rsync_snapshots/>
Le principe est simple:
- on comment par créer une sauvegarde à l'aide de rsync (sauvegarde 0)
ensuite on applique le processus suivant :
- s'il existe, on renomme sauvegarde1 en sauvegarde2 - on copie à grand coup de lien hard sauvegarde0 en sauvegarde1 avec la commande "cp -l" - on met à jour sauvegarde0 à l'aide de rsync.
L'avantage, c'est que comme rsync ne modifie pas les fichiers non modifiés, par la magie des liens hard, c'est le même fichier physique qui est utilisé dans sauvegarde0 et dans sauvegarde1.
Si le fichier a changé, on a bien les deux versions sur disque.
C'est tellement pratique que les versions récentes de rsync ont un support pour çà qui évite le "cp -l" (ce qui n'est pas plus mal car "cp -l" a quelques limitations quand on a des liens symboliques qui pointent vers des fichiers inexistant localement).
Le principe est simplissime mais ça permet de conserver un nombre important de versions d'une arborescence à moindre coût.
-- Pascal PETIT
=====> répondre de façon lisible pour continuer à être lu <==== http://www.giromini.org/usenet-fr/repondre.html
Marc Boyer
Thierry wrote:
Emmanuel Florac wrote:
moyen et un programmeur occasionnel, et j'en suis incapable. Entre passer 3 jours à écrire le truc en perl et passer 1 mois à le faire en C, j'ai déjà choisi. Je pense qu'il vaut mieux de toute façon l'avoir en Perl que de ne pas l'avoir...
C'est marrant mais c'est à peu près l'argument du "Windowsien" :
"Meme si Linux est mieux que Windows, je préfère installer Windows et l'avoir en main rapidement que d'avoir à lire des millions de pages man pour Linux."
Et alors, c'est un très bon argument.
De toute façon, la notion de "mieux" dans le monde réel est multi-critères, et il est rarissime qu'un système A soit supérieur au système B sur tous les critères.
La vitesse de prise en main est *un* critère, pas le seul mais il existe.
Car si on veut jouer à ça, je surenchéri "VMS, c'est mieux que Linux".
Marc Boyer -- La contractualisation de la recherche, c'est me donner de l'argent pour faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce que je sais faire, je le fais sans moyens...
Thierry wrote:
Emmanuel Florac wrote:
moyen et un programmeur occasionnel, et j'en suis incapable. Entre passer
3 jours à écrire le truc en perl et passer 1 mois à le faire en C, j'ai
déjà choisi. Je pense qu'il vaut mieux de toute façon l'avoir en Perl
que de ne pas l'avoir...
C'est marrant mais c'est à peu près l'argument du "Windowsien" :
"Meme si Linux est mieux que Windows, je préfère installer Windows et
l'avoir en main rapidement que d'avoir à lire des millions de pages man
pour Linux."
Et alors, c'est un très bon argument.
De toute façon, la notion de "mieux" dans le monde réel est
multi-critères, et il est rarissime qu'un système A soit
supérieur au système B sur tous les critères.
La vitesse de prise en main est *un* critère, pas le
seul mais il existe.
Car si on veut jouer à ça, je surenchéri "VMS, c'est
mieux que Linux".
Marc Boyer
--
La contractualisation de la recherche, c'est me donner de l'argent pour
faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce
que je sais faire, je le fais sans moyens...
moyen et un programmeur occasionnel, et j'en suis incapable. Entre passer 3 jours à écrire le truc en perl et passer 1 mois à le faire en C, j'ai déjà choisi. Je pense qu'il vaut mieux de toute façon l'avoir en Perl que de ne pas l'avoir...
C'est marrant mais c'est à peu près l'argument du "Windowsien" :
"Meme si Linux est mieux que Windows, je préfère installer Windows et l'avoir en main rapidement que d'avoir à lire des millions de pages man pour Linux."
Et alors, c'est un très bon argument.
De toute façon, la notion de "mieux" dans le monde réel est multi-critères, et il est rarissime qu'un système A soit supérieur au système B sur tous les critères.
La vitesse de prise en main est *un* critère, pas le seul mais il existe.
Car si on veut jouer à ça, je surenchéri "VMS, c'est mieux que Linux".
Marc Boyer -- La contractualisation de la recherche, c'est me donner de l'argent pour faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce que je sais faire, je le fais sans moyens...
Thierry
Emmanuel Florac wrote:
moyen et un programmeur occasionnel, et j'en suis incapable. Entre passer 3 jours à écrire le truc en perl et passer 1 mois à le faire en C, j'ai déjà choisi. Je pense qu'il vaut mieux de toute façon l'avoir en Perl que de ne pas l'avoir...
C'est marrant mais c'est à peu près l'argument du "Windowsien" :
"Meme si Linux est mieux que Windows, je préfère installer Windows et l'avoir en main rapidement que d'avoir à lire des millions de pages man pour Linux."
NB: je n'ai pas dit que l'argument était "juste", mais c'est lui qui sort souvent.
Perl/Windows : meme combat (le RAD) ?
-- Thierry
Emmanuel Florac wrote:
moyen et un programmeur occasionnel, et j'en suis incapable. Entre passer
3 jours à écrire le truc en perl et passer 1 mois à le faire en C, j'ai
déjà choisi. Je pense qu'il vaut mieux de toute façon l'avoir en Perl
que de ne pas l'avoir...
C'est marrant mais c'est à peu près l'argument du "Windowsien" :
"Meme si Linux est mieux que Windows, je préfère installer Windows et
l'avoir en main rapidement que d'avoir à lire des millions de pages man
pour Linux."
NB: je n'ai pas dit que l'argument était "juste", mais c'est lui qui
sort souvent.
moyen et un programmeur occasionnel, et j'en suis incapable. Entre passer 3 jours à écrire le truc en perl et passer 1 mois à le faire en C, j'ai déjà choisi. Je pense qu'il vaut mieux de toute façon l'avoir en Perl que de ne pas l'avoir...
C'est marrant mais c'est à peu près l'argument du "Windowsien" :
"Meme si Linux est mieux que Windows, je préfère installer Windows et l'avoir en main rapidement que d'avoir à lire des millions de pages man pour Linux."
NB: je n'ai pas dit que l'argument était "juste", mais c'est lui qui sort souvent.
Perl/Windows : meme combat (le RAD) ?
-- Thierry
talon
Emmanuel Dreyfus wrote:
Michel Talon wrote:
Tu fais un make readmes sur l'arbre des ports de freebsd. Tu en as pour plusieurs heures et je ne te parle pas du dégagement de chaleur! Tout ça parceque make est utilisé de façon récursive et abominable. Pourtant il s'agit bien de programme en C. Maintenant tu installes le port portindex, qui est écrit en python.
Non, Mauvais exemple: tu compares un programme ecrit en pyhton avec un programme ecrit en Makefiles. make et pythons sont tous les deux ecrits en C.
Oui, j'étais un peu de mauvaise foi, mais bon ça prouve au moins que l'utilisation massive de machins en C inappropriés peut avoir des conséquences calamiteuses.
Tu sais qu'il paraît que le word6 était écrit en basic, et pourtant il ne ramait pas monstrueusement.
Ah?
Sur une machine récente, non.
--
Michel TALON
Emmanuel Dreyfus <manu@netbsd.org> wrote:
Michel Talon <talon@lpthe.jussieu.fr> wrote:
Tu fais un make readmes sur l'arbre des ports de freebsd. Tu en as pour
plusieurs heures et je ne te parle pas du dégagement de chaleur!
Tout ça parceque make est utilisé de façon récursive et abominable.
Pourtant il s'agit bien de programme en C. Maintenant tu installes le port
portindex, qui est écrit en python.
Non, Mauvais exemple: tu compares un programme ecrit en pyhton avec un
programme ecrit en Makefiles. make et pythons sont tous les deux ecrits
en C.
Oui, j'étais un peu de mauvaise foi, mais bon ça prouve au moins que
l'utilisation massive de machins en C inappropriés peut avoir des
conséquences calamiteuses.
Tu sais qu'il paraît que le word6 était écrit en basic, et pourtant
il ne ramait pas monstrueusement.
Tu fais un make readmes sur l'arbre des ports de freebsd. Tu en as pour plusieurs heures et je ne te parle pas du dégagement de chaleur! Tout ça parceque make est utilisé de façon récursive et abominable. Pourtant il s'agit bien de programme en C. Maintenant tu installes le port portindex, qui est écrit en python.
Non, Mauvais exemple: tu compares un programme ecrit en pyhton avec un programme ecrit en Makefiles. make et pythons sont tous les deux ecrits en C.
Oui, j'étais un peu de mauvaise foi, mais bon ça prouve au moins que l'utilisation massive de machins en C inappropriés peut avoir des conséquences calamiteuses.
Tu sais qu'il paraît que le word6 était écrit en basic, et pourtant il ne ramait pas monstrueusement.
Ah?
Sur une machine récente, non.
--
Michel TALON
Emmanuel Florac
Le Wed, 15 Sep 2004 11:12:48 +0200, Thierry a écrit :
"Meme si Linux est mieux que Windows, je préfère installer Windows et l'avoir en main rapidement que d'avoir à lire des millions de pages man pour Linux."
NB: je n'ai pas dit que l'argument était "juste", mais c'est lui qui sort souvent.
Mais il l'est. Si un utilisateur X met 2 heures à être opérationnel sous windows et 8 jours sous autre chose, je ne vois pas pourquoi il prendrait autre chose... Personnellement je suis bien plus opérationnel sous Linux, et alors?
-- Ce qu'il y a d'enivrant dans le mauvais goût c'est le plaisir aristocratique de déplaire. C. Baudelaire.
Le Wed, 15 Sep 2004 11:12:48 +0200, Thierry a écrit :
"Meme si Linux est mieux que Windows, je préfère installer Windows et
l'avoir en main rapidement que d'avoir à lire des millions de pages man
pour Linux."
NB: je n'ai pas dit que l'argument était "juste", mais c'est lui qui
sort souvent.
Mais il l'est. Si un utilisateur X met 2 heures à être opérationnel
sous windows et 8 jours sous autre chose, je ne vois pas pourquoi il
prendrait autre chose... Personnellement je suis bien plus opérationnel
sous Linux, et alors?
--
Ce qu'il y a d'enivrant dans le mauvais goût c'est le plaisir
aristocratique de déplaire.
C. Baudelaire.
Le Wed, 15 Sep 2004 11:12:48 +0200, Thierry a écrit :
"Meme si Linux est mieux que Windows, je préfère installer Windows et l'avoir en main rapidement que d'avoir à lire des millions de pages man pour Linux."
NB: je n'ai pas dit que l'argument était "juste", mais c'est lui qui sort souvent.
Mais il l'est. Si un utilisateur X met 2 heures à être opérationnel sous windows et 8 jours sous autre chose, je ne vois pas pourquoi il prendrait autre chose... Personnellement je suis bien plus opérationnel sous Linux, et alors?
-- Ce qu'il y a d'enivrant dans le mauvais goût c'est le plaisir aristocratique de déplaire. C. Baudelaire.
Emmanuel Florac
Le Wed, 15 Sep 2004 00:01:18 +0200, Pascal PETIT a écrit :
Le principe est simplissime mais ça permet de conserver un nombre important de versions d'une arborescence à moindre coût.
Oui, c'est très bien mais contrairemnet à un vrai snapshot ce n'est pas instantané. Avec un snapshot "vrai", je peux sauvegarder ma base de données en un clin d'oeil, par exemple.
-- De longs désirs, une longue admiration sans espérance, voilà le moyen d'adorer les femmes, et de rendre l'amour une passion délicieuse! N. Rétif de la Bretonne.
Le Wed, 15 Sep 2004 00:01:18 +0200, Pascal PETIT a écrit :
Le principe est simplissime mais ça permet de conserver un nombre
important de versions d'une arborescence à moindre coût.
Oui, c'est très bien mais contrairemnet à un vrai snapshot ce n'est pas
instantané. Avec un snapshot "vrai", je peux sauvegarder ma base de
données en un clin d'oeil, par exemple.
--
De longs désirs, une longue admiration sans espérance, voilà le moyen
d'adorer les femmes, et de rendre l'amour une passion délicieuse!
N. Rétif de la Bretonne.
Le Wed, 15 Sep 2004 00:01:18 +0200, Pascal PETIT a écrit :
Le principe est simplissime mais ça permet de conserver un nombre important de versions d'une arborescence à moindre coût.
Oui, c'est très bien mais contrairemnet à un vrai snapshot ce n'est pas instantané. Avec un snapshot "vrai", je peux sauvegarder ma base de données en un clin d'oeil, par exemple.
-- De longs désirs, une longue admiration sans espérance, voilà le moyen d'adorer les femmes, et de rendre l'amour une passion délicieuse! N. Rétif de la Bretonne.
Emmanuel Florac
Le Wed, 15 Sep 2004 11:56:27 +0200, Erwan David a écrit :
Idem avec cert&ains programmes unix qui reprennent l'UI windows sans la documenter parceque "tout le monde connait".
Ça c'est le pire...
-- Les défauts n'apparaissent qu'après que le programme ait passé (avec succès) la phase d'intégration. Loi de Klipstein.
Le Wed, 15 Sep 2004 11:56:27 +0200, Erwan David a écrit :
Idem avec cert&ains programmes unix qui reprennent l'UI windows sans
la documenter parceque "tout le monde connait".
Ça c'est le pire...
--
Les défauts n'apparaissent qu'après que le programme ait passé (avec
succès) la phase d'intégration.
Loi de Klipstein.
