Ubuntu Ultimate Edition

Jerome Lambert

21/03/2009 à 14:31

JKB wrote:

Le 21-03-2009, ? propos de
Re: Ubuntu Ultimate Edition,
Jerome Lambert ?crivait dans fr.comp.os.linux.debats :
Doug713705 a écrit :
Le Thu, 19 Mar 2009 21:08:57 +0100, pehache-tolai a écrit dans
news: des mots en forme de phrase pour
nous dire :

Que le nom que l'on cherche soit celui d'une entrée dans la BDR ou un
nom de fichier, je ne vois pas ce que ça change.

- Le nombre de clefs dans la BDR est autrement plus important que le nombre
de fichiers de conf d'un système Linux comparable.

Sauf qu'une clé de BDR correspond plutôt à une ligne de fichier de conf,
donc pour comparer il faudrait faire un wc -l récursif sur /etc/ et
additionner tous les résultats en soustrayant les lignes vides.
Pas sûr du tout que la BDR Windows soit perdante d'avance...

Prends un outil au hasard comme Visiodent II et regarde _toutes_ les
entrées rajoutées par ce logiciel dans _toutes_ les branches de la base
de registre, qu'on se marre. Les principales clerfs sont dans
visiodent-40c, mais il en rajoute d'autres un peu partout. Pourquoi
est-ce que tout n'est pas sous visiodent ?

Parce que c'est le principe même et tout l'intérêt d'une base de
registre? Prend l'exemple d'un traitement de texte: il a ses propres
paramètres dans ses propres zones, mais il y a aussi des zones communes,
propres au système, où il doit se déclarer, p.ex. dans la liste des
programmes qui sont capables d'ouvrir du RTF ou du texte brut.

Et je ne parle pas des clefs qui devraient être associées à la
local_user et qui se retrouvent dans local_machine et les autres
aberrations du même genre.

Si en plus ton programme est moisi...

JKB

21/03/2009 à 14:33

Le 21-03-2009, ? propos de
Re: Ubuntu Ultimate Edition,
Jerome Lambert ?crivait dans fr.comp.os.linux.debats :

JKB wrote:
Le 21-03-2009, ? propos de
Re: Ubuntu Ultimate Edition,
Jerome Lambert ?crivait dans fr.comp.os.linux.debats :
Doug713705 a écrit :
Le Thu, 19 Mar 2009 21:08:57 +0100, pehache-tolai a écrit dans
news: des mots en forme de phrase pour
nous dire :

Que le nom que l'on cherche soit celui d'une entrée dans la BDR ou un
nom de fichier, je ne vois pas ce que ça change.

- Le nombre de clefs dans la BDR est autrement plus important que le nombre
de fichiers de conf d'un système Linux comparable.

Sauf qu'une clé de BDR correspond plutôt à une ligne de fichier de conf,
donc pour comparer il faudrait faire un wc -l récursif sur /etc/ et
additionner tous les résultats en soustrayant les lignes vides.
Pas sûr du tout que la BDR Windows soit perdante d'avance...

Prends un outil au hasard comme Visiodent II et regarde _toutes_ les
entrées rajoutées par ce logiciel dans _toutes_ les branches de la base
de registre, qu'on se marre. Les principales clerfs sont dans
visiodent-40c, mais il en rajoute d'autres un peu partout. Pourquoi
est-ce que tout n'est pas sous visiodent ?

Parce que c'est le principe même et tout l'intérêt d'une base de
registre? Prend l'exemple d'un traitement de texte: il a ses propres
paramètres dans ses propres zones, mais il y a aussi des zones communes,
propres au système, où il doit se déclarer, p.ex. dans la liste des
programmes qui sont capables d'ouvrir du RTF ou du texte brut.

Nous sommes bien d'accord. Sauf qu'en pratique, ce n'est pas du tout
le cas. La configuration est éclatée dans une foutitude d'endroits qui
n'ont aucune logique apparente.

Et je ne parle pas des clefs qui devraient être associées à la
local_user et qui se retrouvent dans local_machine et les autres
aberrations du même genre.

Si en plus ton programme est moisi...

Montre-moi un seul progiciel Windows qui n'est pas moisi parce que
le début du développement date de W3.1 et que depuis, on patche pour
suivre les évolutions. Tous les outils qui sont censés fonctionner en
réseau sont déplorables parce qu'ils tournent autour des problèmes
Windows (le coup du poste client qui est maître de l'application, c'est
assez drôle... Chez un client, lorsque le poste du comptable se bauge,
instantanément, tous les postes du service comptables sont aux
choux...).

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 21-03-2009, ? propos de
Re: Ubuntu Ultimate Edition,
Jerome Lambert ?crivait dans fr.comp.os.linux.debats :

JKB wrote:

Le 21-03-2009, ? propos de
Re: Ubuntu Ultimate Edition,
Jerome Lambert ?crivait dans fr.comp.os.linux.debats :

Doug713705 a écrit :

Le Thu, 19 Mar 2009 21:08:57 +0100, pehache-tolai a écrit dans
news:72fn2jFpu9i6U1@mid.individual.net des mots en forme de phrase pour
nous dire :

Que le nom que l'on cherche soit celui d'une entrée dans la BDR ou un
nom de fichier, je ne vois pas ce que ça change.

- Le nombre de clefs dans la BDR est autrement plus important que le nombre
de fichiers de conf d'un système Linux comparable.

Sauf qu'une clé de BDR correspond plutôt à une ligne de fichier de conf,
donc pour comparer il faudrait faire un wc -l récursif sur /etc/ et
additionner tous les résultats en soustrayant les lignes vides.
Pas sûr du tout que la BDR Windows soit perdante d'avance...

