Des slacks, j'en ai eu. L'immense majorité des softs est brute de
fonderie. Les fichiers sont donc à l'emplacement décidé par le type qui
a pondu le logiciel, et souvent, cet emplacement est aberrant. Tu te
retrouves donc avec de la configuration dans /var, des exécutables dans
/etc, de la configuration à nouveau dans /lib et j'en passe. Il y a un
gros boulot pour unifier tout cela.
Je me le suis paluché à une époque, avec recompilation des softs que
j'utilisais .... Mais comme je ne suis pas fan des environnements
intégrés tel que KDE ou Gnome, et que les softs utilisés étaient
relativement limités en nombre, je pouvais m'en sortir avec les bonnes
options passées à configure.
cela dit dans le cas d'un poste de travail avec du KDE,Gnome et
Openoffice, je pense que je ne le ferais pas ...
Des slacks, j'en ai eu. L'immense majorité des softs est brute de
fonderie. Les fichiers sont donc à l'emplacement décidé par le type qui
a pondu le logiciel, et souvent, cet emplacement est aberrant. Tu te
retrouves donc avec de la configuration dans /var, des exécutables dans
/etc, de la configuration à nouveau dans /lib et j'en passe. Il y a un
gros boulot pour unifier tout cela.
Je me le suis paluché à une époque, avec recompilation des softs que
j'utilisais .... Mais comme je ne suis pas fan des environnements
intégrés tel que KDE ou Gnome, et que les softs utilisés étaient
relativement limités en nombre, je pouvais m'en sortir avec les bonnes
options passées à configure.
cela dit dans le cas d'un poste de travail avec du KDE,Gnome et
Openoffice, je pense que je ne le ferais pas ...
Des slacks, j'en ai eu. L'immense majorité des softs est brute de
fonderie. Les fichiers sont donc à l'emplacement décidé par le type qui
a pondu le logiciel, et souvent, cet emplacement est aberrant. Tu te
retrouves donc avec de la configuration dans /var, des exécutables dans
/etc, de la configuration à nouveau dans /lib et j'en passe. Il y a un
gros boulot pour unifier tout cela.
Je me le suis paluché à une époque, avec recompilation des softs que
j'utilisais .... Mais comme je ne suis pas fan des environnements
intégrés tel que KDE ou Gnome, et que les softs utilisés étaient
relativement limités en nombre, je pouvais m'en sortir avec les bonnes
options passées à configure.
cela dit dans le cas d'un poste de travail avec du KDE,Gnome et
Openoffice, je pense que je ne le ferais pas ...
Oui bien sûr. Il y a qqs temps j'ai installé un serveur apach e sur mon
NAS. Le fichier de conf n'est pas dans /etc : j'aimerais bien savoir
pourquoi ?
Non bien sûr. Mais vu que ça fait partie de l'installation de base de
Windows, ça ne pose pas vraiment de problème que ce soit comm e ça.
A nuancer quand même : si un jour tu as besoin d'une appli ou d'un e
version qui n'est pas dans les dépôts, la méthode unique en prend un
coup.
Sous windows, c'est le souk
total, il existe tellement d'installeurs différents, que le systà ¨me est
incapable de désinstaller correctement une appli!
Ce qui n'est pas bien grave à partir du moment où l'appli est
"autonome" et ne s'est pas répandu dans tout le système.
Me fait pas rire avec cet argument... Ca prend combien de place sur le
disque, IE ? Combien font les disques de base d'aujourd'hui ?
Si tu veux faire un serveur tu commences par prendre un OS fait pour
plutôt que de bricoler un OS pas prévu pour
C'est le cas. Sauf sur cette saleté de station de travail qui me soule.
C'est vrai que t'as des gros problèmes dans la vie. Faire un caca
nerveux parce qu'on ne peut pas enlever IE, alors même que ça
n'empêche pas d'utiliser un autre navigateur, faut le faire.
Absolument. Ca apporterait quoi et à qui que MS supprime IE de
l'install de base ?
D'ailleurs, combien de versions "N" de Windows (dépourvues de WMP) MS
a-t-il vendu, qu'on rigole ?
Où est la décision de justice qui dit que c'est illégal concernant
IE ?
Oui bien sûr. Il y a qqs temps j'ai installé un serveur apach e sur mon
NAS. Le fichier de conf n'est pas dans /etc : j'aimerais bien savoir
pourquoi ?
Non bien sûr. Mais vu que ça fait partie de l'installation de base de
Windows, ça ne pose pas vraiment de problème que ce soit comm e ça.
A nuancer quand même : si un jour tu as besoin d'une appli ou d'un e
version qui n'est pas dans les dépôts, la méthode unique en prend un
coup.
Sous windows, c'est le souk
total, il existe tellement d'installeurs différents, que le systà ¨me est
incapable de désinstaller correctement une appli!
Ce qui n'est pas bien grave à partir du moment où l'appli est
"autonome" et ne s'est pas répandu dans tout le système.
Me fait pas rire avec cet argument... Ca prend combien de place sur le
disque, IE ? Combien font les disques de base d'aujourd'hui ?
Si tu veux faire un serveur tu commences par prendre un OS fait pour
plutôt que de bricoler un OS pas prévu pour
C'est le cas. Sauf sur cette saleté de station de travail qui me soule.
C'est vrai que t'as des gros problèmes dans la vie. Faire un caca
nerveux parce qu'on ne peut pas enlever IE, alors même que ça
n'empêche pas d'utiliser un autre navigateur, faut le faire.
Absolument. Ca apporterait quoi et à qui que MS supprime IE de
l'install de base ?
D'ailleurs, combien de versions "N" de Windows (dépourvues de WMP) MS
a-t-il vendu, qu'on rigole ?
Où est la décision de justice qui dit que c'est illégal concernant
IE ?
Oui bien sûr. Il y a qqs temps j'ai installé un serveur apach e sur mon
NAS. Le fichier de conf n'est pas dans /etc : j'aimerais bien savoir
pourquoi ?
Non bien sûr. Mais vu que ça fait partie de l'installation de base de
Windows, ça ne pose pas vraiment de problème que ce soit comm e ça.
A nuancer quand même : si un jour tu as besoin d'une appli ou d'un e
version qui n'est pas dans les dépôts, la méthode unique en prend un
coup.
Sous windows, c'est le souk
total, il existe tellement d'installeurs différents, que le systà ¨me est
incapable de désinstaller correctement une appli!
Ce qui n'est pas bien grave à partir du moment où l'appli est
"autonome" et ne s'est pas répandu dans tout le système.
Me fait pas rire avec cet argument... Ca prend combien de place sur le
disque, IE ? Combien font les disques de base d'aujourd'hui ?
Si tu veux faire un serveur tu commences par prendre un OS fait pour
plutôt que de bricoler un OS pas prévu pour
C'est le cas. Sauf sur cette saleté de station de travail qui me soule.
C'est vrai que t'as des gros problèmes dans la vie. Faire un caca
nerveux parce qu'on ne peut pas enlever IE, alors même que ça
n'empêche pas d'utiliser un autre navigateur, faut le faire.
Absolument. Ca apporterait quoi et à qui que MS supprime IE de
l'install de base ?
D'ailleurs, combien de versions "N" de Windows (dépourvues de WMP) MS
a-t-il vendu, qu'on rigole ?
Où est la décision de justice qui dit que c'est illégal concernant
IE ?
Il ne t'aura surement pas échappé que man et man_db sont deux programmes
différents. Pourquoi tu me parles de la conf de man_db alors que je
parle de la conf de man?
Justement, éclaire ma lanterne, parce que je ne vois rien qui
ressemble à de la configuration de man dans la sous-arborescence de
/usr/lib.
Le mainteneur debian a ajouté une section. C'est une habitude de
debian de modifier les fichiers originaux. On modifie des fichiers README,
puis des fichiers de conf, puis des codes sources et on se retrouve
percé pendant deux ans.
Mauvaise pioche.
Et http://www.debian.org/security/2008/dsa-1571 c'est du mou de veau?
Non. Ce n'est pas du mou de veau. Sauf que je ne suis pas bien sûr
que tu aies tout compris à l'affaire.
Donc dans la pratique, cette faille n'impactait que les
machines qui voulaient bien être touchées.
Par ailleurs, dès sa découverte, le truc a été corrigé. C'est tout
de même mieux que la faille vmslice qui a traîné durant longtemps et qui
permettait de faire des choses assez amusantes.
Il ne t'aura surement pas échappé que man et man_db sont deux programmes
différents. Pourquoi tu me parles de la conf de man_db alors que je
parle de la conf de man?
Justement, éclaire ma lanterne, parce que je ne vois rien qui
ressemble à de la configuration de man dans la sous-arborescence de
/usr/lib.
Le mainteneur debian a ajouté une section. C'est une habitude de
debian de modifier les fichiers originaux. On modifie des fichiers README,
puis des fichiers de conf, puis des codes sources et on se retrouve
percé pendant deux ans.
Mauvaise pioche.
Et http://www.debian.org/security/2008/dsa-1571 c'est du mou de veau?
Non. Ce n'est pas du mou de veau. Sauf que je ne suis pas bien sûr
que tu aies tout compris à l'affaire.
Donc dans la pratique, cette faille n'impactait que les
machines qui voulaient bien être touchées.
Par ailleurs, dès sa découverte, le truc a été corrigé. C'est tout
de même mieux que la faille vmslice qui a traîné durant longtemps et qui
permettait de faire des choses assez amusantes.
Il ne t'aura surement pas échappé que man et man_db sont deux programmes
différents. Pourquoi tu me parles de la conf de man_db alors que je
parle de la conf de man?
Justement, éclaire ma lanterne, parce que je ne vois rien qui
ressemble à de la configuration de man dans la sous-arborescence de
/usr/lib.
Le mainteneur debian a ajouté une section. C'est une habitude de
debian de modifier les fichiers originaux. On modifie des fichiers README,
puis des fichiers de conf, puis des codes sources et on se retrouve
percé pendant deux ans.
Mauvaise pioche.
Et http://www.debian.org/security/2008/dsa-1571 c'est du mou de veau?
Non. Ce n'est pas du mou de veau. Sauf que je ne suis pas bien sûr
que tu aies tout compris à l'affaire.
Donc dans la pratique, cette faille n'impactait que les
machines qui voulaient bien être touchées.
Par ailleurs, dès sa découverte, le truc a été corrigé. C'est tout
de même mieux que la faille vmslice qui a traîné durant longtemps et qui
permettait de faire des choses assez amusantes.
Le 20-03-2009, JKB a écrit :Il ne t'aura surement pas échappé que man et man_db sont deux programmes
différents. Pourquoi tu me parles de la conf de man_db alors que je
parle de la conf de man?
Justement, éclaire ma lanterne, parce que je ne vois rien qui
ressemble à de la configuration de man dans la sous-arborescence de
/usr/lib.
Je reprends, calmement. man et man_db sont deux programmes différents,
qui ont des codes sources différents, qui ont des fichiers de
configuration differents dont l'emplacement est différent. man et
man_db permettent de faire la même chose (lire des pages man) mais
ils s'agit de deux programmes _différents_. Dans les deux programmes,
le binaire s'appelle 'man' ce qui peut prêter à confusion (même si
j'avais pris le soin de mettre une note en bas de page)
Tu as sur ta debian le programme man_db, dont la configuration
est sous /etc. Mais, bis repetita, debian n'est pas linux.
Je parle du programme man, que tu n'as pas sur ta
distribution debian, donc tu peux chercher le fichier de conf
sur ta distribution, tu ne le trouveras pas.
Le mainteneur debian a ajouté une section. C'est une habitude de
debian de modifier les fichiers originaux. On modifie des fichiers README,
puis des fichiers de conf, puis des codes sources et on se retrouve
percé pendant deux ans.
Mauvaise pioche.
Et http://www.debian.org/security/2008/dsa-1571 c'est du mou de veau?
Non. Ce n'est pas du mou de veau. Sauf que je ne suis pas bien sûr
que tu aies tout compris à l'affaire.
L'affaire c'est debian qui s'amuse à modifier des fichiers sources
et qui se retrouve avec un trou tellement gros que même la sécu fait
amateur à côté.
Maintenant, il se trouve que j'ai particulièrement eu à suivre
l'affaire. Et contrairement à toi, j'ai compris que ssh était loin
d'être le seul composant impacté par cette faille.
Mais il est très confortable de penser que seul ssh est impacté.
Ainsi "il suffisait d'un fail2ban" après tout. Raisonnement un
poil court (dans tous les sens du terme; et sur le fait que
fail2ban suffit, et sur le fait que c'est la seule action à mener).
,----------------------------------------------------------------.
| > Il faut que les clefs aient été créées avec _cette_ version |
| > spécifique de la bibliothèque. |
`----------------------------------------------------------------'
Ca s'encadre. openssl est resté moisi pendant deux ans, mais il
suffisait de ne pas l'utiliser. C'est évident.
Donc dans la pratique, cette faille n'impactait que les
machines qui voulaient bien être touchées.
C'est faux, mais comme tu es persuadé que seul ssh était impacté, c'est
seulement vrai pour toi.
Par ailleurs, dès sa découverte, le truc a été corrigé. C'est tout
de même mieux que la faille vmslice qui a traîné durant longtemps et qui
permettait de faire des choses assez amusantes.
C'est vmsplice. Mais nous ne sommes plus à une approximation près,
nous sommes sur fcold.
Le 20-03-2009, JKB <knatschke@koenigsberg.fr> a écrit :
Il ne t'aura surement pas échappé que man et man_db sont deux programmes
différents. Pourquoi tu me parles de la conf de man_db alors que je
parle de la conf de man?
Justement, éclaire ma lanterne, parce que je ne vois rien qui
ressemble à de la configuration de man dans la sous-arborescence de
/usr/lib.
Je reprends, calmement. man et man_db sont deux programmes différents,
qui ont des codes sources différents, qui ont des fichiers de
configuration differents dont l'emplacement est différent. man et
man_db permettent de faire la même chose (lire des pages man) mais
ils s'agit de deux programmes _différents_. Dans les deux programmes,
le binaire s'appelle 'man' ce qui peut prêter à confusion (même si
j'avais pris le soin de mettre une note en bas de page)
Tu as sur ta debian le programme man_db, dont la configuration
est sous /etc. Mais, bis repetita, debian n'est pas linux.
Je parle du programme man, que tu n'as pas sur ta
distribution debian, donc tu peux chercher le fichier de conf
sur ta distribution, tu ne le trouveras pas.
Le mainteneur debian a ajouté une section. C'est une habitude de
debian de modifier les fichiers originaux. On modifie des fichiers README,
puis des fichiers de conf, puis des codes sources et on se retrouve
percé pendant deux ans.
Mauvaise pioche.
Et http://www.debian.org/security/2008/dsa-1571 c'est du mou de veau?
Non. Ce n'est pas du mou de veau. Sauf que je ne suis pas bien sûr
que tu aies tout compris à l'affaire.
L'affaire c'est debian qui s'amuse à modifier des fichiers sources
et qui se retrouve avec un trou tellement gros que même la sécu fait
amateur à côté.
Maintenant, il se trouve que j'ai particulièrement eu à suivre
l'affaire. Et contrairement à toi, j'ai compris que ssh était loin
d'être le seul composant impacté par cette faille.
Mais il est très confortable de penser que seul ssh est impacté.
Ainsi "il suffisait d'un fail2ban" après tout. Raisonnement un
poil court (dans tous les sens du terme; et sur le fait que
fail2ban suffit, et sur le fait que c'est la seule action à mener).
,----------------------------------------------------------------.
| > Il faut que les clefs aient été créées avec _cette_ version |
| > spécifique de la bibliothèque. |
`----------------------------------------------------------------'
Ca s'encadre. openssl est resté moisi pendant deux ans, mais il
suffisait de ne pas l'utiliser. C'est évident.
Donc dans la pratique, cette faille n'impactait que les
machines qui voulaient bien être touchées.
C'est faux, mais comme tu es persuadé que seul ssh était impacté, c'est
seulement vrai pour toi.
Par ailleurs, dès sa découverte, le truc a été corrigé. C'est tout
de même mieux que la faille vmslice qui a traîné durant longtemps et qui
permettait de faire des choses assez amusantes.
C'est vmsplice. Mais nous ne sommes plus à une approximation près,
nous sommes sur fcold.
Le 20-03-2009, JKB a écrit :Il ne t'aura surement pas échappé que man et man_db sont deux programmes
différents. Pourquoi tu me parles de la conf de man_db alors que je
parle de la conf de man?
Justement, éclaire ma lanterne, parce que je ne vois rien qui
ressemble à de la configuration de man dans la sous-arborescence de
/usr/lib.
Je reprends, calmement. man et man_db sont deux programmes différents,
qui ont des codes sources différents, qui ont des fichiers de
configuration differents dont l'emplacement est différent. man et
man_db permettent de faire la même chose (lire des pages man) mais
ils s'agit de deux programmes _différents_. Dans les deux programmes,
le binaire s'appelle 'man' ce qui peut prêter à confusion (même si
j'avais pris le soin de mettre une note en bas de page)
Tu as sur ta debian le programme man_db, dont la configuration
est sous /etc. Mais, bis repetita, debian n'est pas linux.
Je parle du programme man, que tu n'as pas sur ta
distribution debian, donc tu peux chercher le fichier de conf
sur ta distribution, tu ne le trouveras pas.
Le mainteneur debian a ajouté une section. C'est une habitude de
debian de modifier les fichiers originaux. On modifie des fichiers README,
puis des fichiers de conf, puis des codes sources et on se retrouve
percé pendant deux ans.
Mauvaise pioche.
Et http://www.debian.org/security/2008/dsa-1571 c'est du mou de veau?
Non. Ce n'est pas du mou de veau. Sauf que je ne suis pas bien sûr
que tu aies tout compris à l'affaire.
L'affaire c'est debian qui s'amuse à modifier des fichiers sources
et qui se retrouve avec un trou tellement gros que même la sécu fait
amateur à côté.
Maintenant, il se trouve que j'ai particulièrement eu à suivre
l'affaire. Et contrairement à toi, j'ai compris que ssh était loin
d'être le seul composant impacté par cette faille.
Mais il est très confortable de penser que seul ssh est impacté.
Ainsi "il suffisait d'un fail2ban" après tout. Raisonnement un
poil court (dans tous les sens du terme; et sur le fait que
fail2ban suffit, et sur le fait que c'est la seule action à mener).
,----------------------------------------------------------------.
| > Il faut que les clefs aient été créées avec _cette_ version |
| > spécifique de la bibliothèque. |
`----------------------------------------------------------------'
Ca s'encadre. openssl est resté moisi pendant deux ans, mais il
suffisait de ne pas l'utiliser. C'est évident.
Donc dans la pratique, cette faille n'impactait que les
machines qui voulaient bien être touchées.
C'est faux, mais comme tu es persuadé que seul ssh était impacté, c'est
seulement vrai pour toi.
Par ailleurs, dès sa découverte, le truc a été corrigé. C'est tout
de même mieux que la faille vmslice qui a traîné durant longtemps et qui
permettait de faire des choses assez amusantes.
C'est vmsplice. Mais nous ne sommes plus à une approximation près,
nous sommes sur fcold.
Il ne t'aura surement pas échappé que man et man_db sont deux programmes
différents. Pourquoi tu me parles de la conf de man_db alors que je
parle de la conf de man?
Je viens de regarder sous Solaris et sous NetBSD, même motif, même
punition.
L'affaire c'est debian qui s'amuse à modifier des fichiers sources
et qui se retrouve avec un trou tellement gros que même la sécu fait
amateur à côté.
Maintenant, il se trouve que j'ai particulièrement eu à suivre
l'affaire. Et contrairement à toi, j'ai compris que ssh était loin
d'être le seul composant impacté par cette faille.
Je n'ai _jamais_ prétendu que c'était le seul.
Mais il est très confortable de penser que seul ssh est impacté.
Ainsi "il suffisait d'un fail2ban" après tout. Raisonnement un
poil court (dans tous les sens du terme; et sur le fait que
fail2ban suffit, et sur le fait que c'est la seule action à mener).
Euh... Chez moi, fail2ban bannit tout ce qui permet un accès
extérieur à une machine. Je te laisse conclure.
,----------------------------------------------------------------.
| > Il faut que les clefs aient été créées avec _cette_ version |
| > spécifique de la bibliothèque. |
`----------------------------------------------------------------'
Je n'ai qu'une seule machine qui était compromise (et c'est le
certificat https qui avait été recréé par mes soins avec effectivement
un openssl debian, et seulement celui-ci).
Donc dans la pratique, cette faille n'impactait que les
machines qui voulaient bien être touchées.
C'est faux, mais comme tu es persuadé que seul ssh était impacté, c'est
seulement vrai pour toi.
Je n'ai _jamais_ écrit ça. J'ai juste donné un exemple,
De plus en plus petit.
Il ne t'aura surement pas échappé que man et man_db sont deux programmes
différents. Pourquoi tu me parles de la conf de man_db alors que je
parle de la conf de man?
Je viens de regarder sous Solaris et sous NetBSD, même motif, même
punition.
L'affaire c'est debian qui s'amuse à modifier des fichiers sources
et qui se retrouve avec un trou tellement gros que même la sécu fait
amateur à côté.
Maintenant, il se trouve que j'ai particulièrement eu à suivre
l'affaire. Et contrairement à toi, j'ai compris que ssh était loin
d'être le seul composant impacté par cette faille.
Je n'ai _jamais_ prétendu que c'était le seul.
Mais il est très confortable de penser que seul ssh est impacté.
Ainsi "il suffisait d'un fail2ban" après tout. Raisonnement un
poil court (dans tous les sens du terme; et sur le fait que
fail2ban suffit, et sur le fait que c'est la seule action à mener).
Euh... Chez moi, fail2ban bannit tout ce qui permet un accès
extérieur à une machine. Je te laisse conclure.
,----------------------------------------------------------------.
| > Il faut que les clefs aient été créées avec _cette_ version |
| > spécifique de la bibliothèque. |
`----------------------------------------------------------------'
Je n'ai qu'une seule machine qui était compromise (et c'est le
certificat https qui avait été recréé par mes soins avec effectivement
un openssl debian, et seulement celui-ci).
Donc dans la pratique, cette faille n'impactait que les
machines qui voulaient bien être touchées.
C'est faux, mais comme tu es persuadé que seul ssh était impacté, c'est
seulement vrai pour toi.
Je n'ai _jamais_ écrit ça. J'ai juste donné un exemple,
De plus en plus petit.
Il ne t'aura surement pas échappé que man et man_db sont deux programmes
différents. Pourquoi tu me parles de la conf de man_db alors que je
parle de la conf de man?
Je viens de regarder sous Solaris et sous NetBSD, même motif, même
punition.
L'affaire c'est debian qui s'amuse à modifier des fichiers sources
et qui se retrouve avec un trou tellement gros que même la sécu fait
amateur à côté.
Maintenant, il se trouve que j'ai particulièrement eu à suivre
l'affaire. Et contrairement à toi, j'ai compris que ssh était loin
d'être le seul composant impacté par cette faille.
Je n'ai _jamais_ prétendu que c'était le seul.
Mais il est très confortable de penser que seul ssh est impacté.
Ainsi "il suffisait d'un fail2ban" après tout. Raisonnement un
poil court (dans tous les sens du terme; et sur le fait que
fail2ban suffit, et sur le fait que c'est la seule action à mener).
Euh... Chez moi, fail2ban bannit tout ce qui permet un accès
extérieur à une machine. Je te laisse conclure.
,----------------------------------------------------------------.
| > Il faut que les clefs aient été créées avec _cette_ version |
| > spécifique de la bibliothèque. |
`----------------------------------------------------------------'
Je n'ai qu'une seule machine qui était compromise (et c'est le
certificat https qui avait été recréé par mes soins avec effectivement
un openssl debian, et seulement celui-ci).
Donc dans la pratique, cette faille n'impactait que les
machines qui voulaient bien être touchées.
C'est faux, mais comme tu es persuadé que seul ssh était impacté, c'est
seulement vrai pour toi.
Je n'ai _jamais_ écrit ça. J'ai juste donné un exemple,
De plus en plus petit.
Tu veux un compte shell chez moi pour taper ls /usr/lib/man.conf
ou un lien vers le source de man suffira? -> /dev/null, on va pas passer
quinze posts pour que tu comprennes que le programme man pose ses
fichiers de conf sous /usr/lib.
Tu veux un compte shell chez moi pour taper ls /usr/lib/man.conf
ou un lien vers le source de man suffira? -> /dev/null, on va pas passer
quinze posts pour que tu comprennes que le programme man pose ses
fichiers de conf sous /usr/lib.
Tu veux un compte shell chez moi pour taper ls /usr/lib/man.conf
ou un lien vers le source de man suffira? -> /dev/null, on va pas passer
quinze posts pour que tu comprennes que le programme man pose ses
fichiers de conf sous /usr/lib.
Jeu concours: de quel fichier de conf proviennent ces lignes et que
signifient elle?
R< $+ > $+ < @ $+ > $* $@ $>97 $1
R<> $+ < @ $+ > $* $: $1 < @ $2 > $3
Jeu concours: de quel fichier de conf proviennent ces lignes et que
signifient elle?
R< $+ > $+ < @ $+ > $* $@ $>97 $1
R<> $+ < @ $+ > $* $: $1 < @ $2 > $3
Jeu concours: de quel fichier de conf proviennent ces lignes et que
signifient elle?
R< $+ > $+ < @ $+ > $* $@ $>97 $1
R<> $+ < @ $+ > $* $: $1 < @ $2 > $3
Bon, tu utilises une distribution qui t'installe une version pourrave de
man sans prendre le soin d'en corriger les bugs les plus grotesques. À part
le fait que tu utilises une distribution merdique, tu en déduis quoi, a u
juste ?
Bon, tu utilises une distribution qui t'installe une version pourrave de
man sans prendre le soin d'en corriger les bugs les plus grotesques. À part
le fait que tu utilises une distribution merdique, tu en déduis quoi, a u
juste ?
Bon, tu utilises une distribution qui t'installe une version pourrave de
man sans prendre le soin d'en corriger les bugs les plus grotesques. À part
le fait que tu utilises une distribution merdique, tu en déduis quoi, a u
juste ?
En conclusion : le paquet man de la Slackware n'est pas si pourrave
que ça,
En conclusion : le paquet man de la Slackware n'est pas si pourrave
que ça,
En conclusion : le paquet man de la Slackware n'est pas si pourrave
que ça,
pehache-tolai a écrit :Oui bien sûr. Il y a qqs temps j'ai installé un serveur apache sur
mon NAS. Le fichier de conf n'est pas dans /etc : j'aimerais bien
savoir pourquoi ?
Merde, tous les serveurs Apache sous Linux que j'utilise ici (une
40aine) ont leur fichier de conf dans /etc. Si t'es pas foutu de
trouver une distribution qui a un minimum de cohérence dans sa
gestion de l'arborescence, c'est ton problème.
Non bien sûr. Mais vu que ça fait partie de l'installation de base de
Windows, ça ne pose pas vraiment de problème que ce soit comme ça.
Ouais ouais, le solitaire, dans l'install de base. Mort de rire.
Composant essentiel du système, et donc DLL dans system32. Grotesque.
A nuancer quand même : si un jour tu as besoin d'une appli ou d'une
version qui n'est pas dans les dépôts, la méthode unique en prend un
coup.
Non. Toutes les distributions fournissent les outils pour fabriquer
soi-même le paquet qui s'intègrera alors dans l'outil de gestion.
Ce qui n'est pas bien grave à partir du moment où l'appli est
"autonome" et ne s'est pas répandu dans tout le système.
Ah parce que toi, tu trouves ça "pas bien grave" d'avoir une BDR
remplie d'entrées qui ne pointent plus vers quoique ce soit,
des DLLs
inutiles dans des répertoires qu'ils soient system32 ou n'importe
quel autre quand tu as désinstallé un programme via le panneau de
configuration?
Me fait pas rire avec cet argument... Ca prend combien de place sur
le disque, IE ? Combien font les disques de base d'aujourd'hui ?
Le disque de base d'un eeepc c'est 4Go.
Et pourquoi diable suis-je
obligé d'avoir sur mon disque des softs dont je n'ai pas besoin?
Si tu veux faire un serveur tu commences par prendre un OS fait pour
plutôt que de bricoler un OS pas prévu pour
Windows NT3.51, Windows NT4, Windows 2000, Windows 2003, Windows 2008,
MS vend ou a vendu tout ça comme étant des OS serveurs. Trouve autre
chose.
C'est vrai que t'as des gros problèmes dans la vie. Faire un caca
nerveux parce qu'on ne peut pas enlever IE, alors même que ça
n'empêche pas d'utiliser un autre navigateur, faut le faire.
ça me fait chier de ne pas pouvoir désinstaller un
composant qui ne m'intéresse pas.
Absolument. Ca apporterait quoi et à qui que MS supprime IE de
l'install de base ?
1/ à respecter la loi
2/ à respecter le choix de l'utilisateur
D'ailleurs, combien de versions "N" de Windows (dépourvues de WMP) MS
a-t-il vendu, qu'on rigole ?
Je savais même pas que ça existait, c'est dire s'ils communiquent sur
l'existence du produit... Evidemment, ils ont tout intérêt à ce que
cette version, juste créée pour calmer la Cour Européenne de Justice,
ne se vende pas.
Où est la décision de justice qui dit que c'est illégal concernant
IE ?
Concernant IE comme pour tout autre produit, la vente liée est
interdite par le code du commerce en France.
Tu veux une liste des condamnations de MS pour ses pratiques
délictueuses? Ils n'ont pas encore été condamnés pour IE à ce sujet,
mais l'instruction est en cours, l'UE ayant commencé en janvier 2008
une enquête sur de possibles abus de position dominante dans la
majeure partie de la logithèque Microsoft : sont concernés le navigateur
web
Internet Explorer, la suite bureautique Office, les produits online
Windows Live (dont les messageries Hotmail et Messenger) et
l’intégration de la recherche web sur le bureau Windows.
D'ailleurs, concernant IE, ils ont déjà été condamné pour utilisation
frauduleuse de technologies brevetées. Un comble pour des mecs qui
auraient déposé l'alphabet s'ils en avaient eu la possibilité.
pehache-tolai a écrit :
Oui bien sûr. Il y a qqs temps j'ai installé un serveur apache sur
mon NAS. Le fichier de conf n'est pas dans /etc : j'aimerais bien
savoir pourquoi ?
Merde, tous les serveurs Apache sous Linux que j'utilise ici (une
40aine) ont leur fichier de conf dans /etc. Si t'es pas foutu de
trouver une distribution qui a un minimum de cohérence dans sa
gestion de l'arborescence, c'est ton problème.
Non bien sûr. Mais vu que ça fait partie de l'installation de base de
Windows, ça ne pose pas vraiment de problème que ce soit comme ça.
Ouais ouais, le solitaire, dans l'install de base. Mort de rire.
Composant essentiel du système, et donc DLL dans system32. Grotesque.
A nuancer quand même : si un jour tu as besoin d'une appli ou d'une
version qui n'est pas dans les dépôts, la méthode unique en prend un
coup.
Non. Toutes les distributions fournissent les outils pour fabriquer
soi-même le paquet qui s'intègrera alors dans l'outil de gestion.
Ce qui n'est pas bien grave à partir du moment où l'appli est
"autonome" et ne s'est pas répandu dans tout le système.
Ah parce que toi, tu trouves ça "pas bien grave" d'avoir une BDR
remplie d'entrées qui ne pointent plus vers quoique ce soit,
des DLLs
inutiles dans des répertoires qu'ils soient system32 ou n'importe
quel autre quand tu as désinstallé un programme via le panneau de
configuration?
Me fait pas rire avec cet argument... Ca prend combien de place sur
le disque, IE ? Combien font les disques de base d'aujourd'hui ?
Le disque de base d'un eeepc c'est 4Go.
Et pourquoi diable suis-je
obligé d'avoir sur mon disque des softs dont je n'ai pas besoin?
Si tu veux faire un serveur tu commences par prendre un OS fait pour
plutôt que de bricoler un OS pas prévu pour
Windows NT3.51, Windows NT4, Windows 2000, Windows 2003, Windows 2008,
MS vend ou a vendu tout ça comme étant des OS serveurs. Trouve autre
chose.
C'est vrai que t'as des gros problèmes dans la vie. Faire un caca
nerveux parce qu'on ne peut pas enlever IE, alors même que ça
n'empêche pas d'utiliser un autre navigateur, faut le faire.
ça me fait chier de ne pas pouvoir désinstaller un
composant qui ne m'intéresse pas.
Absolument. Ca apporterait quoi et à qui que MS supprime IE de
l'install de base ?
1/ à respecter la loi
2/ à respecter le choix de l'utilisateur
D'ailleurs, combien de versions "N" de Windows (dépourvues de WMP) MS
a-t-il vendu, qu'on rigole ?
Je savais même pas que ça existait, c'est dire s'ils communiquent sur
l'existence du produit... Evidemment, ils ont tout intérêt à ce que
cette version, juste créée pour calmer la Cour Européenne de Justice,
ne se vende pas.
Où est la décision de justice qui dit que c'est illégal concernant
IE ?
Concernant IE comme pour tout autre produit, la vente liée est
interdite par le code du commerce en France.
Tu veux une liste des condamnations de MS pour ses pratiques
délictueuses? Ils n'ont pas encore été condamnés pour IE à ce sujet,
mais l'instruction est en cours, l'UE ayant commencé en janvier 2008
une enquête sur de possibles abus de position dominante dans la
majeure partie de la logithèque Microsoft : sont concernés le navigateur
web
Internet Explorer, la suite bureautique Office, les produits online
Windows Live (dont les messageries Hotmail et Messenger) et
l’intégration de la recherche web sur le bureau Windows.
D'ailleurs, concernant IE, ils ont déjà été condamné pour utilisation
frauduleuse de technologies brevetées. Un comble pour des mecs qui
auraient déposé l'alphabet s'ils en avaient eu la possibilité.
pehache-tolai a écrit :Oui bien sûr. Il y a qqs temps j'ai installé un serveur apache sur
mon NAS. Le fichier de conf n'est pas dans /etc : j'aimerais bien
savoir pourquoi ?
Merde, tous les serveurs Apache sous Linux que j'utilise ici (une
40aine) ont leur fichier de conf dans /etc. Si t'es pas foutu de
trouver une distribution qui a un minimum de cohérence dans sa
gestion de l'arborescence, c'est ton problème.
Non bien sûr. Mais vu que ça fait partie de l'installation de base de
Windows, ça ne pose pas vraiment de problème que ce soit comme ça.
Ouais ouais, le solitaire, dans l'install de base. Mort de rire.
Composant essentiel du système, et donc DLL dans system32. Grotesque.
A nuancer quand même : si un jour tu as besoin d'une appli ou d'une
version qui n'est pas dans les dépôts, la méthode unique en prend un
coup.
Non. Toutes les distributions fournissent les outils pour fabriquer
soi-même le paquet qui s'intègrera alors dans l'outil de gestion.
Ce qui n'est pas bien grave à partir du moment où l'appli est
"autonome" et ne s'est pas répandu dans tout le système.
Ah parce que toi, tu trouves ça "pas bien grave" d'avoir une BDR
remplie d'entrées qui ne pointent plus vers quoique ce soit,
des DLLs
inutiles dans des répertoires qu'ils soient system32 ou n'importe
quel autre quand tu as désinstallé un programme via le panneau de
configuration?
Me fait pas rire avec cet argument... Ca prend combien de place sur
le disque, IE ? Combien font les disques de base d'aujourd'hui ?
Le disque de base d'un eeepc c'est 4Go.
Et pourquoi diable suis-je
obligé d'avoir sur mon disque des softs dont je n'ai pas besoin?
Si tu veux faire un serveur tu commences par prendre un OS fait pour
plutôt que de bricoler un OS pas prévu pour
Windows NT3.51, Windows NT4, Windows 2000, Windows 2003, Windows 2008,
MS vend ou a vendu tout ça comme étant des OS serveurs. Trouve autre
chose.
C'est vrai que t'as des gros problèmes dans la vie. Faire un caca
nerveux parce qu'on ne peut pas enlever IE, alors même que ça
n'empêche pas d'utiliser un autre navigateur, faut le faire.
ça me fait chier de ne pas pouvoir désinstaller un
composant qui ne m'intéresse pas.
Absolument. Ca apporterait quoi et à qui que MS supprime IE de
l'install de base ?
1/ à respecter la loi
2/ à respecter le choix de l'utilisateur
D'ailleurs, combien de versions "N" de Windows (dépourvues de WMP) MS
a-t-il vendu, qu'on rigole ?
Je savais même pas que ça existait, c'est dire s'ils communiquent sur
l'existence du produit... Evidemment, ils ont tout intérêt à ce que
cette version, juste créée pour calmer la Cour Européenne de Justice,
ne se vende pas.
Où est la décision de justice qui dit que c'est illégal concernant
IE ?
Concernant IE comme pour tout autre produit, la vente liée est
interdite par le code du commerce en France.
Tu veux une liste des condamnations de MS pour ses pratiques
délictueuses? Ils n'ont pas encore été condamnés pour IE à ce sujet,
mais l'instruction est en cours, l'UE ayant commencé en janvier 2008
une enquête sur de possibles abus de position dominante dans la
majeure partie de la logithèque Microsoft : sont concernés le navigateur
web
Internet Explorer, la suite bureautique Office, les produits online
Windows Live (dont les messageries Hotmail et Messenger) et
l’intégration de la recherche web sur le bureau Windows.
D'ailleurs, concernant IE, ils ont déjà été condamné pour utilisation
frauduleuse de technologies brevetées. Un comble pour des mecs qui
auraient déposé l'alphabet s'ils en avaient eu la possibilité.
