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 :)
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.
Oui, en gros, quelques appels à system(3), avec eventuellement quelques snprintf(3) pour preparer la commande, et des stat(2), c'est pas la mer à boire.
Typiquement le genre de truc qu'il ne faut _surtout_pas_ faire en C.
On se demande bien pourquoi.
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". C'est probablement le cas, mais une fois qu'on a empilé plein de programmes en langage interpreté pour qui les performances ne sont pas critique, on obtient un OS lent.
Alors forcement, y'a la méthode Windows: avec un PC tout neuf, bourré de RAM et de GHz, ca ne se voit pas.
-- Emmanuel Dreyfus Le cahier de l'admin BSD 2eme ed. est dans toutes les bonnes librairies http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
Emmanuel Florac <eflorac@imaginet.fr> wrote:
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.
Oui, en gros, quelques appels à system(3), avec eventuellement quelques
snprintf(3) pour preparer la commande, et des stat(2), c'est pas la mer
à boire.
Typiquement le genre de truc qu'il ne faut _surtout_pas_ faire en C.
On se demande bien pourquoi.
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". C'est probablement le cas, mais une
fois qu'on a empilé plein de programmes en langage interpreté pour qui
les performances ne sont pas critique, on obtient un OS lent.
Alors forcement, y'a la méthode Windows: avec un PC tout neuf, bourré de
RAM et de GHz, ca ne se voit pas.
--
Emmanuel Dreyfus
Le cahier de l'admin BSD 2eme ed. est dans toutes les bonnes librairies
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu@netbsd.org
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.
Oui, en gros, quelques appels à system(3), avec eventuellement quelques snprintf(3) pour preparer la commande, et des stat(2), c'est pas la mer à boire.
Typiquement le genre de truc qu'il ne faut _surtout_pas_ faire en C.
On se demande bien pourquoi.
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". C'est probablement le cas, mais une fois qu'on a empilé plein de programmes en langage interpreté pour qui les performances ne sont pas critique, on obtient un OS lent.
Alors forcement, y'a la méthode Windows: avec un PC tout neuf, bourré de RAM et de GHz, ca ne se voit pas.
-- Emmanuel Dreyfus Le cahier de l'admin BSD 2eme ed. est dans toutes les bonnes librairies http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
DINH Viêt Hoà
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". C'est probablement le cas, mais une fois qu'on a empilé plein de programmes en langage interpreté pour qui les performances ne sont pas critique, on obtient un OS lent.
quid de caml ?
Alors forcement, y'a la méthode Windows: avec un PC tout neuf, bourré de RAM et de GHz, ca ne se voit pas.
mouais, c'est être mauvaise langue la. L'interface utilisateur demande quand même plus de ressources processeur qu'un twm (ou ctwm) sous linux, xterm + bash + vi. Pour une même tâche donnée, je pense que les ressources processeurs nécessaires doivent être équivalentes.
-- DINH V. Hoa,
"la chatte de ma petite soeur s'appelle Zoé" -- the captain de soiré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". C'est probablement le cas, mais une
fois qu'on a empilé plein de programmes en langage interpreté pour qui
les performances ne sont pas critique, on obtient un OS lent.
quid de caml ?
Alors forcement, y'a la méthode Windows: avec un PC tout neuf, bourré de
RAM et de GHz, ca ne se voit pas.
mouais, c'est être mauvaise langue la.
L'interface utilisateur demande quand même plus de ressources processeur
qu'un twm (ou ctwm) sous linux, xterm + bash + vi.
Pour une même tâche donnée, je pense que les ressources processeurs
nécessaires doivent être équivalentes.
--
DINH V. Hoa,
"la chatte de ma petite soeur s'appelle Zoé" -- the captain de soiré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". C'est probablement le cas, mais une fois qu'on a empilé plein de programmes en langage interpreté pour qui les performances ne sont pas critique, on obtient un OS lent.
quid de caml ?
Alors forcement, y'a la méthode Windows: avec un PC tout neuf, bourré de RAM et de GHz, ca ne se voit pas.
mouais, c'est être mauvaise langue la. L'interface utilisateur demande quand même plus de ressources processeur qu'un twm (ou ctwm) sous linux, xterm + bash + vi. Pour une même tâche donnée, je pense que les ressources processeurs nécessaires doivent être équivalentes.
-- DINH V. Hoa,
"la chatte de ma petite soeur s'appelle Zoé" -- the captain de soirées
Emmanuel Florac
Le Mon, 13 Sep 2004 21:16:42 +0200, Emmanuel Dreyfus a écrit :
Typiquement le genre de truc qu'il ne faut _surtout_pas_ faire en C.
On se demande bien pourquoi.
J'ai posté un extrait de "Art of Unix programming" d'ESR, lis-le. Je n'ai rien à dire de plus. Tu es un développeur C extrèmement pointu, moi je suis un développeur C extrèmement médiocre. Tu fais des choses qui pour moi relève de la magie noire avec du C (comme faire tourner un binaire IRIX sous OpenBSD :), tu es certainement capable de pondre un petit utilitaire en C vite fait bien fait, mais moi je ne suis qu'un type 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...
-- on passe la moitié de son temps à refaire ce que l'on n'a pas eu le temps de faire correctement. Loi de Myers.
Le Mon, 13 Sep 2004 21:16:42 +0200, Emmanuel Dreyfus a écrit :
Typiquement le genre de truc qu'il ne faut _surtout_pas_ faire en C.
On se demande bien pourquoi.
J'ai posté un extrait de "Art of Unix programming" d'ESR, lis-le. Je n'ai
rien à dire de plus. Tu es un développeur C extrèmement pointu, moi je
suis un développeur C extrèmement médiocre. Tu fais des choses qui pour
moi relève de la magie noire avec du C (comme faire tourner un binaire
IRIX sous OpenBSD :), tu es certainement capable de pondre un petit
utilitaire en C vite fait bien fait, mais moi je ne suis qu'un type
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...
--
on passe la moitié de son temps à refaire ce que l'on n'a pas eu le
temps de faire correctement.
Loi de Myers.
Le Mon, 13 Sep 2004 21:16:42 +0200, Emmanuel Dreyfus a écrit :
Typiquement le genre de truc qu'il ne faut _surtout_pas_ faire en C.
On se demande bien pourquoi.
J'ai posté un extrait de "Art of Unix programming" d'ESR, lis-le. Je n'ai rien à dire de plus. Tu es un développeur C extrèmement pointu, moi je suis un développeur C extrèmement médiocre. Tu fais des choses qui pour moi relève de la magie noire avec du C (comme faire tourner un binaire IRIX sous OpenBSD :), tu es certainement capable de pondre un petit utilitaire en C vite fait bien fait, mais moi je ne suis qu'un type 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...
-- on passe la moitié de son temps à refaire ce que l'on n'a pas eu le temps de faire correctement. Loi de Myers.
Emmanuel Florac
Le Mon, 13 Sep 2004 21:36:38 +0200, DINH Viêt Hoà a écrit :
Alors forcement, y'a la méthode Windows: avec un PC tout neuf, bourré de RAM et de GHz, ca ne se voit pas.
mouais, c'est être mauvaise langue la.
Surtout que là on parle d'un outil qu'on fait tourner généralement entre une fois par heure et une fois par jour... C'est pas ça qui va mettre mes serveurs à genoux.
-- L'Algérie était au bord du gouffre, aujourd'hui elle a fait un grand pas en avant. Kaid Ahmed.
Le Mon, 13 Sep 2004 21:36:38 +0200, DINH Viêt Hoà a écrit :
Alors forcement, y'a la méthode Windows: avec un PC tout neuf, bourré de
RAM et de GHz, ca ne se voit pas.
mouais, c'est être mauvaise langue la.
Surtout que là on parle d'un outil qu'on fait tourner généralement
entre une fois par heure et une fois par jour... C'est pas ça qui va
mettre mes serveurs à genoux.
--
L'Algérie était au bord du gouffre, aujourd'hui elle a fait un grand pas
en avant.
Kaid Ahmed.
Le Mon, 13 Sep 2004 21:36:38 +0200, DINH Viêt Hoà a écrit :
Alors forcement, y'a la méthode Windows: avec un PC tout neuf, bourré de RAM et de GHz, ca ne se voit pas.
mouais, c'est être mauvaise langue la.
Surtout que là on parle d'un outil qu'on fait tourner généralement entre une fois par heure et une fois par jour... C'est pas ça qui va mettre mes serveurs à genoux.
-- L'Algérie était au bord du gouffre, aujourd'hui elle a fait un grand pas en avant. Kaid Ahmed.
manu
Emmanuel Florac wrote:
J'ai posté un extrait de "Art of Unix programming" d'ESR, lis-le. Je n'ai rien à dire de plus. Tu es un développeur C extrèmement pointu, moi je suis un développeur C extrèmement médiocre. Tu fais des choses qui pour moi relève de la magie noire avec du C (comme faire tourner un binaire IRIX sous OpenBSD :),
Ah non, faut pas tout mélanger: COMPAT_IRIX est une spécialité de NetBSD/sgimips. OpenBSD n'a même jamais tourné sur sgimips.
Je ne pense pas être un programmeur C très pointu comme tu le dis. Je n'ai d'ailleurs jamais vraiemnt appris le C, c'est rentré petit à petit en faisant des patches pour compiler du logiciel libre.
Les opérations de magie noire citées ci dessus relèvent plus de la connaissance du fonctionnement du système que de celle du C.
tu es certainement capable de pondre un petit utilitaire en C vite fait bien fait, mais moi je ne suis qu'un type 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...
Tu oublies que c'est en forgeant qu'on devient forgeron, et c'est en faisant du C qu'on devient bon en C. Et aussi en programmation système Unix, d'ailleurs, puisque c'est surtout ca qui est mis en jeu ici.
-- Emmanuel Dreyfus Un bouquin en français sur BSD: http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
Emmanuel Florac <eflorac@imaginet.fr> wrote:
J'ai posté un extrait de "Art of Unix programming" d'ESR, lis-le. Je n'ai
rien à dire de plus. Tu es un développeur C extrèmement pointu, moi je
suis un développeur C extrèmement médiocre. Tu fais des choses qui pour
moi relève de la magie noire avec du C (comme faire tourner un binaire
IRIX sous OpenBSD :),
Ah non, faut pas tout mélanger: COMPAT_IRIX est une spécialité de
NetBSD/sgimips. OpenBSD n'a même jamais tourné sur sgimips.
Je ne pense pas être un programmeur C très pointu comme tu le dis. Je
n'ai d'ailleurs jamais vraiemnt appris le C, c'est rentré petit à petit
en faisant des patches pour compiler du logiciel libre.
Les opérations de magie noire citées ci dessus relèvent plus de la
connaissance du fonctionnement du système que de celle du C.
tu es certainement capable de pondre un petit
utilitaire en C vite fait bien fait, mais moi je ne suis qu'un type
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...
Tu oublies que c'est en forgeant qu'on devient forgeron, et c'est en
faisant du C qu'on devient bon en C. Et aussi en programmation système
Unix, d'ailleurs, puisque c'est surtout ca qui est mis en jeu ici.
--
Emmanuel Dreyfus
Un bouquin en français sur BSD:
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu@netbsd.org
J'ai posté un extrait de "Art of Unix programming" d'ESR, lis-le. Je n'ai rien à dire de plus. Tu es un développeur C extrèmement pointu, moi je suis un développeur C extrèmement médiocre. Tu fais des choses qui pour moi relève de la magie noire avec du C (comme faire tourner un binaire IRIX sous OpenBSD :),
Ah non, faut pas tout mélanger: COMPAT_IRIX est une spécialité de NetBSD/sgimips. OpenBSD n'a même jamais tourné sur sgimips.
Je ne pense pas être un programmeur C très pointu comme tu le dis. Je n'ai d'ailleurs jamais vraiemnt appris le C, c'est rentré petit à petit en faisant des patches pour compiler du logiciel libre.
Les opérations de magie noire citées ci dessus relèvent plus de la connaissance du fonctionnement du système que de celle du C.
tu es certainement capable de pondre un petit utilitaire en C vite fait bien fait, mais moi je ne suis qu'un type 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...
Tu oublies que c'est en forgeant qu'on devient forgeron, et c'est en faisant du C qu'on devient bon en C. Et aussi en programmation système Unix, d'ailleurs, puisque c'est surtout ca qui est mis en jeu ici.
-- Emmanuel Dreyfus Un bouquin en français sur BSD: http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
DINH Viêt Hoà
tu es certainement capable de pondre un petit utilitaire en C vite fait bien fait, mais moi je ne suis qu'un type 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...
Tu oublies que c'est en forgeant qu'on devient forgeron, et c'est en faisant du C qu'on devient bon en C. Et aussi en programmation système Unix, d'ailleurs, puisque c'est surtout ca qui est mis en jeu ici.
ah non ! c'est en tentant d'écrire un compilateur C (sans y parvenir) qu'on commence a comprendre un peu le C (sans oublier le kernighan & richie sous le coude).
et pour devenir bon en systeme, rien ne vaut le dernier best-seller de monsieur mcKusick.
-- DINH V. Hoa,
"la chatte de ma petite soeur s'appelle Zoé" -- the captain de soirées
tu es certainement capable de pondre un petit
utilitaire en C vite fait bien fait, mais moi je ne suis qu'un type
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...
Tu oublies que c'est en forgeant qu'on devient forgeron, et c'est en
faisant du C qu'on devient bon en C. Et aussi en programmation système
Unix, d'ailleurs, puisque c'est surtout ca qui est mis en jeu ici.
ah non ! c'est en tentant d'écrire un compilateur C (sans y
parvenir) qu'on commence a comprendre un peu le C (sans oublier le
kernighan & richie sous le coude).
et pour devenir bon en systeme, rien ne vaut le dernier best-seller de
monsieur mcKusick.
--
DINH V. Hoa,
"la chatte de ma petite soeur s'appelle Zoé" -- the captain de soirées
tu es certainement capable de pondre un petit utilitaire en C vite fait bien fait, mais moi je ne suis qu'un type 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...
Tu oublies que c'est en forgeant qu'on devient forgeron, et c'est en faisant du C qu'on devient bon en C. Et aussi en programmation système Unix, d'ailleurs, puisque c'est surtout ca qui est mis en jeu ici.
ah non ! c'est en tentant d'écrire un compilateur C (sans y parvenir) qu'on commence a comprendre un peu le C (sans oublier le kernighan & richie sous le coude).
et pour devenir bon en systeme, rien ne vaut le dernier best-seller de monsieur mcKusick.
-- DINH V. Hoa,
"la chatte de ma petite soeur s'appelle Zoé" -- the captain de soirées
manu
DINH Viêt Hoà wrote:
ah non ! c'est en tentant d'écrire un compilateur C (sans y parvenir) qu'on commence a comprendre un peu le C
Ah j'aurai dit que ca permettait d'apprendre lex et yacc.
-- Emmanuel Dreyfus Un bouquin en français sur BSD: http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
DINH Viêt Hoà <dinh.viet.hoa@free.fr> wrote:
ah non ! c'est en tentant d'écrire un compilateur C (sans y
parvenir) qu'on commence a comprendre un peu le C
Ah j'aurai dit que ca permettait d'apprendre lex et yacc.
--
Emmanuel Dreyfus
Un bouquin en français sur BSD:
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu@netbsd.org
ah non ! c'est en tentant d'écrire un compilateur C (sans y parvenir) qu'on commence a comprendre un peu le C
Ah j'aurai dit que ca permettait d'apprendre lex et yacc.
-- Emmanuel Dreyfus Un bouquin en français sur BSD: http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
talon
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". C'est probablement le cas, mais une fois qu'on a empilé plein de programmes en langage interpreté pour qui les performances ne sont pas critique, on obtient un OS lent.
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. Il y a une première passe qui dure aussi environ une heure, puis la génération des readme, de l'index ou toutes les passes ultérieures prennent quelques minutes. Bref, si le programme n'est pas immonde, une efficacité suffisante peut être au rendez vous.
Alors forcement, y'a la méthode Windows: avec un PC tout neuf, bourré de RAM et de GHz, ca ne se voit pas.
Tu sais qu'il paraît que le word6 était écrit en basic, et pourtant il ne ramait pas monstrueusement.
--
Michel TALON
Emmanuel Dreyfus <manu@netbsd.org> 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". C'est probablement le cas, mais une
fois qu'on a empilé plein de programmes en langage interpreté pour qui
les performances ne sont pas critique, on obtient un OS lent.
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. Il y a une première passe qui
dure aussi environ une heure, puis la génération des readme, de l'index
ou toutes les passes ultérieures prennent quelques minutes.
Bref, si le programme n'est pas immonde, une efficacité suffisante peut
être au rendez vous.
Alors forcement, y'a la méthode Windows: avec un PC tout neuf, bourré de
RAM et de GHz, ca ne se voit pas.
Tu sais qu'il paraît que le word6 était écrit en basic, et pourtant
il ne ramait pas monstrueusement.
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". C'est probablement le cas, mais une fois qu'on a empilé plein de programmes en langage interpreté pour qui les performances ne sont pas critique, on obtient un OS lent.
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. Il y a une première passe qui dure aussi environ une heure, puis la génération des readme, de l'index ou toutes les passes ultérieures prennent quelques minutes. Bref, si le programme n'est pas immonde, une efficacité suffisante peut être au rendez vous.
Alors forcement, y'a la méthode Windows: avec un PC tout neuf, bourré de RAM et de GHz, ca ne se voit pas.
Tu sais qu'il paraît que le word6 était écrit en basic, et pourtant il ne ramait pas monstrueusement.
--
Michel TALON
Pascal Bourguignon
(Emmanuel Dreyfus) writes:
Emmanuel Florac wrote:
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.
Oui, en gros, quelques appels à system(3), avec eventuellement quelques snprintf(3) pour preparer la commande, et des stat(2), c'est pas la mer à boire.
Typiquement le genre de truc qu'il ne faut _surtout_pas_ faire en C.
On se demande bien pourquoi.
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". C'est probablement le cas, mais une fois qu'on a empilé plein de programmes en langage interpreté pour qui les performances ne sont pas critique, on obtient un OS lent.
Alors forcement, y'a la méthode Windows: avec un PC tout neuf, bourré de RAM et de GHz, ca ne se voit pas.
D'accord, mais pas d'accord. La question à se poser c'est combien de temps le programmeur devra passer avec C ou avec un language de haut niveau (comme par exemple Common-Lisp dans mon cas), pour obtenir le programme?
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.
N'oublions pas qu'à part 1 utilisateur sur Terre, pour les six ou sept milliards restant, il y a toujours un ordinateur plus puissant.
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:
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.
Oui, en gros, quelques appels à system(3), avec eventuellement quelques
snprintf(3) pour preparer la commande, et des stat(2), c'est pas la mer
à boire.
Typiquement le genre de truc qu'il ne faut _surtout_pas_ faire en C.
On se demande bien pourquoi.
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". C'est probablement le cas, mais une
fois qu'on a empilé plein de programmes en langage interpreté pour qui
les performances ne sont pas critique, on obtient un OS lent.
Alors forcement, y'a la méthode Windows: avec un PC tout neuf, bourré de
RAM et de GHz, ca ne se voit pas.
D'accord, mais pas d'accord. La question à se poser c'est combien de
temps le programmeur devra passer avec C ou avec un language de haut
niveau (comme par exemple Common-Lisp dans mon cas), pour obtenir le
programme?
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.
N'oublions pas qu'à part 1 utilisateur sur Terre, pour les six ou sept
milliards restant, il y a toujours un ordinateur plus puissant.
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.
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.
Oui, en gros, quelques appels à system(3), avec eventuellement quelques snprintf(3) pour preparer la commande, et des stat(2), c'est pas la mer à boire.
Typiquement le genre de truc qu'il ne faut _surtout_pas_ faire en C.
On se demande bien pourquoi.
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". C'est probablement le cas, mais une fois qu'on a empilé plein de programmes en langage interpreté pour qui les performances ne sont pas critique, on obtient un OS lent.
Alors forcement, y'a la méthode Windows: avec un PC tout neuf, bourré de RAM et de GHz, ca ne se voit pas.
D'accord, mais pas d'accord. La question à se poser c'est combien de temps le programmeur devra passer avec C ou avec un language de haut niveau (comme par exemple Common-Lisp dans mon cas), pour obtenir le programme?
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.
N'oublions pas qu'à part 1 utilisateur sur Terre, pour les six ou sept milliards restant, il y a toujours un ordinateur plus puissant.
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
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.
Tu sais qu'il paraît que le word6 était écrit en basic, et pourtant il ne ramait pas monstrueusement.
Ah?
-- Emmanuel Dreyfus Le cahier de l'admin BSD 2eme ed. est dans toutes les bonnes librairies http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
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.
Tu sais qu'il paraît que le word6 était écrit en basic, et pourtant
il ne ramait pas monstrueusement.
Ah?
--
Emmanuel Dreyfus
Le cahier de l'admin BSD 2eme ed. est dans toutes les bonnes librairies
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu@netbsd.org
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.
Tu sais qu'il paraît que le word6 était écrit en basic, et pourtant il ne ramait pas monstrueusement.
Ah?
-- Emmanuel Dreyfus Le cahier de l'admin BSD 2eme ed. est dans toutes les bonnes librairies http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