Prends un outil au hasard comme Visiodent II et regarde _toutes_ les
entrées rajoutées par ce logiciel dans _toutes_ les branches de la base
de registre, qu'on se marre. Les principales clerfs sont dans
visiodent-40c, mais il en rajoute d'autres un peu partout. Pourquoi
est-ce que tout n'est pas sous visiodent ?

Parce que c'est le principe même et tout l'intérêt d'une base de
registre? Prend l'exemple d'un traitement de texte: il a ses propres
paramètres dans ses propres zones, mais il y a aussi des zones communes,
propres au système, où il doit se déclarer, p.ex. dans la liste des
programmes qui sont capables d'ouvrir du RTF ou du texte brut.

Nous sommes bien d'accord. Sauf qu'en pratique, ce n'est pas du tout
le cas. La configuration est éclatée dans une foutitude d'endroits qui
n'ont aucune logique apparente.

Et je ne parle pas des clefs qui devraient être associées à la
local_user et qui se retrouvent dans local_machine et les autres
aberrations du même genre.

Si en plus ton programme est moisi...

Montre-moi un seul progiciel Windows qui n'est pas moisi parce que
le début du développement date de W3.1 et que depuis, on patche pour
suivre les évolutions. Tous les outils qui sont censés fonctionner en
réseau sont déplorables parce qu'ils tournent autour des problèmes
Windows (le coup du poste client qui est maître de l'application, c'est
assez drôle... Chez un client, lorsque le poste du comptable se bauge,
instantanément, tous les postes du service comptables sont aux
choux...).

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.

Vous avez filtré cet utilisateur ! Consultez son message

Le 21-03-2009, ? propos de
Re: Ubuntu Ultimate Edition,
Jerome Lambert ?crivait dans fr.comp.os.linux.debats :

JKB wrote:
Le 21-03-2009, ? propos de
Re: Ubuntu Ultimate Edition,
Jerome Lambert ?crivait dans fr.comp.os.linux.debats :
Doug713705 a écrit :
Le Thu, 19 Mar 2009 21:08:57 +0100, pehache-tolai a écrit dans
news: des mots en forme de phrase pour
nous dire :

Que le nom que l'on cherche soit celui d'une entrée dans la BDR ou un
nom de fichier, je ne vois pas ce que ça change.

- Le nombre de clefs dans la BDR est autrement plus important que le nombre
de fichiers de conf d'un système Linux comparable.

Sauf qu'une clé de BDR correspond plutôt à une ligne de fichier de conf,
donc pour comparer il faudrait faire un wc -l récursif sur /etc/ et
additionner tous les résultats en soustrayant les lignes vides.
Pas sûr du tout que la BDR Windows soit perdante d'avance...

Prends un outil au hasard comme Visiodent II et regarde _toutes_ les
entrées rajoutées par ce logiciel dans _toutes_ les branches de la base
de registre, qu'on se marre. Les principales clerfs sont dans
visiodent-40c, mais il en rajoute d'autres un peu partout. Pourquoi
est-ce que tout n'est pas sous visiodent ?

Parce que c'est le principe même et tout l'intérêt d'une base de
registre? Prend l'exemple d'un traitement de texte: il a ses propres
paramètres dans ses propres zones, mais il y a aussi des zones communes,
propres au système, où il doit se déclarer, p.ex. dans la liste des
programmes qui sont capables d'ouvrir du RTF ou du texte brut.

Nous sommes bien d'accord. Sauf qu'en pratique, ce n'est pas du tout
le cas. La configuration est éclatée dans une foutitude d'endroits qui
n'ont aucune logique apparente.

Et je ne parle pas des clefs qui devraient être associées à la
local_user et qui se retrouvent dans local_machine et les autres
aberrations du même genre.

Si en plus ton programme est moisi...

Montre-moi un seul progiciel Windows qui n'est pas moisi parce que
le début du développement date de W3.1 et que depuis, on patche pour
suivre les évolutions. Tous les outils qui sont censés fonctionner en
réseau sont déplorables parce qu'ils tournent autour des problèmes
Windows (le coup du poste client qui est maître de l'application, c'est
assez drôle... Chez un client, lorsque le poste du comptable se bauge,
instantanément, tous les postes du service comptables sont aux
choux...).

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.

Jerome Lambert

21/03/2009 à 15:00

JKB wrote:

Le 21-03-2009, ? propos de
Re: Ubuntu Ultimate Edition,
Jerome Lambert ?crivait dans fr.comp.os.linux.debats :
JKB wrote:

(...)

Prends un outil au hasard comme Visiodent II et regarde _toutes_ les
entrées rajoutées par ce logiciel dans _toutes_ les branches de la base
de registre, qu'on se marre. Les principales clerfs sont dans
visiodent-40c, mais il en rajoute d'autres un peu partout. Pourquoi
est-ce que tout n'est pas sous visiodent ?

Parce que c'est le principe même et tout l'intérêt d'une base de
registre? Prend l'exemple d'un traitement de texte: il a ses propres
paramètres dans ses propres zones, mais il y a aussi des zones communes,
propres au système, où il doit se déclarer, p.ex. dans la liste des
programmes qui sont capables d'ouvrir du RTF ou du texte brut.

Nous sommes bien d'accord. Sauf qu'en pratique, ce n'est pas du tout
le cas. La configuration est éclatée dans une foutitude d'endroits qui
n'ont aucune logique apparente.

La logique de la base de registre Windows, ça s'apprend. Pour ne pas
aller loin, va sur le forum approprié: régulièrement, des problèmes
posés sont résolus avec un bon gros coup de regedit, et je ne parle même
pas de sites comme ceux de J-C Bellamy qui grouillent de trucs et
astuces à base de coups de regedit bien senti. Comme quoi c'est possible.

Et je ne parle pas des clefs qui devraient être associées à la
local_user et qui se retrouvent dans local_machine et les autres
aberrations du même genre.

