D'abord laissons le dns de coté : c'est un plus mais ça n'entre pas en ligne de compte lorsqu'on compare dhcpd et la définition statique d'adresses ip.
Un serveur dhcpd s'installe très facilement et si l'outil mandrake fait cette configuration, il n'y a rien à redire : c'est en faveur un bon point, puisque mandrake mettrait ainsi à disposition de ses utilisateurs un outil puissant par défaut... Sans que ça leur apparaisse compliqué.
De plus, l'intérêt de dhcpd est que la conf se fait à un seul endroit, sur le serveur.
« c pas quand la distrib fait tout a ta place que tu apprends a te servir de Linux »
Très concretement, tu parles là de configurer GNU/Linux, pas de simplement l'utiliser. L'informatique n'est pas une finalité en soit pour tous.
Ceci étant dit, tu compares là Mandrake à Slackware, en prennant ce qui est peut-être une erreur de Mandrake (je ne sais pas comment ils gèrent cette affaire). Ca n'est pas un argument en faveur de Slackware mais en défaveur de Mandrake. Car si l'adaptation à la configuration que tu as fait était valide, elle aurait du rester en place. Ceci dit, ce qui aurait été interessant, c'est de savoir quel programme, script à écrasé ta modif. Forcement quelque chose lancé via /etc/cron.* ou /etc/init.d ... En trouvant le coupable de la modif, il y a de fortes chances que tu trouve aussi une explication.
Maintenant pour repondre à tes arguments plus spécifique à Slackware : les scripts d'init de debian et de redhat sont pas particulièrement compliqués à manipuler ; la debian gère un nombre d'architectures tout à fait interessant ; la debian peut s'installer sur un espace disque ridicule. Ce ne sont pas des avantages pour moi.
Je ne vois pas le rapport entre le fait d'être tolérant et le fait de ne pas trouver, rationnellement, d'avantage à la slackware. Et je ne vois pas non plus qui crie ici.
« et si j'en veux pas moi, un système de package (quand on est organisé, on en a pas vraiment besoin). »
Ben voyons.
« J'aime la slackware parce qu'elle est simple à l'install et à l'utilisation, et qu'elle ne contient rien d'inutile ou en surplus comparée aux grosses distribs généralistes (à quoi sert d'installer une mandrake ou une redhat si on ne compte pas se servir de leurs outils parfois déficients comme le montre cet news). »
Il me semble que « ce que montre cet[te] news » (sic) est loin d'être évident.
Ceci étant précisé, peux-tu décrire ce que tu considères comme inutile - en considérant le terme inutile au sens large, c'est-à-dire ce qui est inutile pour tous ou presque.
« Et j'aime la slackware par rapport à une gentoo ou une LFS parce qu'elle est bien plus facile à installer quand on n'a qu'une connection 56k, qu'on n'a pas le temps de compiler la base du système. »
La facilité de l'installation dépend du debit de la connexion ? Si tel est le cas, la chose est amusante.
« Elle n'est en rien dépasser comme tendent à le dire certains, elle tourne avec les applications récentes, elle est toujours maintenu et elle a toujours des utilisateurs qui n'ont rien à gagner à utiliser une autre distrib... »
Tu en a l'air bien persuadé, qu'ils n'ont « rien à gagner ». Peux-tu m'indiquer en 2 secondes toutes les fichiers que tu as installé avec la glibc? Avec un système de paquet comme dpkg ou rpm, c'est possible. C'est inutile ? Tu écris sur des post-it ?
« Et au moins, ses utilisateurs pètent pas plus haut que leur cul en dénigrant les autres distribs. »
Tu supposes donc qu'il y a homogéneité des utilisateurs de distribs. Peux-tu le démontrer ?
« Derriere si je me prend du spam sur cette adresse je sais que lesite est a eviter. Je met en place une regle "unknown mailbox" et generalement le spam se calme tout seul. »
Bizarre :
1) Tu considères qu'un site est responsable d'un spam (« à éviter » ?) alors qu'il ne peut s'agir que du lieu d'où l'adresse à été pompée.
2) T'es obligé de toi même ajouter une règle par spam... fastidieux.
Ce genre d'astuces rigolotes ne sont acceptables que si l'on part du postulat que ceux qui peuvent avoir un intérêt légitime pour notre adresse ont accès à perl... Rarement vrai.
« Il y'a tout un tas de trucs qui sont interdits/reglementés par la loi (négationisme, incitation au racisme, publicité mensongère, etc...) et personne ne crie vraiement a la censure. »
De fait, des gens crient à la censure au propos des deux premiers. Ton exemple me parait donc inapproprié, nous engageant dans un autre débat.
Il y'a en effet une différence entre savoir si toutes les idées doivent être tolérées ou pas et savoir si l'on peut constituer des listes d'adresses de personnes à leur insu pour faire des envois massifs.
La publicité mensongère, puisque t'en passe, n'est pas légale en France, tu peux faire des procès sans difficultés à ce propos - et c'est parfaitement normal !
Ceci étant précisé, il est très clair que la censure signifie interdire des idées, pas restreindre des moyens de diffusions. Lorsqu'un film est classé X, il n'est pas censuré, il est juste soumis à une législation particulière, adapté à son contenu.
« Le problème, c'est qu'avec spamassassin, le spammeur te bouffe ta BP, ton CPU et ton temps (passé a installer/configurer SA). »
Ta BP, de toute façon elle est utilisée. Tant qu'un spam partira, il y aura de la BP bouffée.
Ton CPU, a priori il prend son temps (il tourne tout le temps à 100% au point que cela soit si genant - ceci dit, c'est préférable quand c'est traité par un serveur en amont).
Configurer spamassassin, avec une bonne distrib, c'est rapide.
Sur le long terme, l'intérêt de spamassassin c'est qu'il fait largement baisser la rentabilité du spam. Si spamassassin était partout, si le spam en devenait inutile... il disparaitrait (plus probablement, il se perfectionnerait)
Sauf erreur de ma part, spamassassin ne parle pas à coup de « bel et bien » mais t'informe des tests qui ont influé sur sa réponse.
Spamassassin n'est pas aussi affirmatif que tu le laisses entendre.
Et il me semble que spamassassin est une solution valable à long terme. Je reçois en moyenne une cinquantaine de courriels par jours. A tout casser 1 spam passe entre les mailles du filet : c'est à un stade ou le spam n'est même plus une nuisance.
supermount, quand c'est mis-en-place, ça monte les disques peut importe que l'utilisateur le veuille ou pas. Si on l'installe c'est pour TOUS (utilisateurs de la machine), si on le vire, c'est pour TOUS.
Ce n'est pas géré par utilisateur.... alors que c'est typiquement le genre d'outils qui peuvent être pratique pour certains utilisateurs mais que d'autre, utilisant la même machine, vont forcement vouloir virer.
La Slackware te permet de modifier tout le systeme comme tu veux, sans risquer d'entrer en conflit avec des scripts censes configurer tout automatiquement.
L'abscence de scripts de config automatique est d'ailleurs ce qui apporte une grande stabilite a cette distribution.
En ce qui concerne l'abscence de systeme de packages permettant de gerer les dependances (le plus gros reproche fait a slackware en general), il est possible d'utiliser pkgsrc (de NetBSD) dessus : http://www.pkgsrc.org/(...)
T'utilise apt-get, qui n'est pas supporté officiellement par RedHat. Tu devrais plutot présenter le problème avec rpm -e
Aussi, si linux 2.4.20-8 a été compilé avec le support de lvm, il n'est pas tout à fait choquant que le paquet nécessaire à l'utilisation de lvm soit une dépendance. Reste à voir le contenu du paquet. Il se peut qu'utiliser lvm, présent dans le noyau, sans ce paquet crée de sérieux troubles. Si le paquet est petit, il n'est pas déraisonnable de forcer sa présence, bien qu'inutilisé, si ça peut éviter à des utilisateurs de sérieux problèmes.
Je dis ça, j'en sais rien. Mais ce choix me parait justifiable. Ce n'est pas à mon sens un bon exemple de problème de finition de dépendances. Ce qui à mon avis est largement plus problématique serait un oubli de dépendance.
Il est vrai que le coup des /bin/mount dans un terminal font un peu goret, comme démonstration d'accessibilité.
C'est là l'intérêt du bureau KDE (ou autre) : il suffit d'expliquer qu'il faut monter le disque en cliquant, une fois le CD inséré.
Et on peut donner l'explication sur l'intérêt d'éviter d'avoir ce périph qui monte tout seul (je doute qu'un seul utilisateur de Windows n'ait pas été gavé par ce lecteur CD qui se monte à tout va au démarrage de Windows).
En fait, ce que je trouve vraiment nul avec ce supermount, c'est que justement, ce n'est pas une facilité en plus, au choix, mais c'est obligatoire si on l'active. Bref, pas possible de l'avoir en inactif par défaut et éventuellement de l'avoir activé pour un utilisateur le demandant, par exemple dans son gnomecc ou kcontrol.
(Si c'est possible, depuis quand ?)
Il est fort probable qu'il y ait une relation entre la réputation de Mandrake et le public visé. Il est normal qu'un novice puisse en arriver à réinstaller une distrib alors qu'un utilisateur expérimenté trouvera toujours comment s'en sortir sans passer par là.
Qui peut le plus peut souvent le moins. Tu peux tout configurer à la main avec une RedHat, si tu le veux. Les choses ne sont pas « cachées », elles sont aussi visibles qu'avec une debian. Mais t'es pas obligé de naviguer dans /etc, c'est certain.
La connaissance du système n'est une fin en soit que pour les passionnés ou professionnels de l'informatique.
Et bien vas-y, on te regarde. C'est pas moi qui ait commencé a parler de la Slackware, je faisais que réagir là dessus, et comme la news parlait de la Mandrake...
« Est-ce que tu as essayé de faire tourner Frozen Bubble Java avec Classpath et une JVM libre, ou encore de le compiler avec gcj, avant de dire ça ? Parce qu'en fait, le code de Frozen Bubble est du java 1.1 qui semble très simple (rapide coup d'oeil, je peux me tromper), donc il est tout à fait possible que tu te trompes. »
C'est possible, mais vu qu'il a été dit plus haut qu'il faut la dernière version de java pour que ça fonctionne correctement, j'en doute.
« De toute manière, je ne suis pas sûr de bien comprendre tes remarques. A l'origine, le projet GNU était effectivement un ensemble de logiciels libres dépendant de logiciels propriétaires, ne serait-ce qu'un compilateur pour bootstraper gcc, par exemple, ou encore un système d'expoitation hôte. Lentement mais surement, il devient possible de faire du 100 % libre. C'est bien. Le fait que le 100 % ne soit pas possible pour certaines technologies (par exemple KDE au début, Java 1.4 actuellement, etc.) est-il une raison pour se priver de ces technologies quand elles sont ouvertes (pour mémoire, Sun a modifié les règles du JCP pour autoriser explicitement les implémentations libres, donc Java est ouvert, même s'il n'existe pas actuellement de bibliothèques de classes libres permettant d'obtenir la compatibilité 1.2 parfaite) ? »
Je pense en effet qu'il y a un risque insidieux à faire du 100 % libre dépendant de non-libre. La conséquence me semble assez simple : on reconnait avoir besoin du propriétaire et on incite à son utilisation. A mon avis, ça ne profite pas à la diffusion du libre ; mais bien entendu, il est possible que je me trompe.
Bien sûr, quand on est habitué à la facilité, les défauts sont flagrants. J'ai commencé par une Slackware, et c'est vrai que même maintenant quand j'utilise une Mandrake ou une RedHat, et bien j'ai encore l'impression de savoir comment ça marche derrière, ce que fait le système.
tout n'est pas caché et clickodromisé comme dans les distributions sus-cités, faut encore mettre les mains dans le cambouis. A voir si les gens préfèrent avoir une connaissance du système un peu plus poussé que si ils utilisaient Windows.
[^] # Re: Un test négatif mais constructif (??? vraiment ?)
Posté par Anonyme . En réponse à la dépêche Un test négatif (mais constructif) de la Mandrake 9.1. Évalué à 2.
Un serveur dhcpd s'installe très facilement et si l'outil mandrake fait cette configuration, il n'y a rien à redire : c'est en faveur un bon point, puisque mandrake mettrait ainsi à disposition de ses utilisateurs un outil puissant par défaut... Sans que ça leur apparaisse compliqué.
De plus, l'intérêt de dhcpd est que la conf se fait à un seul endroit, sur le serveur.
[^] # Re: Un test négatif (mais constructif) de la Mandrake 9.1
Posté par Anonyme . En réponse à la dépêche Un test négatif (mais constructif) de la Mandrake 9.1. Évalué à 1.
Très concretement, tu parles là de configurer GNU/Linux, pas de simplement l'utiliser. L'informatique n'est pas une finalité en soit pour tous.
Ceci étant dit, tu compares là Mandrake à Slackware, en prennant ce qui est peut-être une erreur de Mandrake (je ne sais pas comment ils gèrent cette affaire). Ca n'est pas un argument en faveur de Slackware mais en défaveur de Mandrake. Car si l'adaptation à la configuration que tu as fait était valide, elle aurait du rester en place. Ceci dit, ce qui aurait été interessant, c'est de savoir quel programme, script à écrasé ta modif. Forcement quelque chose lancé via /etc/cron.* ou /etc/init.d ... En trouvant le coupable de la modif, il y a de fortes chances que tu trouve aussi une explication.
Maintenant pour repondre à tes arguments plus spécifique à Slackware : les scripts d'init de debian et de redhat sont pas particulièrement compliqués à manipuler ; la debian gère un nombre d'architectures tout à fait interessant ; la debian peut s'installer sur un espace disque ridicule. Ce ne sont pas des avantages pour moi.
Je ne vois pas le rapport entre le fait d'être tolérant et le fait de ne pas trouver, rationnellement, d'avantage à la slackware. Et je ne vois pas non plus qui crie ici.
[^] # Re: Un test négatif (mais constructif) de la Mandrake 9.1
Posté par Anonyme . En réponse à la dépêche Un test négatif (mais constructif) de la Mandrake 9.1. Évalué à 1.
Pour surenchérir, moi je dis, un Linux-débutant qui veut divrocer de son Wintruc devrait toujours commencer sur une Slackware.
Et Paf. Hin hin, ça calme, hein :p
Y'a bon les initscripts BSD-like pour le neu² de base que je suis.
Tiens z'avez vu ça ? : http://freebsdebutant.org(...)
;)
[^] # Re: Un test négatif (mais constructif) de la Mandrake 9.1
Posté par Anonyme . En réponse à la dépêche Un test négatif (mais constructif) de la Mandrake 9.1. Évalué à 1.
Ben voyons.
« J'aime la slackware parce qu'elle est simple à l'install et à l'utilisation, et qu'elle ne contient rien d'inutile ou en surplus comparée aux grosses distribs généralistes (à quoi sert d'installer une mandrake ou une redhat si on ne compte pas se servir de leurs outils parfois déficients comme le montre cet news). »
Il me semble que « ce que montre cet[te] news » (sic) est loin d'être évident.
Ceci étant précisé, peux-tu décrire ce que tu considères comme inutile - en considérant le terme inutile au sens large, c'est-à-dire ce qui est inutile pour tous ou presque.
« Et j'aime la slackware par rapport à une gentoo ou une LFS parce qu'elle est bien plus facile à installer quand on n'a qu'une connection 56k, qu'on n'a pas le temps de compiler la base du système. »
La facilité de l'installation dépend du debit de la connexion ? Si tel est le cas, la chose est amusante.
« Elle n'est en rien dépasser comme tendent à le dire certains, elle tourne avec les applications récentes, elle est toujours maintenu et elle a toujours des utilisateurs qui n'ont rien à gagner à utiliser une autre distrib... »
Tu en a l'air bien persuadé, qu'ils n'ont « rien à gagner ». Peux-tu m'indiquer en 2 secondes toutes les fichiers que tu as installé avec la glibc? Avec un système de paquet comme dpkg ou rpm, c'est possible. C'est inutile ? Tu écris sur des post-it ?
« Et au moins, ses utilisateurs pètent pas plus haut que leur cul en dénigrant les autres distribs. »
Tu supposes donc qu'il y a homogéneité des utilisateurs de distribs. Peux-tu le démontrer ?
[^] # Re: Une fonctionnalité qui manque
Posté par Anonyme . En réponse à la dépêche Sortie de Snort 2.0. Évalué à 0.
[^] # Re: Étude sur le SPAM
Posté par Anonyme . En réponse à la dépêche Étude sur le SPAM. Évalué à 2.
Bizarre :
1) Tu considères qu'un site est responsable d'un spam (« à éviter » ?) alors qu'il ne peut s'agir que du lieu d'où l'adresse à été pompée.
2) T'es obligé de toi même ajouter une règle par spam... fastidieux.
[^] # Re: Étude sur le SPAM
Posté par Anonyme . En réponse à la dépêche Étude sur le SPAM. Évalué à 0.
[^] # Re: Étude sur le SPAM
Posté par Anonyme . En réponse à la dépêche Étude sur le SPAM. Évalué à 3.
De fait, des gens crient à la censure au propos des deux premiers. Ton exemple me parait donc inapproprié, nous engageant dans un autre débat.
Il y'a en effet une différence entre savoir si toutes les idées doivent être tolérées ou pas et savoir si l'on peut constituer des listes d'adresses de personnes à leur insu pour faire des envois massifs.
La publicité mensongère, puisque t'en passe, n'est pas légale en France, tu peux faire des procès sans difficultés à ce propos - et c'est parfaitement normal !
Ceci étant précisé, il est très clair que la censure signifie interdire des idées, pas restreindre des moyens de diffusions. Lorsqu'un film est classé X, il n'est pas censuré, il est juste soumis à une législation particulière, adapté à son contenu.
« Le problème, c'est qu'avec spamassassin, le spammeur te bouffe ta BP, ton CPU et ton temps (passé a installer/configurer SA). »
Ta BP, de toute façon elle est utilisée. Tant qu'un spam partira, il y aura de la BP bouffée.
Ton CPU, a priori il prend son temps (il tourne tout le temps à 100% au point que cela soit si genant - ceci dit, c'est préférable quand c'est traité par un serveur en amont).
Configurer spamassassin, avec une bonne distrib, c'est rapide.
Sur le long terme, l'intérêt de spamassassin c'est qu'il fait largement baisser la rentabilité du spam. Si spamassassin était partout, si le spam en devenait inutile... il disparaitrait (plus probablement, il se perfectionnerait)
[^] # Re: Étude sur le SPAM
Posté par Anonyme . En réponse à la dépêche Étude sur le SPAM. Évalué à 2.
Spamassassin n'est pas aussi affirmatif que tu le laisses entendre.
Et il me semble que spamassassin est une solution valable à long terme. Je reçois en moyenne une cinquantaine de courriels par jours. A tout casser 1 spam passe entre les mailles du filet : c'est à un stade ou le spam n'est même plus une nuisance.
[^] # Re: Un test négatif mais constructif (??? vraiment ?)
Posté par Anonyme . En réponse à la dépêche Un test négatif (mais constructif) de la Mandrake 9.1. Évalué à 3.
supermount, quand c'est mis-en-place, ça monte les disques peut importe que l'utilisateur le veuille ou pas. Si on l'installe c'est pour TOUS (utilisateurs de la machine), si on le vire, c'est pour TOUS.
Ce n'est pas géré par utilisateur.... alors que c'est typiquement le genre d'outils qui peuvent être pratique pour certains utilisateurs mais que d'autre, utilisant la même machine, vont forcement vouloir virer.
[^] # Re: Un test négatif (mais constructif) de la Mandrake 9.1
Posté par Anonyme . En réponse à la dépêche Un test négatif (mais constructif) de la Mandrake 9.1. Évalué à 1.
A ouais ? Moi je n'ai aucun problème de stabilité. Où est l'avantage alors ?
[^] # Re: Un test négatif (mais constructif) de la Mandrake 9.1
Posté par Anonyme . En réponse à la dépêche Un test négatif (mais constructif) de la Mandrake 9.1. Évalué à 2.
L'abscence de scripts de config automatique est d'ailleurs ce qui apporte une grande stabilite a cette distribution.
En ce qui concerne l'abscence de systeme de packages permettant de gerer les dependances (le plus gros reproche fait a slackware en general), il est possible d'utiliser pkgsrc (de NetBSD) dessus :
http://www.pkgsrc.org/(...)
[^] # Re: Un test négatif mais constructif (??? vraiment ?)
Posté par Anonyme . En réponse à la dépêche Un test négatif (mais constructif) de la Mandrake 9.1. Évalué à 2.
Je n'ai pas de problème pour désactiver supermount ; ca reste très largement dans mes moyens :)
[^] # Re: Un test négatif (mais constructif) de la Mandrake 9.1
Posté par Anonyme . En réponse à la dépêche Un test négatif (mais constructif) de la Mandrake 9.1. Évalué à 3.
Aussi, si linux 2.4.20-8 a été compilé avec le support de lvm, il n'est pas tout à fait choquant que le paquet nécessaire à l'utilisation de lvm soit une dépendance. Reste à voir le contenu du paquet. Il se peut qu'utiliser lvm, présent dans le noyau, sans ce paquet crée de sérieux troubles. Si le paquet est petit, il n'est pas déraisonnable de forcer sa présence, bien qu'inutilisé, si ça peut éviter à des utilisateurs de sérieux problèmes.
Je dis ça, j'en sais rien. Mais ce choix me parait justifiable. Ce n'est pas à mon sens un bon exemple de problème de finition de dépendances. Ce qui à mon avis est largement plus problématique serait un oubli de dépendance.
[^] # Re: Un test négatif mais constructif (??? vraiment ?)
Posté par Anonyme . En réponse à la dépêche Un test négatif (mais constructif) de la Mandrake 9.1. Évalué à 3.
C'est là l'intérêt du bureau KDE (ou autre) : il suffit d'expliquer qu'il faut monter le disque en cliquant, une fois le CD inséré.
Et on peut donner l'explication sur l'intérêt d'éviter d'avoir ce périph qui monte tout seul (je doute qu'un seul utilisateur de Windows n'ait pas été gavé par ce lecteur CD qui se monte à tout va au démarrage de Windows).
En fait, ce que je trouve vraiment nul avec ce supermount, c'est que justement, ce n'est pas une facilité en plus, au choix, mais c'est obligatoire si on l'active. Bref, pas possible de l'avoir en inactif par défaut et éventuellement de l'avoir activé pour un utilisateur le demandant, par exemple dans son gnomecc ou kcontrol.
(Si c'est possible, depuis quand ?)
[^] # Re: Un test négatif mais constructif (??? vraiment ?)
Posté par Anonyme . En réponse à la dépêche Un test négatif (mais constructif) de la Mandrake 9.1. Évalué à 8.
[^] # Re: Un test négatif (mais constructif) de la Mandrake 9.1
Posté par Anonyme . En réponse à la dépêche Un test négatif (mais constructif) de la Mandrake 9.1. Évalué à 10.
La connaissance du système n'est une fin en soit que pour les passionnés ou professionnels de l'informatique.
[^] # Re: Un test négatif (mais constructif) de la Mandrake 9.1
Posté par Anonyme . En réponse à la dépêche Un test négatif (mais constructif) de la Mandrake 9.1. Évalué à -4.
[^] # Re: Frozen Bubble en applet JAVA
Posté par Anonyme . En réponse à la dépêche Frozen Bubble en applet JAVA. Évalué à -2.
C'est possible, mais vu qu'il a été dit plus haut qu'il faut la dernière version de java pour que ça fonctionne correctement, j'en doute.
« De toute manière, je ne suis pas sûr de bien comprendre tes remarques. A l'origine, le projet GNU était effectivement un ensemble de logiciels libres dépendant de logiciels propriétaires, ne serait-ce qu'un compilateur pour bootstraper gcc, par exemple, ou encore un système d'expoitation hôte. Lentement mais surement, il devient possible de faire du 100 % libre. C'est bien. Le fait que le 100 % ne soit pas possible pour certaines technologies (par exemple KDE au début, Java 1.4 actuellement, etc.) est-il une raison pour se priver de ces technologies quand elles sont ouvertes (pour mémoire, Sun a modifié les règles du JCP pour autoriser explicitement les implémentations libres, donc Java est ouvert, même s'il n'existe pas actuellement de bibliothèques de classes libres permettant d'obtenir la compatibilité 1.2 parfaite) ? »
Je pense en effet qu'il y a un risque insidieux à faire du 100 % libre dépendant de non-libre. La conséquence me semble assez simple : on reconnait avoir besoin du propriétaire et on incite à son utilisation. A mon avis, ça ne profite pas à la diffusion du libre ; mais bien entendu, il est possible que je me trompe.
[^] # Re: Un test négatif (mais constructif) de la Mandrake 9.1
Posté par Anonyme . En réponse à la dépêche Un test négatif (mais constructif) de la Mandrake 9.1. Évalué à -5.
[^] # Re: Un test négatif (mais constructif) de la Mandrake 9.1
Posté par Anonyme . En réponse à la dépêche Un test négatif (mais constructif) de la Mandrake 9.1. Évalué à -5.
tout n'est pas caché et clickodromisé comme dans les distributions sus-cités, faut encore mettre les mains dans le cambouis. A voir si les gens préfèrent avoir une connaissance du système un peu plus poussé que si ils utilisaient Windows.
[^] # Re: Un test négatif (mais constructif) de la Mandrake 9.1
Posté par Anonyme . En réponse à la dépêche Un test négatif (mais constructif) de la Mandrake 9.1. Évalué à 7.
[^] # Re: Un test négatif (mais constructif) de la Mandrake 9.1
Posté par Anonyme . En réponse à la dépêche Un test négatif (mais constructif) de la Mandrake 9.1. Évalué à 4.
Quand bien même ce serait lui, je me demande en quoi ça a la moindre forme d'importance.
[^] # Re: Un test négatif (mais constructif) de la Mandrake 9.1
Posté par Anonyme . En réponse à la dépêche Un test négatif (mais constructif) de la Mandrake 9.1. Évalué à 4.
[^] # Re: Un test négatif (mais constructif) de la Mandrake 9.1
Posté par Anonyme . En réponse à la dépêche Un test négatif (mais constructif) de la Mandrake 9.1. Évalué à 8.
Moi j'aimerais que me donne rien qu'un argument valable contre. L'auteur de l'article parlait de « bloatware ».
root@hephaistos:~# ps eaux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.3 1264 92 ? S 10:43 0:00 init TERM=linux
root 2 0.0 0.0 0 0 ? SW 10:43 0:00 [keventd]
root 3 0.0 0.0 0 0 ? SWN 10:43 0:00 [ksoftirqd_CPU0]
root 4 0.0 0.0 0 0 ? SW 10:43 0:18 [kswapd]
root 5 0.0 0.0 0 0 ? SW 10:43 0:00 [bdflush]
root 6 0.0 0.0 0 0 ? SW 10:43 0:00 [kupdated]
root 13 0.0 0.0 0 0 ? SW 10:43 0:01 [kjournald]
root 99 0.0 0.0 0 0 ? SW 10:44 0:01 [kjournald]
root 127 0.0 0.0 0 0 ? SW 10:44 0:00 [eth0]
root 147 0.0 1.8 1908 556 ? S 10:44 0:00 dhclient eth0 PWD=/ IFACE=eth0 MODE=start S
daemon 155 0.0 0.4 1372 140 ? S 10:44 0:00 /sbin/portmap PWD=/ CONSOLE=/dev/console PR
root 214 0.0 1.1 1356 340 ? S 10:44 0:03 /sbin/syslogd PWD=/ CONSOLE=/dev/console PR
root 217 0.0 0.1 1892 56 ? S 10:44 0:01 /sbin/klogd PWD=/ CONSOLE=/dev/console PREV
root 220 0.0 2.9 10404 904 ? S 10:44 0:00 /usr/sbin/named PWD=/ CONSOLE=/dev/console
root 222 0.0 2.9 10404 904 ? S 10:44 0:00 /usr/sbin/named PWD=/ CONSOLE=/dev/console
root 223 0.0 2.9 10404 904 ? S 10:44 0:07 /usr/sbin/named PWD=/ CONSOLE=/dev/console
root 224 0.0 2.9 10404 904 ? S 10:44 0:00 /usr/sbin/named PWD=/ CONSOLE=/dev/console
root 225 0.0 2.9 10404 904 ? S 10:44 0:00 /usr/sbin/named PWD=/ CONSOLE=/dev/console
root 235 0.0 0.3 1432 104 ? S 10:44 0:00 /sbin/rpc.statd PWD=/ CONSOLE=/dev/console
root 239 0.0 0.6 2396 184 ? S 10:44 0:00 /usr/sbin/dhcpd3 -q eth1 PWD=/ CONSOLE=/dev
mail 245 0.0 0.5 2792 172 ? S 10:44 0:00 /usr/bin/exim -bd PWD=/ CONSOLE=/dev/consol
daemon 255 0.0 0.8 1956 256 ? S 10:44 0:00 lpd Waiting
root 269 0.0 0.4 2168 140 ? S 10:44 0:00 /bin/sh /usr/bin/safe_mysqld PWD=/ CONSOLE=
mysql 304 0.0 1.2 36500 372 ? S 10:44 0:00 /usr/sbin/mysqld --basedir=/usr --datadir=/
mysql 309 0.0 1.2 36500 372 ? S 10:44 0:00 /usr/sbin/mysqld --basedir=/usr --datadir=/
mysql 310 0.0 1.2 36500 372 ? S 10:44 0:00 /usr/sbin/mysqld --basedir=/usr --datadir=/
mysql 311 0.0 1.2 36500 372 ? S 10:44 0:00 /usr/sbin/mysqld --basedir=/usr --datadir=/
root 323 0.0 0.0 0 0 ? SW 10:44 0:22 [nfsd]
root 324 0.0 0.0 0 0 ? SW 10:44 0:00 [lockd]
root 325 0.0 0.0 0 0 ? SW 10:44 0:00 [rpciod]
root 326 0.0 0.0 0 0 ? SW 10:44 0:20 [nfsd]
root 327 0.0 0.0 0 0 ? SW 10:44 0:20 [nfsd]
root 328 0.0 0.0 0 0 ? SW 10:44 0:21 [nfsd]
root 329 0.0 0.0 0 0 ? SW 10:44 0:23 [nfsd]
root 330 0.0 0.0 0 0 ? SW 10:44 0:23 [nfsd]
root 331 0.0 0.0 0 0 ? SW 10:44 0:21 [nfsd]
root 332 0.0 0.0 0 0 ? SW 10:44 0:21 [nfsd]
root 335 0.0 0.9 1504 296 ? S 10:44 0:00 /usr/sbin/rpc.mountd PWD=/ CONSOLE=/dev/con
root 341 0.0 1.2 2772 392 ? S 10:44 0:15 /usr/sbin/sshd PWD=/ CONSOLE=/dev/console P
root 349 0.0 1.0 2056 328 ? S 10:44 0:00 /usr/sbin/xinetd -reuse PWD=/ CONSOLE=/dev/
daemon 363 0.0 0.3 1376 92 ? S 10:44 0:00 /usr/sbin/atd PWD=/ CONSOLE=/dev/console PR
root 366 0.0 0.6 1640 184 ? S 10:44 0:00 /usr/sbin/cron PWD=/ CONSOLE=/dev/console P
root 371 0.0 0.8 74000 252 ? S 10:44 0:05 /usr/sbin/apache-ssl PWD=/ CONSOLE=/dev/con
root 380 0.0 0.1 1232 56 tty8 S 10:44 0:00 run --restart --robust /var/lib/console-log
root 388 0.0 0.1 1232 56 tty9 S 10:44 0:00 run --restart --robust /var/lib/console-log
root 391 0.0 0.3 1792 96 tty8 S 10:44 0:00 less +F /var/log/exim/mainlog PWD=/var/lib/
root 392 0.0 0.3 2392 116 tty9 S 10:44 0:00 less +F /var/log/syslog PWD=/var/lib/consol
root 393 0.0 0.1 1248 60 tty1 S 10:44 0:00 /sbin/getty 38400 tty1 PATH=/usr/local/sbi
www-data 877 0.0 0.6 2980 208 ? S 10:53 0:00 /usr/lib/apache-ssl/gcache 33 /var/run/gcac
www-data 878 0.0 1.3 75820 420 ? S 10:53 0:05 /usr/sbin/apache-ssl PWD=/ CONSOLE=/dev/con
www-data 3833 0.0 1.5 80548 464 ? S 12:08 0:18 /usr/sbin/apache-ssl PWD=/ CONSOLE=/dev/con
www-data 3834 0.0 1.9 77284 596 ? S 12:08 0:07 /usr/sbin/apache-ssl PWD=/ CONSOLE=/dev/con
root 14411 2.5 4.8 5656 1484 ? S 18:07 0:00 /usr/sbin/sshd PWD=/ CONSOLE=/dev/console P
root 14413 10.7 5.1 2716 1572 pts/0 S 18:07 0:01 -bash USER=root LOGNAME=root HOME=/root PAT
root 14434 0.0 4.6 3284 1412 pts/0 R 18:07 0:00 ps eaux PWD=/root RSYNC_ADDR=/root/serv/.rs
La tronche du bloatware... 0,6% de 32 Mo en RAM...