Tout le monde n'utilise pas Gstreamer pour le moment et cela n'est pas portable sous Win ou MacOS. L'un des avantages de QT4 est qu'il existe en GPL sous Win et que donc, il va être possible de porter les librairies et les applis KDE sous cette plateforme, comme sur Mac.
Ah ? Je pensais, en lisant Pinaraf, que KDE4 allait (devait) s'adapter à ce qu'offrait le système d'exploitation visé :
- DirectSound pour Windows ;
- Quicktime pour Mac OS ;
- et donc GStreamer pour Linux.
Si Phonon est encore une couche d'abstraction au-dessus de cette mêlée, ça explique tout. J'imagine qu'il en aurait été autrement si GStreamer était porté sous Windows et/ou Mac OS.
Il est amusant de constater que les projets cherchant à être très portables ont tous tendance à avoir des cycles de versions très long.
8) de déléguer et partager l'administration entre plusieurs personnes avec la possibilité de révoquer l'une d'elle sans avoir à changer le(s) mot(s) de passe root.
Tu prends la mouche facilement, t'es pas un vrai trolleur. Ou plutôt si, t'es un vrai trolleur, mais de ceux qui se prennent au sérieux, les pires.
Non, je fais simplement partie de ceux qui trouvent ce système de notation complètement inutile tellement il est dévoyé.
J'ose, tout dépends du logiciel et des libs dont ils dépends, forcément si c'est un logiciel kde alors que kde4 est sorti, tu devras mettre à jours quasi tout kde. Si c'est un logiciel console, t'auras rien à mettre à jour ou presque. Et que ce soit un nouveau logiciel ou une nouvelle version d'un logiciel ça ne change rien dans le cas présent.
Malheureusement non, tu n'as pas du lire ce que j'ai écris. Imaginons que je n'ai pas encore installé Grisbi. Après quelques mois avec Debian testing, je souhaite tenir mes comptes, je cherche donc à installer Grisbi. J'utilise également d'autres applications sous Gnome et avec GTK+. Sauf que GTK+ a été mis à jour et pas pour des raisons de sécurité. Je me coltine donc la mise à jour de GTK+ et potentiellement d'autres applications.
Après avec Ubuntu t'as ça tous les six mois avec le système en entier, question de choix quoi, et t'auras pas non plus le choix de mettre à jour ou non certains composants. Sachant qu'il doit pas y avoir des masses de backports pour les stables d'Ubuntu (Là j'en sais rien, j'hypothétise.)
J'ai déjà dit qu'on n'était pas obligé puisque c'était supporté pendant au moins 18 mois. Quant aux backports, ça existe et plus officiellement que sous Debian où ça reste une hérésie. À croire qu'ils préfèrent que leurs utilisateurs se fassent chier à installer la nouvelle version de firefox tout seul (et de la pire manière).
Du coup si tu fais pas ta grosse mise à jour, tu te traines avec des vieilles versions, et j'ai des exemples de gens qui bossent sous linux mais qui sont pas particulièrement intéressés pas l'administration de la machine dans mon entourage. Avec une Debian testing, tu peux mettre à jour juste un logiciel à sa dernière version sans franchir la barrière psychologique du changement de version et ce que ça implique, recherche de tutos sur le net pour savoir quand on fait, temps nécessaire et tout.
Je viens de dire qu'on avait des backports, au pire. Ensuite, si la personne n'est guère intéressée comme tu dis, il vaut mieux que les logiciels ne montent pas en versions. Ça lui éviteras de se demander pourquoi CUPS imprimait hier et plus aujourd'hui (ne me dis pas que ça n'arrive jamais puisque ça m'est arrivé).
Mais sous Linux, on avait déjà Gstreamer...
Qu'est-ce qui peut garantir les compatibilité API et binaire ? Tout refaire soi-même, c'est ça ? Gstreamer est utilisé par Gnome mais il n'est pas non plus spécifique que je sache.
Soit certains ont la mémoire un peu courte, soit certains n'ont JAMAIS utilisé debian sarge et son 2.6.8 par défaut avec de l'USB. On préfère sans doute masquer la vérité que l'admettre, pourtant, ça n'a rien à voir avec Debian en particulier...
Et toi, tu fais « zealot » pour Debian, peut-être ?
Je ne vois pas en quoi mon point de vue serait « inutile » ou « non pertinent ».
Qu'à ne cela tienne : que les utilisateurs de Debian comme toi continuent à l'ignorer et ils ne seront pas près de comprendre pourquoi certains autres utilisateurs préfèrent utiliser Ubuntu stable plutôt que Debian testing/unstable pour un poste de travail.
Osez un peu me dire qu'on peut éviter de mettre à jour une testing pendant deux ou trois mois et, le jour où l'on voudra installer un nouveau logiciel (nouveau logiciel, pas nouvelle version d'un logiciel, hein), on ne sera pas obligé de mettre à jour d'autres composants contre notre plein gré. Parce que c'est entièrement faux. Et ne venez pas me servir la sempiternelle « tu n'as jamais dû utilisé Debian » parce que j'en viens.
Certes mais ils peuvent conserver la version qu'ils ont installé pendant au moins 18 mois (voire 3 ans pour la LTS) avec l'assurance de disposer de mises à jour concernant notamment les failles de sécurité.
Alors que dans le précédent modèle, ils n'ont pas d'autres choix que de suivre les mises à jour, quelqu'elles soient. Si tu pars en vacances, tu auras une bonne mise à jour à faire en rentrant. Pas de risques de ce genre avec une Ubuntu stable.
En outre, si tu ne veux pas suivre les mises à jour, tu ne peux rapidement plus rien installer car le moindre appel à aptitude install risque de mettre à jour d'autres paquets parfois avec des effets de bord. La mise à jour perpétuelle a également ses limites.
Y'a pas que la stable chez Debian... Tu pouvais installer sarge avec son nouvel installeur bien avant sa sortie en stable. Ce n'est pas ubuntu qui a filé un coup de pied au cul e debian pour la simplicité de l'installation puisque l'installeur est celui de debian !
Il y a un moment qu'Ubuntu n'utilise pas exclusivement l'installeur de Debian.
L'installation d'Ubuntu à partir du LiveCD est un modèle du genre.
C'est juste qu'ubuntu n'a pas les mêmes critères de stabilité que debian.
Non mais les critères de stabilité des distributions publiés en tant que saveur « stable » sont bien les mêmes.
Debian a fait le choix de ne pas utiliser PAM (puisqu'il faut ajouter son compte à un groupe) par défaut.
Qu'est-ce que c'est que ces âneries ?
Debian utilise PAM depuis fort longtemps. À quoi fais-tu donc allusion ?
Quel rapport y a-t-il entre PAM et l'un des groupes d'utilisateurs ?
Tu parle du wifi, sous Debian il ne m'a jamais posé aucun soucis. j'ai dû avoir beaucoup de chance.
Dans la mesure où ça dépend énormément du chipset de la carte wifi en question, oui, il faut avoir soit de la chance, soit choisir précautionneusement le matériel.
J'avoue que j'y passe du temps quand j'en ai encore mais je n'ai pas réussi, par exemple, à faire de ma Debian un AP avec mon Atheros à base d'AR5212.
Parce que les HOWTO et autres tutorials qui expliquent comment installer une carte (y compris avec wpa_supplicant), ça foisonne, mais pour expliquer comment vraiment faire du wifi (hostapd, radius et j'en passe), c'est plus dur (et les premiers polluent les résultats pour les seconds).
Deux "détails".
J'avais vu une étude/sondage qui montrait que la majorité des utilisateurs de Debian n'utilisait pas uniquement la branche stable mais un mélange de stable/testing/unstable.
C'est la démonstration que la distribution Debian est naze (prenez un autre terme péjoratif si vous voulez) pour un utilisateur qui veut installer vite et utiliser (beaucoup ou non).
Précisément. Et Ubuntu a répondu, pour moi, au besoin d'avoir, pour un poste de travail correct, une saveur intermédiaire entre la stable de Debian et la unstable, que testing, saveur à laquelle testing ne répondait pas car elle est plus proche d'unstable que de stable. En d'autres termes, elle évolue avec le temps et cumule donc les inconvénients de Debian stable (de longs intervalles entre versions finales) et ceux de l'unstable (des mises à jour constantes). Certains ne voient pas cela comme un inconvénient, tant mieux pour eux : Debian testing ou unstable leur conviendront « sans problème ».
D'autres diront qu'Ubuntu stable n'est pas « stable » mais la stabilité d'une distribution ne renvoie pas à la stabilité de l'ensemble de la logithèque fournie. Est-ce que Debian stable est moins stable lorsqu'on découvre des anomalies liées à certains logiciels après la publication ? Non. La stabilité pour une distribution, c'est l'assurance que les versions des logiciels fournis par celle-ci ne changeront pas. Les mises à jour devront se présenter sous la forme de patchs rétro-portés pour corriger une faille de sécurité ou une anomalie particulièrement critique liée ou non à la sécurité.
Cependant, pour les serveurs, je privilégie toujours Debian (sauf si mes clients m'imposent un autre choix).
Autre détail, beaucoup d'utilisateur de debian confondent leur distribution personnalisé (mélange de stable/testing/unstable) et la distribution Debian (stable).
Ainsi celui qui dit que Debian a NetworkManager, oublie probablement de dire que c'est dans testing ou unstable.
>Debian t'as un outil de configuration pour x ou y ...
oui, depuis le début, dpkg-reconfigure x (ou y) c'est pas super beau peut-être, mais t'as juste à dire oui/non machin ou truc
Debconf implémente une couche d'abstraction entre les données (questions et réponses) et l'affichage. Tu as non seulement une interface textuelle, une autre en ncurses mais également une pour Gnome et elle n'a rien à envier à d'autres interfaces.
>Si Debian est ultra simple, c'est quoi Ubuntu ?
Une interface graphique et un bon plan marketing peut-être
Des choix par défaut (puisqu'il s'agit de l'essence d'une distribution) qui conviennent mieux que Debian pour les mêmes technologies logicielles. Je saurais refaire en sorte que, sous Debian, mes clés USB se montent automatiquement sur mon bureau. Mais j'apprécie qu'Ubuntu propose cette intégration par défaut, ainsi, sur mon ordinateur personnel comme professionnel, j'ai l'assurance de retrouver le même fonctionnement.
>comment on fait sous Debian pour configurer du wifi ? Combien d'étape il faut
Ca c'est super chiant, avec madwifi en tout cas :
"m-a prepare" puis "m-a a-i madwifi" et enfin modprobe (de tête)
Et j'ajouterai, pour avoir la même chose avec fedora l'année dernière, j'ai bien luté, d'où la déduction : c'est dû à linux, avec freebsd ca marche impecablement.
Etc.
(Dans le etc. je comprend toute la gestion des paquets, excuse-moi mais un yum ca a pas toujours été à des années lumière de apt-get point de vue facilité d'utilisation ?)
Le Wifi est quand même un cas particulier et tu ne fais là allusion que du pilote madwifi, qui reste quand même le plus facile à vivre. Pour les autres, vu les choix de Debian (dont les DFSG), il sera plus difficile de configurer des cartes wifi avec des chipset nécessitant ndiswrapper ou des pilotes avec des firmwares non-libres (avec etch, on y a échappé mais avec lenny, ça va être comique). La carte réseau wifi fait partie du matériel comme le reste, on est en droit de s'attendre à ce qu'elle fonctionne aussi. Quand j'ai installé Ubuntu sur le portable professionnel, la carte wifi était fonctionnelle tout de suite (un Centrino). Quand tu installes une Debian sur une machine, les cartes réseaux sont fonctionnelles tout de suite, en général (sauf pour les tigon3 avec lenny prochainement, là aussi, ça va faire tout drôle).
En fait, le problème avec les gens qui critiquent Debian, c'est qu'ils ne l'ont jamais utilisée et ne parlent que sur des préjugés vieux et débiles. Bref, avant de propager de fausses informations (critiquer Debian j'ai l'impression que ça attire les foules), renseigne toi un minimum.
s/Debian/Ubuntu/g voire s/Debian/<ta distribution préférée>/g
Debconf est spécifique à Debian et à ses dérivées, dont Ubuntu.
Debconf est, selon moi, un excellent outil mais pour revenir dans le sujet de la présente discussion, ce n'est pas un élément qui différencie Debian d'Ubuntu puisque la seconde dérive de la première.
Alors comment expliques-tu que Slapper[1] (W32/SQLSlam-A)ait fait autant de dégâts en 2003 ?
- Les serveurs n'étaient pas patchés, ni à jour (malgré la disponibilité du patch par Microsoft) ;
- Les administrateurs n'ont pas réalisés ces mises à jour pour des raisons qui leur appartiennent ;
- Aucun logiciel venant d'on ne sait où, juste MS-SQL Server.
Et pourtant, ce n'était pas faute d'avoir eu un précédent avec Spida[2]...
Une première explication peut sans doute venir du fait qu'il faille installer tout un Service Pack, le SP3 pour corriger la faille.
Si tu parles du délai de grâce, c'est facile à vérifier. sudo flanque ses timestamps dans /var/run/sudo/loginduuser (problablement avec un touch ou assimilé). Il y crée une entrée qui porte le nom du tty depuis lequel la commande a été lancée, pour que ce délai n'affecte que la console de travail de l'utilisateur et pas une autre. Si tu lances l'affaire depuis X-Window (mais pas depuis un Xterm, rattaché, lui, à un /dev/pts/*), il n'y a pas de console et le timestamp s'applique sur unknown. Moralité : tous les processus qui ne sont pas ou plus rattachés à une console peuvent en profiter.
Si tu veux faire le test, colle l'applet de lancement d'applis en ligne de commande dans ton tableau de bord Gnome, ouvre une des applications du menu Administration d'Ubuntu avec ton mot de passe habituel, puis lance gksudo depuis l'applet avec la commande de ton choix.
Cet exemple n'est pas probant. Je ne trouve pas inconcevable que le fait d'ouvrir un outil qui requiert les droits "root" et donc, te demande une première fois ton mot de passe via gksudo, permette ensuite, dans le délai imparti par sudo, d'en ouvrir une autre qui les requiert également, sans te demander à nouveau le mot de passe. La session X11 est vue comme un seul et même tty. Dans une console, ce comportement est strictement le même. Le délai de grâce de sudo permet justement de taper systématiquement le mot de passe quand on tape plusieurs commandes. S'il fallait que je saisisse mon mot de passe à chaque fois que j'utilise un outil graphique lié à l'administration dans un délai inférieur à 5 minutes, ce serait très lourd et on tomberait dans le second cas que tu décries comme "Mauvais".
Il faut donc que :
- le processus ne soit pas rattaché à une console ;
- l'uid du processus fasse partie du groupe admin ;
- que le mot de passe d'un utilisateur du groupe ait été tapé il y a moins de 5 minutes auparavant.
Cela fait quand même pas mal de conditions à retenir.
En outre, revenons à aptitude : il y aura bien un moment où il va avoir besoin des privilèges de root, ne serait-ce que pour installer durablement les fichiers d'un paquet debian ou exécuter des scripts de post-installation créant un nouvel utilisateur ou appliquant des droits particuliers. Comment veux-tu éviter de demander le mot de passe de (root ou l'utilisateur via sudo) ? En créant plaçant un sgid sur l'ensemble du système de fichier ? sur l'exécutable d'aptitude ? Mais dans ce cas, si le compte de l'utilisateur est compromis, plus besoin de se farcir les failles locales pour escalader les privilèges...
Réduire le champ d'action obligatoire de root ne fera pas disparaître la menace d'intégrité du système pour autant.
J'ai bien lu ce que tu as écrit dans les différents liens, ainsi que ce que tes interlocuteurs ont également écrits.
J'ai surtout l'impression que tu te poses en architecte idéaliste de ce que devrait être Linux, en tant qu'héritier d'Unix.
Aucun système Unix et aucun système Linux qu'il m'a été donné de voir, n'ont osé touché à passwd.
Je veux bien admettre que la défiance envers les suid est largement responsable au fait que les administrateurs limitaient volontairement les suid au strict nécessaire, ne cherchant pas à exploiter l'outil (comme avec les sgid).
Je ne pense pas qu'on puisse simplement comparer des démons comme apache ou proftpd avec des commandes de base comme passwd ou des outils comme aptitude.
Les serveurs sont naturellement exposés aux attaques et leurs concepteurs ont essayé de pallier au problème de sécurité, car, effectivement, il n'y a que pour l'écoute du port privilégié que les privilèges de root sont réellement nécessaires. La plupart des serveurs sont capables de faire ce changement de privilèges une fois le port à l'écoute (apache mais aussi bind, postfix, openldap ou encore net-snmp).
Pour accéder aux fichiers en fonction des groupes unix, c'est un peu plus compliqué dans la mesure où il faut faire attention à ne pas trop en faire non plus sous peine d'inventer une nouvelle usine à gaz. En outre, l'utilisateur principal d'une Ubuntu, même dans ce cas précis, appartiendrait certainement à tous les groupes nécessaires pour l'administration de l'ordinateur. Le problème n'est donc toujours pas résolu car un « virus » aurait sans doute tôt fait de tirer parti de l'infrastructure sudo que tu décries tant.
Là où j'attends un peu plus que des « on-devrait-faire-comme-ça », c'est par rapport à X.org, sujet technique que je maîtrise mal en profondeur. Démonstration de ce que tu avances (c'est sans doute vrai), et que préconises-tu pour y pallier ?
Honnêtement, c'est quand même une drôle d'idée ...
Ce qui est inquiétant, c'est que le fait même que tu considères cette option comme seule solution de substitution, ça laisse quand même songeur. Il n'y pas que root sous Unix ... C'est de cette manière que l'on arrive à des horreurs de ce style :
Cette horreur vient aussi du fait du constructeur qui a pondu un script d'installation qui ne connait que root et suid. En fait, il aurait fallu que les distributions puissent avoir un outil gérant ce type de pilotes (comme le gestionnaire de pilotes propriétaires qu'on trouve sous Ubuntu et qui reste un moindre mal vu les dégâts de ton exemple). Par ailleurs, il est intéressant de constater que le constructeur a fait appel à suid que tu pléblicistes pourtant ailleurs mais uniquement sous la forme de groupes bien identifiés, certes.
Concernant sudo, on a déjà eu l'occasion d'en discuter ici :
En l'occurence, que Ubuntu s'appuie sur sudo plutôt que sur un truc à eux pour gagner des privilèges, c'est plutôt une bonne chose. Par contre, avoir à switcher systématiquement vers root chaque fois que l'on ouvre quelque chose dans le menu d'administration sous X-Window, ça me pose problème pour trois raisons :
1) L'utilisateur prend l'habitude de saisir son mot de passe pour un oui ou pour un non, et ça devient dangereux.
Quelle différence avec, par exemple, gksu, qui lui demaderait son mot de passe root ? L'utilisateur est bien obligé, pour certaines opérations, de disposer des privilèges de root (lancer des services à l'écoute de ports inférieurs à 1024, accéder à des fichiers appartenant uniquement à root, etc., etc.)
2) Il suffit de mettre un client graphique à l'écoute des événements pour intercepter ce mot de passe !
Donc, ce même client graphique sera capable d'intercepter le mot de passe quand il le tapera à l'invite de su dans son terminal X. Quoi de neuf ? Tu veux qu'il switche en console pour passer root ?
3) Au contraire de la majorité des outils en ligne de commande qui effectuent immédiatement l'opération demandée et ressortent, une application X (et GNOME à plus forte raison encore), est persistante dans l'environnement, et accapare et influe sur de nombreuses ressources connexes.
Pour obtenir un outil équivalent à synaptic en console, il faut lancer aptitude avec son interface ncurses, donc tant que tu n'as pas fini, l'application aura les privilèges de root.
Donc, tu n'aimes pas simplement gksudo (plutôt que sudo) mais carrément l'idée qu'on puisse offrir des outils d'administration via des clients X11. Que proposes-tu à la place ? A te lire, il faudrait pratiquement implémenter les droits UNIX aux clients X11 (afin d'éviter qu'une application puisse lire les entrées clavier dont elle n'a pas le focus, par exemple). On peut également penser à donner des droits via suid mais si l'attaquant peut modifier l'architecture d'apt-get, il pourra installer ce qu'il a envie d'installer, dont un rootkit en .deb. Tu ne pourras jamais complètement pallier les défauts de l'ICC dans le cadre d'un ordinateur personnel. Il faut que l'utilisateur principal prenne conscience des dangers lié à la sécurité informatique.
Créer des groupes à partir des périphériques dans /dev est une idée qui est déjà utilisé comme en atteste les différents groupes audio, cdrom, etc. Seulement, il n'y a rien de tel pour le réseau car le réseau sous Unix est l'exception qui confirme la règle : tout est fichier sauf le réseau.
Cependant, toute solution est à l'initiative du distributeur, du moins dans le cadre du public visé notamment par Ubuntu, car je vois mal des débutants chercher à créer des groupes pour satisfaire à leurs besoins. Ils ont plutôt tendance à faire d'horribles chmod 777.
Ubuntu n'est certainement pas encore parfaite mais, par rapport aux autres distributions, c'est la seule qui propose l'usage de sudo (et gksudo) par défaut ce qui permet d'utiliser des interfaces graphiques sans nécessiter de taper un mot de passe root que les débutants auraient tôt fait d'y mettre la même chose que pour leur utilisateur. On touche là finalement un problème humain plutôt que technique. La réponse ne peut donc être simplement technique.
Je ne prétend pas être un spécialiste mais le but premier des virus polymorphes (outre la recherche de vie artificielle) est d'éviter de se faire repérer par les antivirus à cause d'une signature qui serait unique.
Je pense que l'auteur de la dépêche aurait dû écrire :
"restreint ou payant" car si l'on devient client de Sourcefire, on a accès sans délais aux mises à jour. La restriction, dans ce cas, est présente sous la forme d'un délai de publication.
[^] # Re: Cycle de release
Posté par Raphaël SurcouF (site web personnel) . En réponse à la dépêche GNOME fête ses dix ans de logiciel libre. Évalué à 2.
Ah ? Je pensais, en lisant Pinaraf, que KDE4 allait (devait) s'adapter à ce qu'offrait le système d'exploitation visé :
- DirectSound pour Windows ;
- Quicktime pour Mac OS ;
- et donc GStreamer pour Linux.
Si Phonon est encore une couche d'abstraction au-dessus de cette mêlée, ça explique tout. J'imagine qu'il en aurait été autrement si GStreamer était porté sous Windows et/ou Mac OS.
Il est amusant de constater que les projets cherchant à être très portables ont tous tendance à avoir des cycles de versions très long.
[^] # Re: retard
Posté par Raphaël SurcouF (site web personnel) . En réponse au journal Debian sapumemesisailibre sai Linux qui le dit. Évalué à 2.
[^] # Re: Gnome 3.0
Posté par Raphaël SurcouF (site web personnel) . En réponse à la dépêche GNOME fête ses dix ans de logiciel libre. Évalué à -10.
[^] # Re: retard
Posté par Raphaël SurcouF (site web personnel) . En réponse au journal Debian sapumemesisailibre sai Linux qui le dit. Évalué à 1.
Non, je fais simplement partie de ceux qui trouvent ce système de notation complètement inutile tellement il est dévoyé.
Malheureusement non, tu n'as pas du lire ce que j'ai écris. Imaginons que je n'ai pas encore installé Grisbi. Après quelques mois avec Debian testing, je souhaite tenir mes comptes, je cherche donc à installer Grisbi. J'utilise également d'autres applications sous Gnome et avec GTK+. Sauf que GTK+ a été mis à jour et pas pour des raisons de sécurité. Je me coltine donc la mise à jour de GTK+ et potentiellement d'autres applications.
J'ai déjà dit qu'on n'était pas obligé puisque c'était supporté pendant au moins 18 mois. Quant aux backports, ça existe et plus officiellement que sous Debian où ça reste une hérésie. À croire qu'ils préfèrent que leurs utilisateurs se fassent chier à installer la nouvelle version de firefox tout seul (et de la pire manière).
Je viens de dire qu'on avait des backports, au pire. Ensuite, si la personne n'est guère intéressée comme tu dis, il vaut mieux que les logiciels ne montent pas en versions. Ça lui éviteras de se demander pourquoi CUPS imprimait hier et plus aujourd'hui (ne me dis pas que ça n'arrive jamais puisque ça m'est arrivé).
[^] # Re: Cycle de release
Posté par Raphaël SurcouF (site web personnel) . En réponse à la dépêche GNOME fête ses dix ans de logiciel libre. Évalué à -3.
Qu'est-ce qui peut garantir les compatibilité API et binaire ? Tout refaire soi-même, c'est ça ? Gstreamer est utilisé par Gnome mais il n'est pas non plus spécifique que je sache.
[^] # Re: retard
Posté par Raphaël SurcouF (site web personnel) . En réponse au journal Debian sapumemesisailibre sai Linux qui le dit. Évalué à -1.
[^] # Re: retard
Posté par Raphaël SurcouF (site web personnel) . En réponse au journal Debian sapumemesisailibre sai Linux qui le dit. Évalué à 0.
Je ne vois pas en quoi mon point de vue serait « inutile » ou « non pertinent ».
Qu'à ne cela tienne : que les utilisateurs de Debian comme toi continuent à l'ignorer et ils ne seront pas près de comprendre pourquoi certains autres utilisateurs préfèrent utiliser Ubuntu stable plutôt que Debian testing/unstable pour un poste de travail.
Osez un peu me dire qu'on peut éviter de mettre à jour une testing pendant deux ou trois mois et, le jour où l'on voudra installer un nouveau logiciel (nouveau logiciel, pas nouvelle version d'un logiciel, hein), on ne sera pas obligé de mettre à jour d'autres composants contre notre plein gré. Parce que c'est entièrement faux. Et ne venez pas me servir la sempiternelle « tu n'as jamais dû utilisé Debian » parce que j'en viens.
[^] # Re: retard
Posté par Raphaël SurcouF (site web personnel) . En réponse au journal Debian sapumemesisailibre sai Linux qui le dit. Évalué à 1.
Alors que dans le précédent modèle, ils n'ont pas d'autres choix que de suivre les mises à jour, quelqu'elles soient. Si tu pars en vacances, tu auras une bonne mise à jour à faire en rentrant. Pas de risques de ce genre avec une Ubuntu stable.
En outre, si tu ne veux pas suivre les mises à jour, tu ne peux rapidement plus rien installer car le moindre appel à aptitude install risque de mettre à jour d'autres paquets parfois avec des effets de bord. La mise à jour perpétuelle a également ses limites.
[^] # Re: retard
Posté par Raphaël SurcouF (site web personnel) . En réponse au journal Debian sapumemesisailibre sai Linux qui le dit. Évalué à 0.
Si tu ne le sais pas, ça ne marchera pas. C'est précisément ce que j'entendais.
[^] # Re: retard
Posté par Raphaël SurcouF (site web personnel) . En réponse au journal Debian sapumemesisailibre sai Linux qui le dit. Évalué à 0.
Il y a un moment qu'Ubuntu n'utilise pas exclusivement l'installeur de Debian.
L'installation d'Ubuntu à partir du LiveCD est un modèle du genre.
Non mais les critères de stabilité des distributions publiés en tant que saveur « stable » sont bien les mêmes.
[^] # Re: retard
Posté par Raphaël SurcouF (site web personnel) . En réponse au journal Debian sapumemesisailibre sai Linux qui le dit. Évalué à 3.
Qu'est-ce que c'est que ces âneries ?
Debian utilise PAM depuis fort longtemps. À quoi fais-tu donc allusion ?
Quel rapport y a-t-il entre PAM et l'un des groupes d'utilisateurs ?
[^] # Re: retard
Posté par Raphaël SurcouF (site web personnel) . En réponse au journal Debian sapumemesisailibre sai Linux qui le dit. Évalué à 1.
Dans la mesure où ça dépend énormément du chipset de la carte wifi en question, oui, il faut avoir soit de la chance, soit choisir précautionneusement le matériel.
J'avoue que j'y passe du temps quand j'en ai encore mais je n'ai pas réussi, par exemple, à faire de ma Debian un AP avec mon Atheros à base d'AR5212.
Parce que les HOWTO et autres tutorials qui expliquent comment installer une carte (y compris avec wpa_supplicant), ça foisonne, mais pour expliquer comment vraiment faire du wifi (hostapd, radius et j'en passe), c'est plus dur (et les premiers polluent les résultats pour les seconds).
[^] # Re: retard
Posté par Raphaël SurcouF (site web personnel) . En réponse au journal Debian sapumemesisailibre sai Linux qui le dit. Évalué à -1.
J'ai eu assez de problèmes entre lui et l'USB.
[^] # Re: retard
Posté par Raphaël SurcouF (site web personnel) . En réponse au journal Debian sapumemesisailibre sai Linux qui le dit. Évalué à 2.
Précisément. Et Ubuntu a répondu, pour moi, au besoin d'avoir, pour un poste de travail correct, une saveur intermédiaire entre la stable de Debian et la unstable, que testing, saveur à laquelle testing ne répondait pas car elle est plus proche d'unstable que de stable. En d'autres termes, elle évolue avec le temps et cumule donc les inconvénients de Debian stable (de longs intervalles entre versions finales) et ceux de l'unstable (des mises à jour constantes). Certains ne voient pas cela comme un inconvénient, tant mieux pour eux : Debian testing ou unstable leur conviendront « sans problème ».
D'autres diront qu'Ubuntu stable n'est pas « stable » mais la stabilité d'une distribution ne renvoie pas à la stabilité de l'ensemble de la logithèque fournie. Est-ce que Debian stable est moins stable lorsqu'on découvre des anomalies liées à certains logiciels après la publication ? Non. La stabilité pour une distribution, c'est l'assurance que les versions des logiciels fournis par celle-ci ne changeront pas. Les mises à jour devront se présenter sous la forme de patchs rétro-portés pour corriger une faille de sécurité ou une anomalie particulièrement critique liée ou non à la sécurité.
Cependant, pour les serveurs, je privilégie toujours Debian (sauf si mes clients m'imposent un autre choix).
Même si tu n'es pas sous Debian, il y a un moyen très simple de vérifier que ce que tu avances là est tout simplement faux :
http://packages.debian.org/stable/net/network-manager (0.6.4-6)
http://packages.debian.org/testing/net/network-manager (0.6.4-8)
http://packages.debian.org/unstable/net/network-manager (0.6.4-8)
Ce qui correpond, au patch près, à la version de Feisty.
http://packages.ubuntu.com/feisty/net/network-manager (0.6.4-6ubuntu7)
[^] # Re: retard
Posté par Raphaël SurcouF (site web personnel) . En réponse au journal Debian sapumemesisailibre sai Linux qui le dit. Évalué à 0.
Debconf implémente une couche d'abstraction entre les données (questions et réponses) et l'affichage. Tu as non seulement une interface textuelle, une autre en ncurses mais également une pour Gnome et elle n'a rien à envier à d'autres interfaces.
Des choix par défaut (puisqu'il s'agit de l'essence d'une distribution) qui conviennent mieux que Debian pour les mêmes technologies logicielles. Je saurais refaire en sorte que, sous Debian, mes clés USB se montent automatiquement sur mon bureau. Mais j'apprécie qu'Ubuntu propose cette intégration par défaut, ainsi, sur mon ordinateur personnel comme professionnel, j'ai l'assurance de retrouver le même fonctionnement.
Le Wifi est quand même un cas particulier et tu ne fais là allusion que du pilote madwifi, qui reste quand même le plus facile à vivre. Pour les autres, vu les choix de Debian (dont les DFSG), il sera plus difficile de configurer des cartes wifi avec des chipset nécessitant ndiswrapper ou des pilotes avec des firmwares non-libres (avec etch, on y a échappé mais avec lenny, ça va être comique). La carte réseau wifi fait partie du matériel comme le reste, on est en droit de s'attendre à ce qu'elle fonctionne aussi. Quand j'ai installé Ubuntu sur le portable professionnel, la carte wifi était fonctionnelle tout de suite (un Centrino). Quand tu installes une Debian sur une machine, les cartes réseaux sont fonctionnelles tout de suite, en général (sauf pour les tigon3 avec lenny prochainement, là aussi, ça va faire tout drôle).
[^] # Re: retard
Posté par Raphaël SurcouF (site web personnel) . En réponse au journal Debian sapumemesisailibre sai Linux qui le dit. Évalué à 5.
s/Debian/Ubuntu/g voire s/Debian/<ta distribution préférée>/g
[^] # Re: retard
Posté par Raphaël SurcouF (site web personnel) . En réponse au journal Debian sapumemesisailibre sai Linux qui le dit. Évalué à -1.
Debconf est, selon moi, un excellent outil mais pour revenir dans le sujet de la présente discussion, ce n'est pas un élément qui différencie Debian d'Ubuntu puisque la seconde dérive de la première.
[^] # Re: mouais
Posté par Raphaël SurcouF (site web personnel) . En réponse à la dépêche Les virus sous Linux. Évalué à 7.
- Les serveurs n'étaient pas patchés, ni à jour (malgré la disponibilité du patch par Microsoft) ;
- Les administrateurs n'ont pas réalisés ces mises à jour pour des raisons qui leur appartiennent ;
- Aucun logiciel venant d'on ne sait où, juste MS-SQL Server.
Et pourtant, ce n'était pas faute d'avoir eu un précédent avec Spida[2]...
Une première explication peut sans doute venir du fait qu'il faille installer tout un Service Pack, le SP3 pour corriger la faille.
[1]: http://www.oreillynet.com/onlamp/blog/2003/01/ms_sql_worm_ma(...)
http://www.certa.ssi.gouv.fr/site/CERTA-2002-AVI-157/index.h(...)
[2]: http://www.certa.ssi.gouv.fr/site/CERTA-2002-ALE-006/
[^] # Re: Parc linux non homogéne
Posté par Raphaël SurcouF (site web personnel) . En réponse à la dépêche Les virus sous Linux. Évalué à 1.
Cet exemple n'est pas probant. Je ne trouve pas inconcevable que le fait d'ouvrir un outil qui requiert les droits "root" et donc, te demande une première fois ton mot de passe via gksudo, permette ensuite, dans le délai imparti par sudo, d'en ouvrir une autre qui les requiert également, sans te demander à nouveau le mot de passe. La session X11 est vue comme un seul et même tty. Dans une console, ce comportement est strictement le même. Le délai de grâce de sudo permet justement de taper systématiquement le mot de passe quand on tape plusieurs commandes. S'il fallait que je saisisse mon mot de passe à chaque fois que j'utilise un outil graphique lié à l'administration dans un délai inférieur à 5 minutes, ce serait très lourd et on tomberait dans le second cas que tu décries comme "Mauvais".
Il faut donc que :
- le processus ne soit pas rattaché à une console ;
- l'uid du processus fasse partie du groupe admin ;
- que le mot de passe d'un utilisateur du groupe ait été tapé il y a moins de 5 minutes auparavant.
Cela fait quand même pas mal de conditions à retenir.
En outre, revenons à aptitude : il y aura bien un moment où il va avoir besoin des privilèges de root, ne serait-ce que pour installer durablement les fichiers d'un paquet debian ou exécuter des scripts de post-installation créant un nouvel utilisateur ou appliquant des droits particuliers. Comment veux-tu éviter de demander le mot de passe de (root ou l'utilisateur via sudo) ? En créant plaçant un sgid sur l'ensemble du système de fichier ? sur l'exécutable d'aptitude ? Mais dans ce cas, si le compte de l'utilisateur est compromis, plus besoin de se farcir les failles locales pour escalader les privilèges...
Réduire le champ d'action obligatoire de root ne fera pas disparaître la menace d'intégrité du système pour autant.
[^] # Re: Parc linux non homogéne
Posté par Raphaël SurcouF (site web personnel) . En réponse à la dépêche Les virus sous Linux. Évalué à 2.
J'ai surtout l'impression que tu te poses en architecte idéaliste de ce que devrait être Linux, en tant qu'héritier d'Unix.
Aucun système Unix et aucun système Linux qu'il m'a été donné de voir, n'ont osé touché à passwd.
Je veux bien admettre que la défiance envers les suid est largement responsable au fait que les administrateurs limitaient volontairement les suid au strict nécessaire, ne cherchant pas à exploiter l'outil (comme avec les sgid).
Je ne pense pas qu'on puisse simplement comparer des démons comme apache ou proftpd avec des commandes de base comme passwd ou des outils comme aptitude.
Les serveurs sont naturellement exposés aux attaques et leurs concepteurs ont essayé de pallier au problème de sécurité, car, effectivement, il n'y a que pour l'écoute du port privilégié que les privilèges de root sont réellement nécessaires. La plupart des serveurs sont capables de faire ce changement de privilèges une fois le port à l'écoute (apache mais aussi bind, postfix, openldap ou encore net-snmp).
Pour accéder aux fichiers en fonction des groupes unix, c'est un peu plus compliqué dans la mesure où il faut faire attention à ne pas trop en faire non plus sous peine d'inventer une nouvelle usine à gaz. En outre, l'utilisateur principal d'une Ubuntu, même dans ce cas précis, appartiendrait certainement à tous les groupes nécessaires pour l'administration de l'ordinateur. Le problème n'est donc toujours pas résolu car un « virus » aurait sans doute tôt fait de tirer parti de l'infrastructure sudo que tu décries tant.
Là où j'attends un peu plus que des « on-devrait-faire-comme-ça », c'est par rapport à X.org, sujet technique que je maîtrise mal en profondeur. Démonstration de ce que tu avances (c'est sans doute vrai), et que préconises-tu pour y pallier ?
[^] # Re: Parc linux non homogéne
Posté par Raphaël SurcouF (site web personnel) . En réponse à la dépêche Les virus sous Linux. Évalué à 2.
Quelle différence avec, par exemple, gksu, qui lui demaderait son mot de passe root ? L'utilisateur est bien obligé, pour certaines opérations, de disposer des privilèges de root (lancer des services à l'écoute de ports inférieurs à 1024, accéder à des fichiers appartenant uniquement à root, etc., etc.)
Donc, ce même client graphique sera capable d'intercepter le mot de passe quand il le tapera à l'invite de su dans son terminal X. Quoi de neuf ? Tu veux qu'il switche en console pour passer root ?
Pour obtenir un outil équivalent à synaptic en console, il faut lancer aptitude avec son interface ncurses, donc tant que tu n'as pas fini, l'application aura les privilèges de root.
Donc, tu n'aimes pas simplement gksudo (plutôt que sudo) mais carrément l'idée qu'on puisse offrir des outils d'administration via des clients X11. Que proposes-tu à la place ? A te lire, il faudrait pratiquement implémenter les droits UNIX aux clients X11 (afin d'éviter qu'une application puisse lire les entrées clavier dont elle n'a pas le focus, par exemple). On peut également penser à donner des droits via suid mais si l'attaquant peut modifier l'architecture d'apt-get, il pourra installer ce qu'il a envie d'installer, dont un rootkit en .deb. Tu ne pourras jamais complètement pallier les défauts de l'ICC dans le cadre d'un ordinateur personnel. Il faut que l'utilisateur principal prenne conscience des dangers lié à la sécurité informatique.
Créer des groupes à partir des périphériques dans /dev est une idée qui est déjà utilisé comme en atteste les différents groupes audio, cdrom, etc. Seulement, il n'y a rien de tel pour le réseau car le réseau sous Unix est l'exception qui confirme la règle : tout est fichier sauf le réseau.
Cependant, toute solution est à l'initiative du distributeur, du moins dans le cadre du public visé notamment par Ubuntu, car je vois mal des débutants chercher à créer des groupes pour satisfaire à leurs besoins. Ils ont plutôt tendance à faire d'horribles chmod 777.
Ubuntu n'est certainement pas encore parfaite mais, par rapport aux autres distributions, c'est la seule qui propose l'usage de sudo (et gksudo) par défaut ce qui permet d'utiliser des interfaces graphiques sans nécessiter de taper un mot de passe root que les débutants auraient tôt fait d'y mettre la même chose que pour leur utilisateur. On touche là finalement un problème humain plutôt que technique. La réponse ne peut donc être simplement technique.
[^] # Re: Étrange
Posté par Raphaël SurcouF (site web personnel) . En réponse à la dépêche Les virus sous Linux. Évalué à 1.
[^] # Re: Faille dans l'ICC...
Posté par Raphaël SurcouF (site web personnel) . En réponse à la dépêche Les virus sous Linux. Évalué à 3.
[^] # Re: "restreint et payant"
Posté par Raphaël SurcouF (site web personnel) . En réponse à la dépêche Le propriétaire de Snort achète ClamAV. Évalué à 4.
"restreint ou payant" car si l'on devient client de Sourcefire, on a accès sans délais aux mises à jour. La restriction, dans ce cas, est présente sous la forme d'un délai de publication.
[^] # Re: Seul la base virale à de la valeur
Posté par Raphaël SurcouF (site web personnel) . En réponse à la dépêche Le propriétaire de Snort achète ClamAV. Évalué à 2.
Parce qu'un IDS dont les bases de signatures et de règles qui ne sont pas à jour sert davantage ?