Si en plus ton programme est moisi...

Montre-moi un seul progiciel Windows qui n'est pas moisi parce que
le début du développement date de W3.1 et que depuis, on patche pour
suivre les évolutions.

C'est la faute de MS si les développeurs sont fainéants, maintenant? Il
leur a fallut combien de temps pour implémenter la gestion du mutli-user
dans les programmes? Ce n'était pas encore le cas lors de la sortie de
XP, alors que tout est en place depuis les premières versions de NT!
Dans la même veine, il y a encore une palanqué de programmes sous MacOS
X (y compris des libres!) qui se basent toujours sur l'API héritée de
MacOS 9 (Carbon), alors que ça fait près de 10 ans qu'on doit faire
autrement. Apple a eu le courage de trancher: cette API ne sera plus
présente dans MacOS X 10.6. Je n'ose imaginer le scandale si Microsoft
faisait de même sous Windows.
Et si, dans un autre domaine, MS a décidé que dorénavant les drivers non
certifiés ne seraient plus installables sur les version 64 bits de ses
OS alors que sur les versions 32 bits on pouvait outrepasser
l'avertissement, c'est qu'il y a une excellente raison à ça.

JKB wrote:

Le 21-03-2009, ? propos de
Re: Ubuntu Ultimate Edition,
Jerome Lambert ?crivait dans fr.comp.os.linux.debats :

JKB wrote:

(...)

Prends un outil au hasard comme Visiodent II et regarde _toutes_ les
entrées rajoutées par ce logiciel dans _toutes_ les branches de la base
de registre, qu'on se marre. Les principales clerfs sont dans
visiodent-40c, mais il en rajoute d'autres un peu partout. Pourquoi
est-ce que tout n'est pas sous visiodent ?

Parce que c'est le principe même et tout l'intérêt d'une base de
registre? Prend l'exemple d'un traitement de texte: il a ses propres
paramètres dans ses propres zones, mais il y a aussi des zones communes,
propres au système, où il doit se déclarer, p.ex. dans la liste des
programmes qui sont capables d'ouvrir du RTF ou du texte brut.

Nous sommes bien d'accord. Sauf qu'en pratique, ce n'est pas du tout
le cas. La configuration est éclatée dans une foutitude d'endroits qui
n'ont aucune logique apparente.

La logique de la base de registre Windows, ça s'apprend. Pour ne pas
aller loin, va sur le forum approprié: régulièrement, des problèmes
posés sont résolus avec un bon gros coup de regedit, et je ne parle même
pas de sites comme ceux de J-C Bellamy qui grouillent de trucs et
astuces à base de coups de regedit bien senti. Comme quoi c'est possible.

Et je ne parle pas des clefs qui devraient être associées à la
local_user et qui se retrouvent dans local_machine et les autres
aberrations du même genre.

Si en plus ton programme est moisi...

Montre-moi un seul progiciel Windows qui n'est pas moisi parce que
le début du développement date de W3.1 et que depuis, on patche pour
suivre les évolutions.

C'est la faute de MS si les développeurs sont fainéants, maintenant? Il
leur a fallut combien de temps pour implémenter la gestion du mutli-user
dans les programmes? Ce n'était pas encore le cas lors de la sortie de
XP, alors que tout est en place depuis les premières versions de NT!
Dans la même veine, il y a encore une palanqué de programmes sous MacOS
X (y compris des libres!) qui se basent toujours sur l'API héritée de
MacOS 9 (Carbon), alors que ça fait près de 10 ans qu'on doit faire
autrement. Apple a eu le courage de trancher: cette API ne sera plus
présente dans MacOS X 10.6. Je n'ose imaginer le scandale si Microsoft
faisait de même sous Windows.
Et si, dans un autre domaine, MS a décidé que dorénavant les drivers non
certifiés ne seraient plus installables sur les version 64 bits de ses
OS alors que sur les versions 32 bits on pouvait outrepasser
l'avertissement, c'est qu'il y a une excellente raison à ça.

Vous avez filtré cet utilisateur ! Consultez son message

JKB wrote:

Le 21-03-2009, ? propos de
Re: Ubuntu Ultimate Edition,
Jerome Lambert ?crivait dans fr.comp.os.linux.debats :
JKB wrote:

(...)

Prends un outil au hasard comme Visiodent II et regarde _toutes_ les
entrées rajoutées par ce logiciel dans _toutes_ les branches de la base
de registre, qu'on se marre. Les principales clerfs sont dans
visiodent-40c, mais il en rajoute d'autres un peu partout. Pourquoi
est-ce que tout n'est pas sous visiodent ?

Parce que c'est le principe même et tout l'intérêt d'une base de
registre? Prend l'exemple d'un traitement de texte: il a ses propres
paramètres dans ses propres zones, mais il y a aussi des zones communes,
propres au système, où il doit se déclarer, p.ex. dans la liste des
programmes qui sont capables d'ouvrir du RTF ou du texte brut.

Nous sommes bien d'accord. Sauf qu'en pratique, ce n'est pas du tout
le cas. La configuration est éclatée dans une foutitude d'endroits qui
n'ont aucune logique apparente.

La logique de la base de registre Windows, ça s'apprend. Pour ne pas
aller loin, va sur le forum approprié: régulièrement, des problèmes
posés sont résolus avec un bon gros coup de regedit, et je ne parle même
pas de sites comme ceux de J-C Bellamy qui grouillent de trucs et
astuces à base de coups de regedit bien senti. Comme quoi c'est possible.

Et je ne parle pas des clefs qui devraient être associées à la
local_user et qui se retrouvent dans local_machine et les autres
aberrations du même genre.

Si en plus ton programme est moisi...

