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 !
Ce qui fait un Unix, plus que le noyau et les API, c'est la manière de l'administrer, avec l'omniprésence des fichiers en texte brut, en particulier des scripts shell. Un Unix est construit autour de la notion de fichier texte, on l'administre en éditant ces fichiers. Et si par hasard il y a des interfaces graphiques pour administrer, ce sont des frontaux sur l'édition de ces fichiers.
ce n'es pas parce que l'on a toujours fait ainsi que c'est la seule
manière de faire.
Si l'on s'en était tenu à ce raisonnement, on marcherait encore à pied parce que c'est ainsi que l'on a toujours fait,
on ferait du feu avec du silex parce que c'est ainsi que l'on a toujours fait (ou mieux, on attendrait que la foudre tombe)
et ce n'est pas parce que Mac OS X peut être utilisé sans se servir du terminal, que ce n'est pas un Unix.
c'est un Unix différent, qui n'est pas réservé à une "élite" soucieuse de préserver son "jargon", signe distinctif qui permet à ses membres de se reconnaître.
Des accros de la console, il y en a beaucoup ici. Et il ne m'a pas semblé qu'ils se sentaien handicapés par Mac OS X.
fu2 maintenu sur ici, car je ne suis pas abonné à f.C.O UNIX
-- PO.
Pour m'écrire : po_taubaty(arobas)yahoo(point)fr
Nicolas George <nicolas$george@salle-s.org> wrote:
Ce qui fait un Unix, plus que le noyau et les API, c'est la manière de
l'administrer, avec l'omniprésence des fichiers en texte brut, en
particulier des scripts shell. Un Unix est construit autour de la notion de
fichier texte, on l'administre en éditant ces fichiers. Et si par hasard il
y a des interfaces graphiques pour administrer, ce sont des frontaux sur
l'édition de ces fichiers.
ce n'es pas parce que l'on a toujours fait ainsi que c'est la seule
manière de faire.
Si l'on s'en était tenu à ce raisonnement, on marcherait encore à pied
parce que c'est ainsi que l'on a toujours fait,
on ferait du feu avec du silex parce que c'est ainsi que l'on a toujours
fait (ou mieux, on attendrait que la foudre tombe)
et ce n'est pas parce que Mac OS X peut être utilisé sans se servir du
terminal, que ce n'est pas un Unix.
c'est un Unix différent, qui n'est pas réservé à une "élite" soucieuse
de préserver son "jargon", signe distinctif qui permet à ses membres de
se reconnaître.
Des accros de la console, il y en a beaucoup ici. Et il ne m'a pas
semblé qu'ils se sentaien handicapés par Mac OS X.
fu2 maintenu sur ici, car je ne suis pas abonné à f.C.O UNIX
Ce qui fait un Unix, plus que le noyau et les API, c'est la manière de l'administrer, avec l'omniprésence des fichiers en texte brut, en particulier des scripts shell. Un Unix est construit autour de la notion de fichier texte, on l'administre en éditant ces fichiers. Et si par hasard il y a des interfaces graphiques pour administrer, ce sont des frontaux sur l'édition de ces fichiers.
ce n'es pas parce que l'on a toujours fait ainsi que c'est la seule
manière de faire.
Si l'on s'en était tenu à ce raisonnement, on marcherait encore à pied parce que c'est ainsi que l'on a toujours fait,
on ferait du feu avec du silex parce que c'est ainsi que l'on a toujours fait (ou mieux, on attendrait que la foudre tombe)
et ce n'est pas parce que Mac OS X peut être utilisé sans se servir du terminal, que ce n'est pas un Unix.
c'est un Unix différent, qui n'est pas réservé à une "élite" soucieuse de préserver son "jargon", signe distinctif qui permet à ses membres de se reconnaître.
Des accros de la console, il y en a beaucoup ici. Et il ne m'a pas semblé qu'ils se sentaien handicapés par Mac OS X.
fu2 maintenu sur ici, car je ne suis pas abonné à f.C.O UNIX
-- PO.
Pour m'écrire : po_taubaty(arobas)yahoo(point)fr
FiLH
(Pierre-Olivier TAUBATY) writes:
Nicolas George <nicolas$ wrote:
Ce qui fait un Unix, plus que le noyau et les API, c'est la manière de l'administrer, avec l'omniprésence des fichiers en texte brut, en particulier des scripts shell. Un Unix est construit autour de la notion de fichier texte, on l'administre en éditant ces fichiers. Et si par hasard il y a des interfaces graphiques pour administrer, ce sont des frontaux sur l'édition de ces fichiers.
ce n'es pas parce que l'on a toujours fait ainsi que c'est la seule
manière de faire.
Si l'on s'en était tenu à ce raisonnement, on marcherait encore à pied parce que c'est ainsi que l'on a toujours fait,
on ferait du feu avec du silex parce que c'est ainsi que l'on a toujours fait (ou mieux, on attendrait que la foudre tombe)
Question administration et informatiquement parlant, la gui est plus proche du silex que la commande line. Avec des commandes en cli on peut faire plein de scripts d'automatisation de tout.
Pas vraiment avec une gui (bon certe il y avait AppleScript mais bon... ).
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 George <nicolas$george@salle-s.org> wrote:
Ce qui fait un Unix, plus que le noyau et les API, c'est la manière de
l'administrer, avec l'omniprésence des fichiers en texte brut, en
particulier des scripts shell. Un Unix est construit autour de la notion de
fichier texte, on l'administre en éditant ces fichiers. Et si par hasard il
y a des interfaces graphiques pour administrer, ce sont des frontaux sur
l'édition de ces fichiers.
ce n'es pas parce que l'on a toujours fait ainsi que c'est la seule
manière de faire.
Si l'on s'en était tenu à ce raisonnement, on marcherait encore à pied
parce que c'est ainsi que l'on a toujours fait,
on ferait du feu avec du silex parce que c'est ainsi que l'on a toujours
fait (ou mieux, on attendrait que la foudre tombe)
Question administration et informatiquement parlant, la gui est plus
proche du silex que la commande line. Avec des commandes en cli on
peut faire plein de scripts d'automatisation de tout.
Pas vraiment avec une gui (bon certe il y avait AppleScript mais
bon... ).
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/
Ce qui fait un Unix, plus que le noyau et les API, c'est la manière de l'administrer, avec l'omniprésence des fichiers en texte brut, en particulier des scripts shell. Un Unix est construit autour de la notion de fichier texte, on l'administre en éditant ces fichiers. Et si par hasard il y a des interfaces graphiques pour administrer, ce sont des frontaux sur l'édition de ces fichiers.
ce n'es pas parce que l'on a toujours fait ainsi que c'est la seule
manière de faire.
Si l'on s'en était tenu à ce raisonnement, on marcherait encore à pied parce que c'est ainsi que l'on a toujours fait,
on ferait du feu avec du silex parce que c'est ainsi que l'on a toujours fait (ou mieux, on attendrait que la foudre tombe)
Question administration et informatiquement parlant, la gui est plus proche du silex que la commande line. Avec des commandes en cli on peut faire plein de scripts d'automatisation de tout.
Pas vraiment avec une gui (bon certe il y avait AppleScript mais bon... ).
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
(Pierre-Olivier TAUBATY) writes:
Nicolas George <nicolas$ wrote:
Ce qui fait un Unix, plus que le noyau et les API, c'est la manière de l'administrer, avec l'omniprésence des fichiers en texte brut, en particulier des scripts shell. Un Unix est construit autour de la notion de fichier texte, on l'administre en éditant ces fichiers. Et si par hasard il y a des interfaces graphiques pour administrer, ce sont des frontaux sur l'édition de ces fichiers.
ce n'es pas parce que l'on a toujours fait ainsi que c'est la seule
manière de faire.
Si l'on s'en était tenu à ce raisonnement, on marcherait encore à pied parce que c'est ainsi que l'on a toujours fait,
on ferait du feu avec du silex parce que c'est ainsi que l'on a toujours fait (ou mieux, on attendrait que la foudre tombe)
Question administration et informatiquement parlant, la gui est plus proche du silex que la commande line. Avec des commandes en cli on peut faire plein de scripts d'automatisation de tout.
Pas vraiment avec une gui (bon certe il y avait AppleScript mais bon... ).
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 George <nicolas$george@salle-s.org> wrote:
Ce qui fait un Unix, plus que le noyau et les API, c'est la manière de
l'administrer, avec l'omniprésence des fichiers en texte brut, en
particulier des scripts shell. Un Unix est construit autour de la notion de
fichier texte, on l'administre en éditant ces fichiers. Et si par hasard il
y a des interfaces graphiques pour administrer, ce sont des frontaux sur
l'édition de ces fichiers.
ce n'es pas parce que l'on a toujours fait ainsi que c'est la seule
manière de faire.
Si l'on s'en était tenu à ce raisonnement, on marcherait encore à pied
parce que c'est ainsi que l'on a toujours fait,
on ferait du feu avec du silex parce que c'est ainsi que l'on a toujours
fait (ou mieux, on attendrait que la foudre tombe)
Question administration et informatiquement parlant, la gui est plus
proche du silex que la commande line. Avec des commandes en cli on
peut faire plein de scripts d'automatisation de tout.
Pas vraiment avec une gui (bon certe il y avait AppleScript mais
bon... ).
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/
Ce qui fait un Unix, plus que le noyau et les API, c'est la manière de l'administrer, avec l'omniprésence des fichiers en texte brut, en particulier des scripts shell. Un Unix est construit autour de la notion de fichier texte, on l'administre en éditant ces fichiers. Et si par hasard il y a des interfaces graphiques pour administrer, ce sont des frontaux sur l'édition de ces fichiers.
ce n'es pas parce que l'on a toujours fait ainsi que c'est la seule
manière de faire.
Si l'on s'en était tenu à ce raisonnement, on marcherait encore à pied parce que c'est ainsi que l'on a toujours fait,
on ferait du feu avec du silex parce que c'est ainsi que l'on a toujours fait (ou mieux, on attendrait que la foudre tombe)
Question administration et informatiquement parlant, la gui est plus proche du silex que la commande line. Avec des commandes en cli on peut faire plein de scripts d'automatisation de tout.
Pas vraiment avec une gui (bon certe il y avait AppleScript mais bon... ).
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/
J.P. Poindessault
In article , Dare Dare Motus <greg@@mdr.fr> wrote:
jean-pierre poindessault a formulé ce samedi :
FAUX: la première fois qu'un utilisateur Windows se connecte au net, son antivirus n'est pas à jour, son windows non plus. Il ramasse donc a première m... venue à la première connexion. Si cette m. ... bloque les updates win et Antivirus, il est très très mal !
pfff n'importe quoi!! -----------
C'est ça, sur un parc informatique de UNE machine. Ici c'est dans le genre 300 machines et la dernière fois qu'une machine a mis le souk dès sa connection au net ça été pollution de tout le réseau université et fermeture des switches de répartition du backbone pour arrêter le déluge. Plus je ne sais combien d'heures d'intervention sur des machines nouvellement installées qui n'avaient pas leurs updates Windows à jour à quelques heures près. Ca s'appelle pas de chance, mais ça calme .
Jean-Pierre
In article <mn.ab467d7a8846e989.54688@mdr.fr>, Dare Dare Motus <greg@@mdr.fr>
wrote:
jean-pierre poindessault a formulé ce samedi :
FAUX: la première fois qu'un utilisateur Windows se connecte au net, son
antivirus n'est pas à jour, son windows non plus.
Il ramasse donc a première m... venue à la première connexion.
Si cette m. ... bloque les updates win et Antivirus, il est très très mal !
pfff n'importe quoi!!
-----------
C'est ça, sur un parc informatique de UNE machine.
Ici c'est dans le genre 300 machines et la dernière fois qu'une machine a mis le
souk dès sa connection au net ça été pollution de tout le réseau université et
fermeture des switches de répartition du backbone pour arrêter le déluge.
Plus je ne sais combien d'heures d'intervention sur des machines nouvellement
installées qui n'avaient pas leurs updates Windows à jour à quelques heures près.
Ca s'appelle pas de chance, mais ça calme .
In article , Dare Dare Motus <greg@@mdr.fr> wrote:
jean-pierre poindessault a formulé ce samedi :
FAUX: la première fois qu'un utilisateur Windows se connecte au net, son antivirus n'est pas à jour, son windows non plus. Il ramasse donc a première m... venue à la première connexion. Si cette m. ... bloque les updates win et Antivirus, il est très très mal !
pfff n'importe quoi!! -----------
C'est ça, sur un parc informatique de UNE machine. Ici c'est dans le genre 300 machines et la dernière fois qu'une machine a mis le souk dès sa connection au net ça été pollution de tout le réseau université et fermeture des switches de répartition du backbone pour arrêter le déluge. Plus je ne sais combien d'heures d'intervention sur des machines nouvellement installées qui n'avaient pas leurs updates Windows à jour à quelques heures près. Ca s'appelle pas de chance, mais ça calme .
Jean-Pierre
J.P. Poindessault
In article , Dare Dare Motus <greg@@mdr.fr> wrote:
jean-pierre poindessault a formulé ce samedi :
FAUX: la première fois qu'un utilisateur Windows se connecte au net, son antivirus n'est pas à jour, son windows non plus. Il ramasse donc a première m... venue à la première connexion. Si cette m. ... bloque les updates win et Antivirus, il est très très mal !
pfff n'importe quoi!! -----------
C'est ça, sur un parc informatique de UNE machine. Ici c'est dans le genre 300 machines et la dernière fois qu'une machine a mis le souk dès sa connection au net ça été pollution de tout le réseau université et fermeture des switches de répartition du backbone pour arrêter le déluge. Plus je ne sais combien d'heures d'intervention sur des machines nouvellement installées qui n'avaient pas leurs updates Windows à jour à quelques heures près. Ca s'appelle pas de chance, mais ça calme .
Jean-Pierre
In article <mn.ab467d7a8846e989.54688@mdr.fr>, Dare Dare Motus <greg@@mdr.fr>
wrote:
jean-pierre poindessault a formulé ce samedi :
FAUX: la première fois qu'un utilisateur Windows se connecte au net, son
antivirus n'est pas à jour, son windows non plus.
Il ramasse donc a première m... venue à la première connexion.
Si cette m. ... bloque les updates win et Antivirus, il est très très mal !
pfff n'importe quoi!!
-----------
C'est ça, sur un parc informatique de UNE machine.
Ici c'est dans le genre 300 machines et la dernière fois qu'une machine a mis le
souk dès sa connection au net ça été pollution de tout le réseau université et
fermeture des switches de répartition du backbone pour arrêter le déluge.
Plus je ne sais combien d'heures d'intervention sur des machines nouvellement
installées qui n'avaient pas leurs updates Windows à jour à quelques heures près.
Ca s'appelle pas de chance, mais ça calme .
In article , Dare Dare Motus <greg@@mdr.fr> wrote:
jean-pierre poindessault a formulé ce samedi :
FAUX: la première fois qu'un utilisateur Windows se connecte au net, son antivirus n'est pas à jour, son windows non plus. Il ramasse donc a première m... venue à la première connexion. Si cette m. ... bloque les updates win et Antivirus, il est très très mal !
pfff n'importe quoi!! -----------
C'est ça, sur un parc informatique de UNE machine. Ici c'est dans le genre 300 machines et la dernière fois qu'une machine a mis le souk dès sa connection au net ça été pollution de tout le réseau université et fermeture des switches de répartition du backbone pour arrêter le déluge. Plus je ne sais combien d'heures d'intervention sur des machines nouvellement installées qui n'avaient pas leurs updates Windows à jour à quelques heures près. Ca s'appelle pas de chance, mais ça calme .
Jean-Pierre
Eric Levenez
Le 23/10/07 10:03, dans <471daaba$0$15764$, « Nicolas George » <nicolas$ a écrit :
Jerome Vernet wrote in message <471d8973$0$5065$:
Au passage, justement, ces fichiers existent toujours sous MacOSX... Allez faire un tour dans /etc....
Certains existent toujours, mais je demande à voir si _tout_ est fait ainsi.
"_tout_" est une aberration. Même sous les unix traditionnels, "tout" n'est pas en texte. Un simple exemple : locate. L'important est de pouvoir faire ce que l'on veut en ligne de commande.
J'ai demandé ailleurs dans ce thread : la configuration du firewall, elle est dans /etc/quoi ?
Et que te donne le man d'ipfw ?
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 23/10/07 10:03, dans <471daaba$0$15764$426a74cc@news.free.fr>, « Nicolas
George » <nicolas$george@salle-s.org> a écrit :
Jerome Vernet wrote in message
<471d8973$0$5065$ba4acef3@news.orange.fr>:
Au passage, justement, ces fichiers existent toujours sous MacOSX...
Allez faire un tour dans /etc....
Certains existent toujours, mais je demande à voir si _tout_ est fait ainsi.
"_tout_" est une aberration. Même sous les unix traditionnels, "tout" n'est
pas en texte. Un simple exemple : locate. L'important est de pouvoir faire
ce que l'on veut en ligne de commande.
J'ai demandé ailleurs dans ce thread : la configuration du firewall, elle
est dans /etc/quoi ?
Et que te donne le man d'ipfw ?
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 23/10/07 10:03, dans <471daaba$0$15764$, « Nicolas George » <nicolas$ a écrit :
Jerome Vernet wrote in message <471d8973$0$5065$:
Au passage, justement, ces fichiers existent toujours sous MacOSX... Allez faire un tour dans /etc....
Certains existent toujours, mais je demande à voir si _tout_ est fait ainsi.
"_tout_" est une aberration. Même sous les unix traditionnels, "tout" n'est pas en texte. Un simple exemple : locate. L'important est de pouvoir faire ce que l'on veut en ligne de commande.
J'ai demandé ailleurs dans ce thread : la configuration du firewall, elle est dans /etc/quoi ?
Et que te donne le man d'ipfw ?
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Paul Gaborit
À (at) Tue, 23 Oct 2007 10:55:24 +0200, Eric Masson écrivait (wrote):
Nicolas George <nicolas$ writes:
Certains existent toujours, mais je demande à voir si _tout_ est fait ainsi. J'ai demandé ailleurs dans ce thread : la configuration du firewall, elle est dans /etc/quoi ?
Si ça n'a pas changé, probablement /etc/rc.firewall, un script qui se résume à l'appel de la commande ipfw(8) avec les arguments kivontbien. Iirc, ce fichier n'existe qu'à partir du moment ou le frontend de configuration a été utilisé ou qu'il a été créé à la mimine.
Oui... mais non. En fait, la configuration du firewall se fait via un outil Apple appelé FirewallTool (cf. le fichier /etc/rc) qui lit le fichier '/Library/Preferences/com.apple.sharing.firewall.plist'. C'est un fichier plist qu'on peut convertir en XML lisible via 'plutil'.
Mais cet outil (FirewallTool) ne fait que traduire les règlages fait en GUI et stockés dans le fichier plist en commandes pour ipfw.
La prise en compte d'un éventuel fichier /etc/rc.firewall ne me semble pas (plus?) prévu par défaut. Mais rien n'empêche d'ajouter son propre fichier d'ajout de règles via /etc/rc.local (à créer).
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Tue, 23 Oct 2007 10:55:24 +0200,
Eric Masson <emss@free.fr> écrivait (wrote):
Nicolas George <nicolas$george@salle-s.org> writes:
Certains existent toujours, mais je demande à voir si _tout_ est fait ainsi.
J'ai demandé ailleurs dans ce thread : la configuration du firewall, elle
est dans /etc/quoi ?
Si ça n'a pas changé, probablement /etc/rc.firewall, un script qui se
résume à l'appel de la commande ipfw(8) avec les arguments kivontbien.
Iirc, ce fichier n'existe qu'à partir du moment ou le frontend de
configuration a été utilisé ou qu'il a été créé à la mimine.
Oui... mais non. En fait, la configuration du firewall se fait via un
outil Apple appelé FirewallTool (cf. le fichier /etc/rc) qui lit le
fichier '/Library/Preferences/com.apple.sharing.firewall.plist'. C'est
un fichier plist qu'on peut convertir en XML lisible via 'plutil'.
Mais cet outil (FirewallTool) ne fait que traduire les règlages fait
en GUI et stockés dans le fichier plist en commandes pour ipfw.
La prise en compte d'un éventuel fichier /etc/rc.firewall ne me semble
pas (plus?) prévu par défaut. Mais rien n'empêche d'ajouter son propre
fichier d'ajout de règles via /etc/rc.local (à créer).
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Tue, 23 Oct 2007 10:55:24 +0200, Eric Masson écrivait (wrote):
Nicolas George <nicolas$ writes:
Certains existent toujours, mais je demande à voir si _tout_ est fait ainsi. J'ai demandé ailleurs dans ce thread : la configuration du firewall, elle est dans /etc/quoi ?
Si ça n'a pas changé, probablement /etc/rc.firewall, un script qui se résume à l'appel de la commande ipfw(8) avec les arguments kivontbien. Iirc, ce fichier n'existe qu'à partir du moment ou le frontend de configuration a été utilisé ou qu'il a été créé à la mimine.
Oui... mais non. En fait, la configuration du firewall se fait via un outil Apple appelé FirewallTool (cf. le fichier /etc/rc) qui lit le fichier '/Library/Preferences/com.apple.sharing.firewall.plist'. C'est un fichier plist qu'on peut convertir en XML lisible via 'plutil'.
Mais cet outil (FirewallTool) ne fait que traduire les règlages fait en GUI et stockés dans le fichier plist en commandes pour ipfw.
La prise en compte d'un éventuel fichier /etc/rc.firewall ne me semble pas (plus?) prévu par défaut. Mais rien n'empêche d'ajouter son propre fichier d'ajout de règles via /etc/rc.local (à créer).
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Paul Gaborit
À (at) 23 Oct 2007 08:01:58 GMT, Nicolas George <nicolas$ écrivait (wrote):
Eric Levenez wrote in message <C3435108.B8B82%:
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.
Je me demande si ces deux approches ne sont pas ce qui distinguait les unix bsd (qui utilisent plutôt des fichiers) des unix sysv (qui utilisent plutôt des commandes)... Maintenant je ne connais aucun unix (actuel) qui ne propose que l'un ou que l'autre. ;-)
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) 23 Oct 2007 08:01:58 GMT,
Nicolas George <nicolas$george@salle-s.org> écrivait (wrote):
Eric Levenez wrote in message <C3435108.B8B82%usenet@levenez.com>:
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.
Je me demande si ces deux approches ne sont pas ce qui distinguait les
unix bsd (qui utilisent plutôt des fichiers) des unix sysv (qui
utilisent plutôt des commandes)... Maintenant je ne connais aucun unix
(actuel) qui ne propose que l'un ou que l'autre. ;-)
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) 23 Oct 2007 08:01:58 GMT, Nicolas George <nicolas$ écrivait (wrote):
Eric Levenez wrote in message <C3435108.B8B82%:
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.
Je me demande si ces deux approches ne sont pas ce qui distinguait les unix bsd (qui utilisent plutôt des fichiers) des unix sysv (qui utilisent plutôt des commandes)... Maintenant je ne connais aucun unix (actuel) qui ne propose que l'un ou que l'autre. ;-)
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Eric Masson
Paul Gaborit writes:
'Lut,
La prise en compte d'un éventuel fichier /etc/rc.firewall ne me semble pas (plus?) prévu par défaut. Mais rien n'empêche d'ajouter son propre fichier d'ajout de règles via /etc/rc.local (à créer).
C'était de mémoire, le dernier OS X sur lequel j'ai regardé de ce coté était un des premiers portables G5 titane.
-- MW >Tss... Un cybermaquereau. On aura tout vu ! JdC> Pourquoi pas ? Il doit bien exister des cybermorues. -+- in : <http://www.le-gnu.net> - Les joies du cybersexe -+-
Paul Gaborit <Paul.Gaborit@invalid.invalid> writes:
'Lut,
La prise en compte d'un éventuel fichier /etc/rc.firewall ne me semble
pas (plus?) prévu par défaut. Mais rien n'empêche d'ajouter son propre
fichier d'ajout de règles via /etc/rc.local (à créer).
C'était de mémoire, le dernier OS X sur lequel j'ai regardé de ce coté
était un des premiers portables G5 titane.
--
MW >Tss... Un cybermaquereau. On aura tout vu !
JdC> Pourquoi pas ? Il doit bien exister des cybermorues.
-+- in : <http://www.le-gnu.net> - Les joies du cybersexe -+-
La prise en compte d'un éventuel fichier /etc/rc.firewall ne me semble pas (plus?) prévu par défaut. Mais rien n'empêche d'ajouter son propre fichier d'ajout de règles via /etc/rc.local (à créer).
C'était de mémoire, le dernier OS X sur lequel j'ai regardé de ce coté était un des premiers portables G5 titane.
-- MW >Tss... Un cybermaquereau. On aura tout vu ! JdC> Pourquoi pas ? Il doit bien exister des cybermorues. -+- in : <http://www.le-gnu.net> - Les joies du cybersexe -+-
laurent.pertois
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.
-- 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.
--
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.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
