En précisant que non seulement on n'a pas besoin de monter un système de fichier pour lancer une vérif' dessus, mais qu'en réalité il ne faut surtout par le faire. D'ailleurs, fsck est assez éloquent lorsque quelqu'un essaie :-) :
Either there is a bug in fsck or some bonehead (you!) is checking a live filesystem. Please report bugs in fsck to ...
mais comment ce fait t'il qu'il n'est pas possible de modifier sa catégorie d'utilisateur?
C'est quoi une catégorie d'utilisateur ?
Si par là tu entends « une gestion des droits à la Windows », avec des bricolages style utilisateur ordinaires, utilisateurs avec pouvoir, administrateurs, etc., oui, tu risques d'être un peu dépaysé (je considère pour la suite que c'est à ce que tu penses).
D'une part, sous Unix, il n'y a pas trente-six niveaux d'accréditation initiaux : il y a root, et il y a les utilisateurs ordinaires. Le root a le droit de faire absolument tout ce qui lui plaît sans restriction (ce qui n'est même pas garanti avec l'administrateur Windows), jusqu'à démolir le système dans son intégralité si cela lui chante. Par contre, il ne peut y en avoir qu'un seul, et il porte forcément le numéro « 0 ». C'est d'ailleurs à ça qu'on le reconnaît. Cela fait donc deux bonnes raisons pour ne jamais travailler en temps normal sous le compte root. Il faut plutôt le considérer comme un pseudo-user, un peu comme Dieu qui s'incarne en homme quand il vient nous rendre visite sur Terre (c'est dire si ça doit arriver souvent :-).
Par contre, la devise d'UNIX est « tout est fichier », du moins en principe parce que cela a tendance à se perdre. Cela veut dire que toutes les ressources de ton système sont visibles sur le système de fichiers. En particulier, tous tes périphériques sont visibles sous la forme de « fichiers spéciaux », tous situés en pratique sous /dev.
S'il y a une entrée dans le catalogue du disque pour ces fichiers, ils ne vont cependant pas correspondre à une quantité de données sur les secteurs de ce disque, mais à un sous-programme du noyau pilotant le périphérique concerné. Ainsi, en lisant le contenu de /dev/hda, tu peux voir le contenu de ton disque secteur par secteur. Sur /dev/hdc, tu tombes généralement sur ton lecteur de CD et tu peux faire la même chose (et donc créer une image de disque ISO), etc.
C'est déjà très fort en soi parce que cela te permet d'exploiter directement tous tes périphs avec de simples commandes shell. Là où ça devient génial, c'est que tu peux de cette manière accorder des droits d'exploitation de tes ressources à certains utilisateurs de la même façon que tu leur donnerait des droits d'accès à tes documents (read-only, read-write, execution, etc.).
Dès lors, tu n'as plus besoin de catégories d'utilisateurs écrites en dur dans ton système. Il suffit de créer des groupes, y placer les fichiers spéciaux concernés ainsi que les répertoires de travail (/var/spool pour les imprimantes, par exemple), puis y inclure les utilisateurs à privilégier.
Un exemple qui fut pertinent mais qui tombe un peu en désuétude aujourd'hui était la gestion des ports série, à l'époque où on les trouvait encore par deux sur toutes les machines, et le premier recevait la souris car toutes les cartes n'étaient pas équipées du port PS/2 (une horreur dans sa conception, soit dit en passant). Le second recevait donc généralement le modem.
On pouvait légitimement souhaiter qu'un utilisateur de base puisse utiliser la souris mais pas le modem. Pour cela, il faut donc laisser un port série en libre usage, mais verrouiller l'autre. Autant que je sache, ce n'était pas faisable simplement sous Windows. Sous Linux, il suffisait de mettre /dev/ttyS0 dans un groupe et /dev/ttyS1 dans un autre.
Pour le reste, tu as eu le temps de lire les pages de manuel proposées ci-dessus. Pour l'histoire, /etc/passwd contenait initialement toutes les infos des utilisateurs (nom, prénom, login, et shell de travail), y compris le mot de passe sous forme codée. À l'époque, c'était largement suffisant. Aujourd'hui, des mots de passe même codés peuvent être facilement cassés, même par force brute. On a donc gardé les infos utilisateurs dans /etc/passwd par compatibilité, mais on a déporté les mots de passe codés dans /etc/shadow.
Dans le principe, c'est un codage à sens unique. On ne peut pas retrouver mathématiquement le mot de passe à partir de sa forme codée. Par contre, on peut coder ce que l'utilisateur tape et vérifier si cela concorde avec ce qui est enregistré.
Ca fonctionne plutot bien pour les cas pas trop tordus. Sinon, la distrib idéale et universelle (newbie<->guru), ça n'existe pas.
Je te suggère tout de même Ubuntu + Réglage des problèmes matos à la main. - A première vue - (j'insiste bien), il semble que c'est de cette manière que tu perdras le moins de temps.
Il manquait pourtant, à mon goût, une application web permettant d'accéder, depuis n'importe quel navigateur, à un outil de conjugaison. J'ai alors décidé de créer sensmotdire, une application Apache/PHP/MySQL de conjugaison française utilisant la base de connaissance de verbiste.
Précisement, ces mots manquent dans ta phrase.
D'ailleurs, l'application a beau ne pas être libre, le site est quand même utilisable sans restriction.
Les outils de conjugaison française libres sont assez méconnus, pourtant ils existent ! Verbiste, le premier d'entre eux, est une application GTK+, une applet GNOME et un outil en ligne de commande permettant de rechercher un verbe infinitif et un verbe conjugué dans une base de connaissance de plus de 6 800 verbes. [...] Konjue est une application KDE basée sur Verbiste qui remplit les mêmes fonctionnalités. Une version Emacs existe également. [...] J'ai alors décidé de créer sensmotdire, une application Apache/PHP/MySQL de conjugaison française utilisant la base de connaissance de Verbiste. C'est un projet jeune, largement perfectible, remplissant l'ensemble des fonctionalités de Verbiste. Bien évidement, celui-ci est prêt pour le web 2.0 avec un système d'auto-suggestion de verbe et un système d'onglet pour les propositions multiples (comme (<- l'un ou l'autre ->) par exemple en recherchant "sue").
C'est presque parfait ! :-)
Ceci dit, il existe déjà un outil qui permet d'accéder, depuis n'importe quel navigateur, à un outil de conjugaison : http://www.leconjugueur.com
Honnêtement, le sudo, on va dire pour être gentil que c'est un moindre mal. Je suis actuellement sous Ubuntu, et on en fait grand usage, sinon je l'utilise également sur les serveurs de production du travail. Personnellement, je trouve ça dégueulasse quand même.
Les avantages de sudo sont :
- Le traçage des commandes dans le log.
- La possibilité de révocation éventuelle (sans objet sur une machine personnelle).
- La non-divulgation du mot de passe root (nécessaire également en cas de révocation).
- La non-ouverture d'une console, qui en général reste ouverte après usage, ou que l'on confond avec une console utilisateur.
- Pouvoir exécuter des scripts shell en root ou autre (extrêmement sensible, pas souhaitable à mon avis).
Pour le reste, c'est un trou de sécurité béant. 9 fois sur 10, le mot de passe est le même que celui de la session utilisateur, mais surtout, le compte utilisateur peut exécuter n'importe quelle commande, et non pas une liste prédéfinie comme le permet /etc/sudoers.
ce qui revient effectivement à percer root, et permet de court-circuiter l'interdiction de connexion depuis l'extérieur.
Derrière ce cas de figure se cache, à mon humble avis, le véritable problème : les mauvaises configurations et gestions des droits UNIX initiaux. Dès que l'on se retrouve à devoir faire quelque chose qui sort de l'ordinaire, allez hop ! Un petit coup de sudo. Il n'est pas normal, par exemple, de prendre l'habitude de passer super-utilisateur pour lire un log, fût-il de sécurité. Si c'est quelque chose à faire plus d'une fois, alors il faut prendre le temps de passer le log en read-only pour un groupe donné, et de s'inclure dans ce groupe.
Unix, en principe, fait du VFS le point d'articulation de toute entité du système, ce qui devrait permettre de tout gérer de manière uniforme. Malheureusement, la plupart des ressources récentes tendent à s'en éloigner. Ça a commencé avec les IPC SysV, et ça se multiplie avec la tendance à vouloir faire du multiplateforme (qui en général, se traduit par une implémentation sous Windows, et des adaptations du produit sur le reste). Je pense qu'il faut commencer par combattre cela pour conserver un pouvoir d'administration, puis s'occuper de mettre en place un système efficace.
Dans le même esprit, est-ce que l'installation de logiciels via apt-get ou assimilé doit être également une opération super-utilisateur ? Les dépots et les archives étant signés, on sait, en principe, à l'avance ce qui doit être installé. On pourrait alors se contenter de commuter vers un groupe ou un utilisateur installer avec des droits de dépot sur le disque (et rien d'autre), mais pas forcément vers root.
Si on prend le cas d'une distribution personnelle dans lequel les mises à jour sont au minimum hebdomadaires, on passe son temps à saisir son mot de passe pour obtenir les droits d'admin. Il suffit à n'importe quel script de se mettre en écoute sur le serveur X pour briser la sécurité. Je suis sûr qu'en y allant au culot et en ouvrant une boite de dialogue impromptue, même les utilisateurs les plus avertis se feraient avoir, à force de switcher à tout bout de champ.
D'une manière générale, en ramenant toutes les opérations privilégiées à des autorisations UNIX et en plaçant une utilisateur dans tous les groupes, ne recrée-t-on pas un compte omnipotent (comme avec sudo) sans la restriction par mot de passe ? Pas tout-à-fait, car on n'autorise à chaque fois que ce qui a été explicitement prévu. Même les effets de bords que cela risque d'engendrer seront potentiellement moins dangereux que l'acquisition même temporaires des super-privilèges.
Je pense que l'avenir sur les machines personnelles est de :
- Ramener à une gestion UNIX des droits toutes les opérations qui ne sont pas irréversibles, telles qu'installer un .deb/.rpm signé, ou relancer un serveur web par exemple (typiquement, avec un apache graceful).
- Faire un usage plus répandu de suid. On a stigmatisé ce procédé à juste titre pendant un temps parce qu'il pouvait introduire une vulnérabilité si l'exécutable contenait une faille. Le problème est exactement le même avec sudo. On peut aussi envisager mettre tous les exécutables à SUID sur une partition dédiée, spécifiée dans le $PATH, et mettre les autres à nosuid. Enfin, on pourrait auditer l'exécution de ces fichiers, à la manière du /var/log/secure. Je pense que des chown/chgrp/chmod sur les fichiers concernés seraient plus propres qu'une entrée texte supplémentaire dans /etc/sudoers.
- Identifier les tâches privilégiées effectuées régulièrement. Par exemple, changer la résolution de son écran est une tâche qui peut avoir besoin d'être privilégiée, mais qui n'est pas fréquente. Si l'on prend le cas d'un utilisateur débutant, vaut-il mieux mettre en place un sudo exprès pour l'occasion, ou définir un groupe et un setuid, pour permettre à l'utilisateur de faire cette tâche comme on utilise passwd ? La réponse n'est pas évidente.
C'est le problème, d'ailleurs. Pour avoir assisté au montage en studio d'un ou deux journaux télévisés (France 3), je peux quand même confirmer que la majorité des reporters font correctement leur boulot, comme partout ailleurs.
La liberté de presse est pour ainsi dire aussi importante, en elle-même, que le droit de vote et dans les cas de guerre, il y a encore trop de journalistes qui ont perdu la vie ou été emprisonés à vie pour avoir voulu garantir l'information au public.
Tout cela pour trouver quoi en bout en chaîne ? toute la profession discréditée par quelques amateurs avides de sensationalisme et aux reportages sans lendemain.
C'est d'ailleurs exactement ce que vaut cet article à mon goût (que je me suis forcé à lire pour être objectif) : un papier qui dans deux mois aura laissé une trace aussi indélébile que le hula hoop.
[^] # Re: Merci
Posté par Obsidian . En réponse au message Bugs dans g++ ?. Évalué à 2.
Si c'est en GPL, mets-le en ligne, on trouvera plus vite !
[^] # Re: typo
Posté par Obsidian . En réponse à la dépêche Montrez-nous le code !. Évalué à 0.
insinuer être sûr -> insinuez être sûrs ...
# À coups de lance-serpent, ou ...
Posté par Obsidian . En réponse au message impossibilité de deplacer des fichiers dans une partition. Évalué à 2.
Essaie d'ouvrir le DHD et de retirer les cristaux de contrôle. Dans 2 épisodes sur 3, ils résolvent le problème de cette façon ...
[^] # Re: Hum...
Posté par Obsidian . En réponse au message force file system integrity check et mot de passe root. Évalué à 2.
# Catégorie d'utilisateur ?
Posté par Obsidian . En réponse au message Quel cryptage, quel format?. Évalué à 6.
C'est quoi une catégorie d'utilisateur ?
Si par là tu entends « une gestion des droits à la Windows », avec des bricolages style utilisateur ordinaires, utilisateurs avec pouvoir, administrateurs, etc., oui, tu risques d'être un peu dépaysé (je considère pour la suite que c'est à ce que tu penses).
D'une part, sous Unix, il n'y a pas trente-six niveaux d'accréditation initiaux : il y a root, et il y a les utilisateurs ordinaires. Le root a le droit de faire absolument tout ce qui lui plaît sans restriction (ce qui n'est même pas garanti avec l'administrateur Windows), jusqu'à démolir le système dans son intégralité si cela lui chante. Par contre, il ne peut y en avoir qu'un seul, et il porte forcément le numéro « 0 ». C'est d'ailleurs à ça qu'on le reconnaît. Cela fait donc deux bonnes raisons pour ne jamais travailler en temps normal sous le compte root. Il faut plutôt le considérer comme un pseudo-user, un peu comme Dieu qui s'incarne en homme quand il vient nous rendre visite sur Terre (c'est dire si ça doit arriver souvent :-).
Par contre, la devise d'UNIX est « tout est fichier », du moins en principe parce que cela a tendance à se perdre. Cela veut dire que toutes les ressources de ton système sont visibles sur le système de fichiers. En particulier, tous tes périphériques sont visibles sous la forme de « fichiers spéciaux », tous situés en pratique sous /dev.
S'il y a une entrée dans le catalogue du disque pour ces fichiers, ils ne vont cependant pas correspondre à une quantité de données sur les secteurs de ce disque, mais à un sous-programme du noyau pilotant le périphérique concerné. Ainsi, en lisant le contenu de /dev/hda, tu peux voir le contenu de ton disque secteur par secteur. Sur /dev/hdc, tu tombes généralement sur ton lecteur de CD et tu peux faire la même chose (et donc créer une image de disque ISO), etc.
C'est déjà très fort en soi parce que cela te permet d'exploiter directement tous tes périphs avec de simples commandes shell. Là où ça devient génial, c'est que tu peux de cette manière accorder des droits d'exploitation de tes ressources à certains utilisateurs de la même façon que tu leur donnerait des droits d'accès à tes documents (read-only, read-write, execution, etc.).
Dès lors, tu n'as plus besoin de catégories d'utilisateurs écrites en dur dans ton système. Il suffit de créer des groupes, y placer les fichiers spéciaux concernés ainsi que les répertoires de travail (/var/spool pour les imprimantes, par exemple), puis y inclure les utilisateurs à privilégier.
Un exemple qui fut pertinent mais qui tombe un peu en désuétude aujourd'hui était la gestion des ports série, à l'époque où on les trouvait encore par deux sur toutes les machines, et le premier recevait la souris car toutes les cartes n'étaient pas équipées du port PS/2 (une horreur dans sa conception, soit dit en passant). Le second recevait donc généralement le modem.
On pouvait légitimement souhaiter qu'un utilisateur de base puisse utiliser la souris mais pas le modem. Pour cela, il faut donc laisser un port série en libre usage, mais verrouiller l'autre. Autant que je sache, ce n'était pas faisable simplement sous Windows. Sous Linux, il suffisait de mettre /dev/ttyS0 dans un groupe et /dev/ttyS1 dans un autre.
Pour le reste, tu as eu le temps de lire les pages de manuel proposées ci-dessus. Pour l'histoire, /etc/passwd contenait initialement toutes les infos des utilisateurs (nom, prénom, login, et shell de travail), y compris le mot de passe sous forme codée. À l'époque, c'était largement suffisant. Aujourd'hui, des mots de passe même codés peuvent être facilement cassés, même par force brute. On a donc gardé les infos utilisateurs dans /etc/passwd par compatibilité, mais on a déporté les mots de passe codés dans /etc/shadow.
Dans le principe, c'est un codage à sens unique. On ne peut pas retrouver mathématiquement le mot de passe à partir de sa forme codée. Par contre, on peut coder ce que l'utilisateur tape et vérifier si cela concorde avec ce qui est enregistré.
[^] # Re: Et pour le lire ?
Posté par Obsidian . En réponse au journal éloge au libre et au mouvement communautaire.. Évalué à 2.
# Ton commentaire se blo
Posté par Obsidian . En réponse au message aide pour clavier non reconnu.... Évalué à 2.
Il me semble que tu es au moins parvenu à écrire ce message ...
# Linux Distrib Chooser
Posté par Obsidian . En réponse au message Cherche distribution Linux simple et puissante?. Évalué à 4.
http://www.zegeniestudios.net/ldc/
Ca fonctionne plutot bien pour les cas pas trop tordus. Sinon, la distrib idéale et universelle (newbie<->guru), ça n'existe pas.
Je te suggère tout de même Ubuntu + Réglage des problèmes matos à la main. - A première vue - (j'insiste bien), il semble que c'est de cette manière que tu perdras le moins de temps.
Qu'est-ce qui te bloque ?
# Normal
Posté par Obsidian . En réponse au message crontab ne m'obeit pas!. Évalué à 5.
C'est normal : c'est un logiciel libre !
(Je sors. -->[]).
# Jeunes enfants ?
Posté par Obsidian . En réponse à la dépêche Bitfrost : Un nouveau modèle de sécurité. Évalué à 2.
Comprendre par là : jusqu'à l'âge de 28 ans environ ! :-)
(pas taper, c'est vendredi après-tout ...)
[^] # Re: libre
Posté par Obsidian . En réponse au journal Musique sans DRM == Musique libre ?!. Évalué à 9.
[^] # Re: email en "clair"...
Posté par Obsidian . En réponse au journal Offre de stage à la Défense. Évalué à 3.
[^] # Re: Histoire de gagner du temps
Posté par Obsidian . En réponse au journal Offre de stage à la Défense. Évalué à 5.
Je pense que cela aurait beaucoup de succès ...
[^] # Re: Peut on passer à travers un proxy
Posté par Obsidian . En réponse au journal Decrypthon ouvert aux particuliers !. Évalué à 2.
[^] # Re: C'est prêt quand ?
Posté par Obsidian . En réponse à la dépêche La conjugaison française libre. Évalué à 2.
[^] # Re: C'est prêt quand ?
Posté par Obsidian . En réponse à la dépêche La conjugaison française libre. Évalué à 3.
Précisement, ces mots manquent dans ta phrase.
D'ailleurs, l'application a beau ne pas être libre, le site est quand même utilisable sans restriction.
Tout ceci n'enlève rien à ton projet ...
# Un boys band.
Posté par Obsidian . En réponse au message E17 ?. Évalué à 5.
http://fr.wikipedia.org/wiki/East_17
http://east17.free.fr/
http://www.caradisiac.com/php/fun_auto/stars/stars_243/east_(...)
Mais sous Linux, généralement ça ressemble à ça :
http://www.enlightenment.org/
# C'est prêt quand ?
Posté par Obsidian . En réponse à la dépêche La conjugaison française libre. Évalué à 1.
C'est presque parfait ! :-)
Ceci dit, il existe déjà un outil qui permet d'accéder, depuis n'importe quel navigateur, à un outil de conjugaison : http://www.leconjugueur.com
[^] # Re: Intrusion -> sudo sucks (un peu).
Posté par Obsidian . En réponse au journal Réagir en cas d'intrusion. Évalué à 2.
[^] # Re: Intrusion -> sudo sucks (un peu).
Posté par Obsidian . En réponse au journal Réagir en cas d'intrusion. Évalué à 10.
Les avantages de sudo sont :
- Le traçage des commandes dans le log.
- La possibilité de révocation éventuelle (sans objet sur une machine personnelle).
- La non-divulgation du mot de passe root (nécessaire également en cas de révocation).
- La non-ouverture d'une console, qui en général reste ouverte après usage, ou que l'on confond avec une console utilisateur.
- Pouvoir exécuter des scripts shell en root ou autre (extrêmement sensible, pas souhaitable à mon avis).
Pour le reste, c'est un trou de sécurité béant. 9 fois sur 10, le mot de passe est le même que celui de la session utilisateur, mais surtout, le compte utilisateur peut exécuter n'importe quelle commande, et non pas une liste prédéfinie comme le permet /etc/sudoers.
ce qui revient effectivement à percer root, et permet de court-circuiter l'interdiction de connexion depuis l'extérieur.
Derrière ce cas de figure se cache, à mon humble avis, le véritable problème : les mauvaises configurations et gestions des droits UNIX initiaux. Dès que l'on se retrouve à devoir faire quelque chose qui sort de l'ordinaire, allez hop ! Un petit coup de sudo. Il n'est pas normal, par exemple, de prendre l'habitude de passer super-utilisateur pour lire un log, fût-il de sécurité. Si c'est quelque chose à faire plus d'une fois, alors il faut prendre le temps de passer le log en read-only pour un groupe donné, et de s'inclure dans ce groupe.
Unix, en principe, fait du VFS le point d'articulation de toute entité du système, ce qui devrait permettre de tout gérer de manière uniforme. Malheureusement, la plupart des ressources récentes tendent à s'en éloigner. Ça a commencé avec les IPC SysV, et ça se multiplie avec la tendance à vouloir faire du multiplateforme (qui en général, se traduit par une implémentation sous Windows, et des adaptations du produit sur le reste). Je pense qu'il faut commencer par combattre cela pour conserver un pouvoir d'administration, puis s'occuper de mettre en place un système efficace.
Dans le même esprit, est-ce que l'installation de logiciels via apt-get ou assimilé doit être également une opération super-utilisateur ? Les dépots et les archives étant signés, on sait, en principe, à l'avance ce qui doit être installé. On pourrait alors se contenter de commuter vers un groupe ou un utilisateur installer avec des droits de dépot sur le disque (et rien d'autre), mais pas forcément vers root.
Si on prend le cas d'une distribution personnelle dans lequel les mises à jour sont au minimum hebdomadaires, on passe son temps à saisir son mot de passe pour obtenir les droits d'admin. Il suffit à n'importe quel script de se mettre en écoute sur le serveur X pour briser la sécurité. Je suis sûr qu'en y allant au culot et en ouvrant une boite de dialogue impromptue, même les utilisateurs les plus avertis se feraient avoir, à force de switcher à tout bout de champ.
D'une manière générale, en ramenant toutes les opérations privilégiées à des autorisations UNIX et en plaçant une utilisateur dans tous les groupes, ne recrée-t-on pas un compte omnipotent (comme avec sudo) sans la restriction par mot de passe ? Pas tout-à-fait, car on n'autorise à chaque fois que ce qui a été explicitement prévu. Même les effets de bords que cela risque d'engendrer seront potentiellement moins dangereux que l'acquisition même temporaires des super-privilèges.
Je pense que l'avenir sur les machines personnelles est de :
- Ramener à une gestion UNIX des droits toutes les opérations qui ne sont pas irréversibles, telles qu'installer un .deb/.rpm signé, ou relancer un serveur web par exemple (typiquement, avec un apache graceful).
- Faire un usage plus répandu de suid. On a stigmatisé ce procédé à juste titre pendant un temps parce qu'il pouvait introduire une vulnérabilité si l'exécutable contenait une faille. Le problème est exactement le même avec sudo. On peut aussi envisager mettre tous les exécutables à SUID sur une partition dédiée, spécifiée dans le $PATH, et mettre les autres à nosuid. Enfin, on pourrait auditer l'exécution de ces fichiers, à la manière du /var/log/secure. Je pense que des chown/chgrp/chmod sur les fichiers concernés seraient plus propres qu'une entrée texte supplémentaire dans /etc/sudoers.
- Identifier les tâches privilégiées effectuées régulièrement. Par exemple, changer la résolution de son écran est une tâche qui peut avoir besoin d'être privilégiée, mais qui n'est pas fréquente. Si l'on prend le cas d'un utilisateur débutant, vaut-il mieux mettre en place un sudo exprès pour l'occasion, ou définir un groupe et un setuid, pour permettre à l'utilisateur de faire cette tâche comme on utilise passwd ? La réponse n'est pas évidente.
Enfin, ce n'est que mon avis ... :-)
[^] # Re: ACPI
Posté par Obsidian . En réponse au message Mon horloge, sous exta.... Évalué à 3.
[^] # Re: Comme d'habitude
Posté par Obsidian . En réponse au journal Wikipedia et Francis Marmande. Évalué à 2.
La liberté de presse est pour ainsi dire aussi importante, en elle-même, que le droit de vote et dans les cas de guerre, il y a encore trop de journalistes qui ont perdu la vie ou été emprisonés à vie pour avoir voulu garantir l'information au public.
Tout cela pour trouver quoi en bout en chaîne ? toute la profession discréditée par quelques amateurs avides de sensationalisme et aux reportages sans lendemain.
C'est d'ailleurs exactement ce que vaut cet article à mon goût (que je me suis forcé à lire pour être objectif) : un papier qui dans deux mois aura laissé une trace aussi indélébile que le hula hoop.
Pauvre homme.
[^] # Re: Autres candidats ?
Posté par Obsidian . En réponse à la dépêche Les candidats à la présidentielle française interrogés sur les logiciels libres. Évalué à 6.
C'est surtout couché qu'il s'exprime le mieux, à mon avis.
Sinon, la « position » est toute trouvée : « software is like sex, it's better when it's free ».
[^] # Re: Tiens...
Posté par Obsidian . En réponse au journal Décès de Jean Ichbiah. Évalué à 2.
[^] # Re: Priorité des règles
Posté par Obsidian . En réponse au message iptable. Évalué à 2.