Montre-moi un seul progiciel Windows qui n'est pas moisi parce que
le début du développement date de W3.1 et que depuis, on patche pour
suivre les évolutions.

C'est la faute de MS si les développeurs sont fainéants, maintenant? Il
leur a fallut combien de temps pour implémenter la gestion du mutli-user
dans les programmes? Ce n'était pas encore le cas lors de la sortie de
XP, alors que tout est en place depuis les premières versions de NT!
Dans la même veine, il y a encore une palanqué de programmes sous MacOS
X (y compris des libres!) qui se basent toujours sur l'API héritée de
MacOS 9 (Carbon), alors que ça fait près de 10 ans qu'on doit faire
autrement. Apple a eu le courage de trancher: cette API ne sera plus
présente dans MacOS X 10.6. Je n'ose imaginer le scandale si Microsoft
faisait de même sous Windows.
Et si, dans un autre domaine, MS a décidé que dorénavant les drivers non
certifiés ne seraient plus installables sur les version 64 bits de ses
OS alors que sur les versions 32 bits on pouvait outrepasser
l'avertissement, c'est qu'il y a une excellente raison à ça.

Hugolino

21/03/2009 à 15:00

Le 21-03-2009, Jerome Lambert a écrit :

Les former et leur apprendre à gérer convenablement un OS est amha
bien plus payant pour tout le monde.

Et c'est bien sûr avec Windows® que ça va être le plus facile...

--
Linux users never complain about Microsoft. They don't need to !
Hugo (né il y a 1 417 047 288 secondes)

Hugolino

21/03/2009 à 15:09

Le 21-03-2009, Jerome Lambert a écrit :

Hugolino a écrit :
> Le 19-03-2009, Jerome Lambert a écrit :
>> Hugolino a écrit :
>>> Il y a un intérêt évident à passer sous Linux quand on veut des
>>> postes verrouillés et simples à administrer, parce que Linux est
>>> prévu dès le départ pour fonctionner en réseau. D'un simple
>>> serveur NFS à un projet comme LTSP où les postes ne sont que des
>>> consoles graphiques, le choix est très vaste, alors qu'un réseau
>>> sous Windows®, c'est la porte ouverte au grand n'importe quoi et
>>> aux emmerdes sans fin.
>> Ce qui est bien avec toi, c'est que tu dis tout et son contraire,
>> il suffit de te laisser parler: d'un côté, tu reproches à Windows
>> que "je doute que les utilisateurs cherchent à en avoir une
>> utilisation plus poussée", alors que d'un autre côté, "Il y a un
>> intérêt évident à passer sous Linux quand on veut des postes
>> verrouillés". Pas mal du tout.
> Il n'y a aucune contradiction entre dire que windows est une sombre
> merde qui ne peut fonctionner que s'il a été verrouillé par un admin
> compétent et dire que *si* on veut verrouiller un poste bureautique,
> alors c'est plus facile à faire avec un Linux.
En l'occurrence, ce n'est pas ce que tu as écris: tu reproches à
Windows de limiter les utilisateurs,

Oui. Windows® est une sombre merde. Quoique tu veuilles faire, tu sais
que ça va mal se passer... C'est là qu'est la limitation.

et tu propose une solution qui est la meilleure pour limiter les
utilisateurs.

Oui mais là, on ne parle plus de la même limitation. Et je parlais
plutôt de verrouillage. Ça t'avait échappé où tu remplaçais juste un mot
par l'autre pour servir ton troll moisi ?

Donc si tu veux verrouiller les utilisateurs, il te faut un admin et un
OS. Windows® et Linux permettent de le faire, mais Linux le permet plus
facilement...

Si tu ne vois pas la contradiction...

Il n'y en avait pas... sauf dans ton esprit trollesque.

>> Mais tu *peux*! Il suffit de savoir ce qu'il faut faire, donc de
>> se former, exactement comme sous n'importe quel OS (ou en
>> n'importe quel domaine, d'ailleurs).
> Il m'est impossible de faire confiance à un OS, conçu par des
> esprits malades, qui présente des boîtes de dialogue proposant d'«
> activer la désactivation ».

Tu parles bien de cet OS dont certains services se désactivent par la ligne

disable = yes

placée dans les bons fichiers de configuration?

Non, je parlais de cette merde de Windows®. Autre question ?

--
There is only 10 types of people: those who understand binary and those
who don't.
Hugo (né il y a 1 417 100 355 secondes)

Le 21-03-2009, Jerome Lambert <jerome.lambert@swing.be> a écrit :

Hugolino a écrit :
> Le 19-03-2009, Jerome Lambert <jerome.lambert@swing.be> a écrit :
>> Hugolino a écrit :
>>> Il y a un intérêt évident à passer sous Linux quand on veut des
>>> postes verrouillés et simples à administrer, parce que Linux est
>>> prévu dès le départ pour fonctionner en réseau. D'un simple
>>> serveur NFS à un projet comme LTSP où les postes ne sont que des
>>> consoles graphiques, le choix est très vaste, alors qu'un réseau
>>> sous Windows®, c'est la porte ouverte au grand n'importe quoi et
>>> aux emmerdes sans fin.
>> Ce qui est bien avec toi, c'est que tu dis tout et son contraire,
>> il suffit de te laisser parler: d'un côté, tu reproches à Windows
>> que "je doute que les utilisateurs cherchent à en avoir une
>> utilisation plus poussée", alors que d'un autre côté, "Il y a un
>> intérêt évident à passer sous Linux quand on veut des postes
>> verrouillés". Pas mal du tout.
> Il n'y a aucune contradiction entre dire que windows est une sombre
> merde qui ne peut fonctionner que s'il a été verrouillé par un admin
> compétent et dire que *si* on veut verrouiller un poste bureautique,
> alors c'est plus facile à faire avec un Linux.
En l'occurrence, ce n'est pas ce que tu as écris: tu reproches à
Windows de limiter les utilisateurs,

