Au hasard de la promenade dans les nouvelles fonctionnalités de Lion,
trois liens qui me semblent intéressants et méritent sans doute
approfondissement :
1/ le prix de la version serveur (sans limitations ?)
<http://www.apple.com/fr/macosx/server/>
2/ le Per-user screen sharing qui romprait avec l'utilisation de Mac OSX
uniquement "en avant plan" (si je comprends bien)
<http://www.apple.com/fr/macosx/whats-new/features.html#screensharing>
3/ les solutions de restauration sur partition dédiée ou depuis un
backup TimeMachine (et pas seulement en ligne)
<http://www.apple.com/fr/macosx/whats-new/features.html#internetrestore>
(pour répondre aux inquiétudes de notre ami)
Il semble qu'il y ait pas mal d'autres bonnes choses à découvrir
Par contre c'est 10 fois plus simple d'ajouter une ligne à fstab ou dans la crontab, que de créer un fichier plist obèse.
c'est clair...
ceci dit, je vois que tous les informaticiens avec lesquels je bosse abandonnent les fichiers textes pour proner partout le xml (ce qu'est un plist). Je me fais traiter de ringard quand je tente d'imposer des parametrages sur des fichiers ACSII.
Il y a probablement une raison défendable...
et de fait, ce n'est pas si pénible que ça de parametrer une plist ; l'éditeur affiche des étiquettes faciles à comprendre, les options se font sur des listes de menu, etc... Quand on ne connait pas, par coeur le parametrage de l'outil c'est pas mal. Bien sur, il y a la possibilité de mettre des commenatires dans un .conf, mais ce n'est pas forcement aussi lisible.
-- Philippe Manet en fait, c'est manet avant @
pehache <pehache.7@gmail.com> wrote:
Par contre c'est 10 fois plus simple d'ajouter une ligne à
fstab ou dans la crontab, que de créer un fichier plist obèse.
c'est clair...
ceci dit, je vois que tous les informaticiens avec lesquels je bosse
abandonnent les fichiers textes pour proner partout le xml (ce qu'est un
plist).
Je me fais traiter de ringard quand je tente d'imposer des parametrages
sur des fichiers ACSII.
Il y a probablement une raison défendable...
et de fait, ce n'est pas si pénible que ça de parametrer une plist ;
l'éditeur affiche des étiquettes faciles à comprendre, les options se
font sur des listes de menu, etc...
Quand on ne connait pas, par coeur le parametrage de l'outil c'est pas
mal. Bien sur, il y a la possibilité de mettre des commenatires dans un
.conf, mais ce n'est pas forcement aussi lisible.
Par contre c'est 10 fois plus simple d'ajouter une ligne à fstab ou dans la crontab, que de créer un fichier plist obèse.
c'est clair...
ceci dit, je vois que tous les informaticiens avec lesquels je bosse abandonnent les fichiers textes pour proner partout le xml (ce qu'est un plist). Je me fais traiter de ringard quand je tente d'imposer des parametrages sur des fichiers ACSII.
Il y a probablement une raison défendable...
et de fait, ce n'est pas si pénible que ça de parametrer une plist ; l'éditeur affiche des étiquettes faciles à comprendre, les options se font sur des listes de menu, etc... Quand on ne connait pas, par coeur le parametrage de l'outil c'est pas mal. Bien sur, il y a la possibilité de mettre des commenatires dans un .conf, mais ce n'est pas forcement aussi lisible.
-- Philippe Manet en fait, c'est manet avant @
Erwan David
(Philippe Manet) écrivait :
pehache wrote:
Par contre c'est 10 fois plus simple d'ajouter une ligne à fstab ou dans la crontab, que de créer un fichier plist obèse.
c'est clair...
ceci dit, je vois que tous les informaticiens avec lesquels je bosse abandonnent les fichiers textes pour proner partout le xml (ce qu'est un plist).
Pas tous...
Je me fais traiter de ringard quand je tente d'imposer des parametrages sur des fichiers ACSII.
Il y a probablement une raison défendable...
Juste de pas se fatiguer à réfléchir et d'utuiliser un bloartware comme parser.
À noter que la plupart du temps ces fichiers n'ont pas de DTD ou de schéma défini...
et de fait, ce n'est pas si pénible que ça de parametrer une plist ; l'éditeur affiche des étiquettes faciles à comprendre, les options se font sur des listes de menu, etc...
C'est lourd et lent, il faut un éditeur spécialiser qui fait perdre un temps fou avec des menus et des boutons dans tous les sens là où on n'a qu'une valeur à mettre.
Les plist sont particulièrement chiant car pour mettre une valeur il faut l'enfouir sous 3 ou 4 niveaux de structurations qui n'apportent rien.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
yapu@invivo.edu (Philippe Manet) écrivait :
pehache <pehache.7@gmail.com> wrote:
Par contre c'est 10 fois plus simple d'ajouter une ligne à
fstab ou dans la crontab, que de créer un fichier plist obèse.
c'est clair...
ceci dit, je vois que tous les informaticiens avec lesquels je bosse
abandonnent les fichiers textes pour proner partout le xml (ce qu'est un
plist).
Pas tous...
Je me fais traiter de ringard quand je tente d'imposer des parametrages
sur des fichiers ACSII.
Il y a probablement une raison défendable...
Juste de pas se fatiguer à réfléchir et d'utuiliser un bloartware comme
parser.
À noter que la plupart du temps ces fichiers n'ont pas de DTD ou de
schéma défini...
et de fait, ce n'est pas si pénible que ça de parametrer une plist ;
l'éditeur affiche des étiquettes faciles à comprendre, les options se
font sur des listes de menu, etc...
C'est lourd et lent, il faut un éditeur spécialiser qui fait perdre un
temps fou avec des menus et des boutons dans tous les sens là où on n'a
qu'une valeur à mettre.
Les plist sont particulièrement chiant car pour mettre une valeur il
faut l'enfouir sous 3 ou 4 niveaux de structurations qui n'apportent
rien.
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Par contre c'est 10 fois plus simple d'ajouter une ligne à fstab ou dans la crontab, que de créer un fichier plist obèse.
c'est clair...
ceci dit, je vois que tous les informaticiens avec lesquels je bosse abandonnent les fichiers textes pour proner partout le xml (ce qu'est un plist).
Pas tous...
Je me fais traiter de ringard quand je tente d'imposer des parametrages sur des fichiers ACSII.
Il y a probablement une raison défendable...
Juste de pas se fatiguer à réfléchir et d'utuiliser un bloartware comme parser.
À noter que la plupart du temps ces fichiers n'ont pas de DTD ou de schéma défini...
et de fait, ce n'est pas si pénible que ça de parametrer une plist ; l'éditeur affiche des étiquettes faciles à comprendre, les options se font sur des listes de menu, etc...
C'est lourd et lent, il faut un éditeur spécialiser qui fait perdre un temps fou avec des menus et des boutons dans tous les sens là où on n'a qu'une valeur à mettre.
Les plist sont particulièrement chiant car pour mettre une valeur il faut l'enfouir sous 3 ou 4 niveaux de structurations qui n'apportent rien.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
xavier
Philippe Manet wrote:
Bien sur, il y a la possibilité de mettre des commenatires dans un .conf, mais ce n'est pas forcement aussi lisible.
Moi, je trouve ça fondamental.
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear. (Jethro Tull)
Philippe Manet <yapu@invivo.edu> wrote:
Bien sur, il y a la possibilité de mettre des commenatires dans un
.conf, mais ce n'est pas forcement aussi lisible.
Moi, je trouve ça fondamental.
--
XAv
In your pomp and all your glory you're a poorer man than me,
as you lick the boots of death born out of fear.
(Jethro Tull)
Bien sur, il y a la possibilité de mettre des commenatires dans un .conf, mais ce n'est pas forcement aussi lisible.
Moi, je trouve ça fondamental.
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear. (Jethro Tull)
filh
pehache wrote:
Le 26/06/11 22:19, FiLH a écrit : >> >> Et cela aussi est faux, puisque apparemment launchd n'est pas seulement >> censé venir en surcouche des outils classiques comme crond, mais les >> remplacer à terme. > > Je parlais essentiellement des fichiers de démarrage. > Quant à cron.. heu... qu'on mette la commande au bout d'une ligne de > texte ou dans un fichier xml c'est juste un changement de syntaxe.
Peut-être, mais entre une syntaxe où chaque tâche gérée par crond consiste en une unique ligne dans un fichier commun, et une syntaxe qui réclame un fichier de 30 lignes par tâche, mon choix est vite fait. D'autant plus que dans le premier cas la syntaxe est commune à tous les unix.
Oui mais bon ça ne marche pas bien pour tous les cas modernes.
Par exemple comment déclarer une tache cron qui dépendrait du lancement d'un autre service.
J'ai par exemple le cas d'un cluster actif/passif de serveurs webs : faire les tâches de maintenances du serveur n'est utile que si le serveur est actif sur la machine.
Ce sont des cas qui n'existaient pas il y a 10 ans...
Donc oui c'était plus simple avant... mais on faisait tellement moins de choses avant...
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
pehache <pehache.7@gmail.com> wrote:
Le 26/06/11 22:19, FiLH a écrit :
>>
>> Et cela aussi est faux, puisque apparemment launchd n'est pas seulement
>> censé venir en surcouche des outils classiques comme crond, mais les
>> remplacer à terme.
>
> Je parlais essentiellement des fichiers de démarrage.
> Quant à cron.. heu... qu'on mette la commande au bout d'une ligne de
> texte ou dans un fichier xml c'est juste un changement de syntaxe.
Peut-être, mais entre une syntaxe où chaque tâche gérée par crond
consiste en une unique ligne dans un fichier commun, et une syntaxe qui
réclame un fichier de 30 lignes par tâche, mon choix est vite fait.
D'autant plus que dans le premier cas la syntaxe est commune à tous les
unix.
Oui mais bon ça ne marche pas bien pour tous les cas modernes.
Par exemple comment déclarer une tache cron qui dépendrait du lancement
d'un autre service.
J'ai par exemple le cas d'un cluster actif/passif de serveurs webs :
faire les tâches de maintenances du serveur n'est utile que si le
serveur est actif sur la machine.
Ce sont des cas qui n'existaient pas il y a 10 ans...
Donc oui c'était plus simple avant... mais on faisait tellement moins de
choses avant...
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org
Le 26/06/11 22:19, FiLH a écrit : >> >> Et cela aussi est faux, puisque apparemment launchd n'est pas seulement >> censé venir en surcouche des outils classiques comme crond, mais les >> remplacer à terme. > > Je parlais essentiellement des fichiers de démarrage. > Quant à cron.. heu... qu'on mette la commande au bout d'une ligne de > texte ou dans un fichier xml c'est juste un changement de syntaxe.
Peut-être, mais entre une syntaxe où chaque tâche gérée par crond consiste en une unique ligne dans un fichier commun, et une syntaxe qui réclame un fichier de 30 lignes par tâche, mon choix est vite fait. D'autant plus que dans le premier cas la syntaxe est commune à tous les unix.
Oui mais bon ça ne marche pas bien pour tous les cas modernes.
Par exemple comment déclarer une tache cron qui dépendrait du lancement d'un autre service.
J'ai par exemple le cas d'un cluster actif/passif de serveurs webs : faire les tâches de maintenances du serveur n'est utile que si le serveur est actif sur la machine.
Ce sont des cas qui n'existaient pas il y a 10 ans...
Donc oui c'était plus simple avant... mais on faisait tellement moins de choses avant...
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
filh
Erwan David wrote:
(Philippe Manet) écrivait :
> pehache wrote: > >> Par contre c'est 10 fois plus simple d'ajouter une ligne à >> fstab ou dans la crontab, que de créer un fichier plist obèse. > > c'est clair... > > ceci dit, je vois que tous les informaticiens avec lesquels je bosse > abandonnent les fichiers textes pour proner partout le xml (ce qu'est un > plist).
Pas tous...
> Je me fais traiter de ringard quand je tente d'imposer des parametrages > sur des fichiers ACSII. > > Il y a probablement une raison défendable...
Juste de pas se fatiguer à réfléchir et d'utuiliser un bloartware comme parser.
Ben.. je préfère réfléchir à des concepts plus amusants qu'à devoir en rester au niveau syntaxique.
Réfléchir à la syntaxe n'a aucun intérêt : un programme peut le faire, ce n'est donc pas une réflexion d'un niveau humain.
Mais bon... chacun réfléchit à son niveau, certains en restent à la syntaxe...
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
Erwan David <erwan@rail.eu.org> wrote:
yapu@invivo.edu (Philippe Manet) écrivait :
> pehache <pehache.7@gmail.com> wrote:
>
>> Par contre c'est 10 fois plus simple d'ajouter une ligne à
>> fstab ou dans la crontab, que de créer un fichier plist obèse.
>
> c'est clair...
>
> ceci dit, je vois que tous les informaticiens avec lesquels je bosse
> abandonnent les fichiers textes pour proner partout le xml (ce qu'est un
> plist).
Pas tous...
> Je me fais traiter de ringard quand je tente d'imposer des parametrages
> sur des fichiers ACSII.
>
> Il y a probablement une raison défendable...
Juste de pas se fatiguer à réfléchir et d'utuiliser un bloartware comme
parser.
Ben.. je préfère réfléchir à des concepts plus amusants qu'à devoir en
rester au niveau syntaxique.
Réfléchir à la syntaxe n'a aucun intérêt : un programme peut le faire,
ce n'est donc pas une réflexion d'un niveau humain.
Mais bon... chacun réfléchit à son niveau, certains en restent à la
syntaxe...
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org
> pehache wrote: > >> Par contre c'est 10 fois plus simple d'ajouter une ligne à >> fstab ou dans la crontab, que de créer un fichier plist obèse. > > c'est clair... > > ceci dit, je vois que tous les informaticiens avec lesquels je bosse > abandonnent les fichiers textes pour proner partout le xml (ce qu'est un > plist).
Pas tous...
> Je me fais traiter de ringard quand je tente d'imposer des parametrages > sur des fichiers ACSII. > > Il y a probablement une raison défendable...
Juste de pas se fatiguer à réfléchir et d'utuiliser un bloartware comme parser.
Ben.. je préfère réfléchir à des concepts plus amusants qu'à devoir en rester au niveau syntaxique.
Réfléchir à la syntaxe n'a aucun intérêt : un programme peut le faire, ce n'est donc pas une réflexion d'un niveau humain.
Mais bon... chacun réfléchit à son niveau, certains en restent à la syntaxe...
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
filh
Philippe Manet wrote:
pehache wrote:
> Par contre c'est 10 fois plus simple d'ajouter une ligne à > fstab ou dans la crontab, que de créer un fichier plist obèse.
c'est clair...
ceci dit, je vois que tous les informaticiens avec lesquels je bosse abandonnent les fichiers textes pour proner partout le xml (ce qu'est un plist). Je me fais traiter de ringard quand je tente d'imposer des parametrages sur des fichiers ACSII.
Il y a probablement une raison défendable...
et de fait, ce n'est pas si pénible que ça de parametrer une plist ; l'éditeur affiche des étiquettes faciles à comprendre, les options se font sur des listes de menu, etc... Quand on ne connait pas, par coeur le parametrage de l'outil c'est pas mal. Bien sur, il y a la possibilité de mettre des commenatires dans un .conf, mais ce n'est pas forcement aussi lisible.
xmllint par exemple est une bonne raison.
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
Philippe Manet <yapu@invivo.edu> wrote:
pehache <pehache.7@gmail.com> wrote:
> Par contre c'est 10 fois plus simple d'ajouter une ligne à
> fstab ou dans la crontab, que de créer un fichier plist obèse.
c'est clair...
ceci dit, je vois que tous les informaticiens avec lesquels je bosse
abandonnent les fichiers textes pour proner partout le xml (ce qu'est un
plist).
Je me fais traiter de ringard quand je tente d'imposer des parametrages
sur des fichiers ACSII.
Il y a probablement une raison défendable...
et de fait, ce n'est pas si pénible que ça de parametrer une plist ;
l'éditeur affiche des étiquettes faciles à comprendre, les options se
font sur des listes de menu, etc...
Quand on ne connait pas, par coeur le parametrage de l'outil c'est pas
mal. Bien sur, il y a la possibilité de mettre des commenatires dans un
.conf, mais ce n'est pas forcement aussi lisible.
xmllint par exemple est une bonne raison.
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org
> Par contre c'est 10 fois plus simple d'ajouter une ligne à > fstab ou dans la crontab, que de créer un fichier plist obèse.
c'est clair...
ceci dit, je vois que tous les informaticiens avec lesquels je bosse abandonnent les fichiers textes pour proner partout le xml (ce qu'est un plist). Je me fais traiter de ringard quand je tente d'imposer des parametrages sur des fichiers ACSII.
Il y a probablement une raison défendable...
et de fait, ce n'est pas si pénible que ça de parametrer une plist ; l'éditeur affiche des étiquettes faciles à comprendre, les options se font sur des listes de menu, etc... Quand on ne connait pas, par coeur le parametrage de l'outil c'est pas mal. Bien sur, il y a la possibilité de mettre des commenatires dans un .conf, mais ce n'est pas forcement aussi lisible.
xmllint par exemple est une bonne raison.
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
pehache
Le 29/06/11 01:43, Philippe Manet a écrit :
pehache wrote:
Par contre c'est 10 fois plus simple d'ajouter une ligne à fstab ou dans la crontab, que de créer un fichier plist obèse.
c'est clair...
ceci dit, je vois que tous les informaticiens avec lesquels je bosse abandonnent les fichiers textes pour proner partout le xml (ce qu'est un plist).
Mauvais informaticiens, changer d'informaticiens
Je me fais traiter de ringard quand je tente d'imposer des parametrages sur des fichiers ACSII.
Il y a probablement une raison défendable...
La mode ?
et de fait, ce n'est pas si pénible que ça de parametrer une plist ; l'éditeur affiche des étiquettes faciles à comprendre, les options se font sur des listes de menu, etc... Quand on ne connait pas, par coeur le parametrage de l'outil c'est pas mal. Bien sur, il y a la possibilité de mettre des commenatires dans un .conf, mais ce n'est pas forcement aussi lisible.
Il est clair que quand on doit construire un truc aussi lourdingue qu'un fichier plist, un éditeur en GUI avec menus devient quasi indispensable (et je suis sérieux).
-- pehache
Le 29/06/11 01:43, Philippe Manet a écrit :
pehache<pehache.7@gmail.com> wrote:
Par contre c'est 10 fois plus simple d'ajouter une ligne à
fstab ou dans la crontab, que de créer un fichier plist obèse.
c'est clair...
ceci dit, je vois que tous les informaticiens avec lesquels je bosse
abandonnent les fichiers textes pour proner partout le xml (ce qu'est un
plist).
Mauvais informaticiens, changer d'informaticiens
Je me fais traiter de ringard quand je tente d'imposer des parametrages
sur des fichiers ACSII.
Il y a probablement une raison défendable...
La mode ?
et de fait, ce n'est pas si pénible que ça de parametrer une plist ;
l'éditeur affiche des étiquettes faciles à comprendre, les options se
font sur des listes de menu, etc...
Quand on ne connait pas, par coeur le parametrage de l'outil c'est pas
mal. Bien sur, il y a la possibilité de mettre des commenatires dans un
.conf, mais ce n'est pas forcement aussi lisible.
Il est clair que quand on doit construire un truc aussi lourdingue qu'un
fichier plist, un éditeur en GUI avec menus devient quasi indispensable
(et je suis sérieux).
Par contre c'est 10 fois plus simple d'ajouter une ligne à fstab ou dans la crontab, que de créer un fichier plist obèse.
c'est clair...
ceci dit, je vois que tous les informaticiens avec lesquels je bosse abandonnent les fichiers textes pour proner partout le xml (ce qu'est un plist).
Mauvais informaticiens, changer d'informaticiens
Je me fais traiter de ringard quand je tente d'imposer des parametrages sur des fichiers ACSII.
Il y a probablement une raison défendable...
La mode ?
et de fait, ce n'est pas si pénible que ça de parametrer une plist ; l'éditeur affiche des étiquettes faciles à comprendre, les options se font sur des listes de menu, etc... Quand on ne connait pas, par coeur le parametrage de l'outil c'est pas mal. Bien sur, il y a la possibilité de mettre des commenatires dans un .conf, mais ce n'est pas forcement aussi lisible.
Il est clair que quand on doit construire un truc aussi lourdingue qu'un fichier plist, un éditeur en GUI avec menus devient quasi indispensable (et je suis sérieux).
-- pehache
pehache
Le 29/06/11 20:42, FiLH a écrit :
Juste de pas se fatiguer à réfléchir et d'utuiliser un bloartware comme parser.
Ben.. je préfère réfléchir à des concepts plus amusants qu'à devoir en rester au niveau syntaxique.
Réfléchir à la syntaxe n'a aucun intérêt : un programme peut le faire, ce n'est donc pas une réflexion d'un niveau humain.
Mais bon... chacun réfléchit à son niveau, certains en restent à la syntaxe...
Il est bien connu qu'il n'y a pas de syntaxe à respecter dans un fichier XML
-- pehache
Le 29/06/11 20:42, FiLH a écrit :
Juste de pas se fatiguer à réfléchir et d'utuiliser un bloartware comme
parser.
Ben.. je préfère réfléchir à des concepts plus amusants qu'à devoir en
rester au niveau syntaxique.
Réfléchir à la syntaxe n'a aucun intérêt : un programme peut le faire,
ce n'est donc pas une réflexion d'un niveau humain.
Mais bon... chacun réfléchit à son niveau, certains en restent à la
syntaxe...
Il est bien connu qu'il n'y a pas de syntaxe à respecter dans un fichier XML
Juste de pas se fatiguer à réfléchir et d'utuiliser un bloartware comme parser.
Ben.. je préfère réfléchir à des concepts plus amusants qu'à devoir en rester au niveau syntaxique.
Réfléchir à la syntaxe n'a aucun intérêt : un programme peut le faire, ce n'est donc pas une réflexion d'un niveau humain.
Mais bon... chacun réfléchit à son niveau, certains en restent à la syntaxe...
Il est bien connu qu'il n'y a pas de syntaxe à respecter dans un fichier XML
-- pehache
pehache
Le 29/06/11 20:42, FiLH a écrit :
Peut-être, mais entre une syntaxe où chaque tâche gérée par crond consiste en une unique ligne dans un fichier commun, et une syntaxe qui réclame un fichier de 30 lignes par tâche, mon choix est vite fait. D'autant plus que dans le premier cas la syntaxe est commune à tous les unix.
Oui mais bon ça ne marche pas bien pour tous les cas modernes.
Par exemple comment déclarer une tache cron qui dépendrait du lancement d'un autre service.
J'ai par exemple le cas d'un cluster actif/passif de serveurs webs : faire les tâches de maintenances du serveur n'est utile que si le serveur est actif sur la machine.
Ce sont des cas qui n'existaient pas il y a 10 ans...
Donc oui c'était plus simple avant... mais on faisait tellement moins de choses avant...
C'est faux. Simplement, les choses complexes se faisaient avec des cascades d'outils simples et canoniques, ce qui correspond à la philosophie unix depuis ses débuts.
Les clusters existaient il y a 10 ans, et on faisait des choses compliquées avec, comme du calcul parallèle en gérant les noeuds qui tombent en panne ou bien où le soft se plante, en relançant automatiquement les bouts de calculs manquants sur d'autres noeuds, etc... Il y a 20 ans, les Cray tournaient sous uniCOS et je n'oserais pas dire qu'un Cray ne faisait pas des choses compliquées.
Vouloir centraliser les services n'est pas une mauvaise idée en soi, mais un outil comme launchd qui prétend tout faire devient facilement indigeste, en plus d'être limité dans la pratique à une plateforme.
-- pehache
Le 29/06/11 20:42, FiLH a écrit :
Peut-être, mais entre une syntaxe où chaque tâche gérée par crond
consiste en une unique ligne dans un fichier commun, et une syntaxe qui
réclame un fichier de 30 lignes par tâche, mon choix est vite fait.
D'autant plus que dans le premier cas la syntaxe est commune à tous les
unix.
Oui mais bon ça ne marche pas bien pour tous les cas modernes.
Par exemple comment déclarer une tache cron qui dépendrait du lancement
d'un autre service.
J'ai par exemple le cas d'un cluster actif/passif de serveurs webs :
faire les tâches de maintenances du serveur n'est utile que si le
serveur est actif sur la machine.
Ce sont des cas qui n'existaient pas il y a 10 ans...
Donc oui c'était plus simple avant... mais on faisait tellement moins de
choses avant...
C'est faux. Simplement, les choses complexes se faisaient avec des
cascades d'outils simples et canoniques, ce qui correspond à la
philosophie unix depuis ses débuts.
Les clusters existaient il y a 10 ans, et on faisait des choses
compliquées avec, comme du calcul parallèle en gérant les noeuds qui
tombent en panne ou bien où le soft se plante, en relançant
automatiquement les bouts de calculs manquants sur d'autres noeuds,
etc... Il y a 20 ans, les Cray tournaient sous uniCOS et je n'oserais
pas dire qu'un Cray ne faisait pas des choses compliquées.
Vouloir centraliser les services n'est pas une mauvaise idée en soi,
mais un outil comme launchd qui prétend tout faire devient facilement
indigeste, en plus d'être limité dans la pratique à une plateforme.
Peut-être, mais entre une syntaxe où chaque tâche gérée par crond consiste en une unique ligne dans un fichier commun, et une syntaxe qui réclame un fichier de 30 lignes par tâche, mon choix est vite fait. D'autant plus que dans le premier cas la syntaxe est commune à tous les unix.
Oui mais bon ça ne marche pas bien pour tous les cas modernes.
Par exemple comment déclarer une tache cron qui dépendrait du lancement d'un autre service.
J'ai par exemple le cas d'un cluster actif/passif de serveurs webs : faire les tâches de maintenances du serveur n'est utile que si le serveur est actif sur la machine.
Ce sont des cas qui n'existaient pas il y a 10 ans...
Donc oui c'était plus simple avant... mais on faisait tellement moins de choses avant...
C'est faux. Simplement, les choses complexes se faisaient avec des cascades d'outils simples et canoniques, ce qui correspond à la philosophie unix depuis ses débuts.
Les clusters existaient il y a 10 ans, et on faisait des choses compliquées avec, comme du calcul parallèle en gérant les noeuds qui tombent en panne ou bien où le soft se plante, en relançant automatiquement les bouts de calculs manquants sur d'autres noeuds, etc... Il y a 20 ans, les Cray tournaient sous uniCOS et je n'oserais pas dire qu'un Cray ne faisait pas des choses compliquées.
Vouloir centraliser les services n'est pas une mauvaise idée en soi, mais un outil comme launchd qui prétend tout faire devient facilement indigeste, en plus d'être limité dans la pratique à une plateforme.
-- pehache
yapu
FiLH wrote:
> Juste de pas se fatiguer à réfléchir et d'utuiliser un bloartware comme > parser.
Ben.. je préfère réfléchir à des concepts plus amusants qu'à devoir en rester au niveau syntaxique.
d'un autre coté, c'est difficile de décrire une ontologie un peu raffinée avec un fichier à plat... -- Philippe Manet en fait, c'est manet avant @
FiLH <filh@filh.orgie> wrote:
> Juste de pas se fatiguer à réfléchir et d'utuiliser un bloartware comme
> parser.
Ben.. je préfère réfléchir à des concepts plus amusants qu'à devoir en
rester au niveau syntaxique.
d'un autre coté, c'est difficile de décrire une ontologie un peu
raffinée avec un fichier à plat...
--
Philippe Manet
en fait, c'est manet avant @