côté
de MacOS X
References: <1i69hwu.1lg9bpn1xufutcN%jc@qui.net> <1i6eo8q.1ndqnxp19kzwqhN%sebastienmarty@yahoo.fr> <471d17f1$0$5239$426a74cc@news.free.fr> <C342E7F2.B8B06%usenet@levenez.com> <471d1dad$0$22161$426a74cc@news.free.fr> <C3435108.B8B82%usenet@levenez.com> <471daa76$0$15764$426a74cc@news.free.fr>
Organization:
Reply-To: wilhelm-siegfried.knatschke-koenigsberg@chezmoi.com
Followup-To:
Le 23-10-2007, à propos de
Re: Windows est une merveille à
côté
de MacOS X,
Nicolas George écrivait dans fr.comp.os.unix :
> Eric Levenez wrote in message <C3435108.B8B82%usenet@levenez.com>:
>> Pourquoi avoir abandonné DOS ?
>
> Tu poses vraiment la question ?
>
>> Tu confonds CLI et fichiers de texte. On peut très bien avoir des outils CLI
>> qui manipulent des fichiers binaires. Cela n'est en rien incompatible avec
>> l'esprit unix comme tu sembles le croire.
>
> Je ne confonds pas du tout. Et je maintiens que le principe même d'Unix,
> c'est le fichier texte plus que les interfaces en ligne de commande.
Le fichier teste ? Dans ce cas Tru64 n'est pas un Unix, Solaris 10
n'est pas un Unix (cf svcadm), Solaris 9 non plus d'ailleurs, HP-UX,
n'en parlons pas. Maintenant, si on colle là dedans le serveur X,
tout ce qui utilise de près ou de loin gtk n'en est pas non plus (cf
gconf2).
Cordialement,
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Dans ce cas Tru64 n'est pas un Unix, Solaris 10 n'est pas un Unix (cf svcadm), Solaris 9 non plus d'ailleurs, HP-UX, n'en parlons pas.
Tu peux préciser à quoi tu penses ?
Maintenant, si on colle là dedans le serveur X, tout ce qui utilise de près ou de loin gtk n'en est pas non plus
Je parlais de la couche de base de l'administration du système.
(cf gconf2).
Gconf est une horreur, à mon avis. Ceci dit, tu te plantes en faisant un lien entre Gconf et Gtk+.
JKB
Le 23-10-2007, à propos de Re: Windows est une merveille à, Nicolas George écrivait dans fr.comp.os.unix :
JKB wrote in message :
Le fichier teste ?
Non, texte.
Dans ce cas Tru64 n'est pas un Unix, Solaris 10 n'est pas un Unix (cf svcadm), Solaris 9 non plus d'ailleurs, HP-UX, n'en parlons pas.
Tu peux préciser à quoi tu penses ?
À la couche de démarrage /etc/rc?.d qui a été changée par un truc SQL-lite abscons qui fait qu'on ne sait _jamais_ si tel ou tel truc est démarré (pour Solaris10). Je ne vais pas faire la liste exhaustive. Essaye simplement de lancer un daemon ntp sous Solaris10 pour voir.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 23-10-2007, à propos de
Re: Windows est une merveille à,
Nicolas George écrivait dans fr.comp.os.unix :
JKB wrote in message <slrnfhrcgp.kuq.knatschke@fermat.systella.fr>:
Le fichier teste ?
Non, texte.
Dans ce cas Tru64 n'est pas un Unix, Solaris 10
n'est pas un Unix (cf svcadm), Solaris 9 non plus d'ailleurs, HP-UX,
n'en parlons pas.
Tu peux préciser à quoi tu penses ?
À la couche de démarrage /etc/rc?.d qui a été changée par un truc
SQL-lite abscons qui fait qu'on ne sait _jamais_ si tel ou tel truc
est démarré (pour Solaris10). Je ne vais pas faire la liste
exhaustive. Essaye simplement de lancer un daemon ntp sous Solaris10
pour voir.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 23-10-2007, à propos de Re: Windows est une merveille à, Nicolas George écrivait dans fr.comp.os.unix :
JKB wrote in message :
Le fichier teste ?
Non, texte.
Dans ce cas Tru64 n'est pas un Unix, Solaris 10 n'est pas un Unix (cf svcadm), Solaris 9 non plus d'ailleurs, HP-UX, n'en parlons pas.
Tu peux préciser à quoi tu penses ?
À la couche de démarrage /etc/rc?.d qui a été changée par un truc SQL-lite abscons qui fait qu'on ne sait _jamais_ si tel ou tel truc est démarré (pour Solaris10). Je ne vais pas faire la liste exhaustive. Essaye simplement de lancer un daemon ntp sous Solaris10 pour voir.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Nicolas George
JKB wrote in message :
À la couche de démarrage /etc/rc?.d qui a été changée par un truc SQL-lite abscons qui fait qu'on ne sait _jamais_ si tel ou tel truc est démarré (pour Solaris10). Je ne vais pas faire la liste exhaustive. Essaye simplement de lancer un daemon ntp sous Solaris10 pour voir.
Ah, beurk. Quels crétins.
JKB wrote in message <slrnfhsd4k.kuq.knatschke@fermat.systella.fr>:
À la couche de démarrage /etc/rc?.d qui a été changée par un truc
SQL-lite abscons qui fait qu'on ne sait _jamais_ si tel ou tel truc
est démarré (pour Solaris10). Je ne vais pas faire la liste
exhaustive. Essaye simplement de lancer un daemon ntp sous Solaris10
pour voir.
À la couche de démarrage /etc/rc?.d qui a été changée par un truc SQL-lite abscons qui fait qu'on ne sait _jamais_ si tel ou tel truc est démarré (pour Solaris10). Je ne vais pas faire la liste exhaustive. Essaye simplement de lancer un daemon ntp sous Solaris10 pour voir.
Ah, beurk. Quels crétins.
Marc
JKB wrote:
À la couche de démarrage /etc/rc?.d qui a été changée par un truc SQL-lite abscons qui fait qu'on ne sait _jamais_ si tel ou tel truc est démarré (pour Solaris10).
Ben il y a une commande toute simple pour demander si un truc tourne ou pas. Et si on veut éviter d'avoir un boot qui prend trois siècles sur un T1000 parce que les scripts de boot sont exécutés séquentiellement, il faut bien exprimer les dépendances entre services, et /etc/rc?.d n'est pas super pratique pour ça. En principe ça permet même de relancer automatiquement un service qui plante, et éventuellement tous ceux qui en dépendent (c'était dans la pub en tout cas, je n'ai jamais eu l'occasion de tester ça).
S'il y a un truc que je reproche à solaris, c'est plutôt d'utiliser justement un fichier texte au lieu d'une base de données pour son gestionnaire de packages, ce qui rend les opérations dessus infiniment lente et augmente les risques de casse. Le seul avantage c'est qu'on peut utiliser grep dessus quand on a oublié le nom de la bonne commande pkg*.
JKB wrote:
À la couche de démarrage /etc/rc?.d qui a été changée par un truc
SQL-lite abscons qui fait qu'on ne sait _jamais_ si tel ou tel truc
est démarré (pour Solaris10).
Ben il y a une commande toute simple pour demander si un truc tourne ou
pas. Et si on veut éviter d'avoir un boot qui prend trois siècles sur un
T1000 parce que les scripts de boot sont exécutés séquentiellement, il
faut bien exprimer les dépendances entre services, et /etc/rc?.d n'est
pas super pratique pour ça. En principe ça permet même de relancer
automatiquement un service qui plante, et éventuellement tous ceux qui en
dépendent (c'était dans la pub en tout cas, je n'ai jamais eu l'occasion
de tester ça).
S'il y a un truc que je reproche à solaris, c'est plutôt d'utiliser
justement un fichier texte au lieu d'une base de données pour son
gestionnaire de packages, ce qui rend les opérations dessus infiniment
lente et augmente les risques de casse. Le seul avantage c'est qu'on peut
utiliser grep dessus quand on a oublié le nom de la bonne commande pkg*.
À la couche de démarrage /etc/rc?.d qui a été changée par un truc SQL-lite abscons qui fait qu'on ne sait _jamais_ si tel ou tel truc est démarré (pour Solaris10).
Ben il y a une commande toute simple pour demander si un truc tourne ou pas. Et si on veut éviter d'avoir un boot qui prend trois siècles sur un T1000 parce que les scripts de boot sont exécutés séquentiellement, il faut bien exprimer les dépendances entre services, et /etc/rc?.d n'est pas super pratique pour ça. En principe ça permet même de relancer automatiquement un service qui plante, et éventuellement tous ceux qui en dépendent (c'était dans la pub en tout cas, je n'ai jamais eu l'occasion de tester ça).
S'il y a un truc que je reproche à solaris, c'est plutôt d'utiliser justement un fichier texte au lieu d'une base de données pour son gestionnaire de packages, ce qui rend les opérations dessus infiniment lente et augmente les risques de casse. Le seul avantage c'est qu'on peut utiliser grep dessus quand on a oublié le nom de la bonne commande pkg*.