Oui. Windows® est une sombre merde. Quoique tu veuilles faire, tu sais
que ça va mal se passer... C'est là qu'est la limitation.

et tu propose une solution qui est la meilleure pour limiter les
utilisateurs.

Oui mais là, on ne parle plus de la même limitation. Et je parlais
plutôt de verrouillage. Ça t'avait échappé où tu remplaçais juste un mot
par l'autre pour servir ton troll moisi ?

Donc si tu veux verrouiller les utilisateurs, il te faut un admin et un
OS. Windows® et Linux permettent de le faire, mais Linux le permet plus
facilement...

Si tu ne vois pas la contradiction...

Il n'y en avait pas... sauf dans ton esprit trollesque.

>> Mais tu *peux*! Il suffit de savoir ce qu'il faut faire, donc de
>> se former, exactement comme sous n'importe quel OS (ou en
>> n'importe quel domaine, d'ailleurs).
> Il m'est impossible de faire confiance à un OS, conçu par des
> esprits malades, qui présente des boîtes de dialogue proposant d'«
> activer la désactivation ».

Tu parles bien de cet OS dont certains services se désactivent par la ligne

disable = yes

placée dans les bons fichiers de configuration?

Non, je parlais de cette merde de Windows®. Autre question ?

--
There is only 10 types of people: those who understand binary and those
who don't.
Hugo (né il y a 1 417 100 355 secondes)

Vous avez filtré cet utilisateur ! Consultez son message

Le 21-03-2009, Jerome Lambert a écrit :

Hugolino a écrit :
> Le 19-03-2009, Jerome Lambert a écrit :
>> Hugolino a écrit :
>>> Il y a un intérêt évident à passer sous Linux quand on veut des
>>> postes verrouillés et simples à administrer, parce que Linux est
>>> prévu dès le départ pour fonctionner en réseau. D'un simple
>>> serveur NFS à un projet comme LTSP où les postes ne sont que des
>>> consoles graphiques, le choix est très vaste, alors qu'un réseau
>>> sous Windows®, c'est la porte ouverte au grand n'importe quoi et
>>> aux emmerdes sans fin.
>> Ce qui est bien avec toi, c'est que tu dis tout et son contraire,
>> il suffit de te laisser parler: d'un côté, tu reproches à Windows
>> que "je doute que les utilisateurs cherchent à en avoir une
>> utilisation plus poussée", alors que d'un autre côté, "Il y a un
>> intérêt évident à passer sous Linux quand on veut des postes
>> verrouillés". Pas mal du tout.
> Il n'y a aucune contradiction entre dire que windows est une sombre
> merde qui ne peut fonctionner que s'il a été verrouillé par un admin
> compétent et dire que *si* on veut verrouiller un poste bureautique,
> alors c'est plus facile à faire avec un Linux.
En l'occurrence, ce n'est pas ce que tu as écris: tu reproches à
Windows de limiter les utilisateurs,

Oui. Windows® est une sombre merde. Quoique tu veuilles faire, tu sais
que ça va mal se passer... C'est là qu'est la limitation.

et tu propose une solution qui est la meilleure pour limiter les
utilisateurs.

Oui mais là, on ne parle plus de la même limitation. Et je parlais
plutôt de verrouillage. Ça t'avait échappé où tu remplaçais juste un mot
par l'autre pour servir ton troll moisi ?

Donc si tu veux verrouiller les utilisateurs, il te faut un admin et un
OS. Windows® et Linux permettent de le faire, mais Linux le permet plus
facilement...

Si tu ne vois pas la contradiction...

Il n'y en avait pas... sauf dans ton esprit trollesque.

>> Mais tu *peux*! Il suffit de savoir ce qu'il faut faire, donc de
>> se former, exactement comme sous n'importe quel OS (ou en
>> n'importe quel domaine, d'ailleurs).
> Il m'est impossible de faire confiance à un OS, conçu par des
> esprits malades, qui présente des boîtes de dialogue proposant d'«
> activer la désactivation ».

Tu parles bien de cet OS dont certains services se désactivent par la ligne

disable = yes

placée dans les bons fichiers de configuration?

Non, je parlais de cette merde de Windows®. Autre question ?

--
There is only 10 types of people: those who understand binary and those
who don't.
Hugo (né il y a 1 417 100 355 secondes)

Jerome Lambert

21/03/2009 à 15:12

Hugolino a écrit :

Le 21-03-2009, Jerome Lambert a écrit :
Les former et leur apprendre à gérer convenablement un OS est amha
bien plus payant pour tout le monde.

Et c'est bien sûr avec Windows® que ça va être le plus facile...

Un Windows *bien géré* ne pose pas plus de problèmes que quoi ce soit
d'autres.

Jerome Lambert

21/03/2009 à 15:21

Hugolino a écrit :

Le 21-03-2009, Jerome Lambert a écrit :
Hugolino a écrit :

(...)

Il n'y a aucune contradiction entre dire que windows est une sombre
merde qui ne peut fonctionner que s'il a été verrouillé par un admin
compétent et dire que *si* on veut verrouiller un poste bureautique,
alors c'est plus facile à faire avec un Linux.

En l'occurrence, ce n'est pas ce que tu as écris: tu reproches à
Windows de limiter les utilisateurs,

Oui. Windows® est une sombre merde. Quoique tu veuilles faire, tu sais
que ça va mal se passer...

Du tout, c'est quoi que *tu* veuilles faire, mais à te lire j'ai
l'impression que la limite est située entre la chaise et le clavier. Tu
me fais un peu penser à ce collègue qui, d'un simple regard, faisait
planter n'importe quelle machine. Il suffisait de lui demander de
refaire exactement les même opérations pour se rendre compte qu'en fait
tout fonctionnait convenablement. C'était devenu un grand sujet de
plaisanterie pour le helpdesk.

