Ceux qui me connaissent savent ô combien je répugne à ces pratiques bassement
mercantiles, mais je crains de devoir une fois de plus me livrer à une
scandaleuse campagne d'autopromotion.
Or, donc... Je sors un bouquin sur l'administration des systèmes BSD, aux
editions Eyrolles. Le bouquin s'adresse à des personnes confirmées en
informatique, mais qui sont eventuellement débutants complets en UNIX. Il
passe en revue les tâches d'administration système et réseau, et tente,
lorsque cela est possible, de prendre un peu de hauteur, en décrivant ce qui
se passe sur les autres systèmes que BSD (System V, Linux), l'idée est
d'essayer de donner des connaissances re-utilisables sur d'autres systèmes. Il
fait 240 pages bien remplies et est vendu 25 euros. Achetez le.
La table des matières:
Unix et BSD
Présentation de l'étude de cas
Bien utiliser Unix pour mieux l'administrer
Installer un système BSD
Démarrage des systèmes Unix
Utilisateurs, groupes, et sécurité
Configuration d'une station Unix
Le réseau pour les administrateurs pressés
BSD dans le rôle du pare-feu
Logiciels tierce-partie et systèmes de paquetages
L'étude des catastrophes
Plus d'info dans cette URL à rallonge:
http://www.editions-eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
Note déontologique: aucun logiciel Microsoft n'a été utilisé dans la
réalisation de ce produit (de la rédaction à la mise en page. Je ne sais pas
ce que fait l'imprimeur).
Et pis zut..... tout les vendredis c'est pareil ! Les piles de mon Prumpleffer me lachent !!
Bah, Prumpleffer est en pourparlers avec SAFT afin d'équiper la nouvelle gamme en préparation, de batteries au Lithium longue durée.
laurent.pertois
Hubert Figuiere wrote:
Ceci dit bravo pour le bouquin (que je n'ai pas lu), car ca a pas du être facile de les convaincre de le faire en LaTeX. :-)
Yep, encore qu'Eyrolles doit être plus habitué à ce genre de demandes qu'un éditeur plus grand public.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Hubert Figuiere <hfiguiere@teaser.fr> wrote:
Ceci dit bravo pour le bouquin (que je n'ai pas lu), car ca a pas du
être facile de les convaincre de le faire en LaTeX. :-)
Yep, encore qu'Eyrolles doit être plus habitué à ce genre de demandes
qu'un éditeur plus grand public.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Ceci dit bravo pour le bouquin (que je n'ai pas lu), car ca a pas du être facile de les convaincre de le faire en LaTeX. :-)
Yep, encore qu'Eyrolles doit être plus habitué à ce genre de demandes qu'un éditeur plus grand public.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Erwan David
TheWarden écrivait :
Miod Vallat wrote: Quoi qu'il en soit, je te laisse te
consoler avec http://objective.jesussave.us/propaganda.html#APPLE qui est assez fendard (comme tout le site en général). Extrait : "Furthermore, the Darwin OS is released under an "Open Source" license, which is just another name for Communism"
[troll]
perso je trouve pas ça drôle. Encore un con de religieu catho (ils le sont pas tous, les extrémistes seulement) qui croit qu'on descend d'Adam et Eve et qui prend Apple pour cible... Connerie, qd tu nous tiens !
Et franchement leur pub à fin "visit those good christian businesses" et le logo de Google...
TheWarden <thewarden@wanadoo.fr> écrivait :
Miod Vallat wrote:
Quoi qu'il en soit, je te laisse te
consoler avec http://objective.jesussave.us/propaganda.html#APPLE
qui est assez fendard (comme tout le site en général).
Extrait : "Furthermore, the Darwin OS is released under an "Open
Source"
license, which is just another name for Communism"
[troll]
perso je trouve pas ça drôle.
Encore un con de religieu catho (ils le sont pas tous, les extrémistes
seulement) qui croit qu'on descend d'Adam et Eve et qui prend Apple
pour cible... Connerie, qd tu nous tiens !
Et franchement leur pub à fin "visit those good christian
businesses" et le logo de Google...
Miod Vallat wrote: Quoi qu'il en soit, je te laisse te
consoler avec http://objective.jesussave.us/propaganda.html#APPLE qui est assez fendard (comme tout le site en général). Extrait : "Furthermore, the Darwin OS is released under an "Open Source" license, which is just another name for Communism"
[troll]
perso je trouve pas ça drôle. Encore un con de religieu catho (ils le sont pas tous, les extrémistes seulement) qui croit qu'on descend d'Adam et Eve et qui prend Apple pour cible... Connerie, qd tu nous tiens !
Et franchement leur pub à fin "visit those good christian businesses" et le logo de Google...
Erwan David
(Laurent Pertois) écrivait :
Hubert Figuiere wrote:
Ceci dit bravo pour le bouquin (que je n'ai pas lu), car ca a pas du être facile de les convaincre de le faire en LaTeX. :-)
Yep, encore qu'Eyrolles doit être plus habitué à ce genre de demandes qu'un éditeur plus grand public.
Ceci dit bravo pour le bouquin (que je n'ai pas lu), car ca a pas du être facile de les convaincre de le faire en LaTeX. :-)
Yep, encore qu'Eyrolles doit être plus habitué à ce genre de demandes qu'un éditeur plus grand public.
Y'en a qui n'ont pas réussi...
talon
Eric Masson wrote:
"Miod" == Miod Vallat writes:
Miod> Bin si, ça reste un micro-kernel. N'oublie pas qu'on reconnait un Miod> vrai micro-kernel à ses performances désastreuses et son absence Miod> totale d'avantages réels face à un noyau monolithique équivalent.
Faut-il en déduire que la direction que prend le sieur Dillon n'est pas la bonne à ton sens ?
Mach n'a jamais été réputé, à vrai dire, comme microkernel. Il y en a d'autres, qui semble t'il, n'ont pas de grosse pénalité. Et puis il faut replacer ça dans le contexte d'une machine avec beaucoup de processeurs. Quel est le coût de la gestion des verrous saupoudrés partout, comparé à celui de la gestion des messages. Il y a aussi la maintenabilité des deux solutions, quelle est celle qui t'aménera au plus vite à un état relativement débuggé, et qui permettra ensuite de gérer les modifications sans que ce soit un cauchemard. Je suppose que ce sont tous ces facteurs qui entrent en jeu dans les propos de Dyson ou la démarche de Dillon. En tous cas juger sur les performances d'une machine monoproc, ou la version monolithique n'est pas plombée par les verrous, ce n'est pas honnête. En outre dans la démarche de Dillon, il y a aussi la volonté de faire évoluer un tas d'autres choses qui sont plombées par le conservatisme ambiant. Par exemple l'installeur. Je sais que c'est un de mes radotages favoris de dire que l'installeur de FreeBSD n'est pas optimal ( understatement) pour ne pas parler de ceux de Net et Open, et bien je vois que l'un des projets les plus discutés dans dragonflybsd, c'est un nouvel installeur. Avec cà vient évidemment un système de paquetage plus performant, permettant de dépouiller le système de base de certains résidus du conservatisme (sendmail, par exemple) et de faire des upgrades binaires de sécurité sans se retaper un make world. Un autre de mes radotages habituels, c'est qu'il faudrait que les BSD supportent un système de fichiers journalisé, et si possible, un de ceux de Linux (pour faciliter le dual boot). Je vois que c'est aussi à l'ordre du jour. Bref un tas de choses qui sont toujours rejetés de façon méprisante avec l'argument, il y a du GPL dedans, on n'en veut pas, ou bien un BSD a toujours eu sendmail, on ne veut pas autre chose, ou bien UFS+softupdates c'est tellement mieux, les sytèmes journalisés, on n'en veut pas, sont en fait en odeur de sainteté dans dfbsd.
Eric Masson
--
Michel TALON
Eric Masson <emss@free.fr> wrote:
"Miod" == Miod Vallat <miod@online.fr> writes:
Miod> Bin si, ça reste un micro-kernel. N'oublie pas qu'on reconnait un
Miod> vrai micro-kernel à ses performances désastreuses et son absence
Miod> totale d'avantages réels face à un noyau monolithique équivalent.
Faut-il en déduire que la direction que prend le sieur Dillon n'est pas
la bonne à ton sens ?
Mach n'a jamais été réputé, à vrai dire, comme microkernel. Il y en a
d'autres, qui semble t'il, n'ont pas de grosse pénalité. Et puis il faut
replacer ça dans le contexte d'une machine avec beaucoup de
processeurs. Quel est le coût de la gestion des verrous saupoudrés
partout, comparé à celui de la gestion des messages. Il y a aussi
la maintenabilité des deux solutions, quelle est celle qui t'aménera au
plus vite à un état relativement débuggé, et qui permettra ensuite de
gérer les modifications sans que ce soit un cauchemard.
Je suppose que ce sont tous ces facteurs qui entrent en jeu dans les
propos de Dyson ou la démarche de Dillon. En tous cas juger sur les
performances d'une machine monoproc, ou la version monolithique n'est
pas plombée par les verrous, ce n'est pas honnête.
En outre dans la démarche de Dillon, il y a aussi la volonté de faire
évoluer un tas d'autres choses qui sont plombées par le conservatisme
ambiant. Par exemple l'installeur. Je sais que c'est un de mes radotages
favoris de dire que l'installeur de FreeBSD n'est pas optimal (
understatement) pour ne pas parler de ceux de Net et Open, et bien je
vois que l'un des projets les plus discutés dans dragonflybsd, c'est un
nouvel installeur. Avec cà vient évidemment un système de paquetage
plus performant, permettant de dépouiller le système de base de certains
résidus du conservatisme (sendmail, par exemple) et de faire des
upgrades binaires de sécurité sans se retaper un make world.
Un autre de mes radotages habituels, c'est qu'il faudrait que les BSD
supportent un système de fichiers journalisé, et si possible, un de ceux
de Linux (pour faciliter le dual boot). Je vois que c'est aussi à
l'ordre du jour. Bref un tas de choses qui sont toujours rejetés de
façon méprisante avec l'argument, il y a du GPL dedans, on n'en veut
pas, ou bien un BSD a toujours eu sendmail, on ne veut pas autre chose,
ou bien UFS+softupdates c'est tellement mieux, les sytèmes journalisés,
on n'en veut pas, sont en fait en odeur de sainteté dans dfbsd.
Miod> Bin si, ça reste un micro-kernel. N'oublie pas qu'on reconnait un Miod> vrai micro-kernel à ses performances désastreuses et son absence Miod> totale d'avantages réels face à un noyau monolithique équivalent.
Faut-il en déduire que la direction que prend le sieur Dillon n'est pas la bonne à ton sens ?
Mach n'a jamais été réputé, à vrai dire, comme microkernel. Il y en a d'autres, qui semble t'il, n'ont pas de grosse pénalité. Et puis il faut replacer ça dans le contexte d'une machine avec beaucoup de processeurs. Quel est le coût de la gestion des verrous saupoudrés partout, comparé à celui de la gestion des messages. Il y a aussi la maintenabilité des deux solutions, quelle est celle qui t'aménera au plus vite à un état relativement débuggé, et qui permettra ensuite de gérer les modifications sans que ce soit un cauchemard. Je suppose que ce sont tous ces facteurs qui entrent en jeu dans les propos de Dyson ou la démarche de Dillon. En tous cas juger sur les performances d'une machine monoproc, ou la version monolithique n'est pas plombée par les verrous, ce n'est pas honnête. En outre dans la démarche de Dillon, il y a aussi la volonté de faire évoluer un tas d'autres choses qui sont plombées par le conservatisme ambiant. Par exemple l'installeur. Je sais que c'est un de mes radotages favoris de dire que l'installeur de FreeBSD n'est pas optimal ( understatement) pour ne pas parler de ceux de Net et Open, et bien je vois que l'un des projets les plus discutés dans dragonflybsd, c'est un nouvel installeur. Avec cà vient évidemment un système de paquetage plus performant, permettant de dépouiller le système de base de certains résidus du conservatisme (sendmail, par exemple) et de faire des upgrades binaires de sécurité sans se retaper un make world. Un autre de mes radotages habituels, c'est qu'il faudrait que les BSD supportent un système de fichiers journalisé, et si possible, un de ceux de Linux (pour faciliter le dual boot). Je vois que c'est aussi à l'ordre du jour. Bref un tas de choses qui sont toujours rejetés de façon méprisante avec l'argument, il y a du GPL dedans, on n'en veut pas, ou bien un BSD a toujours eu sendmail, on ne veut pas autre chose, ou bien UFS+softupdates c'est tellement mieux, les sytèmes journalisés, on n'en veut pas, sont en fait en odeur de sainteté dans dfbsd.
Eric Masson
--
Michel TALON
talon
Miod Vallat wrote:
QNX a un micro-kernel et est très loin de ce tu dis.
C'est l'exemple qui confirme la règle.
J'allais le dire.
C'est surtout un argument creux car s'il existe un seul microkernel qui n'a que 5% de perte de performance par rapport à un noyau monolithique, ça prouve bien que l'argument microkernel=bouse, énoncé en toute généralité est faux.
--
Michel TALON
Miod Vallat <miod@online.fr> wrote:
QNX a un micro-kernel et est très loin de ce tu dis.
C'est l'exemple qui confirme la règle.
J'allais le dire.
C'est surtout un argument creux car s'il existe un seul
microkernel qui n'a que 5% de perte de performance par rapport à un
noyau monolithique, ça prouve bien que l'argument
microkernel=bouse, énoncé en toute généralité est faux.
QNX a un micro-kernel et est très loin de ce tu dis.
C'est l'exemple qui confirme la règle.
J'allais le dire.
C'est surtout un argument creux car s'il existe un seul microkernel qui n'a que 5% de perte de performance par rapport à un noyau monolithique, ça prouve bien que l'argument microkernel=bouse, énoncé en toute généralité est faux.
--
Michel TALON
Miod Vallat
QNX a un micro-kernel et est très loin de ce tu dis.
C'est l'exemple qui confirme la règle.
J'allais le dire.
C'est surtout un argument creux car s'il existe un seul microkernel qui n'a que 5% de perte de performance par rapport à un noyau monolithique, ça prouve bien que l'argument microkernel=bouse, énoncé en toute généralité est faux.
C'est surtout rien du tout, puisqu'on ne sait pas avec certitude si QNX est réellement un micro noyau, où juste un noyau monolithique bien modularisé et bien poli pour être performant, mais décrit comme micro-noyau dans les plaquettes commerciales parce que ça jette plus de poudre aux yeux...
QNX a un micro-kernel et est très loin de ce tu dis.
C'est l'exemple qui confirme la règle.
J'allais le dire.
C'est surtout un argument creux car s'il existe un seul
microkernel qui n'a que 5% de perte de performance par rapport à un
noyau monolithique, ça prouve bien que l'argument
microkernel=bouse, énoncé en toute généralité est faux.
C'est surtout rien du tout, puisqu'on ne sait pas avec certitude si QNX
est réellement un micro noyau, où juste un noyau monolithique bien
modularisé et bien poli pour être performant, mais décrit comme
micro-noyau dans les plaquettes commerciales parce que ça jette plus de
poudre aux yeux...
QNX a un micro-kernel et est très loin de ce tu dis.
C'est l'exemple qui confirme la règle.
J'allais le dire.
C'est surtout un argument creux car s'il existe un seul microkernel qui n'a que 5% de perte de performance par rapport à un noyau monolithique, ça prouve bien que l'argument microkernel=bouse, énoncé en toute généralité est faux.
C'est surtout rien du tout, puisqu'on ne sait pas avec certitude si QNX est réellement un micro noyau, où juste un noyau monolithique bien modularisé et bien poli pour être performant, mais décrit comme micro-noyau dans les plaquettes commerciales parce que ça jette plus de poudre aux yeux...
manu
Bifidus wrote:
Mais il y a 0% de Microsoft, pour moi c'est important. C'est là que je voulais en venir, au fait de n'évoquer que Microsoft,
plutôt que le logiciel non libre en général.
Je ne suis pas un ayatolah du libre. Je suis morallement opposé à l'usage des produits Microsoft, dont l'objectif est d'enfermer l'utilisateur dans une logique de consommation grégaire. Les logiciels commerciaux raisonnables ne me posent pas de problème.
C'est sûr je préfère du libre parceque c'est gratuit et que je peux mettre le nez dedans, mais je ne vais pas me priver d'utiliser un logiciel non libre, si il m'apporte des choses que les logiciels libres ne peuvent pas m'apporter. Exemple: Canvas. Je n'ai pas trouvé de remplacant aussi bien ficelé en logiciel libre.
Mais il y a 0% de Microsoft, pour moi c'est important.
C'est là que je voulais en venir, au fait de n'évoquer que Microsoft,
plutôt que le logiciel non libre en général.
Je ne suis pas un ayatolah du libre. Je suis morallement opposé à
l'usage des produits Microsoft, dont l'objectif est d'enfermer
l'utilisateur dans une logique de consommation grégaire. Les logiciels
commerciaux raisonnables ne me posent pas de problème.
C'est sûr je préfère du libre parceque c'est gratuit et que je peux
mettre le nez dedans, mais je ne vais pas me priver d'utiliser un
logiciel non libre, si il m'apporte des choses que les logiciels libres
ne peuvent pas m'apporter. Exemple: Canvas. Je n'ai pas trouvé de
remplacant aussi bien ficelé en logiciel libre.
Mais il y a 0% de Microsoft, pour moi c'est important. C'est là que je voulais en venir, au fait de n'évoquer que Microsoft,
plutôt que le logiciel non libre en général.
Je ne suis pas un ayatolah du libre. Je suis morallement opposé à l'usage des produits Microsoft, dont l'objectif est d'enfermer l'utilisateur dans une logique de consommation grégaire. Les logiciels commerciaux raisonnables ne me posent pas de problème.
C'est sûr je préfère du libre parceque c'est gratuit et que je peux mettre le nez dedans, mais je ne vais pas me priver d'utiliser un logiciel non libre, si il m'apporte des choses que les logiciels libres ne peuvent pas m'apporter. Exemple: Canvas. Je n'ai pas trouvé de remplacant aussi bien ficelé en logiciel libre.
-- Emmanuel Dreyfus
manu
Hubert Figuiere wrote:
Ouais disons que quand je compare l'exécution d'un script "configure" sur mon G3/400 sous MacOS X and le PPC604 240Mhz sous Linux, je pleure. C'est pas la GUI qui ralentit. MacOS X c'est le inconvénients d'un micro-kernel sans les avantages[1]
Si tu ne l'as pas déjà fait, va voir mes traces sur http://hcpnet.free.fr/applebsd.html et tu comprendra pourquoi ca se traine.
-- Emmanuel Dreyfus
Hubert Figuiere <hfiguiere@teaser.fr> wrote:
Ouais disons que quand je compare l'exécution d'un script "configure"
sur mon G3/400 sous MacOS X and le PPC604 240Mhz sous Linux, je
pleure. C'est pas la GUI qui ralentit.
MacOS X c'est le inconvénients d'un micro-kernel sans les avantages[1]
Si tu ne l'as pas déjà fait, va voir mes traces sur
http://hcpnet.free.fr/applebsd.html et tu comprendra pourquoi ca se
traine.
Ouais disons que quand je compare l'exécution d'un script "configure" sur mon G3/400 sous MacOS X and le PPC604 240Mhz sous Linux, je pleure. C'est pas la GUI qui ralentit. MacOS X c'est le inconvénients d'un micro-kernel sans les avantages[1]
Si tu ne l'as pas déjà fait, va voir mes traces sur http://hcpnet.free.fr/applebsd.html et tu comprendra pourquoi ca se traine.
-- Emmanuel Dreyfus
talon
Miod Vallat wrote:
QNX a un micro-kernel et est très loin de ce tu dis.
C'est l'exemple qui confirme la règle.
J'allais le dire.
C'est surtout un argument creux car s'il existe un seul microkernel qui n'a que 5% de perte de performance par rapport à un noyau monolithique, ça prouve bien que l'argument microkernel=bouse, énoncé en toute généralité est faux.
C'est surtout rien du tout, puisqu'on ne sait pas avec certitude si QNX est réellement un micro noyau, où juste un noyau monolithique bien modularisé et bien poli pour être performant, mais décrit comme micro-noyau dans les plaquettes commerciales parce que ça jette plus de poudre aux yeux...
Et L4?
--
Michel TALON
Miod Vallat <miod@online.fr> wrote:
QNX a un micro-kernel et est très loin de ce tu dis.
C'est l'exemple qui confirme la règle.
J'allais le dire.
C'est surtout un argument creux car s'il existe un seul
microkernel qui n'a que 5% de perte de performance par rapport à un
noyau monolithique, ça prouve bien que l'argument
microkernel=bouse, énoncé en toute généralité est faux.
C'est surtout rien du tout, puisqu'on ne sait pas avec certitude si QNX
est réellement un micro noyau, où juste un noyau monolithique bien
modularisé et bien poli pour être performant, mais décrit comme
micro-noyau dans les plaquettes commerciales parce que ça jette plus de
poudre aux yeux...
QNX a un micro-kernel et est très loin de ce tu dis.
C'est l'exemple qui confirme la règle.
J'allais le dire.
C'est surtout un argument creux car s'il existe un seul microkernel qui n'a que 5% de perte de performance par rapport à un noyau monolithique, ça prouve bien que l'argument microkernel=bouse, énoncé en toute généralité est faux.
C'est surtout rien du tout, puisqu'on ne sait pas avec certitude si QNX est réellement un micro noyau, où juste un noyau monolithique bien modularisé et bien poli pour être performant, mais décrit comme micro-noyau dans les plaquettes commerciales parce que ça jette plus de poudre aux yeux...
