Je sais que je vais faire bondir tout les macounets, mais on me prête en
ce moment un PC portable Dell pour faire certains travaux et je suis
agréablement surpris : l'affichage est d'une netteté dont je rêvais
depuis l'abandon par Apple de son système 9. Les icônes me semblent des
petits bijoux à côté des icônes floues de MacOSX. Pour déplacer ou
copier des fichiers ou des dossiers il y a un dialogue qui affiche le
chemin. Plus besoin de cirer le bureau avec la souris (je ne me ferai de
toute façon jamais aux trackpads). Tout est d'une clarté lumineuse. Avec
de bons antivirus, on ne risque pas plus que sur Mac. Bref, je suis
conquis. Au point de reporter à une date ultérieure l'achat d'un MacBook
Pro 17 pouces que je voulais faire : pas de pavé numérique et de plus
j'attends les disques flash.
Mieux, si je peux trouver toutes mes applications professionnelles sur
PC je crois que je vais faire le grand saut du «côté sombre» (pour
certains, si vous voyez ce que je veux dire). Alors, adieu Apple, tu
m'as suffisamment emmerdé avec ton système 10 pourri !
La question est : selon la définition dudit monsieur, a-t-il même jamais existé de véritable Unix ?
Une Debian ou un FreeBSD rentrent parfaitement dans le cadre que j'ai décrit.
Nicolas George
Nicolas MICHEL wrote in message <1i6hlbp.d12we6o58wpsN%Nicolas-MICHEL'_remove_'@bluewin.ch>:
Sur RedHat tu tapes uname ça te dis Linux.
Et le système, c'est RedHat, pas Linux.
Sous Mac comme sous Linux, quand je modifies la crontab de root j'utilises /usr/bin/crontab. C'est la procédure recommandée.
Ce n'est pas de l'administration. L'administration, c'est quand on édite la crontab du système. Ce qui se fait, sous un Unix normalement constitué, en éditant /etc/crontab ou un fichier qu'il inclue.
Sous linux, mais maheureusement pas sous mac, quand je monte un raid je tapes "mdadm --create", je ne modifies pas un fichier texte.
C'est vrai, mais les manipulations touchant aux systèmes de fichiers et à ce qu'il y a en dessous font exception par la force des choses.
Exactement dans la même idée, quand je modifies un user sur Mac je prends nicl et sur Linux useradd userdel, usermod.
Tu utilises ce que tu veux, mais useradd et compagnie ne sont que des outils simplifiés pour éditer /etc/passwd et /etc/shadow, qui sont des fichiers texte et parfaitement éditables directement.
Que les données soient dans un fichier texte ou dans une db, dans le fond ça change quoi ? C'est pas le bon usage de "unix à l'usage" ? Et pourquoi pas ?
Ce que ça change, c'est que c'est une interface unifiée et auto-documentée, pour laquelle on a des outils généralistes extrêmement puissants (Perl, Git, etc.).
Si chaque partie du système utilise son propre format, même s'il y a des interfaces pour y accéder, ce sont à chaque fois des interfaces différentes, et faire des outils transversaux devient tout de suite plus fastidieux.
Nicolas MICHEL wrote in message
<1i6hlbp.d12we6o58wpsN%Nicolas-MICHEL'_remove_'@bluewin.ch>:
Sur RedHat tu tapes uname ça te dis Linux.
Et le système, c'est RedHat, pas Linux.
Sous Mac comme sous Linux, quand je modifies la crontab de root
j'utilises /usr/bin/crontab. C'est la procédure recommandée.
Ce n'est pas de l'administration. L'administration, c'est quand on édite la
crontab du système. Ce qui se fait, sous un Unix normalement constitué, en
éditant /etc/crontab ou un fichier qu'il inclue.
Sous linux, mais maheureusement pas sous mac, quand je monte un raid je
tapes "mdadm --create", je ne modifies pas un fichier texte.
C'est vrai, mais les manipulations touchant aux systèmes de fichiers et à ce
qu'il y a en dessous font exception par la force des choses.
Exactement dans la même idée, quand je modifies un user sur Mac je
prends nicl et sur Linux useradd userdel, usermod.
Tu utilises ce que tu veux, mais useradd et compagnie ne sont que des outils
simplifiés pour éditer /etc/passwd et /etc/shadow, qui sont des fichiers
texte et parfaitement éditables directement.
Que les données soient dans un fichier texte ou dans une db, dans le
fond ça change quoi ? C'est pas le bon usage de "unix à l'usage" ?
Et pourquoi pas ?
Ce que ça change, c'est que c'est une interface unifiée et auto-documentée,
pour laquelle on a des outils généralistes extrêmement puissants (Perl, Git,
etc.).
Si chaque partie du système utilise son propre format, même s'il y a des
interfaces pour y accéder, ce sont à chaque fois des interfaces différentes,
et faire des outils transversaux devient tout de suite plus fastidieux.
Nicolas MICHEL wrote in message <1i6hlbp.d12we6o58wpsN%Nicolas-MICHEL'_remove_'@bluewin.ch>:
Sur RedHat tu tapes uname ça te dis Linux.
Et le système, c'est RedHat, pas Linux.
Sous Mac comme sous Linux, quand je modifies la crontab de root j'utilises /usr/bin/crontab. C'est la procédure recommandée.
Ce n'est pas de l'administration. L'administration, c'est quand on édite la crontab du système. Ce qui se fait, sous un Unix normalement constitué, en éditant /etc/crontab ou un fichier qu'il inclue.
Sous linux, mais maheureusement pas sous mac, quand je monte un raid je tapes "mdadm --create", je ne modifies pas un fichier texte.
C'est vrai, mais les manipulations touchant aux systèmes de fichiers et à ce qu'il y a en dessous font exception par la force des choses.
Exactement dans la même idée, quand je modifies un user sur Mac je prends nicl et sur Linux useradd userdel, usermod.
Tu utilises ce que tu veux, mais useradd et compagnie ne sont que des outils simplifiés pour éditer /etc/passwd et /etc/shadow, qui sont des fichiers texte et parfaitement éditables directement.
Que les données soient dans un fichier texte ou dans une db, dans le fond ça change quoi ? C'est pas le bon usage de "unix à l'usage" ? Et pourquoi pas ?
Ce que ça change, c'est que c'est une interface unifiée et auto-documentée, pour laquelle on a des outils généralistes extrêmement puissants (Perl, Git, etc.).
Si chaque partie du système utilise son propre format, même s'il y a des interfaces pour y accéder, ce sont à chaque fois des interfaces différentes, et faire des outils transversaux devient tout de suite plus fastidieux.
Nicolas George
Nicolas MICHEL wrote in message <1i6hlbp.d12we6o58wpsN%Nicolas-MICHEL'_remove_'@bluewin.ch>:
Sur RedHat tu tapes uname ça te dis Linux.
Et le système, c'est RedHat, pas Linux.
Sous Mac comme sous Linux, quand je modifies la crontab de root j'utilises /usr/bin/crontab. C'est la procédure recommandée.
Ce n'est pas de l'administration. L'administration, c'est quand on édite la crontab du système. Ce qui se fait, sous un Unix normalement constitué, en éditant /etc/crontab ou un fichier qu'il inclue.
Sous linux, mais maheureusement pas sous mac, quand je monte un raid je tapes "mdadm --create", je ne modifies pas un fichier texte.
C'est vrai, mais les manipulations touchant aux systèmes de fichiers et à ce qu'il y a en dessous font exception par la force des choses.
Exactement dans la même idée, quand je modifies un user sur Mac je prends nicl et sur Linux useradd userdel, usermod.
Tu utilises ce que tu veux, mais useradd et compagnie ne sont que des outils simplifiés pour éditer /etc/passwd et /etc/shadow, qui sont des fichiers texte et parfaitement éditables directement.
Que les données soient dans un fichier texte ou dans une db, dans le fond ça change quoi ? C'est pas le bon usage de "unix à l'usage" ? Et pourquoi pas ?
Ce que ça change, c'est que c'est une interface unifiée et auto-documentée, pour laquelle on a des outils généralistes extrêmement puissants (Perl, Git, etc.).
Si chaque partie du système utilise son propre format, même s'il y a des interfaces pour y accéder, ce sont à chaque fois des interfaces différentes, et faire des outils transversaux devient tout de suite plus fastidieux.
Nicolas MICHEL wrote in message
<1i6hlbp.d12we6o58wpsN%Nicolas-MICHEL'_remove_'@bluewin.ch>:
Sur RedHat tu tapes uname ça te dis Linux.
Et le système, c'est RedHat, pas Linux.
Sous Mac comme sous Linux, quand je modifies la crontab de root
j'utilises /usr/bin/crontab. C'est la procédure recommandée.
Ce n'est pas de l'administration. L'administration, c'est quand on édite la
crontab du système. Ce qui se fait, sous un Unix normalement constitué, en
éditant /etc/crontab ou un fichier qu'il inclue.
Sous linux, mais maheureusement pas sous mac, quand je monte un raid je
tapes "mdadm --create", je ne modifies pas un fichier texte.
C'est vrai, mais les manipulations touchant aux systèmes de fichiers et à ce
qu'il y a en dessous font exception par la force des choses.
Exactement dans la même idée, quand je modifies un user sur Mac je
prends nicl et sur Linux useradd userdel, usermod.
Tu utilises ce que tu veux, mais useradd et compagnie ne sont que des outils
simplifiés pour éditer /etc/passwd et /etc/shadow, qui sont des fichiers
texte et parfaitement éditables directement.
Que les données soient dans un fichier texte ou dans une db, dans le
fond ça change quoi ? C'est pas le bon usage de "unix à l'usage" ?
Et pourquoi pas ?
Ce que ça change, c'est que c'est une interface unifiée et auto-documentée,
pour laquelle on a des outils généralistes extrêmement puissants (Perl, Git,
etc.).
Si chaque partie du système utilise son propre format, même s'il y a des
interfaces pour y accéder, ce sont à chaque fois des interfaces différentes,
et faire des outils transversaux devient tout de suite plus fastidieux.
Nicolas MICHEL wrote in message <1i6hlbp.d12we6o58wpsN%Nicolas-MICHEL'_remove_'@bluewin.ch>:
Sur RedHat tu tapes uname ça te dis Linux.
Et le système, c'est RedHat, pas Linux.
Sous Mac comme sous Linux, quand je modifies la crontab de root j'utilises /usr/bin/crontab. C'est la procédure recommandée.
Ce n'est pas de l'administration. L'administration, c'est quand on édite la crontab du système. Ce qui se fait, sous un Unix normalement constitué, en éditant /etc/crontab ou un fichier qu'il inclue.
Sous linux, mais maheureusement pas sous mac, quand je monte un raid je tapes "mdadm --create", je ne modifies pas un fichier texte.
C'est vrai, mais les manipulations touchant aux systèmes de fichiers et à ce qu'il y a en dessous font exception par la force des choses.
Exactement dans la même idée, quand je modifies un user sur Mac je prends nicl et sur Linux useradd userdel, usermod.
Tu utilises ce que tu veux, mais useradd et compagnie ne sont que des outils simplifiés pour éditer /etc/passwd et /etc/shadow, qui sont des fichiers texte et parfaitement éditables directement.
Que les données soient dans un fichier texte ou dans une db, dans le fond ça change quoi ? C'est pas le bon usage de "unix à l'usage" ? Et pourquoi pas ?
Ce que ça change, c'est que c'est une interface unifiée et auto-documentée, pour laquelle on a des outils généralistes extrêmement puissants (Perl, Git, etc.).
Si chaque partie du système utilise son propre format, même s'il y a des interfaces pour y accéder, ce sont à chaque fois des interfaces différentes, et faire des outils transversaux devient tout de suite plus fastidieux.
pas.de.spam
SbM wrote:
Nicolas George <nicolas$ wrote:
Voilà. Tout ça, ce n'est pas Unix.
C'est donc bien ce que je pensais : tu as une conception rétrograde, passéiste et figée des systèmes Unix. Ce n'est pas la mienne.
c'est bien ce que je disais quand je parlais de marcher à pieds et de faire du feu avec du silex.
-- PO.
Pour m'écrire : po_taubaty(arobas)yahoo(point)fr
SbM <sebastienmarty@yahoo.fr> wrote:
Nicolas George <nicolas$george@salle-s.org> wrote:
Voilà. Tout ça, ce n'est pas Unix.
C'est donc bien ce que je pensais : tu as une conception rétrograde,
passéiste et figée des systèmes Unix. Ce n'est pas la mienne.
c'est bien ce que je disais quand je parlais de marcher à pieds et de
faire du feu avec du silex.
C'est donc bien ce que je pensais : tu as une conception rétrograde, passéiste et figée des systèmes Unix. Ce n'est pas la mienne.
c'est bien ce que je disais quand je parlais de marcher à pieds et de faire du feu avec du silex.
-- PO.
Pour m'écrire : po_taubaty(arobas)yahoo(point)fr
laurent.pertois
Pierre-Olivier TAUBATY wrote:
Laurent Pertois wrote:
jean-pierre poindessault wrote:
Si l'écran TFT n'est pas utilisé a sa résolution native, c'est flou.
Non, si j'ai un écran dont la résolution native est de 1600x1200 il ne sera pas flou en 800x600, tout sera juste monstrueusement gros.
et surtout beaucoup moins net :-) , en tout cas c'est l'impression que cela donne.
Oui, mais pas flou comme quand tu mets une résolution inadaptée
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Si l'écran TFT n'est pas utilisé a sa résolution native, c'est flou.
Non, si j'ai un écran dont la résolution native est de 1600x1200 il ne
sera pas flou en 800x600, tout sera juste monstrueusement gros.
et surtout beaucoup moins net :-) , en tout cas c'est l'impression que
cela donne.
Oui, mais pas flou comme quand tu mets une résolution inadaptée
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Si l'écran TFT n'est pas utilisé a sa résolution native, c'est flou.
Non, si j'ai un écran dont la résolution native est de 1600x1200 il ne sera pas flou en 800x600, tout sera juste monstrueusement gros.
et surtout beaucoup moins net :-) , en tout cas c'est l'impression que cela donne.
Oui, mais pas flou comme quand tu mets une résolution inadaptée
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
FiLH
(Laurent Pertois) writes:
Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> wrote:
FiLH wrote:
Bah, le xml c'est encore assez utilisable, bon, un peu reloud parce que les mecs qui ont fait la norme ils savaient pas compter les parenthèses fermantes...
Ce que je trouve relou, c'est surtout l'absence de commentaires dans la totalité des fichiers .plist d'Apple et dans ce sens je donne un peu raison à Nicolas George, ils ne sont pas conçu dans l'optique d'une administration purement en cli. Le faire demande un peu plus d'effort.
C'est vrai que quand je regarde le named.conf d'un BIND je suis agressé par les commentaires...
Alors qu'un sendmail.cf issus de m4... ben y a des commentaires !!!
Mais avec un bon xmllint derrière on arrive à jouer :)
Intéressant. Tu utilises ça comment ? J'ai survolé, pas compris. Tu peux éditer ton .plist avec ça et le modifier ?
Je pense que FiLH pensait surtout aux options permettant de vérifier la syntaxe XML après édition.
Yes...
FiLH
-- FiLH photography. A taste of freedom in a conventional world. Web: http://www.filh.org e-mail FAQ fr.rec.photo : http://frp.parisv.com/ Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> wrote:
FiLH <filh@filh.orgie> wrote:
Bah, le xml c'est encore assez utilisable, bon, un peu reloud parce que
les mecs qui ont fait la norme ils savaient pas compter les parenthèses
fermantes...
Ce que je trouve relou, c'est surtout l'absence de commentaires dans la
totalité des fichiers .plist d'Apple et dans ce sens je donne un peu
raison à Nicolas George, ils ne sont pas conçu dans l'optique d'une
administration purement en cli. Le faire demande un peu plus d'effort.
C'est vrai que quand je regarde le named.conf d'un BIND je suis agressé
par les commentaires...
Alors qu'un sendmail.cf issus de m4... ben y a des commentaires !!!
Mais avec un bon xmllint derrière on arrive à jouer :)
Intéressant. Tu utilises ça comment ?
J'ai survolé, pas compris.
Tu peux éditer ton .plist avec ça et le modifier ?
Je pense que FiLH pensait surtout aux options permettant de vérifier la
syntaxe XML après édition.
Yes...
FiLH
--
FiLH photography. A taste of freedom in a conventional world.
Web: http://www.filh.org e-mail filh@filh.org
FAQ fr.rec.photo : http://frp.parisv.com/
Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> wrote:
FiLH wrote:
Bah, le xml c'est encore assez utilisable, bon, un peu reloud parce que les mecs qui ont fait la norme ils savaient pas compter les parenthèses fermantes...
Ce que je trouve relou, c'est surtout l'absence de commentaires dans la totalité des fichiers .plist d'Apple et dans ce sens je donne un peu raison à Nicolas George, ils ne sont pas conçu dans l'optique d'une administration purement en cli. Le faire demande un peu plus d'effort.
C'est vrai que quand je regarde le named.conf d'un BIND je suis agressé par les commentaires...
Alors qu'un sendmail.cf issus de m4... ben y a des commentaires !!!
Mais avec un bon xmllint derrière on arrive à jouer :)
Intéressant. Tu utilises ça comment ? J'ai survolé, pas compris. Tu peux éditer ton .plist avec ça et le modifier ?
Je pense que FiLH pensait surtout aux options permettant de vérifier la syntaxe XML après édition.
Yes...
FiLH
-- FiLH photography. A taste of freedom in a conventional world. Web: http://www.filh.org e-mail FAQ fr.rec.photo : http://frp.parisv.com/ Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
FiLH
(Laurent Pertois) writes:
Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> wrote:
FiLH wrote:
Bah, le xml c'est encore assez utilisable, bon, un peu reloud parce que les mecs qui ont fait la norme ils savaient pas compter les parenthèses fermantes...
Ce que je trouve relou, c'est surtout l'absence de commentaires dans la totalité des fichiers .plist d'Apple et dans ce sens je donne un peu raison à Nicolas George, ils ne sont pas conçu dans l'optique d'une administration purement en cli. Le faire demande un peu plus d'effort.
C'est vrai que quand je regarde le named.conf d'un BIND je suis agressé par les commentaires...
Alors qu'un sendmail.cf issus de m4... ben y a des commentaires !!!
Mais avec un bon xmllint derrière on arrive à jouer :)
Intéressant. Tu utilises ça comment ? J'ai survolé, pas compris. Tu peux éditer ton .plist avec ça et le modifier ?
Je pense que FiLH pensait surtout aux options permettant de vérifier la syntaxe XML après édition.
Yes...
FiLH
-- FiLH photography. A taste of freedom in a conventional world. Web: http://www.filh.org e-mail FAQ fr.rec.photo : http://frp.parisv.com/ Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> wrote:
FiLH <filh@filh.orgie> wrote:
Bah, le xml c'est encore assez utilisable, bon, un peu reloud parce que
les mecs qui ont fait la norme ils savaient pas compter les parenthèses
fermantes...
Ce que je trouve relou, c'est surtout l'absence de commentaires dans la
totalité des fichiers .plist d'Apple et dans ce sens je donne un peu
raison à Nicolas George, ils ne sont pas conçu dans l'optique d'une
administration purement en cli. Le faire demande un peu plus d'effort.
C'est vrai que quand je regarde le named.conf d'un BIND je suis agressé
par les commentaires...
Alors qu'un sendmail.cf issus de m4... ben y a des commentaires !!!
Mais avec un bon xmllint derrière on arrive à jouer :)
Intéressant. Tu utilises ça comment ?
J'ai survolé, pas compris.
Tu peux éditer ton .plist avec ça et le modifier ?
Je pense que FiLH pensait surtout aux options permettant de vérifier la
syntaxe XML après édition.
Yes...
FiLH
--
FiLH photography. A taste of freedom in a conventional world.
Web: http://www.filh.org e-mail filh@filh.org
FAQ fr.rec.photo : http://frp.parisv.com/
Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
Nicolas MICHEL <Nicolas-MICHEL'_remove_'@bluewin.ch> wrote:
FiLH wrote:
Bah, le xml c'est encore assez utilisable, bon, un peu reloud parce que les mecs qui ont fait la norme ils savaient pas compter les parenthèses fermantes...
Ce que je trouve relou, c'est surtout l'absence de commentaires dans la totalité des fichiers .plist d'Apple et dans ce sens je donne un peu raison à Nicolas George, ils ne sont pas conçu dans l'optique d'une administration purement en cli. Le faire demande un peu plus d'effort.
C'est vrai que quand je regarde le named.conf d'un BIND je suis agressé par les commentaires...
Alors qu'un sendmail.cf issus de m4... ben y a des commentaires !!!
Mais avec un bon xmllint derrière on arrive à jouer :)
Intéressant. Tu utilises ça comment ? J'ai survolé, pas compris. Tu peux éditer ton .plist avec ça et le modifier ?
Je pense que FiLH pensait surtout aux options permettant de vérifier la syntaxe XML après édition.
Yes...
FiLH
-- FiLH photography. A taste of freedom in a conventional world. Web: http://www.filh.org e-mail FAQ fr.rec.photo : http://frp.parisv.com/ Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
Nicolas-MICHEL'_remove_'
Nicolas George <nicolas$ wrote:
Ce que ça change, c'est que c'est une interface unifiée et auto-documentée, pour laquelle on a des outils généralistes extrêmement puissants (Perl, Git, etc.)
Sur un parc de 200 machines, un seul directory ldap est plus puissant et plus unifié que 20'000 fichiers disparates ayant chacun sa propre syntaxe qui t'obligent à développer ton propre système de maintenance, déployement et gestion.
Dureste même sur une unique machine, directory access et ses composants permetent précisément d'unifier une bonne partie de la gestion de la machine. Mais bon, ...
Si chaque partie du système utilise son propre format, même s'il y a des interfaces pour y accéder, ce sont à chaque fois des interfaces différentes, et faire des outils transversaux devient tout de suite plus fastidieux.
Pour administrer un service sur linux tu peux utiliser /etc/init.d, xinetd, /etc/rc, cron ou encore un loginscript. C'est précisément pour unifier ça que Apple a développé launchd. Ton argumentation ne tient pas la route.
De toutes façon Apple n'est pas pour toi : ils inovent. Mais ce serait plus corect de ta part de ne pas t'approprier la notion de Unix et de ne pas en exclure toute nouveauté qui viendrait déranger tes habitudes. -- Nicolas - MICHEL at bluewin point ch AIM : michelnicolas
Nicolas George <nicolas$george@salle-s.org> wrote:
Ce que ça change, c'est que c'est une interface unifiée et auto-documentée,
pour laquelle on a des outils généralistes extrêmement puissants (Perl, Git,
etc.)
Sur un parc de 200 machines, un seul directory ldap est plus puissant et
plus unifié que 20'000 fichiers disparates ayant chacun sa propre
syntaxe qui t'obligent à développer ton propre système de maintenance,
déployement et gestion.
Dureste même sur une unique machine, directory access et ses composants
permetent précisément d'unifier une bonne partie de la gestion de la
machine. Mais bon, ...
Si chaque partie du système utilise son propre format, même s'il y a des
interfaces pour y accéder, ce sont à chaque fois des interfaces différentes,
et faire des outils transversaux devient tout de suite plus fastidieux.
Pour administrer un service sur linux tu peux utiliser /etc/init.d,
xinetd, /etc/rc, cron ou encore un loginscript.
C'est précisément pour unifier ça que Apple a développé launchd.
Ton argumentation ne tient pas la route.
De toutes façon Apple n'est pas pour toi : ils inovent.
Mais ce serait plus corect de ta part de ne pas t'approprier la notion
de Unix et de ne pas en exclure toute nouveauté qui viendrait déranger
tes habitudes.
--
Nicolas - MICHEL at bluewin point ch
AIM : michelnicolas
Ce que ça change, c'est que c'est une interface unifiée et auto-documentée, pour laquelle on a des outils généralistes extrêmement puissants (Perl, Git, etc.)
Sur un parc de 200 machines, un seul directory ldap est plus puissant et plus unifié que 20'000 fichiers disparates ayant chacun sa propre syntaxe qui t'obligent à développer ton propre système de maintenance, déployement et gestion.
Dureste même sur une unique machine, directory access et ses composants permetent précisément d'unifier une bonne partie de la gestion de la machine. Mais bon, ...
Si chaque partie du système utilise son propre format, même s'il y a des interfaces pour y accéder, ce sont à chaque fois des interfaces différentes, et faire des outils transversaux devient tout de suite plus fastidieux.
Pour administrer un service sur linux tu peux utiliser /etc/init.d, xinetd, /etc/rc, cron ou encore un loginscript. C'est précisément pour unifier ça que Apple a développé launchd. Ton argumentation ne tient pas la route.
De toutes façon Apple n'est pas pour toi : ils inovent. Mais ce serait plus corect de ta part de ne pas t'approprier la notion de Unix et de ne pas en exclure toute nouveauté qui viendrait déranger tes habitudes. -- Nicolas - MICHEL at bluewin point ch AIM : michelnicolas
Nicolas-MICHEL'_remove_'
Nicolas George <nicolas$ wrote:
Ce que ça change, c'est que c'est une interface unifiée et auto-documentée, pour laquelle on a des outils généralistes extrêmement puissants (Perl, Git, etc.)
Sur un parc de 200 machines, un seul directory ldap est plus puissant et plus unifié que 20'000 fichiers disparates ayant chacun sa propre syntaxe qui t'obligent à développer ton propre système de maintenance, déployement et gestion.
Dureste même sur une unique machine, directory access et ses composants permetent précisément d'unifier une bonne partie de la gestion de la machine. Mais bon, ...
Si chaque partie du système utilise son propre format, même s'il y a des interfaces pour y accéder, ce sont à chaque fois des interfaces différentes, et faire des outils transversaux devient tout de suite plus fastidieux.
Pour administrer un service sur linux tu peux utiliser /etc/init.d, xinetd, /etc/rc, cron ou encore un loginscript. C'est précisément pour unifier ça que Apple a développé launchd. Ton argumentation ne tient pas la route.
De toutes façon Apple n'est pas pour toi : ils inovent. Mais ce serait plus corect de ta part de ne pas t'approprier la notion de Unix et de ne pas en exclure toute nouveauté qui viendrait déranger tes habitudes. -- Nicolas - MICHEL at bluewin point ch AIM : michelnicolas
Nicolas George <nicolas$george@salle-s.org> wrote:
Ce que ça change, c'est que c'est une interface unifiée et auto-documentée,
pour laquelle on a des outils généralistes extrêmement puissants (Perl, Git,
etc.)
Sur un parc de 200 machines, un seul directory ldap est plus puissant et
plus unifié que 20'000 fichiers disparates ayant chacun sa propre
syntaxe qui t'obligent à développer ton propre système de maintenance,
déployement et gestion.
Dureste même sur une unique machine, directory access et ses composants
permetent précisément d'unifier une bonne partie de la gestion de la
machine. Mais bon, ...
Si chaque partie du système utilise son propre format, même s'il y a des
interfaces pour y accéder, ce sont à chaque fois des interfaces différentes,
et faire des outils transversaux devient tout de suite plus fastidieux.
Pour administrer un service sur linux tu peux utiliser /etc/init.d,
xinetd, /etc/rc, cron ou encore un loginscript.
C'est précisément pour unifier ça que Apple a développé launchd.
Ton argumentation ne tient pas la route.
De toutes façon Apple n'est pas pour toi : ils inovent.
Mais ce serait plus corect de ta part de ne pas t'approprier la notion
de Unix et de ne pas en exclure toute nouveauté qui viendrait déranger
tes habitudes.
--
Nicolas - MICHEL at bluewin point ch
AIM : michelnicolas
Ce que ça change, c'est que c'est une interface unifiée et auto-documentée, pour laquelle on a des outils généralistes extrêmement puissants (Perl, Git, etc.)
Sur un parc de 200 machines, un seul directory ldap est plus puissant et plus unifié que 20'000 fichiers disparates ayant chacun sa propre syntaxe qui t'obligent à développer ton propre système de maintenance, déployement et gestion.
Dureste même sur une unique machine, directory access et ses composants permetent précisément d'unifier une bonne partie de la gestion de la machine. Mais bon, ...
Si chaque partie du système utilise son propre format, même s'il y a des interfaces pour y accéder, ce sont à chaque fois des interfaces différentes, et faire des outils transversaux devient tout de suite plus fastidieux.
Pour administrer un service sur linux tu peux utiliser /etc/init.d, xinetd, /etc/rc, cron ou encore un loginscript. C'est précisément pour unifier ça que Apple a développé launchd. Ton argumentation ne tient pas la route.
De toutes façon Apple n'est pas pour toi : ils inovent. Mais ce serait plus corect de ta part de ne pas t'approprier la notion de Unix et de ne pas en exclure toute nouveauté qui viendrait déranger tes habitudes. -- Nicolas - MICHEL at bluewin point ch AIM : michelnicolas