et tu propose une solution qui est la meilleure pour limiter les
utilisateurs.

Oui mais là, on ne parle plus de la même limitation. Et je parlais
plutôt de verrouillage. Ça t'avait échappé où tu remplaçais juste un mot
par l'autre pour servir ton troll moisi ?

Donc si tu veux verrouiller les utilisateurs

Oh non, je ne veux surtout pas le faire...

Mais tu *peux*! Il suffit de savoir ce qu'il faut faire, donc de
se former, exactement comme sous n'importe quel OS (ou en
n'importe quel domaine, d'ailleurs).

Il m'est impossible de faire confiance à un OS, conçu par des
esprits malades, qui présente des boîtes de dialogue proposant d'«
activer la désactivation ».

Tu parles bien de cet OS dont certains services se désactivent par la ligne

disable = yes

placée dans les bons fichiers de configuration?

Non, je parlais de cette merde de Windows®.

Pourtant tu fais bien confiance à un OS qui présente des lignes de
fichier de configuration où l'on propose "d'activer la désactivation",
puisque l'extrait ci-dessous vient d'un fichier de conf de xinetd sous
Debian. Encore une fois tu te contredis...

Hugolino a écrit :

Le 21-03-2009, Jerome Lambert <jerome.lambert@swing.be> a écrit :

Hugolino a écrit :

(...)

Il n'y a aucune contradiction entre dire que windows est une sombre
merde qui ne peut fonctionner que s'il a été verrouillé par un admin
compétent et dire que *si* on veut verrouiller un poste bureautique,
alors c'est plus facile à faire avec un Linux.

En l'occurrence, ce n'est pas ce que tu as écris: tu reproches à
Windows de limiter les utilisateurs,

Oui. Windows® est une sombre merde. Quoique tu veuilles faire, tu sais
que ça va mal se passer...

Du tout, c'est quoi que *tu* veuilles faire, mais à te lire j'ai
l'impression que la limite est située entre la chaise et le clavier. Tu
me fais un peu penser à ce collègue qui, d'un simple regard, faisait
planter n'importe quelle machine. Il suffisait de lui demander de
refaire exactement les même opérations pour se rendre compte qu'en fait
tout fonctionnait convenablement. C'était devenu un grand sujet de
plaisanterie pour le helpdesk.

et tu propose une solution qui est la meilleure pour limiter les
utilisateurs.

Oui mais là, on ne parle plus de la même limitation. Et je parlais
plutôt de verrouillage. Ça t'avait échappé où tu remplaçais juste un mot
par l'autre pour servir ton troll moisi ?

Donc si tu veux verrouiller les utilisateurs

Oh non, je ne veux surtout pas le faire...

Mais tu *peux*! Il suffit de savoir ce qu'il faut faire, donc de
se former, exactement comme sous n'importe quel OS (ou en
n'importe quel domaine, d'ailleurs).

Il m'est impossible de faire confiance à un OS, conçu par des
esprits malades, qui présente des boîtes de dialogue proposant d'«
activer la désactivation ».

Tu parles bien de cet OS dont certains services se désactivent par la ligne

disable = yes

placée dans les bons fichiers de configuration?

Non, je parlais de cette merde de Windows®.

Pourtant tu fais bien confiance à un OS qui présente des lignes de
fichier de configuration où l'on propose "d'activer la désactivation",
puisque l'extrait ci-dessous vient d'un fichier de conf de xinetd sous
Debian. Encore une fois tu te contredis...

Vous avez filtré cet utilisateur ! Consultez son message

Hugolino a écrit :

Le 21-03-2009, Jerome Lambert a écrit :
Hugolino a écrit :

(...)

Il n'y a aucune contradiction entre dire que windows est une sombre
merde qui ne peut fonctionner que s'il a été verrouillé par un admin
compétent et dire que *si* on veut verrouiller un poste bureautique,
alors c'est plus facile à faire avec un Linux.

En l'occurrence, ce n'est pas ce que tu as écris: tu reproches à
Windows de limiter les utilisateurs,

Oui. Windows® est une sombre merde. Quoique tu veuilles faire, tu sais
que ça va mal se passer...

Du tout, c'est quoi que *tu* veuilles faire, mais à te lire j'ai
l'impression que la limite est située entre la chaise et le clavier. Tu
me fais un peu penser à ce collègue qui, d'un simple regard, faisait
planter n'importe quelle machine. Il suffisait de lui demander de
refaire exactement les même opérations pour se rendre compte qu'en fait
tout fonctionnait convenablement. C'était devenu un grand sujet de
plaisanterie pour le helpdesk.

et tu propose une solution qui est la meilleure pour limiter les
utilisateurs.

Oui mais là, on ne parle plus de la même limitation. Et je parlais
plutôt de verrouillage. Ça t'avait échappé où tu remplaçais juste un mot
par l'autre pour servir ton troll moisi ?

Donc si tu veux verrouiller les utilisateurs

Oh non, je ne veux surtout pas le faire...

Mais tu *peux*! Il suffit de savoir ce qu'il faut faire, donc de
se former, exactement comme sous n'importe quel OS (ou en
n'importe quel domaine, d'ailleurs).

Il m'est impossible de faire confiance à un OS, conçu par des
esprits malades, qui présente des boîtes de dialogue proposant d'«
activer la désactivation ».

Tu parles bien de cet OS dont certains services se désactivent par la ligne

disable = yes

placée dans les bons fichiers de configuration?

Non, je parlais de cette merde de Windows®.

Pourtant tu fais bien confiance à un OS qui présente des lignes de
fichier de configuration où l'on propose "d'activer la désactivation",
puisque l'extrait ci-dessous vient d'un fichier de conf de xinetd sous
Debian. Encore une fois tu te contredis...

Nicolas George

21/03/2009 à 15:33

Jerome Lambert , dans le message
<49c4f5dc$0$2846$, a écrit :

Un Windows *bien géré* ne pose pas plus de problèmes que quoi ce soit
d'autres.

Si, ça pose des problèmes à celui qui le gère.

Kevin Denis

21/03/2009 à 15:43

Le 21-03-2009, JKB a écrit :

Le slow ssh keyscan, c'est un botnet constitué de beaucoup de machines,
dont _chacune_ demande _un_ mot de passe à ta machine. Je ne vois pas en
quoi fail2ban peut aider, mais si tu as une configuration qui permet
d'être tranquille, je la prends.

Oui, j'ai une configuration qui me permet d'être tranquille parce
que j'utilise mes propres modules dans fail2ban. En particulier je
blackliste toutes les adresses en dehors d'un pool de whitelist dès que
j'ai trop d'erreurs dans les logs.

Ok.
Donc tu es incapable de savoir à l'avance si tu es capable de te logger
depuis une IP qui ne fait pas partie de la whitelist?
Autant limiter directement l'accès au pool d'IP whitelisté.

[certificat de deux ans]

Dommage.

Oh oui, tu peux le dire.

Non. Je suis paranoïaque et les utilisateurs n'ont généralement
pas à se logguer directement sur mes machines.

Je parle d'utilisateurs sous debian qui se loggent ailleurs. Pas des
utilisateurs qui se loggent sur une debian.

Le problème est le suivant:
J'ai une fedora. Un gars sous debian se logge chez moi.
La faille openssl debian est divulguée. Alors que je suis sous _fedora_ je
dois me dépecher de corriger le problème.

Lorsqu'une faille windows sort, je ne suis pas impacté car je ne suis
pas sous windows. Lorsqu'une faille d'un système autre que le mien me
touche directement, je ne suis pas content.

Imaginons un site web https protégé par fail2ban dont l'accès se
fait via un login/pass. Je sniffe l'échange de trafic, je déchiffre,

Sniffe tant que tu veux.

La confidentialité des informations échangées entre ton site web et ton
client n'est pas importante? Il y a beaucoup d'autres choses à récupérer
qu'un login/password.

Cette faille a touché beaucoup de monde, elle est dramatique, et sa portée
dépasse très largement une faille comme vmsplice qui te permet seulement
de passer root à la condition d'avoir déjà un compte shell sur la
machine..

C'est au contraire _très_ facile vu le nombre de machines
administrées par des pieds

Certes. Donc tu considères la faille debian mineure parceque tu n'es
pas touché car tu es paranoïaque et la faille vmsplice majeure car des
machines mal administrées se sont fait percer, c'est ça?

Non, les deux sont emmerdantes et pour les mêmes raisons, à savoir
l'incompétence des administrateurs.

Si tu n'as pas le noyau concerné, tu n'est _pas_ impacté par la faille
vmsplice.
Si tu n'as pas de debian, tu _es_ concerné par la faille debian.
Et pour moi, c'est une énorme différence dans laquelle la compétence
des administrateurs n'a rien à voir.

Quand Peugeot détecte un problème sur un de ses modèles, il fait revenir
ses voitures. Dans le cas de la faille opensssl, Peugeot aurait du
demander à _tous_ les constructeurs auto de faire revenir leurs
modèles. C'est quand même d'une autre portée.

De plus, cette faille debian s'étale dans le temps. Imagine que tu aies
des captures réseaux chiffrées. Ca ne coûte pas cher de vérifier si elles
ont été faites avec une des clés faibles debian. Alors que la faille
vmsplice, une fois corrigée, c'est fini.

<EOT> pour moi. Cette discussion ne mène vraiment nulle part.
--
Kevin

Le 21-03-2009, JKB <knatschke@koenigsberg.fr> a écrit :

Le slow ssh keyscan, c'est un botnet constitué de beaucoup de machines,
dont _chacune_ demande _un_ mot de passe à ta machine. Je ne vois pas en
quoi fail2ban peut aider, mais si tu as une configuration qui permet
d'être tranquille, je la prends.

Oui, j'ai une configuration qui me permet d'être tranquille parce
que j'utilise mes propres modules dans fail2ban. En particulier je
blackliste toutes les adresses en dehors d'un pool de whitelist dès que
j'ai trop d'erreurs dans les logs.

Ok.
Donc tu es incapable de savoir à l'avance si tu es capable de te logger
depuis une IP qui ne fait pas partie de la whitelist?
Autant limiter directement l'accès au pool d'IP whitelisté.

[certificat de deux ans]

Dommage.

Oh oui, tu peux le dire.

Non. Je suis paranoïaque et les utilisateurs n'ont généralement
pas à se logguer directement sur mes machines.

Je parle d'utilisateurs sous debian qui se loggent ailleurs. Pas des
utilisateurs qui se loggent sur une debian.

Le problème est le suivant:
J'ai une fedora. Un gars sous debian se logge chez moi.
La faille openssl debian est divulguée. Alors que je suis sous _fedora_ je
dois me dépecher de corriger le problème.

Lorsqu'une faille windows sort, je ne suis pas impacté car je ne suis
pas sous windows. Lorsqu'une faille d'un système autre que le mien me
touche directement, je ne suis pas content.

Imaginons un site web https protégé par fail2ban dont l'accès se
fait via un login/pass. Je sniffe l'échange de trafic, je déchiffre,

Sniffe tant que tu veux.

La confidentialité des informations échangées entre ton site web et ton
client n'est pas importante? Il y a beaucoup d'autres choses à récupérer
qu'un login/password.

Cette faille a touché beaucoup de monde, elle est dramatique, et sa portée
dépasse très largement une faille comme vmsplice qui te permet seulement
de passer root à la condition d'avoir déjà un compte shell sur la
machine..

C'est au contraire _très_ facile vu le nombre de machines
administrées par des pieds

Certes. Donc tu considères la faille debian mineure parceque tu n'es
pas touché car tu es paranoïaque et la faille vmsplice majeure car des
machines mal administrées se sont fait percer, c'est ça?

Non, les deux sont emmerdantes et pour les mêmes raisons, à savoir
l'incompétence des administrateurs.

Si tu n'as pas le noyau concerné, tu n'est _pas_ impacté par la faille
vmsplice.
Si tu n'as pas de debian, tu _es_ concerné par la faille debian.
Et pour moi, c'est une énorme différence dans laquelle la compétence
des administrateurs n'a rien à voir.

Quand Peugeot détecte un problème sur un de ses modèles, il fait revenir
ses voitures. Dans le cas de la faille opensssl, Peugeot aurait du
demander à _tous_ les constructeurs auto de faire revenir leurs
modèles. C'est quand même d'une autre portée.

De plus, cette faille debian s'étale dans le temps. Imagine que tu aies
des captures réseaux chiffrées. Ca ne coûte pas cher de vérifier si elles
ont été faites avec une des clés faibles debian. Alors que la faille
vmsplice, une fois corrigée, c'est fini.

<EOT> pour moi. Cette discussion ne mène vraiment nulle part.
--
Kevin

Vous avez filtré cet utilisateur ! Consultez son message

Le 21-03-2009, JKB a écrit :

Le slow ssh keyscan, c'est un botnet constitué de beaucoup de machines,
dont _chacune_ demande _un_ mot de passe à ta machine. Je ne vois pas en
quoi fail2ban peut aider, mais si tu as une configuration qui permet
d'être tranquille, je la prends.

Oui, j'ai une configuration qui me permet d'être tranquille parce
que j'utilise mes propres modules dans fail2ban. En particulier je
blackliste toutes les adresses en dehors d'un pool de whitelist dès que
j'ai trop d'erreurs dans les logs.

Ok.
Donc tu es incapable de savoir à l'avance si tu es capable de te logger
depuis une IP qui ne fait pas partie de la whitelist?
Autant limiter directement l'accès au pool d'IP whitelisté.

[certificat de deux ans]

Dommage.

Oh oui, tu peux le dire.

Non. Je suis paranoïaque et les utilisateurs n'ont généralement
pas à se logguer directement sur mes machines.

Je parle d'utilisateurs sous debian qui se loggent ailleurs. Pas des
utilisateurs qui se loggent sur une debian.

Le problème est le suivant:
J'ai une fedora. Un gars sous debian se logge chez moi.
La faille openssl debian est divulguée. Alors que je suis sous _fedora_ je
dois me dépecher de corriger le problème.

Lorsqu'une faille windows sort, je ne suis pas impacté car je ne suis
pas sous windows. Lorsqu'une faille d'un système autre que le mien me
touche directement, je ne suis pas content.

Imaginons un site web https protégé par fail2ban dont l'accès se
fait via un login/pass. Je sniffe l'échange de trafic, je déchiffre,

Sniffe tant que tu veux.

La confidentialité des informations échangées entre ton site web et ton
client n'est pas importante? Il y a beaucoup d'autres choses à récupérer
qu'un login/password.

Cette faille a touché beaucoup de monde, elle est dramatique, et sa portée
dépasse très largement une faille comme vmsplice qui te permet seulement
de passer root à la condition d'avoir déjà un compte shell sur la
machine..

C'est au contraire _très_ facile vu le nombre de machines
administrées par des pieds

Certes. Donc tu considères la faille debian mineure parceque tu n'es
pas touché car tu es paranoïaque et la faille vmsplice majeure car des
machines mal administrées se sont fait percer, c'est ça?

Non, les deux sont emmerdantes et pour les mêmes raisons, à savoir
l'incompétence des administrateurs.

Si tu n'as pas le noyau concerné, tu n'est _pas_ impacté par la faille
vmsplice.
Si tu n'as pas de debian, tu _es_ concerné par la faille debian.
Et pour moi, c'est une énorme différence dans laquelle la compétence
des administrateurs n'a rien à voir.

Quand Peugeot détecte un problème sur un de ses modèles, il fait revenir
ses voitures. Dans le cas de la faille opensssl, Peugeot aurait du
demander à _tous_ les constructeurs auto de faire revenir leurs
modèles. C'est quand même d'une autre portée.

De plus, cette faille debian s'étale dans le temps. Imagine que tu aies
des captures réseaux chiffrées. Ca ne coûte pas cher de vérifier si elles
ont été faites avec une des clés faibles debian. Alors que la faille
vmsplice, une fois corrigée, c'est fini.

<EOT> pour moi. Cette discussion ne mène vraiment nulle part.
--
Kevin

pascal

21/03/2009 à 16:58

> certainement, au moins autant que ta responsabilité dans la position
dominante de microsoft.

Dominante ça reste à prouver je suis une toute petite pme utilisant linux
pour mon serveur apache, sql, et que je veux mettre en place un système
de gestion en ligne de compta qui permettrais au fisc de contrôler mes
déclarations ceux ci ne veulent pas en entendre parler alors qu'il
serais plus simple pour eux de contrôler directement à la source
comptable . Tu me diras même ma compta n'est pas pour mais je fait un
forcing pour que toute ma gestion commercial/ compta soit dispo sur un
serveur linux et la c'est pas gagné.

Ubuntu Ultimate Edition

10 réponses

Veuillez sélectionner un problème